March black Tuesday overview
Overview of the March 2009 Microsoft patches and their status.
| # | Affected | Contra Indications | Known Exploits | Microsoft rating | ISC rating(*) | |
|---|---|---|---|---|---|---|
| clients | servers | |||||
| MS09-006 | Multiple input validation vulnerabilities in the windows kernel allow random code execution though the GDI component (WMF and EMF files yet again), and privilege escalations that allow random code to be run in kernel mode. Replaces MS08-061. |
|||||
| Windows kernel CVE-2009-0081 CVE-2009-0082 CVE-2009-0083 |
KB 958690 |
No publicly known exploits |
Severity:Critical Exploitability:3,2,3 |
Critical | Important | |
| MS09-007 | Secure Channel (SChannel) implements SSL and TLS. When using client certificates (X.509) the server implementation fails to properly validate that the client has access to the private key and allows impersonation using only knowledge of the public key of the client. Replaces MS07-031. |
|||||
| Secure Channel (SChanne)l CVE-2009-0085 |
KB 960225 | No publicly known exploits. | Severity:Important Exploitability:2 |
N/A | Critical | |
| MS09-008 | Multiple vulnerabilities in the DNS and WINS server implementation. DNS spoofing is made easier by allowing a more predicable transaction ID, possible causing DNS cache poisoning. The update also fixes the problem with WPAD (Web Proxy Auto Discovery) a DNS. A similar problem is fixed for WINS with the WPAD and ISATAP (IPv6: Intra Site Automatic Tunnel Addressing Protocol) names Replaces MS08-037, MS08-034 and MS08-066. |
|||||
| DNS and WINS server CVE-2009-0093 CVE-2009-0094 CVE-2009-0233 CVE-2009-0234 |
KB 962238 |
CVE-2009-0093 and CVE-2009-0094 are publicly known according to Microsoft. |
Severity:Important Exploitability:2,2,2,2 |
N/A | 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 typical 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
--
Swa Frantzen -- Section 66
TinyURL and security
Roseman wrote in with a pointer to a techrepublic blog that points out the well known danger to the short URL servcies and their widespread use.
The blog also pointed out:
- TinyURL has a preview function that (once you set the cookie) allows you to see where you're being redirected before it happens. Set the cookie here: http://tinyurl.com/preview.php
- Bit.ly has an add-on for firefox that allows you to see where the URL points to in addition to some statistics.
Those measures reduce some of the dangers, but by far not every danger of users being used to click on links they receive via twitter, IM, or email. It's still far safer to go to any place you need to log in such as e.g. your bank via a bookmarked link only. Those bookmarks reduce the phishing attempts emailing you funny URLs, the typo squatters etc. Add in a properly working certificate on the SSL version of the website and you've got some serious defense going as a user as long as you do not accept bad certificates.
UPDATE:
- There are more generic plug-ins for this for Firefox, suggestions we received include "Long URL Please", and "LongURL Mobile Expander". Use at your own risk.
- TinyURL has a manual version of the preview: change http://tinyurl.com/X into http://preview.tinyurl.com/X .
--
Swa Frantzen -- Section 66
Adobe Acrobat 9.1 released
Charlie, Gilbert and Robert (*) wrote in to point to the eagerly awaited Adobe Acrobat fix that was released today:
http://www.adobe.com/support/security/bulletins/apsb09-03.html
Make sure you have version 9.1.
Updated versions for unix and older versions (versions 7.x and 8.x) will be forthcoming in the next weeks according to Adobe.
--
Swa Frantzen -- Section 66
(*): normally we credit it to the first one to write it, but I lost track of who was first, so all of those that allowed their name to be mentioned get the mention.
conspiracy fodder: pifts.exe
Several readers wrote in with samples of a file PIFTS.exe that seems to be related to a Norton update and gets flagged for its behavior.
The file has been confirmed to call home to stats.norton.com .
The truly bizarre are the mentions that the support forums of norton wipe questions about pifts.exe:
- See this google search for "site:community.norton.com pifts.exe":
- none of them are cached, but they clearly have been indexed and they have been deleted:
This is of course exactly what any conspiracy theorist needs to lower trust in the products.
We're trying to reach our contacts at Symantec for an explanation, and will update if and when we get a response.
UPDATE:
I just had a phone call from a Symantec employee confirming the program is theirs, part of the update process and not intended to do harm, more to follow, stay tuned.
WARNING:
We've been sent an example of a web page targeting the term "PIFTS.exe" along with other popular search terms that lead to obfuscated javascript that leads in turn to actual malware.
Take care if you search for this: you might find the bad guys out there taking advantage of our interest in PIFTS.exe already.
At the time of writing the page we were notified about was not (anymore?) indexed in google, but YMMV.
UPDATE:
From interactions with Symantec staff and the public post, it's safe to conclude the intention of PITFS.exe was to gauge impact on upgrading old versions of the software (even dating as far back as 2006 and 2007).
Of course there are lessons one can learn from it, even if you were unaffected, you can learn form it. But also ask if you'd do better yourself when you are faced with it. Responding to such incidents isn't easy. In hindsight it's easy, on the spot it is much harder.
I'd like to thank the Symatec contacts who did respond to my inquiries in a time of crisis for them. So thanks!
--
Swa Frantzen -- Section 66
Browser plug-ins, transparent proxies and same origin policies
First, just a quick reminder:
- Same origin policy is a way a browser keeps methods from being called between different sites. It assures that www.evil.com's scripts can't access www.bank.com's methods, even if you have both of them open in the same browser at the same time. Any failure here often is catastrophic to security.
- Transparent proxies sit between the browser and the Internet and -as their name suggests- transparently try to either cache some content and safe some bandwidth or either are there to inspect traffic and/or enforce policies. They are supposed to be invisible to the browser. You'll find them at hotels, ISPs, corporate perimeters etc. There are quite a few security technologies that incorporate them to do content filtering.
- Browsers typically have plug-ins such as a flash player that have extensive scripting capabilities (or java). These plug-ins can open TCP connections themselves.
As you're probably getting by now: the above combination can have a problem depending on how the transparent proxy is working.
Last month CERT released a not much published about vulnerability note, that by now still lists many vendors as unknown, but is starting to collect a number of vulnerable ones as well.
Robert sent us a pointer to a paper titled "Socket Capable Browser Plugins Result In Transparent Proxy Abuse".
In it the author describes the attack method in greater detail. The scenario is as follows:
The user (victim) visits somehow www.evil.com through his browser.
- The browser resolves www.evil.com to 1.1.1.1
- The browser downloads the content of the web page
- The browser spots an object referenced in the web page
- The browser downloads the object as well from the same www.evil.com website
- The browser starts executing the object
- The object opens a connection to 1.1.1.1 on port 80
- In that TCP connection, it asks -using the HTTP protocol- for a URL that appears to come from a host www.secret.com (while connected to www.evil.com)
If the transparent proxy intercepts this (it will), and if it resolves www.secret.com to it's real IP address and not 1.1.1.1 of www.evil.com (it might), it might just have connected the browser -thinking it's talking to www.evil.com- with a connection to www.secret.com. The browser will now allow the object from www.evil.com access to what comes in (and goes out) through the connection to www.secret.com, while it also still can communicate with www.evil.com.
What can you do against this:
- As a user: install Firefox and NoScript: as a user in e.g. a hotel that has a vulnerable transparent proxy this might be the only layer you'll get. By default, NoScript stops the objects from www.evil.com like all other scripts you didn't explicitly trust.
- As an administrator of a transparent proxy, check the US-CERT note above and if your vendor isn't listed as "not vulnerable", contact them for a solution.
If you know other defenses that are effective, do contact us and we'll update.
--
Swa Frantzen -- Section 66
Comments