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

Advertisements

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

Virtual Private Onions

Posted in Crazy Plans, Crypto, NSM, Sguil on 8 October, 2012 by Alec Waters

If you’ve not checked out Security Onion (SO) yet, you really should. It’s a powerhouse Linux distro, running everything an analyst could need to carry out effective Network Security Monitoring (NSM). The latest beta is looking fantastic; watch the video and try it out, you won’t be sorry!

I’m not going to talk about SO itself (Mother Google has plenty of good things to say); instead I’m going to look at the underlying network infrastructure.

A major component of SO is Sguil, a distributed monitoring system that has sensor and server components that are used for monitoring the network and aggregating output from multiple sensors (you can see a Sguil schematic here to understand how it all fits together). The comms between the sensors and the server are protected by SSL, and SO builds on this with autossh tunnels to protect other traffic streams from interception. Ubuntu’s Uncomplicated Firewall (UFW) opens only the necessary ports to allow SO sensors to talk to their server, so all the installations are protected to a high degree.

If all of the connections between the sensors and the server are on your own infrastructure, this is fine (perhaps you have a management VLAN specifically for this purpose, for example). There is however another use case I can think of, where we like to use a slightly different method of sensor-to-server communications.

NSM As A Service?

Let’s say you’re in the business of selling NSM to clients, either short-term (“help me understand what’s on my network”) or long-term (“please be our NSM operators in return for huge bushels of cash”). This will probably involve dropping off SO sensor boxes on customer networks and having them all report in to an SO server back at base. The SO sensors will probably be behind the customer’s NAT and firewalls, but this doesn’t matter, the comms will still work. The network of sensors will look a bit like this:

This particular use case isn’t without issue, though – here is where I think that a slightly different approach to the underlying SO infrastructure has value. Consider the following:

  • The Sguil interface shows you that one of the agents on one of the sensors is down. How do you ssh in to fix it if the sensor is behind someone else’s NAT and firewalls? How do you even know which Internet IP address you should use to try?
  • You suspect one of the sensors is under excessive load. It’d be great to install an snmp agent on the sensor and point Munin at it to try and find the stressed metric. Again, how do we contact the sensor from back at base?
  • You want to implement a custom information flow from the sensor back to the server. You need to think about the security of the new flow – can you implement another autossh tunnel? What if the flow is UDP (e.g., snmp-trap)?
  • One of the sensors is reported lost or stolen. How can you easily stop it from connecting back to base when it’s possibly now in the hands of threat actor du jour?

One possible answer is to build a custom “underlay” network to carry all of the traffic between SO sensors and the server, catering for existing flows and anything else you think of in the future. As a side benefit, the sensors will all have static and known IP addresses, and contacting them from the server will be no problem at all.

Virtual Private Onions

We’ll accomplish this by using OpenVPN to create a secure, privately- and statically-addressed cloud that the sensors and server will use to talk to each other (sorry for using the word “cloud”!). Take our starting point above, showing our distributed sensors at client sites behind client firewalls. By “underlaying” the SO comms with an OpenVPN cloud we’ll end up with is something like this:

The client’s firewalls and NAT are still there, but they’re now hidden by the static, bi-directional comms layer provided by OpenVPN. The sensors all talk over the VPN to the server at 10.0.0.1; the server in turn is free to contact any of the sensors via their static addresses in the 10.0.0.0/24 subnet.

Details

I don’t intend for this to be a HOWTO; I want to wait until people tell me that what I’m proposing isn’t a galactic waste of time and completely unnecessary! Conceptually, it works like this:

The SO Server takes on the additional role of an OpenVPN server. Using OpenVPN’s “easy-rsa” feature, the Server also becomes a Certificate Authority capable of issuing certificates to itself and to the sensors.

OpenVPN gives the SO Server a routed tun0 interface with the IP address 10.0.0.1/24 (note routed – if we wanted to, we can give other subnets back at base that are “behind” the Server access to the SO Sensors via the VPN).

The Sensors become OpenVPN clients, using certificates from the Server to mutually authenticate themselves to it. The Sensors know to point their OpenVPN clients at the static Internet-facing IP address of the server back at base, getting a tun0 interface and a static IP address out of 10.0.0.0/24 in return.

When setting up the SO components on the Sensor boxes, the sosetup script is told that the server is at 10.0.0.1 via tun0, ensuring that all SO comms go over the VPN.

The VPN carries all traffic between Sensors and Server, be it Sguil’s SSL connections, autossh tunnels, SNMP traps or queries, raw syslog forwarding, psychic lottery predictions, anything. The Server is also free to ssh onto the Sensors via their static VPN addresses.

Advantages?

We’ve implemented OpenVPN with SO in this manner, and it works well for us. I hope this approach has some advantages:

  • It makes for easier firewalling at the Server and Sensor ends. You only need to open up one port, which is by default 1194/UDP. All of the VPN traffic is carried over this port.
  • You have deterministic sensor IP addressing, something you wouldn’t otherwise have had when your sensors were deployed on foreign networks behind NAT, firewalls, and dynamic IP addresses on customer DSL routers.
  • You don’t need to worry about setting up additional autossh tunnels when you dream up a new flow of information  between Sensor and Server.
  • You can easily talk to the sensors from the server, for ssh sessions, SNMP polls, or anything else.
  • If a sensor is lost or stolen, all you need to do is revoke its certificate at the Server end and it won’t be able to connect to the VPN (more on sensor security in a moment).

There are of course some disadvantages:

  • Complexity, which as we all know is the enemy of security.
  • Double encryption. OpenVPN is encrypting stuff, including stuff already encrypted by Sguil and autossh.
  • <insert other glaring flaws here>

Security considerations

On the Server side, keep in mind that it is now a Certificate Authority capable of signing certificates that grant access to your SO VPN. Guard the CA key material well – maybe even use a separate system for certificate signing and key generation. Also, once you’ve generated and deployed certificates and private keys for your sensors, remove the private keys from the Server – these belong on each specific sensor and nowhere else.

On the Sensor side, we have a duty of care towards the clients purchasing the “NSM As A Service”. OpenVPN should be configured to prohibit comms between Sensor nodes, so that a compromise of one Sensor machine doesn’t automatically give the attacker a path onto other customer networks.

If a Sensor machine is lost or stolen whilst deployed at a customer site, we can of course revoke its certificate to prevent it from connecting to the VPN. That’s great, but the /nsm directory on it is still going to contain a whole bunch of data that the client wouldn’t want turning up on eBay along with the stolen sensor.

I have a plan for this, but I’ve not implemented it yet (comments welcome!). The plan is to have the /nsm directory encrypted (a TrueCrypt volume? something else?), but to have the decryption key stored on the SO Server rather than on the Sensor. When the Sensor starts up, it builds its OpenVPN connection to the Server before the SO services start. Using the VPN, the Sensor retrieves the decryption key (one unique key per Sensor) from the Server (wget? curl? something else?), taking care never to store it on the Sensor’s local disk. Decryption key in hand, the Sensor can decrypt /nsm and allow the SO services to kick off.

In this way, a stolen Sensor box represents minimal risk to the client as the /nsm directory is encrypted, with the keymat necessary for decryption stored on the Server. Provided that the theft is communicated to the NSMAAS provider in an expedient fashion, that keymat will be out of reach of the thief once the OpenVPN certificate is revoked.

(Other, crazier, plans involve giving the Sensors GPS receivers and 3G comms for covert phone-home-in-an-emergency situations…)

So there you have it…

…Virtual Private Onions. Any comments?


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

Accepting the Inevitability of Compromise, Spandau Ballet style

Posted in Silly on 14 August, 2012 by Alec Waters

It’s common knowledge that prevention eventually fails. To help spread the Good News to those who haven’t heard it, I present a musical aide memoire on the inevitability of compromise. Get the music playing and sing along!

Thank you for coming in
I’m sorry but the data’s all gone
I left it here I could have sworn
Safe in my database
Slowly being taken away
Just another hack for today
Off to the cloud it blew, to the cloud it blew
Guess I wasn’t quite on the ball
Luck has left me taking the fall

Pwned!
Always believe in your soul
You’ve got the power to know
You are destructible
Always believe in, ’cause you are
Pwned!
Malware is bound to return
There’s something I could have learned
You are destructible, always believe in

After the data’s gone
The ICO delivers his fine
Even though we’re victims of crime
It’s only two years ago
The kid with the spots on his face
The one who set up our database
Now he’s let blackhats through, he’s let blackhats through
Penetrated our firewall
And right under the table I crawl

Pwned!
Always believe in your soul
You’ve got the power to know
You are destructible
Always believe in, ’cause you are
Pwned!
Malware is bound to return
There’s something I could have learned
You are destructible, always believe in…


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

Posted in NSM, Packet Tracy, Sguil on 14 May, 2012 by Alec Waters

My name’s Tracy, Packet Tracy. I’m a PI. It says so on my door. Last Monday morning began like every other with a fumble through the fog of a hangover looking for new and unexplained bruising. The pounding in my head was aided and abetted by the pounding on my door, and aspirin couldn’t fix both. I dragged myself towards the noise and let in a dame wearing stilletos and a scowl that could shatter concrete at fifty paces. She said her rat of a boyfriend had been flirting with some internet floozy, and all the proof was in the pcap on the USB stick that left another bruise after bouncing off my head. No problem, I said, come back Friday for chapter and verse.

The case was tougher than I thought; the pcap was bigger than my last bar tab and there’s no way I want to go over that line by line either. So I ran it past my Bro and a couple buddies of mine, Suri and Carter, but none of us could come up with the dirt. The dame’s been on my back all week for results, and now it’s Sunday and the pounding is back with a vengeance. She’s at the door, calling me names I’m pretty sure my mother never gave me. I considered leaving by the window until I remembered my office is in a basement and there aren’t any.

Time’s up. Gotta face the music… 

So how come PT couldn’t come up with the goods? The evidence was there, surely it was just a matter of time before he found it?

I’m sure a good many of us have been in needle-in-a-haystack situations where we’ve had to rely on some tool or other to process a gigantic pcap. If the tool doesn’t find what we’re looking for, either it’s not there to find or the analyst or tool itself wasn’t up to the job.

So are all tools created equal? Given the same pcap and the same task, will they return the same results?

I thought I’d run a number of URL extraction tools against a standard 128MB pcap, the kind you might find on a Security Onion box, and I set up a quick deathmatch cage fight between httpry, urlsnarf, Suricata, tshark and Bro. All versions are the ones shipped with SO, and the config files haven’t been tweaked in any way from standard.

I realise that this is hardly a thorough and scholarly test, but I think that the results show a point worth making.

The tools were invoked like this:

user@sensor:~/httpexperiment$ httpry -o httpry.log -r capture.pcap
httpry version 0.1.6 -- HTTP logging and information retrieval tool
Copyright (c) 2005-2011 Jason Bittel <jason.bittel@gmail.com>
Writing output to file: httpry.log
5230 http packets parsed

user@sensor:~/httpexperiment$ urlsnarf -n -p capture.pcap > urlsnarf.log
urlsnarf: using capture.pcap [tcp port 80 or port 8080 or port 3128]

user@sensor:~/httpexperiment$ suricata -c /etc/nsm/sensor-bond0/suricata.yaml -r capture.pcap
<tons of output>
4/4/2012 -- 15:35:58 - <Info> - HTTP logger logged 2206 requests

user@sensor:~/httpexperiment$ tshark -r capture.pcap -R http.request -T fields -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e http.request.method -e http.host -e http.request.uri -e http.request.version > tshark.log

user@sensor:~/httpexperiment$ bro -r capture.pcap

Now, we need to process httpry’s output a little, since it includes server responses as well as client requests. Once done, we can see how many HTTP requests were seen by each tool. The results were a little surprising to begin with:

httpry: 2567 requests seen
tshark: 2557 requests seen
Bro: 2240 requests seen
Suricata: 2206 requests seen
urlsnarf: 2198 requests seen

httpry and urlsnarf are often (probably quite rightly) viewed as less sophisticated than Suricata and Bro, and tshark might not be the tool of choice for this kind of work, especially when you’re constantly monitoring traffic on an interface rather than processing a pcap. Bro and Suricata certainly picked up things that httpry didn’t (HTTP on non-standard ports, for example), but there’s quite a gulf between the apparently less-sophisticated and the cutting-edge.

So why? Each tool does the job in a different way, and with its own set of pros and cons. httpry, for example, only listens on ports 80 and 8080 by default, has no support for VLAN-tagged frames, and performs no TCP session reassembly so it is vulnerable to evasion. On the other hand, the more sophisticated Bro and Suricata have, to my knowledge, no such shortcomings.

However, it’s httpry’s brute simplicity that I suspect put it on top of the pile for this particular test. All it looks for is one of a nominated set of HTTP method verbs at the beginning of a TCP segment. It doesn’t care about proper TCP session establishment or teardown, all it’s looking for are a few bytes in the proper place. In contrast, other tools may not log any URLs at all if the TCP session isn’t complete and well-formed.

Each tool’s results were a subset of the others’ collective results – no one tool captured the superset, and one could probably achieve “better” (or at very least, “different”) results by tweaking each tool. Even then I reckon there would still be a pretty good chance that there are undiscovered URLs lying there that a different tool could pick up.

I don’t mean for this to be seen as some kind of ranking of tools, or a statement that httpry and tshark are “better” URL extractors than Bro and Suricata; all I’m trying to say is that you’re almost certain to miss something by only using a single tool for a job like this. On the flip side of course, running two or more URL extractors might seem like a galactic waste of resources…

Your mileage will almost certainly vary, but it’s worth keeping this in mind when the dame is at the door demanding answers!


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

Hacker Countermeasures, 1984 style

Posted in General Security, Retro on 30 April, 2012 by Alec Waters

Some number of years ago, I was lucky enough to get a Sinclair ZX-81 for Christmas. There was much wonderment and joy to be had amid the frustration of RAM-pack wobble, the agonising waits for software to load from tape, and the never-ending search for a replacement keyboard that wasn’t as bad (or worse) than the original.

The best thing about the computers of olde was the built-in interpreter, usually for BASIC – here was an item of consumer electronics that wouldn’t do a single thing unless you told it to, an unthinkable concept to the marketeers of today. Putting in a tape and typing LOAD “” was the easy way out of this predicament; however, the real solution to the inert nature of your newly purchased box of future was to open the manual and learn how to code.

So learn we did. One day, my father proudly showed me a program he’d written – a version of the card game “snap”, with graphics and everything. After whiling away a good part of the afternoon playing, I looked over the source code. Showing an early leaning towards white-box pentesting, it didn’t take long to find a simple flaw. By simply keeping your finger pressed on your “snap” key (regardless of the two cards on the top of the deck) you could beat even the quickest opponent when a true “snap” finally came around. If both players were aware of this exploit (or “expliot” as I’d almost certainly have spelled it at the time) you had to make sure that you were player 2 since the subroutine that checked which key was pressed during a “snap” condition checked for player 2’s “snap” key before player 1’s.

Easily exploitable vulnerabilities? Some things never change, huh? In terms of Incident Detection, prime Indicators of Compromise included my little sister complaining to our parents that Daddy’s game was no fun because Alec always won.

To restore the game back to a test of speedy reactions my father rolled out some countermeasures in the form of a patch. The next time we played, my tactic resulted in the computer labelling me a cheat and docking me five cards every time I pressed my snap key when it wasn’t snap. To further add injury to insult, the losing player was crushed by a one-ton weight falling from the ceiling. I’m sure you can imagine what a terrifying visual experience this must have been, especially if you remember the graphics capabilities of the ZX-81…

To sample the full glory of this dance of measure and countermeasure, here’s the actual source code as submitted to ZX Computing magazine nearly thirty years ago. Lines 570 and 580 show the horrifying corpses of the losing players, squashed flat by Newtonian Justice From Above. Enjoy 🙂

Newtonian Justice from Above

Lines 570 and 580, Newtonian Justice from Above


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

Quick Book Review – The Alexandria Project, by Andrew Updegrove

Posted in General Security on 19 April, 2012 by Alec Waters

THANK YOU FOR YOUR CONTRIBUTION TO THE ALEXANDRIA PROJECT

In a slight departure from my usual reading material of John le Carré and non-fiction technical tomes, I recently read The Alexandria Project by Andrew Updegrove; it turned out to be a nice mix of the two.

Without wishing to spill too many beans, it’s a fun read featuring mystery attackers with mystery motives, three-letter-agencies butting heads whilst manipulating people down their chosen path, military coups and crazy politicians with their finger on the Big Red Button.

The plot is spookily close to reality, especially in the Big Red Button department – I was reading the story on the actual dates featured in the book, at which time events were playing out on the world stage much as they were in my Kindle (plot spoiler, courtesy of BBC News, here). Coincidence? Or does Mr Updegrove have a crystal ball?

For the grand total of £1.95, you can’t really go wrong. Swing by Amazon and pick up a copy!


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