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!

This website gets itself over TLS and comments on every single byte. It's a really neat visualization of the process.

Das U-Boot - the universal boot loader, is a bootloader for embedded boards for ARM, MIPS and several other processors. This is typically installed early on in the boot process to initialize things components. It has support for an unreal amount of things, such as various drive types, a network and USB stack...

U-Boot has an interactive shell that is turned on by default. If enabled on embedded devices, attackers can modify or dump the firmware quite easily. The article contains many ways of doing this, such as using TFTP, over USB or even over serial.

Using TFTP, we can boot into a modified file system to backdoor the device. Pretty neat! They mention a tool called DepthCharge as well. This is a tool for jailing U-Boot with a lot of automated information dumping. If you're doing an audit of U-Boot, this appears to be the tool to use.

The age-old trick of modifying the init script to be set to /bin/bash did not work. So, instead, they choose to modify the flash memory chip with their own version. They dumped the code, used unsquashfs to unpack the file system, backdoored it, resquashed it and wrote it back.

The bootdelay variable is used to determine how long to wait prior to booting into the OS. If this is set to -1 or -2, this check is skipped entirely. Practically, this means that it's not trivial to get into U-Boot shell. To bypass this, a forced error in the reading of flash will drop you into a U-Boot shell - this is called Pin2Pwn. Can we stop this!? You can't.

The variables bootdelaykey and bootstopkey are passwords for stopping/delaying autoboot. If you don't know these passwords, then you can't go into the shell (even with a glitch like before). This is simply a plaintext password in an ENV variable. By either reading this from the NVRAM or brute forcing the password, it's still possible to break in. bootstopkeysha256 is similar but a sha256 hash.

This begs the question: how do we secure U-Boot?

• Sign and authentication U-Boot with a secure chain of trust.
• Disable the autoboot interrupt and the serial console.
• Ensure that bootargs for Linux are not trivial to modify.

Overall, a very in-depth post! I didn't cover everything in my recap since some of it is already in my notes. But, will be a go to article for U-Boot going forward.

Docker is a containization platform used all around. I knew use it to host the Spokane Cyber Cup! Docker was ported from Linux to Windows with a completely different under-the-hood implementation because of the differences between the OS's.

The flow of the service is below:

DockerDesktop.exe->com.docker.service->
docker engine (dockerd)->container

The service communicates using named pipes. This consists of one or more client pipes to one server pipe. Instead of analyzing the code, they used IO Ninja to read the named pipes communication patterns. The author of this post created a new Pipe Viewer for more rich information on the pipes, such as permissions.

The named pipe dockerBackendV2 is created by the service com.docker.service. The pipe resolver communication uses a REST API while running as SYSTEM. The permissions allows a low-privilege user to make calls to this pipe. By calling this API, it's possible to mount to arbitrary locations using the service!

The previous issue was known by the Docker team and kind of fixed. They found another function though: move-data-folder. This will copy data from one folder into another folder, without restriction, using the SYSTEM user. With an arbitrary file write vulnerability, a simple DLL hijacking will give us a system shell.

Windows File Protection was causing problems though. They were able to bypass this using an indirect directory and junctions. Overall, good post on how simple bugs can be found once you understand a complex architecture.

There are many, many ways to login to AWS. The console and the CLI via Access Keys and Secret Keys is one of them.

Multi Factor Authentication (MFA) can be setup to work on the CLI as well. To do this, a user needs to get temporary credentials via the AWS STS service, as documented in the AWS official documentation.

There's a slight oversight with the IAM policy being used for this though: a user can call iam:CreateVirtualMFADevice on the user being logged in! This is the capability to add an MFA device for the user.

The author of the post bought a Hardware OTP and enabled this. Now, they had just bypassed the AWS CLI based MFA from the default policy in the documentation. Principle of least principle really bit them on this one. It's a good reminder how important writing tight permissions is.

Overall, good string of tweets for a interesting MFA bypass on AWS.

The goal of this post for the author was created a modchip for the Wii U. It has a few known vulnerabilities, but not ever many good for homebrew. Additionally, the Wii's encrypted per-console OTP is known to corrupt and not be fixable.

The Wii U has individual cryptographic keys for each console, which means there are unique images per device. There are security fuses configured to disable encryption and sigchecks entirely. This separates the production from development devices. These are provisioned via JTAG, which is locked via eFuses as well.

eFuses are like fuses in a house. Sometimes, they are literal wires that are blown up; other times, they are EPROMS that can be reset via UV light. One way of turning on the developer functionality would be changing the fuses values (which is supposed to be impossible to do) or glitching the system to read these incorrectly.

The Wii U read the eFuses into registers as soon as the device turns on. There are 8 banks of 0x80 bytes. A counter decrements the fuse bit going all the way down to 0 prior to writing. Knowing on the data is read in and when this happens changes how to perform the attacks.

Initially on the Wii Mini (separate project), they tried glitching a very particular branch instruction for verification. While doing this, they found a path that made all of the OTP fuses zero. If the security level could be set to 0, that'd be perfect for turning off all of the security protections. The author wanted which boot stage they were at; this is outputted by LED GPIOs, which is nice for detecting when to glitch.

The first successful glitch was trying to do reset based attacks. By inserting one small pulse (less than a clock signal wide) into boot0, the signature verification succeeded! Sadly, no signs of life within boot1. After this, they tried undervolting to the same effect. Eventually, they bumped the wire connected to reset and got a success! But why?

From my understanding, they reverse engineered the firmware to find the true root cause. To support the eFuse JTAG lock, eFuse bits are buffered into a registry file right after NRST. When doing this registry file write, the write occurs from least significant to most significant on every rising clock edge.

Here's the kicker: when NRST is triggered, the eFuse registry file to reset to zero but the counter for the remaining bytes to write is NOT. On the subsequent boot after the glitch, 0x400-N (N is bytes written prior to reset) bytes will read into the file. This means we can force bytes to be 0x00 in a consistent fashion, including the JTAG lockout fuse and other security bits.

Overall, an awesome post going into the nitty-gritty details of glitching and the magic behind it. Amazing work!

The Adobe suite of products are immensly popular, especially their PDF readers. The PDF rendering process runs in a protected mode called a sandbox with restricted permissions. The PDF renderer has a brokered communication to a non-sandboxed process. So, to escape the sandbox, a vulnerability in the broker would need to be found.

The communication channel is done via a shared memory buffer of 2MB. When the sandbox wants to access a resource, it edits the shared memory and emits a single to the broker; this happens in reverse as well.

When the sandbox attempts to import a key, there are several values that are taken, two of which are used for a size calculation. The pointer size math with the offsets 0x10 and 0x14 is used for a dynamic heap allocation. Eventually, this size is used on a memcpy. The allocation size can be overflowed, leading to a smaller than necessary buffer.

This primitive can be used to get an out of bounds write within the buffer. However, ASLR, control flow guard and some pointer encryption are being used. So, what do we do!? We create an encryption gadget. The pointer used for the CryptoProvider object is encrypted. Still, we can modify the function pointers on top of this object, this is nice.

We cannot modify the encrypted object directly. However, there is a level of redirection. So, we can abuse the redirection of pointers to get the job done. First, we modify a CryptoProvider object to have a call to WinExec(). Next, we point the parameters for this call to a string we control in another cryptoprovider.

By doing this, we have sidestepped the general pointer encryption. Additionally, calling WinExec() is allowed since this is course-grained CFI.

I got a little lost on the exploit strategy to be honest. This is the best I could gather from it. Overall, this is an interesting post diving into Windows, sandboxes and bypassing of modern mitigations.

LinkedIn is a social media site for business professionals.

An entity on a website is commonly referenced by an identifier. On LinkedIn, this could be a post, picture or many other things.

When using IDs, it is important to validate permissions on these IDs. Otherwise, security problems can occur. In the case of LinkedIn, they were not validated the ID of posts upon deleting them.

Practically, this means that any user could have deleted any other users posts. Considering this could be used by competitor businesses or governments to quite people, this is a major problem. It led to 10K in bug bounty money for a simple IDOR.

Buffer overflow to C is Reentrancy to Solidity. Reentrancy attacks are when a user can reenter code in an unintended state in order to manipulate the system somehow. For instance, while withdrawing tokens, the money may be sent but the state variable is not updated. With the money sending call, we could reenter the contract to withdraw the funds again.

The solution to this problem is using reentrancy guards. On functions in Solidity, modifiers can be provided to ensure that the code cannot be reentered. Although this works well for a single contract, what about multiple? Doesn't work so well. Another smart contract may use a state variable (well, gathered via a function...) while it sits in an unintended state.

The author of this post described a system for cross contract reentrancy protection that they implemented in Volt: Global Reentrancy Lock. There are two components to it. First, a global smart contract that holds the state of the locking and unlocking. Second, a modifier for every state-changing function on the other contracts.

So, locked or not locked, right? The author took this a step further with multiple lock levels. For instance, there is a outer level, inner level and a second inner level. By doing this, it prevents functions being accessed while in weird state.

As an example, the authors mention an AMM that has deposits in several locations. While trading with the service, they would not be able to move assets from a different module. Additionally, they should not be able to trade with other AMMs while a trade is in progress. These both could be at a lock level!

The code is a good way forward for reentrancy security. It was tested heavily with Foundry invariant/unit testing, Echidna symbolic execution, and hevm execution. The implementation relies on the lock numbers being implemented properly by the developers and ensuring that the modifiers are properly added.

This seems like an interesting vector for denial of service as well. There may be unexpected code paths that revert because of a weird entry point. Additionally, it doesn't solve the problem of read-only reentrancy as well, assuming these are only put on modifying code snippets.

On April 2nd, a malicious network participant within the Flashbots eco-system "stole" (lost profits) $20M from a MEV searcher by abusing a vulnerability in the mev-boost-relay implementation. When the patches were released, this led to instability within the network and many reorgs.

mev-boot is a protocol designed by flashbots in order to mitigate the negative effects of Maximal Extractable Value (MEV) on the network. There are three main actors:

• Relays: Mutually trusted auctioneers that connect the two other parties.
• Builders: Entities who construct blocks in order to maximize MEV for themselves and the proposers.
• Proposers: An Ethereum Proof-of-Stake validator who is about to create a block.

The ordering of an event for each block is as follows:

1. A builder creates a block by looking at public and private orderflows.
2. The builder submits the block to a relay.
3. The relay validates that the block is valid (previous vulnerability lolz) and figures out how much to pay the proposer.
4. The relayer sends a blinded header and a payment value to the proposer of the current slot.
5. The proposer evaluates the bids they've received and signs the one with the highest payment.
6. The proposer sends the signed header back to the relay.
7. The blocker gets published by the relayer. The rewards are distributed as originally described.

The relayer is a mutually trusted third party that facilitates an exchange to benefit everyone. It prevents builders/proposers from stealing funds.

A fork choice rule is a function relating to reaching consensus on the state of the chain. In terms of time, the PoS system is broken down into 12 second increments called slots. A different set of nodes are assigned to vote on whether a block is legit or not for the head of the chain.

At 4 seconds, the block is proposed. At 8 seconds the voting occurs. At 12 seconds, the next proposer publishes their block. If a block isn't proposed after 4 seconds, they will vote for a previously accepted head of the chain. Why would somebody do this? Letting MEV accumulate is worthwhile because of the amount of funds that can be gained from it, but slows down the network.

How do we fix this problem of actors waiting and causing forks? Boosts! To minimize the amount of reorgs that occur, a fork-choice boost of 40% of the weight is given for a single slot for a single proposer. This prevents reorg balancing attacks. This allows the proposer to have more weight on the approval.

Honest reorgs are the other solution. If there is an attestation weight below 20%, a proposer can forcibly reorder the blocks to prevent a fork on the chain. By doing this, the forks are less likely to occur but the proposers are able to wait for a better proposed block.

An interesting post into the intricacies of MEV and the Flashbots protocol. I don't 100% understand everything here but watch direct adversaries attempt to make money without destroying the ecosystem is fascinating.

CoinVertible is a euro-pegged stablecoin. Although this sounds like a good idea, the authors of this post found some horrible findings in a brief glance.

The eco-system is highly permissioned. As a result, EURCV requires that all transfers and transfer approvals be validated by the central authority registrar. The function rejectTransfer() has a miscalculation in it. In particular, the wrong entity is used for the approval call.

Additionally, the rejectTransfer() function cannot reject transfers if the allowance is extremely high. This is because the math done is allowance + transferRequest.value. This would revert with an integer overflow, making it impossible to reject the transaction.

The second vulnerability mentioned is the lack of a two-step ownership transfer. This is normally done by setting the recipient but forcing the contract to claim the role to finalize the transfer. This is used to prevent accidental self-DoS attacks.

The contract suffers from the standard ERC20 race condition for setting the allowance of a user too. Instead of setting the values directly, simply increasing or decreasing the values should be done.

There were a few other small things, like the transfer event being missing and a frontrunning gas griefing issue. Overall, fun issues with good impact! Although, there is no direct loss of funds found.