Skip to content

Posts from the ‘Security’ Category


Security Update 2011-005 Fixes DigiNotar SSL Vulnerability

Apple has finally issued Security Update 2011-005 to address the recent issues around compromised Dutch certificate authority DigiNotar. It was discovered that at least 531 fraudulent SSL certificates were issued by DigiNotar, leading to their root certificate being revoked in all major operating systems and browsers over the past two weeks. A man-in-the-middle attacker in possession of one of these certs (eg. Google, Skype), would be able to intercept SSL-encrypted traffic to those sites. It is believed that the use of these fraudulent certs may have been limited to the Iranian government.

This patch removes the DigiNotar CA from the trusted root certificates in the Mac OS X keychain (which is also used by Safari) for Lion and Snow Leopard. Unfortunately no patch has been issued for Leopard (10.5) users, leaving them at a heightened risk from these bad certificates. It is recommended that Leopard users delete the DigiNotar CA certificate from the Keychain using the following steps:

  1. Open Keychain Access (/Applications/Utilities/Keychain Access)
  2. Click on the System Roots keychain in the top-left hand panel
  3. Click on Certificates in the bottom-left hand panel
  4. Type DigiNotar into the search field in the top right.
  5. Right-click on the DigiNotar Root CA, and select Delete.
For sysadmins, the following Terminal command achieves the same thing:
# sudo /usr/bin/security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain

Firefox users should update to the latest version of Firefox. Here is the full Apple description for this update:

Security Update 2011-005

  • Certificate Trust Policy Available for: Mac OS X v10.6.8, Mac OS X Server v10.6.8, OS X Lion v10.7.1, Lion Server v10.7.1Impact: An attacker with a privileged network position may intercept user credentials or other sensitive information

    Description: Fraudulent certificates were issued by multiple certificate authorities operated by DigiNotar. This issue is addressed by removing DigiNotar from the list of trusted root certificates, from the list of Extended Validation (EV) certificate authorities, and by configuring default system trust settings so that DigiNotar’s certificates, including those issued by other authorities, are not trusted.


Reverse SSH over Tor on the Pwnie Express

The Pwnie Express (PwnPlug) is a great little tool for hackers, pentesters and social engineers alike. While I don’t advocate the use of a Pwnie for illicit purposes, I was intrigued about using it as an untraceable tap into a network. Out of the box the Pwnie allows you to configure reverse SSH connections, exfiltrated over a number of different protocols including HTTP, SSL, ICMP and DNS.

While these are great for getting out of controlled networks, they all require the Pwnie to be configured with the IP address of your SSH server, which could potentially be traced back to you. It also requires your SSH server to be able to directly receive connections at the IP/hostname configured on the Pwnie. While one could run an SSH server on a proxy box somewhere, I felt that was too primitive, so I installed Tor on my Pwnie and configured a Tor Hidden Service on my SSH server.

Note: For the purposes of this tutorial, the SSH server will be running on BackTrack 5. I’m assuming you’ve already performed the initial Pwnie Express setup steps on the server! Check out my PwnieScripts to help speed up and automate the Pwnie setup.

These instructions do not yet work on Pwn Plug software >= 1.1 as they’ve changed the layout of things! Will update this post when I get the time.

Read moreRead more


PwnieScripts for Pwnie Express

The Pwnie Express (PwnPlug) is a purpose-built penetration testing device in a plug form factor. A key feature is its ability to exfiltrate from a network and connect back to your SSH server using HTTP, SSL, ICMP or DNS tunnels. Check out my tutorial on how to hack your Pwnie to make untraceable reverse SSH connections over Tor.

There are a number of steps required to set up the computer on which the Pwnie’s reverse SSH connections will be received (setting up the listeners). To simplify and automate this process, I’ve put them together into a set of very simple bash scripts. I’m hoping to turn two of these into a proper init.d script, but haven’t yet had the time. The PwnieScripts set contains the following five bash scripts, and are designed to be used on BackTrack 5 (although they can easily be adapted to work on any other distro):

  • Automates the Pwnie Express setup process by enabling SSHD, generating SSH keys, creating a ‘pwnplug’ user, installing HTTPTunnel, generating an SSL certificate, configuring stunnel, and configuring DNS2TCP.
  • Kills any existing listeners, and then starts SSHD as well as new HTTPTunnel, stunnel (SSL tunnel), DNS2TCP (DNS tunnel) and ptunnel (ICMP tunnel) listeners.
  • One-line script to monitor netstat for incoming connections from Pwnie Express.
  • aka. the Lazy Script – initiates an SSH connection to the first available established connection from Pwnie Express, so you don’t have to check which ones are active. It’ll use the more secure/relible ones first (SSL, HTTP) where available. Use the -t flag to only connect over Tor.
  • Kills all existing HTTPTunnel, stunnel, DNS2TCP and ptunnel listener processses.

Download PwnieScripts (tgz 4kb)

Any feedback or tweaks are welcome. Leave a comment below, send me an email, or message me on Twitter.


v0.1: Initial release.

Sep Compromised, OpenSSH Source Not Backdoored, the primary site for the Linux kernel source, was compromised sometime in August. It is believed that the attackers gained access using compromised user credentials, and then escalated their privileges to root. Early pieces of information implied that some OpenSSH source code was stored on the compromised server(s), apparently this may not be the case. So far the investigation has found that several modifications were made to the compiled OpenSSH client and server binaries running on the system to log user activity. The full extent of the changes is not yet known, and nobody has yet come forward to claim this hack.

If you’ve installed or updated your kernel or OpenSSH recently, you may want to reinstall from a known good version, although it is not yet known if any kernel sources were modified. Although in this case OpenSSH wasn’t compromised, admins can consider running some form of Single Packet Authorization, such as fwknop, as an additional layer of protection for your SSH server against these kinds of issues (backdoors) and other potential future 0days.

Hopefully more info will come to light as the investigation progresses. Hit the jump for more details.

Read moreRead more


Lion + LDAP = Authentication Bypass

Around a month ago, Mac OS X Lion (10.7) was found to have a fairly severe vulnerability when configured to use an LDAP server for authentication. In such a configuration, the system accepts any username or password upon login. This affects both the user interface, but also remote login such as SSH. This issue does not affect normal Lion users who haven’t set up an LDAP server.

Details of the issue aren’t well known, and as much as I’d like to reproduce the issue, I’m too lazy to set up an LDAP server to do it. My guess is that OSX queries the LDAP server, but a bug in the authentication and authorization code makes it so that the user is granted access regardless of whether a login failure is received from the server. I’ve heard reports that it’s possible to login using any non-existent username (with some errors about invalid home directories), but then it begs the question: who do you end up logged in as, and what privileges do you have? If you login with a known username, then you get access in the context of that user. I can’t say for certain, but this vulnerability should not allow a user using an invalid password to gain access to network resources that rely on that user’s authentication credentials, just the local system.

Apple hasn’t yet acknowledged the issue as far as I know, and it’s surprising that no patch was issued with 10.7.1. Perhaps a fix will come in the form of a security update, or the upcoming 10.7.2 update. In the meantime, consider disabling LDAP authentication on Lion systems to prevent unauthorised access.


Safekeeper Hotel Safe Bypass Video

I spent a week in Hawaii on the way back from Blackhat and Defcon in Las Vegas, and my hotel room had a Safekeeper key-lock safe that you had to pay $5 a day to use. Turns out the safe was perfectly usable without the key – which I guess nullifies the safe’s entire purpose. Although it had a Medeco lock, the lock wasn’t really necessary, I used a paperclip as my ‘key’. There must have been something really wrong with the way the plug was installed, I’d be horrified if this ‘attack’ worked on all of these safes. Unfortunately I only had the one in my room to play with.

Check out my demo video below for some facepalm-worthy safe bypass action!

[Updated] A guy called Brad found that his electronic hotel safe could be opened using an all-zero passcode.


Advisory: NAB Credit Card Envelope Information Disclosure Vulnerability

I recently ordered some new credit cards, two sets of two (makin’ it rain baby), and they arrived in the post today in two separate envelopes. National Australia Bank (NAB) send out their cards in unmarked white envelopes, which is good, what’s not so good is that the embossed number on the card gets permanently imprinted into the plastic window of the envelope – presumably due to the pressure of having other envelopes on top of it. As a result, with the right lighting, I was able to read the full card number before I even opened the envelope (blurry snapshot below). It’s probably worth noting that the number will still be legible after the recipient has disposed of the envelope in the trash.

One can argue that having just the card number on its own is not as useful. But remember you’re holding an addressed envelope, so you have the cardholder’s name and address, including post code. You also know the start date on the card, which will almost always be the current month (sometimes the following month), and due to the fact that most credit cards have a lifespan of three years, you can also deduce the year of expiry. The month of expiry may or may not be the same as the start month. The only thing missing is the CVV, but then again there are still plenty of places that don’t require those. With just the card number, an attacker could clone it onto a fake credit card, and start using it in shops with any random signature.

Although this post is intended to be tongue-in-cheek, it probably wouldn’t hurt for NAB (or their card printing company) to fix this ‘vulnerability’. What would PCI say? :D


Grabbing OSX Passwords Through FireWire

There was a lot of attention given to yesterday’s news of Passware Kit Forensic v11 being able to extract your Lion login password if your computer was locked or sleeping, even with FileVault turned on. It’s worth pointing out that not only is this old news (from 2006), it isn’t even a vulnerability specific to Mac OS X, but rather a vulnerability introduced on computers with FireWire (or iLink) ports. The FireWire specification provides external devices with the interesting ability to interact directly with system memory (without going through the OS). While in theory this could open up interesting uses, in reality it just enables vulnerabilies due to the fact that a computer’s live memory can be used to extract data or manipulate parameters. Windows systems are vulnerable to this attack too, and there are tools (eg. winlockpwn) that exist that allow an attacker to unlock a locked Windows machine, or dump its memory, just by plugging into it via FireWire/iLink.

This flaw definitely has security and privacy implications, but only if the attacker is able to get physical access to your computer. As I’ve pointed out on a number of occasions, if someone gets phsysical access to your computer, it’s game over. Even without a FireWire port, techniques such as the Cold Boot Attack may allow an attacker to recover passwords or decryption keys from live memory. Until Apple completely phases out FireWire in favour of Thunderbolt,  this will continue to be an issue to be aware of. Thunderbolt itself, although not fully tested, may yet be found to have some similar issues; although I’m hoping Apple/Intel will have learnt from past mistakes.

There’s not a huge amount you can do to protect yourself apart from:

  1. Disable automatic login, and shut down your computer when you don’t plan on using it (especially if you’re going to be away from it for a while). Note that for this to really be effective, you’ll need to enable FileVault as well – otherwise the attacker will be able to access your unencrypted HD.
  2. Block your FireWire port with epoxy – or destroy it altogether.

Key iOS Security Updates Patch PDF and Certificate Validation Vulnerabilities (4.3.4 and 4.3.5)

The two latest iOS updates are fairly significant in that they patch two critical vulnerabilities. iOS update 4.3.4 patched a number of bugs including comex’s PDF/FreeType vulnerability used to create the latest JailbreakMe exploit. If you’re a jailbreaker, it’s essential that you run comex’s ‘PDF Patcher 2’ within Cydia, in order to patch the underlying vulnerability. iOS update 4.3.5 released a couple days ago, patches a fairly significant bug in the way iOS validates SSL/TLS certificates. This vulnerability can allow an attacker to intercept and/or modify data protected within an SSL session without the user knowing it. This was possible to due the fact that iOS didn’t validate the basicContstrains parameter of SSL certificates in the chain.

If you’re only an occasional patcher – now is the time.


OS X Lion Released, Brings Improved Security

As you will know by now, Apple has release Lion (OSX 10.7) to the orgasmic jubilation of Mac fans everywhere. Ok, perhaps I exaggerate, but Lion was probably the most anticipated release of OSX since Leopard. Critics will argue that the number of major new features are limited, but in my opinion it’s the refinements that make Lion a great update. And for what it’s worth, the Mac App Store update process went perfectly smoothly on my iMac.

Most importantly, however, are the security improvements that Apple have made to the OS. Leopard and Snow Leopard already had some of these features, but they were not fully developed. In Lion, it seems, many of those issues have been fixed. In fact Lion has been said by several security researchers to now offer superior security over competing operating systems. I’ve said for a while that Apple will wait until OSX is really stable before properly addressing security. It appears Lion is the start.

I’ll start off with the most user-visible security features:

  1. FileVault 2: Whereas FileVault on Snow Leopard only encrypted users’ home folders (using disk images), leaving the System and Applications vulnerable to attack, Lion now has true block-level Full Disk Encryption (XTS-AES 128 algorithm). FileVault 2 also supports full disk encryption of external USB and FireWire drives. One key new feature is Lion’s “Instant Wipe”, which will allow you to wipe the hard-drive should your computer fall into the wrong hands. Similar to iOS devices, this may tie in to the new Find My Mac functionality.
  2. Privacy Controls: Apple has sprinkled around some additional privacy controls, giving the user more say in how their data is stored or used. There’s now full control of which applications can make use of the Location Services features of OSX.
  3. Apple ID Authentication: This is an interesting feature that makes it easier for users to share content with others. Normally actions like Screen Sharing and File Sharing require the connecting user to have an account on the system. Now, you can simply add their Apple ID as an authorised account to give them selective access. It will be interesting to test how this actually works in practice.
  4. Application Sandboxing: Lion’s sandboxing capability has been greatly improved. Safari, for example, has been updated to include sandboxing, meaning that website content loads in a separate process with limited functionality. This help prevent malicious websites from gaining access to the underlying system. Apple is encouraging third party software developers to start sandboxing their applications.
  5. Full ASLR: This is a big one. Address Space Layout Randomization is a technique to make exploitation of vulnerabilities more difficult by not using fixed memory addresses for key data areas. In Snow Leopard, ASLR was half-baked and essentially broken. In Lion, it appears that Apple have finally implemented full ASLR (covering 32 and 64-bit application), although how well is yet to be fully determined. Either way this will present an additional barrier to exploits.
All in all, some significant improvements over Snow Leopard. The security push isn’t over yet, however, and I’m sure we’ll be seeing a bit more from Apple as OSX develops. This doesn’t mean vulnerabilities won’t be found in OSX, but it will make it that much harder for workable exploits to be developed. I anticipate we’ll start seeing a lot more vulndev attention being committed to OSX this year.