Interesting HIPS test- Delete Volume

Just tried it.

GesWall - failed
CFP Defenece plus with default protected reg keys - failed
DEP - protected against it.

http://www.testmypcsecurity.com/securitytests/deletevolume.html

 

Running it sandboxed surely will kill it but i'll give it a try and also EQS.

Someone is been reading my mind again. I been wanting to run some of these tests but lost track what website was hosting them.

Thanks aigle

 

damn how many ways to wreck a windows system like this are there that we don't even know of? i'm amazed that both comodo and geswall failed this test. aigle can you try this in a LUA account with SRP enabled? or just a LUA.

ps avira flagged this file as dangerous when i tried to extract it.

 

I think destructive malware like this example is becoming more rare. Hence, I doubt if any real world malware will ever do this.

Just to be on the safe side, I added the reg key to SSM and voila! Another vulnerability gone!

 

Hi, I dont have SRP, XP Home, running as admin. Will try to run as LUA later after I create one.

Edit: zopzop, sorry not sure if I will be able to do it- probably not. Hope u will not mind.

 

thank you very much aigle! i can tell you i bit the bullet and ran the file in my LUA with SRP enabled, the file didnt' run. i got an error message saying that the executable was blocked from running by the SRP. i'm too scared to test it in my LUA with SRP disabled.

ps did email brian and the comodo people about the failure?

pss nice job finding these things

 

On DeleteVolume test i ran it sandboxed in SandboxIE and it failed

Anyone have some ideas on this or similar results?

By the way, if someone does test this make sure you follow instructions "FIRST" and "export" that key so you can return it again.

I'm at a loss on this right now.

Adding that KEY to EQS does alert and aborts the run of it though.

 

Open Sandboxie's gui then right click the exe then select run sandboxed and SB doesn't show that it ran sandboxed.

Run cmd sandboxed then drag and drop the exe into the sandboxed cmd window and it still doesn't seem to run sandboxed.

Reboot with Returnil active and you get your partitions back but it's quite easy to undo through disk management.

Thanks for the link Aigle and it's been posted over at SB's forum to see what it's about.

Tzuk is away for a week but he has some good helpers.

 

Using XP Pro and placing a few restrictions on key folders, without stifling the entire O/S, seems to do a nice job restricting that registry key, even unders the power user account. See, I do use a restricted account, though I don't get carried away with it, as some would believe is necessary BTW, NOD32 flagged the test as a trojan when I tried to run it.

 

Yeah, thanks aigle

After placing that particular registry KEY in EQS Registry Branch Settings AND still running it Sandboxed with SandboxIE, here is where the POWER! of EQSecure really shows itself Strong!

Mind you that key IS NOT set by default in EQS.

Also, after you click thru several BLOCKS (Deny in my case), one of the svchost.exe continues to try to "This Application Will Write To Virtual Memory" a few times requiring additional BLOCK actions.

And even though an EQS user might click BLOCK while it's been detected trying to "Create" all those new registry data, if you then "ALLOW" the svchost.exe to continue, then DeleteVolume still succeeds and removes the assigned letters of all partitions except the system partition.

 

Yup, LUA prevents most of the destructive malware.

 

Absolutely.

But for the sake of this test i didn't run SuRun just to see how far it would go when faced against a HIPS + SandboxIE.

SandboxIE alone wasn't enough, for that matter EQS without adding that particular KEY of course is blind to it also.

This is tricky and very cool test because i like the fact after denying the registry modifications then svchost.exe attempts to complete the task anyway by trying to "change other processes memory" in this case Windows Explorer. So it's a persistent little bug and a pretty cool test all in all.

I just like to know how this test file muscled it's way past these SandboxIE settings to complete it's chore.

ClosedKeyPath=HKEY_CURRENT_CONFIG
ClosedKeyPath=HKEY_USERS
ClosedKeyPath=HKEY_LOCAL_MACHINE
ClosedKeyPath=HKEY_CURRENT_USER
ClosedKeyPath=HKEY_CLASSES_ROOT

 

It actually doesn't seem to run sandboxed even when forced.

 

It's got me puzzled too. I think we all would be interested in what solution can be offered because it obviously ignores the Sandbox completely.

For that matter it also can "Sneak" past a HIPS because if the user doesn't follow each prompt with a BLOCK reply, and there are several by the way, then this little test bug can still snag at least one of the partition letters as i just found out.

Super

 

Maybe, it's "Sandboxie-aware" (?)
FWIW, a "test app" packed with FSG looks suspicious. The high number of detections at Virustotal makes it even more suspicious.

 

Very well may be.

One thing is for certain however, it definitely cannot evade blocking and termination by HIPS

 

zopzop,

There's no need to even try. LUA kills this thing dead by blocking both the API call and write access to the HKLM hive by default, unless you go out of your way to login to an admin account and modify your access rights from there.

I do suggest you learn more about the defenses you employ, otherwise you're liable to fall for the mass hype and paranoia (or unwarranted overconfidence) along with so many others here.

 

Well, this test doesn't shake my confidence in SandboxIE in even the slightest way. I've always said that SandboxIE brought you to 99.99%. So a part of the .01% has been identified. I am quite sure that when Tzuk has the time, he will look into this, and SandboxIE will emerge (much to the dismay of some) as even stronger.

 

I fail to see why a security application should protect the user from calling every kind of windows API function (DeleteVolumeMountPoint in our case).

 

The test is user initiated so I wouldn't be too worried but I think most of us sorta enjoy the mysteries of such.

Opened it up with Winhex but to honest I wouldn't have a clue as to what I was looking at.

 

Aigle, thanks for the heads up. But I do wonder how this stuff could be used by malware, I mean it won´t render the machine unbootable or anything? And what if the C volume was also deleted? But anyway, the test also worked for me, eventhough I did get some alert (from SSM) about svchost.exe trying to modify stuff (which I blocked), but it still worked.

 

I suppose it should be properly configured

If this test is run under powershadow 2.6, does a reboot get rid of any changes
(as is the case with Returnil - as posted earlier in this thread)?

soccerfan

 

Has anyone tried it against Defensewall? I'd like to see how it goes on.

muf