Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IE Zero-Day Exploit Disappears On Reboot

samzenpus posted about a year ago | from the poof-it's-gone dept.

Security 103

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

Sorry! There are no comments related to the filter you selected.

Advanced Persistant Threat (APT) (-1)

Anonymous Coward | about a year ago | (#45393459)

Did you just make that up to sound important?

Re:Advanced Persistant Threat (APT) (1)

dreamchaser (49529) | about a year ago | (#45393487)

The term has been used in the IT security industry for years.

Re:Advanced Persistant Threat (APT) (3, Funny)

Anonymous Coward | about a year ago | (#45393537)

Seems kinda silly for Debian to have a command to intentionally go out and get those things...

Re:Advanced Persistant Threat (APT) (5, Funny)

Anonymous Coward | about a year ago | (#45393581)

Why? It's a very apt term.

Re:Advanced Persistant Threat (APT) (1)

Anonymous Coward | about a year ago | (#45394103)

What the hell....you get a point and I don't? Damn you, Slashbots....damn you all to hell!

Re:Advanced Persistant Threat (APT) (1)

Gothmolly (148874) | about a year ago | (#45393711)

Just because a bunch of "security" dbags use a term doesn't make a thing.

Re:Advanced Persistant Threat (APT) (1, Offtopic)

lgw (121541) | about a year ago | (#45393751)

It's a polite way of saying "governments" because we used to pretend that out own government wouldn't be doing this to us, so "governments" seemed too broad.

Re:Advanced Persistant Threat (APT) (1)

dreamchaser (49529) | about a year ago | (#45394333)

I didn't say it did, I was just pointing out that it was not just made up.

Re:Advanced Persistant Threat (APT) (0)

Anonymous Coward | about a year ago | (#45395783)

Just because you say you are a Gothmolly doesn't make it a thing!

Re:Advanced Persistant Threat (APT) (0)

Anonymous Coward | about a year ago | (#45394411)

So it's a perfectly cromulent expression.

Re:Advanced Persistant Threat (APT) (1)

Behrooz Amoozad (2831361) | about a year ago | (#45394475)

Indeed, I've been using it for almost a decade now, A lot of my programs depend on it to install and update :)

Re:Advanced Persistant Threat (APT) (3, Informative)

sinij (911942) | about a year ago | (#45393511)

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.

Re:Advanced Persistant Threat (APT) (0)

Anonymous Coward | about a year ago | (#45393557)

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.

New buzzword? Unless you have been living under a rock the last few years, IT speaking, these are all rather old.

Re:Advanced Persistant Threat (APT) (0)

Anonymous Coward | about a year ago | (#45394073)

>Web 2.0 for web developers or Cloud for the server guys

That's the marketing guys. Any dev who says web 2.0 is... limited.

Once a guy asked if the website I was working on for him was Web 2.0 compatible....

Re:Advanced Persistant Threat (APT) (2)

Joining Yet Again (2992179) | about a year ago | (#45393565)

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.

Re:Advanced Persistant Threat (APT) (1)

dyingtolive (1393037) | about a year ago | (#45393573)

Sounds like their APT doesn't have super cow powers...

Re:Advanced Persistant Threat (APT) (1)

Joining Yet Again (2992179) | about a year ago | (#45393587)

It's still the Advanced Passenger Train to me.

Let the train take the strain.

Re:Advanced Persistant Threat (APT) (0)

Anonymous Coward | about a year ago | (#45393737)

APT = Always Puke on Tilt

Many people felt sick when the train tilted. According to a mate of mine who worked on it, they couldn't get the tilt damping right. Too little feedback in the control system apparently.

Re:Advanced Persistant Threat (APT) (1)

Joe_Dragon (2206452) | about a year ago | (#45394447)

MOO

Re:Advanced Persistant Threat (APT) (0)

Anonymous Coward | about a year ago | (#45393745)

We get it, dude, you find buffer overflows and stuff. You're not a surgeon.

But he did stay in a Holiday in last night.

Re:Advanced Persistant Threat (APT) (0)

Anonymous Coward | about a year ago | (#45393847)

Doh!!!

Holiday 'Inn' not 'Holiday in'

Good thing it wasn't written to disk....

Re:Advanced Persistant Threat (APT) (0)

Anonymous Coward | about a year ago | (#45398109)

APT was made up to make low-level background brute force attacks seem more impressive when a certain security vendor was caught with their pants down and lost their token seed data.

Shout out to our veterans on Vday (-1)

Anonymous Coward | about a year ago | (#45393463)

Oorah bitches.

Mother Green still kicking ass and taking names, keeping the World free. You can thank us today.

Re:Shout out to our veterans on Vday (0)

Joining Yet Again (2992179) | about a year ago | (#45393583)

"us"

AC is a veteran? Core Wars excepted.

Re:Shout out to our veterans on Vday (1)

NatasRevol (731260) | about a year ago | (#45394109)

Why do *we* need to keep the *world* free?

Re:Shout out to our veterans on Vday (0)

Anonymous Coward | about a year ago | (#45395803)

Because we'd be down to less than 4 races by now if we hadn't?

Re:Shout out to our veterans on Vday (1)

NatasRevol (731260) | about a year ago | (#45400437)

LOL, no.

Meh. (0)

Anonymous Coward | about a year ago | (#45393541)

Spying is boring.
When's the next SQL Slammer?

Yay! (5, Funny)

jargonburn (1950578) | about a year ago | (#45393589)

Another Windows problem that can be fixed by having the user restart his or her computer!

Re:Yay! (1)

Joining Yet Again (2992179) | about a year ago | (#45393603)

Works for me, but then Windows isn't the default grub entry.

(I kid - XP is actually all right. Which explains why Microsoft are getting rid of it in a few months.)

Re:Yay! (1, Insightful)

Jeff Flanagan (2981883) | about a year ago | (#45393821)

XP is very much inferior to Windows 7 or 8. A single process can stall out every application on an XP machine. Under Windows 7 or 8, and probably even Vista, the same process is forced to share the CPU so the machine is still usable.

Re:Yay! (0)

Joining Yet Again (2992179) | about a year ago | (#45393849)

Could you explain this scheduling issue more precisely, please. What common insoluble problem justifies the "very much inferior" label?

Re:Yay! (0)

g0bshiTe (596213) | about a year ago | (#45394017)

I'd say the biggest boost was Session 0 isolation.

Then they took a crap and revisited the Windows 2k days by creating the turd that is Windows 8.

If I wanted my desktop to act like a phone with the phone widgets I'd have used a fucking phone for my desktop, thanks.

Re:Yay! (0)

jarfil (1341877) | about a year ago | (#45397505)

Oh, stop the BS already. You don't have to use Metro if you don't want to (I don't).

Actually, something broke in my "Modern UI" apps while upgrading to Windows 8.1, and I didn't even bother looking to fix it. Still using Windows as usual.

Re:Yay! (-1)

Anonymous Coward | about a year ago | (#45398523)

Oh, stop the BS already. You don't have to use Metro if you don't want to (I don't).

Really? Explain how.

You are not allowed to refer to installing 3rd party software. Explain how to disable Metro without Internet access or external storage holding modification programs, I'll wait.

Remember to explain how to move all the stuff in Metro's Settings App to the desktop control panel as well.

Re:Yay! (0)

TGoss (3006907) | about a year ago | (#45399269)

Oh, stop the BS already. You don't have to use Metro if you don't want to (I don't).

Really? Explain how.

You are not allowed to refer to installing 3rd party software. Explain how to disable Metro without Internet access or external storage holding modification programs, I'll wait.

Remember to explain how to move all the stuff in Metro's Settings App to the desktop control panel as well.

format c:

Re:Yay! (0)

jarfil (1341877) | about a year ago | (#45397479)

In Windows XP, display drivers run in kernel mode. Any failure, means a system-wide crash at best, or a hang up at worst. There is no way to schedule/preempt driver execution before it finishes.

Since Windows Vista, display drivers get split up, with a minimal piece running in kernel mode, and most of the driver running in user mode. Most failures just need a restart of the user mode part. The user mode part can be scheduled/preempted at any time, kernel mode part only blocks for a single DMA buffer.

Since Windows 8, display drivers can be preempted up to a single instruction level.

Saying that Windows XP is "very much inferior", seems to me like quite a polite way to put it.

Re:Yay! (0)

Joining Yet Again (2992179) | about a year ago | (#45398773)

Yeah, Windows 3.51 was better than XP in this respect.

Not being able to write a non-crashing display driver is the real issue, though.

Re:Yay! (0)

Anonymous Coward | about a year ago | (#45393923)

Unless you explicitly spawn enough threads to cover all CPU cores with realtime priority. No.

Re:Yay! (1)

g0bshiTe (596213) | about a year ago | (#45393995)

Yet Windows 7 or 8 are still as crap as XP, when a 15 year old XP flaw is still found on those boxes.

Re:Yay! (1)

TGoss (3006907) | about a year ago | (#45399271)

Yet Windows 7 or 8 are still as crap as XP, when a 15 year old XP flaw is still found on those boxes.

That's actually a side-effect of the NSA spyware code. It's not a bug. It's a feature!

Re:Yay! (2)

TangoMargarine (1617195) | about a year ago | (#45395127)

Why don't you tell that to my Windows 7 install when some horrible abomination in the background on a page somewhere stalls out not only Firefox but the entire PC.

Oh, and what site, you say? *Facebook.* Hangs with the OS completely unresponsive for an entire minute or more. And this is with NoScript, too.

Re:Yay! (1)

mlts (1038732) | about a year ago | (#45395331)

So far, I've tried various operating systems for a VM for Web browsing. Believe it or not, XP is the best. If FB stalls or the VM has issues, a quick rollback to a known good snapshot (one that hasn't touched the Net except for updates.) It performs well in 512 MB of RAM for most Web browsing. That way, if FB decides to hang, you are just a few minutes (less if you snapshot the VM while it is on and suspended.)

Re:Yay! (1)

TangoMargarine (1617195) | about a year ago | (#45395461)

Well sure, if you never use bookmarks or care about cached sessions and stuff...

Re:Yay! (1)

mlts (1038732) | about a year ago | (#45395689)

I copy/paste bookmarks to a different file, so that really isn't an issue. Cached sessions are not a worry either. In fact, being able to dump all state, no matter how much identifying info is left behind is a win for privacy.

Re:Yay! (0)

Anonymous Coward | about a year ago | (#45396851)

XP doesn't have the User Mode Driver Framework (buggy drivers can't crash the system) or the Windows Display Driver Model (GPU accelerated, double buffered, tear-free desktop). So, troll, enjoy your unstable and shitty looking XP. The rest of us have moved on.

Re:Yay! (4, Informative)

higuita (129722) | about a year ago | (#45393793)

Don't forget that now that is harder to do, thanks to the infinite wisdom from microsoft!!

In windows 8 (and 8.1), when you "shutdown" windows, you are really just hibernating the PC, not doing the XP shutdown... When it starts again, it will load the previous state into memory and the malware is still there (and bugs, and crashs, and trash running, etc, etc)

To really "shutdown" a windows, you need to "reboot" it (or press the power button!!)

The real solution is to use linux :)

Re:Yay! (1)

Cramer (69040) | about a year ago | (#45394505)

Unless you configure your shutdown button to actually shutdown the machine instead of hibernate. (Note: it's been like this since Vista, btw)

Re:Yay! (1)

Runaway1956 (1322357) | about a year ago | (#45394775)

Yanking the cord out of the power supply is a decent substitute for #shutdown -now.

Re:Yay! (1)

Cramer (69040) | about a year ago | (#45395179)

If you have a cord... pull cord, then pull battery(s).

Re:Yay! (1)

gmhowell (26755) | about a year ago | (#45396561)

If you have a cord... pull cord, then pull battery(s).

My tablet doesn't have removable/replaceable batteries, you insensitive clod!

Re:Yay! (1)

Runaway1956 (1322357) | about a year ago | (#45396763)

Of course it has removable batteries. Take this hammer, and hit this edge sharply. Now that edge. Wedge a knife under there, and pry up. See that? That's your battery!

Re:Yay! (1)

gmhowell (26755) | about a year ago | (#45396957)

Of course it has removable batteries. Take this hammer, and hit this edge sharply. Now that edge. Wedge a knife under there, and pry up. See that? That's your battery!

You're a genius. Want an apple?

Re:Yay! (0)

Anonymous Coward | about a year ago | (#45396729)

Don't forget that now that is harder to do, thanks to the infinite wisdom from microsoft!!

In windows 8 (and 8.1), when you "shutdown" windows, you are really just hibernating the PC, not doing the XP shutdown... When it starts again, it will load the previous state into memory and the malware is still there (and bugs, and crashs, and trash running, etc, etc)

Wrong! The kernel hibernates, yes. Everything else (programs and services) does not.

The real solution is to use linux :)

Fuck off, misinformed troll.

Re:Yay! (1)

Joshua Shaffer (2895571) | about a year ago | (#45402807)

Don't forget that now that is harder to do, thanks to the infinite wisdom from microsoft!!

The article says only XP and 7 are affected, so the changes from 8 to shutdown wouldn't matter.

Re:Yay! (0)

Anonymous Coward | about a year ago | (#45402983)

Hold down the SHIFT key as you click Shut Down

Re:Yay! (2)

Ravaldy (2621787) | about a year ago | (#45395303)

The reboot trick is for all software, not just Windows. You haven't been in IT long enough if you've only seen MS OS require this.

I have a bunch of self contained Linux based boxes we have to restart on a regular basis due to memory leak issues in software. I think the OS on it's own is fine, but start adding garbage on top of any OS and you have trouble. Reboots are a common practice for fixing a number of issues for any software you may come across regardless of OS.

I have Windows Servers that get rebooted only when critical updates are installed. Last time I rebooted the servers it had been up for over 3 months. I also have a Linux based router that runs months at a time before needing a reboot (and it's usually just a precaution).

Re:Yay! (0)

Anonymous Coward | about a year ago | (#45396149)

I have a bunch of self contained Linux based boxes we have to restart on a regular basis due to memory leak issues in software.

Then you're doing something wrong. I can see restarting the processes which are having leak issues, but the entire OS?

Meanwhile, here we have a Classic Slashdot headline in all it's bullshit glory: "IE Zero-Day Exploit Disappears On Reboot"
Really? So I guess Microsoft doesn't even have to issue a patch. If you want to fix the security hole, just reboot your computer! Remember, you heard it on Slashdot first, rebooting a computer magically patches security problems!

Re:Yay! (1)

RocketRabbit (830691) | about a year ago | (#45396837)

You shouldn't have to reboot a Linux box because of a memory leak in software, killing and restarting the process always does the trick.

I guess if you're a Windows admin thrust into this unfamiliar world you stick with what you know, though. Kind of a knee-jerk reaction.

Re:Yay! (1)

DarkOx (621550) | about a year ago | (#45403761)

I have a bunch of self contained Linux based boxes we have to restart on a regular basis due to memory leak issues in software.

Memory leaks (unless they are IN the kernel or some very core process like init ) should never require a reboot. Once the process is killed, and the OOM killer should do that at some point, all the memory used/leaked will be freed, by a proper kernel. Which is not to say the application or even the entire system might not be thrashing and nearly at a stand still.

I give it 99% odds you could put a cron job on those Linux boxes to kill and restart the offending process at whatever interval your "regular basis" is and they would never need rebooting.

Requires root access (0)

Anonymous Coward | about a year ago | (#45393595)

AFIK WriteProcessMemory and CreateRemoteThread APIs require root. (specifically SeDebugPrivilege)

But you already knew not to run IE as root right?

Re:Requires root access (1)

Joining Yet Again (2992179) | about a year ago | (#45393613)

I blame CamelCase for most Windows security problems. I swear the bumpiness of the function name distracts the mind from thinking properly about argument checking.

Re:Requires root access (1)

lgw (121541) | about a year ago | (#45393801)

you still have to use the shift key for stupid_case, plus you have to type an extra character.

The One True Way of settling style holy wars is "go with the shorter option", and by that measure CamelCase wins.

Meh, I just want functions to start with capital letters, and variables not to, but some languages don't even get that right! (Technically, it's constants that start with a capital, and function/member names are just constant pointers so capitalize em.)

Re:Requires root access (1)

Joining Yet Again (2992179) | about a year ago | (#45393875)

My grand ideological vision involves everything being tokenised, so anybody can see any code in any way they like, and use whatever naming style they want.

The canonical representation looks something like LISP, of course ;).

Re:Requires root access (2)

lgw (121541) | about a year ago | (#45393909)

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

Re:Requires root access (0)

Anonymous Coward | about a year ago | (#45394885)

Meh, I just want functions to start with capital letters, and variables not to, but some languages don't even get that right! (Technically, it's constants that start with a capital, and function/member names are just constant pointers so capitalize em.)

I'm pretty sure McCarthy just rolled over in his grave. And I think you just gave Stroustrup an aneurysm. Gosling is just sitting in the corner, weeping.

Re:Requires root access (1)

lgw (121541) | about a year ago | (#45395375)

My apologies to McCarty and Stroustrup. Gosling deserves it - I had to code in Java, and you don't heal from that, man! (Of course, now C# has the same problem in reverse, with people using properties instead of members for everything and capitalizing property names - you just can't win!).

Re:Requires root access (1)

jarfil (1341877) | about a year ago | (#45397123)

Best naming scheme is Write_processMemory_r1_998 and CreateRemote_thread_rev001_2.
No more ambiguity about which part is static and which not.

Bonus: also no need for some silly source control, just change the rev number (or r for release, unless the minor is > 900, which means it's beta), and bam! all the code at your fingertips, all the time!

Re:Requires root access (0)

Anonymous Coward | about a year ago | (#45398669)

>The One True Way of settling style holy wars is "go with the shorter option"

I bet someone said that at a time when 'creat' function was created.

Re:Requires root access (0)

Anonymous Coward | about a year ago | (#45393743)

Only for accessing processes you didn't create.

Re:Requires root access (0)

Anonymous Coward | about a year ago | (#45394099)

ACtually, you would need admin privledges in this case as well. IE runs as a low integrity process. It cant do anything 'interesting' without privledge escalation. Unless you also exploit a bug in flash/java.

Disappears on reboot is a limitation, not feature (4, Informative)

sinij (911942) | about a year ago | (#45393601)

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.

Re:Disappears on reboot is a limitation, not featu (2)

Anonymous Coward | about a year ago | (#45393785)

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.

Re:Disappears on reboot is a limitation, not featu (0)

Anonymous Coward | about a year ago | (#45394013)

THIS! Plus there's the summary which says "and disappears on reboot **********provided it hasn't already taken over your PC********** making it trickier to detect".

I think they're suggesting that it's a dropper that doesn't start from disk but might make itself persistent later on.

Re:Disappears on reboot is a limitation, not featu (1)

sinij (911942) | about a year ago | (#45394183)

They attempted polymorphism with they key change. Fireeye blog stated: "this 4-byte key is present at offset 0 and changes with each subsequent beacon.". I have no idea how effective this would be, but my guess is that it would defeat all off-the-shelf detectors. If you use static key AV vendors simply add a rule to signature detection. Cryptographically speaking, exploit authors are not 'encrypting' this to keep data secret, or they wouldn't use 4-byte key.

Re:" Copy of the code and exploit"
You have exploit and you have payload. Exploit is always there in pcaps and whatever website that got compromised and serving this, so it is very difficult to completely hide it. Not sure if "memory only" makes it any more difficult for forensic analysis, since payload (trojan) is still there. Attacker wouldn't be uploading such 'red flag' payload if they wanted to keep intrusion hard to detect. This tells me it was likely a smash and grab job.

Re:Disappears on reboot is a limitation, not featu (1)

fluffy99 (870997) | about a year ago | (#45395389)

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.

That's my take as well. If you're a thief breaking into a building to get a copy of important files, you don't leave a busted out window and the safe sitting wide open. The best theft is the one no-one realized happened. For example, the break into Bit-9 where they stole a digital signing cert would have been far more useful if it wasn't detected. Or instead of stealing something, you're leaving something behind such as installing a trusted root cert that you control.

Re:Disappears on reboot is a limitation, not featu (2)

girlintraining (1395911) | about a year ago | (#45393977)

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.

Re:Disappears on reboot is a limitation, not featu (1)

sinij (911942) | about a year ago | (#45394235)

To answer your question - one is controlled entirely by exploit/malware authors and other is not.

Re:Disappears on reboot is a limitation, not featu (1)

girlintraining (1395911) | about a year ago | (#45395087)

To answer your question - one is controlled entirely by exploit/malware authors and other is not.

Yeeeeah... a difference that's sufficiently important why again? Most computer today don't reboot; they hibernate. It could be days to weeks now before they actually wipe it. Weeks during which, it's hoover-vacing every piece of data you put in your browser. Now, let's be honest -- how much do you really do with your computer if your internet is down?

o____o

Re:Disappears on reboot is a limitation, not featu (0)

Anonymous Coward | about a year ago | (#45394803)

Or, this is simply bad reporting and this particular piece of malware is deliberately engineered to not persist to disk.

Lots of really important sounding jargon... (1)

jlv (5619) | about a year ago | (#45393649)

This is the first time I've ever seen the value being used in an XOR loop referred to as a "key".

Re:Lots of really important sounding jargon... (2)

daveoj (319762) | about a year ago | (#45393693)

It's because it's being used in the context of a simple XOR-based encryption scheme -- very common in malware, actually.

Re:Lots of really important sounding jargon... (0)

Anonymous Coward | about a year ago | (#45393949)

We'd call such things "crypters". They're simple scramblers - their favour being their size and the simple fact that they change the crypted data so it isn't constant.

They have to have the key, so it doesn't matter if you use Rijndael, Threefish, Kasumi or make up a simple ARX or ORX cipher - it's not intended to be secure against slow analysis, but simply to stop the most trivial signature fingerprinting the payload.

Bonus points if the crypter routine itself is polymorphic (swaps instructions like for like) or metamorphic (restructures itself), of course, which strongly encourages a very simple approach.

I suppose you could call RC4 something like that, as it very strongly resembles one and I definitely saw very similar algorithms thrown around in the 80s; it's certainly just as broken by now.

Re:Lots of really important sounding jargon... (1)

sinij (911942) | about a year ago | (#45393993)

In this specific case XOR with the short key appears to be used as a method to avoid heuristic detection. If left in plaintext things like kernel32.WriteProcessMemory will trip exploit detectors even if you have Zero-Day.

Complicated unless... (1)

daveoj (319762) | about a year ago | (#45393717)

It's maybe complicated unless forensics are capturing a memory image... which they should be these days.

Rootkit vs. CRIT (5, Interesting)

Anonymous Coward | about a year ago | (#45393831)

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.

Re:Rootkit vs. CRIT (1)

sinij (911942) | about a year ago | (#45394311)

^^^ Mod parent up please.

Re:Rootkit vs. CRIT (1)

Arker (91948) | about a year ago | (#45394985)

You are right, and it's a colander instead of a nearly seaworthy boat that just needs some holes patched because of 'nimble' development practices and several decades of constantly reinventing the wheel and selling it over and over again with a little more gee-whiz each time.

If you want a secure computer you need a conservative stack, free from the ground up, with security designed in from day one, and an emphasis on mathematically correct code rather than features. Otherwise, you are trying to bail a colander.

Re:Rootkit vs. CRIT (1)

Anonymous Coward | about a year ago | (#45396267)

"Two broad approaches exist" ..

The only safe solution is to eliminate Microsoft Windows ...

Re:Rootkit vs. CRIT (1)

Antique Geekmeister (740220) | about a year ago | (#45399443)

> 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

That is _nasty_. May I safely assume that virtual machines, with their hosting server based software NIC's, are immune from this vector? And do you have a reference to this mode of attack?

Re: Rootkit vs. CRIT (0)

Anonymous Coward | about a year ago | (#45399935)

It has been described in the literature for some years now, albeit only as PoCs and vague possibilities: the burden of maintaining very hardware-specific code denies it as a sensible option to all but a few very determined state-sponsored actors who need little introduction at this point. I believe that the implant publicly identified as "BadBios" might be one of these, although I do not have a sample for analysis (I would appreciate one).

I still think it's a stupid approach for a SIGINT agency to take, as the risk is that if it is discovered, it is far more likely to remain in place through a thorough reversing: and although this partially seeks to aid countermeasures to that specific variant, it also shares the unpleasant proliferation characteristic of biological and chemical weapons that once isolated, it is easy for an adversary to copy and turn against you, compared to the cost of development, and can also spread out of control or be subverted (as can all botnets). This risk, or the consequences of the undermining of trust, does not seem to have been adequately weighed. What if somebody honeypots FERRETCANNON (which partially uses p0f), or counter-exploits a FOXACID C&C (which runs on Windows Server 2003, for god's sake!) to steal its coveted 0days?

No conventionally-designed VMs will protect you from a determined attack: they can be easily identified by quirks in the hypervisor handling and jumped out of (so-called "redpill attacks") and then the host machine targeted in such a manner: again, this is described in the literature, although secure VMs are possible the overhead would make them impractical (they are essentially emulators). It's hard to imagine anyone holding a rootkit of that kind of quality wouldn't have, say, an ESXi redpill 0day or two on their shelves. You could even argue that the more layers there are, the more opportunities there are to hide a pea under the princess' mattress, so to speak.

It's a question of insecure foundations. That is the kind of thing Snowden was referring to when he talked about terrible endpoint security bypassing even strong encryption.

Not to mention bugs, sometimes deliberately introduced, sometimes merely deliberately overlooked, in implementations, often encouraged by things like overcomplex and unclear standards (for example, the incomplete curves and complex non-constant-time addition ladders used to implement the Certicom ECC algorithms, designed by Jerry Solinas at the NSA after a search for particularly susceptible seeds).

I think you can begin to see why I'm bitter about the whole thing.

Dissapears on reboot... (1)

enriquevagu (1026480) | about a year ago | (#45393839)

Sure it dissapears!

Unless you're running IE as admin, you have UAC disabled and the malware has installed a hypervisor and you're hickjacked forever without having any chance to detect it. How long before we see that?

Re:Dissapears on reboot... (1)

lgw (121541) | about a year ago | (#45394381)

How many people run IE as admin these days? You'd have to be on XP, right?

Re:Dissapears on reboot... (1)

Antique Geekmeister (740220) | about a year ago | (#45399457)

How many Windows users do _not_ typically run as an "Administrator", to ease software management? And especially for Active Directory or Exchange administrators, re-authenticating every time they need to escalate to manage their resources during the day becomes burdensome. Most of the Windows admins I know do this as a matter of course, to ease the strain on their typing hands and improve their response time to requests.

Re:Dissapears on reboot... (0)

Anonymous Coward | about a year ago | (#45402339)

IF they're doing it - and I doubt that very much - they should be fired for not knowing how to make it automatic for the processes they want.

disconnect ! (0)

Anonymous Coward | about a year ago | (#45396249)

http://scherbius2014.de/HandbuchScherbius2014.pdf

(only in German for now, Google translate is your friend)

In short:
+ Disconnect the cipher machine from the net or be compromised
+ Symmetric crypto and key couriers defeat quantum crypto
+ Carrier pigeons might be an excellent idea after all

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?