From Erik\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'s IT-Security notes
Jump to: navigation, search

EZSecurity Bulletin for June of 2011

INTRO

The summer is here but there’s really no change in pace throughout the IT-security world. Adobe and Microsoft just released critical patches and Siemens took another hit for their poor handling of security incidents. Attacks by crackers on high profile targets are so common, they’re hard to keep track of. So, no rest for the weary (sysadmins). Internet Explorer 6 is dead… Sorta kinda.

After working so hard to get people to ditch Internet Explorer 6, Microsoft can’t be too happy that the barely working browser still crawls through the desert and refuses to die. With a market share of 10%, it’s still not pushing up the daisies. 1) But when will Microsoft finally call it quits? For the last supported wasteland of computing archeology that is Windows XP service pack 3, you can still get security patches for IE6 until the 8th of April 2014. But what about Windows 2003? Oh, no problem, it will be supported with IE 6 until the 13th of July 2010. Ooops, that was a year ago. In short, Internet Explorer 6 must be upgraded on Windows 2003 server. Preferably a year ago.

1) http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2

But enough about the albatross, onwards!

MICROSOFT SECURITY BULLETIN SUMMARY FOR JUNE OF 2011

As per usual, Microsoft release their security bulletins the second Tuesday every month. This month comes along with 16 bulletins. Recommendation: patching should be done as soon as possible, which means next patch window.

Critical
MS11-052 - Vulnerability in Vector Markup Language Could Allow Remote Code Execution (2544521)
MS11-050 - Cumulative Security Update for Internet Explorer (2530548)
MS11-049 - Vulnerability in the Microsoft XML Editor Could Allow Information Disclosure (2543893)
MS11-044 - Vulnerability in .NET Framework Could Allow Remote Code Execution (2538814)
MS11-043 - Vulnerability in SMB Client Could Allow Remote Code Execution (2536276)
MS11-042 - Vulnerabilities in Distributed File System Could Allow Remote Code Execution (2535512)
MS11-041 - Vulnerability in Windows Kernel-Mode Drivers Could Allow Remote Code Execution (2525694)
MS11-040 - Vulnerability in Threat Management Gateway Firewall Client Could Cause Remote Code Execution (2520426)
MS11-039 - Vulnerability in .NET Framework and Microsoft Silverlight Could Allow Remote Code Execution (2514842)
MS11-038 - Vulnerability in OLE Automation Could Allow Remote Code Execution (2476490)
Important
MS11-051 - Vulnerability in Active Directory Certificate Services Web Enrollment Could Allow Elevation of Privilege (2518295)
MS11-048 - Vulnerability in SMB Server Could Allow Denial of Service (2536275) 
MS11-047 - Vulnerability in Microsoft Hyper-V could Cause Denial of Service (2525835)
MS11-046 - Vulnerability in Ancillary Function Driver Could Allow Elevation of Privilege (2503665)
MS11-045 - Vulnerabilities in Microsoft Excel Could Allow Remote Code Execution (2537146)
MS11-037 - Vulnerability in MHTML Could Allow Information Disclosure (2544893)

CAN’T SEE THE FOREST FOR THE LOGS?

Do you remember those old analog TVs, where you could pull the antenna cable out to look at the whirling static of white and black dots? For all intents and purposes, what you see is more or less random and no one could possibly call what you see on the TV-screen “information”. Or could they? Actually, when we talk about “information”, we often mean “useful information”. The bad news is that it can be hard to know what is useful now or in the future.

When working with computer generated logs, this can be disastrous. Logs? I’m not talking about the kind that used to be trees. Many applications store informational, warning and alert events in files or databases. Those databases and files are what we call logs. We often install systems and applications without thinking why and what should be written into them. All logs can give potential clues when we try to track an intrusion or when we try to find the cause of a failure. But when the time comes to look for those clues, they may not be there for us and there are quite a few reasons for that:

We have no plan why we log

Ask operations and they tell you logs are for troubleshooting. The guys in security talk about auditing and forensics and the web master needs to know how the site is doing on the big market called the Internet (assuming we’re talking about a web site, off course). Logs can cater to all those needs, if we set the system up that way. But that is a job for an IT-architect and should be done long before the system is actually built. At this time I want to remind you that organizations should have a set of written policies dealing with security and rules. This is outside the scope of this discussion, but the relevant parts of the security policies must be used to decide how to build the logging architecture.

We wait too long

Logs are often setup to start overwriting the oldest entries after some time or when they get larger than a preset size. In short, we could be too late to actually see something, since the log data has been erased. The solution is to understand what will use the logs for and how much history we need. This should be decided when we design the system and must be applied system wide. Yup, I’m repeating myself, I know!

We log all the wrong things and forget to log the right things

Did you know that the web server Microsoft Internet Information Services 6.0 doesn’t log the referer (yes it’s spelled that way!) tag by default? The referer (sic!) tag can show the address of the site the user was surfing on, when he clicked on a link to your site. It’s probably not so interesting to log just for security purposes, but it is very important if you want to know which search phrases or sites link to your site. Do you only log failed logon attempts? Then you won’t know when they actually managed to break in.

We fail to understand the consequences of our settings

If you setup your logs to rollover after a specified time or size, you don’t have to worry about them filling up the disk. Computer criminals know that this is a common practice and often try to hide their tracks by generating a massive amount of events in relevant logs until they rollover and delete the evidence. If we allow it to fill up, an attacker may be able to cause a system to fail by generating events until the system cannot log anything more. If we don’t transfer our logs to a secure system, an attacker that succeeds in taking over a system can destroy all evidence by clearing the logs. And if we do transfer the logs, the total cost of ownership goes up. All choices have their merits and flaws.

We log inconsequentially

The days of everything being “one server – one system” are long gone. Many larger systems consist of servers, network equipment and even cloud services working in unison. We must make sure we log everything as dictated by the policy on all parts of the system where possible.

… And my favorite: we have no idea what to do with it!

Ok, so you now have megabytes of data at your disposal. Whether you want to detect problems and security issues before they happen or want information enough to nail the attackers afterwards, you can seldom just rely on reading the logs manually. You need tools, procedures and scheduled time for it. This is a huge area and there are hordes of free and commercial products and appliances that can help you finding what you’re looking for or hide it from your eyes by being totally useless tools. The right tools for intrusion detection may be totally useless when it comes to troubleshooting stability issues.

This post in one sentence: thought applied before action saves the future.

LINKS

The official bulletins from Microsoft:
http://www.microsoft.com/technet/security/bulletin/ms11-jun.mspx

ISC Sans's monthly Microsoft-analysis is always a good read:
http://isc.sans.org/diary.html?storyid=11050

All back-issues of this newsletter can be found here:
https://secure.ericade.net/security/index.php/SECBulletins

And on the EZSecurity blog at Tieto DF:
http://df.tieto.com/Blogs/EZSecurity/

My private blog:
http://erik.zalitis.se/

Bruce Schneier’s excellent news letter:
http://www.schneier.com/crypto-gram.html

A collection of useful security links:
https://secure.ericade.net/security/index.php/Security_links

A good site to check for known vulnerabilities for your favorite programs:
http://secunia.com/

What's the general state of the Internet?:
http://isc.sans.org/

OWASP Sweden's email list archive:
https://lists.owasp.org/pipermail/owasp-sweden/

Recommended for you developers out there:
http://www.owasp.org/index.php/Main_Page

My own, random knowledge base:
https://secure.ericade.net/security/index.php/portal:Kb

Regards
Erik Zalitis
Lead Infrastructure Architect
CISSP
Certified Ethical Hacker
MCITP:EA
MCSE:Security 2003
MCSE:Messaging 2003
Citrix Certified Administrator for PS4.
VMware Certified Professional on VI3
ITIL Foundations
Mobile: + 46 (0)70 673 07 54