New Alureon Rootkit Takes Malware To New Level

Trailrunner7 writes "A new version of the venerable Alureon malware has appeared, and this one includes some odd behavior designed to prevent analysis and detection by antimalware systems. However, this isn't the typical evasion algorithm, as it uses some unusual encryption and decryption routines to make life much more difficult for analysts and users whose machines have been infected. Alureon is a well-known and oft-researched malware family that has some rootkit-like capabilities in some of its variations. The newest version of the malware exhibits some behavior that researchers haven't seen before and which make it more problematic for antimalware software to detect it and for experts to break down its components."

Comments

A silly question

[countertrolling]

Why can't the system be installed on ROM? At the very least, it will boot clean every time...

Re:A silly question

[drolli]

Because then security leaks cant be fixed? I suggest at least some switch to update the software. On the other hand that could be achieved with any USB stick with a write protect switch.

Re:A silly question

[improfane]

Malicious software can still be malicious while in memory, send spam, botnet etc. A running exploit of a readonly system is just as compromised as a running writable one, until you turn it off of course. You would never be able to patch it unless you patch the ROM or receive memory patches.

Re:A silly question

[datapharmer]

EEPROM can be... this is essentially what coreboot is.

Re:A silly question

[postbigbang]

No.

A kernel launched from write-protected, hence read-only memory, is going to be the same every time. Subsequent loads can infect a kernel that sits in writeable memory, where malware can do its work. ROMs just are not changeable, unless they're of a genre that permits this, like electrically-erasible programmable read only memory, or EEROMs, which usually take an electrical charge or specific freqs of light to allow change.

My problem with this kit is that we would probably prosecute someone that makes malaria or HIV or even the common cold viruses more difficult to cure. Yes, tools need to be made to discover how to secure system more thoroughly, but we're not instilling diligence on the parts of OS makers and sysadmins to stop the problems we have now.

Re:A silly question

[countertrolling]

On the other hand that could be achieved with any USB stick with a write protect switch.

That would be the proper procedure that I would find perfectly acceptable, but all the present day USB sticks with write protect do it with software. It's not like the floppies that made it physically impossible to write by literally turning off the ability to write. It's one of the giant steps backwards that the industry has made.. intentionally? I don't know, but my suspicions run high.

Re:A silly question

[grumbel]

A more interesting question would be why systems are still so shitty at even basic self verification. A Linux might verify a packages signature on install, but after that, there is absolutely no oversight about what is happening to that package. On a regular dist-upgrade it can't even properly tell apart which config files have been touched by the user and which have been automatically generated.

This is not even an especially hard problem to solve, instead of dumping everything into a single directory tree, dump all packages into a read-only tree and save all the changes to that tree into a completely separate directory tree that is mounted on top of the other one via some kind of unionfs. This wouldn't just be good for security, it would also make a users life much easier, as changes and hacks that divert from the vanilla system would be instantly visible.

Re:A silly question

[tlhIngan]

Because then security leaks cant be fixed? I suggest at least some switch to update the software. On the other hand that could be achieved with any USB stick with a write protect switch.

If software can turn off "write protect" then you don't have anything. Period. Because anything legit software can do, malware can do. If it can do an update of the ROM image, then malware can as well (and there was a virus that overwrote or attempted to overwrite the BIOS).

If you make it harder by requiring the user flip a switch, you'll find after the first update that 75% of the people didn't bother updating. After the second, 95% of the switches will be in the "allow write" position as people get lazy. (It will asymptotically approach 100%). If you make it so they have to flip the switch back to write-protect mode in order to boot, well, you'll asymtotically reach 100% of people who don't bother updating because it's too troublesome.

Re:A silly question

[hairyfeet]

Because then all they have to do is figure out a buffer overflow for the default browser and you can't patch it so you're boned? As a PC repairman my question would be this....why bother? Do you have ANY idea how many unpatched XP boxes are out there? Boxes with NO AV, or the same trialware Norton crap it came with in 05, loaded up with P2P crap or running "Razr1911 Pro SP2 Corp" that has WU turned off to keep from getting WGA'd? If the number was less than 60 million frankly I'd be amazed.

So I don't see why they are bothering with this now when they have so much low hanging fruit left, unless they are planning on using it for a spear phishing attack. The time to be releasing something like this would be about 6 months before XP EOL, when the amount of unpatched "Razr1911 Windows 7 all versions pre-activated" will be much higher, although even then most likely all the updates will be turned off (already seeing that BTW, as MSFT figured out how to kill the Razr1911 OEM hack on the RTM version so pirates are just killing WU like they did with XP) so again hacking will be easy.

As a guy that cleans them for a living I can tell you infecting a Windows box simply isn't that hard, not because MSFT built a bad OS (I'd argue that properly patched an XP or 7 box is actually pretty solid) but because there are so many pirated versions, boxes controlled by people that will happily click on any email attachment, or download "Hot_Lesbos.avi.exe" and run it without a second thought.

Hell Limewire has been dead for a couple of years yet I still see new boxes infected with malware calling itself "the new Limewire" because simply ripping off the old Limewire icons is enough to get the clueless to happily turn off any security that attempts to stop them installing it so they can snatch the latest pop crap. Social engineering with literally millions of clueless users makes it butt simple to infect masses of boxes with just a little carrot at the end of a stick. This seems like a hell of a lot more work than required unless they have some corporate target in mind.

Re:A silly question

[tlhIngan]

That would be the proper procedure that I would find perfectly acceptable, but all the present day USB sticks with write protect do it with software. It's not like the floppies that made it physically impossible to write by literally turning off the ability to write. It's one of the giant steps backwards that the industry has made.. intentionally? I don't know, but my suspicions run high.

A floppy drive is easy - a floppy drive is just some motors in a cage - the floppy controller resides o nthe motherboard and tells those motors how to operate. The write protect switch can easily disable the floppy drive's write amplifier.

Something like a hard drive is hard - you can't disable the read/write line to the (PATA) drive, because you have to write to the registers in order for it to work. It's why forensic labs have drive write blockers - they pass through everything except the write commands - these things require intelligence in order to perform their tasks.

Ditto USB drives - you can't disable writing to the NAND flash chips itself, because you have to write to them in order to read from them (as well as do things like identify the capacity and such), so the controller has to have intelligence to handle ignoring write commands from the USB host (and even then some drives still do wear levelling and garbage collection on the raw media - so you need lots of firmware hooks to disable that, too).

The problem is, there's no way to physically make it impossible to write. Some flash chips it was possible - you protected it by disabling the high-voltage programming power source - without that voltage, programming would be problematic. But these days, the charge circuits to do that are built into the silicon so the manufacturers don't have to spend the extra dollar on external power supply circuits and PCB routing, because the intent for writable nonvolatile memory was being able to write to them.

Making a write-protect switch these days is difficult and often requires extra circuits in order to have the necessary intelligence to block write commands and not all writes (which disables normal read operations as well).

Re:A silly question

[countertrolling]

You're missing part of the discussion where a disk or USB stick with true physical write protection will mitigate the problem considerably.. I don't really care what the 'clueless' do. If they want to hose their systems, that's just more business for you and me. I just want something to protect myself. Word of mouth will catch on in due time... For now, I make images of fresh installs to save myself and clients a great deal of time.. What used to take two hours is fixed in less than 15 minutes. Booting into a live CD allows me to recoup their docs and stuff before I do the restore.

Re:A silly question

[drsmithy]

EEPROM can be... this is essentially what coreboot is.

If the end user can do it, the end user can be convinced to do it by malware.

Re:A silly question

[_0xd0ad]

The point is that the ROM doesn't need to be infected. The system has to load into RAM to actually run, and if you can't patch the OS (easily or at all) you can't fix things like remotely-exploitable buffer underruns.

Then you just end up with malware that network-boots: as soon as you fire up your pristine kernel and connect it to the network, one of the other infected machines on the network re-infects it and the malware is free to do whatever it wants in user-space (send spam, data-mine, participate in a DDOS, and try to spread itself to the other computers on the network). If you can't patch the hole that's being used as an infection vector, you're basically SOL.

Re:A silly question

[v1]

I would have found that hard to believe before having seen it in action myself.

My camera uses an SD card of course, but it can use that open source camera software too. But to use it, you have to write to to a new card, and then turn on the write protect switch or the camera won't boot it. Once thge new software is booted, it can save pictures to the card. Good proof that the write protect on the SD card is more of a "suggestion" than a "switch".

Re:A silly question

[Technician]

I did that because when I worked in repair I needed working copies (they get damaged) that would not lose the tape. You can buy disks without the notch so there is no protect to fall off. To prevent accidents, the switch I put in the drive was a reed switch. It required knowledge of the switch as well as the pocket screwdriver with the magnet in the end to turn on the hidden write switch while writing another working copy of the diagnostic floppy disks.

None of the floppies in the field service kit had a write enable notch. It makes no sense taking one customer's infection and giving it to someone else. The modern replacement is a burned DVD instead of a thumb drive. Use read only media for any of your service materials. No exceptions.

Re:A silly question

[grumbel]

And how do you propose that the "pristine" packages below it are updated without giving malware the same priviledges or ability to update those packages with infected versions?

Packages and their updates have a proper signature from your distributor, malware doesn't. The point here isn't so much to create the one true final solution to computer security, but to have some robust tracking of origin of a package and its containing files, on top of that you could then build a whitelist, WoT or whatever to improve things even further. As of right now there really isn't much of a build in form of tracking for what an application does to your system or how it was modified.

Sadly, the end result is there isn't any way to have the openness of a PC without having the dilligence of being able to maintain it properly.

Quite the opposite, a proper secure system would be much more open then our current PCs, as it would allow users to mess around with their system, run any app they want and all of that without having the fear of braking anything, as the system would be able to keep track of all the changes and undo them if needed.

The OLPC for example has that (in theory at least, real world implementation is still incomplete). You can essentially setup the thing so that it shows you what applications other people in your friends lists are running. If you want to copy that application you just click on it and the system will copy the app over and run it on your system, all in a secure manner, as applications are run in isolation without full system access. If you want to modify it, you click the "show source" button and hack away, again, the thing keeps track of your modifications and can undo them when needed.

Re:A silly question

[macs4all]

Well and good until somebody hacks a floppy drive to bypass it.

You don't understand hardware so good, do you?

The W/P switch in old floppy drives wasn't a "request not to write"; it actually disabled the HARDWARE enable input to the WRITE CURRENT driver in the R/W head. The only way it could fail was if the microswitch that read the "tab" (or the optical sensor in the 3.5 inch version) failed; or, if you had an Apple ][ disk drive, if static zapped the 74LS125 on the 5.25 Shugart drive's board (a somewhat common, VERY nasty problem, which resulted in the write/erase current being turned on PERMANENTLY!).

No amount of SOFTWARE could defeat the HARDWARE W/P switch. And if you are talking about a USER "hacking" their OWN drive to defeat that (a common mod was to install a switch on the front of the drive to provide "no-tab" Normal, Protect Always, and No Protect operation), then that particular user has done so with the understanding that they have VOLUNTARILY placed themselves at greater risk. Different situation completely than with a "Please Write Protect Me" SOFTWARE scheme, as with the USB sticks.

On a related note, I can't understand why someone can't actually provide HARDWARE write protect on a USB stick, unless the integration has gotten so high that the controller and memory are actually within the same IC package (and if the designer of that chip wanted it, they could STILL bring a HARDWARE enable out to the world, not just a port pin read by the controller).

Re:A silly question

[macs4all]

I did that because when I worked in repair I needed working copies (they get damaged) that would not lose the tape. You can buy disks without the notch so there is no protect to fall off. To prevent accidents, the switch I put in the drive was a reed switch. It required knowledge of the switch as well as the pocket screwdriver with the magnet in the end to turn on the hidden write switch while writing another working copy of the diagnostic floppy disks.

None of the floppies in the field service kit had a write enable notch. It makes no sense taking one customer's infection and giving it to someone else. The modern replacement is a burned DVD instead of a thumb drive. Use read only media for any of your service materials. No exceptions.

Yeah, the 8 inch floppies actually got it right. They had a Write ENABLE sticker. If the Notch was NOT covered over, then the disk was automatically Write Protected. The rationale was that a sticker can NEVER "fall ON". I would imagine that whatever evil engineer inverted that logic did it because he was either pressured to, or was tired to digging around to find write-enable stickers...

Re:A silly question

[Penguinisto]

Dude - he was probably referring to the OS, not the apps.

Uncle (below) answered it adequately - that the OS would reboot with a 'pristine' state - including the same flaws it had before. While this would frustrate some forms of trojan or malware, it certainly wouldn't even begin to stop it all.

You can do something similar with virtual machinery, but the pristine VM could get corrupted too... becomes a chicken/egg question if the user isn't too awful computer-savvy.

Now someone with some sysadmin mojo could use it to good effect (oh? that website infected my VM? Well, time to clone off another from the virgin copy, test it out to be sure, and just avoid that site - maybe notify the site owner...) But normal users? Nuh-uh. They'll just get re-infected again 6 or 7 times out of ten.

Worthless Summary

[OverlordQ]

A new version of the venerable Alureon malware has appeared, and this one includes some odd behavior designed to prevent analysis and detection by antimalware systems. However, this isn't the typical evasion algorithm, as it uses some unusual encryption and decryption routines to make life much more difficult for analysts and users whose machines have been infected. Alureon is a well-known and oft-researched malware family that has some rootkit-like capabilities in some of its variations. The newest version of the malware exhibits some behavior that researchers haven't seen before and which make it more problematic for antimalware software to detect it and for experts to break down its components.

A new version of well-known Alureon is out which has odd things to make it hard to analyze. It's odd, and is not normal and makes it's hard to analyze. It's well known and is a rootkit.The new version is odd and makes it hard to analyze.

We got that after the first sentence, how about actually providing some fscking detail.

Re:Worthless Summary

[zill]

A new version of the malware contains new features? Does the president know about this yet?

Re:Worthless Summary

[equex]

Yes, and he said
shut..

down...

EVERYTHING

Re:Worthless Summary

[Anonymous Coward]

Tautology makes things true. You didn't know tautology makes things true? Well, it's true; tautology makes things true.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Make up your mind

[ledow]

Summary says: "The newest version of the malware exhibits some behavior that researchers haven't seen before"

The article says: "In 1999, a new virus, Win32/Crypto, was discovered... Today, in 2011, variants of Win32/Alureon are bringing this old-school technique back to life... Another interesting tidbit is that an initial version of this obfuscator first arrived in our lab in the first half of 2009."

That's kinda stretching the definition of "haven't seen before", which may be true in a technical sense (because they haven't seen THIS EXACT MALWARE before, but they've certainly seen lots like it).

Don't worry, Microsoft is on it

[digitaldc]

"We're closely monitoring Alureon to ensure that our users are always protected. In fact, Alureon has been part of the Microsoft Malicious Software Removal Tool (MSRT) since April 2007."

I am putting my full faith and hope in to the Microsoft security team to eliminate it with their latest Malicious Software Removal tool.
I have given up on being paranoid about viruses, and I am much happier now!

Not really.

[Viewsonic]

Only for major major updates, and it wasn't a pain in the ass. You unplugged the chip and stuck the new one in. Back then it was pretty common for users to hack their Amigas anyways, so it wasn't that big of a deal to open her up and swap it in. The pain the ass was expanding the chip memory by soldering lines to a new socket. I was 12 when I had to do this for my Amiga 500. Worked fine.

Re:Not really.

[Tx]

Kickstart was more of a BIOS-equivalent than an OS. You couldn't do anything with Kickstart by itself, kickstart booted the actual OS (Workbench). Some RiscOS machines OTOH did boot a reasonably advanced GUI OS from ROM, in fact if I'm not mistaken there are some such still in production.

Re:Not really.

[equex]

I had a couple of RiscOS fanatics for friends (i was in the commodore camp), and afaik they had a 2MB ROM to boot from, which included memory protected processes ('modules') and a configurable desktop environment, a taskbar/taskmanager hybrid as well as an assembler/BASIC editor/assembler and some other tools. Also grandparent must be trolling, since those OS'es was so incredibly small and uncomplicated that it should in fact be possible to write them with zero bugs whatsoever.

Re:Not really.

[obarthelemy]

I'll bite

1- above all, there was a lot less of it. Win7 is rumored to be about 50 million lines of code. I can't find the C64's rom size, but it's at least 2 orders of magnitude less.
2- there were no security issues requiring frequent updates. the C64 was not connected to the internet, and the basic OS was in ROM, so any security holes remained un-exploited
3- nobody cared about bugs, especially since the OS did so little anyway. I never had the money for a C64, but my ZX Spectrum had plenty of bugs.
4- I remember very well that the C64 sorely needed un OS update to its floppy disc functions :-p

Re:Or rather

[datapharmer]

Bios, SMM. See Abstracts: http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=publication&name=Persistent_BIOS_Infection http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.153.9106&rep=rep1&type=pdf (warning, pdf!)

Re:Why whitelist it at all?

[maxwell demon]

The problem with this is that DRM software is also intentionally hard to analyse. And for a commercial OS vendor it's not a good idea to disallow DRM on installed software.

Re:Seal Team 6

[AlecC]

You think this is saddos in their Mom's basement? Hacked machines and botnets are big business nowadays. This is the "Russian Mafia" or equivalent, paying big money for infected machines,

A signature by any name would identify as such.

[VortexCortex]

So, the malware has executable payload chunks that are encrypted and spread around (locations obscured) that must be decrypted prior to execution of said payload.

I get that this makes it a little bit harder to figure out what the program is about to do (hint: allow it to decode, breakpoint & step), but isn't the point to simply identify that the malware is present? Unless the malware is capable of executing encrypted code on the chip, the code that decrypts the remaining payload code must be stored in plain machine code.

The machine code that initiates the brute force will be identifiable, and a signature can be made. Nothing to see here folks. The shitty encryption system doesn't even use asymmetric keys, and the very fact that it only takes 255 tries for it to brute-force one of its "chunks" is laughable. I mean -- I wrote better cipher systems when I was 12... Are they trying to avoid breaching US encryption export laws?!

Who cares how good it is at hiding its payload if the code that decodes the payload has a fingerprint...

P.S. What really scares the shit out of me is new processor tech that enables public key crypto at the machine instruction level. Not only will the "good" guys use it to "protect" their code from their user's prying eyes, the malware writers will use this to actually design code that has no fingerprints. Each copy will be indistinguishable from pseudo random noise -- So much for "signatures" at that point.

P.P.S. Once you know malware has executed on the system, it's time for a full wipe, BIOS re-flash, and OS re-install -- There is no "removing" malware.