Securism Blog

Simple Security.

Information Leakage via Delicious

July 10th, 2009 by Jon Janego
Respond

By now, the concept of “google hacking” is pretty commonly understood.  People may not be preventing it very well, but it’s moved beyond a new thing.

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

intranet_amd

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…

links_1

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.

links_2

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.

Tags:   · · · · No Comments.

Integrated vs. Standalone RADIUS Servers in WLAN Deployments

June 29th, 2009 by Walter Goulet
Respond

Several popular WLAN infrastructure vendors include lightweight RADIUS servers directly in their access points. These lightweight servers are typically designed for use by vendors as a backup solution in the event that connectivity to an off-board RADIUS server is lost.

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.

Tags:   · · · · No Comments.

No WPA2 With Windows Wireless Zero Config??

June 8th, 2009 by Jon Janego
Respond

Wow – I would never have thought that in this day and age, a major vendor like Microsoft wouldn’t fully implement a spec.  However, in the case of WPA2 it looks like that they did exactly that – at least until 2005.

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.

Tags:   · · · · · No Comments.

Where Have We Been?

April 15th, 2009 by Jon Janego
Respond

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!

Tags:   No Comments.

Putting Together a Wireless Security Toolkit for the Android OS

February 25th, 2009 by Jon Janego
Respond

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!

Tags:   · · · No Comments.

HIPAA – Technical Safeguards

February 17th, 2009 by Walter Goulet
Respond

A large part of my job requires me to dig into security standards to help figure out how to create consulting services to assist customers with achieving compliance. One standard I’ve never looked into before is HIPAA (Health Insurance Portability and Accountability Act of 1996). HIPAA is not a security standard per-se, but rather a set of administrative rules established by the US Department of Health and Human Services to govern how health information is accurately and securely exchanged between medical institutions and other institutions that have a legal need to access patient medical data.

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

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.

Tags:   · 3 Comments

Gnome Do Microblogging Plugin Authenticates Over Clear Text

January 30th, 2009 by Ben Hagen
Respond

I love the Gnome productivity tool Gnome Do. Its great! What’s not so great is the fact that the installation default Twitter plugin “Microblogging (Twitter)” version 1.0 authenticates to Twitter over clear text. In general, its a great plugin… easy to post updates and wonderful balloon popups when friends post their’s… but this is a killer problem.

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 ;)

Tags:   · · · No Comments.

Responsible Home Wi-Fi

January 28th, 2009 by Jon Janego
Respond

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!

Tags:   2 Comments

HOW-TO: Cutting edge wireless drivers in Ubuntu

January 28th, 2009 by Ben Hagen
Respond

MADWIFI has been the wireless driver of choice for wireless hacking for quite a while, but recently a lot of development time has been moved to the official kernel wireless subsystem drivers. They are slowly gaining and surpassing MADWIFI’s functionality, and are generally more supported and stable. One downside to these drivers is that recompiling the kernel is time and labor intensive and waiting for a distro’s kernel update can put you behind the curve in recent driver functionality.

The COMPAT-WIRELESS project pre-packages the latest wireless code as loadable kernel drivers on a (near) daily basis. This is a convenient way to download pre-patched and archived source… but in order to get the most recent changes (as they are committed) you have to pull the source directly from the kernel.org GIT tree. GIT is a code versioning system similar to CVS, SVN, Bazaar, etc. Below is a simple example of how to do this and compile / install the code. I’m writing this from an Ubuntu installation, but the same concepts should work on other distros. This isn’t an especially difficult process, but it isn’t necessarily obvious either.

There are a few prerequisites for the below instructions to work correctly:

  • Kernel greater than 2.6.21

  • Kernel headers (”apt-get install linux-headers-generic” in Ubuntu)

  • Build tools (”apt-get install build-essential” in Ubuntu)

1. Make a new directory and clone the source trees:

mkdir wireless-testing
cd wireless-testing
git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6.git

2. Make the packages

cd compat-wireless-2.6
export GIT_TREE=../wireless-testing
scripts/admin-update.sh
make

3. Install

cd compat-wireless-2.6
sudo make install

4. Update and repeat steps 2-3 when you want the latest and greatest

cd wireless-testing
git-pull
cd ../compat-wireless-2.6
git-pull

After step 3 you can try reloading the modules dynamically by running “make unload” and “make load” but this probably won’t work if you’re currently using your wireless drivers. Your best bet is to reboot your machine. You can confirm that you’re running the new(er) drivers by listing your kernel modules and look for the mac80211 module.

lsmod | grep mac80211
modinfo mac80211

If there are problems you can uninstall the drivers by running “make uninstall” from the compat-wireless-2.6 directory. Hope this is helpful!

Tags:   · · 3 Comments

Hashes – not just for breakfast

January 28th, 2009 by Walter Goulet
Respond

Consider the problem where you need to know for sure that information you are looking at has not been altered since it was first created. A simple example that kids can relate to is a report card from school. The model for report cards is that the school gives a kid his/her report card, they bring it home and their parents sign it to show that they read the report card. An obvious problem that the school has is to be certain that the report card isn’t changed while the kid has it.

In cryptography, this problem is referred to as ‘data integrity.’ Cryptographic systems solve this problem by creating a representation of the information that is unique. This representation is referred to as a ‘hash’ (or checksum). A good way to think of a hash is as a digital fingerprint that looks totally different for each set of data that it represents. Functions that are used to create hashes from information are called hash functions. There are a couple of important points about hash functions:

  • The result of the hash function MUST be unique for each message that it processes. That is, you should never be able to get the same result from a hash function if you feed in two different messages.
  • The result of the hash function MUST not look anything like the message that it processed.
  • It MUST be impossible, given the result of a hash function, to determine what the original message was.
  • The result of the hash function is usually smaller than the message that it processed.

If you wanted to exchange a message with another person and be sure that the message hasn’t been changed along the way, you could use a hash function as follows:

  1. Create a message.
  2. Feed that message into a hash function.
  3. Send the message to the recipient along with the hash.
  4. The recipient feeds the message into the same hash function used by the sender.
  5. The recipient compares their hash with the sender’s hash. If they are identical, the recipient is sure that the message wasn’t changed.

Of course this exchange isn’t secure as the hash could be changed in transit as well, but it illustrates how such a system works. I’ll explain how to make this exchange secure in a future post. To find out more about the basics of hash functions, read more.

[Read more →]

Tags:   No Comments.