From alertmailinglist at skiifwrald.com Wed Aug 13 20:59:39 2008 From: alertmailinglist at skiifwrald.com (Security and IT News Alerts) Date: Wed, 13 Aug 2008 20:29:39 +0930 Subject: [Sunnet Alert] Advisory #258 - Microsoft (Multiple), Multiple News Message-ID: <3CA41760-0D83-422B-84BD-9AF43F7830B8@beskerming.com> S?nnet Beskerming Alert List Advisory #258 You are receiving this message because you have subscribed to our Information Security Alert Mailing List, or have been selected for a specific one-off copy. If you believe that you are receiving this message in error, pleasecontactinfo at beskerming.com to resolve the error. Why not upgrade to get same day notification on security threats? Details and rates available online - (http://www.beskerming.com/premium/generic_advisory.html). Why not go the next step and get delivery tailored just for your company? (http://www.beskerming.com/premium/focussed_advisory.html) Contents -------------------------------------------------------------------- 1. SECURITY -------------------------------------------------------------------- 1.1 Microsoft (Multiple) - Remote Hacker Automatic Control - Time Since Discovery - 1 day ======================================= /* - Remote or Local - Can it be achieved through a network or does it require physical access? - Hacker - The bad guy - Manual or Automatic - Does the vulnerability need to be manually performed, or can it be automated? - Control, Denial of Service or Data Theft - Will the hacker get control of your system / website, will they prevent you from using it, or will they steal data. */ -------------------------------------------------------------------- 2. NEWS -------------------------------------------------------------------- 2.1 $1 Million gets you International Hacking Capabilities 2.2 Online Attacks for Political Reasons 2.3 You can Only Blame Technology so Often ===================================== 1. SECURITY 1.1 Microsoft (Multiple) - Remote Hacker Automatic Control -- Products Affected -- Windows Exchange Server SQL Server -- Technical Description -- MS08-041 - ActiveX Control associated with Microsoft Access. Remote code execution. Critical MS08-042 - Word. Remote Code Execution. Important MS08-043 - Excel. Remote Code Execution. Critical MS08-044 - Office. Remote Code Execution. Critical MS08-045 - Internet Explorer. Remote Code Execution. Critical MS08-046 - Windows Color Management System. Remote Code Execution. Critical MS08-047 - IPSec policy. Information Disclosure. Important MS08-048 - Outlook Express, Windows Mail. Security Update. Important MS08-049 - Event System. Remote Code Execution. Important MS08-050 - Windows Messenger. Information Disclosure. Important MS08-051 - Microsoft Office Filters. Remote Code Execution. Critical -- Description -- Eleven patches were released by Microsoft with the August Security Patch Release. Of those patches, six were rated as Critical, and the remaining five were rated Important. This marked a change from the advance notification, where it was identified that seven of the patches were to be Critical, and only five as Important. Microsoft also provided updated patches for MS08-022, MS08-033, MS08-047, and MS08-040 and two advisories, 955179 and 954960. -- Recommended Action -- All users and administrators should apply the updates at the earliest opportunity. -- Source -- http://www.beskerming.com/premium/patch_pack.html http://store.eSellerate.net/s.asp?s=STR3448907936&Cmd=CATALOG&CategoryID=9811 -- Updates Available -- Register to gain access -- External Tracking Data -- Register to gain access -- Threat Matrix -- U O Home User 10 10 (Highly Critical) Corporate 10 10 (Highly Critical) ======================================= /* Threat Matrix: U - User O - Operator Harmless - 0 ----- 10 - Highly Critical */ ======================================= 2. NEWS 2.1 Olympic Ticket Scam Traps Many In the age of the P-p-p-p-powerbook and the ubiquitous 419 scammer, it comes as no surprise that many people have fallen for a Beijing Olympics ticketing scam that seems to have hit people all across the world. Due to the rarity of tickets for the games, and the particular setup of the scam site (and others), there has been a lot of money lost by many people as they struggled to get their hands on tickets that didn't exist. It is ticket scalping for the 21st century, made even more lucrative by the need not to actually provide any tickets to the victims. When MSNBC carried a Forbes Traveler article, initially published late February, it carried links to at least one fake ticketing site, sites that have since disappeared from the actual page, pulled sometime between the end of July and now, it led to implied legitimacy for the site and helped it gain a search engine position and helped lead many down the path of losing large amounts of money. By silently fixing the article, MSNBC have contributed to the confusion as to how people were led into believing the site was legitimate. If you or your site find yourself in the position of having to amend something that you have already published online, you need to make sure that visitors can tell that you have amended the original page and at least identify what has changed. MSNBC's silent fix, without any acknowledgement that the original links might not have been appropriate, is the worst possible way to deal with things, it is even worse than leaving the information as it was - at least then people could identify where the implied legitimacy had originated from. Just to make it clear, this is NOT THE REAL BEIJING GAMES TICKET SITE, this one is. Does it mean that the Chinese Olympic organisers have failed to secure all probable online domains before selling tickets? It is impossible to completely close off the multitude of possible domains that might be set up to try and sell tickets, so the organisers aren't really at fault for that. Could they have made more effort to secure likely domains? Probably. Then again, hindsight is always perfect. Key to the whole incident is how trust is allocated and determined when interacting with new sites on the Internet. It actually highlights one of the biggest problems with establishing viable online trust. If a site, such as MSNBC, that you would normally otherwise trust, provides a link to a malicious site and claims it is legitimate, how would you be able to differentiate if the link is malicious if you had never been there before? Under almost any trust model that exists, the site would have gained trustworthy status earlier this year, when MSNBC first linked to it. Where the trust breakdown took place was when people failed to receive their tickets and it was realised that the site was claiming ticket availability for events that had long been completely sold out. Some of the more advanced trust models that are in development (such as the one developed by S?nnet Beskerming) would have given the site a dubious weighting, but would have struggled to offset the implied trust delivered by other sites against the Official Beijing site, which should have been the only one to offer tickets for sale. All you need to trick people into giving you their money, it seems, is to have a flashy website and promise delivery in the future for some desirable item. If you want to find out more about the risks and what sites are scamming people, one of the best resources for those who are trying to hunt down the people behind the various scams is over at beijingticketscam.com. 2.2 Internet Flaw Highlights More Than Just Technical Problems When Dan Kaminsky released a cryptic announcement that one of the core technologies (DNS, the Domain Name System) tying the Internet together was vulnerable to a critical weakness it gained the attention of many people, especially given that many of the software vendors who create the vulnerable software had come together to address the problem and the fact that Kaminsky was going to delay the release of information until early August, at the Las Vegas Black Hat conference. Despite the secrecy about the details of the vulnerability, if you don't want anyone else to work it out for you, then don't tell anyone you've found something. The lack of openness about the issue led many to start speculating and eventually Halvar Flake hit upon the correct answer. When Kaminsky himself challenged others to look into the security of DNS and look at what might have been missed, the outcome was almost guaranteed. Indeed, since the vulnerability was correctly speculated on, exploit code has been publicly released through a number of websites and mailing lists. Since the correct guessing of the vulnerability, the general response has been one of panic. Those who have read and understood the technical details have largely been left scratching their heads - there's not really anything new there. All it demonstrates is a corner case of a previously known issue. Certainly the issue is one that should have been fixed properly the first time, but for whatever reason it wasn't. What is more interesting is to see the vitriol that has now emerged as people realise the information is out there. Some of the most serious claims have been levelled against the team at Matasano Chargen for having been the ones to actually spill the beans, as Halvar Flake had only speculated about the details. The pulled post at Matasano Chargen did more to get people to sit up and take notice than it would have if it was left in place and the fact that they had declared that they were part of the trusted few who had the details confirmed by Dan Kaminsky only further validated for many people what had been posted. Part of the problem is once data has been published on the Internet it is awfully hard to completely retract it, even if it has only been there for a couple of hours in total. As the retracted post at Matasano Chargen promised technical details on the vulnerability it was quickly snapped up by the lucky few who were able to see it and then reproduced on numerous other sites. Information Security has egg on its face over this issue. It shows how immature the industry can be and how poor many people's skills are at managing release and coordination of information. To his credit Dan Kaminsky did find something that hadn't been fixed. Whether that is an old problem or not is irrelevant for the time being, as it affected a significant portion of the Internet's DNS servers and required a coordinated effort by vendors to do something about it. The whole incident has left a sour taste in many mouths. Is Black Hat or DefCon the place to release all about a vulnerability? After the debacle surrounding David Maynor and Jon Ellch's Black Hat OS X wireless vulnerability demonstration in 2006, perhaps people who are looking to release sensitive vulnerability information with some flair should reconsider the pre-release media blitz. It runs the very high risk of turning what might be a valid issue into a circus and leaving all involved worse off for the experience. Richard Bejtlich suggests that the incident might have been better handled if initial and full disclosure was handled by an impartial third party and the conference used for post-disclosure discussion and the details of how the vulnerability was found. The problem is then finding what can be regarded as an impartial third party. The open discussion that was created following the initial announcement turned up a more serious problem, which will continue to have problems for users long after most systems are updated to address the vulnerability. NAT, a very common technology that allows for multiple systems to sit behind a single network connection wasn't considered in the vulnerability equation but it was soon realised that the method implemented to protect against the vulnerability would break down when network traffic encountered most NAT devices, with the result of zero protection against the vulnerability. The whole idea of responsible disclosure, most famously set out by Rain Forest Puppy, has broken down in this case. Those who were not briefed in with details on the vulnerability feel that security by obscurity was the gameplan and watching how the incident played out in the media and how those who knew were (mis)managing the information reinforced this idea for them. As far as those who did know the details, they saw the withholding of information as a necessary step to prevent widespread attack before updated systems could be put in place. The problem was that this left everyone else having to guesstimate the severity of the vulnerability, or having to trust the claims being made by people who weren't releasing enough information to back up their claims. The problem with the approach taken was that it was set up such that the carrot being dangled was too tempting for everyone to leave alone until Black Hat. When the vulnerability was finally released, it didn't seem to make a lot of sense, surely the vulnerability wasn't as simple as that. With the way that a number of people in the know were talking it sounded like the world was about to end. So, what is the vulnerability? Historically, it was possible to guess fairly quickly the IDs in use by DNS queries and responses and so insert fake responses to poison a DNS cache and point requests for legitimate sites to those under a hacker's control. Improved random number generators (to increase the entropy of the IDs) and randomising the source ports helped make this particular attack far more difficult to carry out (but not completely impossible). Within the structure of a DNS response it is possible for amplifying data to be returned about a domain so that subsequent requests to that domain or subdomains can be made more efficiently, either by identifying the correct authoritative server to query or by supplying the data direct to the requesting system so that it doesn't need to poll the server. It is this particular feature which is the key to the whole discovery made by Dan Kaminsky. While it should not be possible (poor implementation of the specification aside) for this amplifying data to change the details of other domain entries, it is possible for the amplifying data to change the details for parent domains. This means that a poisoned response for poisoned.example.com can change the details for example.com. Without the source port randomisation, it has been discovered that it is possible to overcome the message ID randomisation and inject a fake response that poisons the entry for the top domain in around 10 seconds on a fast modern system. To achieve this, numerous requests are made for fake subdomains until the right combination of ID and timing have been found to inject the response. The solution of adding increased randomisation to the source ports used in making the requests adds another layer of complexity for the hacker to overcome, one which is enough for this point in time. It is a band-aid type solution? Only time will show, but it might prove good enough for the next few years at least. Perhaps a better solution would be that every domain should include a wildcard subdomain entry that identifies the legitimate main server as the authoritative one for all subdomains for that particular domain. Sending this wildcard information in the DNS response would result in increased network traffic but it would also completely neutralise a spoofing attack (unless the attacker is lucky enough to have the right combination of ID, timing, and source port to beat the legitimate response to the end user). It might break some business models that rely upon selling / marketing subdomains and mean more authoritative DNS servers need to be set up, but that is what might be necessary to completely neutralise the vulnerability. At the end of the day it still only seems to be domain-specific poisoning, that is you can't forcefully poison results for a domain that you aren't already making requests for (i.e. poisoning the result for google.com when making requests for yahoo.com), but with the various IFRAME and JavaScript tricks that exist out there it isn't too hard to make this seem transparent - such that the user doesn't know that they have been making requests for the site, but by this stage it is too late for their system and they are compromised. With readily available exploit code this is going to become a real problem for many people in a short period of time. ======================================= Sincerely, S?nnet Beskerming Team info at beskerming.com S?nnet Beskerming Pty. Ltd. Adelaide, Australia http://www.beskerming.com Tel: +61 (0) 410 707 444 ** S?nnet Beskerming Pty. Ltd. ** Established in mid 2004, S?nnet Beskerming Pty. Ltd. is the sister company to Jongsma & Jongsma Pty. Ltd., and was formed to develop and commercialise the research coming out of Jongsma & Jongsma Pty. Ltd.. S?nnet Beskerming Pty. Ltd. is an Information Security specialist and, in conjunction with the tools developed by Jongsma & Jongsma Pty. Ltd., provides total security solutions and services, from the perimeter to internal data stores, including web application security and security testing and analysis.