dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
37
KING53
join:2002-01-31
Norcross, GA

KING53 to OzarkMan$

Member

to OzarkMan$

Re: Analysis of Backstealth technology

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]

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

jvmorris

MVM

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.
Yep, and if you'd been running at Medium Security in NIS/NPF, that assessment is precisely what would have allowed the communication to go through with no further notification to the end-user.

If someone's got a good reason why IAMAPP.EXE might need to connect to the Internet (based on their own personal knowledge), I'd sure like to hear it.
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 ).
This is precisely what Steve Friedl, gwion, and others have been warning about (re social engineering). It is incredibly easy for the average end-user to assume that their firewall needs to connect to the Internet; indeed, some of them really do (as currently implemented). Any PSF that needs to connect directly to the internet, for any reason whatsoever, needs to be re-engineered now by the vendor; any other (legitimate) internet communication associated with firewall authentication or updating activities should be handled by a separate, independent application requiring its own PERMIT communications to the specific IP address(es) required to accomplish these functions.
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.
At the moment, SSM, SS, javacool's FileChecker, or Albert's File Change Alarm are about all we've got to work with. But, if I can social engineer you to respond to the pop-up in NIS/NPF or ZA/ZAP, I can also social engineer you to erroneously respond to the pop-ups provided by these utiltities! That's why it's critical that the PSF vendors not only remove any Internet-connection functionality from their main PSF applications (to a separate Application with highly restricted privileges regarding ports and remote IP addresses), but also warn their customers that any subsequent attempt by their main PSF application to connect to the Internet quite likely represents a compromise of the PSF itself. (Okay, I'll hold my breath and wait for that part to happen.)

Feivel1
join:2002-04-11
Baytown, TX

Feivel1

Member

Joseph,
said by jvmorris:
At the moment, SSM, SS, javacool's FileChecker, or Albert's File Change Alarm are about all we've got to work with.
Tsk, tsk, tsk...What about Tiny's Trojan Trap???

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

jvmorris

MVM

Feivel,

Damn! I kept looking at the list and it seemed one short. Thank you.