Skip to content

Pentura at Infosec 2014

by

We’re exhibiting at this year’s Infosecurity Europe show, Tuesday 29th April to Thursday 1st May at Earl’s Court, London.  We’re at stand F27, and we will be showcasing our range of managed data loss prevention services, that help organisations to relieve the headaches of enforcing data security.  We’re also demonstrating solutions from our partners Symantec, Boldon James and Varonis.

We offer a range of individual data services to help with companies’ specific pain points, through to a fully-managed DLP service.  Our individual services include:

  • Assessing risk exposure to breaches
  • Classifying sensitive data
  • Educating staff on data security
  • Where to start with DLP
  • Implementing DLP programmes
  • Managing DLP solutions
  • Data and breach forensic services

If you’re attending Infosec, do come and visit Pentura on stand F27.  We look forward to seeing you there.

My Robot Has WiFi!

by

robo_wifi

Wireless communication using Bluetooth! Thanks to the Adafruit EZ-Link!  Basically that tiny board sticking out on top is a Bluetooth Serial-Link, allows me to remove the cable that binds the robot to my PC / MAC.  Now I cannot only program the robot wirelessly, but if I choose to, I can send it commands wirelessly over the air – thus completing Asimov’s second rule of robotics (if you don’t know the rules, see my previous blog post).  The EZ-Link is smart and auto-detects baud rates – so no extra programming was required; just plug-n-play :)

If others in the office want to cheat at Zumo wrestling and use Bluetooth to control their bots (wrestling has to be complete autonomous), this baby has code to hack and control the Bluetooth link, thus making my Zumo’s opponent a ‘Slave to my Machine’ icon_twisted

To learn how to wire-up and operate this device head on over to Adafruit’s LEARN section: https://learn.adafruit.com/introducing-bluefruit-ez-link/overview

Side view for comparison:

robo_wifi2

And another frontal:

robo_wifi3

I really need to solder on some more headers, or a prototype-board to tidy up all those wires; but this is really just a proto-type.

PS: One member of our Team had an Arduino Yun lying around in his electronics kit.  He decided to have has bot completely wireless using 802.11n and programmed a simple web interface to control his bot :)

This post is our last for robotics week.  I hope all our readers have been having fun this week with their own robotics kit, if not I hope its inspired some of our readers to go out and buy some kits and have fun.  I personal enjoyed reading: http://www.amazon.co.uk/Arduino-Robotics-John-David-Warren/dp/1430231831 (ISBN:978-1430231837) which will get me into building bigger projects :)

It Can See; Giving Your Bot Sight!

by

robot_eyesPreviously we unveiled our love for the Arduino and the Zumo Shield that gives us a massive head start to building our own robot army.  The basic shield has a Zumo reflectance sensor array for primarily line following, and an LSM303DLHC accelerometer & magnometer (magnet-o-meter) for navigation.  But a lot of the remaining Arduino pins are not used, so this gives us the capability to add more tech or sensors so our robot can react to the world around it.

I had a spare HC-SR04 ultrasonic sensor in my kit, so I decided to give my bot some eyes!  Other sensors such as Infra-Red Distance Sensors (Adafruit:IR distance sensor includes cable (10cm-80cm), can also be used.  Adafruit has a variety of sensors available (https://www.adafruit.com/search?q=distance+sensor), but the HC-SR04 can be found on Amazon(http://www.amazon.co.uk/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=HC-SR04) for approximately 1 GBP!

I used a quarter size breadboard (or Tiny breadboard) and stuck it down (with its included sticky back adhesive tape).  The solder-less breadboard gives me the option of swappable sensors (incase I want to swap out the ultrasonic sensor for an IR one).  The Ultrasonic Sensor has 4 pins:

  • VCC (5v)
  • GND
  • Trig
  • Echo

I used an example Zumo motor demo from https://github.com/pololu/zumo-shield ,  and added code for the ultrasonic sensor – I place the Trig on Pin 2 and Echo on Pin 11 (their right next to each other, and also next to GND, and VCC behind the cowcatcher.  The HC-SR04 is already supported by the Arduino IDE, so I could natively call:

pinMode(echoPin, INPUT);
duration = pulseIn(echoPin, HIGH);

So its very easy to communicate with this sensor, though some additional math is needed to calculate distance in ether cm’s or inches (see the sample code below).

For those that don’t know the Asimov’s laws of robotics.  They are:

  1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
  2. A robot must obey the orders given to it by human beings, except where such orders would conflict with the First Law.
  3. A robot may not injure its own kind and defend its own kind unless it is interfering with the first or second rule.

Being, that this robot is a baby, with no real intelligent code; I decided to program the bot with a simple avoid and run-away, thus avoiding danger (unless its on a table/cliff, which case it will fall off, as no border/line-dection is currently in place).  So basically if the robot is on the floor and detects an object within 8cm, it rotates to the left and carries on moving.

My Simple example program using the ultrasonic sensor:

#include <ZumoMotors.h>
#include <Pushbutton.h> 
/*
 * This example uses the ZumoMotors library to drive each motor on the Zumo
 * forward, then backward. The yellow user LED is on when a motor should be
 * running forward and off when a motor should be running backward. If a
 * motor on your Zumo has been flipped, you can correct its direction by
 * uncommenting the call to flipLeftMotor() or flipRightMotor() in the setup()
 * function.
 */

#define LED_PIN 13
#define FORWARD_SPEED     200
const int trigPin = 2;
const int echoPin = 11;
Pushbutton button(ZUMO_BUTTON);   

ZumoMotors motors;

void setup()
{
  pinMode(LED_PIN, OUTPUT);
  Serial.begin(9600);
  // uncomment one or both of the following lines if your motors' directions need to be flipped
  //motors.flipLeftMotor(true);
  //motors.flipRightMotor(true);
   button.waitForButton();
}

void loop()
{
  
  long duration, inches, cm;
  digitalWrite(LED_PIN, HIGH);
  motors.setSpeeds(FORWARD_SPEED, FORWARD_SPEED);
 
  // The sensor is triggered by a HIGH pulse of 10 or more microseconds.
  // Give a short LOW pulse beforehand to ensure a clean HIGH pulse:
  pinMode(trigPin, OUTPUT);
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);
 
  // Read the signal from the sensor: a HIGH pulse whose
  // duration is the time (in microseconds) from the sending
  // of the ping to the reception of its echo off of an object.
  pinMode(echoPin, INPUT);
  duration = pulseIn(echoPin, HIGH);
 
  // convert the time into a distance
  inches = microsecondsToInches(duration);
  cm = microsecondsToCentimeters(duration);
  
  Serial.print(inches);
  Serial.print("in, ");
  Serial.print(cm);
  Serial.print("cm");
  Serial.println();
  
  //delay(100);
  
  if(cm < 8){      // run backwards and spin      digitalWrite(LED_PIN, LOW);   motors.setSpeeds(-FORWARD_SPEED, -FORWARD_SPEED);   delay(100);   for (int speed = 0; speed >= -400; speed--)
  {
    motors.setLeftSpeed(speed);
    motors.setRightSpeed(-speed);
    delay(2);
  }
  
/*  for (int speed = -400; speed <= 0; speed++)
  {
    motors.setLeftSpeed(speed);
    delay(2);
  }*/
  }

}

long microsecondsToInches(long microseconds)
{
  // According to Parallax's datasheet for the PING))), there are
  // 73.746 microseconds per inch (i.e. sound travels at 1130 feet per
  // second).  This gives the distance travelled by the ping, outbound
  // and return, so we divide by 2 to get the distance of the obstacle.
  // See: http://www.parallax.com/dl/docs/prod/acc/28015-PING-v1.3.pdf
  return microseconds / 74 / 2;
}
 
long microsecondsToCentimeters(long microseconds)
{
  // The speed of sound is 340 m/s or 29 microseconds per centimeter.
  // The ping travels out and back, so to find the distance of the
  // object we take half of the distance travelled.
  return microseconds / 29 / 2;
}

Yet Another HeartBleed.

by

heartbleed

This Heartbleed Information Disclosure Vulnerability has pretty much been covered all over the internet today (8th April 2014).  As a one-page-stop summary, please read below:

An online site exists to check vulnerabilities: http://filippo.io/Heartbleed/

Source Code available at: https://github.com/FiloSottile/Heartbleed

A python script (thats much better): http://s3.jspenguin.org/ssltest.py

A second version of above code with STARTTLS Support: https://gist.github.com/takeshixx/10107280

A good breakout of why the bug exists is here: http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

Watching twitter has been entertaining, login.yahoo.com has been leaking user credentials, aswell as several forums, a security competitor was vulnerable leaking their SSL certificates private key, many darknets have been hosting competitions for the most collected credentials / private keys.

What is affected?

Anything using a vulnerable version of openssl:

  • Web services (HTTPS)
  • Mail Services (STARTTLS)
  • SSL based VPNs
  • OpenSSL based Authentication Mechanisms
  • VOIP

Versions affected

From the OpenSSL advisory http://www.openssl.org/news/secadv_20140407.txt the following versions are vulnerable:

  • 1.0.1 through to 1.0.1f
  • 1.0.2-beta & 1.0.2-beta1.

All other versions are unaffected.

How about operating systems?

Some operating system distributions that have shipped with potentially vulnerable OpenSSL version:

  • Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
  • Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
  • CentOS 6.5, OpenSSL 1.0.1e-15
  • Fedora 18, OpenSSL 1.0.1e-4
  • OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
  • FreeBSD 10.0 – OpenSSL 1.0.1e 11 Feb 2013
  • NetBSD 5.0.2 (OpenSSL 1.0.1e)
  • OpenSUSE 12.2 (OpenSSL 1.0.1c)

Operating system distribution with versions that are not vulnerable:

  • Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14
  • SUSE Linux Enterprise Server
  • FreeBSD 8.4 – OpenSSL 0.9.8y 5 Feb 2013
  • FreeBSD 9.2 – OpenSSL 0.9.8y 5 Feb 2013
  • FreeBSD Ports – OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)

Workarounds, incase you can’t Upgrade OpenSSL

Even though the actual code fix may appear trivial, OpenSSL team is the expert in fixing it properly so latest fixed version 1.0.1g or newer should be used. If this is not possible software developers can recompile OpenSSL with the handshake removed from the code by compile time option

-DOPENSSL_NO_HEARTBEATS

CVE-2014-0160

CVE-2014-0160 is the official reference to this bug. CVE (Common Vulnerabilities and Exposures) is the Standard for Information Security Vulnerability Names maintained by the MITRE.

I’m on a Network without Direct Internet Access. How can I Test for This Bug?

We understand that strict controls on some of our clients networks, mean no internet access and new scripts/tools can not be introduced until an authorised maintenance window.  You can actually still test for this vulnerability using openssl:

openssl s_client -connect <ip>:<port>

then at the prompt type:

B

If you receive an error – your service is not vulnerable, anything else your service is potentially vulnerable!

Example Vulnerable Service:

New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-GCM-SHA384
    Session-ID: 1907E866C9EA711CBCC79990A42A3397F42C18187E134C1D45F127D2892D038B
    Session-ID-ctx: 
    Master-Key: 1879E87ED22A69961A769C09CC7BBD920CD274D26D4856AD21A162DA5B9754415204E737F3AD6D1C658E486D6F1FDB17
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - db cb 01 bb d5 55 70 90-0a 23 3e 5c 21 e1 f1 f6   .....Up..#>\!...
    0010 - 7f 84 fe b3 1a f3 6f f7-82 ea b3 be ff b2 8d 14   ......o.........
    0020 - dc 9c e6 d4 fc ed 8a 0d-f9 64 59 1d 2e e3 5b 25   .........dY...[%
    0030 - a0 cb 45 c7 bd fd 74 8e-a3 1d 4e 9f 03 2f 30 b9   ..E...t...N../0.
    0040 - 1e fa 84 36 bd ba 36 21-5c cc 18 00 18 bb 0a 1a   ...6..6!\.......
    0050 - b2 01 87 d1 bc cd 11 cb-2e 64 62 36 50 51 89 57   .........db6PQ.W
    0060 - e6 d3 19 a8 5e 01 2e 3d-6d ec bc 13 ce fb ee 52   ....^..=m......R
    0070 - bc b4 5c 16 92 93 8a a5-bd d7 01 9d 5e a9 84 1e   ..\.........^...
    0080 - 37 d2 15 93 bf 9d 22 93-06 fb e6 b9 16 18 61 f8   7.....".......a.
    0090 - 3b b8 df 77 f9 2e 8c 81-e4 10 e2 3c 07 40 c7 81   ;..w.......<.@..
    00a0 - 13 e2 91 1f 69 a6 7e 64-93 28 30 78 55 34 6b 5e   ....i.~d.(0xU4k^
    00b0 - f6 99 78 ba 7c 9f 13 51-d8 2b b3 1f bc e5 7e b1   ..x.|..Q.+....~.

    Start Time: 1396986311
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
B
HEARTBEATING
read R BLOCK

How Much Data is Leaked?

There is a total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.  Eventually, credentials or even private-keys, x509 certificates can be leaked.

Are my Private Keys Safe?

I’m frequently receiving the Question “Hey, so and so from company XXX claim it is not possible to get critical information like keys, why are you saying its possible?

Well we looked into this, and it mainly comes down to the Heap management of the OS, and the amount of RAM that you have allocated to the server.  In our testing, by continuously hammering the SSL affected service we did eventually obtain critical information like passwords and private keys.  We admit this is a lot easier on a server with a smaller amount of memory, will many active connections.  On the other hand, with the same server, but only a very small amount of connections it is very hard to obtain the same key material; in this case the more popular your service is the more vulnerable you are!  When it came to testing BSD variants, the private keys were only accessible after a server reboot.

Lastly and Most Importantly…

…for Users

Don’t rush to change all your passwords!  You might be revealing the clear-text of your new credentials. Wait for the affected service to update their SSL certificate (you’ll usually get an email from them) and once your sure the patch/fix has been applied, only then change your password.

…for Affected Services

After the applying the workaround or upgrading Openssl don’t forget to change your certificate as the private key might have already been compromised.  Additionally, inform your users/customer about the vulnerability, we also suggest that you warn all users/customers that their credentials might have been compromised and that they should change their passwords.

Additional References

Rise of the Machines: Arduino Bots

by

robot_zumo

Robotics Week

Its robotics week (April 5th – 13th) 2014 (http://www.nationalroboticsweek.org), on Arduino Day (29th March 2014) I posed the question “What will you Build?”.  Well here in the Pentura office, we went out and bought some Zumo Shields from Pololu.  The shields are also available from our favourite electronics provider Adafruit.  The shield is a quick an easy insertable arduino shield that slides perfectly into place on an Arduino Uno R3
robot_shield

Zumo Shield

The Shield on its own with an EnglishPenny for size comparison.  Here you can see the Pin headers are pre-soldered for the Arduino Uno (R3 model if you wish to use the Piezo buzzer, just below the text Zumo Shield).  To the left of the buzzer is a LSM303DLHC accelerometer and magnometer compass, so you can build/write advanced navigation programs.  Underneath the shield (not current visible) is the Zumo reflectance sensor array for line following/avoidance, also the battery compartment for 4x standard 3.3v AA batteries – that supply power to 2x 75:1 micro metal-gear motors and the Arduino Uno.  The shield has an accessible on/off button, input button, and a reset button (resets Arduino).  For more detail about the Zumo Shield please refer to the user guide: http://www.pololu.com/docs/0J57

The pre-assembled version also has a handy stainless steel miniature cowcatcher on the front ;)

robot2

For those interested in Zumo wrestling I would suggest reading this web-blog : http://mcuoneclipse.com/2013/09/03/mini-sumo-robot-competition-running-with-frdm-kl25z/, the blog poster has an interesting pic of the same sumo shield – only its powered/controlled by a beagle bone blackFreescale FRDM-KL25Z board.

The rules for Zumo can be found here: http://www.robotroom.com/SumoRules.html

At Pentura we think programming and electronics skills are extremely useful, for Hackers and Penetration Testers.  To keep our skills sharp – between jobs we like to have fun, and build interesting projects.  If you want to join in and and become a member of our Team? Send us your CV.

Proxmark3 vs Ultralight C

by

Proxmark 3

There have been no secrets this week while I’ve been trying to add Mifare Ultralight C support to the Proxmark. Ultralight C cards are HF (13.56MHz) tags that are part of the Mifare family.  This week has been an interesting learning process, and it has corrected some misconceptions I had about the card.  For those interested you can follow my progress at http://www.proxmark.org/forum/viewtopic.php?id=1946.  But I will summarise my findings below:

Ultralight C

Card Size & Readable Blocks

The Card has 0x2f Pages (or blocks) which means 47 decimal blocks.  However, only 43 of these are readable. The remaining 4 blocks contain the 3DES Key needed for authentication, and are write only, so the key cannot be simply recovered.

proxmark3> hf mfu ucrdcard
Attempting to Read Ultralight C...
#db# READ CARD FINISHED
isOk:01
Block 00:04 0e 6b e9
Block 01:ca 0b 28 80
Block 02:69 48 00 00
Block 03:00 00 00 00 [0]
Block 04:02 00 00 10 [0]
Block 05:00 06 01 10 [0]
Block 06:11 ff 00 00 [0]
Block 07:ff ff ff ff [0]
...abreviated...
Block 2b:00 00 00 00 [0]

Encryption

Contrary to belief (I admit making an initial mistake here), Ultralight C contents are not encrypted by default! (Unless cryptography has been added by the controlling application).  Basically a 3DES (Triple DES) key (16 bytes split into key 1 and key2, (key3=key1)) is used for Authentication Only! Depending on the configuration of Auth0 & Auth1 Page/Block (2a byte 0 & Page 2b Byte 0) depends on what pages/blocks are accessible.

  • Auth0 controls the page range from 0×03 – 0×30; (0×00 = disabled)
  • Auth1 controls the enforced restrictions 0×1 = Read Unauthenticated & Write Protected 0×00 = Read & Write Protected

Authentication (Updated 8th April 2014)

Below is a trace of attempted authentication with an Ultralight C card:

proxmark3> hf mfu auth
#db# Auth1 Resp: af1eae15f85b05e32d99b5                 
#db# AUTH 1 FINISHED                 
enc(RndB):1e ae 15 f8 5b 05 e3 2d           
     RndB:13 46 86 a9 4b f7 94 cd           
     RndA:9b 75 fe 7f 5b 9e ba 79           
     RA+B:9b 75 fe 7f 5b 9e ba 79 46 86 a9 4b f7 94 cd 13           
enc(RA+B):62 7a b7 02 0c fe c7 8b a2 4e 6b 43 5e 0f a0 b7           
#db# len b                 
#db# Auth2 Resp: 00fcb27f6e3d5db88b8e                 
#db# AUTH 2 FINISHED                 
isOk:88 Resonse:00 00 00 00 00 00 00 00           
proxmark3> hf 14a list
Recorded Activity          
          
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer          
All times are in carrier periods (1/13.56Mhz)          
          
     Start |       End | Src | Data          
-----------|-----------|-----|--------          
         0 |       992 | Rdr | 52              
      2404 |      4772 | Tag | 44  00              
      7040 |      9504 | Rdr | 93  20              
     10852 |     16740 | Tag | 88  04  0e  6b  e9              
     18816 |     29280 | Rdr | 93  70  88  04  0e  6b  e9  2c  90              
     30692 |     34212 | Tag | 04  da  17              
     35456 |     37920 | Rdr | 95  20              
     39268 |     45092 | Tag | ca  0b  28  80  69              
     47232 |     57760 | Rdr | 95  70  ca  0b  28  80  69  69  f1              
     59108 |     62692 | Tag | 00  fe  51              
     66176 |     70944 | Rdr | 1a  00  41  76              
     82660 |     95460 | Tag | af  1e  ae  15  f8  5b  05  e3  2d  99  b5              
   1031296 |   1053344 | Rdr | af  62  7a  b7  02  0c  fe  c7  8b  a2  4e  6b  43  5e  0f  a0  b7  96  df              
   1065060 |   1077796 | Tag | 00  fc  b2  7f  6e  3d  5d  b8  8b  8e  cc 

Basically:

  1. The authentication starts with the command 1A 00 concatenated with an iso1433a CRC.
  2. The card/tag responds with AF followed by 8 bytes e_k(RndB) and a 2 byte CRC
  3. This e_k(RndB), is an encrypted Random number with key k.
  4. We decrypt these bytes to get the real number RndB’ =
    13 46 86 a9 4b f7 94 cd
  5. Next we generate our own random number (if we wish)  RndA =
    9b 75 fe 7f 5b 9e ba 79
  6. Rotate RndB’ left by 8 bits
  7. Concatenate RndB’ with Rnd A =
    9b 75 fe 7f 5b 9e ba 79 46 86 a9 4b f7 94 cd 13
  8. We encrypt RndA||RndB’ and send this to the tag with a command byte of AF + our enc(RndA||RndB’) = 
    62 7a b7 02 0c fe c7 8b a2 4e 6b 43 5e 0f a0 b7
  9. The tag should respond with 8 bytes, which should be e_k(RndA’) =
    fcb27f6e3d5db88b
  10. This point we can decrypt and rotate the result right 8 bits and it should match our initial RndA value.  But because we have a valid response we can choose to ignore it :)

Where to get blank tags?

I purchased my Ultralight C tags from Amazon:

http://www.amazon.co.uk/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=mifare%20ultralight%20c

Conclusion

Cracked it! :)  Currently my Proof-of-Concept is hard coded with the default 3DES Ultralight key!  Now I just need to modify the code slightly to take as input a user supplied key.

What keys did I use you may ask?  I have tried an empty key, and the default 3DES key specified in libfreefare, and 000102030405060708090a0b0c0d0e0f

Code

Code has recently been published on the Pentura  Github repo:

https://github.com/PenturaLabs/proxmark3/tree/Ultralight-Mod

Arduino Day – March 29th

by


Arduino Day 2014

Arduino Day is a worldwide celebration of Arduino’s first 10 years. It’s 24 hours full of events – both official and independent, anywhere around the world – where people interested in Arduino can meet, share their experiences, and learn more.

What will you build?

Follow

Get every new post delivered to your Inbox.

Join 98 other followers