Malware bypassed ShadowSurfer

[aigle]

Not a suprise but i thought it might be of interest to some people here.
I tried this under shadow mode of shadow surfer. Some parts of this malware survive the reboot and after reboot malware uses some applications on your system or your browsers to download loads of malware. It's nasty. Still i can't find the actual piece of malware that survives the reboot and manipulates browsers or trusted applications to download tons of malware.
Wil post more about it later as i am out of my home now.

[mark.eleven]

I'd be interested to know if this malware also bypass Sandboxie, DefenseWall, Shadow Defender, Returnil.

[aigle]

Ok, I can confirm the bypass with ShadowSurfer.
GesWall could not be bypassed.
Will test CFP also. More i will not be able to do ATM. Any one if can try it pls with:

ShadowDefender
Returnil
SBIE
DW
MD
etc

I have no VM. So difficult n time consuming with to do this testing with the help of imaging only. PM me for sample pls. Don,t ask it on forums.

Thanks

[bellgamin]

-{ Quote: "Not a suprise but i thought it might be of interest to some people here.
I tried this under shadow mode of shadow surfer. Some parts of this malware survive the reboot and after reboot malware uses some applications on your system or your browsers to download loads of malware. It's nasty. Still i can't find the actual piece of malware that survives the reboot and manipulates browsers or trusted applications to download tons of malware.
Wil post more about it later as i am out of my home now." }-What you discovered sounds rather ominous. I look forward to your discovery (hopefully) of the malware that survived the reboot.

[Toby75]

What kind of malware? Do you have the name of it? Go ahead and PM me...I'll test Outpost.

Thanks,
Toby

[aigle]

Ha ha ... Toby u gave me that. Just run it via cmd.exe. :o

[Toby75]

-{ Quote: "Ha ha ... Toby u gave me that. Just run it via cmd.exe. :o" }-

Are you gonna thank me for that?? Just Kiddin

Toby

[aigle]

Are you gonna thank me for testing it in this way? ;D

Thanks any way, Very clever piece of malware. I love it. :-*

BTW it has more bypasses but of some different kind. In another thread. :o

[Toby75]

-{ Quote: "Are you gonna thank me for testing it in this way? ;D
" }-

Of course - Thank You. We all appreciate the testing that you do!

[Dregg Heda]

-{ Quote: "Are you gonna thank me for testing it in this way? ;D

Thanks any way, Very clever piece of malware. I love it. :-*

BTW it has more bypasses but of some different kind. In another thread. :o" }-
What thread? Any links?

[aigle]

That thread still to come. If i am true there is a malicious behavior bypassing CFP, GW and OA. But i can't be sure unless more people wil test and confirm my findings. I have done the testing and taken all the pictures to explain. I am too busy and might need a week or so to compile it and then, by Allah's will, i am going to post that thread.

[Dregg Heda]

Ok cool!

[aigle]

Any one going to test this malware. Here is how you can reproduce this issue. Run the malware in shadow mode. Allow all prompts by your HIPS, if you have any. Malware wil make many registry changes, wil get debug privileges, wil copy some dlls. May be some service and driver install and direct disk ascess too. It wil try for outbound access too, just deny that.

Most important it wil copy a hidden autorun.inf file and a hidden .pif executable on all partitions/ disks or attachede USB flash sticks. When it,s done, just reboot your system.

After reboot you wil not find any visible files on your system as they wil be wiped away by the shadow surfer.

Now just run your browser and browse the internet for few minutes. Keep your HIPS watching the system. If all goes well, soon you might see some trusted appliction trying for outbound access that it should never do. If allowed it wil download tons of malware and execute them. Also you might find your browser or some trusted application on system trying to make a lot of registry changes.

Still i am puzzled and failed to understand that which malware component survives the reboot and after reboot manipulates browsers or some trusted applicatins to go outbound and download the crap. Sure it,s a root kit but i can't detect/ catch it.

I wil post some screen shots later when i am home.

[Dregg Heda]

If it has direct disk access then no wonder it can defeat your virtualiser. How exactly is OA bypassed if you allow all HIPS prompts?

[aigle]

As promised some of the pop up alerts by CFP.

211715211716
211717 211718
211719

[aigle]

More from CFP.

211720211721
211722211723
211724

[aigle]

Rootkit scan before a reboot in shadow mode.

211725
211726

[aigle]

And finally geswall, seems angry red. ;D

[aigle]

-{ Quote: "If it has direct disk access then no wonder it can defeat your virtualiser. How exactly is OA bypassed if you allow all HIPS prompts?" }-
Wait for my second thread pls. I am not so sure about that issue indeed.

[wat0114]

I attempted to run two of them sandboxed inside the VBox guest, that only resulted in error pop-ups. No damage done. So I ran the same two independently inside the VBox guest un-sandboxed and oh man the results were destructive :o The malware caused the VBox guest to shutdown. When I tried to re-start the current state I was greeted with an ominous "Invalid partition table" message (see screenshot). However, all I had to do was revert to the current snapshot (see screenshot) and all is well again, so VBox seems, so far anyways, to prove its worthiness :)

[wat0114]

-{ Quote: "Doesn't sound like you tested it right. It shouldn't cause the entire system to be crippled like that as far as my testing goes. I get the same pop-ups as aigle above etc. I also used VirtualBox (which was sandboxed), and used Sandboxie within this sandboxed VirtualBox. Everything ran fine, as I stated above." }-

I launched the .x and .z files from the desktop and they both crippled the VBox' partition table. it seems to me the malware did a pretty good job of destruction in these tests, although maybe the partition tables could be restored with a Windows disk. Should they have been run via cmd line?

Anyways, I will try some more.

*EDIT*

I tried the same two from the desktop this time under my limited account. Both attempts resulted in errors with no subsequent damage. The virtues of a limited account seem to come through here.

[wat0114]

One of the others launched via cmd line: see screenshots. I chose "Ignore" even though that is something in reality (non testing) I might not have done. These are not even HIPS-triggered alerts. The second one should pretty obviously trigger a red alert. The system again shut down and once again upon trying to restart the current state of VBox I was greeted with "Invalid partition table" message. BTW, trying to run them via cmd line under lua results in nothing happening. Score another point for lua :)

*EDIT*

the ".C" malware was a little nastier under lua; the whole VBox guest desktop froze, although I was able to finally close the machine using Process explorer. The current state started up again, but just to be safe, I restored the current snapshot. This VBox is excellent for instantly restoring normalcy again :)

[aigle]

Hi wat, sorry sent u wrongle samples. Check ur PM. I am sorry again. Actually some one asked for killdisk too at the same time. So many PMs and I was in hurry.

[wat0114]

-{ Quote: "Hi wat, sorry sent u wrongle samples. Check ur PM. I am sorry again. Actually some one asked for killdisk too at the same time. So many PMs and I was in hurry." }-

hey, no worries aigle :) This just gives something extra to test, but after this, I think that's it for me. I don't want to spend too much time at this (testing malware), nor make it a hobby. It's a bit too addictive - LOL!

Thanks again!

[Peter2150]

Actually that ShadowSurfer might be bypassed by some of the newer malware isn't really surprising. It's really not current, and I don't believe it's being updated.

It's fine for somethings, but not for security purposes, in my opinion.

Pete

[wat0114]

I have run the malware under three situations:


VBox admin guest system (XP Pro Sp3) via command line using limited services profile.
Repeated number 1.
Again in VBox admin guest system, this time with all default services running.

In all three cases I did not notice anything untoward happening more than five minutes after rebooting and running either IE8 or Firefox 3.5.2 browsers, running over 10 minutes in test 3. I believe the malware ran because of brief appearance of hourglass after launching and cmd line prompt returning to previous status, but the malware does not seem to do anything in my VBox environment. It was not even run sandboxed. And no, I did not revert to current snapshot after the reboots. However, before attempts 2 and 3, I did revert to current snapshot.

All I can conclude is that the malware does not work properly under the VBox environment?

[ako]

DW blocks this. (Verified by Ilya.)

[wat0114]

-{ Quote: "It works mate, I tried it myself with a sandboxed VirtualBox." }-

Okay, it does work, but this time before running I installed Malware Defender HIPS on the VBox guest to inspect. This time, however, I did not reboot but the virus sprung in to action about a minute after I launched it. MD alerted numerous times, eventually leading to network access attempts by the virus to various ip addresses, especially to the US. Interesting stuff.

*EDIT*

One last test:

Reverted to current snapshot in VBox, re-installed MD, then launched the malware (via cmd line of course) from the VBox limited account. Results are vastly different, as one might expect:

This time MD alerted many, many pop-ups, but they were all repeated attempts by the virus to infiltrate the registry and attempting to install the autorun.inf and some taping.dll file. I permitted all the alerts. It was clear to me the virus was unsuccessful in its attempts to properly install itself due to the restrictions imposed by the limited account. it just kept running in an endless loop trying to assert itself. There was one early network access attempt but no others after that, as it was fruitlessly trying to breech the registry.

Now I'm certainly no experienced malware tester by a long shot, but with this test of an obviously virulent file here and the killdisk test last night where the limited account was barely scathed by the tests, it is quite evident and proof that running limited has tremendous merit in avoiding serious infection, especially via unexpected drive-by or similar attacks. I'm a believer more than ever now :)

[fcukdat]

Hi Aigle,

Got to love that chinese cuisine :P

After your request to look at the infection i know why Comodo did'nt flag the creation of the service entry...

It is because the service entry already existed(legitimate driver) but the legitimate system file had got replaced and its load entry subsequently hidden(not created).

This is also how it survived reboot and started bringing the rain in the second session.

Use Rootrepeal to copy the hidden file and you have your culprit ;)

MBAM enjoyed all the chinese malwares with this infection so no new signatures for me :'(

[aigle]

Hi thanks a lot. So it was a simple but clever trick. Really love it. I have few questions.
1. After reboot i scanned my XP partition by MBAM from other partition from within win 7 but it detected nothing.
2.No other scanners caught the infected sys file.
3. Was it atapi.sys showed by rootrepeal only once, but never after that. See my pic in the initial posts.
Thanks again.

[developers]

I have tested this malware with Returnil, Deep freeze, Shadow Defender.

Results:

Returnil 2008 2.0.1.9002 has been bypassed
Returnil 2010 Beta 8 (3.0.5636) has been bypassed
Deep freeze 6.53.20.2763 has been bypassed
Shadow Defender 1.1.0.278 has been bypassed

:thumb: Shadow Defender 1.1.0.280 (beta) has not been bypassed :thumb:

[Dregg Heda]

Would a HIPS blocking direct disk access have prevented this?

[aigle]

i blocked direct disk access with comodo and allowed all others and it bypassed.

[Dregg Heda]

-{ Quote: "i blocked direct disk access with comodo and allowed all others and it bypassed." }-
Interesting. I was under the impression that direct disk access was the only way to bypass a virtualiser. Out of curiosity which virtualiser were you using when you blocked direct disk access?

[Windchild]

-{ Quote: "
Now I'm certainly no experienced malware tester by a long shot, but with this test of an obviously virulent file here and the killdisk test last night where the limited account was barely scathed by the tests, it is quite evident and proof that running limited has tremendous merit in avoiding serious infection, especially via unexpected drive-by or similar attacks. I'm a believer more than ever now :)" }-

Indeed.

Based on screenshots posted by Aigle earlier in this thread, it might be interesting to note a couple of things:

1. This malware attempts to obtain the all-powerful SeDebugPrivilege that can be used to inject code into processes running as SYSTEM to gain complete control of the entire system - limited users don't have that, so that's failure number one for the malware and score one for LUA.

2. Apparently the malware also tries to create a dll file C:\daping.dll - limited users can't do that, either, since they can't create files there, another failure for the malware.

3. Then the malware tries to modify AV software registry keys in HKLM - limited users can't do that, assuming the AV software doesn't stupidly grant Everyone - Full Control to its most important registry keys, so it's already the third failure for the malware and things aren't looking all that bright.

4. The malware tries direct disk access - limited users can't do that. Too bad, for the malware.

5. The malware tries to replace the legit but not critically important driver asyncmac.sys, MS remote access serial network driver, with a malicious version - limited users certainly can't do this, having no write access to System32\Drivers. At this point, it's pretty safe to say that the malware has achieved a pathetic failure in infecting the system, or even killing AV scanners running in the system. It's likely that the malware is so stupid it expects to be executed as admin, and fails entirely in LUA, without being able to even infect the user account - which wouldn't be hard to do, if the author bothered to do it.

Of course, LUA couldn't do anything against a stupid user who really just has to install something from an untrusted source. In such a case, they'd just execute this as admin and it could do anything it wants. But, as we can see from this thread right here, even if you're running security software that's supposed to protect you from this kind of thing, you can still get burned. So, the obvious solution: don't execute untrusted code as admin. If you really have to, keep in mind that your security software may not be able to save you, even if it's the fancy HIPS type. ;) Malware, like this sample here, can attempt to evade rather many security software products by first changing trusted system files and processes and then using those against the security software. Threads like this should also serve as a reminder that most people, even in security forums, shouldn't play around with malware, and certainly not with their personal systems they use for anything important. Some malware may slip past the cracks in security software, and then surprises can happen. Of course, running tests in a virtual machine is one way to vastly decrease the risk of surprises. But then one should be aware that some malware acts differently in virtual environments, and may not do all that it's supposed to do, resulting in an incomplete analysis of the malware and possibly even a complete misidentifcation and false negative (this has happened to malware analysts in AV companies).

[arran]

-{ Quote: "I have tested this malware with Returnil, Deep freeze, Shadow Defender.

Results:

Returnil 2008 2.0.1.9002 has been bypassed
Returnil 2010 Beta 8 (3.0.5636) has been bypassed
Deep freeze 6.53.20.2763 has been bypassed
Shadow Defender 1.1.0.278 has been bypassed

:thumb: Shadow Defender 1.1.0.280 (beta) has not been bypassed :thumb:
" }-

-{ Quote: "i blocked direct disk access with comodo and allowed all others and it bypassed." }-

Interesting can someone please pm me sample with pass cheers.

[aigle]

-{ Quote: "Interesting. I was under the impression that direct disk access was the only way to bypass a virtualiser. Out of curiosity which virtualiser were you using when you blocked direct disk access?" }-
ShadowSurfer

[subset]

-{ Quote: "
Threads like this should also serve as a reminder that most people, even in security forums, shouldn't play around with malware, and certainly not with their personal systems they use for anything important.
" }-
Oh, OK then.
We will all stop to play around with malware immediately.
Thanks for the advice.

Cheers

[wat0114]

-{ Quote: "But, as we can see from this thread right here, even if you're running security software that's supposed to protect you from this kind of thing, you can still get burned. So, the obvious solution: don't execute untrusted code as admin. " }-

Good point Windchild. For a while now, I have had a keen interest in testing some malware samples (because I have no interest in long term testing) just to actually see what can happen to get a better appreciation for the threat possibilities, not only when launched within an admin account but especially under a limited account, because it is the latter scenario that interests me the most; exactly how well a limited account can protect against these threats (because it is obvious the admin account opens the doors wide for infection manifestation) even without the aid of security tools (so of course I allowed the HIPS alerts, except the internet acces attempts). I was pleasantly surprised at how ineffective the malware was against the limited account, where basically the malware was beating its figurative head against the wall trying to breech the restrictions.

It also surprises me at how little this is even mentioned by others; most are only interested in what security software the malware can breech, rather than how it can be mitigated or outright stopped with simple measures. Anyways, that is not my problem but felt compelled to mention it.

-{ Quote: "Threads like this should also serve as a reminder that most people, even in security forums, shouldn't play around with malware, and certainly not with their personal systems they use for anything important." }-

Phhhttt! No guts, no glory Windchild ;D :P Seriously, point well taken but it is a risk I had no problems taking, given the measures I have in place in case of breech of containment. I'm sure the same can be said of others who tested this.

-{ Quote: " If you really must run it, do it in a sandboxed VM (this way, if malware leaks out of the VM, you can flush out your sandbox). " }-

Actually, I am quite convinced there is no reason to sandbox the VM or even run the sandbox within the VM. The VM alone easily contained the samples I ran, but I do understand the extra sandbox measure could help in the evnt the VM leaks.

[trismegistos]

Stealth MBR rootkits would either go for low-level disk access to mess up or rewrite the MBR or use a kernel driver to access the mbr just like this rootkit detection utility from Gmer called mbr.exe... http://www2.gmer.net/mbr/

So any virtualizers or virtualizing softwares must have a component with Anti-Executable or a component with HIPS functionality guarding low-level disk access as well as kerneldriver loading. Or the user must supplemment with a companion standalone HIPS or AE or LUA-SRP or a Sandboxing solution.

[aigle]

2nd round of this malware testing is here. :)

http://www.wilderssecurity.com/showthread.php?t=252508

[trismegistos]

-{ Quote: "I'm more surprised at the failure to look at a good "security approach". As Windchild said, LUA isn't going to protect you if your "security approach" is to run every new executable on your real system as administrator - at least run it sandboxed as administrator!

Also, it's more exciting seeing what malware can breech what security software. For example, people aren't testing this to see Antiexecutable 2.3 prevent it from even starting to run haha." }-
Default deny policy approach like AE is just the one needed by those who wants to run their system in Admin. A virtualizer like Returnil(Ram mode) or Deepfreeze with AE is a good combo like Rmus'. :)

[Dregg Heda]

-{ Quote: "Stealth MBR rootkits would either go for low-level disk access to mess up or rewrite the MBR or use a kernel driver to access the mbr just like this rootkit detection utility from Gmer called mbr.exe... http://www2.gmer.net/mbr/

So any virtualizers or virtualizing softwares must have a component with Anti-Executable or a component with HIPS functionality guarding low-level disk access as well as kerneldriver loading. Or the user must supplemment with a companion standalone HIPS or AE or LUA-SRP or a Sandboxing solution." }-

So just to be clear a virtualiser can be bypassed in only 3 different ways:

1) Direct Disk Access
2) Low-level disk access to mess up the mbr
3) Using a kernel driver to rewrite the mbr

Is this correct? And is the purpose of direct disk access also to re-write the mbr? Would this mean that protecting the mbr itself would be enough to prevent malware from bypassing light virtualisation?

[wat0114]

-{ Quote: "I'm more surprised at the failure to look at a good "security approach". As Windchild said, LUA isn't going to protect you if your "security approach" is to run every new executable on your real system as administrator - at least run it sandboxed as administrator!" }-

Hopefully you don't mean my security approach ;) I actually ran the samples in the VM guest both as admin and limited (reverting to current snapshot between test environments), with the host always as limited. This way, in the unlikely event of leakage through the VM, the virus would have had to deal with limited restrictions on the host, which was also protected by Outpost with its host protection enabled. The virtualbox.exe's Internet access was blocked. Of course later on I added Malware Defender to the VM so I could actually get a detailed view of what the virus was trying to do. If this fortress had failed, well, I always have Acronis.

-{ Quote: "Also, it's more exciting seeing what malware can breech what security software. For example, people aren't testing this to see Antiexecutable 2.3 prevent it from even starting to run haha." }-

I don't know about more exciting; I don't think you can count on one product stopping everything, anyways. And of course it goes without saying the malware has to be allowed to launch to properly test the effectiveness, or lack thereof, of the security software and, if desired as was my case, the effectiveness of the limited account. On the software front, I was impressed with the effectiveness of Malware Defender to alert on every single one of the virus' attempts at infiltrating the system.

-{ Quote: "So just to be clear a virtualiser can be bypassed in only 3 different ways:

1) Direct Disk Access
2) Low-level disk access to mess up the mbr
3) Using a kernel driver to rewrite the mbr
" }-

I'm curious about this too. The killdisk malware only messed up the MBR of the virtual machine's disk. However, it was a very easy fix to simply revert to the current snapshot. Remember, I ran the VM on my host's limited account, so I'm not yet convinced the real system is at that much danger as long as the environment is limited. Still, I'm interested to see some informed opinions.

[trismegistos]

-{ Quote: "So just to be clear a virtualiser can be bypassed in only 3 different ways:

1) Direct Disk Access
2) Low-level disk access to mess up the mbr
3) Using a kernel driver to rewrite the mbr

Is this correct? And is the purpose of direct disk access also to re-write the mbr? Would this mean that protecting the mbr itself would be enough to prevent malware from bypassing light virtualisation?" }-
Low level disk access is the same banana as direct disk access. Absolutely right, the mbr is the only place not virtualized in a virtualizer in memory caching mode(all writes will go to RAM) and so it is the achilles' heel. So, it must be protected at all cost from direct disk access as well as from the kernel driver accessing it. In disk overlay type, the malware can write at lowlevel on other sectors of the hard disk besides the mbr.

-{ Quote: "
I'm curious about this too. The killdisk malware only messed up the MBR of the virtual machine's disk. However, it was a very easy fix to simply revert to the current snapshot. Remember, I ran the VM on my host's limited account, so I'm not yet convinced the real system is at that much danger as long as the environment is limited. Still, I'm interested to see some informed opinions." }-

I have tried killdisk trojan on a real system. It will mess up the partition table. I have to delete the partitions and to format it and do a linux install to rewrite the partition table as well as the bootsectors for my imaging program to successfully restore an image back up.

[Dregg Heda]

-{ Quote: "Low level disk access is the same banana as direct disk access. Absolutely right, the mbr is the only place not virtualized in a virtualizer in ram mode and so it is the achilles' heel. So, it must be protected at all cost from direct disk access as well as from the kernel driver accessing it. In disk overlay type, the malware can write at lowlevel on other sectors of the hard disk other than the mbr." }-

So as long as the mbr is protected the virtualiser cant be bypassed? Doesnt Returnil have some sort of feature protecting the MBR? Were these features active when forum member developers tested returnil 2008 and 2010 beta?

developers any response to this?

[developers]

Virtualisers try to protect MBR themselves, it's an internal feature, you can't activate or deactivate it.

New MBR rootkit VS Returnil (http://www.wilderssecurity.com/showthread.php?t=239164): Returnil 2010 beta has protected the MBR

DDOS worm (http://www.wilderssecurity.com/showpost.php?p=1508806&postcount=58): Returnil 2010 beta has protected the MBR

Technical Returnil question regarding malware (http://www.wilderssecurity.com/showthread.php?p=1528795#post1528795): how an Instant System Recovery software can be bypassed

W32.SafeSys.Worm VS Returnil (http://www.wilderssecurity.com/showpost.php?p=1505018&postcount=1): this worm can bypass several ISR (http://www.wilderssecurity.com/showpost.php?p=1505391&postcount=21).

I have tested Returnil 2010 with Virus Guard disabled, and Returnil 2008 without AntiexEcute tool, because Deep Freeze and Shadow Defender haven't these protections. So, only virtualization VS malware.

[wat0114]

-{ Quote: "Absolutely right, the mbr is the only place not virtualized in a virtualizer in ram mode(all writes will go to RAM) and so it is the achilles' heel. So, it must be protected at all cost from direct disk access as well as from the kernel driver accessing it. In disk overlay type, the malware can write at lowlevel on other sectors of the hard disk besides the mbr." }-

If that's the case, then how was I able to easily revert to the current snapshot after killdisk compromised the vm's mbr? Is it because I'm running the VM on the host's limited account?

[trismegistos]

-{ Quote: "If that's the case, then how was I able to easily revert to the current snapshot after killdisk compromised the vm's mbr? Is it because I'm running the VM on the host's limited account?" }-
Yup, just like windchild said, 'lua protects mbr'.

[wat0114]

-{ Quote: "Yup, just like windchild said, 'lua protects mbr'." }-

Ahh, I missed that. Okay, thanks, good to know :)

[Dregg Heda]

-{ Quote: "Virtualisers try to protect MBR themselves, it's an internal feature, you can't activate or deactivate it.

New MBR rootkit VS Returnil (http://www.wilderssecurity.com/showthread.php?t=239164): Returnil 2010 beta has protected the MBR

DDOS worm (http://www.wilderssecurity.com/showpost.php?p=1508806&postcount=58): Returnil 2010 beta has protected the MBR

Technical Returnil question regarding malware (http://www.wilderssecurity.com/showthread.php?p=1528795#post1528795): how an Instant System Recovery software can be bypassed

W32.SafeSys.Worm VS Returnil (http://www.wilderssecurity.com/showpost.php?p=1505018&postcount=1): this worm can bypass several ISR (http://www.wilderssecurity.com/showpost.php?p=1505391&postcount=21).

I have tested Returnil 2010 with Virus Guard disabled, and Returnil 2008 without AntiexEcute tool, because Deep Freeze and Shadow Defender haven't these protections. So, only virtualization VS malware." }-

Alright, thanks for this developrs!:thumb:

So from this we can see that all virtualisers attempt to protect the mbr. However for whatever reason this protection is not complete and from time to time malware writers figure out how to bypass it. The virtualiser programmers then respond by coding to protect against the specific attack and so on and so forth.

Would a third party app independent of the virtualiser do a better job in protecting the mbr and prevent all access, hence ensuring that a virtualiser cannot be bypassed? Im talking of something like MBR Guard. Any ideas?

[jmonge]

-{ Quote: "Alright, thanks for this developrs!:thumb:

So from this we can see that all virtualisers attempt to protect the mbr. However for whatever reason this protection is not complete and from time to time malware writers figure out how to bypass it. The virtualiser programmers then respond by coding to protect against the specific attack and so on and so forth.

Would a third party app independent of the virtualiser do a better job in protecting the mbr and prevent all access, hence ensuring that a virtualiser cannot be bypassed? Im talking of something like MBR Guard. Any ideas?" }-blueridge is developing a program for protecting the mbr;) i forgot the name of the program an i think they will implement it in coming appguard;)

[Dregg Heda]

-{ Quote: "Ahh, I missed that. Okay, thanks, good to know :)" }-

This doesnt make sense wat. The guest itself is in admin so the malware should have no trouble getting to the guests mbr. I doubt the host OS being in LUA can help in anyway. The only two possibilities I can think of are that the malware doesnt show its true capabilities in a vm. Or perhaps snapshots in a vm work differently to snapshots on an isr in the host. Perhaps a snapshot in a vm is more akin to an image for the real system and everything is backed up including the mbr. Hence when you revert your snapshot the infected mbr is replaced and the infection is completely gone.

[Dregg Heda]

-{ Quote: "blueridge is developing a program for protecting the mbr;) i forgot the name of the program an i think they will implement it in coming appguard;)" }-
Yup that is exactly the app I was talking about. :smile:

[jmonge]

-{ Quote: "Yup that is exactly the app I was talking about. :smile:" }-also a hips program can do this but you have to pay the price and that is to deal with bunch of pop ups:) :)

[Coldmoon]

-{ Quote: "Virtualisers try to protect MBR themselves, it's an internal feature, you can't activate or deactivate it.

New MBR rootkit VS Returnil (http://www.wilderssecurity.com/showthread.php?t=239164): Returnil 2010 beta has protected the MBR

DDOS worm (http://www.wilderssecurity.com/showpost.php?p=1508806&postcount=58): Returnil 2010 beta has protected the MBR

Technical Returnil question regarding malware (http://www.wilderssecurity.com/showthread.php?p=1528795#post1528795): how an Instant System Recovery software can be bypassed

W32.SafeSys.Worm VS Returnil (http://www.wilderssecurity.com/showpost.php?p=1505018&postcount=1): this worm can bypass several ISR (http://www.wilderssecurity.com/showpost.php?p=1505391&postcount=21).

I have tested Returnil 2010 with Virus Guard disabled, and Returnil 2008 without AntiexEcute tool, because Deep Freeze and Shadow Defender haven't these protections. So, only virtualization VS malware." }-

Hi developers,
It is important to also report whether the AE in 2008 and/or the VG/targeted AE in 2010 provides protection against these as well. While I applaud and encourage consistency in testing, the reason these things were included in RVS was to provide protection against content that can bypass strict virtualization.

Without knowing whether the VG/Trust only existing files on the real system is doing its work properly, we can't get a complete picture of the overall effectiveness and whether we need to upgrade the code. Thanks in advance...

Mike

[wat0114]

-{ Quote: "This doesnt make sense wat. The guest itself is in admin so the malware should have no trouble getting to the guests mbr." }-

Exactly right and I even confirmed that in post #22 this thread.

-{ Quote: " I doubt the host OS being in LUA can help in anyway. " }-

For the above scenario, I'd agree with you. However, the question is whether or not the host running aas limited can protect itself against rewrire of the MBR, and I'd say it does.

-{ Quote: "The only two possibilities I can think of are that the malware doesnt show its true capabilities in a vm." }-

It appeared the samples I tested were working as intended in the VM, but I can't be 100% certain. What I do know is I had no problems flushing the damage away with a revert to current snapshot, so that's what matters most to me :)

-{ Quote: "Or perhaps snapshots in a vm work differently to snapshots on an isr in the host. " }-

I have never use ISR software so I can't comment.

-{ Quote: "Perhaps a snapshot in a vm is more akin to an image for the real system and everything is backed up including the mbr." }-

Yes, I believe this is true, including backup of the MBR.

-{ Quote: "Hence when you revert your snapshot the infected mbr is replaced and the infection is completely gone." }-

Indeed, I believe that is exactly what happens with the infected mbr, but the reverting snapshot also brings the entire VM O/S to that exact previous state.

[developers]

-{ Quote: "Hi developers,
It is important to also report whether the AE in 2008 and/or the VG/targeted AE in 2010 provides protection against these as well. While I applaud and encourage consistency in testing, the reason these things were included in RVS was to provide protection against content that can bypass strict virtualization.

Without knowing whether the VG/Trust only existing files on the real system is doing its work properly, we can't get a complete picture of the overall effectiveness and whether we need to upgrade the code. Thanks in advance...

Mike" }-

VirusGuard (Returnil 2010) has detected and blocked several malware downloaded by this trojan, and after the reboot system wasn't infected.

AntiExecute (Returnil 2008 ) has protected the OS. After the first "Allow" for executing the malware, all others popups was blocked (on-the-fly driver protection checked also), and after reboot the system resulted clean.

[wat0114]

-{ Quote: "Counting on one product stopping everything? I think it's actually a good security approach that stops everything mate." }-

This could turn into a long, drawn out debate, so no comments here.

-{ Quote: "Of course Malware Defender would give those alerts - it's a classical HIPS, and all classical HIPS are noisy with pop-ups haha. I already stated that Defense+ gave over 100 pop-ups etc." }-

Sure, I’ve probably stated the bleeping obvious so sorry, but to elaborate, it (the HIPS) gave me the opportunity to stop the progress of the virus without freezing up or crashing. At least if the virus was real and I wanted to stop mid-stream in an effort to mitigate the damage, MD could have done so without buckling under the stress of handling the alerts. Believe me, I have enough experience testing these type products to know that some handle the numerous alerts better than others. Specifically, what I have seen with MD is it not only handles the alerts without labouring under the frequency of them, it also alerts instantly, without the delay that I have seen with some other products when they are met with a volley of attempted changes brought on by the unknown process’ installation.

-{ Quote: "No, malware doesn't need to be launched to properly test the security software.
If you deny everything unknown/untrusted at the gate, then you won't get infected. It's as simple as that, and that's all the user cares about - that they won't get infected." }-

Testing malware against security software and running a computer with the intent on denying unkown/intrusted at the gate are two different things ;) Can you honestly say you installed Sanboxie with unconditional faith it will stop everything based only on other’s comments you’ve read, or have you not run some tests against it to bolster your convictions in its abilities?

Anyways, good thread. I've learned something I consider valuable from it :)

[Peter2150]

-{ Quote: "If that's the case, then how was I able to easily revert to the current snapshot after killdisk compromised the vm's mbr? Is it because I'm running the VM on the host's limited account?" }-

Hi Wat0114

You can't compare VM's Snapshot feature with the standard virtualizers like Returnil, ShadowDefender etc. They just aren't comparable.

Pete

PS. Be sure nice if they were.

[wat0114]

-{ Quote: "All this testing is good stuff though, and it lets us understand better how these malware work. It also tells us that products like Shadow Defender etc can be genuinely bypassed too (and it seems frighteningly quite easily)." }-

Absolutely you are right! It has been an eye-opener for me, of sorts. BTW, sorry if it seems I'm nit-picking in response to some of your comments. In truth, I read your posts - all of them - enthusiatically because you bring up a lot of interesting ideas and subject matter regarding security approaches :)

-{ Quote: "Hi Wat0114

You can't compare VM's Snapshot feature with the standard virtualizers like Returnil, ShadowDefender etc. They just aren't comparable.

Pete

PS. Be sure nice if they were." }-

Thanks Pete, I wasn't sure. Indeed, the more I use VBox and discover its capabilities, the more I'm impressed with it, especially when the Guest additions are installed. And regarding the snapshot feature, I think I will take a bold step forward and re-test killdisk in VBox again, but this time on the Host's admin account just to see once and for all if the virus can infect the host's mbr. I better have a reliable backup plan in place :o Stay tuned!

[arran]

-{ Quote: "

Sure, I’ve probably stated the bleeping obvious so sorry, but to elaborate, it (the HIPS) gave me the opportunity to stop the progress of the virus without freezing up or crashing. At least if the virus was real and I wanted to stop mid-stream in an effort to mitigate the damage, MD could have done so without buckling under the stress of handling the alerts. Believe me, I have enough experience testing these type products to know that some handle the numerous alerts better than others. Specifically, what I have seen with MD is it not only handles the alerts without labouring under the frequency of them, it also alerts instantly, without the delay that I have seen with some other products when they are met with a volley of attempted changes brought on by the unknown process’ installation.

" }-

I'm glad some one has seen the light and recognized the speed and how snappy MD is at intercepting and blocking certain activities. There is a lot of people here always complaining about popups, but with MD you can configure it to have Default Deny policy which blocks with ZERO POPUPS. default deny blocking all unknown executables and script executables from running. Just as good or even better than AE2 or AE3.

[arran]

-{ Quote: "It's indeed better than AE2 or AE3, since it also will protect against script executables. However, I find system-wide default-deny policies quite restrictive and then there's the issue with re-configuring the classical HIPS when updating trusted programs etc etc. All a bit inconvenient for me personally. Pop-ups from a classical HIPS aren't actually a problem at all while simply using my computer as per usual - I never (very rarely) got any pop-ups from Defense+. It's not until you're updating programs that pop-ups start happening willy nilly.
" }-


Its not just unknown executables that you can make default deny while in training mode its any thing, any app.

by having separate groups for apps you can have some programs in training mode while at the same time you can have other apps in normal mode. After each app has finished its training mode time I simply put it in the normal mode lock down group. The entire process from MD fresh install to everything going into normal mode = ZERO POPUPS. MD is the only HIPS which allows you to do this. This is another thing which makes MD more superior than others. So for updating programs like firefox etc I temporary pull it out of the normal group into the training mode group. so during the update process there is ZERO POPUPS. Its really no different than temporary running your browser outside of sandboxie to install updates.

[wat0114]

As per post #71, I have conducted a test of the killdisk malware samples in VBox admin account running on the host admin account, in order to see if the MBR of the host's hard drive would get infected. Before I started testing, I had my doubts it would happen ;)

Setup:


Host System: Vista SP 2 running as full admin
Security software on host: Outpost security suite with Host protection enabled
VBox Guest System: XP Pro SP3, running as admin
VBox security software: None
Test samples: Selection of 4 killdisk files run via cmd line on VBox

Results:

All four samples I ran infected, as I expected, the MBR of only the VBox MBR. The Host system's MBR was completely untouched. Outpost was on alert but of course detected nothing because nothing escaped the VBox guest. As with my earlier testing, all I had to do was initiate the simple formality of reverting to the current snapshot and I was back in business in mere seconds. Ho-hum, this is almost too easy :isay: Ahh, confidence in Virtualbox is running extraordinarily high ;D

[Peter2150]

-{ Quote: "

by having separate groups for apps you can have some programs in training mode while at the same time you can have other apps in normal mode. After each app has finished its training mode time I simply put it in the normal mode lock down group. The entire process from MD fresh install to everything going into normal mode = ZERO POPUPS. MD is the only HIPS which allows you to do this. This is another thing which makes MD more superior than others. So for updating programs like firefox etc I temporary pull it out of the normal group into the training mode group. so during the update process there is ZERO POPUPS. Its really no different than temporary running your browser outside of sandboxie to install updates." }-

Ok Arran, once more you've gotten my attention, and made me realize how little I really know about Malware Defender.

I sure would appreciate it, if you would start another thread and go step by step thru how you do what you just mentioned. I bet I am not the only one who would appreciate it.

Thanks,

Pete

[bellgamin]

-{ Quote: "...with MD you can configure it to have Default Deny policy which blocks with ZERO POPUPS. default deny blocking all unknown executables and script executables from running." }-Here is how I instigate MD's "Default Deny policy". . . .

+Right-click MD's icon in the system tray to get pop-up menu.
+On pop-up menu, left-click "Silent Mode".
+While in Silent Mode, MD will silently deny all rules which have an ASK option.

To revert. . . .

+Right-click MD's icon in the system tray to get pop-up menu.
+On pop-up menu, left-click "Normal Mode".

Is there an easier way?

[Scoobs72]

-{ Quote: "

I sure would appreciate it, if you would start another thread and go step by step thru how you do what you just mentioned. I bet I am not the only one who would appreciate it.

" }-

I second that :)

[nick s]

-{ Quote: "Here is how I instigate MD's "Default Deny policy". . . .

+Right-click MD's icon in the system tray to get pop-up menu.
+On pop-up menu, left-click "Silent Mode".
+While in Silent Mode, MD will silently deny all rules which have an ASK option.

To revert. . . .

+Right-click MD's icon in the system tray to get pop-up menu.
+On pop-up menu, left-click "Normal Mode".

Is there an easier way?" }-

Ctrl + Shift + Alt + S toggles Silent Mode. Ctrl + Shift + Alt + N gets you back to Normal Mode. Hot keys can be easily customized via Tools > Options > Hot Keys.

[bellgamin]

-{ Quote: "Ctrl + Shift + Alt + S toggles Silent Mode. Ctrl + Shift + Alt + N gets you back to Normal Mode. Hot keys can be easily customized via Tools > Options > Hot Keys." }-Magnifique!

10 Q :thumb:

[demoneye]

-{ Quote: "I'm glad some one has seen the light and recognized the speed and how snappy MD is at intercepting and blocking certain activities. There is a lot of people here always complaining about popups, but with MD you can configure it to have Default Deny policy which blocks with ZERO POPUPS. default deny blocking all unknown executables and script executables from running. Just as good or even better than AE2 or AE3." }-


how do u choose which group remains in NORMAL mode and which in LEARNING mode?

i see also peter ask for it , hope u can do a step by step explanation

cheers

[arran]

Yea I will first write up some form of instructions and make a new thread soon, don't want to throw this thread any further off topic.

[Dark Star 72]

-{ Quote: "Yea I will first write up some form of instructions and make a new thread soon, don't want to throw this thread any further off topic." }-

Looking forward to this VERY much. Like Pete I hadn't realised just how versatile MD seems to be. You very likely have another convert :thumb:

[wat0114]

-{ Quote: "Well mate, VirtualBox is pretty darn secure on its own. Thanks to WindChild though (who gave claims that VM software can be bypassed/have vulnerabilities), I was prompted to discover that virtualbox.exe can be run sandboxed successfully! I don't think you can get a much more secure testing environment than that." }-

Yes, it's very secure not only as a testing environment but also as a normal user environment. One caveat with VBox, however, is that it is necessary to allow virtualbox.exe Internet access on the Host system's application firewall, if applicable, as it is in my situation. The problem here is that virtualbox.exe acts as a proxy, of sorts, for any application, including browsers and email clients, running on the VBox guest system. So if you want to control Internet access for applications running on the VBox guest, you need to install an application firewall on it, meaning you basically have two software fiirewalls, guest and host, controlling network traffic for applications on the guest.

[Peter2150]

-{ Quote: "Here is how I instigate MD's "Default Deny policy". . . .

+Right-click MD's icon in the system tray to get pop-up menu.
+On pop-up menu, left-click "Silent Mode".
+While in Silent Mode, MD will silently deny all rules which have an ASK option.

To revert. . . .

+Right-click MD's icon in the system tray to get pop-up menu.
+On pop-up menu, left-click "Normal Mode".

Is there an easier way?" }-

That is easy, but it's not what Arran is talking about. He's saying he can have most stuff work normally, but put a couple of programs in learning mode.

[Peter2150]

-{ Quote: "Yea I will first write up some form of instructions and make a new thread soon, don't want to throw this thread any further off topic." }-

Thanks on both counts.

[Windchild]

-{ Quote: "For the above scenario, I'd agree with you. However, the question is whether or not the host running aas limited can protect itself against rewrire of the MBR, and I'd say it does.
" }-

Indeed it does. :thumb: If you're in a limited user account (assuming proper configuration, like an NTFS file system instead of no-security-FAT32) then no MBR rootkit can hide itself in your master boot record to load before the OS does, and no 'killdisk' malware can mess up your partition table or delete your system files.

Limited user accounts are way, way under-rated in Windowsland. Very often, when I read some Windows security forum topic where someone posts about a new malware bypassing some security software product, the first thing that's obvious to me is that "a limited user account would have prevented that." And when I see people asking "what security software can protect my MBR from malware?" or "how can I protect my kernel from evil rootkit drivers being loaded without my permission?" it always bothers me that the obvious answer is "limited user accounts could do that", and yet often no-one ever mentions that solution, even though it's absolutely free and requires no installation of additional software and therefore potentially also additional security vulnerabilities. ;D

LUA is a solution to many things (but obviously not all). I consider it my responsibility, as someone who cares about security and knows more about it than Joe User, to spread information about that solution, just like Unix users recommend the obvious best practice of not running as root.

"Malware bypassed (enter security software name here)"? In about 99 % of all cases malware wouldn't be able to bypass it, if the user was LUA. LUA also protects our precious security software. ;)

This concludes my daily LUA rant. ;D

[Keyboard_Commando]

-{ Quote: "
This concludes my daily LUA rant. ;D" }-

Maybe you could be given the title of forum LUA Propaganda Minister. A uniquely coloured screename to highlight your importance wouldn't look out of place ... as well. Keep up the good work. :thumb:

[Coldmoon]

-{ Quote: "VirusGuard (Returnil 2010) has detected and blocked several malware downloaded by this trojan, and after the reboot system wasn't infected.

AntiExecute (Returnil 2008 ) has protected the OS. After the first "Allow" for executing the malware, all others popups was blocked (on-the-fly driver protection checked also), and after reboot the system resulted clean." }-

Thanks for the verification :)

Mike

[wat0114]

Or you can pay nothing and deploy LUA and/or SRP. And in defense support of Windchild, at least he posts facts, rather than conjecture and hearsay. I understand his rants, because a lot of people obviously just don't get it.

[wat0114]

-{ Quote: "And have the restrictions and associated inconvenience of LUA and/or SRP. But whatever works best for you mate." }-

No reason why the majority of programs should not work seamlessly under LUA. Other tasks such as installing programs and updates and such should be considered a minor inconvenience to switch from lua to admin.

-{ Quote: "Also what is there to defend of Windchild? He posts his opinions just like everyone here in this forum." }-

Nothing directed at you, ssj :) I should have stated "support" so I changed it.

[wat0114]

-{ Quote: "Sure thing mate haha. Well, only one way to find out whether LUA works well for you right? Just try it! If you don't like it, there are other ways of achieving good (and arguably better) security." }-

I've been on lua for about a year now and it's worked near flawlessly. I used to run as power user, which imo if set up properly will provide a solid defense against unexpected intrusions as well. Perhaps I have not seen enough yet, but what I witnessed when running those malware samples in the VBox'es lua has quite thoroughly convinced me of the virtues of lua in repelling malware attacks.

Also, I believe in more than just deploying lua as a security measure; in fact, and as I've alluded to recently, I absolutely love what I see in Virtualbox so I'm using that in the host system with an older version of Outpost firewall (3.51) to restrict Internet access on anything running in the vm. So far, so good.

[wat0114]

No expert here but experienced and confident enough to know if something fishy is happening.

[Keyboard_Commando]

-{ Quote: "By the way, wat0114, I feel that relying on LUA is similar to relying on DefenseWall - you generally won't get pop-ups when malware attacks you etc. So you could be using a system that has "frozen malware" on it, which is fine for most people I guess? For me, it's a bit unsettling." }-

EDIT: not trying to drag this off topic, but lol ...

The "frozen malware" point kinda interests me. Can swapping to Admin mode then allow suppressed malware to then become alive?

-----------------------------------------------------

BTW, I wasn't having 'a go at Windchild. I read Windchilds posts, as much as I can, as they're often epic lengthy novels :D He makes a lot of sense about LUA. I am moving to LUA when I get my hands on Win 7.

[wat0114]

-{ Quote: "EDIT: not trying to drag this off topic, but lol ...

The "frozen malware" point kinda interests me. Can swapping to Admin mode then allow suppressed malware to then become alive?" }-

I'm kinda wondering the same thing ???

-{ Quote: "BTW, I wasn't having 'a go at Windchild. I read Windchilds posts, as much as I can, as they're often epic lengthy novels" }-

No disputing the lengthy posts. Perhaps he should change his handle to "Longwindedchild" or "Windbagchild". LOL, just having fun Windchild :D

-{ Quote: "He makes a lot of sense about LUA. I am moving to LUA when I get my hands on Win 7." }-

Yes, I think everything he says about it is true.

[Windchild]

-{ Quote: "
The "frozen malware" point kinda interests me. Can swapping to Admin mode then allow suppressed malware to then become alive?" }-

Good question. Let's consider how this would happen. For the malware to become alive in the admin account where it could then completely own the system, it needs to be executed by something. And what would execute it? There's a very limited number of ways that could happen:

- Admin (the human who uses the admin account) executes the malicious file manually, because he wants to. This has happened before, but it typically requires a stupid admin - and if you have a stupid admin, chances are pretty good you'll get owned sooner or later, either by malware or by non-software stupidity, such as manually deleting important system files for example. Let's imagine some browser exploit dropped a malicious exe called scvhost.exe into the limited user account's Local Settings\Temp folder, and then died, because it couldn't do what it wanted like create files in System32 because of restrictions imposed by the limited user account. For this inactive, "frozen" malware file to become active, the admin needs to first browse into the limited user account's temporary folder, then search it for suspiciously named executable files, and then the admin needs to manually execute the scvhost.exe file! Why would anyone ever do that, if they're not horrifyingly stupid? ;D What would the admin be thinking: "Gee, this looks like a file I have never seen before, and I don't know what it does. It's also located in a folder where limited users can write. Hmm... I guess I'll just randomly execute this file, which could be absolutely anything between rootkit dropper and harmless game, and let luck decide what happens to my system." Of course, social engineering is a different issue. If the user thinks the malicious file is in fact good, then the game is over, because the user will give that file admin privileges, and will ignore any alert from security software, will take the file out of sandboxes and so on ad nauseam. Nothing helps against that - except not giving the user the option to trust the file (for example, not giving him the admin password which is exactly what you should do on a shared system - don't give your kids/wife/husband/pets the admin password).

- Malicious file is executed without permission from the admin user, by exploiting a vulnerability in some software that runs with admin or system privileges. This has happened, too, but is much rarer, and can still be defended against. The old-hat WMF exploit from 2005 did this. How that happened? If you, as an admin, used Windows Explorer to browse a folder that contained a malicious WMF exploit file that was placed there by a limited user, Explorer would try to read metadata from the file so that it could then display that to you (thumbnails and such). Reading the metadata invoked the vulnerable graphics component, which would get exploited, and then the malicious code would get executed - and if the user who browsed that folder was admin, now the malware got admin privileges. The user didn't have to open or execute the file manually, they only had to open a folder that contained a malicious file. Another way that this happened was with Google Desktop Search and other similar search and index utilities. They, too, read the metadata from the malicious WMF file, and then get exploited. This was even worse, because the user wouldn't have to do anything at all, not even view the folder where the malicious file was contained. Google Desktop would just silently read the metadata of the newly created malicious file, get exploited, and the system would be owned. Nice. But there are obvious ways to defend against much of this. If you're admin, don't go around carelessly browsing folders where limited users can write and therefore can also drop any kind of exploit files in, especially not if there's a known and unpatched vulnerability that allows attacks like this being exploited currently. Think before acting. ;) If you have software like file indexing and search utilities such as Google Desktop, be mindful of what they can do if a certain kind of malicious exploit file ends up on the system and the system is vulnerable to the exploit. Consider not running such utilities at all, or running them with limited privileges. And to keep things in perspective, remember that vulnerabilities that allow this type of exploit are rare, and they tend to get patched quickly.

- Poorly configured file permissions or poor choice of file system may allow automatic execution of malicious files when admin logs in. If you use FAT32 (don't), anything goes, there is no security, and limited user accounts can infect the entire system and gain admin privileges easily - because they can overwrite system files and installed programs, write anywhere, delete anything, and so on. If you're using NTFS (you should), but for some reason have poorly configured, insecure file permissions, limited users may be able to write into places they aren't allowed to write by default, and that can allow malware to gain admin privileges when an admin logs in. Sometimes big computer manufacturers would muck up file permissions for some reason, I've seen many cases myself. For example, they would allow any user to create files in All Users Startup folder, which means that limited users can make malicious files execute immediately when anyone, including an admin, logs in. So, you need to be sure that file permissions are not insecure on the system, and correct them if they are (and flame whoever made them insecure in the first place).

Other than these methods, I can't quickly think of any other way the inactive malware could become active when you log in as admin to do something.

So, in short, the answer to the question "Can swapping to Admin mode allow suppressed malware to become alive?" is "No, unless the user manually executes the malware or there's a rare, unpatched vulnerability that the malware can exploit under the right circumstances such as the user browsing the folder where the malicious file is located or an indexing software running as system indexing the malicious file and being exploited in so doing." An even shorter answer is: "No, if the user knows what he's doing."


As for the long posts, well, I've always had that problem. :P But, you have to admit that some things cannot be explained with just a couple of words. I could write posts that are never longer than one sentence, but then they'd all be something like "Just run security software X lol" and my posts would be even more useless than they are now! ;D

[Dregg Heda]

Windchild:

Excellent post as always. I would like to know how can one find out if file permissions are as they should be for LUA? That your hardware manufaturer didnt screw something up. Id like to know this for both Vista and XP. Thanks.

PS: I dont think theres anything long-winded about any of your posts. Personally I like your detailed explanations which seem to cover all the bases. Keep it up! :thumb: 8) ;D

Editted to correct smilies.

[Windchild]

-{ Quote: "
I've got a few questions about that .wmf exploit (I actually asked it in a recent thread of mine but never got an answer) - would SRP prevent the exploit from running? Or would SRP do nothing, since .wmf will be opened by a trusted executable from C:\windows or C:\program files?
" }-

The exploit itself? No, SRP couldn't do anything to stop the actual exploit part of the attack. The exploit was possible because the WMF file type stupidly had a feature that allowed the image files to contain and run code. This was a useful feature back when dinosaurs still walked the earth, for things like canceling a printing task, but in the internet age it was just huge gaping security hole. SRP could not stop that code from being executed, and that was the actual exploit. But, SRP could stop the actual payload of the exploit: the exploit will run code that will typically download and execute some trojan exe or more rarely a DLL that will be injected into some system process like svchost, and SRP will intercept this when CreateProcess or LoadLibrary is called to execute the malicious file. So, at this point, SRP would stop the attack, although the exploit itself worked.

For SRP, it never matters at all whether the file is being opened by a trusted executable or not. SRP doesn't even consider that. All it cares about is whether the file is allowed by the SRP rules. Two clarifying examples:

- A "trusted" file iexplore.exe tries to execute notepad.exe because IE wants to show you the source code of a page. At this point, SRP wakes up from its sleep and checks to see whether notepad.exe should be allowed. SRP doesn't pay any attention to what started notepad.exe - it doesn't care whether iexplore.exe is trusted or not. SRP just checks its rules against notepad.exe. SRP first sees the SRP security level is disallowed, which means notepad.exe shouldn't be allowed to run. But then SRP notices notepad.exe is located in the Windows directory, and an additional rule has set everything in that directory to unrestricted, that is, allowed. Therefore, SRP allows notepad.exe to run, because the most specific rule takes precedence (and "allow everything in Windows folder" is more specific than "deny everything, anywhere").
- The WMF exploit happens. Malicious code in a malicious wmf file is happily executed. Said code calls URLDownloadToFile to download some boring trojan executable from some bad guy's site, and then executes it. Once the trojan is downloaded, and CreateProcess is called on the trojan file, SRP wakes up and checks whether that file should be allowed. Again, SRP doesn't care what is trying to execute the file. It just checks its rules. Again, security level is disallowed, which means the file should not be allowed to execute. SRP checks additional rules, and there is no additional rule that allows this file. It's located in Local Settings\Temp, and there are no unrestricted rules for that location. Therefore, SRP blocks the trojan file from being executed. The WMF exploit worked, but it could not deliver its trojan payload. The attack failed, and the system did not get owned.

Any decent anti-executable whitelist could have done the same.


-{ Quote: "I would like to know how can one find out if file permissions are as they should be for LUA? That your hardware manufaturer didnt screw something up.
" }-

There are roughly three ways.

1) Perform some quick "manual" testing: try to create files and folders in certain places and see what happens. Limited users, by default, should not be allowed to create files in the root directory of C, but are allowed to create folders. Limited users are not allowed to create files or folders in Windows or Program Files folders. Limited users can't create files or folders in the Default User profile folder, or in the All Users Startup (ProgramData\Microsoft\Windows\Start Menu\Programs\Startup in Vista) folder. So, you can just browse into those folders with Windows Explorer and try to create new files and folders. If Windows says "access denied" or something like that, the permissions are fine. That is easy and requires no skill or additional tools, but only some manual labor. Of course, it's not fully accurate, since it only tests the permissions for creating new files and folders, and not modifying existing files. But if one is correct, usually the other one is, too.

2) Use the Security tab, Luke. View the Properties for the Windows folder, for example, open the Security tab, and check the permissions. If the permissions allow the Users group only Read & Execute, List Folder Contents and Read, then it's okay. If the Users have something more, then it's not okay. This same goes for the Program Files folder, and All Users Startup and most important system folders.

3) AccessEnum: http://technet.microsoft.com/en-us/sysinternals/bb897332.aspx For advanced users, a good way to check even an entire file system for any potentially insecure permissions. This shows a simplified view of permissions, abstracting everything to Read, Write and Execute in Unix style. In AccessEnum output, limited users should have only Read permission to important system folders like those mentioned previously. Great little tool.

Since we're already discussing AccessEnum, might as well add that it allows you to easily check Registry permissions, as well. Limited users aren't allowed to write into HKLM (with some exceptions here and there). Beyond AccessEnum and all the above, there are also Windows services and their permissions, for those who really want to delve into possible ways to escalate privileges on a system by manipulating existing services (especially third party ones). But that is the subject of another topic.

[Dregg Heda]

I see, well thanks for your response Windchild!

[Keyboard_Commando]

Interesting stuff Windchild.

The caveats of the "frozen malware" scenario do seem somewhat remote. A good point I read somewhere made by, Mr. SSJ100, the freezing of malware under LUA buys a little more time for an anti virus definition to have then caught up with and flag a zero day.

I definitely haven't realised the scope of protection LUA offers. Reading one of your posts on another subject (MBR protection) pretty much persuaded me, and opened my eyes, that LUA is the way forwards. I didn't know operating LUA offers the best protection to the MBR.

So yeah, switching to LUA I am, and then see what happens when someone exploits LUA. :D

[Dregg Heda]

Afaik Privilege escalation exploits already exist for LUA.

[Keyboard_Commando]

-{ Quote: "Afaik Privilege escalation exploits already exist for LUA." }-


From what I can gather LUA has some access to start up reg keys. I'm sure Windchild can confirm or deny.

[Windchild]

-{ Quote: "Afaik Privilege escalation exploits already exist for LUA." }-

Indeed, and they wouldn't be called "privilege escalation" if there wasn't any escalation of privilege, that is, going from low privileges to high privileges, from LUA to admin/system. ;)

Of course, any complex code will have vulnerabilities. Then, they tend to get fixed as discovered. It's good to keep in mind that it is unrealistic to expect a security system to be 100 % impossible to bypass under any and all circumstances. That would require a perfect system, and humans are generally not capable of perfection in complex tasks. Therefore, there's really no point in switching from one system to another simply because the system got somehow exploited or bypassed. Today HIPS X gets bypassed, then it gets fixed. Tomorrow, HIPS Y gets bypassed, and the day after that, HIPS X again, but in a different way. Security is like that. It's a process, not something that is point-and-click for perfection, eternally.

-{ Quote: "From what I can gather LUA has some access to start up reg keys. I'm sure Windchild can confirm or deny." }-

Any limited user naturally has access to all the "automatic startup" locations for that limited user account, like HKCU Run keys and the user profile Startup folder. That's really more of a good thing than anything else - to me, at least, it's nice to be able to make some software that I frequently use start automatically even in a limited user account. It can't affect other accounts or the system, so that is not a problem, really. For blocking malicious software from running entirely, a whitelist type measure is needed, which is beyond LUA. SRP, for example, would fit that bill.

[wat0114]

Epic or not, your posts Windchild are highly informative and trustworthy, imo, as usual. You've helped clear up a lot of confusion and uncertainty for me through a number of your posts, especially the ones in this thread :)

[Keyboard_Commando]

AccessEnum is pretty cool, thanks for posting it. I have been taking a look at my XP LUA account privileges.

so far I found read/write

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows

I suppose in ultra paranoid state you could close these down anyway if you wanted.

[Windchild]

-{ Quote: "Epic or not, your posts Windchild are highly informative and trustworthy, imo, as usual. You've helped clear up a lot of confusion and uncertainty for me through a number of your posts, especially the ones in this thread :)" }-

Thanks. If I can help clear some confusion on any security topic, that's more than enough for me. :) Knowledge is power, especially in security.

-{ Quote: "
so far I found read/write

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows

I suppose in ultra paranoid state you could close these down anyway if you wanted." }-

Yeah, when you use AccessEnum in a limited account, you will see that. It's referring to the limited user account's Run and other similar keys, which in my experience a lot of folks who use LUA find useful to have around. You could take away write access to those keys if you wanted, and the only thing that would do is prevent that kind of autostart for that limited user account. Not a big loss, but the gain isn't that big, either.

[simmikie]

-{ Quote: "Hey mate, and thanks for the reply. The thing is that I'm looking more from the user's point of view, not the malware testers point of view. Any classical HIPS or anti-executable will stop this malware from even running (denying initial execution). If you're allowing everything willy nilly, then that's what I classify as "user error". That's why I keep emphasising the importance of having a good "security approach", rather than relying on specific programs to protect you.

All this testing is good stuff though, and it lets us understand better how these malware work. It also tells us that products like Shadow Defender etc can be genuinely bypassed too (and it seems frighteningly quite easily)." }-

yes virtualizers can be breached, and that is the bad news. the better news is that western block countries ie US & Europe aren't likely to see as much of this stuff as we could.

i recall a conversation i had a couple of years ago with Returnils Coldmoon, where i was inquiring about an upgrade or feature i wanted to see Returnil develop. Coldmoon basically told me, that particular upgrade was on the back-burner. it turns out Robodog (if i recall correctly) was eating Returnil's lunch in China (and many other if not all other virtualization products as well). the Chinese apparently use the internet somewhat differently then we do, for instance in the US. in China a healthy chunk of internet usage is done through internet cafes, which obviously use some level of virtualization to flush their machines. well Chinese malware authors have become very adept in writing code that blows up most virtualization products. the fortunate part for us is that for the most part the Chinese blackhats seem content with hacking these cafes, and perhaps enterprise and government institutions, and leaving us hapless private internet users alone (for the most part).

so i believe that for the overwhelming majority of infections we are likely to see, Returnil, Shadowdefender, etc, are still a strong solution to help secure our systems.

Mike

[Dregg Heda]

Or just combine your virtualiser with a HIPS/AE/policy management tool and it will be bullet proof.

[wat0114]

I'll be happy to test anything that can reputedly bust through Virtualbox, and subsequently infect the host system, at least on my machine :)

[Eirik]

-{ Quote: "blueridge is developing a program for protecting the mbr;) i forgot the name of the program an i think they will implement it in coming appguard;)" }-

Yes, its been available in a pre-released, standalone form for a few months. We haven't received ANY reports of any problems. More info and downloading without registration or restrictions can be found here: block MBR write operations (http://www.blueridgenetworks.com/support/mbguard/mbguard.php)

The MBRguard feature will be folded into AppGuard 1.4 and EdgeGuard 3.2 (?) when they are released this fall.

Cheers,

Eirik

[jmonge]

-{ Quote: "Yes, its been available in a pre-released, standalone form for a few months. We haven't received ANY reports of any problems. More info and downloading without registration or restrictions can be found here: block MBR write operations (http://www.blueridgenetworks.com/support/mbguard/mbguard.php)

The MBRguard feature will be folded into AppGuard 1.4 and EdgeGuard 3.2 (?) when they are released this fall.

Cheers,

Eirik" }-thanks Eirik

[aigle]

-{ Quote: "Yes, its been available in a pre-released, standalone form for a few months. We haven't received ANY reports of any problems. More info and downloading without registration or restrictions can be found here: block MBR write operations (http://www.blueridgenetworks.com/support/mbguard/mbguard.php)

The MBRguard feature will be folded into AppGuard 1.4 and EdgeGuard 3.2 (?) when they are released this fall.

Cheers,

Eirik" }-
Hmm... MBR only? What about direct disk access etc?