Latest posts.

Let’s not back the bus over the Target SOC… Yet…

Bloomberg Businessweek released a story today regarding the Target breach that stated Target received not one, but two alerts regarding the malware on their network that sent 40 millions credit cards and 70 million records of customer data into the greedy hands of criminals. Now, coming from a blue team background, this scenario happening on my $DAYJOB’s network keeps me up at night. One of my greatest worries is that I’m missing some kind of chain of events that I’m not piecing together while some ankle biter runs rampant over my work’s systems. It keeps me, and any other defender worth their salt, always looking over their shoulder and through their logs.

That being said, the article makes it sounds like these alerts were gift wrapped, tied with a bow, and adorned with a sign that said THIS IS GOING TO STEAL CREDIT CARDS surrounded by blinking LEDs. Anyone who has worked in a SOC or in an analyst position knows that this never the case. Starting from an event and working backwards to pick out from the noise the bits of applicable data that pointed to the event is trivial, trying to pick out data and see a pattern that points to an event on the horizon is much, much harder.

We’ve seen this kind of analysis before: Anyone who has read into military intelligence failures such as the September 11th or Pearl Harbor attacks, knows that there was a chain of events that when pieced together makes it obvious to any casual observer that the events were going to take place and if someone had simply acted, these tragedies would have been prevented. What the casual observer doesn’t realize is that while yes, the information was there, it likely was fragmented, incomplete, and most importantly, competing with many other bits of data that point to something else or nothing at all. The ability to take this data and form an accurate prediction about future events that allows someone to act takes skill, luck, and a bit of hubris.

I’m not saying Target has clean hands on this, they got their ass kicked, their security team failed, and anyone who saw that report and dismissed it or waffled on it knows that they had a hand in every bit of fraud that occurred due to those stolen records. But, I think it’s important to ask some questions before we condemn them as heavily as Bloomberg does:

  • About that “team of security specialists in Bangalore”:
    • What was their false positive rate?
    • What was their false negative rate?
    • How trained were they?
    • How many alerts did they escalate on a daily basis?
  • Regarding FireEye:
    • How trained were the SOC staff on analysis of FireEye reports?
    • How trained were the SOC staff on malware analysis in general?
    • What was the false positive rate of the FireEye device?
  • Regarding the SOC in general:
    • Was there a defined process for malware remediation?
    • How many alerts did the SOC staff deal with on a daily basis?
    • Did SOC staff have a ability to pull  the fire alarm?

The article from Bloomberg reads great, but it’s important to remember it’s not a detailed analysis report. Sadly, with the current state of affairs in information sharing, we’ll likely never know exactly what happened at Target during those fateful weeks, but if we don’t know, we really can’t judge.

2014 Technology Goals

So, @kylemaxwell posted his 2014 Tech Goals on Twitter the other day and it was a refreshing change from the seemingly endless noise of “2014 prediction” articles that every company and their brother seem to post as the year changes. It was different, and it was a good idea. So, like every good idea I see, I’ve decided to rip it off. When I started thinking about it, I came up with a few goals for 2014:

  1. Finish my ever lengthening list of half baked projects – I like to code things. I enjoy making tools that someone might find useful. However, I have a habit of getting the tools 75%-80% done, declaring it “good enough” and letting it sit there gathering dust. I have approximately three interesting tools that are currently sitting in this state and I need to sit down and finish them.
  2. Examine and update all my existing tools – I also have a problem in which once I send something out the door, it no longer gets worked on, so another goal this year is to go through all my existing projects and tools, examine them, and either update them or retire them.
  3. Work on some hardware projects – I always want to seem to do this but I never have the wherewithal to do this. I hope that actually putting this out in public will motivate me to do so. I’ve recently been enamored with all the fun “home automation” tools out there but shy away from them due to the idea of having my house be controlled from da cloud. Some projects have been rattling around in my head to replicate some of the features I think are cool without the pesky security and privacy concerns.
  4. Become active in Ham Radio again – In early 2012, I got fed up with some of the cliques in the local hobby groups and simultaneously lost my ability to have a radio in my car (where most of my operating was done). I’ve been recently started getting the itch to get back in the hobby and I need to scratch it.
  5. Write more articles – This site has been inactive for years. I want to try to get an article written, either here or on Mayhemic Labs, every other week. (This one counts as #1!)

My boss at work always reminds me to set some “stretch goals”, which are nearly impossible to achieve, sooooo…

  1. Develop more “outside of the box” ideas for Blue Teaming/CND - I really enjoyed writing my SANS paper and this seems to be a topic garnishing more and more interest, so I think working on this is a laudable goal.
  2. Break out of the “Infosec Echo Chamber” – I often try to “put my money where my mouth is” when I say I want things to change. Unfortunately, like a lot of introverts, I enjoy staying behind my keyboard and arguing about things on Twitter. I want to start engaging non-security people about security issues.
  3. Become more engaged in InfoSec meatspace activities – I left the Boston area in 2011 and I’m now local to Providence. This unfortunately cut off my access to MassHackers and BeanSec. I need to locate and become more active in the local Providence Technology and InfoSec activities.

Here we go…

Chris Paget, Part 97, Part 15, and RF Research

It has finally happened. I can finally write a blog post about my two favorite subjects: Information Security and Ham Radio.

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.

Presenting at The Next HOPE

A bit late notice, but I will be presenting not one, but two talks at The Next HOPE next week at the Hotel Pennsylvania in New York City.

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

Hope to see you there!

Where the hell have I been?

Been quiet over here recently, but I’ve been busy in other areas, so let’s do a quick update of what the hell has been going on:

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 the proposed changes to FCC Part 97.313

Since I already did my civic duty and submitted my comments on the NPRM for 97.113 and my all official-looking Word file was just sitting there, I went ahead and submitted my comments on the proposed amendments to the spread spectrum regulations which would limit the maximum power to 10 watts in exchange for elimination of the requirement for automatic power control. While I like the idea of eliminating the APC requirement I think the restriction to 10 watts is a bit overkill. I suggested that they increase the limit to 25 watts, as that would give amateurs a good amount of wattage to play with and still would still be 25% of what is currently allowed, mitigating interference concerns from Wireless ISPs.

My comments on FCC Docket 10-62

Brand spanking new DNS cache scraping tool

I mentioned in a previous post that the ZeuS scraper was more or less going to be kept in it’s then-current form while I work on a new and improved version, and I’m happy to say that it’s just been released with an expanded array of hosts to check as well.

Share and Enjoy!

My comments on the proposed change to FCC Part 97.113

The FCC has submitted a notice of proposed rule making (NPRM) to attempt to create an exception in the Part 97 rules to allow hams to participate in disaster drills on behalf of their employer. Currently, for amateurs to participate in drills on behalf of a government agency, the agency must submit a waiver to the FCC for permission. Now, I have said before that I’m a fan of the waiver process and I think that it has its place. However, I feel that giving blanket immunity to such things is not a good idea. I think I’m very much in the minority in this opinion, but after reading the comments submitted by Mark, K6HX, I felt my Quixote-esque ability to tilt at windmills stir, so I went ahead and submitted my own.

My comments on FCC Docket 10-72

Let us see what happens…

Big career changes ahead — Goodbye InfoSec.

As some of you know, Brady has recently celebrated his 1st birthday. It’s been a long year and as it’s worn on, my commute (two hours each way end to end) has often left me frustrated due to the lack of time with my son. More and more often, I have wondered, despite loving my current job and the people that I work with, if it was worth the time it was taking away from my family. Yesterday, as I had to telecommute due to the epic flooding that shut down Route 140 I was able to play with my son before getting him ready for bed. It was during this I had a moment of clarity: It wasn’t worth it.

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.

More Malware DNS Cache Scraping

There has been some impressive hoopla over the ZeuS DNS scraper I posted last week. There’s been even more chatter then I expected. I’ve received nothing but good feedback and have even gotten tweeted by Mikko Hyppönen and Lenny Zeltser, two people I have immense respect for. Anyway, I have continued messing around with the script, found and squashed a few bugs, and added a few features. So, now, I am releasing:

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.