PoC or GTFO, Volume 2

PoC||GTFO

VOLUME 2

THE BOOK OF POC||GTFO, VOLUME 2.

Copyright © 2018 by Travis Goodspeed.

While you are more than welcome to copy pieces of this book and distribute it electronically, only No Starch Press may produce this printed compilation commercially. Feel free to photocopy these articles for classroom use, or just to do your part in the самиздат, tradition.

Printed in China

First printing

22 21 20 19 18    1 2 3 4 5 6 7 8 9

ISBN-10: 1-59327-934-5

ISBN-13: 978-1-59327-934-9

For information on distribution, translations, or bulk sales, please contact No Starch Press, Inc. directly:

No Starch Press, Inc.

245 8th Street, San Francisco, CA 94103

phone: 1.415.863.9900; [email protected]

www.nostarch.com

No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc. Other product and company names mentioned herein may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurrence of a trademarked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

The information in this book is distributed on an As Is basis, without warranty. While every precaution has been taken in the preparation of this work, neither the author nor No Starch Press, Inc. shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in it.

This is not a book about astronomy; rather, this is a book about telescopes.

Contents

Introduction

9 Elegies of the Second Crypto War

9:1 Zen and the Art of PoC

9:2 From Newton to Turing by Manul Laphroaig

9:3 Globalstar Satellite Comms

by Colby Moore

9:4 Pool Spray Tips

by Peter Hlavaty

9:5 2nd Underhanded Crypto

by Birr-Pixton and Arciszewski

9:6 Cross-VM Side Channels

by Sophia D’Antoine

9:7 Antivirus Tumors

by Eric Davisson

9:8 Brewing TCP/IPA

by Ron Fabela

9:9 APRS and AX.25 Shenanigans

by Vogelfrei

9:10 Galaksija

by Voja Antonić

9:11 Root Rights are a Grrl’s Best Friend

by fbz

9:12 What if you could listen to this PDF?

by Philippe Teuwen

9:13 Oona’s Puzzle Corner

by Oona Räisänen

10 The Theater of Literate Disassembly

10:1 Please stand; now, please be seated

10:2 The Little, Brown Dog

by Manul Laphroaig

10:3 Pokémon Plays Twitch

by DwangoAC, Ilari and P4Plus2

10:4 This PDF is a Gameboy exploit

by Philippe Teuwen

10:5 SWD Marionettes

by Micah Elizabeth Scott

10:6 Reversing a Pregnancy Test

by Amanda Wozniak

10:7 Apple ][ Copy-Protection Techniques

by Peter Ferrie

10:8 Reverse Engineering the MD380

by Travis Goodspeed

11 Welcoming Shores of the Great Unknown

11:1 All aboard!

11:2 In Praise of Junk Hacking

by M. Laphroaig

11:3 Star Wars on a Vector Display

by Trammell Hudson

11:4 MBR Nibbles

by Eric Davisson

11:5 E7 Protection of the Apple ][

by Peter Ferrie

11:6 A Tourist’s Guide to Cortex M

by Goodspeed and Speers

11:7 Ghetto CFI

by Jeffrey Crowell

11:8 A Tourist’s Guide to MSP430

by Speers and Goodspeed

11:9 The Treachery of Files

by Evan Sultanik

11:10 In Memory of Ben Byer

by FailOverflow

12 Collecting Bottles of Broken Things

12:1 Lisez Moi!

12:2 Surviving the Computation Bomb

by Manul Laphroaig

12:3 Z-Wave Carols

by Badenhop and Ramsey

12:4 Comma Chameleon

by Krzysztof Kotowicz, Gábor Molnár

12:5 A Crisis of Existential Import

by Chris Domas

12:6 Network Job Entries

by Soldier of Fortran

12:7 Ирония Судьбы

by Mike Myers and Evan Sultanik

12:8 UMPOwn: Ring 3 to Ring 0 in 3 Acts

by Alex Ionescu

12:9 A VIM Execution Engine

by Chris Domas

12:10 Doing Right by Neighbor O’Hara

by Andreas Bogk

12:11 Are Androids Polyglots?

by Philippe Teuwen

Charade des temps modernes

13 Stones from the Ivory Tower, Only as Ballast

13:1 Listen up you yokels!

13:2 Reverse Engineering Star Raiders

by Lorenz Wiest

13:3 How Slow Can You Go?

by James Forshaw

13:4 A USB Glitching Attack

by Micah Elizabeth Scott

13:5 MD380 Firmware in Linux

by Travis Goodspeed

13:6 Silliness in Three Acts

by Evan Sultanik

13:7 Reversing LoRa

by Matt Knight

13:8 A Sermon on Plumbing, not Popper

by P.M.L

13:9 Where is ShimDBC.exe?

by Geoff Chappell

13:10 A Schizophrenic Ghost

by Sultanik and Teuwen

Useful Tables

Index

Colophon

Introduction

Dear reader, this is a weird book.

This is the second volume of collected works from the prestigious International Journal of Proof of Concept or Get The Fuck Out, a publication for ladies and gentlemen with an interest in reverse engineering, file format polyglots, radio, operating systems, and other assorted technical subjects. The journal’s individual issues are published in a variety of countries across the Americas and Europe, but this volume you hold contains five of our finest releases in 784 action-packed pages, indexed and cross referenced for your convenience.

These articles are the very best stories that engineers and programmers might swap in front of a campfire, the clever tricks that are all too often rejected from the academic conference, but swapped discretely in its hallways by those who know better than their peers. Like the Brothers Grimm, our little gang has spent years collecting these stories, editing and illustrating them so that they won’t be forgotten.

Concerning radio, you will learn how Colby Moore reverse engineered Globalstar’s simplex communications protocol,¹ how Vogelfrei sees the AX.25 protocol that underlies much of ham radio,² how Badenhop and Ramsey join Z-Wave networks with a stolen crypto key,³ and how Matt Knight reverse engineered the real details of the LoRa protocol, which differ from the patent.⁴

If you’re more interested in preserving vintage hardware, we have an English translation of the article by Voja Antonić that introduced the very first Yugoslavian computer,⁵ the most complete modern collection of tricks for breaking Apple ][ copy protection,⁶ and the tale of how Lorenz West reverse engineered every last byte of Star Raiders.⁷

For modern targets, you will find Travis Goodspeed’s work reverse engineering the Tytera MD380 two-way radio⁸ and emulating its AMBE audio codec under Linux,⁹ Peter Hlavaty’s tips for spraying the Windows kernel pools,¹⁰ Alex Ionescu’s UMPown technique for escalating from Ring 3 to Ring 0 on Windows,¹¹ and Micah Elizabeth Scott’s impressive work with a Wacom tablet.¹²

You will also fine some damned clever file format tricks, which are explored through polyglot files that are valid in more than one format. In addition to begin valid PDF and ZIP files, pocorgtfo09.pdf is also a valid WavPack audio file;¹³ pocorgtfo10.pdf is a recording of button presses to exploit Pokemon Red with an IRC client as a payload;¹⁴ pocorgtfo11.pdf is a Ruby quine that hosts itself over HTTP;¹⁵ pocorgtfo12.pdf is a self-replicated Android application that can be installed like any other APK file, and then shared with another phone over bluetooth;¹⁶ and pocorgtfo13.pdf is a Postscript file, but be careful rendering it, because it will include a copy of /etc/passwd!

Each of these technical tricks, however simple or complicated, was written by a good neighbor much like yourself. With a bit of patience and perseverance, the details in these articles should be sufficient for you to repeat those results, rebuilding these proofs of concept in your own home, on your own computer, with your own mind.

And as you study these pages, you will learn the differences between how machines ought to work and how they really do work. You will see that software can be exploited to create strange behavior, that hardware can be patched with altered firmware, that files can be legal in more than one format, and other fine facts. Far more importantly than knowing that these things are possible, you will learn to do these things yourself. Ain’t that nifty?

Your neighbor,

Pastor Manul Laphroaig, T.G. S.B.

9 Elegies of the Second Crypto War

PASTOR MANUL LAPHROAIG’S

TABERNACLE CHOIR

SINGS REVERENT ELEGIES

OF THE

SECOND CRYPTO WAR

9:1 Zen and the Art of PoC

Neighbors, please join me in reading this tenth release of the International Journal of Proof of Concept or Get the Fuck Out, a friendly little collection of articles for ladies and gentlemen of distinguished ability and taste in the field of software exploitation and the worship of weird machines. This is our tenth release, given on paper to the fine neighbors of Novi Sad, Serbia and Stockholm, Sweden.

Page 13 contains our very own Pastor Manul Laphroaig’s sermon on Newton and Turing, in which we learn about the academics’ affection for Turing-completeness.

On page 20, Colby Moore provides all the details you’ll need to sniff simplex packets from the Globalstar satellite constellation.

Page 31 introduces some tips by Peter Hlavaty of the Keen Team on kernel pool spraying in Windows and Linux.

Page 43 presents the results of the second Underhanded Crypto Contest, held at the Crypto Village of Defcon 23.

On page 47, Sophia D’Antoine introduces some tricks for communicating between virtual machines co-located on the same physical host. In particular, the mf ence instruction can be used to force strict ordering, interfering with CPU instruction pipelining in another VM.

Eric Davisson, on page 57, presents a nifty little trick for causing quarantined malware to be re-detected by McAfee Enterprise VirusScan! This particular tumor is benign, but we bet a neighborly reader can write a malignant variant.

Ron Fabela of Binary Brew Works, on page 61, presents his recipe for TCP/IPA, a neighborly beer with which to warm our hearts and our spirits during the coming apocalypse.

Vogelfrei shares with us some tricks for APRS and AX.25 networking on page 71. APRS exists around much of the western world, and all sorts of mischief can be had through it. (But please don’t be a jerk on the airwaves.)

Much as some readers think of us as a security magazine, we are first and foremost a systems-internals journal with a bias toward the strange and the classic designs. Page 84 contains a reprint, translated from the original Serbian, of Voja Antonić’ article on the Galaksija, his Z80 home computer design, the very first in Yugoslavia.

fbz is a damned fine neighbor of ours, both a mathematician and a musician. On page 126 you’ll find her latest single, Root Rights are a Grrl’s Best Friend! If you’d rather listen to it than just read the lyrics, run vlc pocorgtfo09.pdf and jump to page 128, where Philippe Teuwen describes how he made this fine document a polyglot of PDF, ZIP, and WavPack.

On page 131, you will find Oona’s Puzzle Corner, with all sorts of nifty games for a child of five. If you aren’t clever enough to solve them, then ask for help from a child of five!

Academics should just marry Turing Completeness already!

—The Grugq

9:2 From Newton to Turing, a Happy Family

by Pastor Manul Laphroaig, D.D.

When engineers first gifted humanity with horseless carriages that moved on rails under their own power, this invention, for all its usefulness, turned out to have a big problem: occasional humans and animals on the rails. This problem motivated many inventors to look for solutions that would be both usable and effective.

Unfortunately, none worked. The reason for this is not so easy to explain—at least Aristotelian physics had no explanation, and few scientists till Galileo’s time were interested in one. On the one hand, motion had to brought on by some force and tended to kinda barrel about once it got going; on the other hand, it also tended to dissipate eventually. It took five hundred years from doubting the Aristotelian idea that motion ceased as soon as its impelling force ceased to the first clear pronouncement that motion in absence of external forces was a persistent rather than a temporary virtue; and another six hundred for the first correct formulation of exactly what quantities of motion were conserved. Even so, it took another century before the mechanical conservation laws and the actual names and formulas for momentum and energy were written down as we know them.

These days, conservation of energy is supposed to be one of those word combinations to check off on multiple-choice tests that make one eligible for college.¹ Yet we should remember that the steam engine was invented well before these laws of classical mechanics were made comprehensible or even understood at all. Moreover, it wasn’t until nearly a century after Watt’s ten-horsepower steam engine patent that someone formulated the principles of thermodynamics that actually make a steam engine work—by which time it was chugging along at ten thousand horsepower, able to move not just massive amounts of machinery but also the engine’s own weight along the rails, plus a lot more.²

All of this is to say that if you hear scientists doubting that an engineer can accomplish things without their collective guidance, they have a lot of history to catch up with, starting with that thing called the Industrial Revolution. On the other hand, if you see engineers trying to build a thing that just doesn’t seem to work, you just might be able to point them to some formulas that suggest their energies are best applied elsewhere. Distinguishing between these two situations is known as magic, wisdom, extreme luck, or divine revelation; whoever claims to be able to do so unerringly is at best a priest, not a scientist.³

There is an old joke that whatever profession needs to add science to its name is not so sure it is one. Some computer scientists may not take too kindly to this joke, and point out that it’s actually the word computer that’s misleading, as their science transcends particular silicon-and-copper designs. It is undeniable, though, that hacking as we know it would not exist without actual physical computers.

As scientists, we like exhaustive arguments: either by full search of all finite combinatorial possibilities or by tricks such as induction that look convincing enough as a means of exhausting infinite combinations. We value above all being able to say that a condition never takes place, or always holds. We dislike the possibility that there can be a situation or a solution we can overlook but someone may find through luck or cleverness; we want a yes to be a yes, a no to mean no way in Hell. But full search and induction only apply in the world of ideal models—call them combinatorial, logical, or mathematical—that exclude any kinds of unknown unknowns.

Hence we have many models of computation: substituting strings into other strings (Markov algorithms), rewriting formulas (lambda calculus), automata with finite and infinite numbers of states, and so on. The point is always to enumerate all finite possibilities or to convince ourselves that even an infinite number of them does not harbor the ones we wish to avoid. The idea is roughly the same as using algebra: we use formulas we trust to reason about any and all possible values at once, but to do so we must reduce reality to a set of formulas. These formulas come from a process that must prod and probe reality; we have no way of coming up with them without prodding, probing, and otherwise experimenting by hunch and blind groping—that is, by building things before we fully understand how they work. Without these, there can be no formulas, or they won’t be meaningful.

So here we go. Exploits establish the variable space; science searches it, to our satisfaction or otherwise, or—importantly to save us effort—asserts that a full and exhaustive search is infeasible. This may be the case of energy conservation vs. trying to construct a safer fender—or, perhaps, the case of us still trying to formulate what makes sense to attempt.

That which we call the arms race is a part of this process. With it, we continually update the variable spaces that we wish to exhaust; without it, none of our methods and formulas mean much. This brings us to the recent argument about exploits and Turing completeness.

Knowledge is power.⁴ In case of the steam engine, the power emerged before the kind of knowledge called scientific if one is in college or basic if one is a politician looking to hitch a ride—because actual science has a tradition of overturning its own basics as taught in schools for at least decades if not centuries. In any case, the knowledge of how to build these engines was there before the knowledge that actually explained how they worked, and would hardly have emerged if these things had not been built already.

Our very own situation, neighbors, is not unlike that of the steam power before the laws of thermodynamics. There are things that work (pump mines, drive factories), and there are official ways of explaining them that don’t quite work. Eventually, they will merge, and the explanations will catch up, and will then become useful for making things that work better—but they haven’t quite yet, and it is frustrating.

This frustration is understandable. As soon as academics re-discovered a truly nifty kind of exploit programming, they not only focused on the least practically relevant aspect of it (Turing completeness)—but did so to the exclusion of all other kinds of niftyness such as information leaks, probabilistic programming (heap feng-shui and spraying), parallelism (cloning and pinning of threads to sap randomization), and so on. That focus on the irrelevant to the detriment of the relevant had really rankled. It was hard to miss where the next frontier of exploitation’s hard programming tasks and its next set of challenges lay, but oh boy, did the academia do it again.

Yet it is also clear why they did it. Academic CS operates by models and exhaustive searches or reasoning. Its primary method and deliverable is exhaustive analysis of models, i.e., the promise that certain bad things never happen, that all possible trajectories of a system have been or can be enumerated.

Academia first saw exploit programming when it was presented in the form of a model; prior to that, their eyes would just slide off it, because it looked ad-hoc, and one can neither reason about ad-hoc nor enumerate it. (At least, not if one wants to meet publication goals.) When it turned out it had a model, academia did with it what it normally does with models: automating, tweaking, searching, finding their theoretical limits, and relating them to other models, one paper at a time.⁵

This is not a bad method; at least, it gave us complex compilers and CPUs that don’t crumble under the weight of their bugs.⁶ Eventually we will want the kind of assurances such a method creates—when their models of unexpected execution are complete enough, close enough to reality. For now, they are not, and we have to go on building our engines without guidance from models, but rather to make sure new models will come from them.

Not that we are without hope. A reader has only to look to Grsecurity/PaX at any given time to see what will eventually become the precise stuff of Newton’s laws for the better OS kernels; similarly, the inescapable failure modes of data and programming complexity will eventually be understood as clearly as the three principles of thermodynamics. Until then our best bet is to build engines—however unscientific—and to construct theories—however removed from real power—and to hope that the engineering and the science will take enough notice of each other to converge within a lifetime, as they have had the sense to do during the so-called Industrial Revolution, and a few lucky times since.

And to this, neighbors, the Pastor raises not one but two drinks—one for the engineering orienting the science, and another for the science catching up with the knowledge that is power, and saving it the effort of what cannot be done—and may they ever converge! Amen.

9:3 Globalstar Satellite Comms

by Colby Moore

It might be an understatement to say that hackers have a fascination with satellites. Fortunately, with advancements in Software Defined Radio such as the Ettus Research USRP and Michael Ossmann’s HackRF, satellite hacking is now not only feasible, but affordable. Here we’ll discuss the reverse engineering of Globalstar’s Simplex Data Service, allowing for interception of communications and injection of data back into the network.

Rumor has it, that after deployment, Globalstar’s first generation of satellites began to fail, possibly due to poor radiation hardening. This affected the return path data link, where Globalstar’s satellite constellation would transmit to a user. To salvage the damaged satellite network, Globalstar introduced a line of simplex products that enable short, one-way communication from the user to Globalstar.

The nature of the service makes it ideal for asset tracking and remote sensor monitoring. While extremely popular with oil and gas, military, and shipping industries, this technology is also widely used by consumers. A company called SPOT produces consumer-grade asset trackers and personal locator beacons that use this same technology.

Globalstar touts their simplex service as extremely difficult to intercept, noting that the signal’s Low-Probability-of-Intercept (LPI) and Low-Probability-of-Detection(LPD) provide over-the-air security.⁷

In this article I’ll outline the basics for reverse engineering the Globalstar Simplex Data Services modulation scheme and protocol, and will provide the technical information necessary to interface with the network.

Network Architecture

The network is comprised of many Low Earth Orbit, bent-pipe satellites. Data is transmitted from the user to the satellite on an uplink frequency and repeated back to Earth on a downlink frequency. Globalstar ground stations all over the world listen for this downlink data, interpret it, and expose it to the user via an Internet-facing back-end. Each ground station provides a several thousand mile window of data coverage.

Bent-pipe satellites are dumb in that they do not modify the transmitted data. This means that the data on the uplink is the same on the downlink. Thus, with the right knowledge, a skilled adversary can intercept data on either link.

Tools and Code

This research was conducted using GNURadio and Python for data processing and an Ettus Research B200 for RF work. Custom proof-of-concept toolsets were written for DSSS and packet decoding. Devices tested include a SPOT Generation 3, a SPOT Trace, and a SmartOne A.

Frequencies and Antennas

Four frequencies are allocated for the simplex data uplink. Channel A is 1611.25 MHz, B is 1613.75 MHz, C is 1616.25 MHz, and D is 1618.78 MHz. Current testing has only shown operation on channel A.

Globalstar uses left-hand circular-polarized antennas for transmission of simplex data from the user to the satellite. The antenna that ships with Globalstar’s GSP-1620 modem, designed for transmitting from the user to a satellite, has proven adequate for experimentation.

Downlink is a bit more complicated, and far more faint. Channels vary by satellite, but are within the 6875–7055 MHz range. Both RHCP and LHCP are used for downlink.

Direct Sequence Spread Spectrum

Devices using the simplex data service implement direct sequence spread spectrum (DSSS) modulation to reliably transmit data using low power. DSSS is a modulation scheme that works by mixing a slow data signal with a very fast Pseudo Noise (PN) sequence. Since the pseudo-random sequence is known, the resulting signal retains all of the original data information but spread over a much wider spectrum. Among other benefits, this process makes the signal more tolerant to interference.

Figure 9.1: GNURadio Companion Decoder

In Globalstar’s implementation of DSSS, packet data is first modulated as non-differential BPSK at 100.04 bits/second, then spread using a repeating 255 chip PN sequence at a rate of 1,250,000 chips/second. Here chip refers to one bit of a PN sequence, so that it is not confused with actual data bits.

Pseudo Noise Sequence / M-Sequences

Pseudo Noise (PN) sequences are periodic binary sequences known by both the transmitter and receiver. Without this sequence, data cannot be received. The simplex data service uses a specific type of PN sequence called an M-Sequence.

M-Sequences have the unique property of having a strong autocorrelation for phase shifts of zero but very poor correlation for any other phase shift. This makes the detection of the PN in unknown data, and subsequently locking on to a DSSS signal, relatively simple.

All simplex data network devices examined use the same PN sequence to transmit data. By knowing one code, all network data can be intercepted.

Obtaining The M-Sequence

In order to intercept network data, the PN sequence must be recovered. For each bit of data transmitted, the PN sequence repeats 49 times. Data packets contain 144 bits.

The PN sequence never crosses a bit boundary, so it can be inferred that xor(PN, data) == PN.

By decoding the transmitted data stream as BPSK,⁸ we can demodulate a spread bitstream. Note that demodulation in this manner negates any processing gain provided from DSSS and thus can only be received over short distances, so for long distances you will need to use a proper DSSS implementation.

Viewing the demodulated bitstream, a repeating sequence is observed. This is the PN, the spreading code key to the kingdom.

The simplex data network PN code is 1111111100101101011-01110101010111001001101101001100110100011101101100010-0010011110100100100001111000101001110001111101011110011101000010101100101000101100000110010001100001101111-11011100001000001001010100101111100000011100110001101-010000000101110111101100.

Despreading

DSSS theory states that to decode a DSSS-modulated signal, a received signal must be mixed once again with the modulating PN sequence; the original data signal will then fall out. However, for this to work, the PN sequence needs to be phase-aligned with the mixed PN/data signal, otherwise only noise will emerge.

Alignment of the PN sequence to the data stream if accomplished by correlating the PN sequence against the incoming datastream at each sample. When aligned, the correlation will peak. To despread, this correlation peak is tracked and the PN is mixed with the sampled RF data. The resulting signal is the 100.04 bit/second non-differential BPSK modulated packet data.

Decoding and Locations

Once the signal is despread, a BPSK demodulator is used to recover data. The result is a binary stream, 144 bytes in length, representing one data packet. The data packet format is shown in Figure 9.2.

Simplex data packets can technically transmit any 72 bits of user defined data. However, the network is predominantly used for asset tracking and thus many packets contain GPS coordinates being relayed from tracking devices. This data scheme for GPS coordinates can be interpreted with the following Python code.

latitude  =       int ( user_data [8:32],2)  *  90 / 2**23

longitude = 360 - int ( user_data [32:56],2) * 180 / 2**23

CRC

Packets are verified using a 24 bit CRC which covers all of the data packet except for the preamble and, of course, the CRC itself. Python code implementing the CRC algorithm is shown in Figure 9.3.

Transmitting

DISCLAIMER: It is most likely illegal to transmit on Globalstar’s frequencies where you live. Do so at your own risk. Remember, no one likes late night visits from the FCC and it would really suck if you interrupted someone’s emergency communication!

By knowing the secret PN code, modulation parameters, data format, and CRC, it is possible to craft custom data packets and inject them back into the satellite network. The process is to (1) generate a custom packet, (2) calculate and append the correct CRC, (3) spread the packet using Globalstar’s PN sequence, and finally (4) BPSK module the spread data for transmission over the RF carrier.

Figure 9.2: Packet Format

Figure 9.3: Python Implementation of Globalstar’s CRC24

Few SDR boards have sufficient power to communicate with the network, buts COTS amplifiers are available for less than a few hundred dollars. Specifications suggests a minimum transmit power of about 200 milliwatts.

Spoofing

SPOT produces a series of asset trackers called SPOT Trace. SPOT also provides SPOT_Device_Updater.pkg, an OS X update utility, to configure various device settings. This utility contains development code that is never called by the consumer application.

The updater app package contains SPOT3FirmwareTool.jar. Decompilation shows that a UI view calls a method writeESN() in SPOTDevice.class. You read that correctly, they included the functionality to program arbitrary serial numbers to SPOT devices!

This UI can be called with a simple Java utility.

Upon execution, a debug console is launched, allowing the writing of arbitrary settings including ESNs, to the SPOT device. (This functionality was included in Spot Device Updater 1.4 but has since been removed.)

Impact

The simplex data network is implemented in countless places worldwide. Everything from SCADA monitoring to emergency communications relies on this network. To find that there is no encryption or authentication on the services examined is sad. And to see that injection back into the network is possible is even worse.

Using the specifications outlined here, it is possible—among other things—to intercept communications and track assets over time, spoof an asset’s location, or even cancel emergency help messages from personal locator beacons.

One could also enhance their own service, create their own simplex data network device, or use the network to transmit their own covert communications.

PoC and Resources

This work was presented at BlackHat USA 2015 and proof-of-concept code is available both by Github and within pocorgtfo-09.pdf.⁹

9:4 Pool Spray the Feature; or, Unprivileged Data Around the Kernel!

by Peter Hlavaty of Keen Team

When it comes to kernel exploitation, you might think about successful exploitation of interesting bug classes such as use-after-free and over/under-flows. In such exploitation it is sometimes really useful to ensure that the corrupted pointer will still point to accessible, and in the best scenario also controllable, data.

As we described in our recent blogpost about kernel security,¹⁰ although controlling kernel data to such an extent should be impossible and unimaginable, this is, in fact, not the case with current OS kernels.

In this article we describe layout and control of pool data for various kernels, in different scenarios, and with some nifty examples.

Windows

1. Small and large allocations: There are a number of known approaches to invoking ExAllocatePool (kmalloc) in kernel, with more or less control over data shipped to kernel. Two notable examples are SetClassLongPtrW¹¹ by Tarjei Mandt and CreateRoundRectRgn/PolyDraw¹² by Tavis Ormandy. Another option we were working on recently resides in SessionSpace and grants full control of each byte except those in the header space. We successfully leveraged this approach in Pwn2Own 2015 and described it at Recon.¹³ We use the win32k!_gre_bitmap object.

You can think of it as a kind of kmalloc. Consider the following code:

2. Different pools matter: On Windows, exploitation of different objects can get a bit tricky, because they can reside in different pools.

This means that if you want to use our win32k!_gre_bitmap technique, you must use it only on objects existing in SessionPool, which is not always the case. But on the other hand, as we already discussed, in different pools you can find different objects to fulfill your needs. Another nice example, in a different pool, was leveraged by Alex Ionescu, using the Pipe object, proposed with the Socket object as well.¹⁴

The following piece of code represents another kmalloc of chosen size.

This was just a sneak peek at two objects that are easy to misuse for precise control over kernel memory content (via SetBitmapBits and WriteFile) and the pool layout (via Alloc and Free). Precise pool layout control can be achieved mainly in big pools, where layout can be well controlled. With small allocations, you may face more problems due to randomization being in place, as covered by the nifty research of Tarjei Mandt and Chris Valasek.¹⁵

We mention only a few objects to spray with; however, if you invest a bit of time to look around the kernel, you will find other mighty objects in different pools as well.

Linux (Android) Kernel

In Linux, you face a different scenario. With SLUB,¹⁶ you encounter problems due to overall randomization, and due to data that is not so easily controllable. In addition, SLUB has a different concept of pool separation, that of separate kernel caches for specific object types. Kernel caches provide far better granularity, as often only a few objects are stored in the same cache.

In order to exploit an overflow, you may need to use a particular object of the same cache, or force the overflow from your SLAB_objectA to a new SLAB_objectB block. In case of UAF, you can also force a whole particular SLAB block to be freed and reallocate it with another SLAB object. Either of these variants may be complex and not very stable.

However, not all objects are stored in those kernel caches, and a lot of the useful ones are allocated from the default object pool based only on the size of the object, so in the same SLAB you can mix different objects.

Our first useful object for playing with the pool layout is Pipe, in Figure 9.4. TTY in Figure 9.5 and Socket in Figure 9.6 are also rather useful.

However, in our implementations we only play with allocations of sizes sizeof(Pipe), sizeof(TTY), sizeof(Socket), but not with their associated buffers for the Pipe, TTY, or Socket objects respectively. Therefore, here we omit doing the equivalent of memcpy, but you can ship your controlled data to kernel memory through the write syscall, which will store it there faithfully byte-for-byte.

Figure 9.4: Pipe Object

Figure 9.5: TTY Object

Figure 9.6: Socket Object

Here is an example with Pipe. It is similar to the Windows example. In Windows we use the WriteFile API, but in the Linux implementation we have to use CPipe.Write, like in this example with fcntl syscall:

One of the reasons why we focus mainly on object header-based kmallocs is that in Linux the objects we deal with are easy to overwrite, have a lot of pointers and useful state we can manipulate, and are often quite large. For example, they may cover different SLABSs, and may even be located in the same SLAB as various kinds of buffers that make pretty sexy targets. One more reason is covered later in this article.

However, understanding the real pool layout is a far more difficult task than described above, as randomization complicates it to a large extent. You can usually overcome it with spraying in the same cache and filling most of the pool to ensure that almost every object there can be used for exploitation, as due to randomization you don’t know where your target will reside.

Sometimes by trying to do this kind of pool layout with overflowable buffer and right object headers you can achieve full pwn even without touching addr_limit.

Pool spray brute force implementation:

But as we mentioned before, a big drawback to effective pool spraying on Linux and to doing a massive controllable pool layout is the limit on the number of owned kernel objects per process. You can create a lot of processes to overcome it, but that is bit messy and it doesn’t always properly solve your issue.

Spray by GFP_USER zone:

To overcome this limitation and to control more of the kernel memory (zone GFP_USER) state, we came up with a somewhat more comprehensive solution than that which was presented at Confidence 2015.¹⁷

To understand this technique, we will need to take a closer look at the splice method.

As you can see from this highlight, the important page is alloc_page(GFP_USER), which is allocated for PAGE_SIZE and filled with controlled content later. This is nice, but we still have a limit on pipes!

Now here is a paradox: sometimes randomization can play in your hands! In other words, when you splice many times, you will cover a lot of random pages in kernel’s virtual address space. But that’s exactly what we want!

But to trigger default_file_splice_read you need to provide the appropriate pipe counterpart to splice, and one of the best candidates is /dev/ptmx, the TTY. As splice is for moving content around, you will need to perform a few steps to achieve a successful spray algorithm:

You will need to repeatedly (1) fill tty slave, (2) splice tty master to pipe in, and (3) read it out from pipe out.

In conclusion, we consider kmalloc, with per-byte-controlled content, and kfree controllable by user to that extent very damaging for overall kernel security and introduced mitigations. And we believe that this power will be someday stripped from the user, therefore making harder exploitation of otherwise difficult to exploit vulnerabilities.

In this article we do not discuss kernel memory control by the ret2dir technique.¹⁸ For additional info and practical usage check our research from BHUS15!¹⁹

9:5 Second Underhanded Crypto Contest

by Taylor Hornby featuring winning submissions by Joseph Birr-Pixton and Scott Arciszewski

Defcon 23’s Crypto and Privacy Village mini-contest is over. Despite the tight deadline, we received five high-quality submissions in two categories. The first was to patch GnuPG to leak the private key in a message. The second was to backdoor a password authentication system, so that a secret value known to an attacker could be used in place of the correct password.

GnuPG Backdoor

We had three submissions to the GnuPG category. The winner is Joseph Birr-Pixton. The submission takes advantage of how GnuPG 1.4 generates DSA nonces.

The randomness of the DSA nonce is crucial. If the nonce is not chosen randomly, or has low entropy, then it is possible to recover the private key from digital signatures. GnuPG 1.4 generates nonces by first generating a random integer, setting the most-significant bit, and then checking if the value is less than a number Q (a requirement of DSA). If it is not, then the most-significant 32 bits are randomly generated again, leaving the rest the same.

This shortcut enables the backdoor. The patch looks like an improvement to GnuPG, to make it zero the nonce after it is no longer needed. Unfortunately for GnuPG, but fortunately for this contest, there’s an extra call to memset() that zeroes the