Category Archives: Securism

Solving the THOTCON 0×2 Pre-Sale Puzzle

Posted by Jon Janego on November 2, 2010 1 comment

Earlier this year, some folks in the Chicago security community got together and organized a conference called THOTCON, which turned out to be a resounding success.  It took place in April and drew several hundred people together for a day filled with some great talks, beer, and general hacking socialness.

To gather some early buzz (as well as to have some fun) for the follow-up next spring, the organizers decided to do an early pre-sale puzzle.  Of course, like many things in the security community, the hints were leaked only to their twitter stream.  Inspired by a few of my friends poking at it, and with some free time to spare, in the spirit of learning (and a chance to save about $20!) I decided to take a stab at the puzzle.

By the time I started working on it, the organizers had leaked a few hints.  Here’s where it was at when I began:

Puzzle -> FAW2GlImKsT3BL8yKQF= zf-c75-sb-j 60max #thotcon0x2

Hint #7 – I am the answer to my own puzzle. You just need to look at me the right way
Hint #6 – Decrypt, then decode
Hint #5 – The coolest thing about part 2 is… You dont have to do ANYTHING. (Put it somewhere and tada!)
Hint #4 – Part 2: I’m not a cipher, I’m a conversion. You have the tool to convert me. In fact, you don’t have to convert me.
Hint #3 – Part 1: He is dead
Hint #2 – What do you mean I was part of the Reichstag zu Worms?
Hint #1 – I was born on April 5th. #thotcon0x2 <— puzzle hint?

So, to break it down, the hints indicated a 3 step process to solve the initial hint string.

Step 0:

Working from the string:

FAW2GlImKsT3BL8yKQF= zf-c75-sb-j 60max #thotcon0x2

To be honest, I wouldn’t have had much to go from here were it not for the hints, and my twitter addiction.  I picked out the ‘zf’, ‘c75′, ‘sb’, and ‘j’ as being the handles of several of the organizers – @zfasel, @c7five, @sak3bomb, and @jaku.  So we could drop that.  ’60max’- this is cleartext and probably not a code, so dropped.  ‘#thotcon0x2′ – again, twitterese – a hashtag used to talk about the conference.  Dropped.

So we’re left with the cipherext to decode,

FAW2GlImKsT3BL8yKQF=

I suppose that’s a start.

Step 1:

I’m not much of a cryptologist, but I do know a bit of the history, mostly thanks to reading Simon Singh’s excellent The Code Book.  I figured it was a reasonable assumption that this is a classical cipher, breakable by hand.  So, poking a bit around Wikipedia for famous classical ciphers, a bit of digging came up with April 5th being a reference to Blaise de Vigenère, whose name is attached to the famous Vigenere Cipher.

This cipher is a relatively straightforward method of letter substitution, which a dedicated person could do by hand.  However, being a citizen of the 21st century, I wanted to put computers to work for me – so I found a site to decode it!

http://sharkysoft.com/misc/vigenere/

Problem was… a Vigenere cipher requires you to use a known key to decode it.  Which I didn’t have, so I began guessing.

This required jumping ahead a little bit – what to do with the decoded ciphertext?  The hint to part 2 indicated that it was a conversion… so my natural first guess was Base64, just because it’s so common.  So I began working on the assumption that my decoded ciphertext would be Base64 encoded.  I found an online decoder and began guessing away.

Now, a Vigenere cipher would be relatively easy to bruteforce in the age of modern computing, but I didn’t honestly expect the organizers to force people to write a brute forcer.  Instead, I began guessing words associated with the security community.  Eventually, after guessing many words… I tried the name of the conference itself – THOTCON0x2.  And bingo!  I had cleartext that also decoded to Base64:

MTI2NjUzNzM3NS8wWDI=

Step 2:

I suppose this is a bit redundant since I had been testing my cleartext in the Base64 decoder the entire time.  Using this online decoder:

http://www.motobit.com/util/base64-decoder-encoder.asp

I ended up with some very promising text:

1266537375/0X2

Step 3:

In the spirit of full disclosure here, step 3 was where I performed a bit of ‘social surveillance’.  Following the #thotcon hashtag on twitter and saw Nick, one of the organizers, post a hint saying something to the extent of, “is it alive?”

How do you check if a computer is alive?  Usually a good first step is to ping it.  I already had my suspicions about this string, but this gave me the idea to just run a ping at the decimals in that address (the ’0X2′ was clearly intentional and I dropped it from consideration).

ping 1266537375

Pinging 75.125.211.159 with 32 bytes of data:
...

Ping did the translation for me, nice!  Now I have a more easily readable IP address.

This string was a decimal representation of an IP address.  Not commonly used, but still valid – and if it’s used commonly anywhere, it’s with spammers/phishers who like to obscure their targets from cursory glances.  You can read more about it here.

Step 4:

So now we had an IP address.  Now what?  A nmap scan showed a webserver running on port 80, so I sent my browser there…. and got a blank page.

But wait a minute…. wasn’t there a string I dropped from that address?  ‘/0X2′.  After kicking myself for the brain fart, I navigated to…

http://75.125.211.159/0X2/

And had what looked like a winner!

There were three images there – unfortunately not loading at the time – and a link to the registration page.  When doing a mouseover the three images, some codes were revealed:

VEHPVE
NPTJB4M
I0YMDEX

I moved on over to the registration page, concatenated these strings together… and success!  The discount code was accepted.

Conclusion

This puzzle was a fun one, which pushed you to think a bit outside the box.  Also, because it was released ‘into the wild’, the internet was at your full disposal to track down hints.  So while it may have been shortcutting a bit, I didn’t see anything wrong with spying on @c7five as he gave hints to other players ;-)

I don’t know how many pre-sale tickets that they ended up selling, but the initial hint was that they only were offering 60 of them at the discounted price.  So, having solved it before they publicly revealed the pre-sales code, I felt pretty proud of myself.  Perhaps I was just lucky to have the free time to poke at it.  I’ve also gotta thank my friends for pointing me in the right direction after I got stuck (and way to go, Rudy, Jeff and Jim for being more clever than I and figuring it out faster!).

The puzzle appears to have been primarily created by Sak3bomb, who is clearly a brilliant individual, much more clever than those of us trying to work backwards.  Major props to him and his collaborators for putting together a fun puzzle.   He archived the hints on his webpage here:

http://www.haxbysakebomb.com/thotcon.html

I’m really looking forward to the next THOTCON, and general sale tickets are available now – so go on and buy em.  I’ll see you there!

WLAN In the Enterprise – Use Cases and Strategies

Posted by Jon Janego on July 21, 2010 No comments

Continuing from my first post in the series, today I hope to cover the common use cases and general strategies for securing an enterprise WLAN.

Depending on the size and business needs of the enterprise, a WLAN can be used in a few different ways:

Basic Mobility – the most common use of WLAN is simply to extend the existing wired LAN to wireless users.  This can have a very positive impact on productivity, allowing users more flexibility throughout the workspace.

Segmented Mobile Data - this type of WLAN is one where the network is dedicated to use of a specific type of data that is segmented from the main enterprise network.  Typical use cases here are in hospitals or retail stores, where compliance regulations provide strict guidance on data protection and segmentation.

Guest Internet Access – common in cafes and large businesses, this type of WLAN typically provides only internet access and is entirely segmented from the enterprise wired LAN.

Wired LAN Replacement - this type of network is becoming a feasible alternative to the hassle of running cable, and will likely continue to grow in popularity as time goes by

These use cases can blend together in any number of ways.  A well thought-out design at the beginning, along with the right hardware planning, can accomidate these uses and even more.

General Strategy

Like other networking strategies, the use of proper segmentation at the Layer 2 level is critical when designing a WLAN.  Your most critical data flows should have their own segment, protected by methods like VLAN segmentation, firewalling, private IP spaces, and routing tables.  Regardless of the authentication and encryption method used for the WLAN itself, properly designing its location within the enterprise wired LAN is critical.

Data encryption in 802.11 is accomplished by a combination of the authentication type with an underlying encryption method.  Use of WPA2-AES encryption should be considered mandatory in any new WLAN deployment.  This encryption technology has no documented vulnerabilities and widespread hardware and software support.  If your enterprise has devices that do not support WPA2-AES, strongly consider replacing them.  When designing a network, its security should not be determined by the weakest link.  Unless there is a business case for doing something otherwise, use the strongest encryption and authentication methods available.

My next post will get into some specifics about these different use cases!

Deploying A World-Class WLAN in Your Enterprise

Posted by Jon Janego on July 16, 2010 1 comment

In the last decade, 802.11 Wireless LAN technology has had a dramatic impact on the technology world.  Reliable, high-bandwidth networking is now easily available to anybody who wants it, and the number of WiFi enabled devices continues to grow at a dramatic rate.  So naturally, businesses ranging from basic office environments, to complicated co-located warehousing/retail/office operations have begun leveraging the technology as well.  Unfortunately, the ease of setup that WLAN offers has led to some confusion among even seasoned IT practitioners.  In this series of  posts, I hope to provide some simple guidance to help clarify how to securely and efficiently manage an enterprise Wireless LAN.

Some History

I will not go into the history of the 802.11 standard in too much detail here, although there are a couple of important points to recognize when thinking about how to deploy a WLAN in your business.  The most important thing to know is this – many of the WLAN security technologies that were being used in deployment until three or four years ago are vulnerable to several well-known attacks.  If your business has a WLAN that has “just been working” for a while – it should probably get some attention.

To elaborate on this a bit further, the most common Wireless LAN encryption method used until late 2003, WEP, has been subject to some very public weaknesses, almost since its inception.  Its temporary replacement, WPA-TKIP, has similar (although not as dramatic) weaknesses, that have been public since at least 2008.

Adding insult to these platform-common weaknesses, some of the alternate, “more secure” based authentication methods advised by vendors have also been picked apart and had their vulnerabilities shown to the world.  I’m looking at you, LEAP.

To sum it up briefly – many networks that people thought were secure in 2003 or 2004 are definitely not secure today.  And unfortunately, WLAN sometimes is treated like a part of the physical infrastructure – if it ain’t broke, don’t fix it!

Current Tech

Fortunately, 802.11 is really starting to come into its own lately, and can be an extremely secure – in some ways more secure – piece of critical infrastructure.  The extremely solid (and so far unbroken) WPA2-AES encryption standard defined by 802.11i has had widespread vendor support since 2007.  And certificate-based authentication methods such as EAP-TLS, PEAP, and EAP-TTLS have similarly experienced a growth in support, among not just desktop OS platforms, but mobile operating systems as well.  And Wireless Intrusion Detection Systems are hitting their stride, ranging from several robust and effective professional solutions from vendors like AirTight, Cisco, and Motorola, to fantastic open-source applications like Kismet.  And robust infrastructure management software is now making the administration of Wireless LANs more simple and effective.

In short, today it is possible to deploy a WLAN that will meet all the use cases an enterprise can throw at it, and that is as secure as a typical wired LAN infrastructure.

In the next post, I’ll cover typical enterprise WLAN use cases, and the strategies for designing and securing them.

SANS 2010

Posted by Jon Janego on February 25, 2010 No comments

If any readers out there are interested in meeting up, all three of us will be attending the SANS 2010 training conference in Orlando, Florida the week of March 7th.

Feel free to drop us a line here and we can have a beer!

Quick and Easy Portable Media Encryption

Posted by Walter Goulet on February 25, 2010 1 comment

As part of my personal service delivery process, I have a need to store sensitive information for client engagements (vulnerability assessment results, network diagrams etc). To avoid having a dependency on specific test systems, I prefer to use portable USB drives to store data in the event that I need to switch to another system. However, I don’t want to risk losing this drive with confidential data on it. My solution is to create an encrypted partition on the disk in such a fashion that I can quickly mount the drive on another system without downtime.

To meet these requirements, I use a combination of Dropbox (http://www.dropbox.com), Keepass (http://keepass.info/), and Truecrypt (http://www.truecrypt.org/). I use Dropbox as a portable ‘Program Files’ directory where I install portable versions of Keepass and Truecrypt. This allows me to have my ‘Program Files’ directory replicated on all systems where the Dropbox client is installed (for backup purposes, I usually have my Dropbox account synchronized to 2 different systems).

I use Truecrypt to create an encrypted partition on the USB drive (using AES for encryption and HMAC-SHA-512 as a hash algorithm). The volume key used to encrypt/decrypt the partition is then stored as a password in my Keepass database (which is also stored in my Dropbox).

As long as the Dropbox is synchronized between my test systems, switching from one system to the other is as simple as plugging the USB drive in and launching Truecrypt/Keepass from my Dropbox.

Here’s my step by step instructions to replicating this setup on a Windows XP/Vista/7 system (I assume you already have Dropbox installed on your system):

  1. Create a ‘Programs’ directory in your Dropbox folder. In this folder, create 2 subdirectories, ‘Keepass’ and ‘Truecrypt’.
  2. Copy the portable versions of these programs into their respective folders (Truecrypt does not have an explicit ‘portable’ distribution, rather download the setup file here and choose the ‘Extract’ option when running the setup, Keepass on the other hand provides a portable version that can be downloaded here).
  3. Launch Keepass and create a new password entry for the portable drive. I suggest using the Password generator function to generate the password. Note that since this password is used as an encryption key, I recommend selecting all available characters for generating the password and using the maximum key length (64 characters).
  4. Plug in the portable USB drive that will contain the encrypted partition (note: this has only been tested with USB hard drives; I have not tested this with smaller USB flash drives).
  5. Launch TrueCrypt and use the ‘Create Volume’ button to launch the new volume creation wizard. I recommend writing down the path to the volume being created to make it easier to mount later. For my personal setup, I chose to create a regular (non-hidden) partition using AES and SHA-512 for encryption and as a hash algorithm. When prompted for the volume password, use the password entry created in Keepass.
  6. The volume is now created!

To actually mount the encrypted partition, start Truecrypt and select an available drive entry. Select the encrypted volume from the Volume list then click ‘Mount’. When prompted, enter the password from the Keepass password entry.

Note that regardless of which system was used to create the encrypted partition, you can mount it on any other system as long as you have access to Truecrypt and your volume password.

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!

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.