Archive for the 'Security' Category
Black Hat 2008 & DEFCON 16
Back story
By some unexpected fortune last week I found myself in Las Vegas attending Black Hat & Defcon. Apparently there was some attempt by the heads of my office to get clearance from E&Y so that I could go, but that didn’t work out with me being an intern. I was notified about a week before Black Hat that someone was suddenly unable to go and now there was an extra ticket so I would need to make travel plans.
Cut to Monday morning; I roll out of bed at about 4:30am. After showering and throwing clothes on, I’m ready to be picked up at 5:00 to get to Newark airport for my 7:50 flight. I get a call around 5:05: the driver of my car has two flat tires, but they’re going to try to find another car in the area. The minutes crawl by until around 6:00 I get another call from the driver saying that he’s on his way. Since it takes about an hour to get to Newark airport, I narrowly made it through security in time. If the plane wasn’t slightly delayed, this trip would have started off very poorly.
We spend Monday in Houston for our ‘all-hands’ meeting with the Houston team, where many people on the team give presentations on various security-related topics. Because the hurricane was coming we decided to all catch a late flight Monday night to Las Vegas. By this time I was beat, so I checked into the hotel and went to sleep.
Spent Tuesday hanging out – later that night I gambled at a casino for the first time playing blackjack (more on that later).
Black Hat: Day One
Wednesday was the first day of Blackhat which started off with a keynote speech by Ian O. Angell about how complexity in information systems leads to increased risk. He made numerous mentions of how combining human systems with technology systems is disasertous but while eloquent in his speech, I largely disagreed with his opinion. He mentioned in one portion of his speech that we have a desire to categorize things and seemed to insinuate that this is a bad thing. This is, however, how the human brain operates which leads me to believe that it is an efficient way of interpreting reality. Yes, it may not be proper in all possible scenarios, but what is? Overall, he seemed to resent technology which made me resent his keynote.
Later I went to Dan Kaminsky’s talk on the new DNS cache poisoning attack. I had already heard about the details of the attack, but at Black Hat he went over the extent of the damage that could be caused by this attack: just about everything. Originally one of my co-workers mentioned that for anything important, such as your bank’s website, you’ll see a signed SSL certificate ensuring that the website is legit. However, Kaminsky pointed out that Certificate Authorities validate certificate purchases by way of email. So if I control the DNS entry for goodbank.com, I’ll get the mail to anyone@goodbank.com. When I get an email from the CA for my newly-signed SSL cert – bam! You think you’re at goodbank.com, you see a signed SSL certificate, but its all controlled by evil Eve. Pretty cool attack.
A cool but low-profile talk I saw was entitled ‘Return-Oriented Programming: Exploits Without Code Injection’ by Hovav Shacham. Intrigued by the title, I went to the talk and discovered how the author came up with a system for injecting not code, but instead injecting pointers to areas of memory which contained libc functions that when executed contiguously would exhibit malicious behavior. While no evil code was injected, evil behavior would be executed. He even showed how he could run a sort in a vulnerable program by injecting pointers to libc which was pretty cool.
Finally I went to a talk on how implantable medical devices have virtually no security due to battery constraints.
Black Hat: Day Two
On day two, one of the guys from the Houston office was giving a talk on ‘extreme client side exploitation’. Basically, the talk was about how the Same Origin Policy is flawed and how to exploit it using GIFARS. GIFAR is a term which comes from a file which combines a GIF and a JAR together such that the resulting file is a valid GIF and JAR (this is possible due to the way each of these files are parsed; GIFs from the top-down, and JARs from the bottom-up). On sites which you can upload your own images (facebook, myspace, flickr, etc.), you can upload a GIFAR which will live on the website’s server. By getting a user to view a webpage which has an <applet> tag that points to the GIFAR, the attacker can gain access to the private information of the user on that website.
There were some other cool talks but I think my favorite was the Quantum Spookshow. During the conference they had a room with two quantum key distribution setups inside. One setup had a web cam at one end which was sending the encrypted stream via a network connection. At the same time the cryptographic key is transmitted via photons. The receiver is able to determine if the photon transmission has been intercepted and retransmitted or not by the principals of quantum mechanics. The other setup uses quantum entanglement to transmit the key, but has high bandwidth constraints. However, it has the advantage of having a truly random key.
Defcon: Day One
Defcon was a much more relaxed conference and filled with all kinds of cool stuff. The badges for the conference were actually a device that you could connect an SD card to and transfer files to other badges via infrared. They also had a lot of physical security talks which Black Hat didn’t have. My favorite talk from Defcon was entitled, “Advanced Physical Attacks” by Eric Schmiedl and covered a wide range of topics. First the talk was about spies and how the CIA and other agencies recruit them. One of my favorite parts of the talk was how you can listen to the sound of someone typing, and determine what keys they were pressing.
I ended the day at Defcon by buying some cool merch and playing about three hours of Guitar Hero with some other cool geeks. Unfortunately I only got to stay for the first day of Defcon, but the whole trip was outrageously fun.
No commentsSecurID
Recently, a SecurID came under my acquisition. For those unfamiliar, SecurID is a small device that fits on any key chain and displays a six digit number that changes once per minute. The six digit number it displays is based on a seed number that is created when the device is deployed and known only by the device (hopefully) and the party deploying the technology. The deploying party then keeps a big database of each person’s user name, SecurID serial number, SecurID seed number, and SecurID pin, which can be modified via an 800 number. When you want to authenticate to certain services, you provide your pin number, followed by the currently displayed six digit number on the SecurID. The authenticating party then uses the seed to calculate the number that should be on the SecurID at that time and compares it to the PIN and SecurID number you submit.
By doing this you are (theoretically) proving to the authenticating party that you are who you claim to be with two factors of authentication: something you know (your PIN) and something you have (your SecurID). This makes it more secure than only a single factor of authentication, such as a password. Since the SecurID is physical, a hacker would need to steal or tamper with the device to beat the additional authentication method.
In this case, however, the line between something you have and something you know is, in my opinion, a bit blurry. Because the device holds some information that makes it unique – it’s random seed – one could extract this information from the device where it can be emulated in software. Fortunately for SecurID, it’s never connected to a computer, ensuring that an attacker must have physical access to bypass this security measure. (There is however, the issue of the seed being stored in the authenticating server, which is a potential target of attack)
But once an attacker does get physical access, there is little stopping him, in my opinion, from fraudulently authenticating himself. Let’s say, for example, that an attacker acquires another user’s SecurID and username. If the deploying party requires a four digit PIN then there are 10,000 possible codes that can be entered. Lets assume that the deploying party has only allowed one incorrect login per generation cycle. This means that to brute force the PIN number, the maximum amount of time it would take is 10,000 minutes. 10,000 minutes * 1 hour / 60 minutes = 166.7 hours. 166.7 hours * 1 day / 24 hours = 6.94 days. Which means that at most you would need to wait for a week to successfully brute force a SecurID login, assuming you have the device and username with a one minute code generation interval on the device.
But what if I have to enter a six digit PIN? That’s 1,000,000 possible combinations. 1,000,000 minutes * 1 hour / 60 minutes = 16,666.7 hours. 16,666.7 * 1 day / 24 hours = 694.4 days. Hmm, that’s much better. However, the longer you make the required PIN, the harder time the average user is going to have trying to remember it. It’s also been shown that people remember words better than remember a string of numbers, which is why I think SecurID should use passwords rather than a PIN. However, the more characters that need to be entered during authentication, the more time an average user needs to input this information, so there’s a balance that needs to be achieved. Four digit PINs are good because it’s the same size as a bank PIN, and similar brute force deterrent mechanisms can be used, such as disabling login after n failed attempts.
It’s not that I think SecurID is a bad technology; quite the opposite. Instead, I think that ‘something you have’ is almost invariably ‘something you know’ (whether you know it, or the device does, it’s somewhere). This also goes for the third factor of authentication, which is ‘something you are’. What is a thumb print but information? (And something you are is immutable – if someone makes a copy of your thumb print and masquerades as you, what are you going to do? Get a new thumb print?)
That said, I think SecurID is a great technology with a slim chance of being exploited. RSA did a good job of making it unable to be connected to a computer, which eliminates the possibility of being able to remotely discover the device’s seed number.
3 commentsSISMAT
So I recently finished a two week long program at Dartmouth called SISMAT (Secure Information Systems Mentoring and Training) where I learned about a plethora of computer security related topics. Overall I had a really great time and met some really cool people. Each day was structured with two lectures in the morning and one or two labs in the afternoon. The topics presented included web vulnerabilities, software vulnerabilities, sniffing/network analysis, ethics in computer security, and public key infrastructure. Going in I wasn’t expecting my Linux skills to improve, but they did with all the labs and the RTFM mentality of the instructors (and I mean that in a good way).
Starting tomorrow I begin part two of SISMAT; that is, I start my first day at my internship at Ernst & Young in New York City. I’m both excited and nervous to be working at the Advanced Security Center, although I think most of the nervousness is due to my unfamiliarity with New York city. I am, however, looking forward to learning during the month I will be interning since I have had plenty of experience developing web apps for The College.
No comments