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.'"
A: "Volume!"
"Flyin' in just a sweet place,
Never been known to fail..."
"This type of malware is rare, because it dies when the system is rebooted and the memory is cleared.
However, this wasn't a problem for the cybercriminals behind this particular attack, because of the very high probability that most victims would revisit the infected news websites, Golovanov said."
From the linked article.
Oh noe! Programs have invaded my RAM!
I'm doomed! Time to call geek squad and have them reformat Windows!
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,
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.
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
In Soviet Russia, Java runs YOU!
Let's call it what it is, Anti-Social Media.
It is sandboxed as long as there is no bug to be exploited. And since there is no bug free software more complex than a "Hello, world!" program...
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.
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
Oh noe! Programs have invaded my RAM!
I'm doomed! Time to call geek squad and have them reformat Windows!
Have them install Linux. It's so awesome and secure it doesn't need RAM.
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
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.
It's so awesome and secure it doesn't need RAM.
O rly? I agree, it needs very little. I have a Debian appliance with 32 megs of RAM, and a Unix server with 128 megs.
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.