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!

APC is a subsidiary of Schneider Electric. They have Smart-UPS (Uninterruptible Power Supply) that provide emergency backup for ICS, server rooms, hospitals and many other things. Finding vulnerabilities in these products could be quite bad for the world.

The reason for the name TLSStorm is that the vulnerabilities originate in the TLS handling. In order to handle the TLS communications, they use nanoSSL. However, by not properly handling the errors from this library, many security issues arise from it.

When doing the initial TLS handshake, there is a ClientHello and a ServerHello message. After this, they exchange cipher suites. However, if the client decides to use a cipher suite that the server does not support then the exchange will fail. According to the documentation of nanoSSL, this should result in the termination of the connection.

In the case of the software using the library, not error checking was done from the function. This saves the TLS master session key as ZERO. Hence, by using TLS resumption, it is possible to convince the server that this is a trusted user, bypassing the certificate validation. Neat!

While reassembling a packet, there is a maximum size that the payload can be (2389). Anything bigger than this and the library will return an error message and not reallocate the buffer. If an attacker sends a packet with a huge length field, the buffer will never get reallocated and it will copy in packet data until that length is reached. Another neat bug!

The final one is that the firmware updates use symmetric encryption in order to keep it from being tampered with. However, an attacker can figure out the key, reencrypt their own package and upload the firmware. Instead, they should be using a digital signature to validate that the firmware is legit.

The complexity of the firmware supply chain creates the potential for many security vulnerabilities. Additionally, the need to update things ONLY as an authenticated user is complicated in the context of firmware; cryptography is not always easy to do securely.

The vulnerability is within the USB Data handling code. The complexity of the code cannot be secure by design, as they have found 8 CVEs in this location in the past six years. The UsbRt API interface tends to take in pointers that are read, written to or do other things. In CVE-2017-5721, this exact problem was found.

The "patch" (bunny quotes) for this was to use a CRC on the data. Of course, an attacker can simply generate a valid CRC themselves to call this. As a result, the patch from the previous CVE was insufficient, which led to the ability to call arbitrary functions with arbitrary parameters. Yikes!

To prevent this type of bug from being used to, Intel added a protection to NOT allow code from outside of the SMRAM from being executed. This is done in order to prevent a class of vulnerabilities known as System Management Mode (SMM) call out. However, this protection can be bypassed by using a ROP chain, as detailed by Synactiv. The authors of the post claim that ROP chains are simple to create because of how the builds work on UEFI.

Overall, an interesting blog post in an area that most of us never get to look at. I wish the blog post had a lower level of entry, since many of the acronyms and previous research were unknown to me.

The piece of hardware being reverse engineering is the Sony Memory Stick. A few use cases include Aibo Robot Dogs, Magic Gate DRM and GPS devices. The whole purpose of this project was to simply preserve and understand history. For reverse engineer, there are 10 pins on the stick, with pin outs available at pinouts.ru.

To start the reverse engineering, they analyzed an old Sony CLIE PDA. From looking at the wiring the author knew this was a simple 1-bit transform mode. To make his life easier, PalmOS 4 binaries were built with almost all function names still intact and 68k is an easy to reverse engineer architecture. The author took a look at the interface with a logic analyzer to come to some results.

To send information about ready a 0xAA or 0x55 was sent on the line. If the given phase is over, it will toggle to the last bit of the phase to indicate it was done. The 1-bit mode had three wires: BS wire for bus signal state, CLK for the host to send the card a clock signal and SDI0 for the bidirectional data. In 4-bit mode, SDI0 become SDI0, SDI1, SDI2 & SDI3. Data lines are pulled down, the clock idles low and data is set on the rising clock edge.

When sending a transaction (TPC), the TPC is made up of 8 bits, where the first 4 bits are the inverse are the final 4 bits for determining errors. The top-most bit holds the operation: read or write. The data is always followed by a 16-bit CRC with with an initial value of 0 and a polynomial of 0x8005. The flow of information is as follows and is similar between host to card and card to host:

1. BS line goes high.
2. A bit with no meaning is sent to wait for everything to sync up properly.
3. 4 bits of a TPC are sent followed by the next 4 bits that are inverted. The FINAL bit is inverted with the BS line going low in order to indicate a phase change for the data mode.
4. Receive the data. The length is pre-configured.
5. CRC is sent. The least significant bit of the CRC has its bit flipped and the BS line goes high in order to indicate a phase change.
6. Send the data over the SDIO line and a CLK over the CLCK line.

There are several registers for configuring modes, accessible memory and other things. From reverse engineering the binaries, the author figured out what all of these registers means, including the type of stick being accessed and the INT register for showing errors. The commands and registers are completely different from the PRO and the original version of this.

The commands for the memory stick are raw NAND flash commands with a few extra steps. The NAND must handle flipped bits by using error correcting codes (ECC) and handle blocks that are no longer good with wear leveling. To allow blocks to go bad, 3.1255 of the devices raw capability are hidden for the remapping of blocks with wear.

When a Memory Stick is inserted, it must be mounted. The per-device management is stored within the Boot Block and the Backup Boot block, which are written at the factory. Both of these are marked as special sections in the out of band (OOB) and the block itself. The information in these structures pertains to memory mapping, sizes and many other things. To mount (after verification of everything), a mapping of physical to logical is made to read the OOB properly with the block faults and everything else.

To read from a logical sector, we need to divide the number by the logical block number. The remainder of this is the page within the sector. Using the table to convert from logical blocks to physical blocks, we can find the physical block number. Once we find this, we read the page (from the previous math) of this block. The write is fairly similar; none of them do block relocations when an error occurs.

The author wanted to see the MSIO (misc I/O) on the memory sticks as well. To find the functions associated with this, he wrote a value in the register category. If data can be read back, then it's a valid handler. Neat trick to figure out how things work! Every device that used this interface did it in a completely different way, making the reverse engineering even more fun to deal with.

The Pro had an entirely different set of commands and register information. The author claims it is easier to deal with, since more sane choices were made for it. Interesting article (as always from this guy) on reverse engineering complicated things!

ReadySHARE is a feature of Netgear router feature that is used connecting to a printer via USB as if it were a network printer. When a printer is plugged into the router, this feature is automatically turned on for the router.

The router takes in a connection on port 631 by creating a new thread. This accepts a HTTP-like request (but made from scratch with very little validation. The code snippets in this are quite large and Hex Rays dumps, making them not so easy to read.

While parsing the content of the body, the contents of our request are copied into a stack buffer via a memcpy. Since we control BOTH the size of the overflow and the bytes with no character restrictions, this is a pretty awesome bug to exploit.

In terms of binary protections, there is no stack canary, Nx is turned on, no PIE (.bss and .text randomness), no RELRO and ASLR is partially enabled. The libraries and stack are randomized but the heap is not. Additionally, the location of the overflow is at the address furthest away from the return pointer. As a result, we are going to have to craft a set of fake objects in order to allow for our exploit to happen.

The first thing they did was find a path that hit the least amount of possible things. In particular, they escaped the while loop that the buffer overflow occurred in by editing the index value to be

They decided to create a leak primitive in order to be able to reference pointers and call specific functions in LibC. In order to do this, they found a pointer and a size they could overwrite that would return data over the socket to them. However, along the way, they overwrote a socket fd. So, they brute forced the socket fd between different runs.

The final road block was that the pointer would be freed prior to returning the data. This meant that they could only leak data information that was on a valid heap pointer. For whatever reason, a few spots in the Global Offset Table (GOT) in the .bss section wouldn't crash on this but they never investigated why. They could have just gotten their leak from the heap as well, especially considering the heap was not randomized.

With the LibC address in hand, they could calculate the address of system. We still need a place to reference a string and we do not have a stack leak. So, they used a known trick with 32-bit and mmap not being randomized so well. By making a large enough allocation in LibC, it creates an mmap call directly, making it trivial to find our string.

From there, they create a ROP chain to call system with our string placed in the mmaped chunk. To pop a shell, they used the command "nvram set http_passwd=nccgroup && sleep 4 && utelnetd -d -i br0" to backdoor the device. Now, The password is reset and we can take full control of the router.

I really enjoyed this article since it showed the messiness of hacking and making things work. There are a few interesting tricks in here as well, making it all the more enjoyable!

Socket programming is hard. This is a VERY comprehensive page on sockets and how to use them. Just saving this resource for later :)

slaacd is a stateless address auto configuration (SLAAC) daemon. In the IPv6 protocol stack, the Neighbor Discovery (ND) protocol is used for gathering information about network communications, gateways and many other things. One particular type is a Router Advertisement (RA) packet. This particular bug is an OpenBSD.

One of the many options in RA is a DNS Search List Option. This contains one to many domain names of DNS suffixes. Domain names included in this format are encoded with a sequence of labels, which each have a corresponding length byte.

While processing this data, the length byte is improperly used as a signed value instead of an unsigned value. By crafting a length that has the most significant bit set to 1, it believes that it is a negative number instead of a large positive number.

This vulnerability breaks the sanity checks within the code. In particular, it tries to ensure that the length of a single entry does not exceed 63 bytes. But, since our length is negative, this sanity check is not triggered, which eventually leads us to a memcpy.

When the size goes to the memcpy, the signed integer is transparently turned into an unsigned integer. This leads to a huge write occurring within this memory space, ending up as a heap overflow. Since this is a bad size wildcopy, it is unlikely to be exploitable.

Regardless of the exploitation viability, the author wrote a script in Python using Scapy for networking.S capy is a Python program that enables the user to send, sniff and dissect and forge network packets. By having access to data at this low of a level in the stack, the author was able to trigger the bug for a crash.

One night, the author of this post decided to look at the netfilter subsystem of the Linux kernel. Netfilter enables packet filtering, NAT translation, packet logging and many other things. In particular, they chose to review the protocol parsers for two reasons. First, protocol parsing of non-trivial data tends to be error prone. Secondly, the configuration input came from userland with good control.

While digging through the source code of this functionality, they ran across the following line:

entry = &flow->rule->action.entries[ctx->num_actions++];

This line caught their eye because it was incrementing ctx->num_actions and using it as an index without any bounds checks. Secondly, the struct flow->rule->action.entries had seemingly not obvious relationship with ctx->num_actions. Not a bug yet but a code smell that prompted for more review!

How do we determine if an overflow of some sort is occurring here? The hacker asked themselves what is the length of the action.entries array, what are the controls on this function and how are things initialized? All great questions to get to the point of figuring out if this is a bug or not. While diving into this, they found that the path for how things were called. Additionally, they found that the num_actions counter is ONLY incremented when the NFT_OFFLOAD_F_ACTION flag is set on the offload flags.

When reviewing the code that called this functionality, none of them were setting NFT_OFFLOAD_F_ACTION. The problem is that the actions array is allocated based on the number of immediate expressions types and does NOT take into consideration that this index could be incremented. As a result, the MAX index would be different than the original allocation size.

Finding a supposed vulnerability in the Linux kernel and trigger it are two different things. The author had to learn how to trigger the code for nftables. After playing around with the CLI for a while, they noticed it was adding arbitrary restrictions, which screwed up his exploitation attempts. Because of this, they use the GoLang implementation with custom overwrites. After playing with binary settings and tracing code, they were able to trigger the bug with a kernel panic. Exploitation time :)

When starting to hit exploitation, it is crucial to know what the bug provides. The dereference code above gave as an entry struct to play with. In particular, the fields id and dev were being written. To find the offsets of these structs, they used pahole. The id field writes a value of 4 or 5; dev was writing a pointer 24 bytes past the end of the array.

The size of the allocation depending on the amount of immediate rules that were inside of the filter. With no rules, it was 32 bytes; with one rule it's 112 and two rules it is 192. The allocation location is important, since it changes the heap (slab) location that is used. While hunting for target objects in this slab, they hit a road block, since no good targets were around.

After going through this post on a recent kernel bug, they realized something: this bug can be triggered multiple times! This allows hitting different offsets as a result and chain multiple objects together. The post by Alexander Popov uses the security pointer of msg_msg at offset 40 (which is hittable offset by us) to land an arbitrary kfree.

Using the security pointer inside of msg_msg as a target, it will eventually be freed. Since the write will have our net_device pointer (dev in the code above), we have manufactured a use after free from this. In order to make this viable, a ton of heap spraying was done to get tihs to line up JUST right for the attack.

Once the free has occurred, the goal is to get this heap chunk back to overwrite information within the field. In particular, we can set the net_device.netdev_ops function pointer to get code execution in the kernel when this object is overlapped. The exploit chain above has a few nice quirks:

• The overwritten pointer for list_head.prev inside of the msg_msg can be FOUND by calling MSG_CPY. This allows us to know which one is corrupted.
• Besides being able to tell if it's corrupted or not, it contains a kernel heap pointer for us!
• Checking the /code> of a security pointer tells us WHICH one was corrupted with the ID value from above. Boom, code execution!

The exploit was the opposite of consistent though; they kept getting crashes and had no idea why. They hypothesize it had to do with freelist randomization or the other sporadic allocations within the 128 slab (they tried to rewrite this in a different slab even). This was working 30% of the time, but they never figured out what was making it fail. The exploit code is on Github.

Overall, a super interesting post about the bug discovery, primitive gathering and exploitation strategizing. I absolutely LOVE Nick's blog posts since they show the nitty-gritty details of finding and exploiting bugs in the Linux kernel. Good work!

ClickHouse is a Database Management System (DBMS) for online analytical processing. This is a web analytics tool used for seeing what is going on with a database.

When sending a request to the server, compression can be used. On the server side, it will decompress the file according to the header that was sent. The struct used for this has a few fields: hash type, compress method, compressed size (without checksum), decompressed size and the actual compressed bytes. The client supplies the entire struct to the server and thus controls all of its contents.

The size of the allocation made for this is from the decompressed_size field. When the copy actually happened, this size value is not used though! Instead, the data within the buffer is used instead. This creates a fairly standard buffer overflow.

As a proof of concept, they set the size to be 1 and sent over a large payload that was much bigger than this. There is some magic that goes into the size of the actual data being proper, but they do not explain it. Eventually, this segfaults with control over an indirect call (function pointer). Sick! There is the same bug in a similar location that is not covered in the post.

When doing the decompression, a 16-bit user supplied offset is read in from the compressed_data field. This is then subtracted from the current pointer location. There is NO validation that the offset is smaller than the real pointer being used. Down the road, a copy is done, leading to an out of bounds read. A similar variant of this bug exists but is going forward on the offset instead of backwards.

I assume that the offset specified above is for pagination or something similar. Additionally, they found a divide by zero bug which simply crashes the application.

Oxide is building a computer completely from scratch. Before blindly using something, they have decided to completely understand everything on a chip before using it. While developing a product for the LPC55S69, they found undocumented code last year that led to a huge security problem. They are back at it again with these bugs!

The In-System Programming (ISP) interface is used for a signed firmware update mechanism that exists on the ROM. This is for updating the firmware of the chip itself in the case that a critical security issue was found on the chip. Doing this securely requires perfect code and proper cryptography.

The ISP interface receives data in the SB2 format. This format includes a header followed by a set of commands to modify the flash or start code execution. To ensure confidentiality and integrity, the update commands are encrypted with a key set at the manufacturing line.

The update itself is parsed as groups of 16-byte blocks, where different parts of the update are referenced by this block number. The SB2 parser copies the entire ROM into a global buffer before checking the signature. However, instead of just grabbing the header information for this (128 bytes), it uses the field m_keyBlobBlock. If this variable is harder than 128, then a buffer global memory buffer overflow occurs.

In practice, this causes major security issues. By using this buffer overflow, code execution is possible until reboot of the chip. However, since we now control the flash update mechanism, this can be used to modify flash contents, ignoring the signature verification altogether. The POC mentioned in the article enables SWD mode on the chip in order to allow for debugging the existing ROM, which should not be possible.

There are some mitigating factors though. First, if the system is secured with secure boot and sealed via the Customer Manufacturing Programming Area (CMPA), modification of the code in flash will be detected on boots in the future. I was also thinking that if the commands must be encrypted, then can this code even be hit?

Overall, another really interesting finding within the NXP chip by Oxide! This seems like a super cool product and company to work for.

In the land of Windows, the usage of %ENV_VAR% can be used to reference environmental variables. Commonly, this is used within CMD as developers.

When saving a file, the name of the saved file can be returned. This is expected and useful functionality within the web. However, saving a file with the name as an environmental variable had some weird functionality.

In particular, if a file was saved with an environmental variable name, such as %username%, it would return the value of the environmental variable! It is common for developers to store secret information, such as AWS_SECRET_ACCESS_KEY, Github secrets and many other things. As a result, this attack could be used to steal sensitive information from a device.

How would you get a user to save a file with an environmental variable as a name? Using the window.showSaveFilePicker function, a malicious website can specify the suggstedName field for the file.

But, would a user save a file with this name? The attack that the author came up with is super cool! They make a site that says "Hold Enter For 2 Seconds". While holding enter the Save File screen comes up, which will auto focus onto Save File screen. Now, the save button will be triggered, with only a flash on the screen.

This bug is only applicable on Windows but effects Chrome, Edge and Opera. Although the usage of the ENV variable in the file name does not seem like a big deal, the attack method of the auto focus made this feasible. I would bet this could be used somewhere else in the future for similar attacks that require user interaction