Wrap-up: Hack-Lab 2017#2

What is a Hack-Lab?

Compass Security provides a monthly playful occasion for the security analysts to get-together and try to hack new devices, dive into current technologies and share their skills with their fellows.

This also includes the improvement of internal tools, the research of newly identified publicly known attacks, and security analysis of hardware and software we consider useful for our future engagements. This hack-lab took place in our office in Bern.

 

Topics

The following topics, tools and technology has been discussed during this Hack-Lab:

  1. Threat Modeling and Security Concept session
  2. CMS Assessment
  3. JWT4B development
  4. GnuRadio door bell analysis
  5. Windows Share Enumeration Tool
  6. Exploit.courses testing and training

Wrap-Up

Topic #1 -Threat Modeling and Security Concept session

In a combination of talks and hands-on workshop sessions, Thomas Röthlisberger shared his knowledge about threat modeling and security concept creation and analysis with colleagues.

Information Security fundamentals:

  • Security Foundations – CIA
  • Security Design Principles
  • Threat Modeling and Standards

Security Concepts:

  • Ownership and Data Classification
  • Architecture and Network Topology
  • Web Security Controls
  • Operational Security

Topic #2 – CMS Assessment

Using different available security and hardening scanners, we try to asses the security of three CMS: Drupal, Joomla, WordPress.

The goal is to find new vulnerabilities and possible test cases. We refresh and update our Compass Knowledge and improve our tool-set for CMS security assessments.

Technology:

  • Drupal
  • WordPress
  • Joomla
  • Web Scanners written in Python

Topic #3 – JWT4B development

We create a Burp plugin which helps the analyst testing apps which uses JSON Web Tokens (jwt.io).

The first step, which we performed in the previous hacklab, was to create a basic prototype, which enables Burp to visualize the tokens. During this hacklab we increased the functionality, implemented signature checking and interception functionalities.

Here a screenshot of the signature-checking functionality. The correct key was provided by the tester, which enables him to modify the JWT token comfortably:

Technology:

  • Java
  • JJWT (library)
  • JWT

Topic #4 – GnuRadio door bell analysis

We analyzed a wireless door bell with the help of GnuRadio and HackRF One. We captured the ASK modulated signal, and stored it as digital bitstream in a file. Afterwards we could successfully replay the stored bitstream, making the door bell ring. The next step will include to further analyze the bitstream. 

Technology:

  • GNU Radio
  • HackRF One SDR
  • Kali Linux

Topic #5 – Windows Share Enumeration tool development

If a pentest is performed in a large environment, it is possible that hundreds of accessible Windows shares are available in the network. The goal is to create a tool, which supports us during our penetration tests. Our tool should display the following information for every share in the network:

  • IP Address
  • Hostname
  • Share Name
  • 20 top level files and directories
  • ACLs for the top level files and directories

We managed to implement this tool by combining  Linux Samba tools (smbclient, smbcalcs) in an advanced shellscript.

Technology:

  • Windows, filesharing, network share
  • ACL, Permissions
  • masscan
  • samba / smbclient / smbcacls
  • Linux, Shell, Scripting

Topic #6 – Exploit.courses testing and training

Dobin Rutishauser teaches the “Exploiting & Defense” part of the Application- and Software-Security module at the Bern University of Applied Sciences (Berner Fachhochschule). For this assignment he created a website which provides writeups and challenges to be solved by the students. It also hosts dedicated per-user Linux container, accessible via JavaScript terminal. The Hack-Lab was used to check the website for usability problems, resistance against local DoS attacks, security problems and also basic functionality checks. We also performed a review of some of the writeups, where the team members solved several of the challenges. This includes the ARM buffer overflow challenge, and an extended version of the shellcode development challenge.

The team could identify several small bugs, some small mistakes in the writeups, and gave valuable usability improvement feedback.

Technology:

  • qemu, LXC / LXD
  • x86, x64 and ARM
  • gdb, readelf and python
  • AngularJS and go

Making of Compass bIOTech v1.0

The “Internet of Things” (IoT) grows quickly. More and more devices are connected to the Internet to automate tasks and simply life. Fridges automatically order milk, cars are taught to self-drive via a simple update and bridges send live updates about their structural integrity.

According to Gartner’s 2016 Tech Trends, IoT will define the shape of tomorrow’s business. At Compass, we also appreciate the impact of connected devices in the near future, in terms of how they can make our lives easier, and how they can make our information more exposed. With this in mind, we recently opened a new security training on the basics of IoT and their vulnerabilities.

Compass bIOTech v1.0 is our own piece of Hardware in the grand IoT puzzle of devices. This smart device has been designed to measure the moisture level of plant pots using a capacitive sensor. It then connects to the cloud (Hacking-Lab) and an e-mail alert can be sent in case of low humidity level.

But before it reached its v1.0 state, the Compass bIOTech sensor went through multiple stages of development between an original idea and its realisation:

1 – Idea

To give a little life to your office, or to make your living room livelier, green stuff is always a nice addition to your everyday environment. Problem: these things need attention! We all at some point forgot to water a plant, and came back after a day, a weekend, or a longer holiday to find it dried out.

imag0048

The plant of Ivano, at Compass Office Bern

At Compass, we decided to tackle this problem and to grow ourselves a green thumb, green like a circuit board! With no time to spare, Reto Schädler started the design, with a few necessary features in mind:

  1. one must be able to configure the device’s humidity threshold,
  2. a status should be readable directly on the device,
  3. the thing must communicate with a cloud,
  4. the battery should last long.

2 – Circuit Board Design

Schema Compass bIOTech v1.0

Schema Compass bIOTech v1.0

The capacitive humidity sensor consists of a circuit path that is charged via the resistor R5. Using this, we can measured how long it takes until the voltage is half of the operating voltage.

The 32bit ESP8266 Microcontroller Chip is based on the Arduino development environment and has built in Wifi capabilities. It requires an operating voltage of 3.0 – 3.6 Volt and runs at 80MHz.

Since the two AA-Batteries have a voltage level at max. 3V, a Step-Up Convert to 3.3V is necessary. And because of the required battery life time, a Wake-Up chip is used to cut power supply via MOSFET.

Versuchsaufbau Compass bIOTech v1.0

Prototype Compass bIOTech v1.0

3 – Realisation

pcb_both

Left: PCBA 3D Altium Designer, Right: Compass bIOTech v1.0 PCBA

In configuration mode, the chip serves as a Wifi AP and provides DHCP to connecting devices and a web GUI for configuration purposes. In measurement mode, the device connects to the configured SSID/password and submitts moisture level, battery level and firmware version to a dedicated Hacking-Lab services.

 

4 – Where to get your own bIOTech device

We will be giving away a first bunch of bIOTech devices at Swiss Cyber Storm on October 19th in Lucern. Visit the conference and walk by our both. We will be glad to equip you with your own green thumb.

For those who can’t make it to the conference, stay tuned and sign-up for our next IoT security training where we will tinker with the devices interfaces and security issues.

 Grab’em while they’re hot!

Software Defined Radio (SDR) and Decoding On-off Keying (OOK)

This post will give a quick intro into software defined radio (SDR) basics and provide guidance for the decoding of a very simple form of digital modulation (on-off keying).

Device Wireless Specs

Wireless junk hacking is not too difficult. Usually, devices transceive in the 433MHz or 868MHz ISM radio bands. As these bands are somewhat lax with licensing all devices operating in these bands must be capable of tolerating interferences of other band users. Pretty much comparable to the Internet 🙂 The European communications office (ECO) maintains a list of bands for European countries, including Switzerland. The list provides information allocated ranges and its specific purpose e.g. 5000MHz to 5030MHz is reserved to the GALILEO global navigation satellite system (GNSS) project.The US make it even simpler to get up to speed with any junk’s wireless configuration (frequency, modulation types and line coding). Every wireless device approved for the US market must carry an FCC ID. The online catalog provides access to the wireless specs of the devices based on its ID (usually printed on the device’s back or specification sticker).

Radio Observation

Alexandru Csete’s gqrx software defined radio comes in as a handy spectrum analyzer when looking for exact frequencies. It’s mainly based on the GNU radio project and supports all well-known platforms (Ettus USRPs, BladeRF, HackRF, RTL chipset et. al).

For the devices I have at hand (light switches, temperature and humidity sensors, car keys, M-Bus transmitters) it worked out they all operate in the 433MHz and 868MHz bands and can be easily observed with gqrx.

decoding_onoff_keying_gqrx

The spectrum analyzer (mouse tooltip) tells us that the specific light switch is operating at 433.93 MHz. An interestingly enough gqrx supports other fun and geek stuff such as listening to FM radio or eavesdrop on road work and building site radio conversations.

Signal Capturing

Well, signal capturing slightly varies depending on the device and library you use. The device I used for this tutorial is originally an DVB-T USB stick but comes with the relevant Realtek RTL2832 chipset and goes for a few bucks on most major reseller platforms. Check the supported hardware list at the gnuradio site. Hat tip to the Defcon Switzerland folks who provided me with one for cheap.

The following lines give an idea on how to capture signals with the Realtek chipset family of devices.

bla@bli:~$ rtl_sdr -f 433850000 -s 1000000 -g 20 switch.cu8
 Found 1 device(s):
 0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
 Found Rafael Micro R820T tuner
 Exact sample rate is: 1000000.026491 Hz
 [R82XX] PLL not locked!
 Sampling at 1000000 S/s.
 Tuned to 433850000 Hz.
 Tuner gain set to 19.70 dB.
 Reading samples in async mode...
 ^CSignal caught, exiting!

User cancel, exiting...

Make sure not to capture at the exact determined frequency of the device but rather slightly above or below as the internal synthesizer will otherwise interfere and overlay the signal. Note, that we chose to sample the signal at a rate of 1 million samples per second (1 Msps) and the output I/Q data was stored in the cu8 format. Some tools create outputs as complex signed int (.cs8, HackRF), others as complex unsignend int (.cu8, RTL) and GNU radio prefers complex float format (.cfile). There is a GNU Radio Companion (GRC) template and Paul Brewer’s rtlsdr-to-gqrx tool for conversion from .cu8 to .cfiles, should one need to pivot between the file types.

Alternatively one could use gqrx and record or replay signals in cfile format (Menu bar => Tools => I/Q recorder, CTRL-I). Note: Replay doesn’t transmit your signal but displays your capture within gqrx.

Signal Inspection

I used inspectrum to inspect my capture files. Once loaded, the capture coloring needs some tweaking but usually gives good hints on simple modulation, codings (e.g. Manchester) and the signal’s symbol rate.

decoding_onoff_keying_inspectrum_load

Usually, slight zoom and adjustment of power max an min sliders allows to easily discover the on-off keying modulation used in the example. Set the correct sample rate and drag the grid over the signal in order to determine the symbol rate of the signal.

decoding_onoff_keying_inspectrum_symbols

The symbol rate of the switch signal is 1631 Hz. Scrolling through the capture will also reveal that the on and off signal of the switch only differ in few locations, share the same bit heading and are being sent multiple times in a sequence. Pressing the button once obviously results in three or more transmissions of the on or off signal.

Signal Decoding

The GRC is the tool of choice for simple digital signal processing. It provides a building block GUI that allows for quick design of processing flows. The following design serves as a quick and dirty approach for OOK demodulation.

decoding_onoff_keying_grc

The relevant variables for the decoding are the sample rate (samp_rate: 1 Msps) and the symbol rate (baud_rate: 1631 Hz) which must be set to the values determined before.

The file source points to .cfile version of the previously captured signals and feeds data into a throttle block to avoid infinite processing speed. The “Complex to Mag^2” and “Threshold” blocks will convert the signal wave forms into a rectangular pulse of ones and zeros. Note, that the data type switched from complex (light blue) to float (orange) with the “Complex to Mag^2” block.

The “Keep 1 in N” block will assure the one bit is represented by a single data point. N is computed as samp_rate/baud_rate. Note, such rough way of signal processing may not work with signals that slightly vary the baud rate or with long lasting sequences. Even with short signals one must expect small errors. The scope sink then displays the decoded binary values.

decoding_onoff_keying_grc_scope_plot

Compare the scope plot to the previous inspectrum screenshot and you will notice that the demodulated signal actually compares with the figure in inspectrum.

Signal Analysis

GRC Visualization Support

None of the visual sinks in GRC provide easy means to visualize binary streams and adjustments to easily spot patterns and variations between streams. Thus, I decided to come up with a custom out-of-tree module for binary visualization and inspection, in short BinViz.

The initial GRC project requires small justifications to feed data into BinViz instead of the WX GUI Scope.

decoding_onoff_keying_grc_binviz

The “Float to Char” block will convert float values into 0x00 and 0x01. Moreover, the “Unpacked to Packed” block will squeeze eight chars into a single byte (e.g. 0x00 0x00 0x00 0x01 0x01 0x01 0x01 0x01 => 0x1F) and feed this into BinViz.

BinViz Configuration

Parameters start, end and drop patterns allow for justification of how streams are displayed and aligned. These parameters take strings composed of 0s and 1s e.g. 01010101 as a preamble or start pattern. The display will start on a new line for each occurrence of the start pattern. On detection of the end pattern the display will wrap to a new line. In case both, the start and end pattern are defined, the display will drop any out-of-bounds bits and only display streams from start to end on a single line each. Once the start pattern is being detected additional occurrences of the pattern will be ignored until the end is detected.

To get rid of long sequences of zero bytes or arbitrary unwanted bit sequences set “skip zero bytes” to true or define a string of 0s and 1s for the drop pattern to be removed. Note, the drop pattern and “skip zero bytes” have precedence over start and end detection patterns.

decoding_onoff_keying_binviz_example

The display itself allows for some semi-live adjustments and manual analysis. E.g. the mouse wheel on the display allows to zoom-in and zoom-out while new bits are being displayed instantly. Once the display is clicked it will stop painting new bits and display a cursor and its x/y-position. In that mode, one could easily count bits or select part of the bitstream for magnification and closer inspection.

Visual Signal Analysis

Earlier analysis using inspectrum lets us observe six occurrences of the on signal when switching on and further six occurrences of the off signal when switching off. For this type of wireless junk it is probably irrelevant how many times the receiver picks up the signal. As noted earlier it is rather a matter of resilience towards other ISM band users to send the signal multiple times. Just to make sure its being picked up, sooner or later.

decoding_onoff_keying_binviz_sequence

BinViz was configured “11010011” for the start and “1001001001001001001” for the end pattern. That way, only relevant data is displayed. Thanks to BinViz capabilities the six on and off signals are easily recognizable as single rows. Moreover, the the differences between the on and off signals is immediately clear.

Looking forward for you contributions https://github.com/CBrunsch/BinViz

Hands-on, IoT Security Training

If you need more hands-on with junk hacking or analysis of IoT devices then you are very welcome to join us for our brand new practise oriented training on “IoT Security” held in German at the Compass head office in Jona on September 20th/21st 2016. Sign-up here.