dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
10236
share rss forum feed


Feivel1

join:2002-04-11
Baytown, TX
reply to jvmorris

Re: Analysis of Backstealth technology

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