Slashdot Mirror
IE Zero-Day Exploit Disappears On Reboot
nk497 writes "Criminals are taking advantage of unpatched holes in Internet Explorer to launch 'diskless' attacks on PCs visiting malicious sites. Security company FireEye uncovered the zero-day flaw on at least one breached U.S. site, describing the exploit as a 'classic drive-by download attack'. But FireEye also noted the malware doesn't write to disk and disappears on reboot — provided it hasn't already taken over your PC — making it trickier to detect, though easier to purge. '[This is] a technique not typically used by advanced persistent threat (APT) actors,' the company said. 'This technique will further complicate network defenders' ability to triage compromised systems, using traditional forensics methods.'"
APT is the new buzzword in IT security, like Web 2.0 for web developers or Cloud for the server guys. APT means bad guys of moderate sophistication all the way to government agencies, so everyone but script kiddies running standard exploit kits.
Seems kinda silly for Debian to have a command to intentionally go out and get those things...
Definitely security buzzword bingo:
... diskless attack ... APT ... actor ... network defender ... triage ...
We get it, dude, you find buffer overflows and stuff. You're not a surgeon.
Why? It's a very apt term.
Another Windows problem that can be fixed by having the user restart his or her computer!
Disappears on reboot is a limitation, not a feature. If you get root you could always remove payload, if it disappears on its own then it is likely limitation of specific sandbox bypass method. If I had to guess, Zero-Day is related to ElevationPolicy fix for CVE-2013-3186.
It's because it's being used in the context of a simple XOR-based encryption scheme -- very common in malware, actually.
If all you wanted was the data on the end users disk; e.g. credit card numbers, logins, cookies, email passwords, etc; then this is a desirable feature as it makes it much harder for an individual defending systems to get a copy of the code and exploit.
Additionally, if the worm or virus agent is polymorphic in nature, then this assists in avoiding detection by antivirus scans. Remember, those scans slow down end user machines, many companies only do them once a week. By the time the antivirus company updates their heuristics algorithm your code is commited to cybernetic oblivion.
Two broad approaches exist.
Firstly, the rootkit: 'implant' an agent (monolithic or multipartite) which stays as persistent as possible, maintaining control of the system. The most extreme case I've seen writes new firmware to the NIC, which is loaded by the BIOS or UEFI code; this alters the CPU microcode slightly to change TLB handling and then chains a hypervisor into the boot process which is (thanks to the TLB update) hard to detect, and a major barnacle to get rid of - the payloads dropped by the hypervisor's code injections are nowhere near as ninja but somehow keep coming back. (Now you know one more place to look and the general class of attacks if you didn't notice before.)
Alternatively, the CRIT (Covert Remote Intrusion Tool): a non-persistent agent which runs a stealthy process, and when it's done, unloads itself from RAM. Notably, CRITs are never truly reset-proof: this is a conscious design decision. An ideal CRIT leaves absolutely no forensic trace on disk or RAM of the target machine after it disappears (although traces of the vector of infection might need to be cleaned up, and there's always the possibility of server logs from something else - if anyone even knows to look at it). The real world, of course, is rarely so elegant, as anyone who remembers how TSRs weren't always quite so trouble-free.
It is a difference in intent, signalled via design. One prioritises maintaining control above stealth; the other prioritises maintaining stealth above control.
It is telling that the NSA and GCHQ attacks found in the wild so far or described in leaked documents have all been rootkits and never CRITs. Of course, that may be because CRITs simply weren't written of, weren't leaked yet, or were more unlikely to be discovered, but it seems more likely that this is a wide, strategic decision: maintaining control of an asset as long as is possible, even if its cover is blown.
It is very hard to conceive of effective countermeasures - it is, as I unfortunately predicted a little over 15 years ago when I first publicly described such a possibility, likely to become (and now remain) an arms race, between state actors (who, it seems, always wear the black hats), and between non-state actors (black-hats and white-hats alike). In truth, all such agents are terribly dangerous, particularly those with autonomous spreading capabilities, or merely capricious greedy idiots at the keyboard. Perhaps they should be regulated via treaty, like the biological weapons their action resembles: that is an act for politicians and those who lie with a smile on their face. Perhaps we, as engineers, should concentrate on fixing the bugs the vectors exploit; but alas, I fear that may be like trying to sail a giant colander across the Pacific armed only with tape.
I have grave concerns about the direction this whole mess is headed. They have taken what may be the greatest achievement of humankind, and threaten it more than any terrorist ever could, because terrorists don't have a billion dollar budget and a whole world's trust to undermine. We can but try, and do what we can, to fix such damage, and route around it, wherever we find it and whomever perpetrates it for whatever reason - it is all, simply, a bug, at its heart, and bugs need fixing. Perhaps we can build protocols, and software, far more resilient at their core; but until they are ready, please at least let me have my cat pictures and my tea and my discourse and my computer games, lest I become mad as hell and cannot take it anymore. I grow weary. And quietly bitter.
I've actually seen a team that worked that way, no magic needed: they just had good auto-formatting tools. Everything was canonicalized on check-in and auto-formatted however you wanted on check-out. Each dev worked with his own favorite style, and just had to tolerate the canonical style for looking at diffs (I just realized that one of the team went on to be a VP I think at Canonical, by a strange coincidence).
Socialism: a lie told by totalitarians and believed by fools.
Disappears on reboot is a limitation, not a feature
The most sophisticated malware in modern times, Stuxnet, had a built in self-destruct. How is it that a feature that disappears after a certain number of days a feature, but after a reboot not a feature?
If you get root you could always remove payload, if it disappears on its own then it is likely limitation of specific sandbox bypass method.
Small comfort to those who enter their credit card data and then wake up to $-300 dollars, two weeks to pay day, rent due, and not enough gas or food to last. People need to stop being so puritanical about exploits... "Oh, it disappears after reboot, big deal!" ... If it manages to do damage, it doesn't matter.
#fuckbeta #iamslashdot #dicemustdie
This PDF is much more informative than the summary or TFA. I got interested, and followed links, stumbling over this along the way.
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/hidden_lynx.pdf
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br