Malware bypassed ShadowSurfer

Indeed it does. 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.

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.

 

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.

 

Thanks for the verification

Mike

 

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.

 

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.

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

 

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.

 

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

 

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 He makes a lot of sense about LUA. I am moving to LUA when I get my hands on Win 7.

 

I'm kinda wondering the same thing

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

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

 

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? 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. 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!

 

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!

Editted to correct smilies.

 

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.

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.

 

I see, well thanks for your response Windchild!

 

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.

 

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.

 

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.

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.

 

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

 

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.

 

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.

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.

 

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

 

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

 

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

 

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

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

Cheers,

Eirik

 

thanks Eirik