Where Have We Been?

Posted by Jon Janego on April 15, 2009 1 comment

Wow, it’s been over a month without much action here at Securism.  But it’s not for lack of stuff to talk about – precisely the opposite, we’ve all been so incredibly busy that this little blog has fallen by the wayside.  But I promise that we’ll get right back up at it!  In the meantime, here’s what we’ve all been doing.

Ben and I both attended the SANS 2009 conference in early March, in Orlando.  He was in the advanced penetration testing class, and I was taking the wireless security class.  Verdict on both of those: AWESOME.

Walter also went to a SANS conference in Phoenix to attend a class on secure network design.

I also just finished the EC-Council Certified Ethical Hacker program, which is a good overview certification class.  Don’t underestimate that exam – it’s a tricky one!

Beyond the gobs of training, we’ve also been working on some great stuff at work, getting well up to our necks in the world of PCI.

So, dear readers, don’t fret.  We’re still here, and will be back shortly!

Putting Together a Wireless Security Toolkit for the Android OS

Posted by Jon Janego on February 25, 2009 1 comment

I’ve had the first commercially available Android mobile phone, the T-Mobile G1, since the platform launched last fall, and have been really happy with it so far.  As the platform is getting more mature, we are now starting to see a lot of new and useful applications out there – especially some useful for security!  Here’s a quick rundown of some of the tools that I’ve found and am using:

WifiScan – a great wireless discovery application for the platform.  It’s a powerful wireless audit tool that will log all of the discovered networks in range, and plot them to a KML file for visualization in Google Earth.  This application records information such as BSSID, Channel, Security Type, SSID, etc.  Tremendously useful for a discrete wireless network audit!

PortScandroid – a very basic port scanning application for the platform.  It’s not terribly useful for use over the cellular data network due to the filtering applied by T-Mobile, but when using 802.11, it gets the job done.  Doesn’t do any correlation of services to ports, but it performs the basic functions.

ConnectBot – this is a full-functioned SSH client for the platform.  Handy.

androidVNC – a VNC viewer for the Android platform that’s been forked from the tightVNC viewer development project.  Also a handy tool.  This is still in the beta phases and hasn’t been added to the Market yet, but it’s downloadable from the project page.  Easiest way to install it is to navigate to the project page within the phone’s browser and just download the APK package.

I am going to conduct a WarDriving contest between my little Android and a full-fledged laptop running Kismet and an external Wifi antenna to see how the signal discovery compares, but initial tests show the G1 to have a pretty remarkable Wifi range.  I’ll post a followup after I conduct the test.

The Android platform is showing a lot of promise, and for use on a pen-test, these tools could prove to be useful additions to your arsenal – and are certainly more discrete than using a laptop with a big ol’ antenna!

Thanks syn for inspiring me to investigate this – his post about the iPhone wireless toolkit made me wish we had these tools on the Android, and lo-and-behold – we do!

Responsible Home Wi-Fi

Posted by Jon Janego on January 28, 2009 3 comments

Wi-Fi.  Everyone’s got it nowadays.  Your Comcast or Verizon broadband connection at home probably comes with a wireless router.  But do you really know how to set it up??  Better yet – do you really know how yours is set up currently?  Or does it “just work”?

I want to briefly share my thoughts on the subject and give you some advice on making a secure – or perhaps intentionally insecure – wireless network at home.

Let me explain some fundamentals.  The first thing that you need to keep in mind is that all wireless traffic is visible to everybody.  Your XBOX live session.  Your online banking from your laptop.  Your IM sessions.  It’s all out there, just waiting to be listened in on, on a very well-defined and well-understood protocol, 802.11.

Before you panic, you need to remember the second important thing – nearly all wireless traffic can be well-protected.  Walter has been doing a nice series on encryption, and even if you don’t follow all the details, the major takeaway can be that data can be wrapped up pretty tightly if you set it up correctly.

For most people, I am going to advocate running a closed network – encrypting your traffic and only allowing authorized users to use your home access point (AP).  This is the subject of some debate among the security community, most notably from Bruce Schneier (who advocates for keeping your wireless network open), but I’ll say that for the “average user” it’s better to close it off.

Your network can be secured through a combination of obscurity, exclusions, and encryption.  Obscurity is not openly advertising the name of the AP.  Exclusions are preventing unauthorized network cards from joining your network.  Encryption is wrapping the traffic in a difficult-to-break code that can only be understood by your wireless devices and your wireless router.  The first two methods are relatively trivial to subvert – any ‘serious’ attacker could get themselves onto your network if they were the only two barriers to entry.  But the third is the most important, and here your choice is pretty clear – definitely encrypt!

But which encryption and authentication method to choose?  Home APs commonly come with a couple varieties of encryption options – WEP, WPA-PSK, and WPA2-PSK.  WEP has had known vulnerabilities since almost its inception, and is now easily broken in less than 10 minutes of work.  So don’t use it. Use WPA or WPA2, although WPA2 is relatively new and supported by less devices than WPA.

PortForward.com has an excellent guide to the details of setting up security on many wireless routers.  I would personally recommend against masking the SSID (the “name” of the wireless network) and implementing MAC address filtering, just because they’re easily compromised anyways, and make the network a hassle to administer.  The slight tradeoff in security is worth it for the increased usability.  As long as you’re using WPA or WPA2 with a relatively long pre-shared key – at least 15 characters – you’re better off than many networks.

Finally, if you choose to run an “open network” – a network that freely allows any client to associate with it, with no encryption – there are a few ways to still be safe.  First, keep in mind, that while the wireless traffic may be easily ‘sniffed’, if the data itself has already been encrypted via SSL (look for the ‘lock’ icon displayed in your browser) or a VPN tunnel, it’s a moot point – it’ll be garbage to an attacker.  So even though I menacingly mentioned that your bank traffic is visible earlier in this post – it’s only visible as encrypted gobbledygook, so no reason to panic just yet.

Summary – use WPA or WPA2.  Don’t bother with MAC filtering or SSID masking.  Don’t use WEP unless you really have to.  And you probably don’t want to run a wide-open network, but if you do so, don’t panic too much – most ‘important’ traffic is probably encrypted anyways.

In another post I’ll go into some ideas for running a secure, yet open home wireless network.  But until then, keep my simple recommendations in mind and you’ll be just fine!

PGP Followup

Posted by Jon Janego on January 22, 2009 No comments

I wanted to write a quick follow-up on my post last week about the issues that I had with recovering my PGP-encrypted hard disk.

I was contacted by Nathan Liddle, one of the senior support engineers from PGP and we spoke about my experiences.  I was first off, very impressed to see PGP proactively addressing concerns by contacting me here and it was great to be able to share my feedback.

Nathan graciously listened to my story and got the takeaway of that PGP is going to try and improve their recovery disk tools, to hopefully take some of the guesswork out of the process that I had to go through.  They appreciate that I was a pretty ‘techie’ person and was able to figure it out myself, but the average user of PGP WDE may not be able to do so, and that their tools could use some improvement.

So, I’m extending a shoutout to PGP for listening to customer feedback!  Thanks!!

With Great Power, Comes Great Responsibility

Posted by Jon Janego on January 19, 2009 No comments

Last week’s SANS newsletter caught my eye for an interesting story mentioned in it – “Wireless Hacking Braggarts Avoid Jail Time”.  It links to a story in the Cleveland Plain Dealer about two security consultants who were caught in a FBI sting for wirelessly stealing data from a fake defense contractor.

These two fellows were approached with a great offer – $100,000(!) – to grab some files wirelessly and discreetly.  The FBI got the idea of approaching them after they mentioned in an article in Crain’s Cleveland Business that they had broken into several networks wirelessly, and that companies should hire them to protect their networks.  Whoops!

This brings up a tricky question about infosec in general – in a business environment that is only slowly becoming aware to the issue of security, how does one generate new business?  It can seem tempting to ‘demonstrate’ the cost of bad security to a client – and cold-calling a business with information about their vulnerabilities is a sure way to wreck that relationship.  The responsibilities of a security professional are to clearly communicate the importance of a strong security posture and to let that information speak for itself.

These two guys took the exactly wrong approach to selling computer security – becoming the ‘bad guys’ that they’re supposed to be protecting clients against!  In the security field, more than many others, the line between ‘good guy’ and ‘bad guy’ can be blurry.  An infosec professional who is only using commercial tools isn’t really getting in the head of a ‘bad guy’ – because the bad guys are using open source tools, not the expensive Foundstone package.  We’ve got to get in the minds of the threats in order to defend against the them.

This is where professional programs like CEH have value.  This program teaches security professionals both the tools of the ‘bad guys’, and the ethics required to use them properly.  The temptation of a quick payday may be lurking for some people, but it’s good to see that the FBI and other government organizations are actively watching out for these type of people.

As Spiderman said – “With great power, comes great responsibility”.  Security professionals need to keep this at the forefront of their mind at all times.  We’d probably be better off by not wearing tights and a mask, though!

Recovering a PGP Whole-Disk-Encrypted Drive

Posted by Jon Janego on January 9, 2009 32 comments

This week I had a frustrating incident occur that I’d never wish upon anyone again – my PGP-encrypted laptop hard drive was corrupted!  Luckily, I was able to recover the data after hours of research and labor.  The whole experience was a painful one and it’s really turned me off from whole-disk encryption as a whole.

The initial problem was caused by one of my least-favorite pieces of software in the world – the Ubuntu graphical installer.  I was installing Ubuntu onto an external hard disk while using a Ubuntu LiveCD, and in the process of installing the OS, it overwrote the MBR on my laptop’s hard disk.  This seems to be a common pitfall affecting Ubuntu users.  Installing GRUB to the first hard disk is apparently the default behavior, according to several posts on the Ubuntu forums.  I must have missed the “Advanced” menu option to specify the bootloader location.

Installing GRUB to the MBR wouldn’t be terrible, if not for the fact that PGP Whole Disk Encryption (WDE) also uses a non-standard Windows bootloader – a piece of software called BootGuard that prompts the user for the decryption key to the drive.  Because GRUB took over the MBR on my hard drive, BootGuard would no longer execute – and thus the contents of my two partitions were stuck as encrypted with no decryption mechanism on the disk.

Adding further frustration to this issue was the fact that Ubuntu (loaded onto the external HD) wouldn’t even boot up without the laptop’s HD – because the GRUB boot loader was on the internal, encrypted HD, rather than the external HD that held the rest of the operating system.

So, I was stuck with an encrypted Windows installation and a halfway-usable fresh Ubuntu install.  What’s a guy to do?

Fortunately, if there’s one thing that our office has, it’s a lot of computers.  I was able to use a backup laptop to begin doing some research into recovery options.

PGP has recovery boot disks that can be used to decrypt a drive, so this was the first thing I tried.  With my encrypted (and inaccessible) disk in the bay of my laptop, I booted with the PGP recovery CD.  Unfortunately, this returned an error – “Internal error accessing disk, 0×80″.  A common error, if you do a little googling.  Something was wrong in the disk’s partition table or boot record – I would need to try another method.

The first method I found in the PGP Knowledge Base was in Tech Note 807 , which suggests creating a Windows PE recovery disk that supports PGP disk recovery.  I followed this path for a while, but had some issues slipstreaming the PGP software into the disk.  I gave up eventually after seeing a few other simpler methods suggested.

The simpler recovery method recommended by the members of the PGP forum and the PGP Knowledge Base was to install PGP Desktop on another PC, slave the encrypted drive to that machine, and decrypt the drive using the second PC.  I was able to get the PGP Desktop software from our administrator and install it temporarily on a new computer, then cable in my encrypted drive with a IDE to USB adapter.  This looked promising at first, with the machine able to recognize the drive and see its (unreadable due to encryption) partitions, but PGP wasn’t able to identify the drive as holding encrypted data on it.  After a few tries (and a few hours), I decided to move 0n and try a different vector.

I had seen a post on the support forum suggesting using a Windows disk to rebuild the MBR to a normal Windows state.  After doing this, the PGP recovery disc may work, since PGP is prepared to deal with a situation like this (somehow!).  By doing this, I realized I would lose the GRUB bootloader info for my Ubuntu installation, so I first pulled that off the drive from within Ubuntu (cat /boot/grub/menu.lst > /home/menu.lst).  This would give the UUID of the Linux installation if I ever want to try and get it working and bootable.

After doing that, I decided to just go for it.  After installing the encrypted drive into a spare laptop chassis, I put the Windows disc into the CD drive, booted to the recovery console (type R when prompted), and then ran the fixmbr command for the drive.  Rebooted, and…. unable to find operating system.  This was progress!  No more GRUB bootloader!

Finally, I put in the PGP recovery disk again, booted off it, and instead of the error I saw before, it continued on to the recovery console – and it recognized my PGP-encrypted disk!.  I typed in my passphrase, and then, very cautiously, chose “D” to decrypt the drive.  It very slowly started to decrypt.

The entire decryption process when running from the recovery disk takes quite a long time – on this disk (60GB), it was only about 15% along after 90 minutes.  I left the computer plugged in overnight and let it run.  When returning to the office this morning – it was done!  I put it back into my original laptop chassis (I was using a temporary one while I rebuilt a new installation of Windows on a spare HD in the main chassis), and it booted up as if nothing had ever happened.  The whole thing was pretty funny, actually – to see the little guy churning along as if it hadn’t been on the brink of death just 24 hours before.

This entire experience has left a bad taste in my mouth regarding whole disk encryption.  It’s very secure, and my experience with PGP prior to this incident had been pretty drama-free, but when it fails, it fails very dramatically.  PGP has very sparse documentation about the recovery process, and seems to take the opinion that their software is so reliable that they don’t need to spend much time making recovery a little bit easier.  For a user who’s done nothing wrong, they make the barriers to recovery too high – I had the decryption passphrase, and a simple mistake was enough to ruin all my data.  I was on the verge of scrapping the drive, suffering an unexpected data loss (which even regular backups can’t protect against perfectly).

I’ll probably avoid PGP WDE in the future, but whole disk encryption as a concept isn’t going away anytime soon.  It would be good for developers to keep disaster recovery methods in mind when creating their software!

Secure Password Management

Posted by Jon Janego on December 20, 2008 No comments

Following up on my post about passwords and physical security, I’d like to discuss a couple suggestions for secure password management.  This primarily applies to the unfortunate (but common) case where a team is sharing common logins and passwords.  We see this a lot with internal teams, especially in lab and development environments.

A few months ago I saw a good blog post by Joel Spolsky, where he suggested using a combination of Dropbox and Password Safe as a secure password management tool.  For those unfamiliar with it, Dropbox is an Amazon Cloud-based service that essentially acts as a network-based hard disk that can be synced across multiple machines.  Local copies of files are retained on the user’s machine and changes are synced with the main file server and distributed to the user’s other machines with the Dropbox client installed.

It’s a great tool and I would recommend it to anyone – and when used with Password Safe (install your encrypted password file on the dropbox-synced folder), it’s an effortless and secure method for an individual user to manage their passwords.

In an enterprise level IT environment, however, it’s probably not the best choice.  I can’t think of any responsible administrator who’d consider turning over a password list to an untrusted 3rd party, as anonymous or as encrypted as it may be.  It’s just not worth the risk.

The alternative, then, is to leverage a similar method using more secure means.  Our team uses a NAS device, which is an ideal and cost-effective candidate for similar functionality.  If your IT organization has large-scale production file servers which are regularly backed up and maintaned, that would be an even better candidate.

The missing piece in this suggestion is file synchronization – a killer feature of Dropbox.  There are a few different ways to take handle this – either using one of the many file synchronization tools, or a versioning system such as CVS or Subversion.  The choice is yours, but allowing the user to maintain a local copy of the folder is a critical component – because what happens if the file server goes down and the user forgets a shared password?

A careful security administrator will keep these circumstances in mind and plan for them accordingly.  Don’t be “that guy” who assumes his file servers will be up 100% of the time!  That’s what security is all about – hoping for the best, yet planning for the worst.

Password Policy, Physical Security, and Keeping the Cat in the Bag

Posted by Jon Janego on December 19, 2008 1 comment

Password policy is one of the most frustrating subjects for any IT or Security administrator.  You’re stuck in a “Damned if you do, damned if you don’t” situation, where no matter what you do the users will complain.  Something that I like to keep in mind when considering password policies is the careful balance between security and usability.

On one hand, there are fairly well-established best practices regarding password policies.  Non-dictionary words, 8-15 characters, etc.  SANS has a great (if a little strict) password policy document here which is a great starting point for any security administrator.

On the other hand, users have a hard time remembering complicated passwords, especially ones that are frequently rotated.  A well-enforced password policy won’t let users choose their name, dictionary-based words, or any other ‘easy’ passwords, so the user is stuck with having to remember a complicated acrostic, or a random string of characters.  And what do users tend to do in this situation?  Write down the password.

So, what’s wrong with this practice?  Nothing!  It’s even been advocated by various security gurus for years.  But you need adequate physical controls around the password list.  That’s the rub – in a large IT organization,  how does one protect from users carrying around scraps of paper?  Adding a further layer of complication, what about the case of shared logins and passwords?  The problem can become overwhelming quickly.

In an IT environment where Role-Based Access Controls (RBAC) are implemented, I would be inclined to not explicitly discourage users from writing down their individual passwords – because we’re all pretty good at physically controlling pieces of paper (money, anyone?).  I may encourage the use of a tool such as Password Safe,  but there’s only so much that you can do to control the behavior of the users.

Where common usernames and passwords are shared between many people (a tragic case!), the problem of password management becomes much trickier.  I’ve seen systems with multiple versions of a common password list, with each user having their own copy.  I’ve seen password lists distributed betweeen a dozen users via unencrypted email.  I’ve seen printed sheets of passwords “hidden” underneath the keyboard of a common workstation.  I’ve seen post-it-notes on monitors.  All of these situations are terrible, but in reality, they’re also unavoidable.  The best an administrator control for is to provide adequate physical controls; limiting access to the password lists.  It would take a very highly-motivated attacker to get past a security guard, keycarded doors, and a staff that’s advised to pay attention to unrecognized people in the building – and your security response policy should take into account the situation of a password breach and have plans for rapidly shutting down access and rotating shared passwords.

In summary, there’s only so much that you can do to control the behavior of users, especially when asking them to remember complicated passwords.  I would advocate RBAC authenticating against a common directory server in all possible circumstances, so that a breached username and password can be compartmentalized, protecting against damage.  If that’s not possible, educating the users about controlling access to their passwords, and providing for adequate physical controls is about the best you can do.  And as always, having a response policy that takes into account the circumstances of a password breach is critical.  IT has evolved to the point where users are getting comfortable with the strictness of password policies, but as an administrator or security professional, it’s important to consider the vulnerabilities and to keep in mind the careful balance of usability and security.