dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
109
IGGY9
No Guru Just Here To Help
Premium Member
join:2001-03-30
Chatham, IL

IGGY9 to jvmorris

Premium Member

to jvmorris

Re: Analysis of Backstealth technology

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

OzarkMan$
join:2000-12-22
Ozark Mtns.

OzarkMan$

Member

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

join:2001-03-10
Tustin, CA

Steve

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

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

jvmorris to IGGY9

MVM

to IGGY9
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.
jvmorris

jvmorris to Steve

MVM

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! )
IGGY9
No Guru Just Here To Help
Premium Member
join:2001-03-30
Chatham, IL

IGGY9 to jvmorris

Premium Member

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®."

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

R2

MVM

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]
IGGY9
No Guru Just Here To Help
Premium Member
join:2001-03-30
Chatham, IL

IGGY9

Premium Member

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

IGGY9

Premium Member

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.

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve

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
IGGY9
No Guru Just Here To Help
Premium Member
join:2001-03-30
Chatham, IL

IGGY9

Premium Member

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.

CrazyM
Premium Member
join:2001-05-16
BC Canada

CrazyM to Steve

Premium Member

to Steve
said by Steve:
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?

For those firewalls that use the same .exe to perform any live update function (something that would be considered a normal function of that .exe), it would definitely add to the likelihood of someone allowing it. Either by already having an allow rule, or permitting it that one time if they assumed it was just checking for updates.

CrazyM
KING53
join:2002-01-31
Norcross, GA

KING53

Member

A few things here...

1. ZA is coming up as immune because it isn't in the code to look for it, so of course the exploit won't work.

That said....Iggy or anyone else believing ZA immune(ZAP too) are you testing with a modified backstealth by Steve which will look for ZA/ZAP? If not then you are just getting false results. If the code doesn't know ZA exists (which is really why it is passing) then of course it won't penetrate ZA. When testing your security programs you have to make sure your control environment is proper so as not to just get false results which will create false sense of security which is worse than running no security programs at all IMHO.

Why ZA/ZAP is not in the code still puzzles me. Look how quickly Steve picked this simple code apart. To me, the author intentionally left certain firewalls out. So what if ZA/ZAP is immune? What is the harm in putting it in the code anyway so everyone can see it is immune for themselves?

2. In response to how this thing can be handled because ANY program in the OS can be targeted by this exploit....

I like the way Sygate works. Many down DLL authentication and the general way Sygate operates. Guess it is just too thorough and too much information for some people. DLL authentication isn't perfected yet, but AFAIK if Backstealth didn't target smc.exe then it would be stopped by Sygate still. Sygate uses MD5 and every other type of security measure to insure program and connection integrity. Hopefully they can perfect these techniques to be extremely hard to exploit.

3. So Steve, would you make a Backstealth and put IE, ZA, ZAP in it? This would not only test ZA/ZAP but also lead into my next point and teach people a lesson....

4. NEVER ALLOW ANY PROGRAM, NEVER TRUST ANY PROGRAM! I'm sure most follow this already, but I know much more are lazy so they just allow IE or their email client or whatever full access. If your firewall can't be tightened down to only allow a program client or server access, ICMP or not, restrict it to IP's, restrict ports and protocols, then it is lacking in security. Just allowing or blocking programs is obsolete...we have to be able to control what they do once they are out to the net and back in to our systems now. This should be a standard for ALL firewalls.

5. Auto updates = security hole, sad but true. Manual is the way to go. Automate nothing, if you are compromised and are otherwise improperly secured inbound and outbound then something can ride your automated updates in and out. This goes again to restricting programs to only the ports, protocols, and IP they need.

It is unreasonable to restrict your browser by IP's, putting them in one at a time, so make sure you never allow them full access since EVERYONE has a browser 90% using IE which is the most insecure program on earth, then the bad guys have an easy time just by targeting M$ products. Last point...

6. System security can be strengthened just by not using M$ products. Sure you are stuck with the OS, tweak it to make it work for you and not the other way around.
- Get rid of OE/OL M$ office and M$ anything else, there are alternatives...most of them free
- Don't use IE! You would be surprised how many exploits are IE specific, so what do I do? IE on my system can't act as server or client, and when I do use it, I like the sport and dport with the only IP I go to windowsupdate since Opera can't do that thanks to RadioactiveX.

These are just some of my opinions...sorry for being so lengthy just a lot to comment on around here. Hopefully some of this babble makes sense to someone...

OzarkMan$
join:2000-12-22
Ozark Mtns.

OzarkMan$ to Steve

Member

to Steve
quote:
It's not clear that ZoneAlarm is entirely immune from this
It is very clear for at least one user of ZAP 3.0 as posted earlier here that Zone Labs is not mentioned neither in the string values OR from looking at the disassembly.
KING53
join:2002-01-31
Norcross, GA

KING53

Member

said by OzarkMan:
quote:
It's not clear that ZoneAlarm is entirely immune from this
It is very clear for at least one user of ZAP 3.0 as posted earlier here that Zone Labs is not mentioned neither in the string values OR from looking at the disassembly.
Exactly,

It is like having a test on which sneaker is most durable but not including Nike sneakers in the test. When asked, Nike replies that "are sneakers aren't vulnerable to wearing down due to our recent feature X which will stop this." Take their word for it if you will, it just sounds like blah blah to me. I need someone who speaks English to verify in order for me to believe. ZoneLabs speaks $$, the international language of the commercial world.

Food for thought: If your sneaker was invulnerable to wearing down or in this case your firewall invulnerable to an exploit, what reason would you have for not providing proof of this? Wouldn't that be a good thing to show your users, or should they take your word for it?

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

R2

MVM

KING - I agree completely with your assessment and your suspicions about ZoneAlarm. WHY was it left off the list? Saying that it was left off "because we know it is not vulnerable" just isn't good enough. If it is not vulnerable, THEN LET US TEST IT AND LET US PROVE IT! Otherwise this is questionable behavior.

It would be like running a PortProbe at GRC and getting a report back saying "since you have ZoneAlarm installed we did not check your ports -- we know it will pass". That just isn't a response most people would be satisfied with.

Steve seems to have the right idea and hopefully we will have more solid data soon.
_______________________________________________________

Now, the concept of MD5 checking has been brought up. I believe that ZoneAlarm does MD5 checksum verification on all programs trying to reach the Internet, correct? I am still not clear on some issues, simply because of my ignorance:
  1. Does ZA/ZAP check the MD5 value each and every time a program accesses the Internet? Does that include after the program has established a connection? Is this a one time event or an active, on-going process?
  2. If ZA/ZAP checks the MD5 value at least before each connection attempt, doesn't that make allowing access to certain "high use" programs like IE and OE 'less insecure'?
  3. Am I being duped into believing that MD5 is good way to verify file integrity? Are other checksum values needed as well? One would think that a dual checksum system would be extremely hard to beat...
  4. I am definitely not clear on "injecting into" or "highjacking the process space" -- it is over my head. I get the general idea, but the exact mechanisms and implications exceed my cerebral capacity. (So forgive my questions in this area.) Is there any way to run a "checksum" or other verification test for the process space? (I would think not -- isn't the process space a 'dynamic entity'?) Is there any other mechanism to secure the process space??
  5. The concept of a "File Integrity Verification" program is very intriguing. Perhaps I need to create a new thread on this, but are people using these regularly?
I think I better stop here. Thanks.

Time Out$
Premium Member
join:2002-04-28
North Myrtle Beach, SC

Time Out$ to KING53

Premium Member

to KING53
Said by King:

"Why ZA/ZAP is not in the code still puzzles me. Look how quickly Steve picked this simple code apart. To me, the author intentionally left certain firewalls out. So what if ZA/ZAP is immune? What is the harm in putting it in the code anyway so everyone can see it is immune for themselves?"

Just a general comment- I still do not know where many of you really want to take this Backstealth Utility????

Some seem to want a "proof of concept" angle proggie so they can run a test on their own system for the flavor of firewall they happen to have installed..so they can say Yea or Nay.

Others seem to want to modify the "code" so that it really CAN do the dirty deed not only on their firewall..but also the other guys choice of product..while even others want to show that ALL firewalls can be hacked and this is a "technology" that is going to become a household word and the death of any firewall.

This is software we are talking about..you want some "code" that will defeat your "software" firewall from the inside, send the same code to all your friend or dump it on a website for anyone else to get infected..then 10 minutes later disables your system completely to the point it wipes out all your files, and your ability to even reinstall your OS again...it IS Available. Trust me.

The "hit and run" concept has safeguards and stop gaps all over the backbone but...not on your system. You are in control...you take the first action.

So I do understand this "what if scenario"... I even support those who what to show you just "how" it can be done. And if they do not get it right the first time they can go write some more code..modify it to make it "generic" enough that 90 percent can not claim that it will not affect them.

But all of this is about software firewalls that have to use the same hardware and share some of the same "spaces" your OS resides in the first place.

The concept of software firewalls has come a long ways in the last 5 years...but it has reached it peak...not much more can be done in any layered approach.

My point here is...many people run systems without a software firewall..seems like some have been "embarrassed" into not having one now days ... if you do not have one your system is not 100 percent secure...Hogwash.

Most of them are a pain in the butt...most users do not have a clue how they work or how to set they up..much less maintain them or understand the difference in the various flavor of software firewall operations on how they are protecting their OS.

I see many old timers now going back to traps and sandboxes. There are other technologies out that keep the problems away from the heart of your system in layered approaches..I think that is going to be the trend...just as I see the trend to ALL in one products that are AV/AT/Firewall combos still classed as "software" you can get from your local computer store in a box with a CD inside.They then will have to give it a new Name.

And then keep it updated..pay the yearly fee for the service..hope there are enough download sites to keep everyone happy and hope it all snuggles down nicely after the correction are implemented.

I certainly would like to see that happen..cause then you all would have one author,programming group, company...responsible for all three.

Right now we have AT's calling AV's a trojan...AV's calling AT's a virus or a worm...and firewalls trying to figure out if they should let the AT's and AV's just go ahead and kill off each other...or let you go out and enjoy the Internet.

I would send you all an Advertisement on this new "all-in-one" PRODUCT..but I do not think most of you would ever receive it...with Adaware, popper stoppers, and filters out there..this kind of product will never get through until the Security software Houses buy up each other and decided it is just too expensive to keep up the design of three different software products.
jroc9
join:2002-05-04
Lawton, OK

jroc9 to KING53

Member

to KING53
This Was Found About Zone Alarm

"On a side note, it might interest you to know that our research department has uncovered the real reason Zonealarm is "not vulnerable" to Backstealth. This is because the Zonealarm program is not even referenced within the Backstealth code. Our internal testing with the modified Backstealth tool confirms that Zonealarm is indeed vulnerable to the same type of proof of concept vulnerability."
Read the article at »www.neowin.net

Sygate Pro 5.0 (True Firewall)
Jrb2
Premium Member
join:2001-08-31

Jrb2 to R2

Premium Member

to R2
Hi R2,

First of all: maybe it wasn't such a good idea from me to post my previous posting in this thread and that I should have posted it in the other thread; if I did wrong, sorry!

Maybe indeed a new thread should be started about this; so please WCB or other moderators: feel free to move my postings.
Yes, I am using what I call integrity-checkers:
NISFileCheck, ADinf32, CRC32-feature in TDS-3.
In case you would like to read more about NISFileCheck (and FileChecker from Javacool), see the Wilders-forum where are special sections for them (I hope I'm allowed to post the link here):
http://www.security-pro.co.uk/yabb/YaBB.pl

MD5 is a good HASH, but not the best; it has been "cracked" in some way (and certainly CRC32 has been "cracked").

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

R2

MVM

I could be wrong, but I don't believe Steve would mind you posting this information in his thread -- as long as it does not hijack the whole thing. I think I will start a new thread on file integrity programs -- for my own educational benefit if nothing else.

I will restate one question real quick: If one HASH is not enough, should firewalls use two HASHs/checksums to verify file integrity? If different firewalls used different HASHs, wouldn't that make it harder for any given trojan to be successful in a global sense?

Thanks.

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve to jroc9

to jroc9
said by www.neowin.net:
"On a side note, it might interest you to know that our research department has uncovered the real reason Zonealarm is "not vulnerable" to Backstealth. This is because the Zonealarm program is not even referenced within the Backstealth code. Our internal testing with the modified Backstealth tool confirms that Zonealarm is indeed vulnerable to the same type of proof of concept vulnerability."
Ok, since this info is out there, I guess we can spill the beans. This is only partly true, and it's not really the right question to ask "Is ZoneAlarm vulnerable?" even though people will just insist on a "yes" or "no" answer.

Let's ask some more specific questions:
  • "Is ZoneAlarm vulnerable to backstealth.exe" - NO. The author chose not to include the tests for ZA, so it's never tried by the program.

  • "Is ZoneAlarm vulnerable to DLL injection where the bad guy can run code in ZA's address space?" - YES. We can run any injected code just fine.

  • "When the injected DLL tries to talk to the internet, is it detected?" - YES. ZoneAlarm pops up a box asking if you want to allow ZoneAlarm itself to talk to the internet (see attached image), just as it was designed to do. In this respect, ZA is doing its job.

  • "In practice, will people normally allow their firewall to do this?" - Probably YES. Since there is no real clue which real application is trying to talk to the internet, people will just trust their firewalls and be done with it.
So I would say that ZoneAlarm is not really "vulnerable" any more than the other guys, but when it's the firewall asking for permission to talk to the internet, that's almost a social engineering problem: get the user to answer a misleading question.

I need to make it clear that being vulnerable to DLL injection is not a fault of the firewall software or indicative of sloppy coding on their part. The CreateRemoteThread() Win32 call is used by debuggers for software testing and the like, and it requires substantial privilges to run (Administrator, at least).

The firewall vendors will make the case -- and I completely agree -- that if administrators are running untrusted software, it's not really fair to ask for a program running at that same privilege to protect them from themselves.

So in this respect, BackStealth is not really any BFD even though it's technically interesting: the game was over the minute that the user ran untrusted code as admin no matter what the firewall does.

Steve
Steve

Steve

When I clicked on the "More Info" link, it opens a web browser to the ZA web site: see it here. The requesting URL obviously encodes the name of the program requesting access, so this is included in the help message.

I was amused by the first question

Steve

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

jvmorris to R2

MVM

to R2
said by R2:
. . . .Now, the concept of MD5 checking has been brought up. I believe that ZoneAlarm does MD5 checksum verification on all programs trying to reach the Internet, correct? . . . .
Yes, indeed almost all of the major PSFs currently do some sort of hash authentication, at least of the primary executable as stored on disk. (Unfortunately, we aren't talking about a modification of the disk image of the PSF -- or any other executable, for that matter; we're talking about in-memory (RAM) modification of the image. And that image changes almost continuously as internal data buffers in the executable code space are modified during the course of its execution.)
Some are now going a bit further. I thing Sygate 5.0x (and possibly ZAP 3.0?) are now authenticating the called .DLL files.
Unfortunately, I haven't seen any PSF that also yet checks any *.vxd, *.ocx, or *.sys files called by the main executable (or even by the *.dll files called directly).
But, ultimately, it doesn't make any difference in this particularly vulnerability. None of the files being called have had their disk image modified; consequently, all of these files will 'pass' authentication. (If I've misunderstood what Steve and gwion have been saying, I trust one of them will correct the above statement.)
quote:
... Am I being duped into believing that MD5 is good way to verify file integrity? Are other checksum values needed as well? ...
Inasmuch as I feel a certain responsibility for possibly raising that issue in your mind, I rather feel obligated to respond to it. No, you're not being 'duped'. MD5 is a 'good' way to authenticate file integrity. Yes, it's breakable; that's been documented since about 1996. But, it's not an easy thing to do (especially while maintaining other executable file properties). SHA1 (or RIPEMD160 or HAVAL or RIPEMD256 or RIPEMD320) are, I think indisputably "more robust" -- but they, too, can (and eventually will) be compromised. That's really what you need to understand. Microsoft (and subsequently Symantec) simply went to SHA1 because it's more robust than MD5, not because it's ultimately uncrackable.
quote:
...I am definitely not clear on "injecting into" or "highjacking the process space" -- it is over my head. . . .
I could take a crack at responding to that one, but I think there are others here far more knowledgeable on this subject than I and who, consequently, are far less likely to explain it in a misleading way.
quote:
. . . The concept of a "File Integrity Verification" program is very intriguing. Perhaps I need to create a new thread on this, but are people using these regularly?I think I better stop here. Thanks.
File Integrity Checking (or File Authentication) is simply one more layer of computer security -- just like running AV, AT, or Registry Monitoring software in addition to a PSF or a hardware firewall or a router. Anyone who tells you that any product (in any of these categories) is the end-all, be-all of computer security should be summarily executed at dawn tomorrow, in my humble opinion.

Occasu$
join:2001-07-20
North Vancouver, BC

Occasu$ to Steve

Member

to Steve
 
When you tested zonealarm and it came up with the popup, did anything like this happen?

I use NPF 2002 and it came up with a warning that IAMAPP.EXE wanted to connect to the internet. I chose block, but as you can see backstealth still claims to have connected to the internet and downloaded the text file. Where is the text file saved to? It says the file is saved to C\:retrieve.dat. I am confused (sorry if this has been answered already), is the file saved to disk retrieve.dat, or is it a .txt file that is save to the .dat?

Again i must apologize if this has been covered. I haven't been online for a week and as of late last night when i discovered these have been trying to read and catch up on these threads (zhen Xjells and yours). There is a lot of technical stuff that goes way over my head .
[text was edited by author 2002-05-04 18:54:49]

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve

said by Occasu:
Where is the text file saved to? It says the file is saved to C\:retrieve.dat.
BackStealth can't strictly be sure that it has penetrated the firewall, it only detects gross blockage. Look in the root directory of all your hard drives (C:, D:, etc.) and see if you can see \RETRIEVE.DAT. If you don't see this file, it didn't get through: my guess is that it didn't.

Steve

Occasu$
join:2001-07-20
North Vancouver, BC

Occasu$

Member

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.

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve

said by Occasu:
I do have a file on my C: called retrieve.dat,
Is the file empty, or not? Empty file means failure.

Steve

Occasu$
join:2001-07-20
North Vancouver, BC

Occasu$

Member

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]

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

jvmorris

MVM

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
Well, let me respond to this, because you're pushing Steve a bit beyond his current researches.

According to prior posts by GT7697, if you're running one of the more recent versions of NIS/NPF (like 3.0x/4.0x) on HIGH Security and with Automatic Firewall Rule Creation DISABLED, you'll see exactly what you've reported.

Under normal circumstances, there is absolutely no reason why IAMAPP.EXE should be PERMITTED to access the Internet In other words, you made exactly the right choice.

Still, there is a flaw in the current publicly available Backstealth demonstration which will indicate that it has penetrated your NIS/NPF firewall -- even though it really hasn't. This flaw is similar to that which gwion has previously documented for TPF/KPF, but it seems it has somewhat different implications for NIS/NPF (and probably for AtGuard).

However If you had been running a recent version of NIS/NPF on Medium Security and/or with Automatic Firewall Rule Creation ENABLED, then it is quite likely that BackStealth would have succeeded (for real, by which I mean the receive.dat file would be a bit more than 0 bytes). And you would have seen no warning or other notification. In Medium Security, NIS/NPF does, indeed, trust itself and would not have asked for permission to connect; it would simply have done so. NIS/NPF users need to set security to HIGH and DISABLE Automatic Firewall Rule Creation to avoid this vulnerability. I think I've been recommending this for about two years now.

However, (don't you love all my 'howevers'? ) there is a more fundamental vulnerability associated with BackStealth which (as I understand it) NIS/NPF is not yet capable of handling. As I understand it, Symantec is aware of the more fundamental problem and is already in the process of addressing it.

Occasu$
join:2001-07-20
North Vancouver, BC

Occasu$

Member

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]