July 2008 black tuesday overview
Overview of the July 2008 Microsoft patches and their status.
| # | Affected | Contra Indications | Known Exploits | Microsoft rating | ISC rating(*) | |
|---|---|---|---|---|---|---|
| clients | servers | |||||
| MS08-037 | DNS spoofing and cache poisoning is made possible by a lack of entropy when doing DNS queries in both the DNS client and the DNS server. The lack of entropy is visible in the used source ports and the transaction IDs. | |||||
| Windows DNS CVE-2008-1447 CVE-2008-1454 |
UPDATE: Zonealarm press release (includes info on fix) |
No publicly known exploits |
Important | Important | Important | |
| MS08-038 | Multiple vulnerabilities in windows explorer allow code execution with the rights of the logged on user. | |||||
| Windows explorer CVE-2008-1435 CVE-2008-0951 (part) |
KB 950582 |
Publicly disclosed CVE-2008-0951 is a well known vulnerability: CERT VU#889747 (march 2008). |
Important | Critical | Important | |
| MS08-039 |
Multiple XSS vulnerabilities in OWA (Outlook for Web Access) allow any action the authorized user could perform to be done without his consent. |
|||||
| Exchange server CVE-2008-2247 CVE-2008-2248 |
KB 953747 | No publicly known exploits | Important | N/A | Critical(*) | |
| MS08-040 |
Multiple vulnerabilities in Microsoft's SQL server allow information disclosure and unauthorized complete control of the server. |
|||||
|
SQL server |
KB 941203 |
No publicly known exploits | Important | UPDATE: this does affect some clients Important |
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.
(*): For exchange servers with active use of OWA
(**): For SQL servers with SQL users that are not trusted on the server itself, or situation where an escalation of problems needs to be avoided.
--
Swa Frantzen -- Section 66
Multiple Vendors DNS Spoofing Vulnerability
Updates
We received a lot of feedback and comments to this issue. Here a quick summary:
- This only affects caching/resolving name servers. Authoritative name servers are not affected as they only send responses and will never receive responses (only queries).
- The patch will impact your servers performance. Test carefully before patching a very busy server. isc.org mentions 10,000 querries/sec as a problem.
- For BIND users, there is a non-IETF approved workaround to implement DNSSEC without full PKI. See "DNSSEC Look-aside Validation" for details.
- The overall issue has been known for a long time, and is a fundamental problem with the way DNS currently works. However, full details about what makes this so special will be revealed at Blackhat. There may be more to it. For example think about better tools to exploit it and exploits see in the wild.
- Please test carefully. At least Zonealarm seems to have problems with the respective Microsoft patch. Other firewalls may be "surprised" too by your DNS server all for sudden changing ports a lot.
- Don't forget embedded devices. In particular BIND is frequently used as a DNS server on firewalls and routers. If you don't need it: disable it.
- Stay in touch with your vendors. Please let them know if you experience any issues.
- Dan Kaminski's site: http://www.doxpara.com/ (includes a self-test)
Today, Microsoft was just one vendor releasing a patch for its DNS server. The Internet Systems Consortium (www.isc.org) published a very similar patch for its own DNS server, BIND.
Many other DNS servers are derived either form BIND or Microsoft's DNS server. Expect more similar announcements over the next couple days.
The Problem
The root cause is a fundamental, well known, weakness in the DNS protocol. DNS uses UDP, a stateless protocol. A DNS server will send a request in a single UDP packet, then wait for a response to come back. In order to match request and response, a number of parameters are checked:
- who sent the response? Was it the DNS server we sent the request to?
- for this particular response, do we have an outstanding request?
- each request uses a unique and random query ID. The response has to use the same query ID.
- The response has to be sent to the same port from which the request was sent.
Only if all this matches, the response is accepted. The first valid response wins. If an attacker is able to guess the query id and the source port, the attacker is able to send a fake response, which will be cached by the DNS server.
How likely is it to "guess" the query id and the source port? One would think, its not that easy. The query ID is 16 bits long, allowing for 65536 options. The source port could be anything above 1024 which again would allow for another 64512 options. It is easy to guess which DNS server is expected to reply, as it has to be a valid DNS server for the respective domain. A reasonable DNS server should respond in less then a second, allowing for about 1 second to send the spoofed response.
At least for BIND, the source port only changes whenever you restart it. Once restarted it keeps using the same source port.
Ideally, one would think that it would take millions of packets per second to successfully spoof the response. However, the problem is in the details. A DNS server can not use any port to source the query. It may not use a port commonly used by outbound connections, or a port reserved by a server. This is an issue attacked by today's patches. As of today, DNS servers used a rather small set of ports to source requests. This is the actual new finding. The patch will increase the pool of source ports available to DNS queries. To make things worse: the real DNS server may be silenced using DDoS attacks.
Over the past few months, we had a couple patches (again both for Microsoft as well as for BIND) addressing the randomness of the query ID.
How bad is it?
If you run a caching DNS server, patch it soon. I wouldn't say "today, while ignoring sane patch management". But check with your vendor and follow their guidance. The world is not going to end today. It will in fact end in 2 1/2 years from today (different story ;-) ). But this is something you have to fix soon. Right now, the US-CERT advisory lists a handful of vulnerable products and quite a few "unknowns".
Eventually we all may have to break down and fix DNS. DNSSEC is an extension to DNS asking for cryptographic authentication. However, it requires a PKI infrastructure which at this point doesn't exist. There is not much to be gained from implementing DNSSEC on your own (but by all means: try it out and see how it works).
One thing to carefully test is your firewall. We already heard about issues with Zonealarm and MS08-038. However, it is possible that other firewalls will think that something is wrong if your DNS server all for sudden keeps jumping ports.
Where can I find out more?
CERT: www.kb.cert.org/vuls/id/800113
Microsoft: http://www.microsoft.com/technet/security/Bulletin/MS08-037.mspx
Internet Software Consortium (BIND): http://www.isc.org/sw/bind/bind-security.php
Dan Kaminski on Martin McKeay's Podcast: http://media.libsyn.com/media/mckeay/nsp-070808-ep111.mp3
DNSSEC resources:
DNSSEC Overview: http://www.dnssec.org
DNSSEC Deployment Initiative: http://www.dnssec-deployment.org
DNSSEC HowTo: http://www.nlnetlabs.nl/dnssec_howto
-----
UPDATE:
The CERT announcement implies strong randomization of the source port and transaction id makes the attack improbable.
"Because attacks against these vulnerabilities all rely on an attacker's ability to predictably spoof traffic, the implementation of per-query source port randomization in the server presents a practical mitigation"
isc.org warns busy DNS resovlers could be impacted by their patch so they recommend the beta release version.
"The patches will have a noticeable impact on the performance of BIND caching resolvers with query rates at or above 10,000 queries per second. The beta releases include optimized code that will reduce the impact in performance to non-significant levels."
Johannes B. Ullrich, Ph.D.
SANS Technology Institute - http://www.sans.edu
Podcast Episode Eight Record Notice
Security implications in HVAC equipment
Chris sent us: "My wife sent me a link, asking if it would be wise to use a new offering by our local electricity provider (TXU). They will give their customers a free iThermostat with web-enabled features in exchange for the ability to cycle, or turn off the customer's AC unit during peak demand periods. The web-enabled features are hosted by TXU [...]"
There are a number of rather important aspects in there already. As security conscious people (like most, if not all of our readers) we should really try to reach out to our surroundings and try to get the "would it be wise" reaction on the security impact of choices as an integral part of the decision process. It's a hard thing to achieve, not only in a corporate environment, but in a home setting too. It's basically a risk assessment you do, but in order to do it you need to know the risks involved.
The second part is the stressed out electricity generating infrastructure in the USA. If you have to choose between them turning off your electricity for the AC or for all of your home, - outside of the data center (where the AC is critical to avoid overheating of equipment) - the choice at home seems to be relatively easy provided enough others join in the choice to make a difference.
Back to the risks involved:
Confidentiality
The data on when you're at home, what schedule you put in the programming of your AC, when you're on vacation, ... has some impact should it fall in the hands of others. Just imagine what a burglar could do with knowing who's on vacation when, with when you're scheduled to be home or not, ...
Even without that, there's no mention I could find on who has intentional access to that information. Will they use it to send you more marketing stuff? Will they share it with 3rd parties who'll offer their services too?
How is it made sure only your device(s) can get to the settings?
Integrity
What happens if an unathorized setting heats your home in winter to the maximum the HVAC unit can go during your absence ? Or to the minimum it'll go. Who pays for the energy bill and incendental damage if you didn't authorize those settings?
The new unit does have a lockout on the keyboard, but the troubleshooting on the website makes it obvious how trivial it is to override the lockout.
Availability
What happens if the website or your Internet connection is unavailable? Do you loose HVAC? Will it stay in it's last setting? Will it know the rest of the scheduling and continue to execute that without you having the ability to make changes till the communication or service becomes available again?
Authentication
Well ... login and plain old password on that website says enough to our readers I guess.
Wireless
After seeing the installation instructions, there were some additional questions not answered on the wireless network component. After looking at the video a few times, they are using a Digi ConnectPort X2, which seems to be providing ZigBee/IEEE 802.15.4 for "PAN" connections.
So you'll have to read up on another wireless network type next to WiFi, Bluetooth, ... It is interesting to see that zigbee does mention ACLs, AES, ... but I've also seen it mentioned that the encryption is in fact optional ...
Zigbee FAQ, Gilles Thonet, IEEE, February 2006.
ZigBee Security Layer Technical Overview - ZigBee Alliance, Seoul, September 2006.
So this raises many more questions than their FAQ will answer.
A conclusion: well there's hardly any as the questions would need answers before the risk can be determined. And regardless of that, in the end the important part is the risk you're willing to accept in order to gain the benefits that go far beyond the security implications.
For all clarity: I'm sure there are many more providers that use this technology beyond TXU, it's just the one sent in by one of our readers. I'm not trying to single them out in any way other than using this as an educational example.
--
Swa Frantzen -- Section 66
Comments