back to article Mass web infection leaves researcher scratching her head

Security maven Mary Landesman is in the midst of piecing together a who-done-it involving the infection of hundreds of websites that are generating an enormous amount of traffic. Or maybe it's a how-done-it. Either way, she's mostly drawing blanks. Landesman is a researcher for ScanSafe, a company that monitors the web surfing …

COMMENTS

This topic is closed for new posts.

Page:

  1. S

    Its just an apache module issue...

    Depending on the programming language - it'd be very easy to just have the contents of the .js compiled into the apache module.

    then you just send a new header and the content of the file from within the module to send the file to the web browser.

    As for including the file in the html, php files - it would again be pretty simple to amend the data sent to the browser. If it has got to move through apache - then it'll be a module there that is doing it.

    As for infiltration.... Systems get hacked everyday.

  2. Joe K
    Pirate

    So which browser?

    What, no mention of "That IE for you"?

    So does this attack punch through Opera and Firefox too?!?

  3. A J Stiles
    Linux

    Dodgy CMS

    I can second the remark about dodgy CMSes. I have had the dubious pleasure of disinfecting a machine which got infected by a rootkit, thanks to some badly-written CMS software (written in PHP, as it happens, but that's by the by). The problem is related to file upload by HTTP and the way Windows handles permissions. And it's not a problem with PHP per se, but with the way some people (mis)use it.

    Every file on a Windows box has execute permission set. (This appears to be a designed behaviour of Windows.) If you do not perform a chmod on it after upload, it keeps its execute bit. (This is entirely to be expected, and any other behaviour would violate the Principle of Least Surprise.) And if you transfer the uploaded file to a directory from which the web server can serve pages directly to the outside world, it becomes a CGI script. (This is a designed behaviour of the web server: on a UNIX system, files with execute set are executed and their STDOUT stream is served up.) In short, by uploading a crafted script from a Windows host using a badly-written PHP script on a webserver, you can execute arbitrary code on the server.

    A naïve developer testing PHP scripts on a Linux desktop machine with Apache + PHP installed (a very common environment for pre-deployment testing; always used to be a Windows desktop with Apache + PHP, but it's easier nowadays to get Linux up and running than it is to get Apache + PHP on Windows up and running) probably will not spot this, because files uploaded from Linux hosts usually do *not* have the execute bit set. Furthermore, development systems tend to be on the safe side of a NAT router and so will never end up getting the second half of the exploit (where someone gets in as root using a modified sshd.)

    One possible fix would be for the PHP developers to add a third parameter to move_uploaded_file() allowing you to set the permissions on the destination file, and make this default to 644 if absent. Until then, if you're developing scripts in PHP, don't forget to chmod() uploaded files -- and it probably wouldn't hurt to put a .htaccess file in your upload directory, blocking all HTTP transfers from there. (Scripts can still see the directory because they are accessing the filesystem natively, not via http.)

    But blaming PHP for this is a bit like blaming Severn Trent for drownings!

  4. Tim

    Connections?

    It is interesting that this new threat has appeared shortly after the disappearance of the Russian Business Network and when the Storm Worm is losing its power too, perhaps there is a connection to one or both. Presumably their operators are in need of a new income source and are among the limited number of people who have the ability and motivation to create this type of threat.

    Also, albeit more tenuously, the RBN was believed to be routed through the UK, where this is focussed on too.

  5. Carl

    More info - CMS more likely

    I dont spend all day doing this, honest...

    Of the 35 examples (or the 28 that gave helpful header responses), none had the same complement of modules. They (the 28) all did, however, run different Apaches and PHPs which makes me beleive the problem is there (or in something that uses them as a pre-requisite, eg a CMS.

    The js reference insertions were at various lines. Lowest is #4, highest is #223. However, in my 50-odd wget'd www.pehswarjobs home pages the inserted js reference is always at line 4. So it's not "programmed to move about". It pops up wherever it was planted - although that point clearly depends on where the attacker decided to plant it. Not that it doesnt randomly interrupt other HTML structures so some minimal "thought" has gone into planting it.

    Line feeds are interesting...

    In nearly all cases the rogue js reference was inserted with a preceding linefeed. This sticks out like a sore thumb in some HTMLs where there are otherwise no linefeeds. This makes me think someone on a Windows editor has inserted the rogue code into a file that is otherwise UNIX-like.

    Checking out peshawarjobs, I see its a rudimentary CMS written in PHP. My guess is someone has found out how to insert content and has done so, cutting and pasting his rogue code from a Windows editor.

    So look like Linux and Apache ARE secure, but there's no accounting for inexperienced PHP programmers.

  6. Rippy
    Stop

    @A J Stiles -- Least Surprises?

    > Every file on a Windows box has execute permission set.

    Uh, no. Executability is implied by the file extension in Windows.

    > If you do not perform a chmod on it after upload, it keeps its execute bit.

    If you're using ftp, the server should have a UMASK 666 (or less) setting to prevent this.

    > And if you transfer the uploaded file to a directory from which the web server can serve pages directly to the outside world, it becomes a CGI script.

    No, in Apache that's the XBITHACK setting, which is not set in any default config I've seen.

  7. Andrew Badera
    Stop

    Hit by 20 minute scan

    One of my client sites was hit by a 20 minute scan Saturday morning, attempting just about every type of injection I can identify, along with both Windows and Linux directory traversal sites. Unfortunately I only have limited access to logs due to host configuration, so the only data I captured was via invalid querystring. I'm not sure what other avenues were explored.

  8. Thomas Phillips

    I have new Cpanel Apache Serve rthat has this compromise.

    I have a new cpanel apache serve rthat has this compromise. It had a few web sites on it. Very little else. My Guess so far is that it is a Cpanel issue, and that a rootkit has been installed.

    Where do I start looking?

  9. Anonymous Coward
    Anonymous Coward

    About the Javascript

    Javascript is scaped code, that once unescaped, writes the attack code in the page for then execute it. It tries several attacks called in file MDAC, Slide, VML2, QuickTime, SuperBuddy, AudioFile, GOM and WVF and executed in this order. If one works, the rest of the attacks are not executed:

    if (startMDAC() || makeSlide() || startVML2() || startQuickTime() || startSuperBuddy() || startAudioFile() || startGOM() || startWVF()) {}

    It seems that this attacks are for Windows (several of them use ActiveX objects) and none of them has worked in Firefox + Linux, and some of them try to inject payload code using some Javascript buffer overrun.

    Of course, the point is not this Javascript but how the servers have been infected.

  10. Anonymous Coward
    Unhappy

    Name of Virus

    I hear that this virus can be identified with three anti-virus programs (including Kaspersky and AVG). Does anyone know what these vendors are calling the virus? It might help the rest of us determine if more anti-virus programs detect it. Or at least help us track when the one we're using *will* detect it...

  11. Julie Ho
    Flame

    fire ahead

    this is funny. watch out

  12. Anonymous Coward
    Anonymous Coward

    @Thomas Phillips

    Thomas,

    On WHT there is a competent guy who already cured the rootkit from several servers ( Scott.MC I think ).

    No point looking here, just guys claiming "that there will never be Linux viruses" and that it is "an Apache issue".

    Good luck!

  13. Anonymous Coward
    Anonymous Coward

    cpanel ?

    I have tested 10 random urls from the article and each site is hosted on a cpanel server. If someone could set up a script to check all the reported infected sites and see whether they're hosted on a cpanel server that'd be great.

    eg. if you can collect a list of say 1,000 known infected sites and write a script to see if they all answer on ports 2082/2083 (cpanel ports) we'd find the common link to this exploit for sure. My gut feeling says this is a cpanel-related root hole.

  14. Paul Murray
    Unhappy

    Worked out the site vulreability

    My guess at the site vilnerability is that these "mom-and-pop" websites are copy-and-pasting dodgy example code from somewhere.

  15. Anonymous Coward
    Anonymous Coward

    No Cure

    Scott.MC from WHT does NOT cure the rootkit - he knows how to clean up the exploit (which is serving the nasty js) from infected servers.

    HOWEVER, every cleaned up box is STILL rooted and rootable as no one so far has determined how the hackers gain root access to set up the exploit in the first place.

  16. Anonymous Coward
    Black Helicopters

    Cure symptoms

    At least a cure for symptoms is far better than the disdain campaign we can see there.

    If your site were a "roach motel" you can understand it is appreciable that customers do not see the roaches walking on the walls. And Scott.MC at least *knows* this is not an "Apache issue".

    Then, the exploit was very probably installed via cpanel ( hostgator and many other sites had a wide infection last year ), and the hole is very likely to be fixed with a clean update ( if the exploit was possible in up-to-date versions, there would be tens of thousands of sites infected right now ).

    Anyway Thomas Phillips would maybe give more info once he has been able to do some pest control.

  17. Richard Bishop

    ScanSafe Report

    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.

  18. A J Stiles
    Linux

    There's a simple solution

    There's a simple solution to this. We need a kernel / GCC hack that basically will make it impossible for code compiled on one computer to run on a different computer.

    Then all you, as a responsible sysadmin, need to do is build your system from the ground up -- exactly like a Gentoo Stage One install -- with this protection built-in. And, therefore, unable to run code compiled by anyone else. If you keep the gcc binary on a removable disk which you do actually remove when not in use, then nobody else can compile code to run on your system either.

    OK, it's not perfect; because we have C-T Complete interpreted languages such as Python. And it means you have to wait a few minutes while packages are compiled. But at least an exploit in an interpreted language depends on the interpreter, which is more than you could say for a compiled exploit.

  19. Karl Lattimer

    RE: Linux users should accept that security is also problem on this platform

    as a massive linux advocate I have to agree 100% here, there's no excuse for shoddy sys admin skills. Good firewalls, package updates and the regular round of sysadmin paranoia that someone is out to hack them are all good doses for us to take.

    I've had countless old mambo installations hijacked by worms, running on linux, and apache. They are generally easy enough to remove because of the quarantine aspect of proper user separation (the apache user can't write to /bin). However this doesn't at all mean that the server wouldn't be trying to hijack other machines or visitors machines. The intrinsic security of Linux can only be broken by bad sys admins and all too regularly it is.

  20. Ross

    A rehash?

    Had some time to play at last :o)

    Gotten a hold of the .js and binary. Seems the binary is served in a similar fashion to the .js file - random file name that is deleted after being served.

    The server exploit seems to be the one Matt Bradley above linked to. It's only usable locally tho so owners of affected domains might want to check their systems for key loggers. I really can't imagine the attackers bought a hosting account on each affected server, although it may be possible to execute the exploit through the "try before you buy" test account that some providers have...

    Frankly if I were one of the users caught out by this, and my customers were being trojaned and it did turn out to be an exploit that was patched back in September 2006 I'd be fuming.

    The binary is a 453k PE file. PEiD says it's packed with:

    UPX 0.89.6 - 1.02 / 1.05 - 1.24 modified -> Markus & Laszlo [Overlay]

    Going to have to find my OllyDB CD out to see what's inside.

  21. Morely Dotes
    Alert

    @ Erik Aamot

    "does this perhaps mean they are using cheap shared hosting or webhost reseller packages without proper WebHostManagement licenses(?)"

    Not meaning to be rude here, merely baffled. WTF do you by "WebHostManagement licenses"? Is there some secret society which requires Web host owners to pay a licensing fee, an which so far has managed to miss noticing my hosting service?

    Bang icon because there's no ? icon.

  22. Ross

    @Morely Dotes

    WHM is a software package (see www.cpanel.net) - there was a locally exploitable vuln in it in late 2006 that elevated the attackers privs to root. It was patched fairly swiftly, but those ppl running it without paying for it don't get support and so no patch.

    No need to worry about the hosting mafia :o)

  23. zombini
    Thumb Up

    Norton Tested

    I am getting a number of hits when testing with NIS2008 from each of those sites. Some appear to have been cleaned up:

    - Gretech GOMPlayer openURL BO

    - MSIE ADODB.Stream Object File Installation Weakness

    - VML BO

    - MSIE WebViewFolderIcon BO

    - MSIE RealPlayer sometihing..

    - QuickTime something

    - AOL Superbuddy BO

    There were a couple of others.

  24. John Bowles

    @ A J Stiles

    Until someone slips code into GCC.

    Its been done before, as a proof of concept.

    A backdoor was inserted into the 'login' program on a Unix system - this was detectable in the source, however, so he modified the compiler to insert the backdoor at compile time. Clean source built with that compiler would still have the backdoor.

    He went even further though - the backdoor code was still visible in the source code for the compiler, so he modified the compiler further, to insert the backdoor in itself when compiled.

    He then built a new compiler with fresh, unmodified code and his hacked compiler. This produced a compiler from clean source that contained the backdoor, and would insert the backdoor in any copy of the compiler that it compiled, and any of those compilers would insert the backdoor in 'login'. No source code audit would ever detect it.

    Starting fresh from source still needs a compiler, and that compiler can be enough to exploit the entire system.

    Not saying it'd be easy to do, but a compile only system doesn't protect you from everything.

  25. A J Stiles
    Linux

    @John Bowles

    That sounds like Ken Thompson's "reflections on trusting trust" paper. And what it comes down to is this: Anything compiled with a tainted compiler is liable to be compromised, and may behave in ways other than suggested by the Source Code.

    The way around it, if you don't trust the compiler, is to rewrite the compiler -- starting from clean Source Code -- in straight assembler. You know it's clean because you wrote it. Nothing compiled with a "clean" compiler will do anything that was not in the Source Code.

    But there's another way that takes a little bit less hard work. All you really need is to write in assembler is a *partial* C *interpreter*: it only has to be able to interpret enough of the language to run the compiler Source Code interpretatively. It doesn't matter if it's slow, because it only needs to be run once. You know the interpreter is clean because you wrote it, and you know that the interpreted compiler is also clean because you checked the Source Code. Therefore, you know you will be compiling a "clean" compiler.

    Well, at least to the extent that you trust the silicon .....

    Depending on the sophistication of the backdoor, even a C interpreter written in C might be enough protection (since the compiled compiler is never seeing compiler Source Code; only the interpreter Source Code, which it probably doesn't know about.)

    You're right in saying that a compile only system doesn't protect you from everything, but that is no reason not to think it's a good idea anyway. Seat belts don't protect you from your car going on fire, but that's not a good reason not to wear one.

Page:

This topic is closed for new posts.

Other stories you might like