DefenseWall, SBIE and SSM bypassed by Trojan

Why it should bypass DeepFreeze?

 

I can't seem to run this little blighter on my system. As soon as I allow it through my execution protection I get a pop-up from ZAP warning me of dangerous behaviour involving IE (which I had open) but before I could finish reading the message or get a screenshot I get rebooted. So I don't know if ZAP is protecting me or the demo is plain buggy!

Sometimes I get prueba.exe in config32, but that's the only change.

 

Nice analysis.
On XP Home with SSM pro, if u have rules for ur browser to be launched by explorer, u will not get any alerts except intial execution of malware. Even no alert of global hook by the browser. Very clever piece of work by this malware. SSM pro fails here.

Mind it that no one uses such a paranoid set up as u( like launching browser via batch files). Just see above the alert by DSA, that is infact the best response by a HIPS against this malware. Even PS responded better than SSM. EQS and SSM proved poor in this response.

With GW, when malware infects explorer.exe GW isolates this and u will see two explorer.exe instances in task manager, one isolated( infected)and one normal( trusted). If u kill the isolated explorer.exe via GW or task manager( and kill the browser via task manager) the demo will stop.

 

Can anybody try it against KAV PDMs?

 

Good description herbalist, but you've missed one point

Hint : Try Firehole leaktest (which SSM is passing), after the trojan/backdoor is tested. I'm ready to bet that SSM will then fail.

 

NicM,
I don't see what that would accomplish. On my box, the firehole test fails on its own, even when I allow everything. Just for fun, I tried launching it after launching the demo. Explorer locks up, so I can't even try the idea.

lucas1985,
The app that alerted was MoniDir 2000, a polling folder contents checker. It's not real time. Just happened to be checking when I launched the demo. Sorry if I gave the impression I had a real time file/folder checker. Wish I did.

Is SSM configured to allow your browser (Opera?) to set global hooks? I don't know how Opera compares to Sea Monkey or IE6, but Sea Monkey has never asked to set a hook during normal usage, only when testing something like this demo. IE6 has, but I blocked it with no ill effects. This could also be from differences in the OS being used, XP vs 98. Either way, I'm suprised the free version detected the hook but not the pro version. I'd be interested to hear others results on this point with different browsers, OSs, SSM versions.
Rick

 

Thanks herbalist

 

Hi Rick,

The leaktest failed, nevermind, that was just a hint : What I wanted to point out is that, the most important thing about this trojan is not its ability to open the browser without detection, in itself, but the changes it performs on the system, in order to do so. It's making changes -somewhere - so that the ability of various HIPS to detect this browser launching is affected, indeed.

It is the most important, because, how to say, these HIPS do not work "as good" after the test than they did before : Hence the success of starting the browser without alert.

Thus is is this "change" that needs to be prevented, more than the detection of the browser starting. Otherwise, system is already affected.

Cheers,

nicM

 

Sorry SSM gives the alert of keyboard hook atleast. Actually my browser was GeSWalled so SSM did not alert, probably the hook was blocked by GW. My other description is correct though( but in my rules set explorere is allowed to launch my browser).

 

Except for that and Pro Security's debugging alert, which SSM free doesn't cover, our results are pretty much the same. I won't try to guess how SSM and PS interact in that situation. I'd expect that would even be influenced by the order they're installed, which one intercepts a given item first.

IMO, all bets are off when malicious code is allowed to execute. I'm convinced that there is no end to the number of ways apps and operating system components can be exploited when malicious or test code is allowed to run. If it were possible to plug all the holes in an app or operating system, you'd think XP or IE6 would be fixed by now with so many patches on them. I wholly expect it'll be the same with security apps. If the code is allowed to run, they'll all be defeated eventually, be patched, and the process will repeat. Even if the apps are hardened, how much damage was done while it was defeated? Was your system compromised when the security app was defeated? How would one know when to check or what to look for? IMO, it's too great of a risk to rely on containment or damage control apps like sandboxes, virtual operating systems, etc, because they will eventually be beaten.

I'm waiting for the day someone packs a new exploit, a real one into a firewall test. So many click on a "test" with no hesitation that a new botnet could be made from the PCs of security buffs.

Rick

 

I have thought of that many times. Not just a firewall test but any test for that matter.Even scanning the test file with something like virus total is no guarantee that it is safe.One must be sure that it is from a trusted source.
But even at that how can one be sure that site was not hacked and compromised?

Looking thru BOCleans covered trojans list,it seems BOClean covers this one as well.(Prueba)

 

I have no idea of this debuging alert but I guess this is the main interception against this malware( I may be wrong though). KAV PDMs give same alert as well on behavioral analysis.

 

It's fail in my PC

I used TINY I am not afraid

 

That,s great. I am really impressed.
Can u explain how it blocks it? Any screenshots pls?

Thanks

 

This , the first time

This test , after i added it to the trusted group .if not, the " prueba " can't do anything

 

Thanks, I know Tiny is discontinued. Is there a site to get a trial of this firewall( Pro Version). I will like to play with it.

Thanks

 

By the way, u this thread. "Explorer exe wants to start the trojan", if u deny this and think PASS, then all HIPS pass this test, SSM , NG, PS etc etc. None of them fails.

We are talking about allowing prueba.exe to run and then see if ur HIPS stops its malicious actions or not? This is a test of behavioral blocker functionality of HIPS( not the anti-execution functionality), otherwise any simple anti-execution software will make this trojan dead.

 

Maybe here.
http://www.321download.com/LastFreeware/page3.html#Tiny Personal Firewall

EDIT: Just took a second look. NOT for XP or Vista.

 

Rick,

First I want to say that I really appreciate your contributions in this forum. Second I have some time to kill, so I will argue with you (just for fun).

Ad 1.
Rick, that is true point taken. Still an Anti Executable also has to find out all possible entries of executable code. Due to rise of the 'networked' community all sorts of remote or distributed code is shared across platforms and networks. On top of this embedded dynamic code (eg the Jpeg exploit, all sort sof scripts, executable meta data, XML, etc). This is not bad is the ideal of the network being the computer with only lean clients and applications or sniplets of code made available when the user requires it. To conclude the principle is true, this does not mean that an Anti Executable has an easy and straight forward job to do. If an Anti Executable was able to close all entries on a given platform, SSM for instance would not fail one single tests.

Ad 2.
Now you yourself are providing me the Achilles weak spot of Anti Executables. Over a period of time any user is confronted with a few changes to his executable base (being updates, additional programs). When you choose allow, you on your own, while containment measures like behavior analysis or rights/policy managers still provide backing. In an earlier post I challenged AE-fan's what kind of measurements they took before allowing a new ap (that is setting the gates of your defense wide open). Your answer was the only one which made sense and showed a contained risk prevention way of handling this.

Ad 3.
This is true when people with AE's would not change there system after the clean installation. In terms of risk management you better of with lower average protection all time through than higher protection combined with periods (say yes to a leaktest for instance) of lowering your AE-shield.

I live in the Netherlands with a statiscal higher chance of a nuture disaster than some one living in the center of France, say my nature disaster chance is 0,005% and for the French guy it is 0,001%. When our conditions are stable (no variances in riks), the French Guy is better off. Only the French guy happens to work for Air Liquide. Part of his job is to check and maintain for a period of two weeks a year the production of highly compressed gasses. During this period his risk on a disaster is 0,01%. Which of us has the highest risk profile is it me with 0,005%, because on average the French guy's risk is lower 0,0013% ( (0,001 x 50 + 0,01 x 2)/ 52 weeks )? I am sorry to say that this is a miscalculation, the French guy has more risk of getting an incident because of nature/external reasons than me.
This is not just a theoretical example this is a real world fact based on a lengthy law suit/court with a multiple of experts opinions coming to the same conclusion. In the US 30 workers were killed on the premises of a production plant an oil company (I thought it was BP), because they were located to close to a dangerous high risk part of the plant for two weeks a year, the oil company had violated the safety regulations.
This two weak high risk period are the moments of weakness of an Anti Executable, you some times have to allow new code.
To conclude : Yes a containment strategy does provide a lower security than a prevent start/anti executable white list strategy. But on the moments you are CONSIDERING to change or increase your whitelist, you are left naked, hanging out to dry in the wind.

One closing remark.
Because sandboxes base their rights/authorization allocation upon the likelyhood of possible external code (only focus on the threat gates), by nature/design this type of containment is maybe simpler in the design than an Anti Executable. GesWall Pro 2.71 (next release) also provides a track list of the behavior of untrusted applications. DefenseWall has had for long a file and registry track option (with roll back option). Although this is only meant for th epower user, it provides me with a lot of info. So I bet that our PC's with out of the box configuration (A2 paid + DefenseWall paid, CyberHawk paid + GeSWall paid) have an overall higher protection/lower infection chance than the majority of Anti Executable users (who have painfully tried to configure/figure out a protection rule set).

 

I get the same type of warnings from ZAP. First I get an OS FW alert of dangerous behaviour involving IE, then, if I allow that, I get component control warning of Explorer trying to connect; if I deny either of these the trojan is stopped. So I think the Explorer thing is to do with .dll loading rather than execution control (which ZAP doesn't do) - but I don't know anything about Tiny so maybe I'm missing something. (Does Tiny do execution protection?)

 

I get all these four alerts from SSM and Outpost fw Pro: It should be clear that a layered approach supported by a little common sense can stop this. It is of no surprise to me that at least herbalist has got it right. It astounds me to see so much concern expressed over this when clearly there is no need for it.

 

It's my rules,auto stop it .
I don‘t want to change the rules .
so this test “prueba.exe”this thread , auto ended .
By the way I use BBlean ,and I renamed "Explorer.exe".
“prueba.exe”can't find it.
I re. back "Explorer.exe" for this test.

Second test
Omitted some pictures (maximum of 5 files one day )

 

I'm not sure what you're specifically referring to with "possible entries". If this referrs to types of files or media which can contain executable code, it's all suspect anymore. If you mean the apps and/or the possible commands these apps could be made to execute, that's theoretically almost unlimited. Given that this is limited to the apps and components installed on a given PC, I'll assume you're referring to the files and media types. If this doesn't address what you were referring to, let me know.

I'm assuming that "networked community" is referring to a LAN, such as is used in a business or multiple PC household. I'm also assuming that the user has control over their own PC. In some situations, being part of a LAN could limit your ability to filter out potentially malicious content, such as material from another workstation or department over which you have no control, material you have to open.

IMO, there is no type of media or file that can be treated as safe. Even a simple text file can be malicious when combined with a couple of normal user commands like "Rename". How many apps would consider the renaming of a text file as malicious? What about when the rename changes the file extension fron txt to reg, bat, or hta? I've seen several AVs intercept batch files I use, identifying them as suspect or malicious whenever Deltree and windows appear in the same line. Basically, the user should treat any file or code not their own as suspect and every application that could be used to open that file as an entry point.

For all purposes, you're potentially opening malicious content every time you go online. What guarantee do you have that someone didn't find a brand new exploit in the software used by this forum (or your homepage) and made use of it 5 minutes ago to deliver a trojan to anyone who visits it? How do you know that a thread link supposedly leading to a screenshot doesn't connect to an HTA designed to send you to a drive-by site? Likely, no, but there's no guarantees. You can only filter out so much with firewalls and filtering apps, especially when your PC is used as part of your work and has to accept files from other PCs at work. The LAN or at work scenario only changes the number of apps that can be used as potential entry points, not the basic security policy.

I regard every app that opens files of any type as a potential target, working on the assumption that I can't intercept all potentially malicious content. By limiting the parent-child settings of each app to only what it absolutely needs, AEs like SSM do perform a type of sandboxing. It would be very difficult to completely prevent your browser from caching a given file, say a malicious dll or exe, but I can prevent the browser from launching that exe, registering that dll, or running that dll using rundll32.exe. I might not be able to stop a bit of embedded code from executing in an already running application but I can intercept its attempts to access other system critical functions, changing system settings in the registry, or gaining a command shell.

Adding or updating the executable base is a more vulnerable point in time for users who depend on an AE but that doesn't hang you out to dry, unless you're one who shuts down everything at the time. I leave everything turned on and deal with the alerts. In addition to recording all the system changes, I'm alerted to every new process during the install, every new dll that gets registered, every new autostart entry, etc as it happens. Yes, it's a pain, especially if you're installing something like OpenOffice.org or GIMP, feels like a lifetime supply of alerts. If I see autostart entries I don't want during the install process, I will block them. If that screws up the install, I can always restore and do it again. Even if I allow all the registry changes, they aren't permanent until I save the new registry with the batch files I wrote for that purpose.

When configured well, an AE will not hang you out to dry unless you shut it off. How well it does is up to the user, the rules they write, and what other defenses they use. Besides, it isn't just AE's that have this problem. How many functional defenses do you have if the app being updated is your sandbox or containment app? What happens if the updated sandbox conflicts with something else you use? If you didn't back up your system before updating, you could have big problems.

Rick

 

@ wat0114

After I execute this trojan, SSM Pro is not able to stop it from executing IE, at least not on my system. And it also manages to escape from the sandbox in DefenseWall and Sandboxie, that´s the problem. Cool to know that ProSecurity, Outpost and Tiny performed better. Btw, this trojan is called Bifrose if I´m correct.

http://www.f-secure.com/v-descs/bifrose_uz.shtml

 

Hi Rasheed,

I don't doubt that and the way this trojan works is probably in a very diabolical manner, but one still has to allow explorer.exe to launch it in the first place, after prompted by SSM. Outpost, at least in my case, just adds another layer of defense in case I mistakenly allow the former sequence to occur.

It seems to come down to the defense package one deploys on their machine, as well as how attentive and knowledgeable one is to these alerts. I would even venture to say surfing habits play a significant role in how likely it is to stumble upon one of these Until I come across an exploit that does not trigger any kind of alert from at least one of my defense layers, I'm not really worried about it. If I blow it by allowing something malicious to run even after one or more alerts, that is my tough luck and, heaven forbid, my own stupidity

It would simply mean restoring one of my Acronis backups.

However, I do enjoy testing these exploits. It satisfies my curiosity and provides a bit of a learning experience as well.