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.
The guys at GPGTools have taken control of the MacGPG2, GPGMail, GPG Keychain Access and GPG Services projects, and have released a single unified installer that installs all of these apps. They are maintaining these tools, which are all 64-bit and Snow Leopard compatible. The package also include Enigmail, a GPG-compatible plugin for Thunderbird (Mozilla’s free email client).
For more information, check out my tutorial on using GPGMail to send encrypted emails on Mac OS X.
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…
Ever since the release of the IronKey I’ve been drooling over the device (good thing it’s waterproof I guess). Due to not wanting to pay so much for a USB key, I decided to make my own. I grabbed myself a 32GB USB key, and got to work on making it as close to the IronKey as possible.
When Snow Leopard came around, it completely broke support for GPGMail, and there were no other solutions that enabled similar functionality. This caused a significant issue for Snow Leopard users needing GPG functionality. The original developer of GPGMail unfortunately did not have the time to update the plugin and restore support for Snow Leopard.
Since then the GPGMail project has been handed over to a new team of developers who have been working on restoring the full functionality of the plugin under 10.6. This tutorial shows you how to easily install GPGMail and start sending and receiving encrypted emails!
[Updated 21/01/2011] The team at GPGTools have now created a unified installer which consolidates MacGPG2, GPG Keychain Access, GPGMail and GPG Service. Their all-in-one installer simplifies the install process, and installs everything you need for encrypting/signing files and emails.
If you’ve used the GPGTools package, please post your experiences in the comments!
Current supported hash algorithms are MD5, SHA-1, SHA-256 and SHA-512.
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!
This research was performed by J. Alex Halderman , Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten. A combined team from Princeton, the Electronic Frontier Foundation (EFF), and Wind River Systems (specialists in decide software optimisation).
Although their paper focuses on recovering encryption keys, naturally this technique can be applied to any other sensitive information that may be stored in RAM at the time. They’ve also used data reconstructions algorithms to recover data that has already decayed from RAM. According to their paper, keys with 10% of bits decayed can be reconstructed to nearly any 128-bit AES key within a few seconds. On average, they found that memory was legible for up to 20 seconds on some hardware, but this number could extend into several minutes. By drastically reducing the temperature of the memory modules, they were able to reliably recover data up to 10 minutes after removing the RAM chip. Particularly interesting is their research with ECC memory, where they found that machines that support ECC memory tended to wipe RAM upon boot, which is done to avoid errors in the case of uninitialised reads of the memory. Unfortunately this is a characteristic of ECC-enabled machines, and not the memory modules themselves, meaning that ECC memory inserted into non-ECC hardware was still recoverable.
The software developed by the team, presumably with the particular help of Wind River Systems, allowed them to recover the memory dumps in several ways including: over a PXE network boot, which would send the data in UDP packets over the network; using a USB drive to run a small memory-dumping program; or using an EFI bootloader, such as those used on Intel Macs, which also allowed data transfer over netboot.
I highly recommend their paper, particularly the first and last thirds of it, as they are quite legibly written (the middle is mainly about recovering different encryption algorithm keys). It will be interesting to see what kind of innovation will come about in attempts to defend against such attacks. No doubt we will be seeing some papers on that subject soon.