Chris Paget made some news this weekend at yearly DEFCON hacker conference in Las Vegas. Paget demonstrated the flaws of the GSM cell phone protocol by creating a simple device to intercept every GSM call in a small area. Chris did a lot of work making sure that he wasn’t violating anyone’s privacy by intercepting these phone calls, up to enlisting the help of the Electronic Frontier Foundation. When reading some of Chris’ preparations, I was impressed, but the first thing that popped into my head was “Wait, that’s nice and all, but what about FCC regulations?”

To take a quick detour into FCC regulations, most unlicensed devices fall under Part 15 of the FCC rules. They have to be tested and certified by the FCC before they are marketed and sold in the United States. Whenever you see your favorite technology blog talking about how some new device is being tested by the FCC, they’re talking about this testing.

So, when Chris was explaining his presentation I figured he was going to go one of two ways: Either he was going to unveil some kind of new FCC certified cell phone interceptor (unlikely), or he was going to put on an eye patch, raise the Jolly Roger and go full pirate. However, after the presentation was done, I was reading the coverage of the presentation and saw that he did it a way that I hadn’t considered: Chris, unbeknownst to me, had an amateur radio license, so he tried to classify his transmissions under Part 97.

Part 97 is the Amateur Radio section of the FCC rules. Amateur radio is classified as an “experimental” service. As I’ve stated in my “Why you should be an Amateur” presentation, amateur radio is “radio hacking.” Chris saw that part of the European GSM band overlaps with the 33cm amateur radio band, so he (and I!) have rights to transmit there. Seems like a perfect fit, right?

Unfortunately, no. While Chris did seem to catch the “no encryption” part of the rules, he didn’t realize that his transmissions were not legal under Part 97 either for other reasons. Part 97.111 and Part 97.113 establish but “authorized” and “unauthorized” transmissions of amateur radio stations, of which Chris, by my count, violated the rules 2 or 3 different ways:

1. Chris was using his Part 97 transmitter to communicate with Part 15 devices, not other Part 97 devices. (Violates Part 97.111(a))
2. Chris’ GSM cell site was beaconing to cell phones to let them know it’s there. That counts as a way transmission. (Violates Part 97.113(b))
3. Chris was impersonating a AT&T cell phone site. You can’t impersonate people on amateur radio. (Might Violate 97.113(a)(4))

Chris does get props for establishing a Morse Code beacon to ID himself every 10 minutes as defined by the rules, however, that is like a restaurant owner trying to convince the health inspector that his restaurant is OK despite the rats and roaches because his employees wash their hands after they go to the bathroom. Too little, too late.

I’m not trying to string up Chris here, I’m honestly worried for him. He’s admitted that he’s had conversations with the FCC regarding this presentation which he classified as “unproductive”. This, combined with the fact that the FCC enforcement bureau loves to hand out documents with “Notice of Apparent Liability” at the top and five figure fines on the bottom leads me to wonder if Chris isn’t headed toward a protracted legal battle with the Feds. Chris’ presentation shows a major shortcoming with the current FCC rules dealing with research. Chris should not have tried to find a loophole within the FCC regulations to do his research, it should have been legal for him to establish a low powered signal to do and demonstrate his research. We, as researchers, are running into another version of the same ostrich syndrome that prohibited users from listening to cell phone and pager traffic that were transmitted in-the-clear back in the early 1990s, and to a lesser extent, still are. With the expansion of data networks to mobile devices, it’s become even worse, as Chris’ presentation demonstrated. By not allowing research into these fields the FCC is keeping the sunlight out of the dark corners of our mobile networks and allowing the mobile phone companies to convince us that everything is OK when in reality someone with $1500 worth of equipment can intercept local mobile phone traffic is negligent at best, and criminal at worst.

While I disagree with Chris’ characterization of his transmissions being “cool” because he’s licensed as an amateur radio operator, I fully support his research and his efforts to do this research in a controlled environment. I also hope that the FCC will realize that this type of research only helps people and all the laws in the world won’t help bad people from doing this same type of activity in a malicious manner, as they already are.

• Locational Privacy and Wholesale Surveillance via Photo Services (Friday, July 16th, 11:00AM EDT in the Lovelace Room)
• Why You Should Be an Amateur (Saturday, July 17th, 6:00PM EDT in the Bell Room)

Talk slide decks should be posted up here and at Mayhemic Labs after the talks.

Hope to see you there!

First off, QuahogCon was a blast. My presentation went rather well, despite some technical difficulties with the lack of Internet access and the fact that I was not able to raise the local IRLP repeater from inside the building. I’ve started tweaking it a bit and submitted an abstract to The Next HOPE‘s CFP.

You can download the QuahogCon version of the slide deck here:

• Why you should be an Amateur PPT (8.0MB)
• Why you should be an Amateur PDF (7.0MB)

Also, available over at QuahogCon’s site is the audio of the presentation.

Next, over the past month, I re-launched Mayhemic Labs a group of very talented folks. We have started doing a few projects, the coolest one (in my not so humble opinion) is ICanStalkU, a site that rips through public photo sites looking for latitude and longitude EXIF tags. You can read more about the project at the site’s how and why pages.

So, despite the lack of activity on here, I have been keeping busy. Of course, I am always mumbling to myself on Twitter.

My comments on FCC Docket 10-62

Share and Enjoy!

My comments on FCC Docket 10-72

Let us see what happens…

After putting him to bed and discussing it with my wife, I started weighing my options to figure out a way to allow me to work near my family, make my own hours, and hopefully live comfortably. After thinking about it more and more, I came to the realization that InfoSec lifestyle wasn’t cutting it anymore and that I was essentially fighting a losing battle. I’ve always been a bit of a chaotic neutral person and thusly I came to the conclusion that the best way to get what I want is to switch sides and move over to the darker realms of the Internet. As in my old job I monitored them daily, it was easy to reach out to my former adversaries and start inquiring about positions within their organization. They were very receptive and were happy to get someone with my portfolio, so I was able to negotiate a tidy signing bonus as long as relocation costs.

Yes, you read that right, relocation. We are all moving to Estonia. This may seem like a big move, but I have always wanted to set out and blaze a new trail beyond my comfort zone, so this was right up my alley. With Brady just picking up Portuguese and English, adding Estonian on top of that will do wonders for his development. Finding a new house would be a worry, but thankfully Peeter, my new boss, has an associate, Mikhail, that was able to get me a a killer deal on some waterfront property in Hiiumaa. He was even able to get the seller to go way below their asking price! Plus, they have a very decentralized structure are fans of working from home, so I should be able to get away with only showing up to meetings a couple times a month off-island. This is an ideal situation and everyone in the Jackson household is excited.

I know this might come to a shock to some of my InfoSec friends and it may seem like I’m abandoning them for “the other team” — and I’m sorry if you feel this way. This was the best option available to me to continue working in the field I love that will allow me to be close to my family. I sincerely hope that despite now me being an adversary, we can still remain cordial and reasonable to each other and can remain friends. Of course, trusted friends should feel free to contact me if you are interested in joining me on this great adventure, as we are currently looking for people who have experience in the field and like to work in the trenches.

I’ll be chronicling the move and the adventure of emigrating int he upcoming weeks, this should be interesting on so many levels. I need to start researching how one gets an Amateur Radio license in Estonia.

• zeusdnsscrape.pl – v0.3.4

All of the old flags should continue to work, and most of the changes are under the hood. There is, however, one major bug that was squashed: apparently the old version would never update the local copy of the ZeuS domain block list, even when it was supposed to. So, I would highly recommend everyone use this newer version. The big feature that has been added in this script is the ability to limit the rate of queries being fed to the DNS server. When I was running v0.3, I would occasionally run into problems where the script would stall for a bit, presumably when the DNS server didn’t respond fast enough. Worried that the sheer amount of queries may be overwhelming the server and also trying to make this as low-impact as possible for folks to run, I added he –rate flag in which you can specify how many queries per second the script should send.

So, if you wanted to run it at 30 queries per second:

perl zeusdnsscraper.pl --server 192.168.1.2 --server 192.168.1.3 --rate 30

If no rate is specified, the script currently defaults at 25 queries per second, which (I assume) most normal DNS servers should be able to easily handle without breaking a sweat.

Also, this might probably the last version of this tool in it current form. I currently have a new and improved version baking in the oven that expands the capabilities and dataset of the tool. I hope to have this out and released within the next week or so.

Allow me to introduce you to two script kiddies: David Kernell and Michael Mooney. One of which is currently on trial for accessing computers in an unauthorized manner, the other is currently scott free for doing the same. Why is one being prosecuted for his crimes while the other is not? I think it’s a symptom of a larger problem in the legal system in the United States.

First off, a little background: In 2008, David Kernell aka “rubico” correctly guessed then Alaskan Governor Sarah Palin’s password reset question on her Yahoo mail account using public information sources such as Wikipedia. Kernell then proceeded to post the screenshots and other bits of information found in the account in a public forum on the Internet. A few months later, Michael Mooney aka “Mikeyy” found a security hole in the Twitter service which allowed a user to post Javascript in their “Bio” section. Mooney then decided that instead of doing the responsible thing and reporting this to Twitter, he should instead use the hole to hijack people’s Twitter account to at first promote a site he ran, then to sing his praises. You may remember me writing an article about what unfolded next, but that’s another discussion entirely.

Now, today, Kernell is currently awaiting trial for his crimes in a Federal court in Knoxville. Mooney would have long faded into obscurity in my mind, but he decided to do some Google vanity searches on himself, came across my article, and decided to convince himself that I was somehow jealous of his… hmm… nope, not sure on that one, but anyway… After telling him in no uncertain terms about what I thought of him, we got in a classic Internet argument.

After dealing with his inane ramblings and him trying trying to convince me that despite him admitting what he did broke the law what he did wasn’t illegal (Obviously, Mooney retained Erwin Schrödinger as counsel), I got to wondering why is Mooney free to drink Martinis, watch the sun rise, and fancy himself as some kind of security consultant, while Kernell is currently staring down a sentence in FPMITA prison? I understand that the Feds don’t have the time and inclination to investigate every little event, but the facts that Mooney admitted to doing it, his information is publicly available (Heck! Check his Twitter stream or his website and find his mobile number!), and that he’s admitted to breaking the law, the Feds are saying that while it’s not OK to break into a Vice Presidential candidate’s e-mail, you can hijack thousands of user’s computers to promote your website and get away with it, provided you don’t  do anything really nasty.

Something that has always concerned me is the selective prosecution of one computer crime and not of another. As someone who deals with the endless streams of attacks and scans coming down the SuperInfoBahn, “getting the bad guys” is a all too infrequent event. When incidents like the Mikeyy worm go un-prosecuted I feel that we are continuing to send the message to people that compromising a computer, website, or whatever, is fine provided that, you know, don’t do anything really bad, whatever that means. I think we’re essentially already looking at the Fixing Broken Windows theory at work: we’re not going after the crimes when their small, and thus, we’re continuing to see problems escalate. While I’m not suggesting that if we go after the small crimes we’ll see ZeuS drop off the face of the planet next week, it might start to take a bite out of younger people trying to compromise each other via Rouge Neopets Paintbrush Generators.

I don’t know how it’s come to be that Kernell is being prosecuted while Mooney is not, I’m sure going after such a high profile target under USSS protection definitely made it hard for Kernell to slide back into obscurity. I’m not suggesting that Kernell be let off  the hook for his crimes, but, I don’t think anyone can disagree that it’s fair that Mooney isn’t being held responsible for his crimes, while Kernell is.

As some of you may know, I wear an Incident Response hat within my organization. As I like to be proactive and actively search for issues rather then just be an IDS alert monkey, I love pages like the Malware Domain List, the ZeuS Tracker, and malwareurl.com. While these are great resources, it is a bit difficult attempting to take the lists and apply them to the environment; most of their usefulness comes from when you have a questionable URL and need to see if someone else has reported it as a bad site. A great service, but not proactive.

While staring at the ZeuS Tracker Domain Block list and trying my usual method of snipe hunting manually entering domains to query the firewalls, a moment of inspiration hit: I don’t care about all the domains, just the domains that people visit. Who knows what domains people visit? The DNS servers! Now it was just a question of trying to coax the information out of the DNS servers. Thankfully, PaulDotCom Security Weekly came to the rescue: They have been talking about getting information out of DNS servers during penetration tests and a simple non-recursive DNS lookup on the local DNS server can tell you if someone queried for the host recently. A couple of quick experiments to verify this fact on my work’s main DNS servers confirmed this fact, and I set to work.

My first attempt was a simple script to take a pre-chewed version of the ZeuS Domain list, feed it through dig and pipe the output through grep. It worked, but I wanted something a touch more automated. Over the next couple of nights on the train, I whipped up a tool to automate the process a little more. The resulting tool is the ZeuS DNS Scraper. It’s a simple script written in Perl and should work straight out of the box with the default modules included in a Perl distribution.

Running the Script

Running the tool is fairly simple, there are only 4 options: –server, specifying which server(s) to query, –file, specifying where to put the downloaded ZeuS Tracker block list (defaulting to /tmp/ztbl.txt) , –download/–nodownload which specifies whether or not the script should attempt to download the block list, and –debug, which specifies the verbosity of the script.

A typical command line would be:

perl zeusdnsscraper.pl --server 192.168.1.2 --server 192.168.1.3

Which would download the block list, and then proceed to query 192.168.1.2 and 192.168.1.3 for each entry in the block list. You can specify as many as many servers as you like, however, the block list often hovers around a thousand entries, so each additional server adds another thousand or so queries.

Alternatively, once the list is downloaded, the script will download the block list only if the local copy is older then 60 minutes, (don’t worry it doesn’t update that frequently). You can also specify that the script doesn’t download the list again with the –nodownload option:

perl zeusdnsscraper.pl --server 192.168.1.2 --server 192.168.1.3 --nodownload

You can also turn on debugging with the debug option, which will display every step in the process:

perl zeusdnsscraper.pl --server 192.168.1.2 --server 192.168.1.3 --debug

Interpreting Results

When the script is run in default mode, a ‘.’ will appear after each query, while in debug mode it will display the result of the query and whether or not it found an entry.

What You Want To See

Completed!
NNNN queries made, 0 entries found! Hooray!

In this example, NNNN would be the number of queries sent, remember this increases which each additional server you need to query, and it has found 0 entries, indicating that the DNS servers queried have no cached entries for any of the domains. Congratulations, pat yourself on the back and grab yourself a nice frosty beverage from the refrigerator.

What You Do Not Want To See

NNNN queries made, 4 entries found. Uh Oh.
W.X.Y.Z has an entry in it's cache for www.example.net: 10.1.2.3
W.X.Y.Z has an entry in it's cache for www.example.net: 10.1.2.4
W.X.Y.Z has an entry in it's cache for www.example.com: 10.4.5.6
W.X.Y.Z has an entry in it's cache for www.example.org: 10.7.8.9

Well, crap. This time the beverage you need is probably kept in your attrition.org flask. NNNN is the number of queries the script made and the “4″ in this example is number of results found. In this example, “www.example.net” was cached with two separate addresses, while “www.example.com” and “www.example.org” both have one apiece. The W.X.Y.Z in the above example is the DNS server that responded, and the 10.X.X.X addresses are the IP addresses that the DNS server responded with. These IP addresses are what you are interested in.

My DNS Servers Have Cached Entries! Now What?

This is where some good old detective work comes in. The presence of the cached entries on your DNS server only means that one of the clients on your network asked for the entry in question. Normally, it’s time to start plugging IP addresses in your firewall logs to see who’s been visiting them. Then it’s time to start cleaning.

Caveats

Now, obviously, this sends a boat load of queries in a very rapid fashion to DNS servers. Make sure that your DNS server and your connection can handle the load and don’t run it against DNS servers that you do not have permission to do so. Also, some of the DNS entries have small enough TTLs that they may expire quickly, meaning that even if the script comes back clean, there could still be infected hosts.

Thanks

I’d just like to say a big thanks to the folks over at abuse.ch for hosting the ZeuS Tracker. It’s a handy tool and it’s invaluable if you’re running even a moderately sized network.

ZeuS DNS Scraper