Mac OS X Skype 0day Remote Code Execution Vulnerability [Updated]
A fairly significant 0day vulnerability is being reported in the Skype client (< 5.1.0.922) for Mac OS X. By sending a specially-crafted instant message, an attacker may be able to remotely execute code on the recipient’s computer and gain access to a root shell. This issue has been discovered (by accident it seems) by Gordon Maddern of Australian security consultancy Pure Hacking.
“About a month ago I was chatting on skype to a collegue about a payload for one of our clients. Completely by accident, my payload executed in my collegues skype client. I decided to investigate a little further and found that the Windows and Linux clients were not vulnerable. It was only the Mac skype client that seemed to be affected. […] Low and behold (sic) I was able to remotely gain a shell.”
It is believed that due to the relative simplicity in the delivery of the payload, it may be possible for this attack to be automated in the form of a worm. Skype are aware of this issue, but have yet to release a patch (see below). Mac users should be extra careful until a patch is made available, and in the short term I recommend quitting Skype when not using it, or at least checking that your Skype client is set to only allow messages from your contacts (Skype > Preferences > Privacy Tab > Allow Messages From: Contacts).
No further details or proof-of-concept of the vulnerability are available as of yet, although I’d be interested to see it… time to start pasting random Metasploit payloads into Skype! ;)
[Updated 8/5/2011] Skype addressed this vulnerability in version 5.1.0.922 of the Mac OS X client. Run the updater by going to the Skype menu > Check for Updates, or download the latest version here.
Full disclosure of the vulnerability is now available here. In short, the issue was a persistent XSS that could be used to redirect the user to a malicious website. Here’s the PoC attack string:
http://www.example.com/?foo=”><script>document.location=’http://10.11.1.225′;</script>
Safari, Mac OS X and Fraudulent SSL Certificates (Comodo)
Following the recent hacking of Comodo, a certificate authority that distributes SSL certificates, web users to the following domains are at a higher risk of phishing and sniffing attacks:
- login.live.com
- mail.google.com
- www.google.com
- login.yahoo.com
- login.skype.com
- addons.mozilla.org
Attackers were able to obtain SSL certificates for these domains, essentially allowing them to pose as those websites. The certificates have since been revoked by Comodo, however this relies on browsers checking for them by checking Comodo’s Certificate Revocation List (CRL) and having the Online Certificate Status Protocol (OCSP) enabled. Firefox and Chrome were updated last week to block the fraudulent certs, but Safari doesn’t do CRL and OCSP checking by default.
Hit the jump for how to enable these checks in OSX and Safari. Read more
Browser and Smartphone Exploits Fly at Pwn2Own [Recap]
With Google offering $20,000 for a Chrome sandbox exploit, Apple releasing fresh security updates, and the organisers allowing researchers to target mobile phone basebands, it was sure make for an interesting Pwn2Own contest at CanSecWest this year.
For the fifth year running, Pwn2Own invited security researchers to discover vulnerabilities and develop exploits for the most popular browsers on Mac OS X and Windows (for some reason Linux is left out this year). Traditionally IE, Firefox and Safari have gotten exploited, with Chrome being the last browser standing at last year’s competition. Google upped the ante by making it significantly more attractive to target their browser this year.
In short: Safari, Internet Explorer, iPhone and Blackberry were all successfully compromised. Chrome and Firefox survive. Hit the jump for the full details! Read more
Safari Errorjacking Vulnerability and Exploit [Patched]
One of the vulnerabilities patched in Safari 5.0.4 is a fairly critical issue in WebKit (CVE-2011-0167) that allows Javascript to jump into the local zone, and access any file on the local computer that is accessible to the current user. This could be used by malicious websites to extract files and information from the victim’s computer. The vulnerability affects Safari on Mac OS X and Windows, and could affect other WebKit-based browsers, although Chrome is safe due to added restrictions.
The bug exists because most browser error pages are loaded from the local “file:” zone, a zone that Javascript is not normally allowed to access directly. Since a child browser window remains under the control of the parent, it is possible to cause a child browser window to error, thus entering the normally-restricted local zone, and then instructing the child window to access local files using this elevated local-zone privilege.
This issue was a nice catch, discovered by Aaron Sigel who has a detailed explanation, video demo and proof-of-concept on his blog. It probably goes without saying, but Safari users should run Software Update as soon as possible.
Apple Drops iOS 4.3 and Safari 5.0.4 Security Updates Ahead of Pwn2Own Contest
In awesome day-before-just-to-try-and-screw-with-your-exploits style, Apple has released significant security patches for iOS, Safari and Apple TV. Safari, which is one of the targets at CanSecWest’s Pwn2Own contest where hackers come to demonstrate 0day exploits, has received an update to 5.0.4, and fixes over 62 bugs including major vulnerabilities in WebKit (eg. Errorjacking) and the ImageIO and libxml libraries.
iOS 4.3 patches largely the same issues in MobileSafari, as well as a remote code execution vulnerability in CoreGraphics. iOS is expected to get a lot of attention at Pwn2Own, with at least four researchers having developed exploits. Charlie Miller and Dionysus Blazakis (@dionthegod) have one exploit which doesn’t work on update, although allegedly the vulnerability hasn’t been patched yet.
Whether or not these updates thwart some of the exploits developed for Pwn2Own remains to be seen. It’ll be cool if it prevents at least one. Either way, good job to Apple for trying.
Update: Just found out that target iPhones at Pwn2Own won’t be running the latest iOS 4.3 which does indeed prevent a number of exploits. Here’s a recap of the Pwn2Own action.
Lastly, Apple TV has been updated to 4.2 to patch a couple not-so-critical vulnerabilities in libfreetype and libtiff that could allow code execution if a malicious image were opened.
Hi the jump for the long list of issues fixed in iOS 4.3. Read more
Researchers Extract iPhone Data and Passwords in Minutes
A group of German security researchers from the Fraunhofer Institute for Secure Information Technology have discovered a way of extracting personal information and stored credentials from a locked iPhone, by way of a jailbreak. By gaining physical access to an iPhone (or iPad/iTouch), an attacker is able to reboot it into recovery mode, thus allowing them to upload their own jailbroken firmware onto the device. As part of this process SSH is enabled and a script can then be uploaded to the device which uses built-in system calls to extract encrypted data (including credentials in the keychain) from the device. See the video below for a demo of their attack, which can take as little as six minutes.
This attack would not be possible without existing jailbreak mechanisms, which effectively bypass the iPhone’s sandbox and allow unsigned code to be executed. The second issue is the way that iOS handles stored data and credentials, allowing any application to request the information. This is actually a prime example of the dangers of having a jailbroken iPhone or iPad, as it makes it much easier for an attacker to execute malicious code on your device.
These kinds of issues are not isolated to iOS devices, and the same would exist on other devices that could be made to run custom scripts. This will be a tricky issue for Apple to resolve, as much of its security relies on a strong sandbox. Their best chance is to try to identify and patch as many of the vulnerabilities that could be used for a jailbreak. They will also need to review the way iOS handles encrypted data, and ensure that data cannot be extracted by arbitrary applications.
Luckily there is not yet a publicly available automated tool to perform this attack, so it is unlikely that a random thief will be obtaining your data. If you’re really worried, you can use Apple’s free Find My iPhone service to remotely wipe your iOS device should it be lost or stolen. Check out my article on protecting and recovering your iPhone from loss and theft for more information.
The team’s original research paper is available here (PDF).
Insecurity: Bad Secret Questions and Information Disclosure
It’s a little known fact that most websites have a backdoor that can get you access in other people’s accounts – weak secret questions! Ok, so maybe it’s not a back door as such, but the threat is so high that for some websites it might as well be. Let me explain… Read more
WordPress 3.0.4 Patches XSS Flaws in HTML Sanitation Library
WordPress have released an update (3.0.4), dubbed “the most important security release of the year”, that patches a core security bug in the HTML sanitation library (KSES). KSES is responsible for filtering user input and, as such, is used to protect WordPress sites from attacks such as Cross-Site Scripting (XSS). XSS vulnerabilities were discovered, however the details of these are not available (see below).
They rate this release “critical”, and so it’s recommended that all WordPress sites update as soon as possible. The full changeset for the 3.0.4 update is here. Security researchers are invited to review these changes to ensure the vulnerabilities have been fully fixed. Spread the news if you have any friends with a WordPress blog!
[Updated] One stored XSS exploit for 3.0.3 is available here.
Finding Security Bugs in Gawker Source Code
With the recent high-profile Gawker compromise, their entire source code and user database are available as a torrent. Some people have taken to cracking the (weak) password hashes, whilst others are looking for bugs in the source.
Mike Bailey has started Gawker Bug of the Day (@gawkerbugs), and will be disclosing security vulnerabilities in their source code… presumably for funsies.
GBOTD#1 is a XSS found in the first 3 lines of the first file:
http://gawker.com/at.js.php?country=%3Cimg%20src%3D.%20onerror%3Dalert%28document.cookie%29%20%3E
According to Mike, he’s already found over 30 bugs after just a few hours of hunting.
OpenBSD IPSec Possibly Probably Not Backdoored by FBI
In a post to the OpenBSD mailing list, developer Theo de Raadt reveals an email from an ex-contributor (Gregory Perry) alleging that money was accepted from the FBI around 2000-2001, in return for implementing a backdoor into the IPSec stack. Such a backdoor would give the FBI the ability to eavesdrop on any IPSec connection made using OpenBSD, or any other projects that have since made use of its IPSec code.
Clearly this would be a big deal if true, and although we know that open source projects are regularly backdoored by rogue developers or ‘hackers’ (such as the recent ProFTPd backdoor), it is not often that we hear of governments inserting some themselves. Should we be surprised? After all it is known that the NSA was involved with the development of DES by altering the algorithm’s S-Boxes and suggesting a shorter key length. There are also rumors of a covert backdoor in several versions of the Windows OS. That said, many people are smelling a troll in this case.
Following this information (can we call it a leak rumor?), OpenBSD’s IPSec code will undoubtedly come under quite a bit of scrutiny, and I’m sure we will hear a lot more about it should anything untoward be uncovered.
Read the full mailing list post here, archived below for posterity.
[Update] Scott Lowe denies being affiliated with the FBI, and Jason Wright denies having inserted a backdoor. This is sounding more and more like a trolling. To what end, I couldn’t speculate. It’s also worth noting that this kind of activity would probably not fall under a normal NDA, but under a government-level Top Secret classification which lasts at least 25 years…
An interesting observation about OpenBSD IPSec and Stuxnet. Read more
Loading ...
