4 X Security Team

Microsoft today shipped three security bulletins with fixes for at least 8 documented vulnerabilities affecting millions of Windows OS users.

The most serious of this month’s patch batch is rated “critical” and could allow full remote execution attacks if a Windows user is simply lured into viewing a booby-trapped image file.

The skinny on the March 2009 bulletins:

• MS09-006: (CRITICAL) Provides cover for three newly discovered and privately reported vulnerabilities in Windows, which could allow remote code execution if a user viewed a specially crafted EMF or WMF image file from an affected system. These vulnerabilities affect all versions of Windows, including Vista and Windows Server 2008. Microsoft expects to see exploit code for these flaws but reckons the reliability will be “inconsistent.”
• MS09-007: (IMPORTANT): This bulletin includes a patch for a solitary vulnerability in Windows, which could allow spoofing if an attacker gains access to the certificate used by the end user for authentication. Again, Microsoft says “inconsistent exploit code” is likely. The bulletin is available for all versions of Windows — Windows 2000 through Windows Server 2008.
• MS09-008 (IMPORTANT): This update resolves two privately reported vulnerabilities and two publicly disclosed vulnerabilities in Windows , which could allow a remote attacker to redirect network traffic intended for systems on the Internet to the attacker’s own systems. Microsoft says the patches correct the way that Windows DNS servers cache and validate queries, and by modifying the way that Windows DNS servers and Windows WINS servers handle WPAD and ISATAP registration. For these issues, Microsoft warns that “consistent exploit code” is likely.

Windows users should treat the “critical” bulletin with the highest possible priority.

[Source: zdnet]

Microsoft today outlined plans to ship three security bulletins for software vulnerabilities in the Windows operating system.

One of the three bulletins will carry a “critical” rating, meaning that it will cover flaws that could be exploited to launch remote code execution attacks.

According to the advance notice from Microsoft, the other two bulletins are rated “important” and can expose Windows users to spoofing attacks.

All three bulletins require a restart after deployment.

All supported versions of Windows will be affected by next Tuesday’s releases, including the newer Windows Vista and Windows Server 2008.

This month’s batch of patches will NOT include a fix for a known — and under attack — code execution vulnerability affecting Microsoft Office. Microsoft has already issued a security advisory on the Office attacks (via rigged Excel files) with some suggested mitigation guidance.

[Source: zdnet]

Google is (indirectly) buying security vulnerabilities from white hat hackers.

Under the guise of a Native Client Security Contest, the search engine firm is offering big cash prizes to hackers who find bugs and other security flaws in the open-source research technology for running x86 native code in Web applications.

[ SEE: Android security team appeals to hackers ]

From the contest FAQ:

• To participate, you will need to test the Native Client builds, identify security exploits which affect the current Native Client build at the time of submission and report them to our team. Our judges will review your entry. If you are one of the top five participants selected by the judges and satisfy the requirements for eligibility, then you will win a cash prize.

The judging will be led by Princeton University’s Ed Felten.

The first prize is $8,192, the second prize $4,096, the third prize is $2,048, the fourth prize is $1,024 and the fifth prize is $1,024. All amounts are in USD.

At least one exploitable defect is already publicly known.

, iDefense, Shockwave Flash, Security, Ryan Naraine [ UPDATE: Here's the official alert from Adobe with information on the patch. It covers a total of five vulnerabilities and affects Flash Player 10.0.12.36 and earlier ]

Sometime later today, Adobe will issue a patch for at least one critical vulnerability affecting its ubiquitous Flash Player. If you live on the Windows ecosystem, this is a heads-up to pay attention to Adobe’s security updates page and treat this as a high-priority issue.

According to an advisory from iDefense, the company that brokered the disclosure process, the patch will fix a Flash Player vulnerability that could allow an attacker to use rigged Shockwave Flash files to execute arbitrary code with the privileges of the current user.

From the iDefense alert:

• During the processing of a Shockwave Flash file, a particular object can be created, along with multiple references that point to the object. The object can be destroyed and its associated references removed. However a reference can incorrectly remain pointing to the object. The invalid object resides in uninitialized memory, which the attacker may control to gain arbitrary execution control.

To exploit this vulnerability, iDefense said a targeted user must load a malicious Shockwave Flash file created by an attacker. This can be trivially done via social engineering techniques or injecting content into a compromised, trusted site or advertising network.

• Utilizing various techniques, an attacker is able to re-allocate and control the memory used by the destroyed object. This allows the attacker to subvert execution when a virtual function is called via the invalid reference.

The flaw was confirmed latest version of Flash Player (9.0.124.0). Previous versions may also be affected. iDefense said it tested exploitation on Windows XP SP3 and Windows Vista SP1.

• iDefense believe that all platforms supported by Flash Player are affected by this vulnerability, including Linux and MacOS.

Adobe was first notified of this issue last August. The company is currently in the midst of responding to zero-day attacks against bugs in its Adobe Reader and Acrobat products.

Yesterday, Adobe confirmed the existence of a critical vulnerability affecting Adobe Reader and Acrobat versions 9.0 and earlier, originally detected by the Shadowserver Foundation last week.

The onging targeted attacks have since been confirmed by both, Symantec and McAfee urging users to disable JavaScript in Adobe Reader and Acrobat until Adobe issues a patch on the 11th of March in the following way - Click: Edit -> Preferences -> JavaScript and uncheck Enable Acrobat JavaScript.

Symantec’s comments on the potential for massive attacks using the exploit:

So far, these attacks appear to be targeted and not widespread. Symantec is continuing to monitor the vulnerability’s use in the wild.

While examining the JavaScript code used for “heap-spraying” in these PDFs, we can see the same comments that show that these separate exploit attempts come from the same source! It seems likely that the people behind this threat are using targeted attacks against high-ranking people within different organizations—for example, locating the CEO’s email address on the company website and sending a malicious PDF in the hope that their malicious payload will run. Once the machine is compromised, the attackers may gain access to sensitive corporate documents that could be costly for companies breached by this threat.

For the time being, cybercriminals chose to generate less noise by launching targeted attacks just like they did earlier this week using IE7’s MS09-002 vulnerability. However, as we’ve previously seen it’s only a matter of time until copycat attackers start using it on a large scale.

With several targeted campaigns currently active, what are the chances that a sample malware campaign would be once again monetizing infected hosts by infecting them with rogue security software similar to Conficker’s first release? Huge.

• Go through related incidents using Adobe exploits: MSN Norway serving Flash exploits through malvertising; CNET’s Clientside developer blog serving Adobe Flash exploits; Rigged PDFs exploiting just-patched Adobe Reader flaw

Upon analyzing the binary served once an infected host gets successfully exploited from a sample campaign, it’s attempting to trick the user into install the very latest rogue security software Spyware Protect 2009. The cute part is that the cybercriminals didn’t manage to successfully configure their campaign resulting in a 404 error.

What’s important to point out is that the original targeted attacks detected by the Shadowserver Foundation are once again using a well known and previously abused Chinese DNS provider (js001.3322.org) with more details about its owner available in a related BusinessWeek article.

[Source: zdnet]

Routing and switching giant Cisco has released an alert to warn of multiple security flaws in some of its Wireless LAN controllers.

The company documented at least four vulnerabilities that could lead to denial-of-service or privilege escalation attacks. Affected product lines include Cisco Wireless LAN Controllers (WLCs), Cisco Catalyst 6500 Wireless Services Modules (WiSMs), and Cisco Catalyst 3750 Integrated Wireless LAN Controllers.

The skinny:

• CVE-2009-0058: Web authentication is a Layer 3 security feature that causes the
  controller to drop IP traffic (except DHCP and DNS related packets) from a
  particular client until that client has correctly supplied a valid username and
  password.
  
• CVE-2009-0059: An attacker may cause a device reload when sending a malformed post
  to the web authentication “login.html” page.
• CVE-2009-0061: Affected Cisco WLC, WiSM and Catalyst 3750 Wireless LAN Controller
  models are vulnerable to a DoS condition that is triggered by the receipt of
  certain IP packets. Upon receiving these IP packets, the affected device may
  become unresponsive and require a reboot to recover.
• CVE-2009-0062: A privilege escalation vulnerability exists only in WLC software
  version 4.2.173.0, and could allow a restricted user (i.e., Lobby Admin) to
  gain full administrative rights on the affected system.

One of these flaws carry a CVSS Base Score of 9.0, meaning it should be treated as a “high priority” update.

Microsoft today shipped a solitary bulletin with patches for at least three documented security flaws in the Microsoft Server Message Block (SMB) Protocol.

The three vulnerabilities, rated “critical” on Windows 2000, Windows XP and Windows Server 2003, exposes Windows users to remote code execution attacks, Microsoft said in its MS09-001 bulletin. The company warns:

“An attacker who successfully exploited these vulnerabilities could install programs; view, change, or delete data; or create new accounts with full user rights.”

Only two of the three vulnerabilities affect Windows Vista and Windows Server 2008.

Although the exposure to risk seems severe (remote code execution), Microsoft believes it’s unlikely that functioning exploit code will be created and released. Microsoft’s Mark Wodrich explains why:

• The vulnerabilities cause a fixed value (zero) to be written to kernel memory – not data that the attacker controls.
• Controlling what data is overwritten is difficult. To exploit this type of kernel buffer overrun, an attacker typically needs to be able to predict the layout and contents of memory. The memory layout of the targeted machine will depend on various factors such as the physical characteristics (RAM, CPUs) of the system, system load, other SMB requests it is processing, etc.

Eric Schultze, CTO at patch management specialists Shavlik, still recommends that Windows users view at MS09-001 as “super critical to install right away.”

This flaw enables an attacker to send evil packets to a Microsoft computer and take any action they desire on that computer - no credentials required. The only pre-requisite for this attack to be successful is a connection from the attacker to the victim over the NetBIOS (File and Printer Sharing) ports (tcp 139 or 445). By default, most computers have these ports turned on.

While these ports are usually blocked on Internet firewalls and personal firewalls, these ports are typically left open in a corporate network. If a worm is released, and that worm makes it into a corporate network, it will make swiss cheese of that network relatively quickly.

According to Roel Schouwenberg, a senior anti-virus researcher at Kaspersky Lab (my employer) the risk of a network worm attack is minimal. “It’s unlikely we’ll see a worm,” he said.

There’s a major privacy problem with the RSS reader built into Apple’s Safari browser.

According to an alert from Brian Mastenbrook, there is a serious Safari vulnerability that allows a malicious web site to read files on a user’s hard drive without user intervention.

Mastenbrook warns:

This can be used to gain access to sensitive information stored on the user’s computer, such as emails, passwords, or cookies that could be used to gain access to the user’s accounts on some web sites. The vulnerability has been acknowledged by Apple. All users of Mac OS X 10.5 Leopard who have not changed their feed reader application preference from the system default are affected, regardless of whether they use any RSS feeds or use a different web browser (such as Firefox). Users of previous versions of Mac OS X are not affected.

[ SEE: Microsoft issues Safari-to-IE blended threat warning ]

Mastenbrook, who has a credible history of reporting security issues affecting the Mac ecosystem, said users of Safari on Windows are also affected.

The researcher recommends that Safari users change the default feed reader in the browser.

[ SEE: Adobe Flash, Apple Safari fail privacy test ]

To select a different feed reader:

1. Open Safari and select Preferences… from the Safari menu.
2. Choose the RSS tab from the top of the Preferences window.
3. Click on the Default RSS reader pop-up and select an application other than Safari.

The only workaround available for users of Safari on Windows is to use a different web browser, Mastenbrook recommends.

[Source: zdnet]

This is not the first time that Apple’s Safari browser has failed a privacy-related test.

In the wake of this morning’s 25C3 presentation by Alex Sotirov and Jacob Appelbaum, most of the coverage I’ve read so far has focused on the technical details and real-world impact of their findings. Rightly so — their paper describing the attack is a fascinating read filled with enough gory details to make any security practitioner salivate.

To summarize, the crux of the attack was the fact that certain certificate authorities (CAs) still use the MD5 algorithm to sign SSL certificates. The researchers exploited this implementation by harnessing some existing academic research on MD5 chosen-prefix collisions and sprinkling in a few additional tricks.

The most frustrating part of this whole debacle is that it should have never happened.

Like any widely-used cipher, MD5 has been scoured for weaknesses by crypt-analysts since its introduction in 1991. The first significant cracks in the surface appeared at the CRYPTO 2004 conference in August 2004, when Xiaoyun Wang presented a paper entitled Collisions for Hash Functions that described a method for producing MD5 collisions.

[ SEE: SSL broken! Hackers create rogue CA certificate using MD5 collisions ]

History has shown repeatedly that cryptanalysis is an evolutionary process. Each subsequent compromise builds on top of prior work, and each new attack is more practical than the last. The Wang presentation should have been a wake-up call that the clock was ticking on MD5. But, aside from the security community, nobody paid much attention.

At the time, I was employed as a security consultant for @stake, and I can remember revising all of our deliverable templates to remove any mention of MD5 from our best practices or boilerplate text. Even some of my own colleagues were split on whether that was necessary, since the attack didn’t have any practical implications yet. I agreed that we had no reason to act like the sky was falling, but it would only be a matter of time until a practical attack would be discovered. As such, our customers should be advised, at the very least, to eradicate MD5 from their code going forward.

But people tend to be lazy. The typical enterprise mindset can best be summarized as “if it can’t hurt me today, stop bothering me,” and that probably won’t change anytime soon. For an enterprise application, the risk is bounded. If you choose to use a weak hash algorithm in your custom web application, you only hurt yourself and your customers. Apparently, that is a risk people are willing to take, even though switching hash algorithms is a fairly trivial code modification.

A few years later, right on cue, Marc Stevens released a master’s thesis entitled On Collisions in MD5 (.pdf), detailing a chosen-prefix attack against MD5. This was a significant breakthrough and one crucial step closer to the practical, real-world attack revealed today in Berlin.

It’s an absolute travesty that the CAs failed to act not only on the Wang research, but on every other MD5 attack that has materialized since. Any organization who is in the business of selling trust should take all possible measures to be trustworthy, and the CAs failed miserably in that regard.

* Chris Eng is senior director of security research at Veracode. He is currently removing root CAs from his web browser.

[Source: zdnet]

Using computing power from a cluster of 200 PS3 game consoles and about $700 in test digital certificates, a group of hackers in the U.S. and Europe have found a way to target a known weakness in the MD5 algorithm to create a rogue Certification Authority (CA), a breakthrough that allows the forging of certificates that are fully trusted by all modern Web browsers.

The research, which will be presented today by Alex Sotirov (top left) and Jacob Appelbaum (bottom left) at the 25C3 conference in Germany, effectively defeats the way modern Web browsers trust secure Web sites and provides a way for attackers to conduct phishing attacks that are virtually undetectable.

The research is significant because there are at least six CAs currently using the weak MD5 cryptographic algorithm in digital signatures and certificates. The most commonly used Web browsers — including Microsoft’s Internet Explorer and Mozilla’s Firefox — whitelist these CAs, meaning that a fake Certificate Authority can display any site as secure (with the SSL padlock).

“We basically broke SSL,” Sotirov said in an interview ahead of his 25C3 presentation.

Our main result is that we are in possession of a “rogue” Certification Authority (CA) certificate. This certificate will be accepted as valid and trusted by many browsers, as it appears to be based on one of the “root CA certificates” present in the so called “trust list” of the browser. In turn, web site certificates issued by us and based on our rogue CA certificate will be validated and trusted as well. Browsers will display these web sites as “secure”, using common security indicators such as a closed padlock in the browser’s window frame, the web address starting with “https://” instead of “http://”, and displaying reassuring phrases such as “This certificate is OK ” when the user clicks on security related menu items, buttons or links.

Researchers at the Centrum Wiskunde & Informatica (CWI) in the Netherlands, EPFL in Switzerland, and Eindhoven University of Technology (TU/e) in the Netherlands helped in the design and implementation of the attack using an advanced implementation of a known MD5 collision construction and a cluster of more than 200 PlayStation 3 game consoles.

According to Sotirov, a rogue CA in combination with Dan Kaminsky’s DNS attack can have serious consequences:

For example, without being aware of it, users could be redirected to malicious sites that appear exactly the same as the trusted banking or e-commerce websites they believe to be visiting. The web browser could then receive a forged certificate that will be erroneously trusted, and users’ passwords and other private data can fall in the wrong hands. Besides secure websites and email servers, the weakness also affects other commonly used software.

Sotirov said the team was able to secure NDAs in advance of briefing the major browser vendors about the problem but because of issues — some practical and some political — there are no straightforward fixes unless the CAs stop using MD5 and move to the more secure SHA-1 algorithm.

To avoid abuse, the team back-dated its rogue CA (it was set only for August 2004) and will not release the private key. “We’re also not going to release the special code that we used to do the MD5 collisions until later this year,” Sotirov added.

“We don’t anticipate this attack to be repeatable very easily. If you do a naive implementation, you would need six months to run it successfully,” he added.

Arjen Lenstra, head of EPFL’s Laboratory for Cryptologic Algorithms, the key objective of the research was to stimulate better Internet security with adequate protocols that provide the necessary security.

The key takeaway, according to Lenstra: “It’s imperative that browsers and CAs stop using MD5, and migrate to more robust alternatives such as SHA-2 and the upcoming SHA-3 standard.”

Further details:

• Detailed explanation
• Slides from the 25c3 presentation
• Demo site (set your system date to August 2004 before clicking)

Colliding certificates:

• Real certificate
• Rogue CA certificate

Media, Security, Consumer Electronics

Microsoft is pouring cold water on public reports of a serious code execution vulnerability in the newest versions of its Windows Media Player software.

Following the release of proof-of-concept code alongside a claim that the bug can be remotely exploitable to launch arbitrary code, a Microsoft spokesman insists this “is not a product vulnerability.”

Here’s Microsoft’s full statement:

Microsoft is aware of a falsely reported vulnerability in Microsoft Windows Media Player Dec. 25, 2008. Microsoft investigated the claim and found that this is not a product vulnerability. Microsoft confirmed that the reported crash is not exploitable and does not allow an attacker to execute arbitrary code, as was incorrectly claimed in the public report.

The statement follows an advisory from researcher Laurent Gaffie that a remote user can create a specially crafted WAV, SND, or MIDI file to trigger an integer overflow and execute arbitrary code on the target system.

Gaffie claims the bug affects all versions of the media player, including WMP 11.

UPDATE:

Jonathan Ness from Microsoft’s SWI team provides more details on why this bug isn’t exploitable and says it was already discovered internally and slated for fixing in a future service pack:

We found this already through our internal fuzzing efforts. It was correctly triaged at the time as a reliability issue with no security risk to customers. We do like to get these reliability issues fixed in a future service pack or a future version of the platform whenever possible. This particular bug, for example, has already been fixed in Windows Server 2003 Service Pack 2.

On the MSRC blog, Christopher Budd laments the fact that the researcher went public with an advisory instead of reporting it directly to Microsoft.

* Image source: LuChOeDu Flickr photostream (Creative Commons 2.0)

[Source: zdnet]

Microsoft late Monday issued a pre-patch advisory confirming a remote code execution vulnerability affecting its SQL Server line.

The vulnerability, publicly disclosed with exploit code more than two weeks ago, affects Microsoft SQL Server 2000, Microsoft SQL Server 2005, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 Desktop Engine (MSDE 2000), Microsoft SQL Server 2000 Desktop Engine (WMSDE), and Windows Internal Database (WYukon).

From the advisory:

[ SEE: As attacks escalate, MS readies emergency IE patch ]

Microsoft is aware that exploit code has been published on the Internet for the vulnerability addressed by this advisory. Our investigation of this exploit code has verified that it does not affect systems that have had the workarounds listed below applied. Currently, Microsoft is not aware of active attacks that use this exploit code or of customer impact at this time.

In addition, due to the mitigating factors for default installations of MSDE 2000 and SQL Server 2005 Express, Microsoft is not currently aware of any third-party applications that use MSDE 2000 or SQL Server 2005 Express which would be vulnerable to remote attack. However, Microsoft is actively monitoring this situation to provide customer guidance as necessary.

[ SEE: MS Patch Tuesday whopper: 28 vulnerabilities in Windows, IE, Office ]

The vulnerability is not exposed anonymously. An attacker would need to either authenticate to exploit the vulnerability or take advantage of a SQL injection vulnerability in a Web application that is able to authenticate, Microsoft explained.

[Source: zdnet]

A T-SQL script is available to test systems for this issue. In the absence of a patch, Microsoft recommends that SQL Server admins deny permissions on the sp_replwritetovarbin extended stored procedure. See more in the Microsoft advisory.

Microsoft is planning to ship an emergency Internet Explorer update tomorrow (December 17) to counter an escalating wave of malware attacks targeting a zero-day browser vulnerability.

[ SEE: Hackers exploiting (unpatched) IE 7 flaw to launch drive-by attacks ]

The out-of-band update, which will be rated critical, follows the public discovery of password-stealing Trojans exploiting the bug on Chinese-language Web sites. Over the past week, the attacks have expanded with hackers using SQL injection techniques to seed exploits on legitimate Web sites.

[ GALLERY: How to configure Internet Explorer to run securely ]

This will be the second out-of-band update from the MSRC (Microsoft Security Response Center) in the last two months. Back in October, the company shipped MS08-067 to plug an extremely critical worm hole that affected Windows 2000, Windows XP and Windows Server 2003.

The IE patch will be available for all supported versions of the browser. According to this pre-patch advisory from Microsoft, the in-the-wild attacks have targeted IE 7 on Windows XP SP2 and SP3, Windows Server 2003 SP1 and SP2, Windows Vista (including SP1) and Windows Server 2008.

The actual flaw exists in the way IE handles DHTML Data Bindings:

Malicious HTML that targets this vulnerability causes IE to create an array of data binding objects, release one of them, and later reference it. This class of vulnerability is exploitable by preparing heap memory with attacker-controlled data (“heap spray”) before the invalid pointer dereference.

* Image source: jmv’s Flickr photostream (Creative Commons 2.0)

[Source: zdnet]

[ UPDATE: See e-mail from NoScript creator Giorgio Maone on a possible mitigation ]

Researchers are beginning to raise an alarm for what looks like a scary new browser exploit/threat affecting all the major desktop platforms — Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, Opera and Adobe Flash.

The threat, called Clickjacking, was to be discussed at the OWASP NYC AppSec 2008 Conference but, at the request of Adobe and other affected vendors, the talk was nixed until a comprehensive fix is ready.

The two researchers behind the discovery — Robert Hansen (left) and Jeremiah Grossman — have released droplets of information to highlight the severity of this issue.

So, what exactly is Clickjacking?

According to someone who attended the semi-restricted OWASP presentation, the issue is indeed zero-day, affects all the different browsers and has nothing to do with JavaScript:

• In a nutshell, it’s when you visit a malicious website and the attacker is able to take control of the links that your browser visits. The problem affects all of the different browsers except something like lynx. The issue has nothing to do with JavaScript so turning JavaScript off in your browser will not help you. It’s a fundamental flaw with the way your browser works and cannot be fixed with a simple patch. With this exploit, once you’re on the malicious web page, the bad guy can make you click on any link, any button, or anything on the page without you even seeing it happening.

[ SEE: Adobe Flash ads launching clipboard hijack attack ]

If that’s not scary enough, consider than the average end user would have no idea what’s going on during a Clickjack attack.

• Ebay, for example, would be vulnerable to this since you could embed javascript into the web page, although, javascript is not required to exploit this. “It makes it easier in many ways, but you do not need it.” Use lynx to protect yourself and don’t do dynamic anything. You can “sort of” fill out forms and things like that. The exploit requires DHTML. Not letting yourself be framed (framebusting code) will prevent cross-domain clickjacking, but an attacker can still force you to click any links on their page. Each click by the user equals a clickjacking click so something like a flash game is perfect bait.

According to Hansen, the threat scenario was discussed with both Microsoft and Mozilla and they concur independently that this is a tough problem with no easy solution at the moment.

Grossman confirmed that the latest versions of Internet Explorer (including version 8) and Firefox 3 are affected.

• In the meantime, the only fix is to disable browser scripting and plugins. We realize this doesn’t give people much technical detail to go on, but it’s the best we can do right now.

en testing, Google, Denial of Service (DoS), Google Chrome

Aditya K Sood from the EvilFingers community, which disclosed the first Chrome DoS vulnerability at the beginning of the month, has released a proof of concept demonstrating a memory exhaustion DoS vulnerability affecting Google’s Chrome versions Chrome/0.2.149.30 and Chrome/0.2.149.29 :

“The Google chrome browser is vulnerable to memory exhaustion based denial of service which can be triggered remotely.The vulnerability triggers when Carriage Return(\r\n\r\n) is passed as an argument to window.open() function. It makes the Google Chrome to generate number of windows at the same time thereby leading to memory exhaustion. The behavior can be easily checked by looking at the task manager as with no time the memory usage rises high. The problem lies in the handling of object and its value returned by the javascript function. Once it is triggered the pop ups are started generating. The Google Chrome browser generate object windows continuously there by affecting memory of the resultant system. Probably it can be crashed within no time. User interaction is required in this.”

What’s Google’s take on this flaw, and have they acknowledged it already? Zero Day asked the researchers.

Q: This is the second DoS vulnerability that members from EvilFingers disclose. How is the second one different than the first one, and how would a remote attacker take advantage of it?

A: Ideally, both are Denial of Service attacks. But second one is different for the matter that it does a memory exhaustion, or I would say “performance” peaks with the pop-ups. By default, all the pops are blocked by Chrome, but still the CPU usage jumps up to 98% and so does the memory consumption, therefore other processes will surely be affected. And then the PoC for the first one crashes the chrome right away without any reaction time to the user or any user way to prevent the loss of work. But with the second one, an experienced user can prevent the same and can save work of other tabs before resulting in a browser restart. Or put in another way, first one is a crash of all tabs, second one is a hang of tabs.

Q: Since you’re responsibly disclosing the vulnerabilities that you find to Google, what is your opinion on their current response time and overall attitude towards the vulnerabilities that you’ve reported?

A: Response time with the first one was well appreciable, as it was fixed within 24hrs though it took some days to roll out next 0.2.149.29 ‘patched’ version. For this newer DoS, the patch is yet to roll out and they have acknowledged the bug for now.

Has Google’s Chrome level of exploitability changed since the first DoS vulnerability? It may well be declining considering some recently published browser market-share statistics, clearly indicating that a lot of users seems to have given Chrome a try, and are back to their default browsers. According to published Chrome stats by Net Application :

“At the end of its third week of availability, Google Inc.’s Chrome accounted for 0.77% of the browsers that visited the 40,000 sites tracked by Net Applications, down from a 0.85% share the week before. “The trend line on Chrome still has a slight downward angle, and these weekly numbers reflect that,” said Vince Vizzaccaro, Net Applications’ executive vice president of marketing. Although Chrome popped above 1% within hours of its release, the new browser now reaches that mark only in the middle of the night, U.S. time, Vizzaccaro added.”

StatCounter’s latest Chrome stats of over 450M page views globally, also indicate the introduction period and the slight decline afterwards. Chrome’s popularity is proportional with its level of exploitability, so keeping an eye on how many users stick with the (BETA) browser, will either increase or decrease it.

[Source: zdnet]

Microsoft’s scheduled batch of patches for November crossed the wires today with fixes for at least four documented vulnerabilities affecting millions of Windows and Office users.

As previously reported, the company released two security bulletins — one rated critical, one rated important — with fixes for flaws that could lead to remote code execution attacks. The updates apply to users running all supported versions of Windows (including Vista and Windows Server 2008) and most versions of Microsoft Office.

The critical MS08-069 bulletin should be treated with the utmost priority because of the risk of remote code execution attacks if a Windows user is simply tricked into browsing to a rigged Web page with Internet Explorer.

Details from the bulletin:

• CVE-2007-0099: A remote code execution vulnerability exists in the way that Microsoft XML Core Services parses XML content. The vulnerability could allow remote code execution if a user browses a Web site that contains specially crafted content or opens specially crafted HTML e-mail. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
• CVE-2008-4029: An information disclosure vulnerability exists in the way that Microsoft XML Core Services handles error checks for external document type definitions (DTDs). The vulnerability could allow information disclosure if a user browses a Web site that contains specially crafted content or opens specially crafted HTML e-mail. An attacker who successfully exploited this vulnerability could read data from a Web page in another domain in Internet Explorer. In all cases, however, an attacker would have no way to force users to visit these Web sites.
• CVE-2008-4033: An information disclosure vulnerability exists in the way that Microsoft XML Core Services handles transfer-encoding headers. The vulnerability could allow information disclosure if a user browses a Web site that contains specially crafted content or opens specially crafted HTML e-mail. An attacker who successfully exploited this vulnerability could read data from a Web page in another domain in Internet Explorer.

The second update — MS08-068 — provides cover for a publicly disclosed vulnerability in Microsoft Server Message Block (SMB) Protocol. Exploit code for this flaw is currently available on the Internet.

• CVE-2008-4037: A remote code execution vulnerability exists in the way that Microsoft Server Message Block (SMB) Protocol handles NTLM credentials when a user connects to an attacker’s SMB server. This vulnerability allows an attacker to replay the user’s credentials back to them and execute code in the context of the logged-on user. If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

One of the code execution vulnerabilities fixed in this month’s Microsoft Patch Tuesday release dates back to 2001 when it was first disclosed by Cult of the Dead Cow hacker Sir Dystic (pictured left).

If that wasn’t cause for worry, get this: An exploit for the bug — in the way that Microsoft Server Message Block (SMB) Protocol handles NTLM credentials — has been part of the Metasploit hacking tool since July 2007.

So, why did it take Microsoft seven years to fix something that could lead to full system takeover?

Microsoft’s Christopher Budd explains:

When this issue was first raised back in 2001, we said that we could not make changes to address this issue without negatively impacting network-based applications. And to be clear, the impact would have been to render many (or nearly all) customers’ network-based applications then inoperable. For instance, an Outlook 2000 client wouldn’t have been able to communicate with an Exchange 2000 server. We did say that customers who were concerned about this issue could use SMB signing as an effective mitigation, but, the reality was that there were similar constraints that made it infeasible for customers to implement SMB signing.

[ SEE: Responsible disclosure, the Microsoft way ]

Sisk said the case was never closed and investigations continued over the years to determine if there was a way to fix the bug without requiring developers to completely rewrite applications.

Over the course of the past year, however, that ongoing work showed us a way to build on those incremental changes that we believed would enable us to make changes that address the issues outlined in the SMBRelay attack and also minimize the impact on network applications. If we were able to do that, we would be able to look at addressing this issue not in a new version of Windows but instead in a security update, provided it met the appropriate quality bar.

Our engineering teams spent a great deal of time testing this approach and found it was feasible. We then took that work and developed it into a security update, putting it through our standard testing to ensure it met an appropriate level of quality for broad release. What we released today with MS08-068 is that security update. It addresses the SMBRelay issue but does so in a way that doesn’t have the negative impact on applications that we originally believed addressing this issue would have.

[ SEE: Where on earth are these Microsoft patches? ]

Microsoft wasn’t alone discussing attack paths to this old vulnerability. In 2003, on the Full Disclosure mailing list, there’s evidence of public discussion of the issue and a note by Dave Aitel that it was already part of a previous DefCon presentation.

Microsoft has done an amazing job of improving its security response process but these time-to-patch hiccups continue to be a major source of worry. I’ve documented several times in the past when Microsoft failed to fix issues in a timely — and responsible — manner and these examples only highlight one of the company’s biggest security weakness.

Oh, by the way, there’s another outstanding issue collecting cobweb. This ‘token kidnapping’ issue was first discussed in March 2008 and, after a bit of hemming and hawing, confirmed in this Microsoft security advisory. Exploit code for this privilege escalation vulnerability was publicly released last month.

Microsoft knows all this.

We are still waiting on a patch.

[Source: zdnet]

First came Microsoft’s emergency patch. Then the public release of reliable exploit code. Now, virus hunters are reporting two new in-the-wild worms exploiting the critical MS08-067 vulnerability.

The worms, intercepted on Chinese-language versions of Windows, are being used to install a Trojan downloader, a denial-of-service bot and a rootkit to maintain stealthy presence on infected machines.

[ SEE: MS ships emergency patch for Windows worm hole ]

The in-the-wild attacks are using portions of the proof-of-concept code that’s publicly available, according to a source tracking this new threat.

One of the two worms spotted is capable of conducting DDoS (distributed denial-of-service) attacks against several Chinese sites, including the two big search engines Google and Baidu. It also downloads the eMule peer-to-peer program and drops an erotic movie on the hijacked system.

Windows users that have applied the MS08-067 update are not vulnerable to these attacks. Patch now.

[Source: zdnet]

One would assume that popular sources for zero day vulnerabilities+Poc’s such as Full-Disclosure, Bugtraq or Milw0rm are the primary sources for obtaining responsibly or irresponsibly released flaws. They’d be wrong. The black market for zero day vulnerabilities and the concept of over-the-counter (OTC) trade of zero day flaws, has been gradually developing itself through the last couple of years.

Let’s take a brief retrospective of the black market for zero day vulnerabilities, and review a recently launched underground shop for zero day vulnerabilities, currently offering 15 zero day vulnerabilities affecting popular web applications in order to execute successful XSS or SQL injection attacks, with prices ranging from $10 to $300.

Back in 2005, a bid for a zero day vulnerability affecting Microsoft’s Office Excel was posted on Ebay prompting mass media outbreak on the potential of rewarding security researchers for their research. It didn’t take long before a zero day vulnerabilities cash bubble started to form, with legitimate sellers and cybercriminals over hyping the seriousness of their discoveries. Around December, 2005, the first publicly disclosed case of underground market trade of zero day vulnerabilities took place when it became evident that the the infamous Windows Metafile vulnerability (WMF vulnerability) has been sold for $4,000 :

“It seems most likely that the vulnerability was detected by an unnamed person around 1st December 2005, give or take a few days. It took a few days for the exploit enabling random code to be executed on the victim machine to be developed. Around the middle of December, this exploit could be bought from a number of specialized sites. It seems that two or three competing hacker groups from Russian were selling this exploit for $4,000. Interestingly, the groups don’t seem to have understood the exact nature of the vulnerability. One of the purchasers of the exploit is involved in the criminal adware/ spyware business, and it seems likely that this was how the exploit became public.”

Interestingly, the authors of the then popular WebAttacker DIY web exploitation kit started conducting basic market research on the potential of this market, by featuring a survey asking their visits how much would they be willing to pay for a zero day vulnerability. The results out of 155 votes indicated that 40% of the potential buyers were willing to pay between $100 and $300, with 14.19% answering that they code their own zero day exploits and another 17% stating that they obtain them for free.

It didn’t take long before the underground market model materialized in the face of the International Exploits Shop, among the first underground offerings of a web malware exploitation kit featuring a multitude of client-side vulnerabilities, next to two zero day flaws back in 2006. And whereas the shop quickly disappeared, the concept always remained there.

In times when legitimate online auctions for zero day vulnerabilities are admitting that the market model they’ve introduced is far ahead of its time, their underground alternatives are thriving. Launched in early August, this web based shop is the latest attempt to utilize a black market model for zero day vulnerabilities.

Here’s a translated introduction to the exploits shop :

“We present you the private exploits shop targeting PHP-applications (Content Management Systems, Guest books, forums, chat rooms, statistics and any other scripts). Our store will be constantly updated so you can expect to find the exploit you were looking for at any given time. If it doesn’t you will still be able to request such a vulnerability for a web application of your choice, and our team will provide with you the necessary PoC’s and tools to start using it. All exploits are written solely to our command, meaning you’re not going to find them anywhere else on the Internet.

Each exploit is accompanied by information on the approximate number of sites running the vulnerable application in Google, the language the exploit is written in, and price. We also have a forum where you can place an order, discuss, complain, express an opinion or ask a question about the exploit purchased. All exploits have a user-friendly Web interface, possibly in the future we’ll be releasing win32 console exploits. There are also technical support, patiently waiting for requests from users who have a problem using the exploit. We also conduct audits, security services, tests for entry (this service will be available by the end of August this year).

Watch our virtual merchandise, and if not today perhaps tomorrow you’ll find what you’re looking for.”

What’s particularly interesting about the service is the major shift towards exploitation of web applications in order to facilitate massive SQL injection attacks compared to previously known and analyzed services focusing exclusively on client-side vulnerabilities.

As always, you have a pure cybercrime market proposition pitched as a security service. The e-shop is not only offering proof of concept exploits to demonstrate the vulnerabilities, but also, easy to use web based applications for exploitation.

Moreover, this pseudo responsible positioning is flawed right from very beginning since the service administrators have done their homework and are also offering stats from basic search engines reconnaissance — Google dorks — so that potential buyers can easily measure the impact of the flaw that they’re purchasing. These very same vulnerabilities would later on be abused for blackhat search engine optimization, and injection of malicious scripts redirecting to live exploit serving URLS. Here’s their ethical pen-testing pitch :

“Our team is reviewing source code software and finding bugs in the programming, leading to critical consequences and employees of security systems. Thus, we are pleased to offer you the results of their analysis of popular (or little) systems. The results of our study are presented in the form of finished applications in languages php / perl, which aim - to demonstrate the vulnerability of the system to further assist in their neutralization. If you’re going to use our software for other purposes than penetration testing, the administration does not take responsibility for your actions.

We also take orders for individual study of your source code, security auditing of servers and sites (penetration tests). Orders for such services are taken at the forum, and the price purely individual and dealt with each customer individually (mainly depends on the number and type of vulnerabilities discovered, as well as the number of code).”

Which products are they targeting? Currently offered zero days affect multiple versions of the following web applications :

- All versions of PHP Fusion
- WHMCompleteSolution
- PHP Nuke
- PunBB
- Tiki Wiki
- BMForum
- Invision Power Board
- YaBB
- PunBB
- e170 Plugin Calendar
- vBulletin v3.6 + ICQ Mod
- vBulletin v3.6 + GVideo Mod
- vBulletin v3.6 + Youtube Mod
- vBulletin v3.6 + LJ Mod
- Zen Cart

The most expensive is the $300 SQL injection flaw affecting all versions of PHP Fusion, which can be exploited on a large scale since there are over 2.5 million instances of it on the web, and even if the stats are conservative this hit list building approach through search engines reconnaissance has always been there, with the most recent proof of its usability were the massive SQL injections attacks.

Next to their current inventory, the service is also offering zero day vulnerabilities on demand charging the following prices :

“- Remotely upload shell - $120
- Remote file inclusion on request - $100
- Remote SQL injection - $70
- Passive and Active XSS for $10 and $40 respectively”

This overall shift from client-side vulnerabilities to web applications based ones is taking place due to the increasing demand for techniques allowing the easy hijacking of traffic from legitimate web sites, which is where these web application vulnerabilities fit in. Once they acquire the traffic by exploiting them, they would ultimately redirect it to malware and exploits serving domains taking advantage of outdated but unpatched on a large scale client-side vulnerabilities. It’s all a matter of perspective, and the people behind this particular e-shop for zero days are taking the pragmatic one by offering the right product for the right moment.

[Source: zdnet]

Guest editorial by Aviv Raff

If you ask any Opera fanboy, he will tell you that Opera is the most secured browser. Well frankly, it really is a good and secure browser, implementing many restrictions that other browsers simply ignore.

For example, while other browsers allow scripts running from local resources to access local files Opera doesn’t. And by that, it is almost impossible to steal local files, or execute code by exploiting vulnerabilities local resources.

You probably noticed that I used the word almost. It is almost impossible, due to the fact that one, and only one local resource, does allow you to access local files and other browser settings. The local resource is opera:config.

[ SEE: On Opera patch day, a new zero-day flaw ]

One of the many settings this local resource can be used to change is the mail external application. The mail external application will be opened whenever you click on a “mailto:” link, or whenever your browser redirects to a “mailto:” URL. If an attacker can change this setting it means that he can automatically execute arbitrary code on the user’s machine from remote.

This is of course irrelevant, unless you can actually change the settings automatically from remote, and unfortunately for Opera users, there was a way.

Today, Opera released a new version, 9.62, with a fix for a vulnerability in a different local resource - the “History Search” page (opera:historysearch). The problem was that Opera did not sanitize specific parameters correctly, and an arbitrary script could be injected to this page. An attacker could then execute a script that will create an iframe which will open the opera:config local resource. And then, it will call a script within the opera:config page, which will change the settings and execute arbitrary code on the user’s machine as previously explained.

[ SEE: Opera bitten by ‘extremely severe’ browser bug ]

The vulnerability in the “History Search” page was found by Stefano Di Paola, during our discussion on the full-disclosure mailing about an older vulnerability in the “History Page” that was found by Roberto Suggi and was fixed by Opera in version 9.61. I’ve created proof-of-concept codes which demonstrate the vulnerabilities. Both can be found on milw0rm.com.

While both vulnerabilities in the “History Page” are now fixed, the core problem which makes it possible to execute code from remote, still isn’t.

There is still no Same Origin Policy restriction between local resources in Opera. It is still possible for a script to access one local resource (e.g. opera:cache) from another (e.g. opera:config). In my submission to Opera I’ve asked them to fix this issue as well, and I really hope they will do so before other vulnerabilities will be found in more local resources.

Nevertheless, my recommendation for Opera users is still to upgrade to the latest version.

* Aviv Raff manages a security research team for a Fortune 500 company. You can read about his research at his blog or follow his daily activities on Twitter.