Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Back in 2015, there is Smart Locks were starting to come around. Within these, there was a proximity functionality that allowed the automatic opening of locks if one is close by. How does this work?

Each bluetooth device has a unique Bluetooth device address (6 bytes), which is similar to a MAC address. In order to determine the proximity, the bluetooth device id was used. Of course, this can be spoofed!

In order to communicate with the lock, there is a shared key from a previous step. So, it is not as simple as spoofing the ID. Instead, an attacker must know the ID AND send data via the unencrypted communication channel. Now, the device is trusted, opening the lock.

To launch this attack, you must know the ID of the phone. However, using the Ubertooth One or similar tools, this is trivial to do. Even worse, the sniffing and reproducing could be done via a planted Raspberry Pi.

Overall, good post with many other fun wireless things on this blog. Good job Martin!

In order for lending protocols to determine the price of an asset, a price oracle is used to fetch prices either on-chain or off-chain. This is known as a price oracle. In this case, Chainlink was being relied upon.

The Chainlink oracle is secure by itself. However, the integration of Chainlink to the application needs to be tested as well.

Normally, the data is fetched via the call to AggregatorInterface.latestAnswer. This is secure. But, what if this fails? If this fails, such as when the price is 0, then a fallback function is called.

This fallback function (_fallbackOracle.getAssetPrice) has zero access control; this was meant to be a test only function. If this function was called then anyone can set any price for any asset. Yikes!

If this possible to trigger? If an asset is valued at $0, then it could happen. Additionally, they use the function deprecated function latestAnswer instead of latestRoundData.

If a new asset was added as a collateral before the price feed of the asset is configured, there would be a brief moment where the fallback oracle was used, and hence manipulated. Damn... that's wild.

This service was tested by 5 different solidity expert companies. So, why did they miss it? The company only allowed audits to happen on test environments instead of an actual blockchain (test net) setup. The test code should not have been deployed, which was told to the companies doing the audits.

Overall, a super interesting finding on why end-to-end security testing must be done. Good find!

Embedded devices are notoriously broken. This is not because of bad developers but a forced rush to the market. Because of this, several consistent and secure by default build system have been made. This whitepaper analyzes how to make more secure embedded devices using these build systems. In particular, OpenEmbedded and Yocto.

The first interesting section is labeled Automating QA Tasks. This can be done in order to add security into the build process from the beginning. One trick is to use the cve-check build class to automatically pull for security advisories. Additionally, meta-security checks for other security misconfigurations.

buck-security is a scanner used for basic checks on file permissions. meta-security-isafw (Image Security Analyzer Framework) provides additionally build and configuration checks. ISA_kca_plugin is a kernel configuration analyzer... there are a bunch of these tools that are very useful.

Next, they talk about binary protections, such as Nx, format strings, Fortify and other protections, into the compilation scripts. From there, they go into privilege separation. The key component is principle of least privilege for handling permissions correctly.

They talk about removing all entrenous functionality from these large frameworks to reduce attack surface. Good call out!

Overall, good paper with very actionable items.

Filesystem in USErspace (FUSE) ) is a userspace library for file system utilities, such as mount. In FUSE, there are two modes of IO: kernel page caching or direct requests on read/write to the userspace file system.

In the second mode of operation (FOPEN_DIRECT_IO), this calls a series of functions that eventually grab a reference to the userspace pages.

On the file system device side, they can be read or spliced as pipe buffers later. This is a problem because the read done via fuse_dev_read() unlocks the FUSE request while the userspace file system marks the request as completed.

This means that the buffer being used for the data (remember, this is a reference) can be used for other things. When this gets used for other things, we can still read data from it, causing a use-after-free-read-like scenario.

To exploit this, they got a leak from /etc/shadow by manipulating data within glibc. This required a strange error message path to hit but still works.

Overall, this required a deep understanding of the code to find this bug. Dangling references are bad; this one did not lead to memory corruption though!

Workspace One UEM (used to be AirWatch) is a mobile product used to deploy, secure and manage mobile devices. This also provides compliance-checking tools to ensure remote access devices meet the security standards.

The application comes as a .NET bundle of applications, which is really easy to reverse using a tool like dnspy. They looked at the web.config file in order to find the routes and things to hit.

One of these groupings of routes was in the BlobHandler. One of the pieces of functionality was for proxying HTTP requests. The logic for the parsing functionality went as follows:

• Encrypted URL parameter is passed in.
• Call RenderProxyResponse.
• Decrypt the input and call the proxy service.

The hackers were interested in this functionality because the security of the functionality was based upon the key being secret. Is this a good secret?

The function DataEncryption.DecryptString was completely custom code, which makes it more interesting. The data had a strange format: {cryptoVersion}:{keyVersion}:{text}:{cipherText}. To get the key for the function, it depended on the parameters passed in.

If the key is not specified, then it must be grabbed from the database or cache. However, if the key version is kv0 or NULL, then something else happens: a hardcoded default key is used.

With a hardcoded key, the security boundary has been broken. Now, we can create arbitrary ciphertexts since we know the hardcoded. This allows us to perform SSRF on the site with an unauthenticated user.

Overall, good bug and an awesome description that cryptography needs to be used properly in order to provide security. They also found several other cases that this happened.

A security issue was found on Rubygems.org. This is a website that stores packages (gems in Ruby land) and allows that creators of the package to manage them.

Imagine we want to yank (remove) a gem (such as where this is a security bug) of a popular package. For instance, we want to hit rails-html-sanitizer. We could set up a gem called rails-html.

While yanking a gem, there are a few parameters to identify the gem: name and slug. The slug is simply the version being used.

To do the gem lookup, it first validates that we have access to the gem name that we specified. After this, the two are concatenated together to find the name and version. This looks like so: name-slug. Do you see the problem!?

We can simply have our slug contain the remaining part of the package and the version. From our previous example with control over rails-html we could use the slug sanitizer-version_no. Now, we have control over the gem by using the slug!

String concatenation with arbitrary data can lead to security problems. This just goes to show that security bugs will never go away!

FairPlay is a line of scoreboards made since 1975 by the Fairtron Corporation. The scoreboard in the authors league date all the way back to 1992. The goal of the hacker was to make the wired implementation into a wireless one.

The boards are wired up to 100V AC power with a low voltage signal line. The board itself has E26/A19 bulb sockets for all of the different things in baseball (strikes, balls, etc.). The scoreboard has a line that goes underground all the way to the scoring booth. Since nobody wanted to be in the booth, the scoreboard become unused throughout many of the games.

The author decided to attack the controller box, since getting an oscilloscope out to the scoreboard would be complicated. The controller has an old time Motorola 68HC11 and a 128K EPROM. Normally, they would read out the EPROM, throw it in a disassembler and reverse engineer everything via code. However, the author thought that the signal would be simple enough reverse engineer from simply blackbox testing.

The FairPlay signal uses RS-232 signal levels (+5V and -5V) with a proprietary protocol. A 1 bit is +5V and a 0 bit is a -5V. Each symbol is 30 microseconds long. A 0 symbol is 5 microseconds high and 25 microseconds low while a 1 symbol is 20 microseconds high and 10 microseconds low. The messages go from controller to board, there is no path for a response from the scoreboard.

The data going across the wire directly mapped to different bulbs being lit up on the scoreboard. The scoreboard uses a 56 bit message word every 50 milliseconds. They determined all of the fields by simply pressing buttons on the controller and seeing what change was made. The data going across the wire directly mapped to different bulbs being lit up on the scoreboard. Well, sort of.

For the ball, strike and out fields on the scoreboard, each bulb directly matches the bits in the message; one bit for one bulb. The score and the inning are controlled by a single byte in the message. But, how is this possible? Each digit is made up of 13 bulbs! Several of the bits that could be turned on were ONLY possible with other bits being turned on as well. The numbers for the display are shown below:

007 
5 1 
567 
4 2
337

Eventually, the author came up with a way to represent each numbers as a mapping of bits. To fully implement a wireless version of the scoreboard, they hooked up a Raspberry Pi Zero to the talk UART to the controller with MAX3232, which is a converter of data from RD232 to TTL. Now, the scoreboard could be used wirelessly! Overall, great post on scoreboards and reverse engineering!

This post is about emulating the Netgear R7000 UPnP daemon in QEMU. This is beneficial because it allows for easier testing and dynamic reverse engineering.

First, they download the firmware and use binwalk to unpack it. Once they find the UPnP daemon, they extract the root file system and stick it into a pre-built ARM Debian OS via mount. They mention that it is much easier to emulate individual processes instead of the whole OS. Additionally, ARM tends to be easier to emulate than MIPS because of architecture changes between generations.

The author then creates a few device drivers for the file system, in order to allow everything to work as normal. In particular, dev/urandom, dev/null and proc (mounted to the regular proc of the debian OS). The Netgear devices use NVRAM in order to read settings, such the device type and the IP address to use. So, a custom version of the NVRAM library had to be used, in order to return the expected values to get everything to run.

The author then chroots into the file system to run the binary. However, it does not work as expected. When attaching GDB to the process there is a problem with the network settings; this can be fixed with a little GDBscript to hop over this check or patching the binary itself.

From previous research, they knew that the firmware update routine had a buffer overflow in it. Using this overflow (which required authentication), it is trivial to create a return-to-libc attack to pop a shell.

The updates for the Circle firmware, platform and loader are all encrypted. A good use of this is emulation is to allow the program to perform the decryption for us then extract it. To do this, they tell GDB to jump to the code that would decrypt the firmware and pass it a file to decrypt. Of course, this required a bunch of reverse engineering to get working.

The binary has anti-debugger features. At the beginning of the program, if it detects that GDB is being used, then it will reuse to decrypt the firmware. The detection methods are as follows:

• The PID of the parent process has ltrace, strace or GDB.
• ENV variables used in GDB, such as COLUMNS and LINES.
• Check the path of the ENV variables.
• LD_PRELOAD cannot be defined.

By starting the process then immediately jumping to the firmware decryption routine, all of these can be avoided. With anti-debugging, it is important to spread out the checking code in order to make it annoying for attackers. Overall, good article on what it takes to emulate router firmware.

The fiscal printer is part of the cash register. This is used to keep track of all income that a retailer would make in a day. The integrity of the device is marked with a seal to show that it has not been tampered with.

How does this register ensure that all items are recorded? The device must record every transaction processed by the printer inside an append-only internal memory and a special SD card called DGFE. Most fiscal printers have two units: the fiscal unit and the management unit. The fiscal unit is an MCU that connects to the append only memory, the PoS devices (printer, cash drawer, etc.) The management unit contains a full computer with a Linux or Android distribution.

The Italretail SpiceT fiscal printer is an Android-based printer that exchanges data between the management unit and the fiscal unit over UART. This comes with a custom ROM image with 4 custom apps on the OS and several default items. These app installations normally happen over a USB plugin. It is trivial to install a custom app this way as an attacker.

The UART port, used to talk to the fiscal unit, can be reached via the /dev/ttymxc4 character device. The permissions for this are rw-rw-rw-, meaning that ALL users can use the device!

The UART communication supports two different protocols: XON/XOFF and CUSTOM. CUSTOM uses a Baud rate of 19200, odd parity, 7 bits data length and 1 bit stop. The packets are in the following format:

• STX: Start the frame signal. Always 0x2.
• CNT: The frame counters. 2 bytes from 00 to 99 in decimal.
• IDENT: Packet identifier that is simply 1 ASCII character.
• CMD: The command to execute in the packet (4 bytes) alongside parameters. The codes range from 1000 to gather information and 9000 for admin actions, like firmware updates.
• CKS: Checksum. This is just the sum mod 100 of the CNT,IDENT,CMD fields.
• ETX: The end of the frame (0x3).

A successful response comes in three parts: ACK (0x6), CMD_HEADER and RESP. If there was an error, then the ACK becomes 0x15 and there is an error code after this. The author chose to setup Frida on the device driver, hooking the read and write syscalls. While viewing this, they noticed that several undocumented commands were being used.

One of these undocumented commands was 4003. This command would allow for the starting of a legit print, pausing it, print a BUNCH of fake receipts then close out the original one. This means that an auditor could verify what was printer but NOT everything would be written to the DGFE. Problem!

Remember how the DGFE was append only? That just isn't the case! The code 741x could be used to delete or overwrite the files here. Yikes! Good find that compromises the use of the whole system.

Elliptic Curve Digital Signature Algorithm (ECDSA) is digitial signature algorithm based upon elliptic curve cryptography. ECDSA consists of two values: r and s. To verify the signature, the signers public key, r, s and a hash of the message are required. If the two parts of the equation are correct then the signature is valid or invalid otherwise.

When doing the math for this, multiplication is done. What happens if r and s are both 0? well, 0 * anything is 0! the first check that ECDSA needs to check is that both 4 and s are greater than 1.

When Java was rewriting the code for ECDSA with a non-security based developer, this restriction was removed. As a result, a zero signature is valid, allowing for the completely bypass of all ECDSA based systems. Luckily for us, this code hasn't been in production very long.

Overall, a basic cryptography blunder was made in the Java library that affects a ton of companies. If you are writing crypto, please make sure you understand it!