4 X Security Team

The police executed a bench warrant and arrested a 60-year-old man resident of Solana Beach, California. He is charged with computer intrusion and extortion and he is scheduled to appear in a federal court on October 31. Bruce Mengler is accused of hacking his way into a promotional website belonging to the US branch of car manufacturer Maserati and retrieving personal information about the company's potential customers.

The stolen personal data was gathered by Maserati as part of a promotion that was offering free gift certificates in exchange for participation in a test drive. The company distributed fliers to potential customers containing an invitation to test drive Maserati cars. The fliers contained a unique identification code intended to be used by the interested people on a promotional website in order to receive gift certificates usable at Omaha Steaks. Along with the code on the flier, people were asked on the website to also provide personal contact information.

The indictment does not specify exactly how Mengler accessed the information, but it suggests that he successfully downloaded the entire database, then blackmailed Maserati by asking money in return for his silence. He is supposed to have sent several letters from a “sol.beach@gmail.com” email address threatening to disclose the information and the incident publicly if he was not paid. To prove the authenticity of his claims, he included samples of the stolen information.

The company's losses are estimated at around $5,000, but the most important aspect of this incident is represented by the security policies adopted by companies in regard to customers’ personal data. 2008 has already been tagged by security researchers as “the data loss year” due to the increased number of cases where sensitive data was lost by employees, stolen by hackers or leaked through website security holes.

Graham Cluley, Senior Technology Consultant for security vendor Sophos, noted on his blog referring to the case that "if a hacker was able to gain access to customer information via the promotional website then there is a clear warning here to all companies that they need to properly secure their public websites". Undergoing such marketing campaigns where sensitive customer info is gathered is fine as long as they are performed in accordance to responsible security practices. “It’s all very well asking for potential customers to enter their names and addresses in exchange for free steaks, but you’ll be dealing with higher stakes (groan…) if your website is not properly defended,” Mr. Cluley adds.

[Source: softpedia]

Just days after shipping a patch for a dozen serious security holes in Firefox, Mozilla has rushed out another version to fix an annoying password manager bug.

The newest Firefox 3.0.3 basically fixes a problem where users were unable to retrieve saved passwords or save new passwords.

Firefox’s Mike Beltzner explains:

• The symptom is that users who have password data stores with non-ASCII data saved as something other than UTF-8 (more common for people who have saved passwords on IDN domains or non en-US domains) will not be able to access their saved passwords or create any new saved passwords. There is no permanent dataloss, the saved data is just inaccessible.

Also see Bug 454708.

[Source: zdnet]

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]

In response to my story earlier on the cross-browser Clickjacking exploit/threat, I received the following e-mail from Giorgio Maone, creator of the popular Firefox NoScript plug-in:

Hi Ryan,

I’ve seen a lot of speculation and confusion in the comments to your Clickjacking article about NoScript not being able to mitigate [the issue].

I had access to detailed information about how this attack works and I can tell you the following:

1. It’s really scary
2. NoScript in its default configuration can defeat most of the possible attack scenarios (i.e. the most practical, effective and dangerous) — see this comment by Jeremiah Grossman himself.
3. For 100% protection by NoScript, you need to check the “Plugins|Forbid

Cheers,
Giorgio

I also received private confirmation from a high-level source at an affected vendor about the true severity of this issue. In a nutshell, I was told that it’s indeed “very, freaking scary” and “near impossible” to fix properly.

Tod Beardsley from BreakingPoint has posted a few proof-of-concept exploits with speculation around clickjacking.

[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.

[Source: zdnet]

Apple today released Java for Mac OS X 10.5 Update 2 with patches for a total of 25 documented security flaws that could expose Mac users to malicious code execution attacks.

Two of the 25 flaws are specific to Apple and could be exploited to launch drive-by attacks if a Mac user is tricked into visiting a maliciously rigged Web page.

The two bugs affect Mac OS X v10.5.4 and Mac OS X Server v10.5.4 and address:

• CVE-2008-3638: The Java plug-in does not block applets from launching file:// URLs. Visiting a website containing a maliciously crafted Java applet may allow a remote attacker to launch local files, which may lead to arbitrary code execution. This update addresses the issue through improved handling of URLs. This is an Apple-specific issue. Credit to Nitesh Dhanjani and Billy Rios for reporting this issue.
• CVE-2008-3637: An error checking issue leading to the use of an uninitialized variable exists in the Hash-based Message Authentication Code (HMAC) provider used for generating MD5 and SHA-1 hashes. Visiting a website containing a maliciously crafted Java applet may lead to arbitrary code execution. This update addresses the issue through improved error handling. This is an Apple-specific issue. Credit to Radim Marek for reporting this issue.

The mega update also addresses multiple serious vulnerabilities in Java 1.4.2_16, Java 1.5.0_13 and Java 1.6.0_05.

[Source: zdnet]

Today is a very busy patch day for network administrations managing Cisco gear.

The networking giant released a whopping 12 bulletins with fixes for a wide range of security vulnerabilities in IOS, the underlying software that powers routers and network switches.

Some of the flaws could allow a malicious hacker to take complete control of vulnerable devices while others put Cisco customers at risk of denial-of-service attacks.

The most serious issue in this patch batch carries a maximum CVSS base score of 10.0 and affects the Cisco uBR10012 series devices:

Cisco uBR10012 series devices need to communicate with an RF Switch when configured for linecard redundancy. This communication is based on SNMP (Simple Network Management Protocol). When linecard redundancy is enabled on a Cisco uBR10012 series device, SNMP is also automatically enabled with a default community string of private that has read/write privileges. Since there are no access restrictions on this community string, it may be exploited by an attacker to gain complete control of the device. Changing the default community string, adding access restrictions on SNMP or doing both will mitigate this vulnerability. The recommended mitigation is to do both.Blogger: 4 X Security Team - Create Post

Network administrators managing Cisco gear (with IOS) and strongly urged to review all the September 24 patches listed here and prioritize fixes according to severity rating scores. In cases where mitigations are offered, those should be applied where necessary.

[Source: zdnet]