Thoughts on minimal security

[trismegistos]

Originally Posted by Rmus

here are many lessons regarding security -- minimal or otherwise -- from this exploit.

1) It was a carefully crafted exploit aimed at millions of Win XP users, where the Windows Picture and Fax viewer was installed by default, using the .wmf file extension which would trigger automatically from code embedded in a web page. (Win98 and Win2K were not vulnerable to this attack vector. Win98 didn't have SHIMGVW.DLL and my Win2K didn't have the .wmf file type registered).

2) The average user was not likely to be aware of any of these things that were going on behind the scenes, and, unless they kept up with security matters, would probably not even know about the exploit itself until a patch was released. Does that mean they were automatically vulnerable? Maybe, maybe not...

3) Many knowledgeable people who follow security matters jump to conclusions without verifying sensational reports with information from tried and true security research sites. While this is not always possible in the early days of an exploit, careful users will not accept at face value everything they read, and will search around/wait for verifiable descriptions.

4) The use of another imaging program for this exploit would require user interaction, ie, clicking on a file to open in the program. How would such a file get onto the computer? Another possible attack vector suggested was email attachments (although I never heard of any in the wild). This would require the user to open such an attachment, violating a principle of sound policies about attachments:

• ignore those from unknown users,
  
  
• verify those from known users.

5) An application firewall is protection against untrusted applications being used to connect to the internet. PDF exploits, for example, use the PDF Reader to connect out.

6) This, as with most web embedded exploits, drops a binary executable payload. With protection in place against such payloads, users are protected from all such exploits, where AV is often a day or two away from getting signatures, as in this case, for both the .wmf file and for the executable payload.

7) For people with the above security and sound policies and procedures in place (the "maybe not" from 2) above), this exploit was not an imminent threat, notwithstanding all of the media hoopla! The same can be said for today's PDF exploits.

----
rich

As always, hats off to you!

In addition to your clear, comprehensive but concise explanations:

1. The already patched vulnerability is on Windows system's GDI32.dll, that's why all other applications requiring that library to render images would be vulnerable. Initially some security researchers had an impression that this was an intentional backdoor. Ironically, the same security researchers have mellowed down and have downplayed stuxnet's initial FOUR(4) zero day vulnerabilities as not intentional backdoors.

2. While users of other imaging programs require user interactions as you have mentioned. Explorer.exe, the Windows GUI shell in itself was vulnerable because of the vulnerable GDI32.dll. Just opening the windows folder containing the images(whatever renamed extensions it may be) or hovering the mouse over the images would trigger the exploit. No need for user interactions like clicking/double clicking.

What I have/do:

• All passwords and the like must be secure, but the ones I need to manually type have an obvious limit of extension;

• Properly updated drivers and a properly configured router with updated firmware from the developer;

• All built-in Win7 features that can improve security/privacy are ON by default, with small tweaks here and there to improve usability (like a less annoying UAC that doesn't dim the desktop);

• Fully enabled Microsoft Security Essentials;

• Maintain a small set of trusted software installed, updated and properly configured;

• Maintain a small set of online accounts properly configured;

• Maintain secure backups;

• Never follow untrusted links;

• On internet cafes and other public networks, I avoid to access online accounts, but if the necessity is big I use SafeKeys and then change passwords when possible.

[andyman35]

Extremely interesting thread,just what my brain needs to get working this morning.

I'm always intrigued by the concept of 'minimal security',I guess what constitutes a bare minimum pretty much depends on the individual user,their level of expertise and how risky their day-to-day activities.

My own thoughts are that after utilizing the OS built in features and the likes of EMET 2,some form of snapshot technology,added to sandboxing/virtualization should be sufficient in most cases.An on-demand AV scanner such as HMP for extra peace of mind perhaps.

[moriez]

Originally Posted by andyman35

I guess what constitutes a bare minimum pretty much depends on the individual user

I think this is what everybody agrees on. It's all a matter of preference.
For a home user like me, I have now tried to find some balance in security/performance but like to keep emphasis on performance. That translates in being able to use the OS and internet in a smooth manner and not being clearly hindered by complementary actions and degrading or hassling fore/background action. To use something like Sandboxie is just extra stuff to handle. This ofcourse goes for all 3rd party apps so I tried to seek out the one that I find really important. I have chosen (Comodo) Firewall over AV as the only 3rd party app because I prefer to control internet traffic and have nearly no worries over malware. I like to think I can keep that out by keeping processes in check and using noscript which will defend me from installing crap or a hi-jacked browser.

A big and hopefully helpful change is that I have made an image of the OS. That will safe me a lot of hassle if something ever might happen.

[Cutting_Edgetech]

In most cases I use a sliding scale. Balance of protection vs usability, and performance loss.

[andyman35]

Originally Posted by moriez

A big and hopefully helpful change is that I have made an image of the OS.

Changes don't come any bigger or more helpful than imaging the OS IMO.

[noone_particular]

Originally Posted by katio

Not any, but most. Not all vulns require execution. Default deny is not an answer to everything, you need at a minimum also privilege isolation.
I see you are using very old operating systems which weren't being designed with security in mind from the get go (MS really started dealing with security proactievely with XP SP2, still only bolted on none the less), that translates into lots of kernel holes which again means lots of critical patches, so I don't really share your viewpoint on this one.

Privilege escalation, malware executing at user level and gaining a higher level. If it doesn't execute, it isn't going to gain kernel access. Pointing out that older systems have kernel vulnerabilities proves very little as well. They're finding these in the newest systems as well. There are no secure Windows kernels.

Originally Posted by katio

Anything that uses "data" files instead of "executable" files really, default deny policies don't cover these. PaX, NX, DEP, ASLR... on the other hand do for some classes of bugs and isolation can mitigate to some extent. Also default deny will stop them if the shellcode is only used to drop an executable. But strictly speaking the first stage still "executes" successfully, despite your execution prevention, even if it can't actually do anything "useful".

Yes exploit code can execute, but if it doesn't manage to do anything useful, it means nothing. Sure, Microsoft will use such statistics to "prove" the superiority of their new systems, but in the end, all that matters is whether or not it successfully compromised your system.

A lot of the data exploits you mention can be mitigated by controlling parent-child settings, one of the strengths of classic HIPS. Example: PDF software and the constant stream of vulnerabilities that are being found in them. If the PDF software can't parent (launch) a browser, it won't be able to use the browser to download a malicious file. On the other hand, if you read PDFs in browser windows, the exploit will succeed because you've already given it everything it needs, especially if that browser is part of the OS itself. Configuration is everything because integration compromises security.

Originally Posted by katio

And then there are macros, interpreted code like perl and python and batch/bash/... scripts, again not stopped by default deny unless you deny execution of the interpreter itself.

There's several ways to mitigate these as well. Controlling what can parent the interpreter and restricting what child processes it can parent will prevent a lot of malicious script from running. Apps like the good old Script Sentry will allow you to view such scripts before allowing them. It can also be used to whitelist your own scripts and batch files while blocking others.

While default-deny is mostly identified with process whitelisting, it can be applied to much more than that by selecting apps that can enforce the policy in their area of coverage. The classic rule based firewall is a default-deny app for internet access. Proxomitron can be set up to apply the policy to web content. Classic HIPS can apply default-deny to process parent-child settings, which goes a long way towards isolating the apps that make up the attack surface. Combine this with the existing system tools and there isn't much left to attack and even less that an attacker can do with it.

I'm not disagreeing with you on anything you've said (and it doesn't really seem to be the other way round either, like you mention "isolation" too at the bottom, except *). But let me just point out this: What you suggest brings us further away from what was called "minimal security". Using built in SRP or Applocker and applying security updates in a timely manner is "minimal" by any means, a full fledged HIPS is not.

*
except maybe for this point:
Any kernel exploit which doesn't require the user to execute a program (that's I think the majority) has the theoretical potential to disable ALL protection and then own the system. Kernel design matters a lot in this regard and while Windows kernel was never secure (even fully grsec patched Linux or OpenBSD aren't) it's getting better. But real world effect is slim to none existent because of all the low hanging fruits, Adobe etc.

[Rmus]

noone_particular wrote:

Configuration is everything because integration compromises security.

How true!

At a minimum the user needs to look at all default configurations to see what is being compromised. He mentions PDFs opening in the browser window. Certainly not a good thing!

I call your attention to the BLADE-defender summary of URLs with remote code execution exploits embedded. Their summary is quite revealing.:

BLADE MALWARE URL ANALYSIS RESULTS
http://www.blade-defender.org/eval-lab/

The first box shows the browsers used. The second box (right hand column) shows the applications targeted . Note that the only browser targeted is IE. All of the other exploits target plug-ins. A plugin integrates the application (PDF reader, for example) with the browser, which is just the triggering mechanism, meaning that any browser has the potential to be used in this type of exploit.

(All year BLADE has harvested these URLs. BLADE ran the browsers with Plug-ins enabled in order to test their product's ability to catch the binary payload)

I would say that minimal security requires the user to change the default settings so that the plugins are either uninstalled (if not used, such as JAVA) or at least disabled. This means that in the case of reading a PDF file on line, the user will get a prompt, rather than the file being loaded automatically into the browser window. This will require an extra few seconds, but will protect should the user be redirected to a site which attempts to load a malicious PDF file into the browser, as in this old example:



As I followed the BLADE URLs this year, I discovered that using Opera with Plugins disabled, not a single exploit triggered in the dozens of URLs I tested. I knew this already, because I've done this in the past with other URLs from malware domain lists. Thus, I've always listed my Opera browser as a security product in my setup, along with my firewall, as preventing remote code execution exploits from triggering (firewall: Conficker.A worm, Port 445, for example). Other configurations necessary to change in Opera, of course, include javascript in site preferences, and other files in the download preferences that can contain executable or macro code, such as MSOffice documents, so that they prompt for a download, rather than opening automatically.

Firefox provides the same protection through its extensions and preferences.

Although using IE6 triggered most of the exploits when I used it, I suspect that IE8 can be configured to be as safe as the other browsers. Anyway, a good default-deny product will block the binary executable payload in an IE exploit, Google's lax of security against Aurora notwithstanding!

My Conclusion:

A minimum security set up starts with the browser and firewall. Note that these prevent the exploits from triggering, starting.

Then, other considerations depending on user habits/expertise, as has already been mentioned.

You really don't need much, if you understand how exploits are triggered: stop them from triggering and there is not much else to do, if you are starting from the standpoint of a minimum setup!

That leaves social engineering exploits, which is another topic indeed!

----
rich

[Konata Izumi]

Thank you for this awesome thread.
I am learning alot

Rmus has become one of the awesomest person I knew XD

[trismegistos]

Originally Posted by katio

except maybe for this point:
Any kernel exploit which doesn't require the user to execute a program (that's I think the majority) has the theoretical potential to disable ALL protection and then own the system. Kernel design matters a lot in this regard and while Windows kernel was never secure (even fully grsec patched Linux or OpenBSD aren't) it's getting better. But real world effect is slim to none existent because of all the low hanging fruits, Adobe etc.

The most sophisticated malware-Stuxnet's three of four zero day vulnerabilities are windows kernel vulnerabilities. As everybody knows the non-kernel vulnerability on shell32.dll also as "known dlls vulnerability" or lnk vulnerability and exploit or binary planting is already patched. Two of the Windows kernel vulnerabilities on win32k.sys kernel driver were patched last tuesday... http://www.h-online.com/security/new...n-1106886.html
Still one security hole remains unpatched.

I wonder if these 4 zero day vulnerabilities are intentional security holes(intentional backdoors to the paranoids) to wean others from running SP2 to generate more sales as my idol, noone_particular puts it.

[noone_particular]

But let me just point out this: What you suggest brings us further away from what was called "minimal security". Using built in SRP or Applocker and applying security updates in a timely manner is "minimal" by any means, a full fledged HIPS is not.

We have gone full circle here and are back at one of the early questions:
"What defines minimal security?"
For this, we have completely different definitions. I would consider classic HIPS as minimal due to its light system load and in the case of SSM, one running process. OTOH, I'd call an AV heavy due to its multiple processes and heavier system load. I have a hard time looking at anything built into Windows and calling it light. Compared to what it was, Windows is a hog. I'm also not completely trusting of Microsoft and use 3rd party apps to control the activities of their software.

Any kernel exploit which doesn't require the user to execute a program (that's I think the majority) has the theoretical potential to disable ALL protection and then own the system. Kernel design matters a lot in this regard and while Windows kernel was never secure (even fully grsec patched Linux or OpenBSD aren't) it's getting better. But real world effect is slim to none existent because of all the low hanging fruits, Adobe etc.

If Adobe keeps going at the current rate, they might replace IE6 as the most exploited software. Adobe Acrobat is one of the first things I get rid of, if it's on any PC I obtain. Flash is its own problem. On my PCs, Proxomitron filters it by default. If I allow it past Proxomitron, Flashblock lets me choose which ones I want to see.

We seem to agree on what needs to be done, but use different methods to get there. I use the HIPS to effectively isolate the attack surface apps from the rest of the system, a sort of policy sandbox instead of an app like Sandboxie. It's not that Sandboxie isn't good. It's just not the best choice for implementing a default-deny policy. For a policy based on attack surface isolation, it's an ideal choice. Besides the default-deny policy, the next most important thing to do is to minimize the attack surface. Since I run older operating systems, I can get rid of the biggest vulnerability of all, Internet Explorer. IMO, when the browser is part of the operating system, it makes the operating system part of the attack surface. If IE6 did anything, it proved just how bad of an idea that integration was. In that other thread where MS claims that the older systems are more vulnerable, that's probably because they all came with IE6.

[vasa1]

Originally Posted by noone_particular

...Example: PDF software and the constant stream of vulnerabilities that are being found in them. If the PDF software can't parent (launch) a browser, it won't be able to use the browser to download a malicious file. On the other hand, if you read PDFs in browser windows, the exploit will succeed because you've already given it everything it needs, especially if that browser is part of the OS itself. Configuration is everything because integration compromises security.
...

I'd like to add my appreciation here

Phrases like enriching the user experience and seamless integration give me goose bumps.