dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
10076
share rss forum feed


Time Out$
Premium
join:2002-04-28
North Myrtle Beach, SC
reply to Steve

Re: Analysis of Backstealth technology

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

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

»Command line for RefUpdate to run automatically?


psloss
Premium
join:2002-02-24
Lebanon, KS
reply to Steve

said by Steve:
My particular testing is on NT 4.0 server
NT 4...SP6a, then? There's a KB article that talks about a CreateRemoteThread handle leak in NT 4, SP6...I don't know if a hotfix was publicly released for this or not:
»support.microsoft.com/default.as···;q246691

That doesn't explain the failure, though; I'm testing on a system using Win2K SP2 (pre-rollup).

Did you get a chance to dump the process token for the Sygate process? By the way, is Sygate architected like Zone Alarm? Zone Alarm employs a driver, a service (actually two, vsmon/minilog), and a GUI process (zonealarm) that run mostly separately. Is Sygate anything like that?

Sorry, another question: have you tried attaching to the Sygate process with your trusty debugger? I'd be curious whether it protects against that.

Thanks,

Philip Sloss


Occasu$

join:2001-07-20
North Vancouver, BC

reply 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
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5

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
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


Occasu$

join:2001-07-20
North Vancouver, BC

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
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5

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
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


Occasu$

join:2001-07-20
North Vancouver, BC

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.
Premium,MVM
join:2001-04-03
Reston, VA
kudos:1

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.
--
Regards, Joseph V. Morris


Occasu$

join:2001-07-20
North Vancouver, BC

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.
Premium,MVM
join:2001-04-03
Reston, VA
kudos:1

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.)
--
Regards, Joseph V. Morris


Feivel1

join:2002-04-11
Baytown, TX

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???
--
Feivel - Feivels ChessWeb


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

Feivel,

Damn! I kept looking at the list and it seemed one short. Thank you.
--
Regards, Joseph V. Morris


number_one

join:2001-11-30
Midlothian, VA
reply to jvmorris

Earlier I said something about a separate list of trusted applications used to authenticate inter-process activity.

Now I have a better idea. First of all, Win9X/ME are utterly helpless in terms of security, so those operating systems are doomed to live out their lives as insecure as a house with no walls. WinNT/2000/XP at least have a basis for security, both in the file system and in the way the OS kernel activates processes with certain user privileges.

However, the current method of security that these operating systems employ for normal application execution is not comprehensive enough. Applications are executed under the permission level of the currently logged-on user, so whatever this user has permissions to do, the application can do (which includes the ability to mess with other processes if the user is an Admin or has 'Debug Programs' rights). Regardless of whether or not you think it is wise for a user to give themselves Admin rights, just using Admin accounts when connected to the internet is not a sufficient solution to this general application permission problem.

What I see as the solution is to have the option to separate out the permissions for certain types of operations from the user group, and instead have them apply to individual executables and DLL files.

In other words, in addition to having a 'Debug Program' permission that allows a particular user to run a program that calls the CreateRemoteThread() function, also give individual executables and DLLs that same permission setting, so that an individual executable or DLL can be individually allowed or disallowed to call that function. A permission to allow calling that function would only be valid if the file was verified through an MD5 or other type of signature, which would stop a virus from gaining rights to call the function by infecting an authenticated executable. This individual file permission level would not only apply to the 'Debug Program' permissions, but to just about every type of permission found in the System Policy Editor.

Using this kind of security system would eliminate one of reasons for not using an Admin account, because even when you are logged on as an Admin, an executable or DLL that tries to hijack another process will fail unless that executable specifically has rights to do it. Unfortunately, this new security model would require an update to the OS, and possibly to the NTFS file system as well, so it isn't something that can be added to current versions of windows unless Microsoft did it in a service pack.


dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
Reviews:
·Verizon FiOS
reply to Steve

One problem with giving privileges to individual files (.exe/.dll) is that there are tens if not hundreds of files in the address space of any given process. You'd somehow need to have access tokens for each piece of the address space, and even then it would be a little tricky because the CreateRemoteThread that counts isn't in badboy.exe, it's in ntdll.dll, which may have been called from kernel32.dll, possibly with indirections through a couple of fixup vectors on the way. (I take it as axiomatic that you don't want every file in the address space to get the access rights of the main .exe?)

Even if you could track down the call reliably to the file that issued it, how do you know the code hasn't been violated? The address space of a process is accessible by the entire process (or at least the user-owned pages are accessinle by all of the process). There is no mechanism which seems like it could be extended to provide this protection.

I think what you seem to need is a structure in which there are several non-overlapping address spaces, which are changed as you pass across a protection boundary. This seems beyond the scope of a service pack!

Or am I missing your point? You seem to have an implementation in mind, but I don't see it.
--
dave



Jamming777$
Time Is Running Out
Premium
join:2001-07-25
USA

ZAP 3.0.118 all ready has a component monitoring aspect that reports any change to a DLLs condition or a request to access outside the computer to the network. It is called component control, whenever I see a series of component request that I don't expect, I always check their properties.
--
Jamming *Team Z Member*

[text was edited by author 2002-05-05 00:10:38]



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

KERIO round 1...

I have posted in the Kerio forum regarding an informal observation I made that the "block all" setting in Kerio can stop the packet stream Kerio is otherwise allowing by an implicit rule allowing outbound access to persfw.exe - I've confirmed that "block all" works, and not just by blocking DNS resolution.

I have also run repeated replications on two separate NT machines that confirm that a "user" group account does not have the necessary privileges for BS to operate, at all. It just terminates harmlessly... this affects the process itself, not the packet stream it generates.

However, run from an account with admin permissions, it executes and terminates normally, the container is filled, and the firewall is bypassed.

Making a rule denying the persfw.exe app access in or out, TCP or UDP, any port or remote host causes the demo to terminate abnormally, but this is a DNS resolution failure. By placing the rule higher in sequence than DNS, it prevents the firewall from contacting the DNS server to resolve the domain name in the test. However, substituting the raw IP address for the domain name results in a completed connection, a filled container and a bypassed firewall.

This proves two things; it proves the firewall can be compromised on the application layer. That's not at all surprising to me. Any packet filter can be, somehow. That isn't the threat it was designed to anticipate. It also proves the firewall has an implicit rule for persfw.exe that does surprise me. It's incredibly broad. It seems to be "allow outbound TCP (udp?) to remote port 80, on ANY remote host from app persfw.exe." That's all I know of, right now.

The more surprsing part, to me, was discovering that a deny rule mapped to persfw.exe and set to log and alert could catch udp DNS packets (remote port 53, udp), and would generate an alert... but will not create a log entry, despite being directed to ... more surprising, though, when it allowed an outbound packet despite an explicit application specific rule blocking it at the top of the ule set (with only LAN above). Nor did the remote port 80 access log ... or alert.

So, roughly:

Round 1: logged in as user: the demo is unable to run at all. Hostname or IP address, the privilege for it to do what it does isn't there.

Round 2: Logged in as admin: the demo runs as designed. Using a hostname, a rule to deny persfw access as detailed when this started stops the packet stream and generates an alert, fails to log, but stops the stream by not allowing it to resolve the name to find the server. If the remote address is entered as a raw IP, it bypasses the rule entirely, the container fills and the app works as though no rule were there. Direct dial. No log entry is made and no alert is given, despite being set to do so.

Round 3: "Stop all traffic" checked: Kerio interdicts the actual packet stream; that is, it filters the packets the way a packet filter should, applies no implicit undocumented hard coded rules to its own app, and blocks both a hostname and a raw IP. Tight as a drum.

That's my report, for now. I'm still tinkering...
--
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


number_one

join:2001-11-30
Midlothian, VA
reply to dave

said by dave:
One problem with giving privileges to individual files (.exe/.dll) is that there are tens if not hundreds of files in the address space of any given process. You'd somehow need to have access tokens for each piece of the address space...
Not necessarily. There is only going to be one executable that initiates any given process. All security levels for calls made to external files would be based on the permissions you have given that initiating executable. So even though the CreateRemoteThread function may be located in a system DLL somewhere, the actual call TO that function does reside in some badboy.exe, or another executable or DLL that it references.

So what happens when a virus infects an executable to which you have given inter-process permissions, or even where a virus infects a DLL that is called by said privileged executable? That is where the file checksum signatures come into place. A verified file is one that a user has checked to make sure its checksum is what it is supposed to be. All system files distributed with windows would be verified by default. So when an executable is run, the OS first checks whether or not the file is verified. If it is not verified, then it runs the executable under the permissions you have set for unverified code. If it is verified, it looks at the user security level and the file security level and takes the lowest level of the two. When an executable calls any unverified piece of code, it could either demote the process to the security level of an unverified file or it could prompt the user as to whether the action should continue with a warning about the unverified code. In the same way that software firewalls have rules, a rule-based system could apply here as well in terms of how to deal with the verification of files and how to work with unverified files.

This is kind of just train-of-thought, so I know it is a little confusing, but I think something like this could be the future of OS security, where security is based not just on user accounts but on the actual code that is running as well. This may well be beyond the bounds of a service pack, but I think this kind of security is going to be necessary as the internet continues to grow and distributed computing takes over. We need something more than an axiom to unplug your ethernet whenever you want to log in as an administrator. I'm sorry, but with viruses and trojans becoming as complex as they are now, just unplugging your internet connection before using Admin accounts isn't going to cut it.


Jamming777$
Time Is Running Out
Premium
join:2001-07-25
USA

reply to Steve

One of the things I like about Trojan Hunter Anti Trojan is it has a Checksum to verify the Rules of the Latest Update built into the program. So what if the Firewall had a built in self test that had the checksum value hidden in its code somewhere would that alert the firewall that someone was inserting a .dll in the process, as it would change the checksum? Or am I missing something here about how checksum works?
--
Jamming *Team Z Member*

[text was edited by author 2002-05-05 15:24:56]



Daniel
Premium,MVM
join:2000-06-26
San Francisco, CA
Reviews:
·webpass.net
reply to gt7697c

BID 3.5 vs. BackStealth...

said by gt7697c:
Steve, has anyone tested BID 3.5 with your modified BackStealth. In the main thread a user reported that BackStealth was shut down completely by BID 3.5, however I don't believe BackStealth was actually targeting BID 3.5.
Well, I have heard that the new version of BlackIce protects you from this but I couldn't find the post and decided to test it myself. Here is what I think.

Firewall applications that are on the list of 'supported' firewalls for BackStealth work by checking the application to see if it is allowed to access the Internet. Fair enough. The key though is that they simply move their operations to the memory space of the 'supported' firewall so that it seems that the firewall is what is trying to access the Internet. Fairly simple concept I think (now that I have read all of the excellent posts here to get up to speed).

Here is where BlackIce is different than the other 'supported' firewalls. It simply throws a prompt when you go to load the application. This is the application that is going to load the thing into the hidden location...but it can't even execute due to the MD5 of that application being unknown. BlackIce works by establishing a baseline of your system, saying in effect that, "This (gesturing), is mine, and anything else is malicious until you tell me otherwise." So in order for a nifty little tool like this to work it at least has to execute, which BID 3.5 won't let it do.

I tried it both ways, first saying that I didn't want it to run and then allowing it to. When I don't allow it run it just kills it and nothing happens. When I did allow it to run it just said that it couldn't find my firewall and told me mine wasn't 'supported'.

I imagine though that it probably would have worked if it was supported (although I don't know that for sure) but the key point is that it wasn't allowed to run in the first place under the new BID.

I am happy with that.
--
"Opportunities multiply as they are seized." - Sun Tzu

dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
Reviews:
·Verizon FiOS
reply to gwion

Re: Analysis of Backstealth technology

said by gwion:
I have also run repeated replications on two separate NT machines that confirm that a "user" group account does not have the necessary privileges for BS to operate, at all
If you need 'debug' privilege for this to work at all, then you can simply remove debug from the admins group rights. Use the security MMC snap-in (secpol.msc). My guess is that you won't break anything (this is not an acceptable workaround for programmers, of course).

However, it might be that you can also get access by normal object protection checks (i.e., the privilege simply allows you to bypass the checks). If this is so, then it all comes down to who owns what process, and since I don't run any of these firewalls, I can't tell you that.
--
dave

dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
Reviews:
·Verizon FiOS
reply to number_one

said by number_one:
I know it is a little confusing, but I think something like this could be the future of OS security, where security is based not just on user accounts but on the actual code that is running as well
Actually, it's the past

(1) VMS could install program images with privileges, and I don't think they invented it (2) I understand the Titan system at Cambridge University in the 1960s had the ability to grant identifiers (i.e., like NT SIDs) to processes based on the program running, which id could then be used in normal ACL-based checks. (3) It's not dissimilar to classical Unix setuid-to-root, though of course it was all-or-nothing in Unix.

I'd be interested to know why Cutler, architect/implementor of VMS and NT, did not see fit to add install-with-privilege to NT.

As a one-time VMS hacker (in the good sense) I do remember that many many system exploits started off by hijacking a trusted program that was installed with privilege. Maybe that's the reason why NT doesn't have it.

I think actually the orthodox NT way is to build the application that needs special access as a system service, and then have the non-priv users talk to the service via RPC mechanisms. That way, you never put the elevated-privilege-using code into an address space owned by the hoi polloi.

I'm open to the possibility that I'm dismissing this on a knee-jerk been-there-done-that basis and missing why it would be possible to do it right in NT.
--
dave