I recently purchased a BladeRF for cellular security research with srsRAN and YateBTS. Jumping straight into using these programs without a strong background in software defined radio (SDR) can feel like trying to run before you can walk – especially when debugging PHY layer issues. Today I will brush up on the fundamentals by exploring a much easier target: my fan remote. Projects like srsRAN use SDRs as an physical interface to the air. More specifically they use a SDR’s library bindings to send and receive I/Q data (YouTube link) on select frequencies in order to synthesize and receive arbitrary signals. For simpler projects, its best to use software that abstracts away from these bindings and gives a friendly set of libraries and tools to explore with. In this blog I show how I used GNU Radio, GQRX and Inspectrum to identify, capture, replay, decode, synthesize, and virtualize the signals coming from my remote.

Have you ever wondered how your smartphone communicates over-the-air? How calls and SMSs reach your phone from across the world? What about how your phone decodes over-the-air messages? Does it do it correctly and what happens if it doesn’t? Well these answers and more lie within the 2 - 5G cellular protocols and their implementations. Understanding and setting up a cellular testbed for this kind of exploration can be a difficult and frustrating process. Without a background in signal processing, cellular protocol conventions, or the right equipment, debugging why a cellular testbed isn’t working can be a pain, to say the least. In this tutorial we’re going to detail the exact steps my guest author Tyler Tucker and I took to get a 2G (GSM) and 4G (LTE) testbed up and running. In cellular terminology these are known as the BTS and eNodeB for GSM and LTE respectively, but throughout we’ll stick with base station. To get a base station up and running you need two things: a software defined radio (SDR) for the radio frontend and a software station implementation that can talk to your SDR.

This article documents my personal experiences with CCDC. The opinions expressed are my own.

I’ve had the privilege of participating four times in the Collegiate Cyber Defense Competition across five years. During my time as a competitor, I learned volumes about system administration and working together with a team. My primary role was Linux administration and hardening, but other roles rubbed off along the way giving me a broad view of the competition.

If you are not too familiar with CCDC, here is the overview: CCDC is a blue-team network and business simulation run in the United States, which fills a distinct niche compared to more traditional security competitions like CTFs by focusing on network fundamentals, service management, incident detection & response, and communication. Universities from around the nation compete in this yearly event with the hope of winning the National title. The gist of the competition is as follows: you are a newly hired IT team tasked to bring a business’ network into a secure and known state as quickly as possible. The catch is that you have multiple bosses breathing down your neck, assigning you business tasks (known as injects) quicker than you can complete and an active red-team (professional penetration testers) breaking down the doors of your network and trying to keep your services down. Teams are thrust into this overflow of tasks and events and scored on their performance. Although it may sound like volunteering to become a piñata, playing in CCDC is some of the most stressful fun you can have. You have to experience it for yourself to truly understand the continual adrenaline rush of jumping into an unknown, broken, red-team infested, network of machines.

Sound fun? Great! So how do you get started? In my case, my undergraduate university, the University of Central Florida, started its own security club, Hack@UCF, also known as the Collegiate Cyber Defense Club on paper. The club’s primary directive was to form a team to play in CCDC. I joined the club immediately given my interest in cyber security and I decided to give CCDC a go. This turned out to be one of the best decisions of my undergraduate career.

When I heard about the emergency disclosure of CVE-2019-2215 by Project Zero, I decided to replicate the exploit on my local device to see it in action. I so happened to have a vulnerable Pixel 2 with the exact kernel version as my main device (don’t hack me). All I needed to do was compile the exploit and run it over ADB. I downloaded the latest Android NDK and compiled the proof of concept:

[grant ~/Downloads/android-ndk-r20 >> ./toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android29-clang -o poc ../poc.c
[grant ~/Downloads/android-ndk-r20 >> adb push poc /data/local/tmp/poc
poc: 1 file pushed. 0.8 MB/s (22528 bytes in 0.026s)

I ran it on my device and confirmed that I was able to reproduce Maddie Stone’s screenshot exactly.

The base PoC left us with a full kernel read/write primitive, essentially game over for the systems’ security, but left achieving root as an exercise for the reader. This raises the question, what does “root” really mean for a modern Android system? To answer this, we must first understand how Android enforces its security policies.

Welcome to a journey of AArch64 kernel exploitation, from the least privileged, to the most secure privilege level on the ARMv8 platform. For this year’s HITCON CTF, I played with my academic team, Kernel Sanders. When scanning through the problems, I quickly latched on to the Super Hexagon challenge once I heard it involved ARM exploitation. Here is the challenge prompt:

Super Hexagon
Escape each level for your six flags.

EL0 - Hard
EL1 - Harder
EL2 - Hardest
S-EL0 - Hardester
S-EL1 - Hardestest
S-EL3 - Hardestestest

nc 54.64.96.126 6666
Author: sean, atdog

Super Hexagon - 1: 39 Teams solved.
Super Hexagon - 2: 9 Teams solved.
Super Hexagon - 3: 4 Teams solved.
Super Hexagon - 4: 2 Teams solved.
Super Hexagon - 5: 1 Team solved.
Super Hexagon - 6: 1 Team solved.

Backing up or moving a VMWare Fusion VM to an external hard drive is usually no problem - except when your destination filesystem is FAT-32.

I use FAT-32 on my external drives for maximum compatibility between Mac, Windows and Linux. Unfortunately, FAT-32 is quite dated and doesn’t allow any file larger than 4GiB.

One night while playing Counter Strike: Condition Zero (CZ), I decided to take a break and challenge myself to find an exploitable bug in the old engine known as GoldSrc. Condition Zero, Half-Life 1, and CS 1.6 all run on the GoldSrc engine, which was created by Valve and is based upon the original Quake engine.

What makes Counter Strike an interesting target is that it relies on a game lobby for players to find and select servers to play on. Upon connecting to the server, the game client will automatically download any required resources (maps, textures, sounds, etc.). Once all of the resources have been downloaded, they have to be loaded and parsed from disk into memory. Only then will the client begin receiving commands and entity updates from the server.

This automatic resource fetching looked like the ticket to a remotely exploitable vulnerability via a local file.

The vulnerability discussed in this article has been disclosed to Valve Security and the patch publicly deployed on July 10th.

I would like to extend my thanks to the Valve Security team and specifically to Alfred Reynolds who was my liaison during the disclosure process. The whole process, from initial email to fix, lasted less than 30 days. I certainly look forward to disclosing to Valve in the future.

This is a follow up to my previous post on creating a CRC-32 chip from scratch using Cadence. Check it out as it goes over the design details.

tl;dr: see die shot images

After submitting my CRC-32 design to MOSIS for fabrication, I had to wait quite a while for the results (over 6 months), but considering it was

1. Free
2. An actual chip that I can physically hold in my hands
3. Something I designed myself from scratch

I was willing to wait. The wait was finally over in late December of 2015.

We are given a PCAPNG file with a bunch of USB packets. By scanning through the PCAP, I noticed that there appears to be a large amount of URB_INTERRUPT packets after some initial configuration and setup. On a hunch, I immediately suspected either a USB keyboard or mouse due to the amount of data and the fact that all incoming packets were created from interrupts (i.e some kinda of slow I/O device driven by a human).

While looking at the packets, I initially assumed this was a keyboard as it would be straight forward to hide a flag in keyboard data. I tried the obvious choice and googled for some Python that already solved this problem and I came across this keyboard PCAP parser. I noticed that the offsets used in the file were not close to the size of the packets I was seeing, so I did some more research on USB HID devices and I came across this great page on USB mice packets.

The packet structure described here matched what I was seeing in the PCAP data. I confirmed this by looked for a USB descriptor packet from the device. I found the right packet at number 84 (below).

No. |   Time   | Source | Dest | Protocol | Length | Info
----+----------+--------+------+----------+--------+------------------------------
84  | 6.505211 | 1.3.0  | host |   USB    |   46   | GET DESCRIPTOR Response DEVICE

The device descriptor decoding showed that this was definitely a mouse.

This semester at UCF I enrolled in a 5000 level (graduate level) Very Large Scale Integration (VLSI) class entitled EEE5390 “Full-Custom VLSI Design”. It caught my eye back in the Spring of 2014 when I noticed another student’s screen as they designed a chip. The mash-up of colored rectangles and wiring intrigued me. Later I learned that the best designs would actually be fabricated through MOSIS, a university chip fabrication service. This was a big pull in my decision to take the class – how often do you get to say your design is baked in to a working piece of silicon?

With that, I decided to give it a shot this spring.

This week a friend of mine suggested that I make something cool with bitmaps. Normally most of the code I write is pretty low level, but I’ve gotten more and more interested in graphics. So, I thought of an interesting idea and challenged myself to implement it. Here are some of the results:

My previous experience with exploitation from the IO wargame on Smash the Stack led me to choose this challenge as my first target in the CSAW competition.

The challenge text is such:

nc 128.238.66.218 54321
Read the key out of ./key in the current working directory.

I/O Analysis

Okay, lets run the command and see what type response we get. Note: on my machine `nc’ is `ncat’ because I am using the version that comes with nmap:

$ ncat 128.238.66.218 54321
Wecome to my first CS project.
Please type your name:

I’ll take that misspelling as subtle humor. This seems pretty straight forward: we give the program a specially crafted input name and it gives us the key. Time to investigate the executable.

After downloading the executable, I use file to get some information:

thinkfast ~/learning/csaw-2012 $ file csaw2012reversing
csaw2012reversing: ELF 64-bit LSB executable, x86-64, ...

Uh oh. My system is 32 bit and I don’t have any cross compilers installed. Luckily, I have an Amazon AWS account. I spin up a generic Ubuntu 64 bit micro instance, transfer the file, and begin investigating.

A quick run of the program prints the target key, but it’s encrypted. No command line arguments are accepted, therefore this problem requires a patch.