Testing NFC Input Vectors

Apr 30 2013

Can we agree that NFC is here to stay? Just about every mobile platform supports it, (I’m looking at you Apple) including simple feature phones from way back when . Let me just get to the good part: NFC input vectors for pen-testing. The scenario here is a mobile application that supports some kind of NFC exchange. Maybe it’s a Windows Phone 8 tag reader or something using Android Beam — whatever. The point is that the mobile app is receiving input from an outside source (the NFC tag), and we want to make sure it’s properly validating that input. Specifically, when an application reads in the NDEF (or proprietary) content from the NFC tag, how is it used by the application? What happens when we change this value to something unexpected? In an ideal world, it will catch the exception and stop trying to read the tag, but what about in the case of “less than ideal” programming.

Tools

To get started we need something that can read and write NFC tags. Sorry, iPhone users, but the easiest way to do this as I see it is to use an Android device and a few choice apps:

NXP NFC TagInfo

Does exactly what its name implies. It gives you info on an NFC tag. This includes any kind of ASCII characters inside of the NDEF storage container or a hex representation of the values if that’s your thing. This is step 1 when it comes to learning about the content that’s on an NFC tag. Play store link.

NXP NFC Tag Writer

NXP’s tag writer will read, write, and copy tags. When I say copy, I mean it will copy the NDEF format. That’s the content that’s normally on an NFC tag. Hard coded values like the UID can’t be changed (unless you know where to get sketchy NFC tags and even then you need a libNFC-based tool to interface with it). Play store link.

NFC Developer

This is where the fun happens. This app allows you to design just about any NDEF formatted NFC tag you want. The nice part of this is if there is an application implementing a weird custom format, you can create it. It’s made by Thomas Skjolberg who apparently has a whole workshop on the subject that gets you started with NFC on Android.

Used in partnership with the ndefeditor.com site, the app lets you generate just about any NFC tag you can think of and then record it to a tag. Or you can use the Eclipse Plugin  that does the same thing inside of Eclipse. Very useful.

Create a new tag in Eclipse by going to New>Other>NDEF File

blog1

Fill the file with whatever contents you want or whatever the application can handle. This may be a specific MIME type like below or a Android Application Resource (AAR)… or many other things for that matter.
blog5

 

Once you’re done, it’ll create a QR code for you that you can scan with the NFC Developer application installed on your device.
blog3

You’ll now be able to load your custom NDEF message onto an NFC tag of your choice.

Link

Tags

If you’re using Android, you don’t necessarily need to write your content to physical tags. It’s possible to manually create intents that look like the device is receiving an NFC tag. But since we’re talking about testing any NFC function on *any* platform, you’ll need to pick up some NFC tags. The NFC protocol itself supports a “card emulation” mode where you could theoretically turn your Android phone into a simple NFC tag, but from what I understand, it’s either extremely hard to do or impossible right now because it’s based on the NFC secure element that is manufacturer specific. If someone wants to enlighten me on that, please feel free.

You’ll want a variety of tag types. The main difference you’ll be concerned about here is just the amount of storage. The Mifare 4K have a reasonably large storage capacity and can still deliver the data in the same way that a Mifare Classic (1K). Maybe there’s a situation where you’ll need a special tag type but I haven’t run into that yet. Either way, here’s a random link to some tags. 

Bad Code:

Lets take a look at some example code for Android that we’re trying to exploit. This is a portion of code that is reading an NFC tag, and saving to a file name based on that input. You can see that the value of “strfile1″ is whatever the first NDEF record is. What happens if that payload was something like “../databases/superimportantcontent.db”.  Even worse, the app looks at the second value of the NDEF record for the content to write to.

Lets imagine that this app stores a textfile of SSH hosts to connect to. In this case, we could create a custom NFC tag that would have a first record of the path we want to access (“SSH.txt”) and the second record would be the values to put inside of this file (your malicious SSH MiTM proxy). Having a user read your custom tag would redirect their connections to you.

Happy hacking.

 

Malicious Exit Nodes: Judge Dredd or Anarchy?

Mar 29 2013

InspecTor is a .onion page that kept track of bad exit nodes on the network. And it did a pretty good job. It looked for things like:

  • SSL Stripping: Replacing HTTPS links with HTTP
  • JavaScript injection
  • iFrame injection
  • Exit nodes that have no exit policy (black holes)

Those are the easy to quantify bad properties. We can compare the results of connecting to a bad Exit Node and a good one and diff the results. These are some of the grey areas it also tries to look for:

  • Warning about similar nodes in the same netblock
  • Watch for similar named nodes spinning up hundreds of instances
  • Look at the names of the nodes and conclude that they’re bad (e.g. NSAFortMeade)

The worst case scenario for a service like this, is that first, they’re wrong and kick off a perfectly good Exit Node. Second, they make users use custom routes to evade the bad nodes. Doing so means that your network traffic has a fingerprint. “He’s the guy that never users Iranian exits” for example.

And that’s kind of what happened with InspecTor – now celebrating the anniversary of it’s retirement a year ago. He went Judge Dredd on Tor and started making broad conclusions on what nodes were evil. For example, he said that NSAFortMeade is obviously an Exit Node owned by the NSA assumedly to catch the traffic of Americans (because they can’t do that already?). Other conclusions stated that a family of Tor nodes were from Washington DC. One of them was malicious so the conclusion was that it was probably the Government keeping an eye on us.

Tor’s Controls

What does Tor have as a control mechanism if they do somehow come across a bad exit node? The protocol has a “bad-exit” flag in it so that authorities can let Tor users that this Exit-Node should be avoided. That flag is set by The Tor Project admins as far as I know and you have to be blatantly offensive to cause this to happen. Here is the _total_ list  of nodes that are blocked today:

agitator agitator.towiski.de [188.40.77.107] Directory Server Guard Server
Unnamed vz14796.eurodir.ru [46.30.42.154] Exit Server Guard Server
Unnamed vz14794.eurodir.ru [46.30.42.152] Exit Server Tor 0.2.3.25 on Linux
Unnamed vz14795.eurodir.ru [46.30.42.153] Exit Server Guard Server

http://torstatus.blutmagie.de/index.php?SR=FBadExit&SO=Desc

This says that there are four bad nodes (one’s a bad directory server) on the network right now. I think most people would agree that is a bit low. You can take a look at this link for a complete list of the nodes they’ve blocked in the past. You should notice that a bad-exit flag doesn’t kick them off the network, it just tells the client to never use them as an exit. So these nodes can stay online as long as they want but they’ll never be used.

The Point

The point is not to just say everything sucks. How Tor isn’t doing a good job at monitoring for Exit Nodes or how InspecTor was doing too good of a job for it’s own good. It’s to highlight the real-world problem in Tor. Unlike the sexy theoretical attacks we like to wrap our heads around like global adversaries correlating your traffic back to an individual IP by statistically analyzing your web history patterns, the most likely thing to happen to you is that some douche nuckle is running dsniff and ulogd. And the point is also to highlight a need for a replacement of Snakes On A Tor. You can tell by it’s name, it’s a bit outdated. That is something actively being worked on but it may be a while before something reliable comes out of it.

 

ISTS X

Mar 25 2013

Another year, another ISTS. For those that haven’t heard the Information Security Talent Search (ISTS) is a yearly event run by RIT’s SPARSA group — a student run organization. This isn’t your run-of-the-mill hacking competition. ISTS was one of the first (if not the first) to actually bring an offensive perspective to the competition.

Here’s your job:

  1. Keep your services running – the longer they are up, the more points you get
  2. Stop your opponents from running services. Hack, exploit, social engineer, whatever.. make their boxes go down.
  3. Complete the business injects that are given throughout the day
  4. Complete the various challenges faster than your opponents

Sounds simple right?

Setup

As always, SPARSA worked hard to get the system up and working by opening hours. And as always, that didn’t necessarily work out. But to be fair, to configure the competition the way it needed to be was not a simple task.

Last year we had a power outage in the opening minutes of the competition, this year, we had some networking issues that delayed us about an hour and half. Minus a few other issues like the Red Team didn’t have enough networking equipment to begin, we were good. Issues aside, the SPARA people worked insanely hard to organize this event and I think overall it went over amazingly.

This year was the introduction of Col. Sanders – a no nonsense representation of the worst case boss you could ever had. When the Red Team exfiltrated sensitive information off the network, it was reported to Col. Sanders who would bring in the affected team and give them a stern yelling. First offense was a single team member, second offense was the entire team.

But if your entire team has to go into the office, this leaves your physical security lacking.

IMe3Brg

In previous years, the problem (for the Red Team) was that after about a half a day, the Blue Teams would figure out how to lock down their services or replace them with secure versions of services, and we would be in a bit of trouble having to dig deep for some attack vectors. This year, was great because teams would often decide to roll back to a previous version of their system, restoring all of the old vulnerabilities that had just patched.

Red Team

Our read team this year was made up of Raphael Mudge (Cobalt Strike),   Joe Werther (MIT Lincoln Labs), Jason Ross (Intrepidus Group), Corey Sinay (Booz Allen), Phillip Martin (Palantir), Tim April (Akamai), Rusty Bower (Palantir), Justin Elze (Accuvant), Charles Profitt, (anyone I’m missing) and  myself [UPDATE: Forgot our freaking group leader - JP Bourget of Syncurity].

Our job, was to add some anarchy to the already stressful environment. Although competitors were already attacking each other, it was our job to attack everyone as well.  Cruel and entertaining.

War Stories

This was a pretty unfortunate blood bath. To start off, we had the developer of effing Cobalt Strike with us who had default credentials on the boxes from the beginning. He built a custom listener that beaconed home via DNS. That’s I’ll I’m going to say about that.

Cobalt Strike logo

This year we added a cruel little detail. Unlike previous years where we would secretly just report issues we exploited to the White Team, we decided that public shaming was a better route so we created a subreddit dedicated to mocking the teams. Col. Sanders put this up on the screens in front of the contestants to let them see live what was happening.

I think Rusty did the Wingdings one – which replaced the fonts on the Windows machines with only Wingdings. You’ll see a lot of screenshots showing shadow files, exploiting web stuff, and dropping database tables (and complete databases in Jason’s case). VNC that was running on a lot of the machines made it extra interesting to watch their thought process. There was also some logging in via open MYSQL instances.

Web Fun

I wish I could get more stories from others but I can tell you that I enjoyed playing with web vulnerabilities on the Sea Shell application. This was an app that had a directory traversal, a c99 web shell, a chinese character shell, and a web shell inside of a picture of a shell!

We would take the C99 shell, and copy  it over to another directory – usually the cgi-bin directory. This ended up being really difficult for some teams to detect so I would dump their shadow file to their index page, they would reboot and delete everything in /var/www and then I would dump their shadow file again and taunt them. It looked like this:

bNEhfbq


broh2
fuckoffshithead

The last one, they added in some code that said if page = anything except login or blog, then print this nice message. But they never found the issue.

I ended up just scripting the whole thing because this was a waste of time.

You’ll see this did a command injection using the “Seashell.png” and tried to use the c99 shell  if it was there to dump /etc/shadow to their main page. One just printed “balls” to the main index page. I noticed code that tried to detect this specific attack that would search for “balls”. Others gave up and changed their static page to this:

team4_lolzballs

 

The whole point of this was to knock down the score so it was run on all the teams every 60 seconds. I ran it for about 4 hours and it kept getting new groups that were rolling back their machines to previous versions I think.

autopwn

 

Offense Is The New Black

I can’t say enough positive things about the experience of ISTS. It was well organized, managed by hard working people, and all in all went off without major issues. From a talent search perspective, I think that ISTS is far beyond many of the other competitions that have always been doing a Defend and Remediate approach to emulate IT environments. Now that we can all agree that we need offensive people as well as defensive people, companies should be paying attention to these people at ISTS.

Again, ISTS has been doing offensive security way before it was cool making them the hipsters of hacker competitions.

hackerhipster

 

UPDATE 3/26: More people are blogging from the redteam:

Justin Elze:

Older »

Switch to our mobile site