Broadband Tech > Security > Security > Analysis of Backstealth technology

reply to Steve

Re: Analysis of Backstealth technology

said by Steve:

---

said by KING:

---

I wonder what the author of Backstealth has to say now about leaving ZA and ZAP out?

---

Nothing sinister or foolish about it: because BackStealth wouldn't work on ZoneAlarm. The fact that ZA prompted for internet access meant that the whole concept - stealth - didn't apply.
The idea of proof-of-concept is to prove your concept, and it didn't with ZA.

---

reply to Steve
I've had a couple of private queries that made clear that the exact method of "DLL Injection" is not so clear to everybody. I'd like to expand on this a bit.

First, this is not about infecting an executable file (the .EXE itself), though viruses clearly do this. The technique we're using never touches any program on disk - the firewall or otherwise - and only operates on in-memory objects.

Each window in the system has a title (for instance, "MSDN Library - January 2002 - Open Process" is the title of the Win32 API help browser I have open now. The firewall windows have a name too ("ZoneAlarm Pro", etc.).

Any program can ask the operating system: "do you know of any windows with name XYZ?", and receive a handle to the process that has that window. This handle lets us investigate and sometimes manipulate the process, but (again) has nothing to do with anything on disk.

The next step is to allocate memory in the remote process, and if you've not done it before, it seems bizarre. Normally when you allocate memory, it's in your own process space for your own use, but Win32 allows us to do it remotely. So the firewall process has a bit of extra memory just "show up", and it has no idea this has happened.

Because we can read and write memory in the remote firewall process, we fill up this new chunk of memory with some evil data and some evil code. We're about to light the fuse, and the firewall still has no idea this is going on right under its nose.

Finally the bomb goes off: we do CreateRemoteThread() that actually runs the code in that remote memory space - inside the firewall. This is a functionality normally reserved for debuggers, but even after studying it a lot for a few days it still seems far out.

But it works, and our evil code starts executing inside the firewall, and the firewall has no idea that it has any company. Our evil code is part of the firewall, and we can do pretty much anything we like. By default, this thread won't hurt any part of the rest of the firewall, so if we're careful we can remain undetected and won't mess the program up.

The current BackStealth doesn't touch the firewall code itself: it just uses it as a convenient parking space to do its work. But once we're running around inside the firewall, it's very hard for it to protect itself.

Now Sygate has (somehow) managed to prevent the bomb from going off by (somehow) causing the evil CreateRemoteThread to fail. I'm working on ways to circumvent this, but in any case they've forestalled most of this for now.

The technology to do DLL injection has been around for many years, so BackStealth is more of a "clever application of technology" than breakthrough original research. But it's still very clever.

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net

said by Steve:

---

Each window in the system has a title (for instance, "MSDN Library - January 2002 - Open Process" is the title of the Win32 API help browser I have open now. The firewall windows have a name too ("ZoneAlarm Pro", etc.).

Any program can ask the operating system: "do you know of any windows with name XYZ?", and receive a handle to the process that has that window. This handle lets us investigate and sometimes manipulate the process, but (again) has nothing to do with anything on disk.

---

said by Steve:

---

Now Sygate has (somehow) managed to prevent the bomb from going off by (somehow) causing the evil CreateRemoteThread to fail. I'm working on ways to circumvent this, but in any case they've forestalled most of this for now.

---

reply to Steve
Steve, has anyone tested BID 3.5 with your modified BackStealth. In the main thread a user reported that BackStealth was shut down completely by BID 3.5, however I don't believe BackStealth was actually targeting BID 3.5.

I apologize if this has already been asked before.
--
Just my 2 bits.

reply to psloss

said by psloss:

---

It should also be possible to do this to processes that don't create windows, such as services.

---

quote:

---

I don't have Sygate, but can you check to see if Sygate has marked the pages in its address space?

---

reply to gt7697c

said by gt7697c:

---

Steve, has anyone tested BID 3.5 with your modified BackStealth.

---

• ZoneAlarm Pro Personal Firewall
• ZoneAlarm Personal Firewall
• Sygate Personal Firewall
• Sygate Personal Firewall Pro
• McAfee Personal Firewall
• Tiny Personal Firewall
• Norton Internet Security 2002
• Kerio Personal Firewall

reply to Steve

said by Steve:

---

Yup, that's next. I am able to open a PROCESS_ALL_RIGHTS handle to the Sygate firewall process, and both VirtualAllocEx() and WriteProcessMemory() work just fine: so I'm clearly able to muck with their address space. It's only CreateRemoteThread() that's failing.

---

said by Steve:

---

I originally thought they had done something with the process token take away the right to create a thread, but if they knew how to do this, they'd surely have done the same thing to the VirtualAllocEx() and ProcessWriteMemory() calls. Will be interesting to find out...

---

said by psloss:

---

What is the failure signature for CreateRemoteThread?

---

quote:

---

Are you familiar with SysInternals.com?

---

said by Steve:

---

said by psloss:

---

What is the failure signature for CreateRemoteThread?

---

ERROR_ACCESS_DENIED (err#5). I can't find any reason why this would be denied for an admin with seDebugPrivilege.

---

said by psloss:

---

What NT platform? NT, 2000, or XP?

---

quote:

---

Also, what is the process token for the Sygate process you're trying to get into?

---

code:

---

WINDOW hWnd = FindWindow("Sygate Personal Firewall");
GetWindowThreadProcessId(hWnd, &dwProcessId);
HANDLE OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwProcessId);

---

If Jaykaykay can hijack an unwise.exe and make it go get some updates over the Internet, you guys do not have a chance to ever again feel your firewall is safe.

I would like the name this the JKK injection technolgy after one of our favotite members.

»Command line for RefUpdate to run automatically?

reply to Steve

said by Steve:

---

My particular testing is on NT 4.0 server

---

reply to Steve

said by Occasu:

---

Where is the text file saved to? It says the file is saved to C\:retrieve.dat.

---

I do have a file on my C: called retrieve.dat, despite the warning that my norton firewall gave to wanting to connect and blocking. That is why i was wondering when you changed backstealth to work for ZA it may have downloaded the file despite the warning ZA prompted.

said by Occasu:

---

I do have a file on my C: called retrieve.dat,

---

Ahh i see 0 bytes

Edit: oops sorry steve, the answer to this question seems to be in Zhen Xjells thread... sorry
[text was edited by author 2002-05-04 19:26:19]

[text was edited by author 2002-05-04 19:33:47]

said by Occasu:

---

ahhh i see the file is 0 bytes. What i still dont understand is NPF/NIS is one of the firewalls it is designed to bypass. From what it seems this exploit only seems to provide a warning that a trusted application, in this case a firewall is trying to access the internet. It is not actually bypassing the firewall unless i allow it to. Is backstealth just a variation of the firehole test that used IE as a zombie?

Again thank you for your time in answering my most likely redundant questions

---

Thank you very much for the reply JVmorris. Seeing that a lot of users use the default settings for NPF/NIS i see how this would be a problem. Even in the the warning i got it says "threat level low risk" for IAMAPP.EXE connecting to the internet. To someone a bit too trusting in their firewall would have still clicked automatic or even allow.

In this case I was expecting some sort of warning that my firewall or a component of it would try to connect, but had this happened out of the blue i can't say for certain that i would have blocked it (although i would like to think i would have been paranoid enough to just say no ).

I would also like to mention System Safety Monitor correctly recognized backstealth.exe as trying to start and prevented it from doing anything until i allowed it to.

[text was edited by author 2002-05-04 19:52:22]

said by Occasu:

---

. . . . Even in the the warning i got it says "threat level low risk" for IAMAPP.EXE connecting to the internet. To someone a bit too trusting in their firewall would have still clicked automatic or even allow.

---

quote:

---

In this case I was expecting some sort of warning that my firewall or a component of it would try to connect, but had this happened out of the blue i can't say for certain that i would have blocked it (although i would like to think i would have been paranoid enough to just say no ).

---

quote:

---

I would also like to mention System Safety Monitor correctly recognized backstealth.exe as trying to start and prevented it from doing anything until i allowed it.

---