Slashdot Mirror
Drive-By Exploits Pushing Ransomware Now Able To Bypass Microsoft EMET (arstechnica.com)
An anonymous reader writes from a report via Ars Technica: Ars Technica reports that drive-by attacks that install the TeslaCrypt crypto ransomware are now able to bypass Microsoft's Enhanced Mitigation Experience Toolkit (EMET), which is designed to block entire classes of Windows-based exploits. The EMET-evading attacks are included in Angler, a toolkit for sale online that provides ready-to-use exploits that can be stitched into compromised websites. Researchers from FireEye published a blog post Monday that says the new Angler attacks are significant because they're the first exploits found in the wild that effectively pierce the mitigations. The exploits' code is based on the Adobe Flash and Microsoft Silverlight browser plugins that bypass data execution prevention, a protection that prevents computers from running data loaded into memory. The new Angler exploits rely on techniques other than Data Execution Prevention (DEP) that are harder to detect and contain fewer limitations. FireEye researchers have observed the exploits working only on Windows 7 and not on Windows 10, which is more resistant to exploits. They also only work when targeted computers have either Flash or Silverlight installed. Microsoft created EMET to largely block entire classes of memory-based software exploits that had existed for decades. Now, Angler developers have struck back with techniques that can undo some of those protections. Recently, the TeslaCrypt ransomware makers closed down shop and released a master key and an apology.
Why does Adobe Flash and Microsoft Silverlight browser plugins bypass data execution prevention?
It is pitch black. You are likely to be eaten by a grue.
and not on Windows 10, which is more resistant to exploits."
Which the FireEye didn't actually say.. Nice summary, nice summary, lets be friends.
Make daily back-ups. Never pay a red cent to that filth. It'll go away if we stop paying them. Maybe we should make it illegal to pay them, as well as for them to do what they do.
The exploits' code is based on the Adobe Flash and Microsoft Silverlight browser plugins
So don't run crapware in your browser, and you're all set.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
That was my one reason for Silverlight.
Flash disabled for awhile now just too damn dangerous.
Create a ransomware to force upgrade/make some pocket money.
OMG! I just can't believe it! Does this mean that Windows is not secure???
What should I do???!!?!?
I don't read your sig. Why are you reading mine?
If this doesn't get you to upgrade to Windows 10, nothing will!
A Microsoft product vulnerable to exploits? That just can't true... Putting aside the sarcasm for a moment, this really should not come as a surprised to anyone. MS products are constantly targeted because MS makes them easy targets and their latest OS version has spyware and adware built in.
Anyone foolish enough to trust MS to fight against malware, when MS are pushing their own spyware/adware in Windows 10, is crazy and deserves whatever they get.
Microsoft has lots of money. Why don't they just actively buy these exploits as they hit the market (through an 'agent' if they must), reverse engineer them, update EMET & issue a patch that closes the flaw, and move on, long before anyone is hacked ???
You can do it at link time with this: https://msdn.microsoft.com/en-... Or by setting the proper AppCompatFlags. Or by calling SetProcessDEPPolicy. Or half a dozen other ways documented on MSDN and technet.
It isn't suitable for anything serious, it's a constant battle that will never end.
I'm pretty sure that "The Clapper" was a more beneficial invention than the internet.(saw one on clearance the other day, haha)
It's useful to download some files or documents and send some email, but that's about it, connect - get your stuff -then disconnect. Other than that it's a sad joke but it is amusing to sit back and watch the never ending failures.
EMET isn't a technology, its a package containing a number of security enhancing techniques (none invented by Microsoft), so "bypasses EMET" at best is uninformative, at worse makes little sense.
And you can allocate executable blocks with VirtualAlloc and change protection settings using VirtualProtect. The reasons that it's possible to bypass DEP in various ways fall broadly in two categories: backward compatibility and scripting. .Net byte code into native code. In addition even pure interpreters often still need to generate code, like thunks when the interpreted code needs to interface with the native environment, for example when a callback in interpreted code needs to be called from native code.
1. Backward compatibility
DEP was introduced in Windows XP and didn't exist before then. Even in Windows XP it isn't turned on by default for most processes. A lot of software has been written that executes data. A few common examples:
- Certain compilers (including GCC) allocate trampolines on the stack for certain operations. Trampolines are essentially bits of executable code that do a bit of bookkeeping and then jump to the actual function. An example use case is where you take a pointer to a nested function. Nested functions have access to locals from the function they're nested in, so they need to know where to find them. A common, but dangerous, way to do this is to allocate a trampoline on the stack that fixes the stack pointer so the trampoline sees the correct locals when it's called. GCC later ‘fixed’ this IIRC by marking the page with the trampoline executable, which is the worst solution imaginable since it effectively disables DEP for at least 4 kB of stack. It would have been better to either disable trampolines and the language features that require them (after all, you cannot safely use them now anyway) or to allocate them from a special heap.
- Certain popular libraries (including ATL) generate thunks, bits of executable code that convert input parameters into a form in which they can be consumed by the actual function. An example use case is where a callback is called by the operating system using a handle, but the actual function needs a pointer to a C++ object. So for example in ATL this is used to convert a window handle into a pointer to the object that implements the window's behaviour for use as a this pointer. In principle this can be fixed by allocating thunks from a special heap, but not all software has been recompiled and / or relinked with a newer library that does that.
- And then there are old scripting engines and the software that uses them. Next section.
2. Scripting
Scripting engines often aren't completely interpreted, because that makes them slow. Instead they translate the scripting code they want to execute, for example JavaScript or Java /
Nowadays it's possible to allocate this executable code from a special heap with modified permissions so code can execute even with DEP for the process as a whole turned on. It is an extra bit of executable memory though and care must be taken to avoid making it easy for attackers to exploit that.
And of course, older scripting engines were written before DEP was a thing and they don't know that they need to jump through the hoops and therefore don't work if DEP is enabled.
This DEP bypass has been known about for over 10 years. I guess people in security theatre land love their false sense.