Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Java Security IT

Java Web Attack Installs Malware In RAM 98

Posted by Soulskill from the movin'-on-up dept.
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.'"
This discussion has been archived. No new comments can be posted.

Java Web Attack Installs Malware In RAM More

Java Web Attack Installs Malware In RAM

Comments Filter:

  • Persistence? (Score:2, Redundant)

    by JDG1980 ( 2438906 )
    If this malware resides exclusively in RAM without any footprint on the HDD or BIOS, then how does it survive a cold boot?

    • Re: (Score:3, Funny)

      by Jeremiah Cornelius ( 137 )

      A: "Volume!"

    • Re: (Score:3, Informative)

      by Anonymous Coward

      "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.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      Oh noe! Programs have invaded my RAM!

      I'm doomed! Time to call geek squad and have them reformat Windows!

      • Re: (Score:2, Funny)

        by Anonymous Coward

        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.

        • Re: (Score:3)

          by mcavic ( 2007672 )

          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.

    • It doesn't (Score:5, Informative)

      by improfane ( 855034 ) * on Monday March 19, 2012 @03:01PM (#39406757) Journal

      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.

    • Wouldn't necessarily need to, if it's an infostealer type malware. It's already gotten what it needs to, doesn't matter if it gets rebooted - your passwords belong to the guy on the other end already.

    • If this malware resides exclusively in RAM without any footprint on the HDD or BIOS, then how does it survive a cold boot?

      I didn't RTFA, so feel free to heckle me at whim:

      1. How often do cold reboots really happen these days?

      2. If Slashdot, for example, was a site that used this exploit, well there ya go.

      • 1. How often do cold reboots really happen these days?

        Every night for most home users. It's mainly geeks who leave their computers on 24/7 you know.

        • I'd have to disagree, from what I've seen. Neighbors, family, friends, and most end users at work typically are scared to death of the OS, and the less they have to do to it (such as rebooting), from their perspective, the better. Half the issues they bug with me could be solved by a reboot but it doesn't occur to them -or, they're wary of doing it.

        • Do you have a statistic on that? My own experience paints a different picture.

        • > Every night for most home users. It's mainly geeks
          > who leave their computers on 24/7 you know.

          I probably qualify as a geek, but... here in Ontario, Canada, condo buildings have separate electric meters for each suite. So I have a financial incentive to hibernate my linux machine when not in use.

          And I haven't had Java on my linux machine for years. One less attack vector. Nothing is "unbreakeable" (I'm looking at you, Oracle), but not running Java sure helps. Ditto for replacing Acrobat with epdfvie

    • It hooks into a process say winlogon.exe when a shutdown event passes through it writes itself to disk before the computer is shutdown and adds what it needs to the registry to start back up and remove itself save the memory resident portion. On startup it gets reexecuted and put back into memory.

      Why this is news is a wonder, other than it being Java. We've seen it before, think SmitFraud.
    • Comment removed based on user account deletion
    • FTA: "In some cases, the instructions given out by attackers were to install an online banking Trojan horse on the compromised computers."

    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)?

    • It is sandboxed. If there was a DLL loaded there is a flaw in the sandbox, somebody got this code signed by a trusted certificate, or the user clicked "Run".

    • 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...

      • I see you forgot to free your character array containing "Hello World". Oh wait we're talking about Java, well I see you are running on this ultra complex virtual machine thingy. :D

  • All in memory? (Score:5, Interesting)

    by medv4380 ( 1604309 ) on Monday March 19, 2012 @03:09PM (#39406837)
    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.

    • Could the jar pull the DLL remotely? If so, the only thing local that could be hunted for could be made to be innocuous, since pulling web resources is hardly an unusual process.

      • But the Jar is the exploit and that has to be downloaded for the JVM to load it. You won't find the DLL but that's not really the exploit. Any jar that is designed to get out of the sand box without being signed should be locked up by the AntiVirus as a code exploit.

        • Re: (Score:2)

          by dkf ( 304284 )

          But the Jar is the exploit and that has to be downloaded for the JVM to load it. You won't find the DLL but that's not really the exploit. Any jar that is designed to get out of the sand box without being signed should be locked up by the AntiVirus as a code exploit.

          Doesn't mean that the JAR has to hit disk. Java can load code out of memory just fine, though it has to go via the verifier on its journey from bytes to a loaded class. The problem comes when something messes up and gives code loaded from an untrusted source permission to do too much. Wasting CPU is irritating; turning into part of a botnet is much worse.

          • Unless the JVM has been changed to stream in jar's for applets and for web start I don't see how what you describe works. Applets and Web Start need an initial bit of code to start that is supposed to be downloaded and will reside in ether the browser cache for applets or the web start cache for jnlp files. From the exploits description [microsoft.com] that is exactly what happens. It downloads a jar runs it gets out of the sand box though a known exploit then it download the DLL into memory. The jar is the actual drop
    • I assume (without reading the article) that they literally wrote out an object that represented itself as a jar/dll like fetching a jar off the internet with wget (but instead of writing it to the HDD, they wrote it to the memory which is essentially how live cd's work for OS's). There's no reason why that wouldn't work in Java, it has a full io structure.
  • ...all I need to do is reboot?

  • Not too terribly novel. (Score:3)

    by willaien ( 2494962 ) on Monday March 19, 2012 @03:17PM (#39406901)

    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.

  • Then what does a memory scan do? (Score:3)

    by hawguy ( 1600213 ) on Monday March 19, 2012 @03:26PM (#39406975)

    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?

    • Re:Then what does a memory scan do? (Score:4, Interesting)

      by Baloroth ( 2370816 ) on Monday March 19, 2012 @03:39PM (#39407105)

      AV software can scan memory in order to find active malware, yes, but it cannot do so constantly. For example, in order to make sure that your browser isn't getting owned, or that malware isn't otherwise being attached to an active process, it would have to scan every change to memory, which would be prohibitive in terms of processing overhead. Instead, they generally scan whenever files are written to the hard drive. Since any permanent virus needs to do that at some point (and most malware works by downloading a file then executing that), that will usually catch and stop most malware at the very beginning. And since writing is comparatively slow (next to RAM), the overhead is minimal.

      What this seems to do is run exclusively in RAM, which can be caught by AV doing a RAM sweep, but not by most resident AV systems which don't do regular RAM sweeps (again, because of the performance impact that would cause). It will either have to download a permanent program to the harddrive later (ideally, after getting "trusted" status to bypass AV software) or simply steal info while resident. Either way, most AV software will have trouble detecting it. I think if the malware gets written to swap, the AV will detect it than, but I could be wrong.

      • I think if the malware gets written to swap, the AV will detect it than, but I could be wrong.

        This is the case for most major AV vendors, but depends upon HOW it is written to swap. If it is polymorphic shell code that is stored encrypted in memory, it probably won't trigger a swap scan. If it contains an easy to identify javascript exploit in plain text and is stored at the top of a swap segment or cache file, it will be detected. If you have encryption enabled for your swapfiles and cache files, no AV scanner will detect it.

  • Ugh, keep Java off! (Score:3)

    by Pope ( 17780 ) on Monday March 19, 2012 @03:33PM (#39407047)

    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.

  • Sounds like we need to write a GUI in VB6 to get rid of it...
  • 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?
    • UEFI Secure Boot [wikipedia.org].

      • Re: (Score:2, Informative)

        by Anonymous Coward

        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.

        • 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.

    • 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 boot

      • Re: (Score:2)

        by DavidTC ( 10147 )

        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.

        • 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

    • Re: (Score:2)

      by gl4ss ( 559668 )

      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)

    • 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!"

    • 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!

  • Memory-only worms are not new (Score:1)

    by Anonymous Coward

    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 (Hi

  • Oh no, Java scary! (Score:4, Informative)

    by dgun ( 1056422 ) on Monday March 19, 2012 @04:44PM (#39407591) Homepage
    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 [oracle.com]

    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
  • 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 [securelist.com]

  • OK. The usual question. Does this run on Linux? (or Mac)?
    It mentions a DLL which is Windows only so I assume Windows only?

Slashdot Top Deals

Avoid strange women and temporary variables.

Close