
AtomBombing: A Code Injection That Bypasses Current Security Solutions - brakmic
http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions
======
amluto
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.

~~~
userbinator
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.

~~~
TheDong
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.

We'll call it the iPhone.

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

[1] [http://www.codeproject.com/Articles/11777/InjLib-A-
Library-t...](http://www.codeproject.com/Articles/11777/InjLib-A-Library-that-
implements-remote-code-injec)

~~~
userbinator
_It does however allow you to execute code in another process._

CreateRemoteThread also allows you to do this, quite straightforwardly.

------
darklajid
Disclaimer: I'm clueless.

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?

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

~~~
red75prime
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.

Nothing new, but a few new tricks.

------
Animats
Here's the real paper.[1]

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

[1] [https://breakingmalware.com/injection-
techniques/atombombing...](https://breakingmalware.com/injection-
techniques/atombombing-brand-new-code-injection-for-windows/) [2]
[https://msdn.microsoft.com/en-
us/library/windows/desktop/ms6...](https://msdn.microsoft.com/en-
us/library/windows/desktop/ms684954\(v=vs.85\).aspx)

~~~
tr1ck5t3r
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.

[http://www.rohitab.com/](http://www.rohitab.com/)

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

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

~~~
cm3
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.

