I once again have the honor of helping to make B-sides Seattle a reality. It was a really successful event last year. For its second iteration, the con will be moving to the tech mecca of Redmond, Washington, just a few miles east of Seattle.
The CFP has just opened up. Are you going to be in the greater Seattle area on December 14th and have something you would like to present? Then submit your talk or workshop idea at http://t.co/TimwOGGYNi . The CFP will close on October 25th, so get moving!
As I’ll explain why shortly, I’m just getting around to posting this. In a previous blog entry, I mentioned the SANS Pen-testing blog’s Holiday 2011 challenge and attached my submission. It turns out I was selected as the winner for the “individual” category!
Unfortunately, due to the evils of spam filtering, I didn’t discover I had won until earlier this year. I contacted Ed, who was kind enough to send along my prize despite the late date. Thanks Ed!
I just did something that I still can’t quite believe. I got BackTrack 5 running on my Android phone (a Driod Incredible 2) and tablet (Nook Tablet). Not only that, I can’t believe how easy it was!
Although there is an ARM port of BackTrack (most Android devices use ARM processors), it probably won’t just boot up natively on your phone. But a couple of users on XDA-Developers came up with a convenient script to automate starting BackTrack 5 on Android in a chroot environment, and shrunk the BackTrack image file to make it small enough to fit on a FAT32 partition (the standard BackTrack ARM image is larger than the 4GB single-file limit). This allows BackTrack to run alongside the existing Android system, which I think is actually better than running BackTrack natively since you can still use your phone as a phone when you’re done with BackTrack.
I’m running Cyanogenmod 7 on both devices, and as far as I can tell, this should work as advertised for any CM7 installation that mounts the external SD card as /sdcard. If you aren’t running Cyanogenmod, or your SD card doesn’t mount as /sdcard, your milage may vary. First, a couple of caveats. You must:
*Have a proper busybox install
*Be able to “su” from the command line
Have a terminal program installed
*Have ext2 support (use “cat /proc/filesystems” at a superuser command
prompt – you should see ext2 listed)
Have a VNC viewer installed
Be connected to a WiFi network (BackTrack won’t see a cellular data
connection as a valid network device)
The items with stars above should come along for the ride by running Cyanogenmod 7. I had previously installed a terminal program (the cleverly named “Terminal Emulator”) and was connected to a WiFi network, so my prep time was about two minutes to find a VNC viewer (the equally well-named androidVNC).
The only hard part was getting the BackTrack 5 files. The original thread from XDA-Developers is here with additional background here. I was only able to get one of the mirror sites to work. If you can’t get any of the mirrors to work, try googling for the filename – BackTrack5forARM-MattsLifeBytesEditionv2.zip.
Once you have the file, decompress it to get the bt5 folder out. It should be about 3.25 gigs. Copy that to your SD card. Open your terminal and type the following:
Backtrack should start up and ask you if you want to start a VNC server. Once past that, you are at BackTrack’s command line. You can run command line tools (like Metasploit’s MSF Console) from here, or SSH to it from another system on the network. Even better than that, if you answered yes to the VNC server, you can use the VNC client on your phone or on another system to connect to the Gnome desktop session (address: 127.0.0.1, port: 5901, user and password are root – change the address as needed for external connections). It couldn’t be much more simple than that.
I finally gave in last week and bought a Nook Tablet. After spending all of 10 minutes checking out the stock interface, I rooted it using Snowball-mod. It strips the tablet down pretty close to the barebones Android system, and provides root-level access. Having the ability to ssh both from and to my mobile device is awesome. It makes me feel like I’m carrying a tiny Linux box around in my pocket (which is pretty accurate).
The folks over at XDA-Developers (where the Snowball-mod instructions are located) are pretty amazing. You should check out the site if you are interested in hacking on mobile devices.
Even with the stripped down Nook, I’ll be installing CyanogenMod as soon as it is available for the Nook Tab. I’ve been running it on my phones for a couple of years, and I’m quite happy with it.
If you missed it, Ed Skoudis and Tom Hessman put together a great network forensics challenge over at the SANS site complete with a .pcap file, .jpg file with interesting EXIF data, and a very funny backstory. The entry date has passed, but you can still download the data and make your own conclusions. I’ve attached the response I submitted so you can compare it to your own conclusions. Have fun!
I was up on the pfSense firewall site the other day. I was really intrigued by two features it offered. The first was the ability to run Snort directly on the firewall. The other was that it supported several embedded/small footprint platforms.
As an infosec professional, being able to run Snort at home without spinning up another machine seemed to have some obvious benefits. Running on an imbedded platform also drew me in, since my home firewall had been a home license of Astaro running on relatively loud, hot, and large standard PC hardware.
It seemed like pfSense was going to be a really neat system to check out, but there was one problem. The option to run on an embedded platform isn’t compatible with running Snort. Snort generates so much write activity that it will kill an embedded system’s flash card quite quickly, so the Snort package is disabled for the imbedded install.
I was all set for disappointment until I heard Carlos Perez mention on an episode of Pauldotcom Security Weekly that he was running the full non-embedded pfSense on an Alix board (embedded platform) by using a Microdrive (basically a hard drive that plugs in to a Compact Flash interface). With that glimmer of hope, I decided to order up the hardware and give it a shot myself. I’m happy to say that I my home firewall is now running the full non-embedded pfSense distribution on an embedded hardware platform. The better news (for you) is that I’ve decided to write up a little tutorial to help others do the same.
For hardware you will need a system board, a Microdrive, an enclosure and a power supply. I chose an Alix 2D13 for my system board. It has three ethernet interfaces and a miniPCI slot to add wifi. You can get this as a kit with an enclosure (in black, silver, red or blue), CF card (which will go unused in this tutorial) and power supply from Netgate for just under $200. The Netgate enclosure is very nice. I highly recommend them. This covers everything but the Microdrive.
For the Microdrive, you will need a CF-compatible Microdrive and a USB Compact Flash reader. This one is a little tougher. Many people are selling PATA/IDE Microdrives through eBay and other online outlets. The issue with those drives is that they use the physical layout of a CF card. Even though they will physically plug in to a CF slot, the data is being transmitted using PATA/IDE protocol. These drives are used in devices like iPods. Make sure the drive you get is a true CF. I ordered one from Amazon for about $30, but they are starting to get rare. As for the reader, if you don’t have one already, your local big box store probably has a 12-in-1 media reader for $15 that will work.
For software, download and burn the latest version 2.0 .iso of the i386 architecture from pfSense, currently named pfSense-2.0-RC3-i386-2011062101650.iso.gz. Ignore all of the nanobsd and memstick files, those are for embedded systems.
Now for the tricky bit, the installation. Plug your microdrive into your CF reader and make sure you can read it with your regular OS. Then insert the CD you burned, restart your computer and boot off of the pfSense CD. The pfSense CD is a combination live CD and installer. Make your way through the installer and install pfSense to whatever device is assigned to your Microdrive. In my case, it was device da1. I created a 500 Mb swap partition and allocated the rest to data. I wasn’t sure how much swap pfSense might need, so I pretty much guessed.
If you have an issue where pfSense won’t get past the interface assignment stage because you don’t have a separate interfaces for the LAN and WAN, tell it you want to set up VLANs and create two VLAN interfaces.
After completing the install, restart your system and boot back into pfSense off of the CD. This time, instead of choosing to install the system, choose the option to drop into a console. At this point, you will be at a standard *nix shell prompt.
The last step is to correct for the fact that the Alix system will assign a different device name to the Microdrive than your PC does. Create a temporary directory (I did “mkdir /tmp/mount”) and mount the data partition off of your Microdrive (“mount /dev/da1s1a /tmp/mount” for me). I used the /tmp directory because many directories are read-only because of running from the CD. Edit the fstab file from the Microdrive (“vi /tmp/mount/etc/fstab”) and change the device names to match the format of ad0s1a (that’s a zero after the d). Since I had a data and a swap partition that were listed as da1s1a and da1s1b in my fstab, I changed them to ad0s1a and ad0s1b.
Shut down the system, pull the Microdrive, install it into the Alix board, and apply power. If everything goes well, after about 20 seconds you should see the three LEDs on the front panel do their best Cylon imitation. Once that show is over, hook a PC up to the LAN port, assign an address in the 192.168.1.x range, and you should be able to pull up the web interface at 192.168.1.1.
I really wonder if RSA isn’t shooting themselves in the foot with their PR strategy surrounding the breach of their network. As far as I can tell, their plan is to blind everyone with useless (but possibly interesting) details while hoping that no one notices that they haven’t disclosed any information that anyone can actually use.
Let’s look at the information that went out initially. On March 17th, RSA sent a letter to SecurID customers, informing them that RSA had been hacked. However, the only information included other than the fact that the breach centered on the SecurID product was a list of recommendations that could have been written by a student going through a SANS 401 class:
- Enforce strong password policy
- Increase focus on social media security
- Re-educate employees
- Pay attention to your SIEM
- Harden and monitor critical systems
- Examine helpdesk practices for social engineering weaknesses
- Apply patches and updates
Oh…thanks. That really helps folks who are afraid their SecurID tokens now provide as much security as double-ROT13 encoding. Based on the lack of information to help evaluate the risk level, I’m sure many organizations have begun making plans to move away from SecureID (including one organization described by Allen Paller as “one of the largest US defense contractors”).
Maybe RSA will fix this with a follow-up announcement, letting everyone know that they have nothing to fear? They did release a second announcement (almost two weeks later), but I’m not sure it was any more helpful or reassuring than the first.
In a post titled “Anatomy of an Attack“, RSA laid out some of the technical details of the intrusion. The first stage is described in great detail. An attacker sent phishing emails containing a trojanized Excel file with an embedded Flash 0-day exploit. A user opened the file, allowing the attacker to install a copy of Poison Ivy in reverse connect mode.
This unfortunate user is described as being part of a group that was not high profile or high value. But later in the post, the attackers are described as needing more access and getting access to user, service and even domain admin accounts. Wait, how did the attacker go from compromising what sounds like a limited user on a workstation to having domain admin access? Apparently, “digital shoulder surfing.”
Again, we have lots of information we already know (attackers are sending phishing emails and users will launch them), and almost nothing about what we don’t know (how an attacker went from limited access on a limited system to owning the network).
It almost seems like RSA is trying to make the worst of a good situation with their misguided PR plan. They announce they’ve been hacked, but they don’t give any details about what their customer’s risk level is. They yell “APT!!!”, then talk about how the attacker used a well-known tool and common techniques, with no details about the true meat of the attack. They caught the attack in the middle of the operation, but they won’t say that they were able to curtail the attacker’s access from the most sensitive data. Maybe they can’t say more due to legal or other constraints, but at least they could let us know if that was the case.
And what’s with the now-popular use of “APT”, anyway? RSA caught the attack in the early stages, so it wasn’t exactly persistent. The attacker also used common tools and techniques, so not terribly advanced. The use of a Flash 0-day does elevate the attacker to somewhere above script-kiddie level, but Flash flaws are discovered about twice a week… so this isn’t exactly Stuxnet. Maybe there was something amazing in the technical details of the “digital shoulder surfing”, but at this point everything we’ve heard from RSA is “we got hacked by the best… but everything’s cool.”
RSA may be reaching out to SecurID customers directly to share more detailed information about this incident, but if I was in the market for two-factor authentication, I would be severely spooked. It’s funny, because I feel like RSA might have deserved a pat on the back. Their blog post states they caught the hack in progress, which deserve some kudos, even if they didn’t prevent the attack in the first place (prevention is ideal, but detection is a must). Maybe RSA is suffering from the tech geek’s Achilles heel: they have done some good technical work, but they’ve failed to put it into words for the customer/boss.