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.

 

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.

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.

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:

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:

 

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.

 

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.

 

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

Justin Elze:

• http://justinelze.wordpress.com/2013/03/26/ists-defense/
• http://justinelze.wordpress.com/2013/03/26/rpi-toolkit-ists-x/ – dropping dox on RPI’s toolkit.

This is a presentation I gave about embedded security at the last 2600 meeting. This mostly just referencing other people’s work like Joe Grand and Travis Goodspeed who are embedded security gods.