Safari and Internet Explorer Fall on Day 1, Chrome Remains Undefeated in Annual Hackfest

History repeated itself, once again, on the first day of pwn2own, an annual hacking competition where hackers try to break through the defense of modern browsers and operating systems. Safari and Internet Explorer were once again successfully exploited by hackers, while Chrome remained unchallenged and undefeated.

Pwn2OwnSafari, which was the first browser to be challenged, fell within five seconds. The French security firm VUPEN managed to both execute arbitrary code (launch the Calculator), and bypass sandbox protection (write file on the hard disk). The technique used by VUPEN required development of tools from the scratch and took about three weeks to put together. VUPEN’s success is notable because shortly before the contest began, Apple patched as many as 62 vulnerabilities in a massive security update.

Next up was Internet Explorer, which met a similar fate at the hands of Stephen Fewer. Fewer exploited three separate vulnerabilities to execute Calculator and write a file to the disk. Unlike Apple, Microsoft hadn’t even bothered to issue any security updates last week.

The final browser that was supposed to be tested today was Chrome. However, the single contestant who had signed up to take a crack at Chrome didn’t turn up. So Chrome finished the day unchallenged and undefeated. Like Apple, Google had also released a major security update to Chrome in which at least 24 vulnerabilities were patched. It’s likely that the contestant dropped out because the zero-day vulnerability he planned on using was fixed by Google.

Firefox is slated to be challenged tomorrow. Should it fall, Google Chrome will be the last browser standing for the third consecutive year. Opera is not included in the competition as the organisers are of the opinion that its current user base of 53 million is not large enough.

Google Uses Kill-Switch to Remotely Uninstall Android Malware, Pushes Update to Undo Changes

Earlier in the week, a Redditor uncovered a large network of malwares masquerading as popular apps in the Android Market, when he stumbled upon one of the apps and noticed its incorrect publisher info. Android Police has a lowdown on the incident, which once again demonstrated how easy it is to infiltrate the Android Market. The fake apps, once downloaded, proceeded to root the phone using the famous “rageagainstthecage” exploit, and called home. It also had the potential to download additional payloads.

Android-Malware-AttackFor its part, Google reacted swiftly, and pulled the apps minutes after being notified by Android Police. However, according to information provided by “lompolo”, the Redditor who uncovered this entire mess, some of the app developers were already aware of this for as long as a week, but their complaints fell on deaf ears. The apps injected with malware, which were dubbed as DroidDream by Lookout, only affected handsets running versions older than Android 2.2.2. Google found DroidDream in 58 applications, which were downloaded onto 260,000 devices.

Google believes that the apps only uploaded device information (IMEI/IMSI, unique codes which are used to identify mobile devices, and the version of Android running on your device), and not user-data. After pulling the apps, and performing its initial investigation, Google is now moving to rectify the damage caused. It is in the process of removing the apps from all handsets by employing the remote kill-switch built into Android. It is also pushing through a new update called “Android Market Security Tool March 2011″ to affected devices. This update will undo the changes made by DroidDream. If you were among the affected users, expect an email from Google soon.

This entire saga raises several questions. Obviously, as Android’s popularity continues to surge, more and more hackers and malware writers will target it. Unfortunately, it’s clear that Google is simply in no position to mitigate these attacks before they occur. The “openness” of the Market is becoming Android’s biggest security weakness. Although most Android users have nothing but disdain for any app review system, I would welcome a change in the Market policy, whereby all submitted apps are screened for signs of malicious or fraudulent activities. Google might also need to give a serious thought to how it deploys security updates. Apple and Microsoft have full control over deploying critical system updates, unlike Google, which is at the mercy of handset manufacturers and carriers. Although the bug that was exploited by DroidDream was fixed in Android 2.2.2, hundreds of thousands of handsets were successfully compromised because Android 2.2.2 isn’t yet available for a substantial number of handsets. Unless Google can reign in the fragmentation problem, it might have to start deploying hotfixes for different versions of Android to patch critical security vulnerabilities, i.e. employ a Windows like model of distributing patches to different OS versions. What is your take on this issue? Chime in by dropping a comment here or in our Facebook page.

SourceForge.net Resets All User Passwords in Wake of a Sniffing Attempt

Attacks on passwords, security and privacy are becoming bolder and stronger. Recently, Sourceforge.net had warned its users of a possible attack on their passwords with a blog post.

sourceforge-down

Although, the blog is down now as they are carrying out database maintenance, we can still show you the email via Sathyajit that says,

Hello,

We recently experienced a directed attack on SourceForge infrastructure
(http://sourceforge.net/blog/sourceforge-net-attack/) and so we are
resetting all passwords in the sf.net database — just in case. We’re
e-mailing all sf.net registered account holders to let you know about this
change to your account.

Our investigation uncovered evidence of password sniffing attempts. We have
no evidence to suggest that your password has been compromised. But, what
we definitely don’t want is to find out in 2 months that passwords were
compromised and we didn’t take action.

So, as a proactive measure we’ve invalidated your SourceForge.net account
password. To access the site again, you’ll need to go through the email
recovery process and choose a shiny new password:

https://sourceforge.net/account/registration/recover.php

If you need help with this, feel free to e-mail us:

[email protected]

We appreciate your patience with us as we work to respond to this attack.
We’ll be working through the weekend to get things back to normal as
quickly as possible.

Watch for updates on the service outages on our blog:

http://sourceforge.net/blog/

Thank you,

The SourceForge Team

Given the last fiasco at Gawker media and Mozilla, we sure have to wake up and stop using MD5.

As a failsafe method, we should reset our passwords at major websites like Google and other developer networks regularly. This can work well towards keeping you safe. You can check the Sourceforge blog for details once the page is back up.

Android 2.3 Still Vulnerable To Previously “Fixed” Data Theft

Do you remember that old vulnerability in Android 2.2 that allowed an attacker to grab data off an SD card, provided they knew the absolute path of a file and were able to get a user to visit a specially crafted site? Well, Google specifically stated they would fix the issue in 2.3 Gingerbread. It would seem that they did indeed patch something in a hotfix – but the issue cropped up again. Xuxian Jiang, an assistant professor in the Department of Computer Science at North Carolina State University has confirmed with Google’s Security team that a related vulnerability still exists in the “shipping” branch of Gingerbread. This means that the fabled Nexus S is being boxed, bought and used with a very exploitable security hole. Fortunately, the team says they are unaware of any active exploitation of this in the wild.

With manufacturers and carriers only now upgrading devices to the old and relatively antiquated releases of 2.1, how many devices does this leave vulnerable? As far as it’s known, 2.2 devices have not received an update that completely closes this security hole. It also looks as if all the new devices on the horizon that are slated to be released with Android 2.3 may be vulnerable to this as well. Google may deny that fragmentation is a problem for users, but when security is at hand and you can’t patch your mobile device due to the OS being fingered by 3 different companies before you get it (Google, OEM, carrier) then it should be a huge concern for consumers. For those enterprising users who want take all attempts to reduce their risk, it is recommended that you use a third party browser or completely disable javascript in the stock browser until the issue is resolved.

Stuxnet Was Not Well Written, But Required Diverse Coding Skills

The Stuxnet worm has become a thing of interest among hackers. It has displayed immense potential and has hit a nation at its ultimate reserve- energy. An analysis of the worm by Tom Parker has revealed some interesting facts at the Black Hat DC conference on Tuesday. The most interesting facts are the two-phase nature of the development of Stuxnet and the unprotected and evident obviousness of its behavior.

The analysis by Parker reveals that an expert group of talents, who specialized in reverse-engineering platforms, proprietary file formats and developing kernel rootkits initially, designed the worm to be deployed. However, these talents were used as a third party in the development process and there was another team of less talented hackers responsible for implementing the worm. This is where the plan suffered a setback. The deployment was not of the same level of expertise of the development phase and probably could not make full use of the entire potential of Stuxnet.

Another fact that security experts are advocating is that the Stuxnet developers made minimal effort to hide the payload data and the data transmission could be better hidden. It was almost as if the developers of Stuxnet wanted it to be found and understood. Also, there was no anti-debugging code obfuscation involved in the development of Stuxnet. The only possible conclusion is that the developers of Stuxnet did not have enough time to incorporate these protections and were under pressure to deploy the code even before it was completely ready.

Trojan Horse For Android Listens To And Stores Credit Card Numbers

Once again, Android is in the limelight for malware, this time it’s a trojan horse installed on the device that is triggered by outgoing calls, that has the ability to store credit card numbers that are input either via touch tone (DTMF decoding) or by analysing voice input and then converting it to text. The application, Soundminder, is a relatively small application weighing in at just over 1MB and uses minimal permissions to capture, store and analyse any information that is input via voice or the dial-pad. It takes roughly 15 seconds to convert the voice audio into actual numbers and then the information is stored to be used at a later time. Enter the partner in crime to Soundminder, Deliverer. Deliverer is a tiny application that uses network permissions to transfer the captured information to a hosted server so the attacker can view the credit card numbers.

Together, the applications use a covert method of transferring the data back and forth. Since Android uses sandboxing and separate user accounts for each running process, it is very hard for applications to share information without explicitly requesting permissions. Since Soundminder has write access to certain hardware, it can adjust device settings such as LCD timeout, ringer volume and other seemingly innocuous values. Deliverer can then read the values, obtain the information and send the stored credit card numbers to an attacker.

Soundminder has less invasive permissions than other applications in the Android Market, so it would be extremely easy for a user to assume it to be safe and install it. Hopefully Google can find a way to list permissions on a lower item level, so users can see exactly what API calls an app has access to.

See below for the video.

Motorola Gets Questioned About Their Locked Down Bootloader

If you can remember when the Motorola Milestone launched, which was ages ago in the technology world, it came with chip technology called “e-Fuse”. For all intents and purposes, this was a blatant attempt by Motorola to stop hackers and developers from booting custom firmware on their devices and protecting their own intellectual property, such as MotoBLUR. Some of the reasons that people purchase Android devices, is solely because they have much more open access to the hardware than they would compared to an iPhone, Windows Phone 7 or webOS device. HTC seems to understand this and provides a way for users to unlock their devices albeit forgoing their warranty. Perhaps this is why Google chose HTC as their OEM for the Nexus One and it was a big hit with the community.

Today, a user posted a question to Motorola’s YouTube account asking about dock support for the up and coming Atrix 4G. The poster was met with a response – @tdcrooks if you want to do custom roms, then buy elsewhere, we’ll continue with our strategy that is working thanks. Moments after the AndroidCentral member posted it to their forums, Motorola removed all the comments off their page and started on damage control.

They posted up a Note on their Facebook page apologizing for the comment made by one of their employees. They are also claiming that there will be a work-around for their future devices in order to allow developers to use devices “as a development platform” but still giving them the ability to “protect our users’ interests”. Keeping in mind that because Texas Instruments has eFuse embedded in a lot of their chips, Motorola does have the power to re-program the “fuse” on the fly – this means that Motorola could ship out binaries to requesting developers, which would allow them to bypass the fuse and give them lower level access to the hardware.

There are many choices out there if you’re looking for an Android handset. If you disagree with the practices of Motorola, the best option would be to vote with your wallet.

Microsoft Developer Blogger Shows Easy Sniffing Of WP7 Traffic

Do you fancy investigating any traffic being sent in and out of your Windows Phone 7 device? Aside from the more involved method of using a packet sniffer on your phone or capturing the data over a wireless connection and decrypting it, a member of the Microsoft Developer Network (MSDN) has gone ahead and given some extremely straight forward steps on how to set up a man-in-the-middle proxy to capture and store all HTTP and HTTPS traffic. How it works is very simple – Fiddler, a web debugging proxy, is run on a Windows PC and acts as an intermediary gateway to the outside world, once you configure your device to pass information through it, Fiddler will capture, display and allow you to modify the passing traffic.

What legitimate use case could this have? Well it’s useful for developers who are writing apps, however it’s especially useful for enterprising hackers, do-it-yourselfers and anybody else who is concerned about the information that apps are uploading. Microsoft does have very stringent rules for allowing applications into the Marketplace, but as we’ve seen before with the Apple AppStore and the Android Market, sometimes things either slip through the cracks or are obfuscated enough that the QA team is fooled which allows the malicious code to go live. With Fiddler, you can see full HTTP streams and if you do choose to install the SSL certificate – all HTTPS encrypted traffic can be re-signed using the cert and then decrypted at will.

While most developers will be using the emulator to do the majority of their development work, when it comes to real deployment and users who want to get started in monitoring their device traffic, they should visit the post on the MSDN Blog by Eric Lawrence and follow the provided instructions.

RIM Releases Security Advisory For DoS Against BES And Devices

RIM has carved the way with enterprise security and holds a high amount of corporate users in the mobile market, but every now and then they encounter speed bumps that might come in the form of support issues, bugs and security vulnerabilities. While Blackberry doesn’t see near the amount of publicly disclosed weaknesses as other mobile platforms such as Android or webOS, RIM does regularly audit and push updates to BES, BIS and client device software aimed at closing and mitigating possible security risks related to their software. KB24547 is a security advisory that RIM published late in 2010, indicating the existence of a vulnerability pertaining to the PDF rendering and control engine of the attachment service in BES 5.x as well as third party applications that utilise BES core, such as Microsoft Exchange, IBM Lotus Notes Domino and Novell GroupWise.

The advisory details the susceptibility of BES to a possible buffer overflow leading to a Denial-of-Service on a hand-held device. For the vulnerability to be successfully exploited, an attacker would need to have a Blackberry user, with an account tied to a BES, open a modified PDF file. The PDF would be “filtered” through the attachment service and may allow an attacker to execute code on the BES hosting server or hang the machine. RIM has marked it extremely high, with a CVSS (Common Vulnerability Scoring System) score of 9.3 out of 10. It is recommended that all BES administrators obtain the Interim Security Software Update to ensure they are protected.

In addition to the BES vulnerability, RIM has released an advisory for a client-side DoS affecting hand-held Blackberry devices. While the CVSS score is a relatively low 5 out of 10, RIM recommends that all users ensure they are running the most up to date version of their device software. The vulnerability affects many devices running OS 5.0.0.x and causes the browser to hang while processing a specially crafted web page, forcing the user to reboot the device. Advisory KB24841 was issued less than a week ago and affects many devices including the Blackberry Bold 9700, the Tour 9630 and the Curve 9300.

Adobe Flash Sandbox Cracked, Takes It Back To Square One

On Tuesday, a security researcher Billy Rios demonstrated a proof-of-concept attack depicting the vulnerability in Adobe flash sandbox. The sandboxing system used by Adobe flash has a simple hack that allows it to communicate to a remote host.

flash-logo

Adobe had done a good job in sandboxing technologies like Flash and Reader as they were the most vulnerable contents on the Internet. However, now it seems that this sandboxing can be broken without writing a single line of code. Ross has proved this by simply changing Windows settings, which was enough for cracking the sandbox on Adobe Flash. However, the Google Chromes sandbox for Adobe Flash is safe from this attack.

This has been reported at Information Week as:

In particular, Rios tapped the mhtml protocol handler that’s built into Windows 7 and which will launch with no warning to the user. With mhtml, “it’s easy to bypass the Flash sandbox,” he said, and transmits data to a remote server without a user ever knowing that the exploit occurred.

Anup Ghosh, the founder and chief scientist of Invincea, a company that deals with sandboxing technologies had this to say:

This is a flaw in design, it’s not a flaw in implementation or coding.

From what is being reported everywhere, this hack can be prevented by blocking the mhtml protocol. Adobe is yet to comment on this vulnerability.

(Image via: Webmonkey)