Pwn Plug Command Execution Using USB Sticks
This is something I’ve been meaning to do for a while, and whilst the title may not sound all that intuitive, it’s actually referring to something pretty simple. When I got my Pwnie Express Pwn Plugs, there were several times when I wished I could run commands on them when I couldn’t connect to them over SSH, for example when I couldn’t remember the last static IP I’d set. Yes, I could use the serial connection, but somehow that didn’t fully appeal to me.
So I came up with the idea of being able to use a USB stick to carry a command ‘payload’ that would get automatically executed upon being plugged into the Pwn Plug. Now I can run commands such as ifconfig, kick off an nmap scan, whatever I need; and all the results are output back onto the USB stick.
Note that I chose to do this on my Pwn Plug, but it should work equally well on other embedded devices such as the MiniPwner with a bit of tweaking.
Charlie Miller Discovers iOS Code-Signing Bypass Vulnerability
Security researcher Charlie Miller (@0xcharlie) has discovered a significant flaw in iOS which may allow a malicious app on the App Store to download and execute arbitrary unsigned code. What this means for iPhone, iPad and iPod Touch users is that installing a malicious app may allow an attacker to obtain shell access to your device, and download contacts or images.
Apple reviews every app submitted to the App Store, which has meant that iOS users have not had to worry about outright malware. Since this vulnerability allows the apps to fetch code remotely, they can perform actions not reviewed by the App Store staff. Charlie had submitted a proof-of-concept app that was approved (see video below), but has since been removed by Apple.
The reason this vulnerability works is based around some changes Apple made in iOS 4.3 last year, which allowed Mobile Safari to run javascript at a more privileged level on the devices. This change required Apple to make an exception for Safari to execute unsigned code in a particular area of memory. Charlie Miller’s bug is allegedly a very unique case that allows any app to take advantage of this, and hence run their own unsigned code.
Charlie will be presenting the vulnerability in detail at the SysCan conference in Taiwan next week. Apple has already released a developer beta of iOS 5.0.1 which patches the recent iPad Smart Cover lock screen bypass, but I would not be at all surprised if they release another beta which includes a fix for this bug. Until then, be careful to only install apps from developers you trust.
[Update] Apple has kicked Charlie out of the Developer program. At first I felt that this was an extremely bad reaction on Apple’s part. That said, Apple is probably most upset that Charlie’s proof-of-concept app could have been installed by legitimate users. Regardless of Charlie’s intentions, this could constitute malware, and he should have removed the app as soon as he saw the flaw existed. The posting of his video above probably didn’t help matters either.
iPad Lock Screen Bypass Vulnerability using Smart Cover [Patched]
Marc Gurman at 9to5Mac has discovered a vulnerability on the iPad that allows for a limited bypass of the device’s lockscreen. Anyone with an iPad Smart Cover (or fridge magnet) can gain access to the previously-open app (or the home screen if no app was open).
By holding the power button to bring up the ‘Power Off’ screen, closing the smart cover, re-opening it (or just sliding a fridge magnet along the right-hand side of the device), and clicking cancel, the attacker will be dropped into the screen that was open before the iPad was locked. If the attacker gets dropped into the home screen, then they’ll be able to see the installed apps, but won’t be able to open anything. If Safari or Mail (or any other app) was the open when the device was locked, then the attacker would have access to that app.
Unlike Siri being available from the lock screen, which is not a security flaw (an unintended behaviour), this one actually is; and although an attacker does not get full control of the iPad, the severity depends on whether a sensitive app was being used before the device was locked.
Luckily it is possible to protect yourself against this bug in the interim by disabling Smart Covers in Settings > General > iPad Cover Lock/Unlock > Off. Expect Apple to patch this in iOS 5.0.1. Check out 9to5’s video below for a demonstration:
[Update] Apple did indeed patch this bug in iOS 5.0.1. Those of you who disabled your Smart Covers for security purposes can now re-enable them!
Jailbreak iOS 4.3.3 with JailbreakMe 3.0
JailbreakMe.com has been updated to allow easy untethered jailbreak of your iOS devices, just follow the instructions on the site. Thanks to a new PDF exploit from comex (with the help of chpwn), it is now possible to jailbreak iPhones, iPads (including iPad 2) and iPod Touches running iOS 4.3.3 (note this doesn’t yet include any versions below that). During the jailbreak, saurik’s Cydia app store is automatically installed.
Interestingly, users with jailbroken devices can protect themselves by patching the PDF vulnerability by using ‘PDF Patcher 2’ in Cydia. Normal users will have to wait for iOS 4.3.4 from Apple. Note, however, that having a jailbroken iPhone or iPad still makes you slightly more vulnerable to other attacks, as the iOS sandbox is essentially bypassed.
Mac App Store Simple Copy Protection Security Bypassed
The Mac App Store was released in the recent 10.6.6 update, allowing Mac users to buy and install apps in the same, easy, one-click fashion as iPhone and iPod Touch users. Over 1 million apps were downloaded in the first 24 hours. Although the Mac App Store doesn’t make use of a sandbox like the iOS App Store does, there are still several mechanisms developers can use to prevent their software from being copied and shared between different users.
Hackers have discovered that one of the simpler methods used to authenticate an app is actually stored as a separate plist file within the application bundle. This means that an app can be copied, and the authentication files within its bundle can be replaced with those from an app that was legally purchased (even if it’s a free app).
In order to resolve this, developers should not rely solely on the data found within the plist file external to the binary, and perform some checks against hard-coded values within the binary itself. Some simple tips are available here. Ultimately all software is crackable, Mac App Store or not, so my suggestion to application developers is: spend more time developing great new features, and less time worrying about anti-piracy. This is what itself Apple does. In the long run most people will follow the simplicity route and buy the app.
In related news: How not to store passwords in iOS (developers take heed)
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.
Gawker Media Hacked and Accounts Compromised
Gawker Media, who run many other sites including Lifehacker, Gizmodo and io9, have had their servers and databases hacked by a group called Gnosis. This results in over 1.3 million user accounts being compromised, across their various websites. Part of the issue is the fact that Gawker were using the outdated DES algorithm to secure passwords in the database, making it trivial for the hackers to crack the hashes. To make matters worse, many Gawker admins have also been using extremely weak passwords for their accounts. A full account from the hackers’ perspective can be found here, and there is clearly some beef between them and Nick Denton (owner of Gawker) who appears to have been baiting 4chan (baad idea).
The 1.3 million user accounts, together with Gawker Media’s source code, have been made available in a torrent posted on The Pirate Bay. You can quickly check whether your account is one of those by checking out this spreadsheet (Google). It’s safe to say that if you have any accounts on websites run by Gawker Media, you’re going to want to change your password. If you happen to reuse passwords a lot, then you’ll want to change your password everywhere… isn’t password reuse a joy?
ProFTPD 1.3.3c Briefly Backdoored by Hackers
Servers of the widely popular FTP server, ProFTPD, were compromised (probably with 0day) on the 28th of November 2010. During the attack, some source code was modified to insert a backdoor. The source files affected were for ProFTPD version 1.3.3c., between the 28/11/2010 and 02/12/2010.
The backdoor introduced by the attackers allows unauthenticated users remote root access to systems which run the maliciously modified version of the ProFTPD daemon.
If you installed or updated ProFTPD from one of the official mirrors during that time, it is recommended that you recompile from a known good version of the code. The source modification was spotted and rectified on 01/12/2010. MD5 sums for the valid source tarballs:
8571bd78874b557e98480ed48e2df1d2 proftpd-1.3.3c.tar.bz2
4f2c554d6273b8145095837913ba9e5d proftpd-1.3.3c.tar.gz
Hit the jump for details on how the backdoor is triggered. A Metasploit module is available to automate the exploit. Read more
Compromising Disk Encryption Through Cold-boot Key Recovery
Note: This is a 2008 post I managed to recover from my archive of Securethoughts.net
A team of researchers at Princeton University have devised a way to compromise disk encryption mechanisms, and even other disk image encryption mechanisms, by recovering latent data such as encryption keys, that remain in RAM after a computer has been rebooted/turned off. They’ve tested their attacks against encryption mechanisms such as Microsoft’s BitLocker, TrueCrypt, Linux’s dm-crypt and Apple’s FileVault.
This technique is ingeniously simple, and they’ve written a tool from which they can boot a computer, and do a memory-dump of the latent memory data, which they then run through another utility which searches the memory dump for encryption keys, which can then be used to decrypt the encrypted drive/images.
With regards to Mac OS X 10.4 and 10.5, the group discovered that the system stores multiple copies of users’ login passwords in active memory, making them vulnerable to such imaging attacks. Those passwords are often used to protect the keychain, which stores many of users’ other passwords, including the FileVault password, and potentially other encrypted disk images. This is potentially something Apple should address, and they don’t really want to be storing passwords and keys in memory, if they don’t have to. Keeping as little sensitive data in active memory as possible would greatly reduce the chances of it being compromised in imaging attacks such as these.
Check out their great video below, and read more about it after the jump! Read more
Loading ...
