0-Days Not As Big of a Threat as You Think

I use a few alpha and beta software, and other software, that I constantly upgrade to see latest news and versions fixing issues I'm experiencing. I have a default-deny policy. I got no issues with it. Everything I place in Program Files is allowed, based on certain conditions, including newest versions.

It depends on the tool you use to apply a default-deny policy. If the application/tool you use to apply a default-deny policy is weak on features, then for sure it will be a living hell to deal with such policy.

And, since when is a system static? Unless the user, including administrators, doesn't update the O.S and applications and don't open files, a system is never static. Changes are always happening, even with those rollback applications. Even those get upgrades, don't they?

If you want a static system, then install the operating system and the applications, but never use it. That way, is 100% static.

Otherwise, I just don't see how you're staying with a static system? Am I failing to see something?

 

That really depends on whether the user wants a tool or a toy. In a lot of the homes where I've serviced PCs, the parents want something they can trust while the kids want a game center. That said, if the hardware is good, there's no reason they can't have both. The play system can be virtual while the host system is default-deny secured.

I haven't seen this "proper" system either. I don't see any real way a secure, non-static system could be achieved for the average user without someone else having total control over it, which itself would be completely unacceptable. I wouldn't be surprised if that's coming though, where users will be limited to choosing from lists of "approved software".

 

Would this be so wrong? If Microsoft's application store was vetted and approved?

Anyways, you can have a system where the user is able to install whatever the ywant without security risks. As I've said either in another topic or another forum, proper sandboxing and restriction levels (emphasis on multiple levels) combined with specific heuristics is all an OS should need.

Or not. I can think of a few ways to get around the system I would consider ideal but they don't include 0-days or social engineering.

 

mOOnblOOd,
I'll try to clarify this a bit. My operating systems are each on their own separate partition. All user files, documents, etc are on a separate data partition. The desktops for each OS are also on this partition, as are the few user apps that store files in their own folders. The operating systems share a dedicated swap partition. The browser cache(s) and temp folders are on a Ramdisk, self cleaning. It's the system partitions that are nearly static on my system. The partitions/drives that hold data, backups, virtual systems, etc are not.

The operating systems I use by choice are unsupported. There are no official updates for them. The only time I update the applications is when the change is something I need or want. Most of them I don't want changed. On each reboot, the existing registry is replaced by a clean, optimized, MRU free copy. The only time that backup copy changes is when I update certain applications. Because of this arrangement, my system partitions need very little maintenance. There's also no fragmentation. The system partitions remain in near optimum condition so there's very little performance change over time.

 

This doesn't have to be the case.

As with a lot of terms, such as "whitelisting," "Default-Deny" comes in many guises.

In its simplest form, either by means of a Group Policy configured within the OS, or a security product, no executable file not already on the system (White Listed) is permitted to run without the user's permission.

This takes care of the Drive-by Download attack -- 0-Day or not.

With a firm user policy of not installing anything the user didn't go looking for, the user will not be tricked into granting permission when confronted with a web site popup.

The fake update popups are also handled by a firm user policy of updating from the vendor's site only, not from a link in a popup or email. A firm user policy of monitoring the update sites of the software is an added protection to this policy. Users have to take some responsibility for these things, and I've not found it difficult to explain this to those who will listen.

Now, when the user chooses to install a program, the user grants permission. This is accomplished in various ways, depending on how Default-Deny is set up. With a program such as Anti-Executable, it's several mouse clicks and a password to permit the installation. If this makes the system "static,"I don't think that's much effort at all for the peace of mind of knowing that nothing can install without permission.

No matter the security setup, Default-Deny or not, the user has to decide whether or not the program to install is clean. The user will trust either a scanner, or the source of the program.

But this is a completely different topic and has nothing to do with the way I think of employing Default-Deny.

regards,

-rich

 

Gotcha. Yes, default-deny can be looked at in different ways. The one taht you just posted I naturally agree with.

 

would Allow-Deny prevent/warn when installing a browser addon?

 

What's wrong with Microsoft approved applications only? Would you expect such a list to include torrent or P2P software, Tor, Strong file or e-mail encryption, NMAP, Classic HIPS, or a lot of the Open Source alternatives we have now? Software selection aside, for me it's a much more basic issue. I bought the system. It is mine to do with as I choose, whether they "approve" of it or not. What I install, use, change, etc is also none of their business. I won't use a system that attempts to restrict or interfere with the choices I make or calls home about them.

A virtual system on a default-deny secured host fills that role quite well.

We each have different definitions of "ideal'. When running in user mode (the default mode), I don't worry about zero-day stuff or social engineering getting someone to launch an unknown. It's not possible in user mode. Of course, if social engineering gets a user to reveal personal info, there's not much any security arrangement can do to stop it, but that's a whole different problem.

 

I'm assuming you meant default-deny. It can be applied that way. Default-deny can be applied to any aspect of the system that you want. Preventing the installing of add-ons would be done via the browsers own settings. Some 3rd party security apps also have a "window watcher" feature that can block users access to user specified interfaces, system folders, etc, making it much more difficult for another user to gain access to those parts of the system. With SSM for instance, when a user opens a "watched window" SSM immediately closes it. I've used it to block access to the control panel, folder options, services, and others. For a Mozilla browser, I'd add the preferences screen and about:config to the list.

 

If they were submitted to the store they could very well be accepted. And as long as one has the option to install outside of the store I can only see benefits.

 

From Microsoft: Choose Your Words Carefully:

 

From the blog, "Microsoft: Choose Your Words Carefully" --

IMO, the blog should choose its words carefully, or at least, point to the source of the quote, for I've read summaries of the SIR, and just now downloaded the entire SIR, and do not find the word "overblown" used.

Rather, is this statement:

I suppose a reader can infer various levels of concern from Microsoft, depending on one's point of view.

But the blog.bit9.com article opens the door for other considerations:

Those attacks, and those listed in Microsoft's SIR, had malware executables as their payload.

The blog.bit9.com article notes:

Actually, "ways to mitigate or prevent Zero Days" in the form of Application White Listing (or Default-Deny) have been known and discussed for at least six years:

An Ounce of Prevention: Risk Management Approach is the Key to Good Security Process
Jan. 05
http://www.infosec.co.uk/ExhibitorLibrary/123/An_Ounce_of_Prevention.pdf

Application whitelisting
http://advosys.ca/viewpoints/2006/10/windows-application-whitelisting/
October 14th, 2006

This bit9.com blog seems to be an arm of bit9.com, which is rather curious, since that company is one of the leaders in Enterprise Security:

http://www.bit9.com/

Returning full circle to the blog,

Well, The famous Aurora APT attack against Google and others could have been easily prevented with proper security in place:

Google Hack Attack Was Ultra Sophisticated, New Details Show
http://www.wired.com/threatlevel/2010/01/operation-aurora/

An Insight into the Aurora Communication Protocol
http://blogs.mcafee.com/mcafee-labs/an-insight-into-the-aurora-communication-protocol

And so it goes...


----
rich

 

I use a simple whitelist approach, supplied by the OS (Vista or Windows7)

a) deny execution of any downloaded executable (1806-trick)
b) deny elevation from medium to high rights of any unsigned program (UAC-trick)
c) allow only specified applications to go outbound in the Windows FireWall (STEM-trick)

On top of that using the low rights sandbox of Chrome (low rights objects can't rouch the rest of your system). Chrome has a history of closing exploits within a day (see https://www.wilderssecurity.com/showpost.php?p=1968526&postcount=40) and has a history of staying on its feet at the Pawn2Own contest. So malware authors should be able to write exploitable malware within a day, which would be a real feat since only a few theoretical exploits are usable in practice.

So being an average user having auto updating/patching enabled, I would be (statistically) unlikely unlucky to be hit by a zero-day exploit which would defeat both Chrome's sandbox and the Microsoft OS-protections. Possibly the same chance as being killed in a car accident. For my work I am at least two-to-three hours a day driving a car, at work I also use a computer for at least two hours a day for work and often one hour for fun at home in the evening. The NCAP status, airbag and safety belt of my car are sufficient security to me as are chrome's sandbox and the UAC deny elevation trick and 1806 deny driveby trick of the OS do fine. For the rest I rely on my driving skills and safe-hex practises.

So putting risk in perspective does not mean that one does not need security. What is sufficient and paranoid is often scaled on a two dimensional axis (based on impact and risk), allways denying the high impact of the third dimension: user behavior (ranging from stupid to safe IMO)

 

You live in Holland and you drive?? You should ride a bike in the best cycling country in the world Won't that statistically improve your security setup's chances of avoiding malware as compared to your chances of getting in an accident riding a bike?

 

Yes at least half of the year it is no fun on a bike. Therefore I cycle in-doors and it is called spinning We have projections of nice canadian scenery while spinning though

I have two bikes a ducati 1078 monster and a laverda 1000 SF (yes one of the few build thirty years ago with upside down front, mono-lever suspension at the back and four piston brakes at the front). Riding a (motor) bike does not statiscally improve my security

 

Very cool bikes Mine's an old 90's Kona Explosif, well maintained. 6 months is about right for here in Calgary, at least for regular folks like myself; I just finished daily commuting 27 km round trip, from May to November, but there are some hardcore renegades who cycle all year, even in minus 20's with the wind

*EDIT*

only now I realize you own motor bikes! Wow, the Ducati looks FAST

 

0- Days may not be as big as a threat except in cases of targetted attacks or as in the most recent zero day kernel exploit of the Ducu malware(Son of Stuxnet fame)...

Exploit -> kernel -> driver in kernel -> loader dll in services.exe -> big pnf in services.exe -> big pnf installing from lsass or AV process.



[ from http://www.securelist.com/en/blog/208193243/The_Duqu_Saga_Continues_Enter_Mr_B_Jason_and_TVs_Dexter ]


The exploit is on the "Vulnerability in TrueType font parsing" which could allow elevation of privileges and arbitrary code execution. In this case, the shellcode executed goes into the kernelmode, win32k.sys, gaining Ring Zero or kernel or the highest privileges bypassing most security, AVs, LUA-SRP, Applocker, probably AE and possibly even Sandboxie and some classical HIPS, once the recipient/victim of a corporation targetted for e.g. opens a seemingly benign Microsoft document file.

This is what is HD Moore is warning, a kernel exploit that doesn't require an initial remote or local arbitrary code execution unlike the usual local kernel exploits(EoP) requiring an initial exploit of those types to gain local access. Mostly, local kernel exploits would be pushed by a dropper executable(obfuscated exe's or dlls) to elevate privileges. Most AVs, and such protections like SRP, Applocker, AE would easily detect those payloads.

I am not sure how most classical HIPS would fare in this case of stopping the loading of the malicious driver depending on how deep down to the kernel it guards.

This is one rare case, AE would probably not block as the payload is not an ordinary executable but a kernel driver in kernel space and the initial dropper is the exploit's shellcode itself before loading the main dropper, the malicious dll.

SRP even with the grainier dll control would fail to catch the malicious dll, main dropper.

Sandboxie can be bypassed by these types of kernel exploits as implied by tzuk's statements... http://www.sandboxie.com/phpbb/viewtopic.php?p=53719

Not sure how EMET, ASLR, DEP, Sehop, et al will be successful in preventing the exploit of this malwae.

Only with the actual malware testing with the actual document file containing the kernel exploit, the kernel driver and the malicious dll can we say for certain.

Fortunately for us, this is easy to mitigate by installing the MS' Fix It program for the meanwhile to block the access to t2embedd.dll as we wait for the patch. T2embedd.dll was the same buggy dll which had been patched before (as in the past EOT vulnerability). I preferred unregistering it permanently which might, however, block some functionalities in certain programs. Some functionalities, which for now I don't really need and have better alternatives.

 

It would bypass Sandboxie and just about everything else.

The problem with 0days isn't how common they are, it's that when you do run into one there is virtually nothing you can do to stop it.

Currently it's easier for malware authors to just exploit 3rd party - that's sufficient for a huge amount of the userbase. They don't even need new exploits they can use old as hell IE5 ones and get a nice chunk of users. Or social engineering.

But kernel exploits exist and we'll continue to see them.

 

A few exceptions are properly implemented Host-side IPS such as Malware Defender, SSM, PG as all can detect the kernel driver loading and can detect any modification on system processes as well as the core system files. However, some HIPS particularly on those AV suites have defaultly whitelisted some critical system processes for user comfort, those could be bypassed easily.

SSM in particular have worked effectively even in non-protected mode DOS environment (Windows 98 ), where there is no security boundary between core system processes and user-side application processes unlike the NT's protected mode.

Can be stopped as described above.

That's because of the decision to bring some functions that can be implemented in the usermode as close to the kernel for increased performance just like the Graphics rendering by GDI32.dll whereas a WMF exploit could affect the kernel win32k.sys and you have privilege escalation.

You forgot to mention those 3rd party kernel driver vulnerabilities(AVs, firewalls) which open potential holes into the kernel.

 

If I'm exploiting the kernel I do not necessarily need to load a kernel level driver or modify system processes. As long as they can interact with the system (which... everything can) you can get a kernel level exploit. A really noisy hips might be able to stop a program before it starts the exploit. At that point it can depend on how the exploit is achieved.

HIPS won't do too much, maybe a network IPS can.

Which is why MS is moving that stuff out of the kernel. I don't think it was for performance - just poor design.

But they'll exist in the kernel for a long time.

 

What? HIPS won't do much?
It can prevent low level disk access or rewriting the MBR for e.g. Can prevent a shell from modifying certain core system files, etc.
HIPS can stop the payload for e.g if configured, can block the command shell.

 

Yeah, hence:

The problem with noisy hips is they're inability to convey the issue to the user/ loads of FPs.

I like the idea of preventing kernel level exploits at the network level but there's no implementation for that that I've seen.

 

Nope, not just before the exploit starts but afterwards, what the shellcode actually does can be intercepted by HIPS. Can detect a shell or prevent the occurence of a shell or can prevent a shell from tunneling to home, etc.

That's the negative side. But it is possible to make certain rules or policy sandbox and still a lockdown protection with no "noise" at all. HIPS is a great learning experience and not for everybody.

IDS or IPS network side only block shellcodes or exploits which they have a signature of.

 

How can it stop it if it's in the kernel? If the kernel wants to open a port your HIPS isn't going to be able to stop it. Or at least I doubt it.

There are methods using heuristic signatures. Signature based network prevention isn't useful imo.

 

Those with kernel hooks on Create Connection port, Connect Port etc can prevent that opening of port. Firewall rules can also be hardened so that the usual shell trying to connect home can be detected.

Metasploit framework meterpreter and commandshells requires payload for e.g. to connect home.