To us he was, of course, much more. He brought us together, as a group and in spirit. Without him, we as a team would not exist. He was a mentor to many, and an inspiration to us all.
Yet above anything, he was our friend. He will be dearly missed.
Our thoughts go out to his wife and family.
Keep hacking. It’s what bushing would have wanted.
Ben Byer 1980-2016
12 Collecting Bottles of Broken Things
COLLECTING BOTTLES OF BROKEN THINGS,
PASTOR MANUL LAPHROAIG
WITH THEORY AND PRAXIS
COULD BE THE MAN
WHO SNEAKS A LOOK
BEHIND THE CURTAIN!
12:1 Lisez Moi!
Neighbors, please join me in reading this thirteenth release of the International Journal of Proof of Concept or Get the Fuck Out. This release is given on paper to the fine neighbors of Montréal.
We begin on page 431 with a sermon concerning peak computation, population bombs, and the joy of peeks and pokes in the modern world by our own Pastor Manul Laphroaig.
On page 437 we have a Z-Wave Christmas Carol by Chris Badenhop and Ben Ramsey. They present a number of tricks for extracting pre-shared keys from wireless Z-Wave devices, and then show how to use those keys to join the network.
On page 453, Krzysztof Kotowicz and Gábor Molnár present Comma Chameleon, weaponize PDF polyglots to exfiltrate data via XSS-like vulnerabilities. You will never look at a PDF with the same eyes again, neighbors!
Chris Domas, whom you’ll remember from his brilliant compiler tricks, has contributed two articles to this fine release. On page 483, he explains how to implement M/o/Vfuscator as a Virtual Machine, producing a few bytes of portable C or assembly and a complete, obfuscated program in the .data segment.
IBM had JCL with syntax worse than Joss, and everywhere the language went, it was a total loss! So dust off your z/OS mainframe and use the ASCII/EBCDIC chart from the back of the book to read Soldier of Fortran’s JCL Adventure with Network Job Entries on page 490.
What does a cult Brezhnev-era movie have to do with how exploit code finds its bearings in a Windows process’ address space? Read Exploiting Weak Shellcode Hashes to Thwart Module Discovery; or, Go Home, Malware, You’re Drunk! by Mike Myers and Evan Sultanik on page 535 to find out!
Page 553 begins Alex Ionescu’s article on a DeviceGuard Mitigation Bypass for Windows 10, escalating from Ring 3 to Ring 0 with complete reconstruction of all corrupted data structures.
Page 577 is Chris Domas’ second article of this release. He presents a Turing-complete Virtual Machine for VIM using only the normal commands, such as yank, put, delete, and search.
On page 587 you will find a rousing guest sermon Doing Right by Neighbor O’Hara by Andreas Bogk, against the heresy of “sanitizing” input as a miracle cure against injection attacks. Our guest preacher exposes it as fundamentally unneighborly, and vouchsafes the true faith.
Concluding this issue’s amazing lineup is Are androids polyglots? by Philippe Teuwen on page 593, in which you get to practice Jedi polyglot mind tricks on the Android package system. Now these are the droids we are looking for!
12:2 Surviving the Computation Bomb
by Manul Laphroaig
Gather round the campfire, neighbors. Now is the time for a scary story, of the kind that only science can tell. Vampires may scare children, but it takes an astronomer to scare adults—as anyone who lived through the 1910 scare of the Earth’s passing through the Halley’s comet’s tail would plainly tell you. After all, they had it on the best authority that the tail’s cyanogen gas—spectroscopically confirmed by very prominent bands—would impregnate the atmosphere and possibly snuff out all life on the planet.
But comets as a scare are old and busted, and astronomic spectroscopy is no longer a hot new thing, prominent bands or no. We can do better.
Imagine that you come home after a strenuous workday, and, after a nice dinner, sit down to write some code on that fun little project for your PoC‖GTFO submission. Little do you know that you are contributing to the thing that will doom us all!
You see, neighbors, there is only so much computation possible in the world. By programming for pleasure, you are taking away from this non-renewable resource, and when it runs out, our civilization will be destroyed.
Think of it, neighbors. Computation was invented by mathematicians, and they tend to imagine infinite resources, like endless tapes for their model machines, but in reality nothing is inexhaustible. There is only a finite amount of atoms in the universe—so how could such a universe hold even one of these infinite tapes? Mathematicians are notorious for being shortsighted, neighbors.
You may think, okay, so there may not be an infinite amount of computation, but there’s surely enough for everyone? No, neighbors, not when it’s growing exponentially! We may have been safe when people just wrote programs, but when they started writing programs to write programs, and programs to write programs to write programs, how long do you think this unsustainable rush would last? Have you looked at the size of “hello world” lately? We are doomed, and your little program is adding to that, too!
Now you may think, what about all these shiny new computers they keep making, and all those bright ads showing how computers make things better, with all the happy people smiling at you? But these are made by corporations, neighbors, and corporations would do anything to turn a profit, would they not? Aren’t they the ones destroying the world anyway? Perhaps the rich and powerful will have stashed some of it away for their own needs, but there will not be enough for everyone.
Think of the day when computation runs out. The Internet of Things will turn into an Internet of Bricks, and all the things it will be running by that time, like your electricity, your water, your heat, and so on will just stop functioning. The self-driving cars will stop. In vain will your smart fridge, previously shunned by your other devices as the simpleton with the least processor power, call out to its brethren and its mother factory—until it too stops and gives up its frosty ghost.
A national mobilization of the senior folks who still remember how to use paper and drive may save some lives, but “will only provide a stay of execution.” Nothing could be more misleading to our children than our present society of affluent computation!1
To meet the needs of not just individual programmers, but of society as a whole, requires that we take an immediate action at home and promote effective action worldwide—hopefully, through change in our value system, but by compulsion if voluntary methods fail—before our planet is permanently ruined.2
No point in beating around the bush, neighbors—computation must be rationed before it’s too late. We must also control the population of programmers, or mankind will program itself into oblivion. “The hand that hefted the axe against the ice, the tiger, and the bear [and] now fondles the machine gun”—and, we must add, the keyboard—“just as lovingly”3 must be stopped.
Uncontrolled programming is a menace. The peeks and pokes cannot be left to the unguided masses. Governments must step in and Do Something.
Well, maybe the forward-thinking elements in government already are. When industrial nations sign an international agreement to control software under the same treaty that controls nuclear and chemical weapon technologies—and then have to explicitly exclude debuggers from it, because the treaty’s definition of controlled software clearly covers debuggers—something must be going on. When politicians who loudly profess their commitment to technological progress and education demand to punish makers and sellers of non-faulty computers—maybe they are only faking ignorance.
When “Advanced Placement” computing in high schools means Java and only Java, one starts to suspect shenanigans. When most of you, barely escaped courses that purported to teach programming, but in fact looked like their whole point was to turn you away from it—can this be a coincidence? Not hardly, neighbors, not by a long shot!
Scared yet?4
Perhaps it is this little litany: “Science is the belief in the ignorance of experts.” At the time that Rev. Feynman composed it, he felt compelled to say, “I think we live in an unscientific age ... [with] a considerable amount of intellectual tyranny in the name of science.” We wonder what he would have said of our times.
But take heart, neighbors. Experts and sciences of doom come and go; so do killer comets with cyanogen tails, the imminent Fifth Ice Age, and population bombs. We might survive the computation bomb yet—so finish that little project of yours without guilt, send it to us, and let its little light shine—in an unscientific world that needs it.
12:3 Carols of Z-Wave Security; or, Robbing Keys from Peter to Unlock Paul
by Chris Badenhop and Ben Ramsey
Adeste Fideles
Z-Wave is a physical, network, and application layer protocol for home automation. It also allows members of the disposable income class to feed their zeal for domestic gadgetry, irrespective of genuine utility. Z-Wave devices sit in their homes, quietly exchanging sensor reports and actuating in response to user commands or the environment.
The curious reader may use an SDR to learn how, when, and what they communicate. Tools like Scapy-radio (Picod, Lebrun, and Demay) and EZ-Wave (Hall and Ramsey) demodulate Z-Wave frames for inspection and analysis. The C++ source code for OpenZwave is a great place to examine characteristics of the Z-Wave application layer. Others may still prefer to cross-compile OpenZwave to their favorite target and examine the binary using a custom disassembler built from ROP gadgets found in the old shareware binary WOLF3D.EXE.
After tinkering with Z-Wave devices and an SDR, readers will quickly realize that they can send arbitrary application layer commands to devices where they are executed. To combat this, some devices utilize the Z-Wave security layer, which provides both integrity and confidentiality services to prevent forgery, eavesdropping, and replay.
The first gospel of the Z-Wave security layer was presented by Fouladi and Ghanoun at Black Hat 2013. In it they identified and exploited a remote rekeying vulnerability. In this second gospel of the Z-Wave security layer, we validate and extend their analysis of the security layer, identify a hardware key extraction vulnerability, and provide open source PoC tools to inject authenticated and encrypted commands to sleeping Z-Wave devices.
Deck the Home with Boughs of Z-Wave
This Christmas, Billy Peltzer invests heavily in Z-Wave home automation. The view of his festive front porch reveals several of these gadgets. Billy is a little paranoid after having to defend himself from hordes of gremlins every Christmas, so he installs a Z-Wave door lock, which both Gizmo and he are able to open using a smart phone or tablet. Billy uses a Z-Wave smart plug to control Christmas lights around his front window. He programs the strand of lights to turn on when a Z-Wave PIR (passive infrared) sensor detects darkness and turn off again at daylight. This provides a modest amount of energy savings, which will pay for itself and his Mogwai-themed ornament investment after twenty years.
The inquisitive reader may wonder whether Billy’s front door is secure. Could a gremlin covertly enter his home using the Z-Wave application layer protocol, or must it instead cannonball through a window, alerting his dog Barney? Fortunately, sniffing, replaying, or injecting wireless door commands is fruitless because the door command class implements the Z-Wave security layer, which is rooted in cryptography.
Z-Wave cryptography uses symmetric keys to provide encryption and authentication services to the application layer. It stores a form of these keys in nonvolatile memory, so that the device does not require rekeying upon power loss. Of the five locks we have examined, the nonvolatile memory is always located in the inner-facing module, so a gremlin would have to destroy a large portion of the Z-Wave door lock to extract the key. At that point it would have physical access to the lock spindle anyway, making the cryptographic system moot.
Wireless security is enabled on the fifth generation (Z-Wave Plus) devices on Billy’s front porch. Thus, their memory contains the same keys that keep gremlins from wirelessly unlocking his door. A gremlin may crack open the outdoor smart plug or PIR sensor, locate and extract the keys, and send an authenticated unlock command to the door. Billy has, figuratively, left a key under the doormat!
We Three Keys of AES Are
Since Z-Wave security hinges on the security of the keys, it is important to know how they are stored and used. Z-Wave encryption and authentication services are provided by three 128-bit AES keys; however, the security of an entire Z-Wave network converges to a single key in the set. Like the three wise men, only one of them was necessary to deliver the gifts to Brian of Nazareth. The other two could have just as well stayed home and added a few extra camels to haul the gifts. A card would also have been nice.
The key of keys in this system is the network key. This key is generated by the Z-Wave network controller device and is shared with every device requiring cryptographic services. It is used to derive both the encrypting and signing keys. When a new device is added to a Z-Wave network, the device may declare a set of command classes that will be using security (e.g., the door lock command class) to the Z-Wave network controller. In turn, the controller sends the network key to the new device. To provide a razor-thin margin of opaqueness, this message is encrypted and signed using a set of three default keys known to all Z-Wave devices. The default encryption and authentication keys are derived from a default 128-bit network key of all zeros. If the adherent reader recovers the encryption key from their device, decrypts sniffed frames, and finds that the plaintext is not correct, then they should attempt to use the encryption key derived from the null network key instead.5
An authentication key is derived from a network key as follows. Using an AES cipher in ECB-mode, a 16-byte authentication seed is encrypted using the network key to derive the authentication key. The derivation process for the encryption key is identical, except that a different 16-byte seed value is used. A curious reader may want to know what these seeds are, and any fortuitous reader in possession of a MiCasaVerde controller will be able to tell you.
The MiCasaVerde controller uses an embedded Linux OS and provides two mechanisms for extracting a keyfile from its filesystem, located at /etc/cmh/keys. Using the web interface, one may download a compressed archive of the controller state. The archive contains the /etc directory of the filesystem. Alternatively, a secure shell interface is also provided to remotely explore the filesystem. The MiCasaVerde binary key file (keys) is exactly 48 bytes and contains all three keys. The file is ordered with the network key first, the authentication key second, and the encryption key last. Billy Peltzer’s Z-Wave network controller is a MiCasaVerde-Edge. In Figure 12.1, we show the resulting key file and dump the values of the keys for his network, 0xe97a-5631cb5686fa24450eba103f945c.
Figure 12.1: Keys found in Billy’s MiCasaVerde Edge Controller
Figure 12.2: Seeds for Encryption and Authentication Keys
To find the seeds, one must simply decrypt the authentication and encryption keys using an AES cipher in ECB mode loaded with the network key, and the resulting gifts will be the authentication and encryption seeds respectively. From our own observations, the same seed values are recovered from both third and fifth generation Z-Wave devices. Billy’s keys are used in Figure 12.2 to recover the seeds. Given the seed values and a network key, we have a method for deriving the encryption key and the authentication key from an extracted network key.
Away in an EEPROM, No ROM for Three Keys
Z-Wave devices other than MiCasaVerde controllers may not have an embedded Linux OS, so where are the keys stored in those devices? Extracting and analyzing the nonvolatile memory of Billy’s PIR sensor
and doorlock reveal that the network key is stored in a lowly, unprotected 8-pin SPI EEPROM, which is external to the proprietary Z-Wave transceiver chip. In fact, only the network key is stored in the EEPROM, implying that the encryption key and the authentication key are derived upon startup and stored in RAM.
Unless the device designers hoped to obscure the key derivation process, the decision to store only the network key in nonvolatile memory is unclear. Moreover, it is not clear why the key is found in the EEPROM rather than somewhere in the recesses of the proprietary ZW0X01 Z-Wave transceiver module, whose implementation details are protected by an NDA. The transceiver certainly has available flash memory, and there does not appear to be anyone who has dumped the ZW0501 fifth generation flash memory yet. Until this issue is fixed, anyone with an EEPROM programmer and physical access can acquire this key, derive the other two keys, and issue authenticated commands to devices. We extract Billy’s network key by desoldering the EEPROM from the main board of his PIR sensor and use an inexpensive USB EEPROM programmer (Signstek MiniPRO) to dump the memory to a file.
The circuit board from the PIR sensor is shown in Figure 12.3. The ZW0501 transceiver is the large chip located on the right side of the board (a third generation system would have a ZW0301). In general, the SPI EEPROM is the 8-pin package closest to the transceiver. The reader may validate that the SPI pins are shared between the EEPROM and transceiver package to be sure. In fact, the ATMLH436 EEPROM used in a third generation door lock is not in the MiniPRO schematics library, so we trace the SPI pin outs of the ZM3102 (i.e., the postage-stamp transceiver package) to the SPI EEPROM to identify its pin layout. We use this information to select a compatible SOIC8 ATMEL memory chip that is available in the MiniPRO library.
PoC or GTFO, Volume 2 Page 24