While these weaknesses have been known, what makes Moxie’s presentation unique is that he launched this attack against a large sample set of real victims, and succeeded in capturing their login credentials. Further, Moxie has shown us that his tool SSLstrip, and others like it, can make these attacks easy and automatic – assuming you have a foothold as a MITM. Hopefully somewhere, upon reading Moxie’s slides, a browser UI designer has finally let out a “Doh!” and slapped his own forehead.

MITM attacks on SSL aside, the most interesting thing I’ve taken away from Moxie’s talk that he was able to identify user accounts for specific web sites on the Tor network. You can read about how Tor works on the Tor Project site, but the purpose of Tor is to provide reliable anonymity while surfing the Internet. Anonymity is key for folks who want to blog about their oppressive governments, as well as those who engage in less-than-ethical activities on the Internet.

Posting an anonymous blog on a free blog service is one thing. But what about anonymously logging into your bank’s web site? Or anonymously checking your PayPal account? Isn’t that kind of like anonymously presenting your drivers license to the bouncer at the bar? The person on the receiving end of the communication knows who you are claiming to be.

If I wanted to do something that would hide my identity, I would use the Tor network. However, if I were doing something to hide my identity, I would not do so using my own peronally identifiable information (PII). This really makes me wonder about the people that Moxie man-in-the-middled. Were they ignorantly using Tor, assuming that anonymity in the network provided them increased security to perform their online banking? Or were they bad guys (phishers) logging in to compromised accounts using Tor to hide their identity and protect them from prosecution?

There are a lot of misconceptions about SSL and “online security” in the non-security geek world. People don’t get it. The big question I have after Moxie’s presentation is “do similar misconceptions apply to the use of Tor”? I would be very interested to know more about the people compromised in Moxies experiment.

-Schmoilito

Hello everyone, I’m Rajendra Umadas, the newest member of the Intrepidus team. I joined Intrepidus not too long ago and I’m loving every second of it. We just came back from ShmooCon, which was my first security conference. Shmoo was a great experience, and I’m excited to attend further cons. While a few of the talks were pretty informative, one in particular I found very interesting. Michael Ossmann and Dominic Spill spoke about how one can build an all channel Bluetooth monitor. Their approach towards solving this problem was ingenious. Quite honestly, any hack that allows us to capture data flows that were otherwise private is awesome. If this hack relies on a basic theory of digital signal processing (I’ll get into that later) as well as the normal security concepts we are all well aware of, it becomes that much more interesting. This Bluetooth presentation had all of those traits.

I don’t plan on reproducing the presentation since you can find that online, however, I do want to talk about what I believed was an interesting solution to a problem that they ran into. But before I can get into the solution I need to introduce the problem.

Bluetooth operates within a 79 MHz bandwidth. It uses 79 channels, each of which is 1 MHz wide. The devices randomly hop around the 79 MHz bandwidth 1600 times a second. All devices that are in a Bluetooth network (piconet) know the hopping pattern and listen to the right frequency at the right time. Ossmann and Spill were able to reverse out the hopping pattern of a piconet by passively listening to 25 channels of communication using their USRP (a tool used to help create software radio implementations.) Their USRP can sample a 25 MHz bandwidth and pass all the data to a computer for processing. They also developed a few scripts that can reverse out the hop sequence by looking at a fraction of a piconet conversation.

Once the pattern is discovered, monitoring a Bluetooth stream can go in one of two directions. You can sniff one channel at a time and retune the radio per hop, or you can record all 79 channels and parse out the correct channels in the DSP software. Both of these paths have some limiting factors. The first, retune per hop, cannot be done with the USRP. Retuning the 2.4 GHz card in the USRP cannot happen 1600 times a second, and therefore cannot hop as fast as the Bluetooth devices. One suggestion then was to bootstrap a Bluetooth dongle with the correct hop sequence and let it do the sniffing. But if we are going to spend thousands on a USRP we damn well want to keep using it. The second solution entails listening to all 79 channels, which would require 4 USRPs. However, buying 4 USRPs is 4 times harder than buying one. We need to find a cheaper way. Digital sampling theory to the rescue!

Using a principle called aliasing, Ossmann and Spill were able to turn their 25 MHz bandwidth USRP into one that can sample 79 MHz! Aliasing is a term used to describe the phenomena when two distinct analog signals create the same digital representation when they are sampled at a certain frequency. This is because at the points where the two signals are sampled, they also intersect each other. Refer to figure one below. The two analog signals are obviously different frequencies, however, if they are sampled at the blue points their digital representation would be identical. Usually this is a phenomena radio designers try to eliminate from their systems. This is because they need to read only one frequency, and the alias frequency would just add noise to the desired signal. Therefore many designs use band-pass filters to isolate one central frequency and eliminate the alias before sampling.

Figure 1. Aliasing in action.

However, for the purpose of Bluetooth monitoring, we do not need this filtering. This is because only one of the 79 channels is ever used at once. No one channel will interfere with the communication on another channel. Once the filters were isolated on the 2.4 GHz ISM board in the USRP, Ossmann and Spill could just remove it, choose an appropriate sampling frequency, and rely on the aliased frequencies of the 25 MHz band to pick up the rest of the information. Problem solved, and they can now use one USRP to sample the full band of Bluetooth!

So now that all your Bluetooth traffic are belong to us, the sky is the limit. As pointed out in the presentation, many of these devices do not encrypt traffic before it is transmitted. This opens the door to quite a number of attacks. There is the obvious consumer based traffic that can now be sniffed (cell phone, key board, and so on.) Bluetooth, however, has a strong industrial footing. A lot of these industrial applications are one of a kind systems, tailored for a specific facility. Any industrial facility that uses Bluetooth to monitor and control machinery must now consider this new threat to their assets. If there are any vulnerabilities in their deployed Bluetooth systems, proprietary company information could leak into the wrong hands. The presentation also mentioned that active Bluetooth attacks can now be developed. Once you have the hopping order, you can inject traffic into a piconet. This may lead to DoS attacks, unauthorized access and control, and other devious actions against the industrial equipment. Be forewarned…

-D1AB1069

(cross post on RajWeb)

Unfortunately, Discover Card isn’t the only organization breaking PKI. The pillars of Internet security, our trusted third party Certificate Authorities, have been having a rough time recently. A number of implementation specific flaws at multiple CAs have allowed outsiders to abuse their systems and obtain certificates for which they are not authorized to hold. Sure, these implementation specific flaws can be fixed, but the lasting damage to the trust we have in PKI can’t be undone. Further, the way PKI has been handling these situations seems to further undermine whatever trust remains.

Last summer when I disclosed the details of how I got the live.com certificate to Microsoft, I told them I wasn’t going to do anything bad with it, they said thanks, we shook hands, and that was pretty much the end of it. A few weeks ago, when Sotirov and crew disclosed that they derived their very own key capable of signing certificates that would be trusted by all web browsers, the researchers told Microsoft, Mozilla, etc, that they wouldn’t do anything bad with it. These companies again said thanks, hands were shook, and that was pretty much the end of that.

We rely on WebTrust audits and other mechanisms to ensure that our commercial Certificate Authorities do their job well, and so we can be sure we’re sending our data to the web sites we trust. Unfortunately, when the audits are useless and the Certificate Authorities screw up like they did in the above two scenarios, companies like Microsoft and Mozilla are forced to make a tough call:

Do they
a) Revoke the root CA for which a duplicate signing key was derived by unknown individuals, thus breaking the Internet for many businesses and individual users
or
b) Do nothing and trust that these guys really only have an expired certificate, and didn’t generate one valid for the next couple of years since they so very easily could have.

In the end, the trust that backs PKI is replaced with the trust of a few select individuals at the organizations who manage our root certificate programs (a.k.a the browser vendors). The millions of dollars spent on web trust audits are meaningless. The CAs could have just paid all of their money earmarked for audits to Sotirov and Appelbaum in exchange for their silence, and PKI would lived to fall another day.

Burn your SSL Certificates?

PKI, while good on paper, is hard to implement securely. It has taken almost two decades for us to have web browsers that actually support the one method that PKI has to protect itself from rogue certificates: Certificate Revocation Lists. And it doesn’t really matter, since not everyone is using IE7 or Firefox 3 yet. CRLs, which are essentially blacklists, are completely ineffective when you don’t even know what rogue certificates are actually in existence.

I don’t think trusted third parties are enough. We need technology that puts the ability to make trust decisions back in the hands of end users, rather than trying to make these decisions for them.

So what can we do differently? I’m of the mindset that client side certificate / public key caching, like that of SSH, can drastically improve our ability to make trust decisions when communicating on the Internet. SSH shows us that we can communicate securely without trusted third parties. The next question is how best to apply this to web browsers. Hashes of public keys are not easily consumed by casual Internet users. Another Intrepidus colleague, Aaron Rhodes, brought up the idea of vanity hashes that are actually easily recognizable patterns. This could help, but it would certainly complicate key management.

In an effort to actually try and help make things better, rather than just ranting about how bad PKI is on this blog, I’ve actually been working on a plug-in for Firefox that lets users white list SSL public keys SSH style and alerts the user when they change. It is actually alot harder than it would seem. In my next post, I’ll talk more about this plug-in, and the challenges I’ve faced in getting it working.

-schmoilito

The discussion resulting from StartComs blog post is quite interesting, and touches on many issues spanning from internal CA domain validation procedures, to how to revoke a certificate in the Mozilla root cert program. One issue in particular, is exactly what I talked about in my last post.

Frank Hecker, of the Mozilla Foundation, said “[right] now we have no real idea as to the extent of the problem (e.g., how many certs might have been issued without proper validation, how many of those were issued to malicious actors, etc.).”

When a flaw in a CA validation mechanism is uncovered, it can sometimes be trivial to fix. The hard part is determining if any other certificates were obtained by taking advantage of the same flaw, and then revoke them. Although I can imagine a methodology for this process, I can’t comment on how any given CA would actually tackle this problem. Based on my own application security experience, I will say that I’m sure lots of logs that would need to be parsed, might not actually exist.

One person who commented on the StartCom post that started this all critiqued the post by saying it seemed dodgy that StartCom was blatantly pointing out flaws in a competing CA. The reader did, however, understand the severity of the problem that was found and thanked StartCom for publicly disclosing it. I agree with the reader, and I think StartCom did a good thing in disclosing this bug.

So in the interest of full-disclosure, here is what happened on Friday December 19 (three days before the StartCom disclosure). I found a flaw in StartCom’s domain validation mechanism that easily allowed anyone to authorize themselves for ANY domain name, on various .TLDs. While I only tested .COM, many other TLDs were available including .GOV.

The screen shot above shows the domain names my StartCom account was allowed to create signed certificates for. These certificates would have been trusted by Firefox, but not Internet Explorer. The first one is a domain I control. Phishme.com and Intrepidusgroup.com are domains owned by my employer for which I am not an authorized contact, and for which I should not have been, but was, granted a signed certificate. Needless to say Paypal.com and Verisign.com are companies I’m also not authorized for.

Fortunately for Verisign and PayPal, a defense in-depth strategy succeeded for StartCom. While I by-passed StartComs domain validation process, my attempts to create a signed certificate for Verisign.com was flagged by a black-list and not permitted. This is good news for the prominent sites on the black-list, but bad news for lesser known sites that rely on the trust gained by having a valid SSL certificate (small credit unions, for example).

Because they’re a good CA, the StartCom team was immediately aware of my attempt to get a certificate for Verisign. I disclosed the details of the flaw to them, and the simple problem was fixed within hours. But the question remains: did anyone else take advantage of the flaw?

PKI is not a perfect system, and there is no perfect CA. But, there are at least two types of CAs. One type treats SSL certificates as a cash cow, pushing signed certificates out the door, and counting the money. The second type is like StartCom. This second type understands that trust comes before money and that trusted CAs are a critical piece of Internet infrastructure.

-Schmoilito

(cross post on Schmoilito’s Way)

So what should happen when a CA screws up? Last summer, folks thought that the CA which issued the login.live.com certificate should have its status as a trusted CA revoked. I’m sure people feel the same way about RapidSSL. In my opinion, they are correct. However, it is clear that this could not happen, as it would effect the millions of businesses that rely on these CAs being trusted, which is what a VP at Verisign reaffirms in the comments of this post on the Breakingpoint blog.

A different question that Appelbaum asked during the presentation in Berlin, and one I’ve asked many times during my research of Certificate Authorities, is: if we were able to do this, how do we know if anybody else has done the same thing?

No one can ever give a straight answer. I’ve reported a number of flaws to CAs responsibly; flaws that can allow people to get certificates that they shouldn’t be allowed to get. The flaws get fixed, and thats great, but the damage that could have already been done is immeasurable.

It sucks when an online retailer gets hacked one or even multiple times. It’s bad for them, and it’s bad for their customers. When a trusted CA gets hacked, it sucks for the ENTIRE INTERNET. The CAs are supposed to help us secure the Internet. What does it mean if they are not secure themselves? To me, it means that we can’t rely on trusted third parties.

I know that abandoning PKI and trusted third parties is a bad idea, and probably won’t happen. However, people need to be more involved in the process of making trust decisions when communicating online. And I don’t mean little yellow locks and green address bars. I have some ideas on how to make better use of SSL in web browsers and other SSL clients. So far, I’ve gotten mixed responses to them from my peers However, with what the Sotirov/Applebaum team accomplished, maybe my ideas will make more sense. Stay tuned…

-Schmoilito

(cross post on Schmoilito’s Way)

The ‘file’ command is a nice tool. It has a database of filetypes and “magic” numbers which correspond to offsets and values within a file and are used to hazard a guess as to what type of file it is. On my system, the /usr/share/file/magic database has 13474 lines in it. Quite a bit of knowledge about filetypes at your fingertips!

To use it simply:

$ file <targetfile>

Example:

$ file /pictures/nice.jpg

/pictures/nice.jpg: JPEG image data, JFIF standard 1.02

or

$ file ./unknown

./unknown: VMS Alpha executable

What happens when dealing with “unknown” file types that may not be accurately described by the “file” command’s knowledge of filetypes? Or, what happens when a file contains many other files within it that we can easily get to? We can attempt to peer inside an unknown container file and find what types of other files it is made of… by sliding along the file and comparing every offset to the magic database.

Luckily, there is a python binding the “magic” database.

# apt-get install python-magic

And a handy example is included in /usr/share/doc/python-magic/examples/example.py.

Excellent. This is just what we need. Our algorithm is simple. Loop over each offset in the file and see what python-magic thinks it is. Interesting offsets can then be identified and extracted for further analysis.

Here’s a quick one-off python script to do just that:

-------------------------- BEGIN magicslide.py
# !/usr/bin/env python

"""

%s <filename>
<filename> will be checked at each  offset to see what the magic offset
database from the "file" command's database thinks it is.

Entries that return 'data' will be filtered because they are boring.

"""

import magic

import os

import sys

def usage():

    sys.stdout.write( __doc__ % os.path.basename(sys.argv[0]))

    sys.exit(0)

def analyze(ms,buffer):

    return ms.buffer(buffer)

def output(offset,s):

    sys.stdout.write("%08x:%s\n" % (offset,s) )

try:

    filename = sys.argv[1]

except:

    usage()

try:

    f = open(filename)

except:

    sys.stderr.write("could not open %s\n" % filename)

    sys.exit(1)

filedata = f.read()

totallen = len(filedata)

buffsize = 4096 # a nice big chunk of file

# load the magic db

ms = magic.open(magic.MAGIC_NONE)

ms.load()

for offset in range(0,totallen):

    end_offset = min(offset+buffsize+1,totallen)

    kind = analyze ( ms, filedata[offset:end_offset] )

    if kind != 'data':

        output( offset, kind )
--------------------------------------- END magicslide.py

Sample output looks like:

0001047c:Hitachi SH big-endian COFF executable, not stripped

00010493:PCX ver. 2.5 image data

000104a8:MIPSEB MIPS-III ECOFF executable not stripped - version 255.26

000104b2:\012- 8086 relocatable (Microsoft)

000104b8:PCX ver. 2.5 image data

000104bd:MPEG ADTS, layer I, v1,  32 kBits, 32 kHz, Monaural

000104c1:MPEG ADTS, layer I, v1, 448 kBits, 32 kHz, Stereo

000104c8:DBase 3 data file

000104cc:LANalyzer capture file

000104e0:PCX ver. 2.5 image data

000104e8:shell archive or script for antique kernel text

000104ef:PCX ver. 2.5 image data

000104f6:MPEG-4 LOAS

00010508:AmigaOS bitmap font

0001050c:PCX ver. 2.5 image data

00010514:shell archive or script for antique kernel text

0001051c:MIPSEB MIPS-III ECOFF executable not stripped - version 0.10

00010522:MPEG-4 LOAS

00010530:Hitachi SH big-endian COFF executable, stripped

00010538:DBase 3 data file

0001053c:PCX ver. 2.5 image data

00010544:shell archive or script for antique kernel text

00010549:MPEG ADTS, layer I, v1,  32 kBits, 32 kHz, Stereo

00010560:DBase 3 data file

Well, it’s still pretty messy and the data may be wrong, but it’s more than we had to go on before for our analysis of this unknown file type. There are obvious false positives here, but things like images such as JPGs, PNGs, etc. can probably be readily identified in the file of interest.

# aa

I’ve spoken at DefCon, BlackHat, Shmoocon, etc…. but at this conference, I wore my exhibitor badge, which might as well have read “leper”.  Hah, not that I can blame the attendees for treating me like a leper, after all, I was just another exhibitor in the gauntlet they had to run in order to get to the drinks and snacks. 

When you brave the booth gauntlet, you’re bombarded by shiny people. Appliance after appliance, magic boxes that make all your IT security problems go away.

My booth was at the end of the gauntlet. It was entertaining to watch attendees pickup my swag without missing a step, only to read the banner that says “Phish your employees” pause, double back, and curiously ask me  “what is this?”  Most would chuckle after figuring out exactly what phishme.com does. Eyes popped out of heads of the ones that actually saw the demo.

There was something about the conference and expo that REALLY bothered me……

The sad thing was these Internet terminals were in heavy use throughout the conference. Every time I walked by them people were in their email. 

-higB

Better late than never right?

Since we basically missed all of Blackhat except Schmoilito’s talk this year (hey, pool security is important too), I’ve made a list of the best Defcon talks I heard this year. To sum it up: Cable Modems, Wifi, NMAP, and Mati Aharoni.

Both Guy Martin’s and Blake Self’s talks on cable modems were eye openers. You could have probably guessed people were writing their own firmware for cable modems to unlock their full potential, but it was interesting to get the background on it and an overview of DOCSIS. Mr Martain’s presentation then showed what mass pwnage really looks like by sniffing a network at cable modem speeds using an inexpensive DVB-C card. It also wasn’t over looked that his “packet-o-matic” tool had one of the best user interfaces for any home grown tool we’ve seen in a long time. A web interface with smooth AJAX requests. Sure, GUI’s are for script kiddies, but good GUI’s are like the same reason the chicken wings at Hooters taste so much better.

In the WiFi world, Rick Farina and Thomas d’Otreppe talk was interesting especially in regards to unlocking the 4920-6100 MHz range. I’m wondering if we’ll ever see this in an assessment, but the idea of running your own home wireless network outside the range of normal prying eyes is very intriguing. The ath5k frequency patch appears to now be online. Still looking for a Wii patch to support this…

While I was in the cable modem talks, the network guys hit Fyodor NMAP talk. From the twitter comments, he rocked it with some cool new updates to NMAP and a Netcat replacement tool. I thought I had too many beers when they mentioned the Netcat replacement, but it sounds like Fyodor and team’s Ncat has a lot going for it. SSL support, port redirection, built in proxy and access control support. Definitely worth checking out.

The last thing on my highlight reel was Mati Aharoni’s “From bug to 0day” talk. Mati showed he must make one hell of a teacher in the Backtrack classes. He basically told the story of what he needed to go through to find an 0day in a client’s project. It was a great walk through of both the technical and thought process and not just a walk through of slides (don’t bother with the slides on this one, you needed to see his screen and hear him). I think Mati got everyone in the room sharing his tension and completely wrapped up in the adventure. I wanted a box of popcorn and a squeal when he was done.

DefCon badges were once again, awesome.

… I completely missed Sunday’s talks. I heard good things about Carric’s Pen-Testing presentation. I plan to catch that on the DVD.

-b3nn

Essentially, you validate the web site against what you know to be true (hostname and expected content). The browser validates that a trusted third party signed the web sites public key, and together they vouch for the sites identity by showing you a visual cue.

If the web site passes your personal validation and you decide to provide them, the application will take your credentials and validate them against what it knows to be true: a directory or other repository with user information. If it validates your credentials, it lets you in.

Dan Kaminsky’s DNS flaw makes it possible for attackers to spoof one of the three credentials web servers use to authenticate against users: the host name. The look and feel of a particular web site is already easy to spoof: phishers have been doing this for years. The only remaining credential the web server has that can’t easily be compromised is its SSL certificate, and the signature of a trusted third party (one of the commercial certifcate authorities).

Now that two of the three credentials could be spoofed, I started wondering how hard it would be to spoof the third. If you can get a valid SSL certificate, you can completely steal the identify of a web site. Unfortunately, it is not too dificult, and it is through no technical fault of the SSL protocol.

For me, it required no social engineering, no illicit hacking or ninja skills. In fact, it was kinda scary in its simplicity, and the real fault is in the process of the certificate authority (a big one). Is it that bad? I attempted to get certs for three HUGE Internet sites, and I was successful with one. An interesting application logic problem prevented me from getting another, and the certificate authority basically told me no (over the phone) for the third. The one I did get, however, is a biggie.

I’ll drop the details at the beginning of my SSL VPN talk at BlackHat next week. I won’t divulge them sooner. Not even if Matasano kidnaps me, sends me overseas, and water boards me.

-Schmoilito

If you are like me, then you remember seeing the word “linux” in the hallowed directory listings of ftp.cdrom.com circa 1994 and thinking… hey what’s this new word? A few hours/days later, after borrowing a laptop from the school A/V department, getting comfy trashing the existing operating system fdisk style and loading slackware from a lot of floppy disks, you were greeted by a fully-bootable operating system that measured its speed in BogoMips and could do most of the things the computers in the Sun lab could do  except that you were root (legitimately).

So now we’ve had Linux for a while, its used all over the place and is a system that people seem to have gotten pretty comfortable with.  This level of ease and comfort is now available in the form of “the device you take with you everywhere” …your cellphone is now just a little linux box.  Why is this cool?  Because now I can talk to my friends, and ssh into my server from my cell phone (or vice versa).  Oh yeah, and do all that other stuff that Linux does, like run Apache, FTP, NFS, torrent, or scan your systems with Nessus (theoretically).

The OpenMoko project has already suffered/gained from the normal Linux way of things and there are a few different distributions available.  Developers being the way they are have splintered off from the official OpenMoko distribution and created their own distros already.  One in particular, an “Underground” distro has even gone so far as to scrap X11 for windowing and use the framebuffer directly.  The wheel gets reinvented once again.  Hopefully this time with built-in battery powered spinners.

There are numerous ways this little toy could be used for security testers. Since it has both WiFi and can use the GSM networks (AT&T and T-Mobile work ok in the states), this would make a nice little remote access device.  All you need to do is leave it in the proximity of a location with WiFi then dial in (pppd) from across the world or anywhere cellular data connections can go (if you don’t like the idea of being in physical proximity of your targets or aren’t good at talking to beefy security guards who wonder why your laptop is beeping.) Alternatively, since it has USB, plug into a corporate computer, then dial in from the cellular side and route through newly-befriended corporate system. The possibilities here are numerous. GPS-activated, bluetooth aware, motiondetecting wifi gprs connection machine…

All in all, a cool device.  Stay tuned for fun stuff to do with it.

- theOtherAaron