Experimenting with Software Defined Radio

In this blog post, I will describe my first project experimenting with a software defined radio (SDR). For those of you new to this technology, think of it as an RF frontend to your computer, which performs most signal processing from digitized radio waves in software. Hence, virtually any radio communication system can be implemented given capable software. There is already a plethora of projects for a variety of RF applications related to industry or consumer standards. The CGRAN maintains a list of projects, have a look at it to get an idea of what's all possible.

The test hardware

So, to become acquainted with the SDR, I chose to analyze this simple RF controlled power switch system I found at my local supermarket. The package contains three radio controlled connectors with a pass through socket for the electrical appliance. The remote control individually switches the connectors on and off by pressing on the corresponding buttons. When switching a controller on and off, the clicking sound of a relay is clearly audible.

Power Switch System 1204380 3M from Steffen AG

Anatomy of the controller

The remote and the connectors are both configured via dip switches inside the enclosure. The address scheme comprises a 5 bit system code (positions 1 to 5 in the pictures below), commonly used by all devices. Also, a unit code (positions A-E) is assigned to each of the connectors to individually address them. Interestingly enough, position E is not provided on the remote, instead, there is a master on/off switch that addresses all units at once.

Dip switches for the selection of the system code (common to all devices)
and the unit code (individual to each connector)

On the back of the remote control, the model number and most interestingly, the operating frequency 433.92MHz are engraved on the enclosure. Within the enclosure, a PCB with a single IC labeled AZ08C20, P50 0322D. Unfortunately, I couldn't find any specification for this chip that would ease the task of analyzing the control signal. There are specifications publicly available for similar ICs that helped me grasp the encoding principle: for example Princeton Technologies PT2262 and PT2272, and Holtek HT12A and HT12E.

 

The remote control's IC:
AZ08C20 P50 0322D

Visualizing the signal

For this, I designed a GNURadio flowgraph. The source block provides the data from the SDR. Use either a UHD source for USRP devices from Ettus Research or else a OsmoSDR source for USB DVB-T dongles, BladeRF or HackRF. The data provided by the source is a stream of complex I/Q values, represented by pairs of 32bit floats. If you're not familiar with I/Q data, here are two excellent write-ups to learn about this data format and why it's used for SDRs. After reading this, you'll understand how the Complex to Mag^2 block is used to convert the complex I/Q samples into a real, scalar magnitude sample. The Threshold block is used to distinguish between HIGH and LOW states of the signal. Both real and discrete signals are input to the Scope Sink for the visusalization. The Wav File Sink is used to create a .wav file which can then be analyzed using common audio processing software such as Audacity.

GNURadio flowgraph used to visualize the signal

In the scope visusalization, we can see that the amplitude of the carrier frequency is modulated to form pulses of varying widths. This modulation scheme is called (binary) amplitude shift keying (ASK) or also sometimes On-Off-Keying (OOK). The encoding is a discretization of pulse width modulation (PWM), where pulses of different widths represent different information symbols. I determined the duration of the short (unit) pulse to be 533µs by measuring the number of samples across its width. The long pulse is twice as long: 2*533µs = 1.066ms. The blank between each pulse is of same duration as the unit. Effectively, each pulse starts after a period of 3*533µs = 1.6ms. Messages are continually sent in bursts of 25 pulse periods with a pause of 3.2ms inbetween, for a total of 128ms per message.

Replaying the signal (security implications)

Having recorded the signal as .wav file or as raw data, the flowgraph can be reversed to replay the messages. Choose the Wav File Source and connect it to your SDR sink (either UHD Sink or OsmoSDR Sink). This already suffices to trigger the switch. This indicates that there is no security whatsoever to protect the connectors from receiving messages not originating from the remote control. Also note that the number of possible different addresses (given by the combination of dip switch positions) is very low, 2^5 = 32, hence an attacker can very rapidly guess it by running through all possibilities.

Reverse-engineering

Assigning a short pulse to 0 and a long pulse to 1, I wrote down the different code patterns while pressing each button and systematically changing the dip switch positions. I could not identify every bit's meaning in these patterns, but I retrieved enough information to synthesize message which would actually trigger the switch. Here are some examples having all dip switches for the system code on HIGH:

                         DIPSW ????? ?????? B ?? EDCBA  ?
A         OFF            11111 00011 100101 0 00 00001 0
B         ON             11111 00011 100111 1 00 00010 0
B         OFF            11111 00011 101000 0 00 00010 0
C         ON             11111 00011 101001 1 00 00100 0
C         OFF            11111 00011 101010 0 00 00100 0
D         ON             11111 00011 101100 1 00 01000 0
D         OFF            11111 00011 101100 0 00 01000 0
Master    ON             11111 00011 101101 1 00 00000 0
Master    OFF            11111 00011 101110 0 00 00000 0

So obviously, the dip switches are reflected by the 5 first bits in the message. The 17th bit always correlates with the on (1) and off (0) button. Finally, bits 20-24 reflect the unit code. Concerning the remaining bits, I suspect bits 11-16 to be a counter and the rest to be padding.

Synthesizing the signal

After gathering all this information about the signal and the encoding, I decided to write a small GNURadio application with python to replicate the remote control in software by emitting the signal from the SDR. You can access the code here on github. The basic idea behind the modulator is to process the incoming stream of bits and converting them into I/Q samples. In order to describe the pulse train, I defined a intermediate 2-bit mapping according to following diagram, which will help you understand the code:

Intermediate 2-bit encoding of the pulse-widths

Using this mapping, a logical 0 is encoded with 01, a logical 1 is encoded with 10 and the pause between each burst is encoded with 00. Note that code 11 is never used. The GUI is designed to resemble the remote control's interface:

Application replicating
the remote control. Uses the
GNURadio framework

 That's it, I hope you enjoyed reading this. If you did, don't miss the flattr button ;-)

UPnP P0wnage

I've been enjoying some really good podcasts lately, in particular Security Now!. I was listening to episode 389 this morning about UPnP when I realized that I neither understood the technology, nor did I know if my home router provided this feature, if it was enabled and as such if it was prone to attacks discussed in the episode.

UPnP is a convenience service used to query and control network devices in a LAN without a hassle... meaning without proper authentication and access control. Which is perfectly fine in the context of your home LAN under the assumption that access will be granted only to trusted clients. The problem is: a lot of routers fail at blocking the UPnP port (UDP 1900) on the public WAN interface, making your router accessible to the entire internet. And then, most router products employ outdated, vulnerable UPnP frameworks for which a lot of exploits are publicly available. So think about the consequences: your router is your gateway to the internet, it handles all traffic to and from your laptops, tablets and iphones, and it is probably always on... it's the perfect jumpstation for man-in-the-middle attacks.

There are several online tools to check whether your router has UPnP enabled and if it is vulnerable to corresponding attacks, e.g. here or here. If you prefer testing it yourself, get a recent version of nmap, and type this into your console:

$ sudo nmap -Pn --script upnp-info.nse -p 1900 -sU 10.0.0.1

Starting Nmap 6.25 ( http://nmap.org ) at 2013-05-14 00:22 CEST
Nmap scan report for 10.0.0.1
Host is up (0.0010s latency).
PORT     STATE SERVICE
1900/udp open  upnp
| upnp-info: 
| 10.0.0.1
|     Server: Linux/2.6.12, UPnP/1.0, NETGEAR-UPNP/1.0
|     Location: http://10.0.0.1:5000/Public_UPNP_gatedesc.xml
|       Webserver: Linux/2.6.12 UPnP/1.0 NETGEAR-UPNP/1.0
|       Name: WGR614v9
|       Manufacturer: NETGEAR, Inc.
|       Model Descr: Wireless-G Router
|       Model Name: WGR614v9
|       Model Version: WGR614v9
|       Name: WAN Device
|       Manufacturer: NETGEAR, Inc.
|       Model Descr: Wireless-G Router
|       Model Name: WGR614v9
|       Model Version: WGR614v9
|       Name: WAN Connection Device
|       Manufacturer: NETGEAR, Inc.
|       Model Descr: Wireless-G Router
|       Model Name: WGR614v9
|_      Model Version: WGR614v9
MAC Address: C0:3F:0E:2D:12:F8 (Netgear)

The response to the discovery packet sent by nmap already contains various informations about the device, notably the webservice endpoint to which clients can address their UPnP calls (this is the actual vulnerable service). Also very interesting, the string "UPnP" occurs in the webserver banner. This makes it very easy to search for potential targets using a metadata search engine.

The best countermeasures for this insecurity is to keep your router firmware up to date and disable the UPnP feature. Better do it soon :-)

LinkedIn Password Data Leaked

As reported by several security related online portals, a file with approx. 6.5 mio SHA-1 password hashes from LinkedIn users is currently circulating the web. I could easily get ahold of a copy of that 250 Mb file through bittorrent and realized that my password matched an entry :(.

Here's how you can check:

$ echo -n "password" | shasum
$ grep 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 SHA1.txt
$ grep 000001e4c9b93f3f0682250b6cf8331b7ee68fd8 SHA1.txt 
000001e4c9b93f3f0682250b6cf8331b7ee68fd8

As mentioned here, a subset of the hashes are marked with 00000, presumably to identify already cracked passwords. You should therefore check both variants as shown above.

If your password matches, you should change your LinkedIn Password asap and then change your passwords everywhere where you reused it (especially for popular platforms like Facebook, Google or Amazon).

Did you just email me back my own password?!

A while ago I wrote a blog post about what precautions to take handling password data on your website. plaintextoffenders.com is a website dedicated to this issue. It nicely points out why storing passwords in plaintext really is such a bad idea. The main part of the website is a pillory of submitted websites which obviously apply bad password practices. There's for awareness...

Password Security 101 for Web Developers

Passwords are still the only mean of authentication for I'd say 99.95% of all online services including social networking sites, online shops and even e-banking applications. When you think about the consequences of a password theft, say for your personal email account, you'll soon realize that a password such as 123456, iloveyou or your mom's birthdate is totally insufficient... (see this and change your password everywhere if you get a match).

There a lots of articles that will tell you what a (more) secure password looks like (I especially like this one as well as it's illustration). And although many web sites will impose some password policy during registration that will reject any password unless it contains some digit or special characters, the choice (and the complexity) is ultimately left to the user. What's unavoidable is that users are almost certainly going to reuse at least one password sometime for one or the other online service. Haven't you also? (don't blush).

So what can you as a developer do about it? I don't know, but I can tell you what you should totally avoid if you don't want yourself and your company to be looked at as total newbs.

First realize that passwords are the user's good and you are due to treat that information with absolute care. Every single one of your clients has spent the effort of selecting some unnatural string, repeating the process until it complied with your password policy and spending the rest of the day trying not to forget it. This is the reason why user's will eventually reuse a password. So bear in mind, that you're not storing a user's password for your web application only, but most probably also for a number of other services the user has registered to. Respecting your client's integrity means that you will never disclose that data, not even internally within your company.

The most important precaution you should take when dealing with password data is: never ever store passwords in clear text. No system is safe enough, not even yours. And the risk's not worth it. If you don't know how to avoid storing passwords in clear text, learn about hash functions and salting.

Second rule: never ever send a password back to the user (for instance via email). This is totally unprofessional. You're not only showing your client that you're storing passwords in clear text (i.e. that you're a newb), you're also compromising his password by sending it over an unsecure channel.

I assume companies do this to reduce support cases related to lost passwords. They should rethink it all over. Recent attacks have shown how much damage is caused to the company (reputation) as well as to their clients by having confidential user data stolen. Think about RSA, the Sony Playstation network or recently Youporn (should you not know, the most popular pornographic website)...