Some Bitsquatting Observations

I registered a basket full of bit-squatting domains last year and as they all recently expired I thought I’d give a few observations about my experience.

The idea is that memory errors on end devices or intermediate equipment results in occasional bits being flipped in memory. Where one of these flips happens to land on a domain name in memory, the flip might change it to another valid character and send traffic to the corrupt domain instead. While these errors are exceptionally rare, the internet is exceptionally big so we can observe this behaviour with high enough traffic domains. You can read read about it here and there’s a good video here about this and other fun DNS stuff.

Now despite reading the papers and seeing the presentations it still seemed a bit far out, so as domains are cheap I registered a few to validate this for myself as it looked quite fun. I was surprised at the time that so many squats were available despite this being a well known issue with talks being given at Defcon, even the the exact domains provided in papers/talks were available. I was also a bit disappointed at this, are the companies subject to the publicised squats not interested in preventing further abuse of this? And why were the security community not picking these up to validate for themselves or just for a laugh?? Oh well..

My set-up used a slightly modified copy of dnschef to serve requests, a web server logging connections and headers, smtp-sink to log emails and logging of DNS lookups and some other traffic with tcpdump. Unfortunately due to a cock up I blew the six months of results away in a botched migration. Oh well..

I pretty much ended up with the same observations as others that presented their findings, lots of requests for well used domain names and a significant number from mobile devices and not many verifiable bit flip hits on the less popular domains.

There were a decent number of requests that could have been pretty bad for the squatted organisation had they been taken advantage of such as lookups for internal host names from the organisations themselves, requests for certificates and software updates and the likes.

No valid SMTP traffic was observed logging email headers but there was an insane quantity of spam. I’m not entirely sure whether the spammers had been subject to bitflips or whether they just had typos in their lists but it was enough to make me give up on this monitoring very quickly.

As about 12 months had passed since my disappointment in so many of the squat domains being available, I compared the availability now to then. This time about there was a more marked change.

One example would be in the gstatic.com domain that was used in the demonstrations and presentations:

  • gstatic.com – October 2013 – 26 squats unregistered
  • gstatic.com – October 2014 – 0 squats unregistered

This reduction in availability was observed in other domains too, interestingly most of the gstatic squats and some of the other domains appear to have been registered by the same individual with the name servers at bitfl1p.com so at least some one is having fun 🙂

I’d recommend trying some bit squatting out, it’s easy and cheap to do and with some careful domain choice it can lead you to some amusing and unpredictable results. Plus it’s funky knowing that a cosmic ray might just be the cause for that traffic coming your way!

Cracking APEX Hashes with John, Long Salts

Cracking APEX hashes with john the ripper doesn’t often cause me any bother but I’ve come across two instances where john would not crack the hashes provided, this turned out to be due to the user name and workspace it uses as a salt being too long.

The easiest way to obtain the hashes with access to the database is using dump-apex-hashes.sql while making sure to alter the schema to match the version you are using. After this we can reformat with apex2john.py and crack away. The semi automated process along with the manual process is described well here.

The john input we might end up with after following the above steps is:

$dynamic_1$f96d32cbb2fbe17732c3bbab91c14f3a$10ADMIN

Cracking this APEX hash with john results in the following:

Loaded 1 password hash (dynamic_1: md5($p.$s) (joomla) [128/128 SSE2 intrinsics 10x4x3])
password (?)

The above hash uses the trailing 10ADMIN string as the salt. This salt is made up of the workspace name plus the user name, to demonstrate this we can see the following example matches the hash cracked as “password” above:

>>> print hashlib.md5("password" + "10" + "ADMIN").hexdigest()
f96d32cbb2fbe17732c3bbab91c14f3a

Where I’ve had a problem is when the workspace name plus the user name is greater than 31 characters, quite why someone would pick such a long workspace name I don’t know but they do!

When this salt ends up over 31 characters we run in to a problem, john no longer picks it up as valid:

cat apex;./john apex 
$dynamic_1$98d706b82b654265e71ea7db05eccbfa$4782602601579360ABCDEFGHIJKLMNOPQ
No password hashes loaded (see FAQ)

Adding the following dedicated APEX configuration to john’s dynamic.conf file will allow us to use dynamic_1011 to crack the hashes, the main difference with this one being it doesn’t have a maximum “Saltlen”.

####################################################################
# Crack APEX hashes with long salts - Radwire
####################################################################
[List.Generic:dynamic_1011]
Expression=md5($p.$s) (APEX long salts)
Flag=MGF_SALTED
Func=DynamicFunc__clean_input
Func=DynamicFunc__append_keys
Func=DynamicFunc__append_salt
Func=DynamicFunc__crypt_md5
Test=$dynamic_1011$B932A7CB1C06A03310921989DACBA3F7$4782602601579360ABCDEFGHIJKLMNO:password

Now when we try again after substituting dynamic_1 with dynamic_1011 we see the hash that wasn’t picked up before works okay:

cat apex;./john apex
$dynamic_1011$98d706b82b654265e71ea7db05eccbfa$4782602601579360ABCDEFGHIJKLMNOPQ
Loaded 1 password hash (dynamic_1011 md5($p.$s) (APEX long salts) [128/128 SSE2 intrinsics 10x4x3])
password1        (?)

SDR / GNU Radio Tutorials

It doesn’t take too long once you get your hands on an SDR to realise that there’s a lot to learn if you want to move beyond being a consumer of programs and applications others produce. This is where I find myself at the moment, and it is a bit like being back at school but fun.

Here’s a few resources I’ve been reading, watching or have bookmarked in no particular order relating to SDR and GNU Radio. As a beginner in this I can’t fully vouch for their quality but they seem okay!

X11 Pentesting Tips

I’ve had to do a fair bit of X11 testing recently and needed to dust off a few cobwebs as it’s not something I come across that often. I guess there will be others in the same boat or those that haven’t come across it at all.

First up are remote xdmp services listening on UDP port 177. These can be easily connected to and used from within your current X11 session by using Xephyr or Xnest which is a lot less fiddly than starting up a new X instance, e.g.

$ Xephyr -query 192.168.0.234 -geometry 1024x786 :1

Open X11 services are easily identified with a service scan in nmap

6001/tcp open X11 X.Org (open)

You firstly might want to list all of the open windows and get their IDs:

$ xlsclients -al -display 192.168.0.234:1
Window 0x200010:
 Machine: Myhost
 Name: xterm
 Icon Name: xterm
 Command: xterm
 Instance/Class: xterm/XTerm

With an open X11 service we usually do something like take a screen shot using xwd:

$ xwd --display 192.168.0.234:0 –out file.xwd
$ convert file.xwd file.jpeg 
$ xv file.jpeg

We can also use xwatchwin to watch Windows remotely, so to watch the xterm listed above:

$ xwatchwin 192.168.0.234:1 -w 0x200010

Sometimes you might find that the screen is locked or black, sending a keyboard or mouse event to the remote server may wake it up. I’ve a small hacky perl script that will move the mouse pointer, this can be handy for waking up the remote display or changing focus.

$ ./xtest.pl -d 192.168.0.234:1 -m
Currently focused Window: 0x0
X-shift: -100
Y-shift: -100
Currently focused Window: 0x200010

xtest.pl will also display basic information, take screenshots, change windows, list windows and kill pesky windows between you and that open shell, it’s over on github.

xtest.pl 0.2 usage:

 -d <displayname> Uses $DISPLAY or :0.0 if none specified
 -k <windowid> In hex to kill
 -l List windows
 -f <windowid> In hex to focus input on
 -i Server information
 -m Move the mouse pointer
 -s <tofilename> Take screen capture using xwd

Sending key strokes is a great way to take advantage of an open X11 session, and all to often people don’t seem to do this, if there is a terminal sitting there on the desktop send yourself a shell!

We can use the virtual keyboard xvkbd for this, click on the xvkbd down the bottom left and connect to remote display. Once connected type slowly to avoid errors, it might be an idea to check up on what you are typing by taking a screen shot or using xwatchwin.

xvkbd

The focus mode on xvkbd will move the mouse on the remote display and auto clicking can be set up but this is rather fiddily. A better option is to install the xdotool application, this lets you easily move the mouse and send clicks/mousedown events and monitor the current mouse location, handy for opening menus up etc. The following example right clicks to open a context menu, we then take a screenshot to see where the pointer is and move relative to its current position and click again top open the option we are now over.

~ $ export DISPLAY=remote:0
~ $ xdotool click 3
~ $ xdotool getmouselocation
x:210 y:98 screen:0 window:0
~ $ xdotool mousemove_relative 10 50
~ $ xdotool click 3

We can also watch for events such as keystrokes in the remote session using xsnoop or the likes, which might be handy if someone is using the session but all to often its a forgotten session with no-one there:

$ ./xsnoop 192.168.0.234:1
ssh somehost
someone
somepassword

Plenty of fun to be had with an open X11 session, it’s not just screen shots and event sniffing as I’ve seen suggested in others reports and posts!

Analysing An Active RFID Card

The next device from the box of bits was a pair of active RFID cards from a top of the range vehicle security system used around 2001-2003. These tags were required to be on your person to start the car in addition to a key. This is just an analysis of the cards RF transmissions and not the system itself as I don’t own one.

Popping open the two cards we can see they have similar layouts but the newer board on the right doesn’t look as clean and does not have any PCB labelling. The keys each have a serial number sticker on the back of the PCB as well as having it printed on the front of the card.

The two RFID tokens.

The two RFID tokens

There are not many components on the card, we can see an SMD EEPROM along with a small SAW device and the PCB antenna. Looking up the SAW device documentation indicated that it will most likely be transmitting in the 433Mhz ISM band on 433.900.

The batteries in the cards had long run out, so we just hooked them up to an external power supply and monitored with the HackRF and GQRX, this would have worked fine with the RTL SDR device too. We see a short transmission on 433.920Mhz roughly every 5 seconds but it does vary a bit. The frequency reading is wrong below as the screen shot was captured off an IQ replay.

Clear signal.

Clear signal.

On looking at this a bit closer with baudline it unsurprisingly looks to be an on off keying AM signal. Importing a saved audio clip in to Audacity shows the signal, the first capture looked a bit odd with dips and other strangeness but it turned out I was a bit off frequency, fixing the frequency gave a clearer capture.

Unclean off frequency capture.

Unclean off frequency capture.

The first thing I wanted to do was level off the signals to allow for an easier visual comparison, the capture below shows the original signal up top and the altered one below. I used a the same script I used with the previous doorbell project and we can count 78 peaks in each tokens transmission.

Full capture with the second channel prettified

Full capture with the second channel prettified

Comparing transmissions showed that the token is beaconing the same pattern over and over so maybe they are easily repayable as with the doorbell. Interestingly when we look at the two tokens with different serial numbers next to each other we can see a quite long period at the start where they roughly match followed by not too dissimilar patterns after. At this stage I’m guessing the serial numbers are likely just being beaconed following the preamble/synchronisation signal.

The signals patch prior to the red line.

The signals match prior to the red line.

The timings were not particularly consistent even in the initial preamble to allow them to be lined up easily and my previous script to guess binary output based on the period of time (NRZ) was not working perfectly due to this.

There appeared to be two spacing times, one around 18 samples and one around 45 samples but these varied by +/- 10 samples which added up to a large error by the end of the 78 state changes. In order to sort this out I added an option to the script we created for the doorbell to make the sample spacing gaps even. So in this instance a sample space of >30 = 40 and <30 = 20 gives us an easy to compare output.

A resized comparison showing some matching digits

A resized comparison showing matching digits

Now that the WAV file has evenly spaced samples, we can compare them easier as can be seen in the image above of the two tokens beside each other. The initial preamble matches perfectly between each transmission up to the previously indicated red line and would seem to have 5 8 bit components going by the peak count. Handily enough, the tokens 6 digit serial numbers share one digit in the same place and we can see where these match between the two tokens, we can also see this digit repeated again in two other places in the second serial number, these are indicated in the image above.

Now on to the actual decoding! The number of peaks, 78, doesn’t really tally with the indication from the preambles/synchronisation that each part is 8 bits. We now have to turn to a different encoding mechanism commonly used for this sort of cheap OOK device, Manchester encoding. This is better explained somewhere like http://www.quickbuilder.co.uk/qb/articles/, but the idea is that instead of counting the peaks and troughs as a high or low as you might when taking a look at it, we use the transition between high and low values in the middle of a set time period to define the 1 or 0.

As we have already altered our file to have a consistent spacing of 20 or 40 samples we can script reading this Manchester encoding easily by starting at the first state change position, measuring forward 39 samples and detecting whether the value increases or decreases in that time period and repeating this process until the end of the file.

This gives us the following binary output which looks very promising, we can see the matching patterns for the shared digits in the serial numbers between the tokens. The first 5 preamble bytes are the same, 6 is different, and 7 is the same matching the digit 0 in each of the tokens at position 2 with token 2 having two further digit 0’s all in bold.

Token 1: 11111111 01010101 10101010 01010101 00110110 00110001 00110000
Token 2: 11111111 01010101 10101010 01010101 00110110 00110100 00110000
Token 1: 00110001 00111001 00110011 00110010 00000000 10111011
Token 2: 00110000 00110111 00110000 00110011 00110000 11100100

Now converting each of these from binary to hexadecimal we get a match for ASCII characters so by adding an extra decode step to the script processing the file containing the resized signal, we can see the serial numbers they are broadcasting!

stats.py -i gqrx_20140905_134055_433900000-tag-101932.resize.wav -m
Manchester encoding, channel: 0 offset: 40 boundary: 40
ASCII: �U�U6101932

stats.py -i gqrx_20140905_134055_433900000-tag-400703.resize.wav -m
Manchester encoding, channel: 0 offset: 40 boundary: 40
ASCII: �U�U64007030�

So we have managed to go from a captured signal to decoding a beacon from an active RFID card in not too many steps. I’m not going to go in to any more details but it doesn’t seem a particularly secure security device on the evidence we have gathered here.

Now this would be a lot nicer if I could do it with GNU Radio as it is happening, but small steps!

Filtering a Capture with GNU Radio

So after the previous post where I was sending out a rather large sample, I had a look in to filtering things a bit. The first step in the doorbell example should have been to sample as low as possible to limit it to the minimum sample size.

In order to test filtering with GNU Radio, I captured a sample with a short transmission at +100kHz followed by another shortly later at +300kHz using the basic capture flow in the previous post and used this with a waterfall to observe the output. The goal was to filter out the +300kHz signal.

Searching for “filter” turned up a low pass filter which sounded about right, with a bit of trial and error with the “Transition Width” which didn’t work when set to 0 or a low figure we can see the output when the filter is set to 500kHz.

Low Pass Filter Flow500khz low pass filterChanging the cut off value to 150kHz shows the following where we can see the +300kHz signal has been filtered out.150khz filterWe can still see the band where it transmits and the signal outside the filter but I assume this is due to the strength of the signal in the original capture.

Trying this out adding the HackRF as a sink and listening with another receiver confirms that only the +100kHz signal is being transmitted with nothing heard on the +300kHz frequency.

I’d still like to figure out what the transition actually is, if anything at all is being transmitted outside the filter frequency and if there’s a way to have it filter in one direction from the centre frequency instead of both although for my purposes the filter above is enough.

Since writing this I’ve messed about with some of the other filters that also work well. I did run in to a problem with some GNU Radio 3.6 blocks being used instead of the 3.7 ones. For instance when trying to use the bandpass filter I received this error:

cannot import name firdes

Removing /usr/local/share/gnuradio/grc/blocks/band_pass_filter.xml did the trick here to get it working and let the 3.7 filter_band_pass_filter.xml be used. I did this for a couple of the blocks before removing all of the older dated ones, I’ve not seen any problems but a total clean up might be in order prior to a reinstall.

HackRF DoorBell Ringer Part 2 – Replay

Following on from capturing the signal in the previous post was to try a simple replay of the signal to see if it would set the doorbell off as expected.

For this we started off using hackrf_transfer, this receives data in to a file then transmits again from the file, perfect for a quick signal replay.

My first attempt at this was to simply set hackrf_transfer to record the signal centred on the frequency of interest 433.780Mhz.

Firstly capturing to a file:

hackrf_transfer -r 433780000.raw -f 433780000

Then transmitting from the file:

hackrf_transfer -t 433780000.raw -f 433780000 -x 20

Initially I hadn’t included a transmit gain option with -x so wasn’t seeing a signal when transmitting, this could have been reduced a bit.

Now the approach taken above did not work as expected. On looking at the signal transmitted by using an RTL-SDR device to see what was going on we can see a problem.

Hackrf_transfer no offset

The image above shows that capturing and transmitting on the same frequency has resulted in in a continuous signal being sent, the red line, through the middle of our real signal. This signal is on the exact same frequency the doorbell receiver is expecting the real signals and unsurprisingly the AM receiver doesn’t like a strong signal interfering so it didn’t ring.

The simple answer here is to offset the record and transmit frequency a bit, 20khz here, so the DC spike that exists in the middle of our recording isn’t where we’re wanting to transmit.

hackrf_transfer -r 433760000.raw -f 433760000
hackrf_transfer -t 433760000.raw -f 433760000 -x 20

As can be seen in the image below, by shifting the capture and transmit frequency 100khz away, the carrier of the spike is no longer on top of our signal and bing bong the doorbell rings!

hackrf_transfer offset

I tried to replay the signal with GNU Radio gnuradio-companion using an offset frequency and it also worked as expected and rang the doorbell first try.

Simple flow to capture to file.

Simple flow to capture to file.

The GNU Radio waterfall from the  capture

The GNU Radio waterfall from the
capture showing the signal (just)

Simple flow to transmit from file.

Simple flow to transmit from file.

The only problem with this is approach is it’s transmitting the full captured sample which could land us transmitting something unintentionally captured. So while it works and is quick, a better approach would include some filtering, I have a look at this in the next post here.

I’d also like to emulate the signal in GNU Radio as retransmitting isn’t that great but that’s a bit of learning away yet.

I uploaded a short video to youtube demonstrating the doorbell ringing.