PHP 5.4.3 and PHP 5.3.13 Released
In addition to other announcements, the folks behind PHP have released new versions in the 5.3 and 5.4 branches to address a couple of security issues.
5.3.13 addresses CVE-2012-2311 and 5.4.3 addresses both CVE-2012-2311 and CVE-2012-2329.
Details are available here: http://www.php.net/archive/2012.php#id2012-05-08-1
Incident-response without NTP
While we patiently await the arrival of this month's patches from Microsoft (and everyone else who publishes today) I have a little thought experiment for you. We all know that the internet doesn't work too efficiently if DNS isn't working or present. NTP is just as critical for your security infrastructure. Without reliable clock synchronization, piecing together what happened during an incident can become extremely difficult.
Consider a hypothetical services network and DMZ: there's an external firewall, a couple of webservers, an inner firewall with a database server behind it. Let's also assume that something bad happened to the webservers a couple of months ago and you've been brought in as a consultant to piece together the order of events and figure out what the attacker did. The web administration team, and the database team, and the firewall team have all provided your request for logs and you've got them on your system of choice.
More About NTP
For a complete background on NTP I recommend: http://www.ntp.org/ntpfaq
There are two main types of clock error that we are concerned with in this example:
- Clock Skew also called Accuracy, determines how close a clock is to an official time reference.
- Clock Drift or the change in accuracy over time.
Common clock hardware is not very accurate; an error of 0.001% causes a clock to be off by nearly one second per day. We can expect most clocks to have one second of drift every 2 days. The oscillator used in computer clocks can be influenced by changes in local temperature, and the quality of the electricity feeding the system. Update: Joanne wrote in to point out that the accuracies that I've cited in this paragraph are an order of magnitude better than what one would expect in computer hardware. We'll see later in some example data how optimistic my values were.
Today's Challenge
How do you begin order the events between the systems? First I'll solicit general approaches via comments and email, later I'll summarize and provide some example data to illustrate the most popular/promising approaches.
Example Data
Let's take a look at what the web team and the firewall team sent to us.
Date Time Event Epoch
Web1:
1/1/1972 13:24:04 First Request from badguy 262990.55837962962963
1/1/1972 13:24:04 2nd Request from badguy 262990.55837962962963
1/1/1972 13:24:04 3rd Request from badguy 262990.55837962962963
1/1/1972 13:24:05 4th Request from badguy 262990.558391203703704
1/1/1972 13:24:09 5th Request from badguy 262990.5584375
Web 2:
1/1/1972 13:25:37 First Request from badguy 262990.559456018518519
1/1/1972 13:25:41 2nd Request from badguy 262990.559502314814815
1/1/1972 13:25:57 3rd Request from badguy 262990.5596875
1/1/1972 13:26:49 4th Request from badguy 262990.560289351851852
1/1/1972 13:26:59 5th Request from badguy 262990.560405092592593
1/1/1972 13:27:42 6th Request from badguy 262990.560902777777778
Firewall:
1/1/1972 7:00:41 Accept "tcp_80" "34153" "bad_guy_ip" "web1" 262990.292141203703704
1/1/1972 7:00:43 Accept "tcp_80" "34154" "bad_guy_ip" "web1" 262990.292164351851852
1/1/1972 7:00:45 Accept "tcp_80" "34155" "bad_guy_ip" "web1" 262990.2921875
1/1/1972 7:00:49 Accept "tcp_80" "34156" "bad_guy_ip" "web1" 262990.292233796296296
1/1/1972 7:00:52 Accept "tcp_80" "34157" "bad_guy_ip" "web1" 262990.292268518518518
1/1/1972 7:02:27 Accept "tcp_80" "59498" "bad_guy_ip" "web2" 262990.293368055555556
1/1/1972 7:02:31 Accept "tcp_80" "59499" "bad_guy_ip" "web2" 262990.293414351851852
1/1/1972 7:02:47 Accept "tcp_80" "59500" "bad_guy_ip" "web2" 262990.293599537037037
1/1/1972 7:03:39 Accept "tcp_80" "59501" "bad_guy_ip" "web2" 262990.294201388888889
1/1/1972 7:03:49 Accept "tcp_80" "59502" "bad_guy_ip" "web2" 262990.29431712962963
1/1/1972 7:04:32 Accept "tcp_80" "59503" "bad_guy_ip" "web2" 262990.294814814814815
I've merged added the epoch column since that will help some folks apply their favorite methods and trimmed the logs from the three systems down to the activity of one suspicious IP address.
My Naive Approach
My initial assumption is that we should be able to account for the bias between the clocks on sufficiently-small windows of time. We will not likely come up with a simple formula to correct several months-worth of logs. However, for critical periods, we should be able to knit together log events from multiple systems, identify the clock bias, and account for it in the ultimate investigative timeline. So my approach is to pick a small time-frame of events, pick a system to be the reference point, tie events together manually a bit, and plot it out to see if there is a simple linear relationship, or if we have other issues.
Immediately we see that there's clearly a timezone difference between the web team and the firewall team, that's not a big deal at the moment. Initially we may feel in luck that the firewall can act as a semi-reliable observer to compare the attack against web1 and web2. Maybe fortune will continue and we can simply shift the times a little to account for clock skew. The event was only a few seconds so the window should be small enough that drift should be undetectable, right?
No, something's not right. If we compare the elapsed time of the event for web1 and web2 using the firewall as a frame of reference. While the firewall and web2 agree that it was visited over 2 minutes and 5 seconds, web1 records an elapsed time of 5 seconds, while the firewall indicates 11 between the first accept and the last accept.
Let's plot out the times from the web server vs. the time noted by the firewall. Ideally we should see something of a straight line with a slope of one and a zero-intercept of zero. In this case, we're hoping for a slope near one, and a zero-intercept that will help identify the timezone used by the firewall or the webservers.
How about a closer look at those two:
Web 1 recorded the first few probes as happening in the same second. Over time though (draw a line between the first and last event) and it's a bit more in agreement with web2.
A Side Note About the Comments
The comments strayed off-topic pretty quickly today, but there are some nice gems in there about deploying and monitoring NTP. They're worth a look.
May Adobe Security Bulletins
Adobe has released their monthly security bulletins today:
- Security Bulletin for Adobe Illustrator - APSB12-10 - http://www.adobe.com/support/security/bulletins/apsb12-10.html
- Security Bulletin for Adobe Photoshop - APSB12-11- http://www.adobe.com/support/security/bulletins/apsb12-11.html
- Security Bulletin for Adobe Flash Professional - APSB12-12 - http://www.adobe.com/support/security/bulletins/apsb12-12.html
- Security update available for Adobe Shockwave Player - APSB12-13 - http://www.adobe.com/support/security/bulletins/apsb12-13.html
Note that APSB12-12 addresses Flash Professional, not the flash player add-on to your browser. Also of note is that the first three bulletins simply inform users that their current version of the software is vulnerable, and that the upgraded version isn't. No free security patch options, just pay to upgrade. At least the Shockwave player update is free.
Windows Firewall Bypass Vulnerability and NetBIOS NS
One of the attacks I always perform when doing internal penetration tests is NetBIOS Name Spoofing. NetBIOS has been a golden mine for penetration testers for years – many good articles about how to use NBNS spoofing have been written, and Metasploit comes with a module that allows you to easily abuse NBNS in order to collect LM and NT hashes from victim machines (of course, depending if LANMAN has been disabled or not).
I wrote a diary about this back in January so if you want to see details on how to abuse this I’d suggest that you read http://isc.sans.edu/diary.html?storyid=12454 first.
However, attacking clients, retrieving their LM/NT hashes and cracking them, as fun as it is, is only half of the job a penetration tester has to do. Besides capturing the flag, the report you produce must also include recommendations on how to mitigate the detected vulnerability otherwise it is really useless for your client (no matter how cool it is for us penetration testers to pwn something).
So after seeing NBNS being abused in many internal penetration tests (all?) I started checking what potential security controls we have at our disposal to prevent such attacks, or at least to make them less effective.
Obviously, the best way to prevent NBNS spoofing attacks is to completely disable NetBIOS name resolution. However, this maybe be easier said than done – from the diary I posted before (link above) it appears that there are many other services that still depend on NBNS.
Since Windows operating systems now come with a firewall (“Windows firewall” with Windows XP SP2 and “Windows Firewall with Advanced Security” with Vista and newer OSes) that can have multiple policies, depending on the current location of the machine (home, work or public networks), this sounded like a perfect idea for preventing NBNS attacks. In this scenario, an administrator that controls client machines through group policies could allow NBNS in home and work networks and disable it completely in public networks. While not perfect, this still offers a certain (and I’d say decent) amount of protection.
However, while testing this I noticed that the Windows firewall has a nasty bypass vulnerability (the now patched CVE-2012-0174 vulnerability).
In order to test it I turned on both inbound and outbound firewalls – remember that the Windows built-in firewall does not stop outbound connections by default:
Besides this, NBNS rules had to be disabled manually, in order to prevent NB-Name-Out network traffic. By stopping this traffic we would make sure that an attacker cannot abuse NBNS spoofing attacks, since the built-in firewall would stop all such outgoing requests. You can see the rules, with their respective profiles in the following picture:
After setting this, I expected that my NBNS spoofing attacks will fail. However, that did not happen – the attacks were still successful, and I was able to see NBNS queries on my local network. After setting up logging in the Windows firewall as well, I confirmed that Windows was happily letting this traffic leave, despite all the rules that have been set above:
2012-01-29 11:07:21 ALLOW UDP 192.168.161.137 192.168.161.255 137 137 0 - - - - - - - SEND
This log shows a NBNS query destined to the local network’s broadcast address.
The issue here is pretty clear – this means that an organization’s administrator who set such rules to protect his clients when they leave the organization’s network cannot rely on the built-in Windows firewall!
And, if you take a look at the attack scenarios I mentioned in the first diary, this can be particularly nasty for browsers configured in organizations. For example, a lot of organizations configure browsers on client machines to automatically open intranet portals, which are typically hosted on machines with names “intranet”, “portal” or similar.
When a user with such a machine connects to an open wireless network and opens a browser, the browser will first try to resolve such a name via DNS. When that fails, the machine will try to resolve this name via NBNS and this is where an attacker can fake the response and start collecting LM/NT hashes.
Another very nasty scenario includes machines looking for WPAD (Web Proxy Auto-Discovery). By spoofing this request, an attacker can “push” his own machine as the web proxy and the client’s web browser will happily use it, allowing the attacker to analyze network traffic and at least try to launch Man-in-the-Middle attacks (hopefully, we’ve trained our users not to click on certificate warnings, right?).
So, I got in touch with Microsoft and the MSRC guys verified that this is indeed an issue with the firewall. The conversations with the MSRC guys were great and, as you can see, the patch has been released that fixes this vulnerability.
As with other security patches, you should definitely install it as part of your monthly patch install cycles. The whole exercise also shows how one should always test security controls that you put in place – just the fact that you added a rule to block certain network traffic does not have to mean that the traffic is really blocked.
More information and the patch is available at the Microsoft’s web site: http://technet.microsoft.com/en-us/security/bulletin/ms12-032
Advisory details at http://www.infigo.hr/en/in_focus/advisories/INFIGO-2012-05-01
--
Bojan
INFIGO IS
Microsoft May 2012 Black Tuesday Update - Overview
Overview of the May 2012 Microsoft patches and their status.
| # | Affected | Contra Indications - KB | Known Exploits | Microsoft rating(**) | ISC rating(*) | |
|---|---|---|---|---|---|---|
| clients | servers | |||||
| MS12-029 | Microsoft Word RTF Import (Replaces MS10-079, MS11-089, MS11-094) |
|||||
| Microsoft Word 2003 and 2007 CVE-2012-0183 |
KB 2680352 | No publicly known exploits | Severity:Critical Exploitability: 1 |
CRITICAL | N/A | |
| MS12-030 | Microsoft Office Remote Code Execution Vulnerabilities (Replaces MS11-072, MS11-089, MS11-094, MS11-096) |
|||||
| Microsoft Excel 2003/2007/2010 CVE-2012-0141 CVE-2012-0142 CVE-2012-0143 CVE-2012-0184 CVE-2012-0185 CVE-2012-1847 |
KB 2663830 | Yes (CVE-2012-0143) | Severity:Critical Exploitability: 3,3,1,1,2,1 |
CRITICAL | N/A | |
| MS12-031 | Visio Viewer 2010 Remote Code Execution Vulnerability (Replaces MS12-015) |
|||||
| Microsoft Visio Viewer 2010 CVE-2012-0018 |
KB 2597981 | No publicly known exploits | Severity:Important Exploitability: 1 |
CRITICAL | N/A | |
| MS12-032 | TCP/IP Elevation of Privilege and Firewall Bypass Vulnerability (Replaces MS11-083) |
|||||
| TCP/IP, Windows Firewall CVE-2012-0174 CVE-2012-0179 |
KB 2597981 | No publicly known exploits | Severity:Important Exploitability: 1 |
important | important | |
| MS12-033 | Vulnerability in Windows Client/Server Run-time Subsystem Could Allow Elevation of Privilege | |||||
| Plug and Play (PnP) Configuration Manager Vulnerability CVE-2012-0178 |
KB 2690533 | Elevation of Privilege | Severity:Important Exploitability: Likely |
Important | Important | |
| MS12-034 | Combined Security Update for Microsoft Office, Windows, .NET Framework, and Silverlight (Replaces MS11-029, MS12-018) |
|||||
| Microsoft Windows, Microsoft .NET Framework, Microsoft Silverlight, Microsoft Office CVE-2011-3402 CVE-2012-0159 CVE-2012-0162 CVE-2012-0164 CVE-2012-0165 CVE-2012-0167 CVE-2012-0176 CVE-2012-0180 CVE-2012-0181 CVE-2012-0184 |
KB 2681578 | Yes | Severity:Critical Exploitability: 1,1,1,1,2,1,1,1,1,1 |
CRITICAL | CRITICAL | |
| MS12-035 | .Net Framework Remote Code Execution (Replaces MS11-044, MS11-078, MS12-016) |
|||||
| .NET Framework CVE-2012-0160 CVE-2012-0161 |
KB 2693777 | No publicly known exploits | Severity:Critical Exploitability: 1 |
CRITICAL | CRITICAL | |
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
- We use 4 levels:
- PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
- Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
- Important: Things where more testing and other measures can help.
- Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
- The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
- The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a t ypical worst-case role.
- Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
- All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.
(**): The exploitability rating we show is the worst of them all due to the too large number of ratings Microsoft assigns to some of the patches.
--
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Storm Center - https://isc.sans.edu
Symantec False-Positive Issue with XLS Files - Bloodhound.Exploit.459
John writes in to report that Symantec has announced an issue with their current definition files that may generate false-positive alerts on .xls files.
- http://clientui-kb.symantec.com/kb/index?page=content&id=TECH188271&actp=RSS
- http://www.symantec.com/connect/forums/bloodhoundexploit459-false-positive
Thanks John!
The fix should be going out today as a rapid release: 134129 2012-05-08 rev. 016
New Poll: Which Patch Delivery Schedule Works the Best for You?
I've enabled a new poll today in honor of this month's Patch-Tuesday. In your organization is it easier for you to set aside that 2nd week of the month to focus on security patching, or is it easier for you to integrate security patching into your everyday system administration? I've always felt that if your environment was large enough to have it's on vulnerability management team, a steady stream of security advisories was preferable to the shock of all arriving at the same day. However, not everyone is that size, so it may be easier to schedule widespread reboots on Tuesday nights, saving Wednesday for dealing with any consequences (which seem to be happening less often, thankfully.)
Which would you prefer in your environment?
Comments