Posts by Richard Bishop 7 publicly visible posts • joined 12 Jan 2008
With Microsoft unable to sell M$ Word surely that means that there are less people being exposed to this kind of thing?
Maybe a judge should pass a ruling banning them from selling any software - the world would be a much better place!
Surely though, it doesn't take two years to work its way through M$ before a fix is released - Apple managed it in 24 hours with the iPhone SMS exploit! Long live Steve!
<-- Stop, because Microsoft had to.
Visiting the page on Virgin Media gives a blank page (0 bytes). It seems that they have redirected requests to en.wikipedia.org to some proxy at 62.30.249.131 - to get the proxy IP simply try and edit any page on Wikipedia which will reveal the IP. Visiting any other website or one of the many 'whatismyip' websites shows me my actual public IP. The Virgin proxy doesn't seem to add or modify any headers though - you literally get a blank page.
Visiting the page through Eclipse Internet gives me a 404 error page
"The Web server cannot find the file or script you asked for. Please check the URL to ensure that the path is correct." This is apparantly generated by a Squid server (squid/2.6.STABLE15) called 'wensleydale.karoo.lan' - public IP is 213.249.193.2. The Eclipse proxy appears to be adding HTTP via, cache and error 'access denied' headers. Again, visiting any other websites displays my 'real ip'.
<- Flaming ISP's!
One of the Universities wrote some software that would automatically ping a central service, together with trace routes and similar (it might have been MIT).
Edit:
It was the University of Washington - http://adeona.cs.washington.edu/ It's running on my lappy and it's not been stolen yet.
<-- Bill, since if the laptop was running Vista I'd probably want rid of it anyway!
One of the Universities wrote some software that would automatically ping a central service, together with trace routes and similar (it might have been MIT).
Edit:
It was the University of Washington - http://adeona.cs.washington.edu/ it's running on my lappy and it's not be stolen yet.
<-- Bill, since if the laptop was running Vista I'd probably want rid of it anyway!
ScanSafe have posted a report on their findings on their blog:
http://blog.scansafe.com/journal/2008/1/15/mom-pop-sites-hit-hard-by-host-compromise.html
It's definitely a kernel issue though - read the posts on the WHT forum which detail many people having the same issues - and all are running Linux.
Finjan are calling this "random.js toolkit" and have apparantly been seeing this since late on in 2007 - see here for details and a nice writeup by them. http://www.finjan.com/GetObject.aspx?ObjId=550&Openform=50
@Anonymous Coward:
People are linking Apache/PHP as Linux because all of the affected sites were running Linux! You've obviously not read over the WHT postings which detail those affected and whose servers have been exploited to serve this junk. What's more - it's not an Apache or PHP exploit (though some application layer stuff may have been used for the initial compromise), it's a rootkit which has buried itself deep down at the kernel. From what I've read it looks like there might be an unpublished flaw in cpanel (though I'm sure I've heard before that there are some lesser known exploits in cpanel) which allows an attacker to gain root on the box and install the rookit.
This has gotten me thinking now. Following a bit of Googling for 'trojan kmem kernel' I've found a number of forum posts reporting very similar issues:
Here for instance: http://www.gossamer-threads.com/lists/fulldisc/full-disclosure/27857
As one of the posts I've read [somewhere] says, inserting the malicious code through an Apache module would be extremely straightforward to do, though having a kernel module doing the same thing (although much more complicated to write) would be much harder to detect (it's got us talking!) and much more difficult to remove - half the problem being to know what you're looking for.
It looks like an evolution of the code on that xpire.info link I posted above which inserted an Iframe into the page; in that now the compromised server is hosting the whole shebang. It also shows hallmarks of a modern web attacks:
1) Hiding from sys-admins trying to remove it in order to remain active as long as possible
2) Giving researchers the run-around by only exploiting once per IP
3) Using a number of published exploits in order to get a binary onto the target machine
4) Obfuscating the actual exploit code through various means to try to prevent static/automated analysis
It's certainly not 'randomly' inserting the code into the page / serving the exploit. It's doing it once per IP, once you've had your fill of exploit then there's no coming back for seconds. Randomly inserting the code would be pretty silly - some people (potentially AV researchers) would get multiple copies, whilst others wouldn't get it at all. Some people may visit multiple pages within the same site - thereby giving further chances that they may randomly encounter the exploit, whereas others may visit the homepage then move on. Serving the malicious code once per IP gives everybody a fair shot at getting infected whilst slowing researchers down at little.
Unlike Storm and similar the server isn't generating the obfuscated exploit code on the fly. The server contains a static copy of the trojan and the obfuscated exploit, with probably a simple string replace on the "var arg = xxx". This means that every copy of the xxxxx.js file is identical across all servers and all domains. As posted on the WHT forum page, there are no traces of the .js files on the server - these are obviously being generated on the fly. There is obviously quite a bit of keeping state happening on the server though - who has downloaded the files already? what filename did I tell this IP address to use? (unless it's a hash of some sort), I would guess this is stored in a file somewhere on the system (which the rootkit is then denying the existance of).
It would be interesting to know how the trojan infected the servers in the first place, given that in order to install either an Apache module or a kernel rootkit would require root privileges. Could this be a buggy PHP script with some fancy privilege escalation or has the attacker somehow SSH'd into the box? I guess the only way to answer these questions would be to get hold of a compromised box and hope they didn't clear the log files out.
It would be interesting to look at the rootkit itself though - modifying Apache replies on the fly can't be the easiest thing in the world to achieve.
This is certainly an interesting one. Initially I thought it must be an Apache module that had installed or doctored which was inserting the code into the pages, I've certainly not seen anything like this working at kernel level before.
This doesn't appear to be that difficult to write signatures (or heuristic rules) for though, the exploit xxxxx.js files are all the same across domains other than the filenames and the very first line of the file 'var arg = '
Looks like a bit of a pain to clean up your server though - especially given that chkrootkit doesn't appear to find it according to that WHT page.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
