Slashdot Mirror
Java Web Attack Installs Malware In RAM
snydeq writes "A hard-to-detect piece of malware that doesn't create any files on the affected systems was dropped onto the computers of visitors to popular news sites in Russia in a drive-by download attack, according to Kaspersky Lab. 'What's interesting about this particular attack is the type of malware that was installed in cases of successful exploitation: one that only lives in the computer's memory. ... It's ideal to stop the infection in its early stages, because once this type of "fileless" malware gets loaded into memory and attaches itself to a trusted process, it's much harder to detect by antivirus programs.'"
If this malware resides exclusively in RAM without any footprint on the HDD or BIOS, then how does it survive a cold boot?
It doesn't have to. It contacts the C&C server where someone presumably decides whether to install further bots or more resident exploits.
The exploit seems to be more about stealth distribution and about dropping other malware. This makes sense because if a dropper is detected as malicious, it becomes useless due to its detection. (You can safely assume anything using a dropper is malicious)
This means that anti virus software should in theory only be able to detect the actual dropped malware. Any new malware could have had a field day with this exploit because both the dropper and malware would not have been detected.
From my understanding of the article it actually dropped the Lurk trojan but I get the feeling it could drop anything the C&C wants it to.
Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,
But how would it do that? Isn't Java sandboxed? Or is it only sandboxed on more recent operating systems (Win7 & OS X 10.7)?
"We can categorically state we have not released man-eating badgers into the area." - UK military spokesman, July 2007
In this case it's more general, you have to press the reset button which is the most frequent solution to any computer problem on any platform.
After reading a bit on the referenced exploit((CVE-2011-3544) I find it hard to believe that the app was all in memory. The exploit involves and unsigned applet gaining higher privileges. Things may have changed since the last time I checked, but shouldn't the jar file for the applet that copied the DLL into memory be the new file sitting the the browser cache that you're looking for? The DLL could retroactively delete the trace but at some point the jar is what the anti-virus should be looking for since it has to be loaded before the DLL can be.
That's how you solve all problems in Winders, right?
CTRL+SHIFT+ESCAPE is infinitely superior.
...all I need to do is reboot?
These are fairly common, actually.
Well, at least in the first steps of the malware - load a payload into memory that disables antivirus. Then you do the filesystem changes after the antivirus can no longer stop you.
Thus why antivirus isn't nearly as important as due diligence in using your computer. This means browsing without all of the fancy addons, generally. Or, at least, if you must have them, keep them up to date.
Oh, if only that weren't true.
My wife does enterprise storage, used to do backups ... occasionally a server gets out of whack, and has all sorts of problems. Eventually she or someone on her team ends up saying "can we just reboot it?". This is usually after several days of troubleshooting and huge amounts of time spent.
It fixes a vast amount of issue in which nobody can identify what's going wrong. Though, it makes any proper form of root-cause impossible to track down. I've heard this referred to as "The Microsoft Patch".
I also know some old-school UNIX admins and mainframe guys who cringe at the notion that a reboot can be a viable way of troubleshooting/making the problem go away. Because they don't reboot unless God himself has filled out all of the right paperwork, and only then if he's got a really good reason and there are no alternatives.
Lost at C:>. Found at C.
Every antivirus product I've used claims to scan memory for viruses (usually as the first step of a full scan). If it's not looking for these RAM based viruses, then what is it looking for?
That makes a whole lot of sense. If your system isn't opaque like Windows, you can dig down to the root cause of a problem and ascertain that it will actually be gone after a reboot or whatever fix is needed. Otherwise chances are that it'll come back.
That's what I do on my own Linux boxes too. As soon as I find the time I want to switch from Debian to Gentoo to have even more of that capability.
thegodmovie.com - watch it
Ever since those fucking banner ads starting using Java exploits to do redirects and run fake malware scans, I've kept Java off except for the incredibly rare occasion.
It doesn't mean much now, it's built for the future.
Sounds like we need to write a GUI in VB6 to get rid of it...
Forget your ctrl+shift+esc and go for the real killer, windows+r+format C:+enter
WTF Slashdot, why do I have to login 50 times to post?
Where's the format button?
Java, not Java-script. Also it looks like Java is just the front for the payload.... The article says it uses a DLL, so you non-windows people are probably safe.
An antivirus company sends two messages: 1) Stay in RAM and be undetected; 2) Attach to a trustworthy process and they'll miss you. I wonder what are they not telling us?
Remember Commodore 64? Its boot record was kept separate from the OS. So no matter what you did when you mucked around, you could boot again. Microsoft should provide two modes: A) "Wreckless Compatibility Mode" -This is for legacy issues and B) "Secure OS mode", where no one can write to the boot sector or start up, and you enter a special boot mode for cases of drivers.
I think by making it impossible to write over the OS, or alter OS files, then when you boot you shouldn't worry of a virus hosing your boot. Sure, a virus could write over all your program files and screw with your data, but I think the OS itself should never be at risk. Someone else can figure out how to make program files secure. Maybe they could say things can't escape out of their parent install directory.
Am I naive to think this sort of thing should be possible?
God spoke to me
I also know some old-school UNIX admins and mainframe guys who cringe at the notion that a reboot can be a viable way of troubleshooting/making the problem go away.
One way you can find out what the problem is and prevent it from happening again. The other way you just pour gasoline on it, throw a couple matches in and hope that whatever caused the problem isn't fireproof.
Doing the magic dance, pressing the red button and hoping that everything gets better on its own isn't that different from Cargo Cult science or faith-based economic policy. It shouldn't be that hard to see why people who are supposed to know better don't like it.
How does Gentoo provide more of that capability than Debian? Even if you need to change the source, it's not like running an "apt-get source" and then a "dpkg-buildpackage" is a difficult process.
(This isn't a dig on Gentoo, which is obviously a great distro)
Dilbert RSS feed
CTRL+AmigaLeft+AmigaRight is more superior.
(Unless you get a Guru Meditation error.)
My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
Oh, I know why people don't like it, and certainly people don't like taking production outages for a mystery reboot.
But if you have spent a week on the phone with the vendor, involved several teams to trouble shoot, spent countless hours trying to identify the problem, and gotten nowhere ... If the reboot fixes the problem and it never comes back (which I have seen), then sometimes you have no better options.
The vendor just asks for logs. Nothing anywhere ever actually shows the source. And all you do is lose a lot of time to it.
I absolutely hate it, but there have been times when everyone just throws up their hands and says "bugger it, try rebooting".
Lost at C:>. Found at C.
The idea of loading malware into memory and not placing it in file is hardly new. In fact, the idea goes back over 20 years.
Back in the dark ages of networking, one of the earliest deliberately malicious worms was WANK (Worms Against Nuclear Killers) which was unleashed back in October of 1989. It was a VMS based worm that attacked via DECnet (no laughter...DECnet was more popular than IP at one time.)
WANK attacked systems on the old NASA SPAN (Space Physics Analysis Network) and the DOE HEPnet (High-Energy Pysics Network). It was quite effective in not writing into a file and both notified C&C of the successful attack and then launched attacks on other systems. If the authors, widely believed to be Australian environmentalists, had a very inventive way of downloading and bootstrapping into memory, but then made some dumb coding errors that greatly limited the damage and spread of the worm. The story of WANK is recounted in "The Underground" by Suzanne Dreyfus. and the worm itself is discussed in this article. Having contributed to the book and having done the first analysis of the worm in parallel with analyses by Ron Tencati and John McMahon of NASA, I believe that the information is correct. (That Julian Assange guy does get around, doesn't he.)
As the article points out this is a known vulnerability. And there has been a patch available since October 2011.
http://www.oracle.com/technetwork/topics/security/javacpuoct2011-443431.html
The infoworld article mentions that the applet used a "rogue" DLL. Where did that come from? If it didn't install any files on the system, why is there a "rogue" DLL on the system? Did it just "install" that DLL into memory also? And if the malicious applet code managed to get escalated privileges, why didn't it install something on the drive? And isn’t the term “install” being misused in the article? In fact, isn’t it true Mr. Infoworld Article person, that the alleged malware was merely “loaded” into memory? The truth is there was no flight leaving Guantanamo Bay, you doctored the flight logs, you ordered the code red, you framed OJ Simpson
FAQs are evil.
UEFI Secure Boot.
This is not a virus, but it does use a command and control server.
It's not old-school to avoid rebooting unix machines that have a fault but are still accessible, particularly remotely.
I've seen a number of instances, from people trying to email files that were bigger than the total RAM on the machine, to secondary drives that were dying, all of which would cause the machine to fail to come back up but could be corrected while it was still on and save hours of work and possibly a trip to the site.
Rebooting a windows server though, yeah, that's stage 1 troubleshooting....
Linux users have [access to] the sources of all or at least most of what they're running. Old school UNIX users used to as well, until IBM, HP & co made their Unixes proprietary.
thegodmovie.com - watch it
I agree but Gentoo kind of forces me to use the source and it seems that some of the system management is simpler and more obvious.
thegodmovie.com - watch it
UEFI isn't going to protect the operating system from being modified, it's going to prevent the computer from booting if said operating system if it gets modified, which is pretty much exactly the opposite of what we wanted.
They may be old hat, but an exploit that mentions "Java" suits Microsoft's purposes just fine (since it is trying to kill cross-platform Java and promote Windows-only .NET). Strange it made the news half a year after a patch has been available - what were the editors thinking? Wouldn't the article's title be more accurate if it was "Unpatched systems get malware in RAM"?
This requires there to be no code that loads before the code that locks down the OS. UEFI Secure Boot is part way there, but there's still the option to write to keyboard/video memory and persist across a reboot, then automatically enter an insecure mode, install the rogue bootloader, and then load the expected OS on top, applying the appropriate secure patches as if the software was an external user.
As long as we've got buggy code, input devices and device drivers, there will be ways of shoehorning a bootkit onto a piece of hardware.
Of course, considering how doing this is orders of magnitude harder in effort spent than just fooling the operator into letting the software run, it will continue to mostly be done for industrial espionage/targeted reasons, not for adding home users to an uberbotnet.
As elsewhere, is it now slashdot policy to only mention '`computer` malware ..
"After seizing all necessary privileges on the victim computer, the exploit does not install malware on the hard drive using Java. Instead, it uses its payload to inject an encrypted dll from the web directly into the memory of the" javaw.exe process
AccountKiller
OK. The usual question. Does this run on Linux? (or Mac)?
It mentions a DLL which is Windows only so I assume Windows only?
I don't read your sig. Why are you reading mine?
Old school VM and MVS system programmers also had the source (in 370 assembler) available and they indeed used it.
But the malware already ran "touch -t 0101011337 ./malware.exe", so maybe you won't spot it with this.
yeah, have fun with win8 arm.
"what? I can't install a virtual cd device that'll look exactly like a real cdrom drive?"
(anyways, the files.. if they can't be altered, then ms can't hot update them either)
world was created 5 seconds before this post as it is.
Aren't they doing that with Windows 8, and getting slapped around by all the linux guys over it by saying "OMG they're locking us out of our own hardwarez by requiring the secure EFI bootz!"
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Except that you can repair it from the UEFI shell, or a UEFI binary written to replace the infected file with a clean one on the installation media / over the wire.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Window's really what the problem is here.
Why do we still use this shit?
But if you have spent a week on the phone with the vendor, involved several teams to trouble shoot, spent countless hours trying to identify the problem, and gotten nowhere ..
Yeah we had to reboot cisco core switches before. Initially we thought it was a firewall problem (was an active-active firewall cluster - which usually means it's more likely to be the culprit ;) ). But after spending a few nights in a freezing datacenter trying to figure out why it wasn't working, the decision was to reboot both the clustered switches (which took _everything_ down) and stuff started working again.
We were the support vendor for the firewall but not the switches. So we had to make sure it was not our problem and wait for the relevant parties to do it.
Linux, Solaris, Windows, Cisco. Sometimes you just have to reboot. Just make sure your cisco configs (running and saved) are backed up first though ;).
I also know some old-school UNIX admins and mainframe guys who cringe at the notion that a reboot can be a viable way of troubleshooting/making the problem go away. Because they don't reboot unless God himself has filled out all of the right paperwork, and only then if he's got a really good reason and there are no alternatives.
I've seen issues where rebooting a Linux machine actually causes more problems than it solves.
As long as the kernel is still running nearly every other software issue on a Unix/Linux system can be fixed. And a few firmware/hardware issues, too.
Of course, considering how doing this is orders of magnitude harder in effort spent than just fooling the operator into letting the software run, it will continue to mostly be done for industrial espionage/targeted reasons, not for adding home users to an uberbotnet.
The interesting fact about software is that it only needs to be written once.
If corporations are people, aren't stockholders guilty of slavery?
The Atari 1040ST had its operating system on eproms, I have yet to see a computer virus that came eiqipped to erase and reprogram an eprom, it takes UV light to erase one! eeproms on the other hand are vulnerable to exploits! Of course TOS was quite small compared to modern OSes!
Interesting - I didn't know that bash worked that way. Contrary to C and PHP. But I usually use the == anyway.
The interesting fact about software is that it only needs to be written once.
Indeed... the continuing prevalence of Conficker shows us that. But what we're talking about here is targeted attacks using both exploits and social engineering. If I received an email containing a PDF claiming to contain the auditor's edits of Oracle's 2011 tax statement, for example, I'd probably suspect something fishy was going on. Plus, the rootkit likely wouldn't run on my computer, and the database it is attempting to gain access to sure isn't on my subnet.
The other interesting fact about software is that it only does what you tell it to.
The orders of magnitude of difficulty are to do with fooling the operator and exploiting the environment, not to do with writing the software.