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

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.

For the uninitiated, though, here’s a brief summary: using Google (or any other search engine – but really, is there any other?) to find vulnerable web apps, personal information, mp3s in public directories, etc etc.  It’s great fun, and a pretty fundamental initial step of profiling an attack target.

Johnny Long was one of the main evangelists of this method and has a great database of search terms.  It’s no longer actively maintained, but you can still find plenty of good information with this as a starting point!

So Google hacking is great, but it only gets you to the public internet.  What if I wanted to profile the inside of a company, from the outside?  And passively – without hitting their servers myself?  Wouldn’t it be great if I could look for public information shared by company insiders?

Delicious seems almost perfectly designed to do this kind of activity.  For the unfamiliar, delicious is an online bookmarking site, designed around the idea that sharing bookmarks is a great way to learn about new sites.  Which is an alright idea…  but don’t people also bookmark a lot of private information?  I sure do!

Making matters worse, delicious encourages users to get started by uploading their browser bookmarks.  Essentially uploading gobs of potentially personal data to a public site.  This is a classic case of information leakage.  A dedicated attacker can use this public information to get all sorts of juicy tidbits about a company.

Let’s do some examples.  This all works great in theory, but, like Google, there is a LOT of data to sort through.  Say I’m a bad guy interested in insider information about a company.  I can start looking for the basics – say… “intranet”.  Delicious makes this easier by encouraging users to tag their posts for easy categorization:

http://delicious.com/tag/intranet

So that gives me everything that users have tagged with ‘intranet’.   Lots of sites about intranet design, usability, etc.  But also sites tagged by users to manage their own bookmarks!  So I’ll start digging into an individual company… how about AMD?

http://delicious.com/search?p=amd&u=&chk=&context=recent&tag=intranet

The first result doesn’t look interesting, but the second and third, well those sound like intranet sites!  This is confirmed by trying to follow them through and the DNS not resolving.  Nice!  Now let’s see what else this presumed AMD employee has bookmarked…

Wow, lots of development related links!  Interesting.  And what’s that link on page 2 about “AMD Manager Toolkit” ??  This fellow looks like he’s a technical manager at AMD!

Dig a little deeper, and it looks like we have another intranet site – mentioning the (presumably internal) code name of a project.  Interesting!  Go further into the links, and you see even further links to internal project Wiki pages.

Surfing around to a few of the non-intranet sites gives me an even better profile of this person.  They work with unit testing.  They use UML, C++, and Ruby, and read a lot about circuit design.  They live in India.  They’re learning guitar, and are interested in martial arts.

This may seem like innocent information to an outsider, but if I was doing this for espionage purposes, I just learned a lot about the internal operations of a project – and this is with 10 minutes of work on one webpage.  What else could I find if I dug through the internet further?

Web 2.0 is a lot of fun, and can be really useful.  But what’s often overlooked are the implications of sharing all this information.  Unless you make it a point to protect your privacy, that privacy probably doesn’t exist.  And for businesses, this can be a major potential risk.

Delicious certainly doesn’t help stop this – according to the FAQ, you cannot make your links private by default, but instead must manually edit them to make them private.  And also, the TOS leaves responsibility entirely in the hands of the users.  Very laissez-faire!

Should companies ban employees from using sites like delicious?  Probably not.  But I think that this demonstrates that employees need to be more educated on what they are exposing themselves and their employer to when using social networking sites.

I recently had the opportunity to speak with a WLAN network administrator and we briefly discussed the merits of using an integrated RADIUS server on APs vs using an external RADIUS server for authentication. After thinking about it for a few days, I realized that relying solely on the integrated RADIUS server for wireless authentication is rarely a good idea.

• Integrated RADIUS servers on APs are typically minimal servers that are designed to serve a small number of clients. If the WLAN network grows in size, the number of users that will need to be configured could easily exceed the limits of the integrated RADIUS servers.
• Some integrated RADIUS servers do not offer support for accounting services. This can be either a non-issue or a serious disadvantage depending on the purpose of the WLAN.
• Integrated RADIUS servers typically use proprietary local database engines/management interfaces to administer the user database, which makes it difficult to do certain operations like import/export user databases between APs or switch to APs from a different vendor.
• Standalone RADIUS servers offer advanced capabilities such as integrating with LDAP or Exchange servers to provide single sign-on capabilities. Integrated RADIUS servers in APs don’t have such capabilities due to the complexities and necessary protocol support required to interact with other authentication servers.
• Integrated RADIUS servers can only support the EAP methods that are built into it, restricting the set of EAP methods that can be used in the WLAN. Standalone RADIUS servers can typically support a much larger number of EAP methods and therefore provide the WLAN administrator with a great deal of flexibility. Note that APs which are acting only as a NAS are only relaying EAP messages between clients and the RADIUS server and therefore don’t need to have support for the different EAP types built-in.

However, even with all of the advantages a standalone RADIUS server offers over an integrated RADIUS server, there are some compelling advantages of the integrated solution: the integrated server is likely only to fail when the AP itself physically fails, the authentication sequence may be slightly faster since there is no extra hop between the AP and a RADIUS server, and of course it doesn’t require any additional capital expense for your network. In short, the decision between a integrated and standalone server solution should carefully consider short term and long term costs/network growth as well as flexibility in supporting both existing and future requirements of the network.

BUT making things more interesting- this was an “optional” update with XP SP2, until it was finally rolled into XP SP3.  There is a hotfix for XP SP2 machines in order to support WPA2 – KB 893357.

WPA2/AES didnt’ really become widely implemented until 2006, but it was in the 802.11i spec that introduced WPA in 2004.  For a major vendor like MS to not implement it is pretty crazy.  But then again I, as a wireless security professional, didn’t setup a WPA2/AES network in my home until last month.  So maybe they were onto something.

Anyways, if you’re using XPSP2 and a WPA2 network – you need the hotfix, or XPSP3+.  Good luck out there!  I really recommend moving to WPA2/AES, especially considering the improvements in the Nvidia CUDA drivers that are allowing TKIP to be broken in an increasingly short amount of time.

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!

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!

HIPAA is encoded in the US Code of Federal Regulations, Title 45, Parts 160, 162 and 164 (see here for the CFR). Section 164 is the most interesting section for a security professional, as this section describes the security and privacy requirements that must be satisfied by organizations that must comply to HIPAA regulations (these entities are called ‘covered entities’). Unfortunately, Part 164 is further divided into 31 subsections that define the actual security requirements. Rather than digging into each of these sub-sections, I’m going to focus on sub-section 312 which defines the technical safeguards that must be implemented by covered entities. Subsection 312 specifies 5 standard safeguards: access control, audit controls, integrity, person or entity authentication, and transmission security. The code further specifies implementation requirements for each standard. The following mindmap graphically illustrates Subsection 312.

Mindmap of CFR 164, Section 312

As far as legislation goes, the HIPAA Technical Safeguards are fairly well written in terms of striking a good balance between actionable requirements with room for interpretation to make the standard independent of changes in technology (for example, the Encryption safeguards do not name specific encryption algorithms that need to be used). However, the Safeguards are too vague to use alone. Therefore, NIST prepared a Special Publication, SP800-66 Rev1 (found here), that can be used to help interpret the safeguards by mapping them to specific controls described in NIST documentation. In a future post, I’ll further examine NIST SP800-66 and attempt to summarize some of the specific security controls to implement the HIPAA Technical Safeguards.

I’ve filed a bug report with the plugins group here.

With the ubiquity of wireless networks and the ease of promiscuously monitoring wireless networks, it is no longer acceptable to authenticate over clear text. Twitter shouldn’t allow authentications over none SSL channels, and applications shouldn’t support them even if non-SSL is supported. I discovered this while a friend was toying around with Kismet at a local cafe. I typically connect to an OpenSSL VPN whenever I use public networks, but due to the nature of the plugin it connects before I have a reasonable chance to enable the VPN… hence my friend captured my password. Fun.

I would also like to take this oppurtunity to remove any liability from myself for anything posted to my Twitter account in the future

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!