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.5
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.6 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.”7
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 b
its.
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,8 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
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,10 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 SetClassLongPtrW11 by Tarjei Mandt and CreateRoundRectRgn/PolyDraw12 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.13 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.14
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.15
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,16 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 forc
e 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.
PoC or GTFO, Volume 2 Page 2