This doesn't seem all that exciting to me. If you have a handle to a target thread that allows you to call QueueUserAPC, it's game over already. You can own that thread in so many ways that I don't see why a new one is exciting. (Heck, you could just use the debugging APIs.)
This seems like of like saying "hey look, root on a Linux system can inject code into Chrome". No kidding.
Indeed, the basic mindset and operating premise of these security companies is to find anything that could even be the tiniest bit exploitable and hype it as a huge risk... I have a suspicion that they will not be satisfied until everyone's computers are turned into virtual prisons and controlled by some central entity.
And no one can add a new bit of software to this computer you "own" until the software has submitted to draconian laws and been reviewed by their experts who will entirely decide your developer livelihood. You'll pay money for the possibility to maybe let a user ever run the software you spent years developing.
I think the point is that contemporary malware detection closely monitors straightforward APIs like CreateRemoteThread, but this technique flies below the radar for now. It's just another iteration of the arms race.
That was true 15 years ago, when people run Windows XP using an Administrator account. Those years, without a third-party security product monitoring various API calls, you were pretty much screwed.
In modern Windows however, UAC has largely managed the attack vector.
1) You need to open a thread handle, and you can only do that on processes running in the same security context the attacking thread. So you can already execute code, and this vector alone does not give you privilege escalation. It does however allow you to execute code in another process.
2) It uses NtQueueApcThread for 1), which is a known vector for this type of "attack", see e.g., [1]. That code uses NtQueueApcThread to call LoadLibrary in the target process
3) the "new" thing presented in the article is to get a ROP-chain in the called process by using atom tables
I don't know. I have been away from windows for about ten years, and a lot may have happened, but this doesn't seem like it would allow me to do something that I couldn't already do. What is the benefit here, compared to e.g., using NtQueueApcThread and LoadLibrary to load the code?
They claim that there's basically no way to fix this (it's a consequence of the design of some features, Atoms).
But as far as I understand they have to call the (undocumented, according to the blog) NtQueueApcThread function.
a) What guarantees are given for undocumented API methods in Windows? I know Microsoft tries hard to make everyone happy, to be backwards compatible. But - even for stuff like this?
b) For AV solutions: Wouldn't this undocumented call be a somewhat decent marker?
Wow. Is this really as bad as it sounds? I'm no security researcher but this sounds quite bad:
"AtomBombing is performed just by using the underlying Windows mechanisms. There is no need to exploit operating system bugs or vulnerabilities.
Since the issue cannot be fixed, there is no notion of a patch for this"
I'm guessing that if this starts to be a popular attack vector, security firms would try to come up with some sort of atom integrity checker or something, but still, this doesn't look good.
Or am I missing something and maybe it's really not that bad? any one has any resources to read up more on atoms (besides the research paper)?
If you have an active virus on your system, it can use this method (or any other already known method) to inject its code into, say, your browser and steal credit card info or some such.
Windows Atom Tables are nothing special and are, like many APIs invented for other features, very old. Think using lookup for DLLs in the same dir as the program or autorun.ini as similar old feature that were abused as attack vectors.
It's a code injection method. And it's an interesting approach, but dll injection with some tricks can be just as undetectable.
Short version: An attacker already has unprivileged access to your machine (running something with your user's privilege level). The attacker can use this type of method to access other processes in the same security context (running under the same user).
Or in different terms: it's not privilege escalation, it's not remote code injection (because you already need to be in), it's a method for increasing horizontal access.
So no, the sky is not falling or not more than usual. :)
Windows has a terrible mechanism for inter-thread procedure calls.
This is a way to get another thread to call a function determined by the sending thread. (What could possibly go wrong with that?) There are some security safeguards around this, but not enough.
This looks like something left over from the Windows 3.1/DOS days of no memory protection. Microsoft does not recommend it for threads outside the caller's process[2], but it's still in the OS. Some Windows expert might try disabling it for inter-process calls and see what breaks. It's only supposed to work for "desktop processes" anyway; for servers it could be disabled.
(I'm all in favor of inter-process calls, but the QNX MsgSend/MsgReceive/MsgReply mechanism is far better than this. Most others are far worse. Either performance or security is poor.)
Non domain windows systems are quite easy to hack, those connected to a domain server are harder but still not impossible.
As they have already persuaded a user to run evil.exe assuming they have sufficient admin privileges, you can do a lot of damage in a lot of ways.
People can learn alot from using this little tool to see a variety of attack vectors just by using api's.
I've read all the text yesterday and still don't see an explanation how code is executed. I know Windows atom tables as a feature used in DDE (say for clipboard infrastructure), and it's been there like forever, but how is the code from the table executed?
In the research paper there's a bit more of an explanation. I really can't explain it since I'm no expert but I believe the relevant bit is this:
"...a new exploitation technique was invented solely to bypass DEP: ROP – Return Oriented Programming.
How can we use ROP to our advantage in order to execute our shellcode in the target process?
We can copy our code to an RW code cave in the target process (using the method described in stage 1). Then use a meticulously crafted ROP chain to allocate RWX memory, copy the code from the RW code cave to the newly allocated RWX memory, and finally jump to the RWX memory and execute it."
Then a bit later it says:
"This syscall will set the context (register values) of hThread to the values contained in lpContext. If we can get the target process to call this syscall with an lpContext that will set ESP to point to our ROP chain and set EIP to point to ZwAllocateVirtualMemory, then our ROP chain will execute. The execution of the ROP chain will eventually lead to the execution of our shellcode."
Thanks, I need to reread it, because I'm not sure who invokes the syscall. Quite possibly it's automated via an innocuous looking DDE invocation. Basically, I'm wondering what piece of code writes to the table and then makes some other aimed for application run the code from the table. If it's a piece of code that's already running as the same user, then the aim must be to make a higher privileged application to execute the code from the table. Need to brush up my Win32 knowledge to make sense of it, I guess.
This seems like of like saying "hey look, root on a Linux system can inject code into Chrome". No kidding.