dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
9894
share rss forum feed


Steve
I know your IP address
Consultant
join:2001-03-10
Yorba Linda, CA
kudos:5

Analysis of Backstealth technology

There has been discussion here about the "Backstealth" trojan, but I'm not sure if there has been much talk about exactly how it works. I've been disassembling it and have a pretty good idea how it operates. This is my analysis of it so far. Note that I'm not really strong on the Win32 calls involved here so am doing a certain amount of hand-waving in my explanations. But I have a pretty good idea how it's working.

This proof-of-concept comes in two parts: backstealth.exe and backdll.dll.

Backstealth.exe contains the new idea here: it searches for the personal firewall process and infects it with a bit of code at runtime. Then this bit of code is actually executed in the firewall's address space, and it is able to talk to the internet without notice.

Backdll.dll is the code that ultimately gets run in the firewall's address space, and the one provided is just sample code: it fetches a file. Within certain parameters, this code could in practice do nearly anything.

The infected code doesn't seem to interact with the firewall itself, so it's not like it's taking firewall-specific countermeasures: it simply relies on the fact that the firewall trusts itself.

How Backstealth seems to work

This discussion is at the C programming level talking to the Win32 API - "regular users" don't see any of these functions.

First, backstealth uses FindWindow() to search by name for the signature window of each firewall. The windows and their names

  • Sygate Personal Firewall Pro (with class #32770)
  • McAfee_FwClientClass (with class McAfee_FwClientClass
  • TinyPersonalFirewallMainWindow (with class #32770)
  • no window name, but with class Symantec NAMApp Class
  • KerioPersonalFirewallMainWindow (with class #32770)
I don't know whether these are actually visible windows or not, but I'm pretty sure it doesn't matter. The name of the firewall .EXE doesn't matter at all - renaming won't help.

Each of the firewalls is searched in order, but only the last one found is chosen for infection.

If the firewall's window handle is found, GetWindowThreadProcessId() is called to get a handle to the firewall process itself. This handle will gives access to all the manipulations that follow.

The program uses AdjustTokenPrivileges() to give itself permission to "do stuff" to the other process. This probably won't work for non-admin users, and I've not looked at it in that much detail. If this step fails, the injection can't happen.

It then calls VirtualAllocEx() to allocate a chunk of memory in the firewall process itself (yes, remotely), and I believe that the remote process can't detect this. The returned address is valid only in the remote process, but we can write to it from here.

Then it uses WriteProcessMemory() to remotely poke in some data to this newly-allocated space. This data includes a small bit of code. Again, it's a pretty safe bet that the remote process cannot detect that this new chunk of memory that it doesn't know about is starting to be filled in with Bad Stuff.

Then, CreateRemoteThread() is called to launch a new thread that uses the newly-allocated memory as the code base. Now the remote process - the firewall - has a new thread running that it doesn't know anything about. And since the firewall generally trusts itself, that thread's network access is unnoticed.

But Gwion had the bright idea to tell Kerio to watch itself, and it was able to catch this outbound access.

Impact

This technique rests squarely on the ability of the injection .EXE to run on the user's machine, and good computing practices should protect you. It's likely that there are those who rely on their firewall to catch the bad stuff do they can work without thinking, and they are the ones at risk.

How the firewall vendors will address this is unclear: protecting the user from himself is not always such an easy job.

Edit - minor technical updates

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

[text was edited by author 2002-05-02 13:32:59]


YinYang
Celestial Phenomenon

join:2002-04-24
Kissimmee, FL

Great info on this! I'm also going to be adding Gwion's rule to block this.
--
Everything is a differentiation of One Infinity.



Randy Bell
Premium
join:2002-02-24
Santa Clara, CA
reply to Steve

So, backstealth technology relies on the fact that your firewall trusts its own process and memory space -- interesting.



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
reply to Steve

Steve, you're priceless. Thanks. Very much appreciated.



jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA
reply to Steve

Steve,

Nice piece of work! Knew you couldn't resist!

For those like myself who aren't going to play with this baby,
-- How big is BackStealth.exe?
-- How bit is BackStealth.dll?

Just for general sizing information.

Understand your comment on BackStealth.dll. Like CRv1, I suppose we ought to be damn glad that it doesn't do anything more than it current does.

Re FindWindow(), now are you saying you KNOW it only searches for these signature windows or are you assuming that? If the former, then that would answer one of my questions as to whether it even tries to run with ZA/ZAP.

Re AdjustTokenPriviileges(), effectively Win 9X/ME users would consequently have no protection against this call (assuming it works on those OSs). Win NT/2K/XP users would have at least some protection running with a non-Admin account? (Which would be consistent with some recent posts by gwion in the Tiny-Kerio Program.)

As always, much thanks. (Warming up for the summer season, are you? )
--
Regards, Joseph V. Morris



Steve
I know your IP address
Consultant
join:2001-03-10
Yorba Linda, CA
kudos:5

-- How big is BackStealth.exe? 58,368 bytes
-- How big is BackDLL.dll? 55,808 bytes

quote:
Re FindWindow(), now are you saying you KNOW it only searches for these signature windows or are you assuming that?
I'm looking at the disassembled code, not strings in the binary: this is all it looks for. But in general, it's not in concept looking for "firewall processes" as it is "processes known to be trusted". My guess is that it could inject itself into IE with the same ease - most of the time IE is trusted as well, and this hidden worker thread would not likely go through all the security setup imposed by the browser.
quote:
Re AdjustTokenPriviileges(), effectively Win 9X/ME users would consequently have no protection against this call (assuming it works on those OSs)
This is true in any case. On an operating system with no real hardware protection of memory (as you have on the Win 9x/ME), there is next to nothing you can do to keep really mal-intentioned code from behaving badly. It may be a lot of work, but once bad code gets the CPU, you're finished.

Edit: - typos

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

[text was edited by author 2002-05-02 14:44:07]


Cudni

@193.130.x.x
reply to Steve

Just a data point
Backstealth doesn't make a connection on win98 although it identifies correctly the target fw(s)
lack of debug privileges

Cudni



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1

reply to Steve

Well, trying to run this as "user" in my NT setup kills it instantly... just plain dies the minute I press the go button. I saw a few log entries "denied" referring to it... and some attempted accesses contemporaneous with the test that are unusual ... some service controller and token stuff, but I'm not looking at it, right now, so that's my best comment, for now.

Haven't had a chance to review them all... but something in that configuration is murder on this exploit. I wish I could put my finger on what it is...

Probably immaterial, though, since most win users are reticent about running as admin full time, anyhow... defeating any real advantage that NT family security provides pretty much entirely. Which was why I took it to a junker and ran it as admin to start off, figuring that would be the way 80% of users will be running... and, of course, that 9x users have no choice at all in the matter ...
--
Forget and forgive. This is not difficult, when properly understood. It means you are to forget inconvenient duties, and forgive yourself for forgetting. In time, by rigid practice and stern determination, it comes easy.
- Mark Twain

[text was edited by author 2002-05-02 14:48:10]



Steve
I know your IP address
Consultant
join:2001-03-10
Yorba Linda, CA
kudos:5
reply to Steve

A bit more study reveals how this works.

The injecting program (backstealth.exe) creates a small memory buffer that contains data that will be needed by the remote thread: this includes the addresses of three key functions in the KERNEL32 DLL (GetProcAddr(), LoadLibrary(), FreeLibrary()), along with the full pathname of the backdll.dll to load and the name of the entry point function (themain).

These bits of data are all copied to the start of the memory allocated by VirtualAllocEx(), and the injection subroutine is copied to follow it. This is a fairly small amount of memory in total, perhaps 1 kbyte.

Once the memory has been crafted, the remote thread is executed at the start of the copied injection subroutine. This gets things going over in the remote process.

The concept of "starting a remote thread" is foreign to UNIX folks, where processes are much more inviolable than they are under Win32. This is not really a bug in Win32 at all - it's a feature, but it should be protected by the permission structure.

This injection subroutine is really simple: a classic trampoline function. It simply loads the requested DLL, finds the entry point, and calls it - it has no idea what the loaded DLL does, nor does it care. All the "real" work is done by the secondary DLL (backdll).

... and the SetProcessToken() business is used to grant the current process the seDebugPrivilege right. "Privileges" are the ability to do a thing, as opposed to "Access Permissions" which are the ability to access an object. "Debug another process" is a privilege. "Read a file" is a permission.

I believe that this whole technology won't work on 95/98/Me, but it's not due to the lack of the debug privilege. The key function is CreateRemoteThread, which is not supported under these operating systems.

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



Steve
I know your IP address
Consultant
join:2001-03-10
Yorba Linda, CA
kudos:5
reply to gwion

said by gwion:
Well, trying to run this as "user" in my NT setup kills it instantly...
Most likely the process is not able to acquire the seDebugPrivilege right. Run the program in a cmd window and there should be debugging information to the console.

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


Sentinel
Premium
join:2001-02-07
Florida
kudos:1
reply to Steve

said by Steve:
snip... I believe that this whole technology won't work on 95/98/Me, but it's not due to the lack of the debug privilege. The key function is CreateRemoteThread, which is not supported under these operating systems.
This thread is way to far over my head but I am trying to read it anyway in hopes of someday getting smarter but... I did catch this quote and I saw something that interested me. Are you saying that this whole thing is a non-issue on Win9x based systems because of their inability to do something that is possible on NT based systems? Or am I reading that wrong?
--
AL


Steve
I know your IP address
Consultant
join:2001-03-10
Yorba Linda, CA
kudos:5

said by Al Otero:
Are you saying that this whole thing is a non-issue on Win9x based systems because of their inability to do something that is possible on NT based systems?
I think that's a good way to put it: the program backstealth simply relies on the ability to create a remote thread, and if it can't, it will fail. That just means that 9x is immune to this exploit.

But because it's a much more "open" memory architecture (aka, "unprotected"), it seems to me that with some effort somebody could accomplish more or less the same thing by doing this "the hard way". It might be too hard tobe worth the bother, but I'm pretty sure that in this battle, the bad guys will ultimately get the upper hand on the 9x/ME front.

... but I could be wrong on all of this - it's been a hasty analysis.

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


Steve
I know your IP address
Consultant
join:2001-03-10
Yorba Linda, CA
kudos:5

... and I'd like to take this chance to sing a happy song about the fantastic disassembler I use, "IDA Pro" from DataRescue. The last time I jumped into disassembling something (Code Red II), I was using an utter piece of crap that made life lousy. I was determined not to go through that again, so I looked in to IDA Pro.

What a fantastic piece of software. It's an interactive disassembler that runs under Windows, and it's simply spectacular in its ability to turn "bytes" back into "programs". They have modules to disassemble nearly anything, and they recognize most of the popular C runtime libraries so that "unknown_sub_1235" is actually recognized as "printf". It's just stunningly good.

Highest possible recommendation for this work of art.

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



R2
R Not
Premium,MVM
join:2000-09-18
Long Beach, CA
kudos:1
reply to Steve

Steve - is ZoneAlarm immune to this vulnerability -- or just immune to this demonstration of the vulnerability? I noticed that by your report backstealth.exe does NOT go looking for ZA -- so it was NEVER intended to test ZA.



Steve
I know your IP address
Consultant
join:2001-03-10
Yorba Linda, CA
kudos:5

said by R2:
is ZoneAlarm immune to this vulnerability -- or just immune to this demonstration of the vulnerability?
All I know is that the program doesn't check for it, and I thought I remember reading somewhere that the technique doesn't work for ZA (I can't find that reference now).

I don't run any of the personal firewalls so I can't test it out, nor do I know how a piece of software would defend itself this in the general case.

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


R2
R Not
Premium,MVM
join:2000-09-18
Long Beach, CA
kudos:1

One source of the reference was ZoneLabs, but I would like to have a third-party source verify this...

Clearly, testing "backstealth" on a system using ZoneAlarm is not going to be a useful endeavor. Thanks.



jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA
reply to Steve

Steve,

If we've been reading the same comments, we've been seeing a bit of inductive reasoning. To wit:

Statements that Zone Alarm is not affected by BackStealth,
which is then used to conclude that Zone Alarm is invulnerable to BackStealth.

All of which, of course, would be true by definition.

However, it continues to beg the question as to whether Zone Alarm can be exploited based on this vulnerability demonstrated by BackStealth.

I don't know one way or the other and I won't pretend that I do. What I would like to see is a definitive statement (one way or the other) as to whether ZA/ZAP (by version) on a particular OS is or is not vulnerable to the fundamental vulnerability upon which the BackStealth vulnerability demonstrator is based. I've been waiting for about 48 hours now, but still haven't seen any such definitive statement (again, one way or the other).
--
Regards, Joseph V. Morris



R2
R Not
Premium,MVM
join:2000-09-18
Long Beach, CA
kudos:1

I agree completely.

Which begs the next question -- did the creator of backstealth purposefully not attempt test ZA??

Again, I also have no bloody idea, but I am interested only from a security standpoint. If ZA is vulnerable, but the vulnerability is not tested, Zonelabs will have no 'pressure' to 'fix' ZoneAlarm...

I would relish a definitive answer.



gwion
wild colonial boy
Premium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1

reply to Steve

"Can't open process. 5. ERROR"



That was the termination message that appears in the console...

... edit: and consider, too, that the implicit rules issue this has uncovered (again) is another vulnerability altogether. What good purpose do open-ended allow rules serve for the user? I make a practice of preaching to people, look, if you want to run a PC firewall, then do it right and restrict remote endpoints as much as possible... and here, we see the manufacturers putting unloggable, un-overridable implicit rules, and compounding the issues by making the remote endpoint "any remote host, port 80!" Why do I bother? Hell, that's unbelievable. They mean to tell me my firewall can connect to "porn_n_warez.com" as easily as update.kerio.com ? That's a serious problem. What purpose does a non-closable, non-loggable implicit rule serve to begin with? And even if there's an explanation, why... why on earth... make the rule endpoint "ANY" remote host???
[text was edited by author 2002-05-02 17:41:08]



Steve
I know your IP address
Consultant
join:2001-03-10
Yorba Linda, CA
kudos:5

said by gwion:
"Can't open process. 5. ERROR"
"5" is a Win32 error code
code:
C> net helpmsg 5

Access is denied.

No permission to open the process because it clearly couldn't get the debug privilege. It probably also printed the message Failed enabling Debug privilege. Proceeding anyway, right?

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

IGGY
No Guru Just Here To Help
Premium,MVM
join:2001-03-30
Chatham, IL
reply to jvmorris

I did my best to answer this question for you in this thread = »New Stealth Attack Found Against Personal Firewall Where yourself & others asked the same exact question.
"I've sent an email to ZoneLabs on the subject. Waiting for a reply. Hopefully I'll have an answer soon. Speaking of. Just checked my email again. The official word from ZoneLabs on this = "We tested Backstealth ourselves to confirm that we successfully block it. Basically, it attempts to make a Telnet connection to 127.0.0.1 (the NIC, actually) without being recognized by the firewall. ZA and ZAP were designed to prevent just this sort of unauthorized connection." Hope that is of some help."
--
*IGGYZ* *TeamZ*



OzarkMan$

join:2000-12-22
Ozark Mtns.

Click for full size
"""We tested Backstealth ourselves to confirm that we successfully block it. Basically, it attempts to make a Telnet connection to 127.0.0.1 (the NIC, actually) without being recognized by the firewall. ZA and ZAP were designed to prevent just this sort of unauthorized connection." Hope that is of some help.""

Hmmm....as Steve is showing in his initial post, there are five Firewall entries backstealth searches for. While viewing the backstealth.exe file with Robin Keir's Bin Yext 3.0 file text scanner....I notice only five also and no where in the dll or exe does Zone Alarm get mentioned. Having said that I find Zone Labs response perhaps a little mis-leading or PERHAPS I have no clue what I'm talking about and do not see any mention of ZA inside the files due to all the other gibberish.

Found inside backstealth.exe....

BACKSTEALTH Security Test
BACKSTEALTH 1.1 Security Test --- (C) 2002 Paolo Iorio
Search Sygate Personal Firewall Pro ...
#32770
Sygate Personal Firewall Pro
Sygate Personal Firewall Pro PRESENT!
Sygate Personal Firewall Pro not running
Search McAfee Personal Firewall ...
McAfee_FwClientClass
McAfee_FwClientClass
McAfee Personal Firewall PRESENT!
McAfee Personal Firewall not running
Search Tiny Personal Firewall ...#32770
TinyPersonalFirewallMainWindow
Tiny Personal Firewall PRESENT!
Tiny Personal Firewall not running
Search Norton Internet Security 2002 ...
Symantec NAMApp Class
Norton Internet Security 2002 PRESENT!
Norton Internet Security 2002 not running
Search Kerio Personal Firewall ...#32770
KerioPersonalFirewallMainWindow
Kerio Personal Firewall PRESENT!
Kerio Personal Firewall not running
DON'T CLOSE THIS WINDOW!

[text was edited by author 2002-05-02 18:17:15]

NoteAll of the above jpg's were taken with ZAP 3.0 loaded....everything has to ask for permission out and nothing was ever asked of ZAP and no packets attempted to leave.

[text was edited by author 2002-05-02 18:50:14]


Steve
I know your IP address
Consultant
join:2001-03-10
Yorba Linda, CA
kudos:5

I'm working on a reverse-engineered version of backstealth that we can use to test it on any other program we care to. May take a day or two, but we should be able to try it on ZA with only minor effort.

But I'm perfectly clear that it's not even remotely attempting to try ZoneAlarm on its own, and this is from looking at the disassembly and not just from the strings.

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



jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA
reply to IGGY

Iggy,

I appreciated your post. I think what I'm apparently not doing a very good job of explaining is that (while what Zonelabs is saying may well be technically true) it doesn't answer the question I'm asking here (or there, for that matter).

If BackStealth doesn't even attempt to exploit Zone Alarm, well then, rather obviously "...we successfully block it ...".

Steve's analysis is quite specific: Zone Alarm products are not even being probed by the BackStealth vulnerability demonstrator. Under these circumstances, of course they pass!

My concern (and it was better expressed by R2), is that I can't tell if Zone Alarm is susceptible to this vulnerability until it's expressly (and adequately) challenged by an exploit demonstrator similar to BackStealth. That ZoneLabs quotation above rather skillfully fails to answer my question.
--
Regards, Joseph V. Morris



jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA
reply to Steve

Steve,

Thank you. I didn't want to make you feel obligated to try this yourself, but I do appreciate your efforts. Indeed, it sounds like you may well be on the way to producing a more authentic vulnerability demonstrator. (But I'm still not gonna run it myself! )
--
Regards, Joseph V. Morris



OzarkMan$

join:2000-12-22
Ozark Mtns.
reply to Steve

quote:
But in general, it's not in concept looking for "firewall processes" as it is "processes known to be trusted".
There in lies the key for some users....in fact this has been mentioned many times. The day has\will come when NO process SHOULD be Trusted....unless the user explicatelly approves the action at THAT particular moment in time.


jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA

said by OzarkMan:
. . . .There in lies the key for some users....in fact this has been mentioned many times. The day has\will come when NO process SHOULD be Trusted....unless the user explicatelly approves the action at THAT particular moment in time.
Well, you know the old saying (modified by someone or other):
quote:
Life's a beach . . . and then you fry . . . . unless you've got a really good sunblock lotion and have applied it correctly. . . . Unfortunately, you never know until it's too late to make any significant change.
--
Regards, Joseph V. Morris


TekViper

join:2001-07-03
Howell, NJ
reply to Steve

Dunno if this is related or not, but today ZAP asked permission to access the internet. Is this bad or was it just trying to see if there was any update avialable? Does it from time to time.



Steve
I know your IP address
Consultant
join:2001-03-10
Yorba Linda, CA
kudos:5
reply to Steve

I wanted to expand on a couple of points on this whole bit of technology.

First, "DLL Injection" is not new - it's been around for a while and has been used to acquire system-level permissions from processes that are "only" Administrators. pwdump2 is an example of a program that uses this technique (though perhaps not implemented the same way as this one).

What's new here is the application to personal firewalls to "hide" in a process that the firewall trusts. In practice it should be relatively easy for the software firewall vendors to counter this approach by simply adding themselves to the "list" of untrusted applications.

But the deeper problem is this:

If I am able to run my code in the address space of the software firewall, there is simply no hope for them to protect your system.
The technique we see in BackStealth doesn't actually have anything to do with the firewall code per se, it just found a good place to hide.

But what if I know how (say) Tiny stores its internal data in memory, and I am able to go an modify that memory myself? Add programs to the "trusted" list? Disable alerts for a certain kind of traffic that I wish to generate? Quietly disable the firewall entirely?

I is just not possible for the firewall to protect the system if its own memory is being changed out from under it. It very well may be difficult to figure out just how to poke around inside the firewall and muck with the memory, and clearly the vendors can make it difficult, but I believe that the bad guys are gonna win this one.

Steve happily using a hardware firewall
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net

IGGY
No Guru Just Here To Help
Premium,MVM
join:2001-03-30
Chatham, IL

reply to jvmorris

I've fired off another email. With a link to this thread. Maybe ZoneLabs will offer. Some more technical reasoning. To support the information I've previously provided.
My personal thought. Is that maybe the author of the "proof of concept". Was aware that the concept wouldn't work for ZAP. So they didn't code to try & exploit the software. The author fully stated on there site. That the software wouldn't work with ZoneLabs products. Or maybe the author couldn't code to exploit the software. Also wasn't it stated that this "proof of concept" was similar in nature to FireHole? ZAP 3 is no longer susceptible to this. So that could be. Another reason this new "proof of concept". Won't in fact work with the ZAP product. Just thinking out loud. Some or none of this. May in fact have merit.
"The security in ZoneAlarm Pro 3.0 has been hardened further to protect against recently discovered security flaws including vulnerabilities with Microsoft® Windows® XP Universal Plug and Play (UpnP), the well-publicized 'Firehole' issue and email attachment vulnerabilities in Microsoft Outlook®."

--
*IGGYZ*
*TeamZ*

[text was edited by author 2002-05-02 20:40:35]

[text was edited by author 2002-05-02 20:41:32]

[text was edited by author 2002-05-02 20:42:35]