I found a security hole in AppDefend.

[[suave]]

Jason,

I was playing around with the trial and I found a small security hole.

Since I don't like to be bothered with prompts when applications execute, I have the default for "Execution" set to "Allow", and everything else set to "Ask"

Now, lets use internet explorer for this example.

C:\Program Files\Internet Explorer\iexplore.exe

This file has custom permissions that I set for it in AppDefend. Such as, allow network access, allow global hooks, and some other things.

Now, when a trojan or some sort of virus replaces iexplore.exe with a simple renamed version of itself, it now has access to all the permissions I set for the original iexplore.exe.

To reproduce this, follow the steps here:

1) Set the default for Execution to allow.
2) Give certain permissions like Network Access to iexplore.exe
3) Replace iexplore.exe with some other application that accesses the internet (like your email client or another browser) and rename it to iexplore.exe.
4) Launch your "new" iexplore.exe and see how AppDefend just lets it access the internet, as if it were the real iexplore.exe.

I'm replacing iexplore.exe with an email client in my test, which is kind of harmless. But this also means that it can be replaced by a virus or even modified by a trojan or some malicious coding.

[TheQuest]

Hi, [suave]

-{ Quote: "Launch your "new" iexplore.exe and see how AppDefend just lets it access the internet, as if it were the real iexplore.exe" }-
Interesting, did you try running a checksum on your app[s] before you renamed and ran it?

Take Care,
TheQuest 8)

[[suave]]

-{ Quote: "Hi, [suave]


Interesting, did you try running a checksum on your app[s] before you renamed and ran it?

Take Care,
TheQuest 8)" }-

Would a trojan run a checksum on my apps before it renames itself and runs? ;)

[tonyjl]

-{ Quote: "']Would a trojan run a checksum on my apps before it renames itself and runs? ;)" }-

Don't forget that this is only a beta version::) ,but a good point none the less. I'm sure Jason will sort out AD to consult the checksums ready for the final release.;)

[nick s]

Hi [suave],

In your tests with iexplore.exe, have you disabled Windows File Protection? It is not normally possible to replace/rename iexplore.exe. WPF restores the correct iexplore.exe within a few seconds. In any case, when I swapped and executed a renamed notepad.exe for my e-mail client (which is allowed to execute and have network access), AD alerted to the hash mismatch as expected.

Nick

[[suave]]

-{ Quote: "Hi [suave],

In your tests with iexplore.exe, have you disabled Windows File Protection? It is not normally possible to replace/rename iexplore.exe. WPF restores the correct iexplore.exe within a few seconds. In any case, when I swapped and executed a renamed notepad.exe for my e-mail client (which is allowed to execute and have network access), AD alerted to the hash mismatch as expected.

Nick" }-

nick s, you didn't follow all the steps in my description on how to reproduce this.

follow all 4 steps and you will see how easy it is for a trojan to take over the permissions set for any app in your list.

This is because the hash check only happens on the process exectution and not during any other protection like network access and the rest.

Im not an expert in this field of security, so maybe Jason knows a better more secure way to fix this small issue, but I have come up with some ways to fix it.

1) AD should check the hash of each application in its list and notify us of any modification (Even though "allow execution" is set as default)

or

2) AD should check the hash of each application not only on execution, but also on network access and the rest of the other protections.

or

3) AD should build its own hash list as you run apps for the first time, and even though they aren't on your list with custom protections, it should notify us of any modifications on previously runned apps wether they are on the list or not.

I don't know which method would be best, and there is possibly a better way. I don't know.

Anyways, lets not jump the gun here. Lets wait and see what Jason says.

[tonyjl]

Mine detected the modification :) ,you sure you had AD active?

[[suave]]

-{ Quote: "Mine detected the modification :) ,you sure you had AD active?" }-

tony, are you sure you didn't skip step 1, listed in my first post of this topic???

please follow all the steps and then let me know what happens.

I'm gonna try it again now as well.

[[suave]]

Ok I have figured out that in order to reproduce this you must do the following:

Lets say you are replacing firefox.exe.

1) Set the default for Execution to allow.
2) If firefox.exe is already in your AD list, make sure the "Execution" setting for it is set to "Default"

and there you go. Now any file renamed to firefox.exe in C:\Program Files\Mozilla Firefox\ will take over the AD rules set for firefox as if it is the real firefox.

It sounds confusing but its not. I just suck at explaining myself ;)

[nick s]

Hi [suave],

The wording of your first step should then be "1) Set the .Default profile for Execution to allow". But by doing so, you have not only disabled hash checking for existing apps, but also execution protection globally for any new and potentially malicious app.

Nick

[[suave]]

-{ Quote: "Hi [suave],

The wording of your first step should then be "1) Set the .Default profile for Execution to allow". But by doing so, you have not only disabled hash checking for existing apps, but also execution protection globally for any new and potentially malicious app.

Nick" }-

Yep exactly :D

So my whole point is that setting the .Default profile for Execution to allow should NOT disable hash checking for existing apps.

Because you see, i like to use my computer in a non restrictive way. I hate getting prompted for every new app I execute asking me if I am sure I want to execute it. Obviously if I executed it then I wanted to.

So I allow executions (as long as I am the executer). Which, as it is right now, leaves me with this security hole in AD. :lurking:

[TheQuest]

Hi, [suave]

-{ Quote: "Would a trojan run a checksum on my apps before it renames itself and runs? ;) " }-
What ever

-{ Quote: "I found a small security hole." }-
Not that small, if not protecting.

Take Care
TheQuest 8)

[nick s]

-{ Quote: "']Yep exactly :D

So my whole point is that setting the .Default profile for Execution to allow should NOT disable hash checking for existing apps.

Because you see, i like to use my computer in a non restrictive way. I hate getting prompted for every new app I execute asking me if I am sure I want to execute it. Obviously if I executed it then I wanted to.

So I allow executions (as long as I am the executer). Which, as it is right now, leaves me with this security hole in AD. :lurking:" }-Hi [suave],

Yeah, I prefer the more restrictive route ;). Still curious though about the state of your Windows File Protection.

Nick

[[suave]]

-{ Quote: "...Still curious though about the state of your Windows File Protection..." }-

Oh yeah, that crap is disabled.

You gotta understand, with me and my computer, everything is tweaked to the bare minimum.

I also use nlite to strip all the crap that comes bundled with windows right off the installation cd so it never installs in the first place. Then i slipstream all the windows updates right onto the install cd so I don't need to install them later. Then I install windows and tweak my computer to death. All the services are disabled except for the bare minimum required for my needs.

And I'm real picky about what I install. Only ghost security apps are allowed (though I do wish AD was a standalone app) :D

Right when i've got my PC the way I want, I defrag, then install Deep Freeze. So nothing gets through and my PC is back to optimal state as soon as I reboot.

My only concern really is outbound internet control.

But lets not get off topic here. I am still awaiting Jason's reply.

;D ;D ;D

[nick s]

-{ Quote: "']Oh yeah, that crap is disabled.

You gotta understand, with me and my computer, everything is tweaked to the bare minimum.

I also use nlite to strip all the crap that comes bundled with windows right off the installation cd so it never installs in the first place. Then i slipstream all the windows updates right onto the install cd so I don't need to install them later. Then I install windows and tweak my computer to death. All the services are disabled except for the bare minimum required for my needs.

And I'm real picky about what I install. Only ghost security apps are allowed (though I do wish AD was a standalone app) :D

Right when i've got my PC the way I want, I defrag, then install Deep Freeze. So nothing gets through and my PC is back to optimal state as soon as I reboot.

My only concern really is outbound internet control.

;D ;D ;D" }-Interesting approach...glad it works for you :). Anyway, Jason is already aware of the need for some hash-check tweaking...http://www.wilderssecurity.com/showpost.php?p=621794&postcount=6.

Nick

[f3x]

On a not so different topic ... regdefend + app defend have another security hole. I admit this have not many chances to happen as GSS is not a mainstream software but it should still be fixed.

Let's say a program want to bypass GSS, it can easily be done using:

Step1:

the program insert those values to registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Ghost Security\GhostSecuritySuite]
"RD_Ruleset"="<DISABLED>"
"MD_Ruleset"="<DISABLED>"
"AD_Ruleset"="<DISABLED>"
"TrialDate_3"=dword:00000000
"RDRegname"="null"
"RDRegemail"="null"
"RDRegkey"="null"
"ADRegname"="null"
"ADRegemail"="null"
"ADRegkey"="null"

Step 2:
the program create a shortcut to self in the starup folder
or any otehr mean of autostart not guarded by regdefend

Step 3:
Crash / force reboot



Now you have a completely non working GSS in your system tray (disabled + free mode) and a program who is now autostarted and is free to terminate gss.exe, uninstall gss driver, install his own rootkit / access the net etc...


quickfix would be to monitor those key with regdefend by default with a special application rule for gss.exe

better fix would be not to rel on registry to decide if the computer is protected or not

[tonyjl]

-{ Quote: "On a not so different topic ... regdefend + app defend have another security hole. I admit this have not many chances to happen as GSS is not a mainstream software but it should still be fixed.

Let's say a program want to bypass GSS, it can easily be done using:

Step1:

the program insert those values to registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Ghost Security\GhostSecuritySuite]
"RD_Ruleset"="<DISABLED>"
"MD_Ruleset"="<DISABLED>"
"AD_Ruleset"="<DISABLED>"
"TrialDate_3"=dword:00000000
"RDRegname"="null"
"RDRegemail"="null"
"RDRegkey"="null"
"ADRegname"="null"
"ADRegemail"="null"
"ADRegkey"="null"

Step 2:
the program create a shortcut to self in the starup folder
or any otehr mean of autostart not guarded by regdefend

Step 3:
Crash / force reboot



Now you have a completely non working GSS in your system tray (disabled + free mode) and a program who is now autostarted and is free to terminate gss.exe, uninstall gss driver, install his own rootkit / access the net etc...


quickfix would be to monitor those key with regdefend by default with a special application rule for gss.exe

better fix would be not to rel on registry to decide if the computer is protected or not" }-


Just add your own rules to protect those key/values ::) You don't have to rely on Jason to create the rules,as he has think of people who don't really know anything about the registry etc. That's whats so good about his appz,you can set them as basic OR as advanced as YOU want. ;D

[f3x]

I did fix the issue mylself but i still feel like it's something worth adding as a default security layer.

A program that is supposed to protect registry should be able to protect itself, especialy if it's only a matter of adding a default rule

Anywais.. on a completely different note.. anyone notice how the "alert" icon next to the log look like the one on diamondcs mainpage, only flipped 180 degree ?

[Jason_R0]

-{ Quote: "']Jason,

I was playing around with the trial and I found a small security hole.

Since I don't like to be bothered with prompts when applications execute, I have the default for "Execution" set to "Allow", and everything else set to "Ask"

Now, lets use internet explorer for this example.

C:\Program Files\Internet Explorer\iexplore.exe

This file has custom permissions that I set for it in AppDefend. Such as, allow network access, allow global hooks, and some other things.

Now, when a trojan or some sort of virus replaces iexplore.exe with a simple renamed version of itself, it now has access to all the permissions I set for the original iexplore.exe.

To reproduce this, follow the steps here:

1) Set the default for Execution to allow.
2) Give certain permissions like Network Access to iexplore.exe
3) Replace iexplore.exe with some other application that accesses the internet (like your email client or another browser) and rename it to iexplore.exe.
4) Launch your "new" iexplore.exe and see how AppDefend just lets it access the internet, as if it were the real iexplore.exe.

I'm replacing iexplore.exe with an email client in my test, which is kind of harmless. But this also means that it can be replaced by a virus or even modified by a trojan or some malicious coding." }-

Hi [Suave],

As has been mentioned, the .DEFAULT rule allows you to switch off checking the "Execution" of applications. The reason I designed AppDefend like this is so that end-users could enable/disable any particular part they didn't feel they need. AppDefend is totally configurable in this manner.

[[suave]]

-{ Quote: "Hi [Suave],

As has been mentioned, the .DEFAULT rule allows you to switch off checking the "Execution" of applications. The reason I designed AppDefend like this is so that end-users could enable/disable any particular part they didn't feel they need. AppDefend is totally configurable in this manner." }-

I understand that. But don't you think the applications in AppDefends list (which have special permissions) should be checked for validity on start wether execution protection is enabled or not?

This is clearly a hole. Someone who doesn't want to be prompted at each execution will be vulnerable to the most basic leaktest in the book. :-\

I love being able to configure AppDefend in the way I want, like you said. But the way I want is obviously not a wise choice.

[Jason_R0]

-{ Quote: "']I understand that. But don't you think the applications in AppDefends list (which have special permissions) should be checked for validity on start wether execution protection is enabled or not?

This is clearly a hole. Someone who doesn't want to be prompted at each execution will be vulnerable to the most basic leaktest in the book. :-\

I love being able to configure AppDefend in the way I want, like you said. But the way I want is obviously not a wise choice." }-

Hi [suave],

Yes it is a bit of a problem, I might switch the way hash checking works, so it doesn't rely on the .DEFAULT rule, but instead will *always* ask the user if it has changed or BLOCK otherwise if impossible to ask user. That way people like yourself can still be protected.

[nameless1]

Yes, please reevaluate how that feature works. I have had AppDefend configure in a manner similar to [suave], with Execution under the .Default rule set to Allow. I had no idea this meant I had totally disabled all hash checking, even for applications I'd already configured.

[nameless1]

-{ Quote: "[HKEY_LOCAL_MACHINE\SOFTWARE\Ghost Security\GhostSecuritySuite]
"RD_Ruleset"="<DISABLED>"
"MD_Ruleset"="<DISABLED>"
"AD_Ruleset"="<DISABLED>"" }-RD = RegDefend; AD = AppDefend ... But what is "MD"? That value doesn't even exist in my registry.

[[suave]]

-{ Quote: "Hi [suave],

Yes it is a bit of a problem, I might switch the way hash checking works, so it doesn't rely on the .DEFAULT rule, but instead will *always* ask the user if it has changed or BLOCK otherwise if impossible to ask user. That way people like yourself can still be protected." }-

thanks :D ;D ;)

[nameless1]

-{ Quote: "Yes, please reevaluate how that feature works. I have had AppDefend configure in a manner similar to [suave], with Execution under the .Default rule set to Allow. I had no idea this meant I had totally disabled all hash checking, even for applications I'd already configured." }-
Nor do I want to do a hash check of every application I run. I only care about the ones I have configured in AppDefend's list.