 SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | reply to Steve
Re: Analysis of Backstealth technology 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 |
|
 SentinelPremium
join:2001-02-07
Florida
kudos:1 | 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 |
|
SteveI know your IP addressConsultant
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 |
|
SteveI know your IP addressConsultant
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 |
|
 R2R NotPremium,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. |
|
SteveI know your IP addressConsultant
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 |
|
R2R NotPremium,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. |
|
 jvmorrisI 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 |
|
R2R NotPremium,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. |
|
IGGYNo Guru Just Here To HelpPremium,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* |
|
| """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] |
|
SteveI know your IP addressConsultant
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 |
|
jvmorrisI 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 |
|
jvmorrisI 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 |
|
IGGYNo Guru Just Here To HelpPremium,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] |
|
|
|
R2R NotPremium,MVM
join:2000-09-18
Long Beach, CA
kudos:1
| IGGY - I agree with your assessment -- I just don't know and I am therefore skeptical.
I was hoping there would be a source other than the program's author and other than ZoneLabs that could state conclusively that ZA is not vulnerable.
Let us assume that ZAP 3.0 is patched and fixed. There are a lot of users who use ZA (free) and ZAP 2.6 -- and it would be nice to test these as well. But since the program specifically does not try to test them, I have to wonder why. Just having ZoneLabs say that ZA is "safe" is simply not that satisfying of an answer...
[text was edited by author 2002-05-02 20:52:38] |
|
IGGYNo Guru Just Here To HelpPremium,MVM
join:2001-03-30
Chatham, IL | I agree with your points. And it is nice to have double ( or even triple ) confirmation. Your point about ZoneAlarm ( free version ) is another good point to consider. If ZoneLabs is willing to provide more info. This may answer some of these questions more fully. I for 1. Am glad to see a "debate" on the subject. If just for the fact. That it increases the learning experience. For some of us.
--
*IGGYZ* *TeamZ* |
|
IGGYNo Guru Just Here To HelpPremium,MVM
join:2001-03-30
Chatham, IL
| Further reply from Zonelabs = "Backstealth is not a complicated program and there actually isn't much else I can say about it. Sorry!  We block it because we block untrusted communication with the NIC." And I have tested this on ZAP 3. And I clearly posted my results in another thread. If for some reason. The way I tested isn't up to standard. Or someone has other ways to test. I'd be more than happy to do so. But from my testing. The software engineers at ZoneLabs are correct. This proof of concept is a dud. I've tested this on ZAP 3. I've not tested this on ZA Free. But have sent an email reply to Corey. Asking for confirmation. That all current versions of ZoneLabs products are immune to this.
--
*IGGYZ*
*TeamZ*
[text was edited by author 2002-05-04 01:41:27] |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | said by IGGY:
Further reply from Zonelabs = "Backstealth is not a complicated program and there actually isn't much else I can say about it. Sorry! We block it because we block untrusted communication with the NIC."
It's not clear that ZoneAlarm is entirely immune from this (still researching), but I'll ask this question of the group: of most of you saw a popup from ZoneAlarm saying that the firewall itself wanted to talk to the internet, would you allow it?
Steve yes, this is a hint
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net |
|
IGGYNo Guru Just Here To HelpPremium,MVM
join:2001-03-30
Chatham, IL
| Considering I have mine set for manual update. I would definitely not allow the firewall to connect. And would do further investigation as to why it wants to connect. As you & others have stated. The whole point of this. Is to be aware of what is on your machine. And what you have downloaded. If you don't run this exe. There isn't a chance of your pc being compromised. But couldn't someone create an automated exploit? Similar to the behavior of say Klez? I'm thinking out loud again. My point may not be valid. But it seems. That we're seeing newer exploits. Where the user doesn't have to do much. For the exploit to in fact run & cause harm.
--
*IGGYZ*
*TeamZ*
[text was edited by author 2002-05-04 01:50:50] |
|
