Skip to content

Posts from the ‘Hacking’ Category

4
Apr

Hi, I’m a Pen(etration) Tester!

The first thing people think when you tell them you’re a Penetration Tester:

censored

 

 

 

 

 

 

 

 

 

What people think when you tell them you’re a Pen Tester:

pentesting

 

 

 

 

 

 

 

 

 

 

Protip: Go with the first one.

 

3
Jul

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.

Read moreRead more

8
Nov

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.

20
Sep

Extracting and Cracking Mac OS X Lion Password Hashes [Updated]

The Defence in Depth blog has a post about a flaw in Lion’s redesigned authentication mechanisms and Directory Services. In short, it is possible to change the password of the currently logged in user by simply running the following command in the terminal, and it won’t ask you for the user’s current password:

$ dscl localhost -passwd /Search/Users/<username>

In Lion it is also easy to dump a user’s SHA-512 password hash using the following command:

$ dscl localhost -read /Search/Users/<username>

Then look for the dsAttrTypeNative:ShadowHashData chunk in the output (sample below). The hex string in red is the salt, and the green is the hash.

62706c69 73743030 d101025d 53414c54 45442d53 48413531 324f1044 74911f72 3bd2f66a 3255e0af 4b85c639 776d510b 63f0b939 c432ab6e 082286c4 7586f19b 4e2f3aab 74229ae1 24ccb11e 916a7a1c 9b29c64b d6b0fd6c bd22e7b1 f0ba1673 080b1900 00000000 00010100 00000000 00000300 00000000 00000000 00000000 000060

Cracking password hashes can be done using his custom Python script, or John the Ripper (with the Jumbo patch). Note that even if someone manages to obtain your password hash, if you’re using a strong password it will be extremely difficult for them to recover it. Seems like both of these are important but fairly low-risk flaws introduced into Lion. Hopefully Apple will look into these for the  next update.

[Update 1] While waiting for an Apple-supplied security update, it is possible to protect yourself from this vulnerability by adjusting the permissions on dscl:

sudo chmod go-x /usr/bin/dscl

This makes it so that only root can execute dscl. To revert this simply run:

sudo chmod go+x /usr/bin/dscl

[Update 2] This vulnerability was patched in Mac OS X 10.7.2.

8
Sep

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

8
Sep

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):

  • pwnsetup.sh: 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.
  • pwnstart.sh: Kills any existing listeners, and then starts SSHD as well as new HTTPTunnel, stunnel (SSL tunnel), DNS2TCP (DNS tunnel) and ptunnel (ICMP tunnel) listeners.
  • pwnwatch.sh: One-line script to monitor netstat for incoming connections from Pwnie Express.
  • pwnconnect.sh: 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.
  • pwnstop.sh: 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.

[Changelog]

v0.1: Initial release.

1
Sep

Kernel.org Compromised, OpenSSH Source Not Backdoored

Kernel.org, 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 Kernel.org 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

27
Jul

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.
8
Jul

Mac OS X “Lion” and the Dangers of Restoring from a Partition

With the release of Mac OS X 10.7 “Lion”, Apple is changing the way we’ll be doing system upgrades. Lion will only be available to Snow Leopard users electronically through the Mac App Store, and thus it will no longer be possible to purchase a physical install DVD. Before I go into the intended topic of this post, allow me to <rant> about how I’m not too keen on this decision. As a result, it’s no longer possible to install OSX on Macs that don’t have an internet connection (yes, these do exist!). Even for those who do, many don’t have very fast internet connections, or may have extremely low usage caps. I know that UK internet providers still offer entry-level packages 5Mbit lines and stupidly low 1-5 GB monthly limits. Lion is likely to be about 4GBs in size. Oh, you want to install OSX on more than one Mac? Suuure, just download the 4GB install package on each Mac.</rant> You get the point…

The real thing I wanted to talk about is Apple’s solution to system re-installation or recovery, and specifically the security implications thereof. Installing Lion will cause it to create a small ‘recovery’ partition on your primary drive, which is essentially a partition equivalent of an install DVD. If you have a problem with your main OSX partition, and need to run repair utilities or reinstall, you just boot from the recovery partition. Sounds really useful actually, as you don’t need to worry about having a DVD handy. But where this solution brings ease-of-use and convenience, it also brings some security risks.

Although Mac OS X is still largely unaffected by malware, the winds of change are indeed upon us, and it’s unrealistic to assume the Mac will remain virus-free forever. As viruses get more complex they find ever-improving ways of making themselves persistent on a system. There are countless examples of Master Boot Record viruses on Windows where the only sure-fire solution is to completely wipe the hard drive and reinstall from CD/DVD. Because once your system is infected, good security practice forces you to assume that any file or executable is compromised. So, how does this affect a bootable recovery partition? If I were a virus writer, I’d make pretty darn sure that I infect a core installer file on the recovery partition so that any  installation will have my virus. The nice thing about DVDs is that even if you insert them into an infected computer, they can’t be changed, and so you have complete confidence (barring a very advanced/rare firmware virus) that wiping and reinstalling from DVD yields a fresh and clean install of your system. As a security professional, I don’t think I’ll be able to trust a recovery partition like that.

But wait, there’s more. Viruses are a concern, but if you’re a smart user they’re not really a problem. We can run anti-virus, disable Flash, Java and Javascript, etc, and as long as you browse safely and don’t open random executables you’ll be perfectly fine. What about an attacker with remote or physical access to your computer? If I remotely hack into someone’s Mac, either due to a vulnerability or a weak password, all I have to do is modify a few files in the existing system and the recovery partition, and boom, persistent back door! The user can reinstall OSX all they want… my back door will simply be reinstalled with it.

But wait, there’s more. Even if your computer is completely secure from remote attacks, the same goes for someone with physical access to your Mac. Now, as a disclaimer, I have to point out that anytime an attacker gets physical access to any computer it’s game over. Even if you use FileVault, I may not be able to log in to your computer (unless some kind of cold boot attack is still possible), but I can easily boot your computer from a USB stick (or remove your hard drive if you have a Firmware password), trojan your recovery partition and corrupt your primary boot partition (similar to an Evil Maid attack). What are you going to do? Reinstall Mac OS X from my trojaned recovery partition of course! It’s not like you have a choice.

Any system compromise can lead to the installation of a persistent backdoor for the lifetime of the recovery partition on that hard drive. I don’t want to sound overly critical; I am probably one of the most fervent Apple supporters you’ll ever meet (with good reasons too), but not to the extent it stops me from thinking about potential impacts. I appreciate that Apple is trying to make things easier for Joe User. Being able to download updates electronically is awesome, and I honestly believe many would take advantage of that (myself included), but users should be given the choice. Particularly in situations like this where not having a physical install medium can have an impact on both usability and security.

My guess (or maybe hope) is that if Apple is not going to sell install DVDs itself, we may be allowed to burn our own install DVDs after downloading Lion from the Mac App Store. Either way, it is fairly trivial to burn the Lion installer onto a DVD – but users shouldn’t have to (or sometimes can’t) resort to a hack like that. Take heed, Apple.

[Update 21/07/11] Ok, so Apple isn’t going to allow users to burn their own DVDs, but they have confirmed that Lion will be available on a mini USB drive in August (for $69).

css.php