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!

In April of 2023, a malicious proposer tricked the Ultrasound relay into revealing the contents of a block by committing an invalid block initially. This allowed for the attacker to perform an unbundling attack to reorder the transactions against the builder's MEV attempts to get a heavy profit of $50M. Troy found a variant of this attack on the Titan relay implementation.

Running validators and building optimal MEV blocks are entirely different specializations. So, the validator (proposer) can outsource their block building to another entity called a builder. The relayer is an intermediary that can take multiple proposals (aka how much they will pay the validator to make the block how they want). The secrecy of the built block is of the utmost importance to the builder, as we learned with the 2023 attack.

During a proposer's slot, it will request a payload from the relay. It will then sign and thereby commit to proposing this block without seeing the entire payload, which is called blinded. The proposer will then send the signed block back to get the relay to send back the unblinded block, revealing its contents.

This blinding approach works because of duplicate block slashing. If the proposer signs the commitment, gets back the other block, and frontruns the original with their own malicious and unbundled block, then it will get slashed (lose funds) for doing this. To make this even harder, the relayer delays responses to line up with their proposal windows end in order to make it harder to perform unbundling attacks.

Ethereum blocks contain a blob sidecar (additional blob information). When a Beacon Node receives this, it will reject it if the commitments do not correspond to the blob contents. The function validate_header_equality() verifies the contents of the signed execution payload match what the builder supplied but it does NOT check the KZG commitments.

Since invalid KZG commitments can be provided, the block will be rejected when propagated but the relayer doesn't know this. So, when the block is returned, it can be unbundled when sent back to the proposer to do the same attack as from 2023. To fix this, the code now verifies that the builders and proposers have matching KZG commitments.

Overall, an excellent blog post that is rich in context for those (like myself) unfamiliar with the MEV builder and proposer market.

Anchor is a common framework for building Solana contracts. Compared to vanilla Solana contracts, it adds many safety features and makes it easier to write secure code. Frameworks that compile your code do have the drawback of not being fully understood by the programmer, though.

The author starts with a Solana smart contract written in Anchor with only a single instruction - initialize(). By default, Anchor adds seven extra instructions to the contract, which have to do with the IDL (Interface Description Language) storage. It is mostly just account management (create, resize, close), though. There are also buffer accounts that can be stored prior to storing information in the main account.

The instruction IdlCreateAccount is permissionless but can only be called once. It creates the IDL program snd assigns the IDL authority. This means that if an attacker finds a program without this set or frontruns the call, they are able to specify a malicious IDL file. Since this is used to call the program, an attacker could abuse this in sophisticated phishing campaigns.

This is a known issue. Additionally, I'm guessing that most Anchor programs, when deployed, will upload their IDL file at the same time. Multiple instructions can be executed in a single transaction too, so I'm unsure if this is vulnerable to frontrunning.

IdlCreateBuffer enables a beautiful primitive for a Solana-specific vulnerability called type cosplay aka type confusion. Solana accounts should have a discriminator on them - bytes at the beginning of the account (data structure) to define the type. If this isn't checked, then havoc can occur. This instruction allows nearly arbitrary data to be stored in the account. As a result, this creates a great data store primitive for exploiting type cosplay issues.

To remediate the issue, you can upgrade the contract with a custom instruction to swap the IDL's authority back to the intended party. Or you can just disable the IDL instructions. There is a fix on the way; I'm guessing that it just sets the IDL's authority to be the same as the program's, preventing this altogether.

This is a pretty interesting bug because so much fraud occurs in crypto. I personally like the type-cosplay primitive the most of the two things! Overall, great post and I look forward to reading about more Solana things!

A terrible vulnerability in an OAuth implementation is an arbitrary redirect. This is because the code from the OAuth provider is sent back in the URL before being turned into an access token. If an attacker can get the redirect to happen to their website with the code in it, they can compromise the account.

The redirect_uri is usually incredibly strict and checked by the provider. A value commonly used to hold extra state and prevent login CSRF is the state parameter. In some implementations the data is not validated as thoroughly but can control the flow of execution still.

The author found that the state parameter contained functionality to redirect to a secondary domain after the original domain, somewhat separate to OAuth. Their hypothesis is that the application had several different areas depending on the platform so it needed a firm redirect to satisfy the providers requirements and then would redirect to the platform specific page once it was done.

This redirect on the state led to a one-click account takeover of the applications account. I had personally seen this state used like this before so it was interesting to see a vulnerability in it. Good find!

ClipSp is a Windows driver used for Client Licensing. Because it's fairly sensitive, the driver has no symbols and they're even obfuscated. The author of this post spent some time reviewing this code to find a few OOB reads and writes.

The format processing is tag-length-value (TLV) format for a large group of blocks. Each one of these tag entries represented a bit of license information. One of these tags was a signature tag.

The code would iterate over the top of every single tag. When it saw the signature block it would use the an index to count to the number of bytes in the buffer before this that needed to be signed.

The issue with this scheme is that the data after the signature block would still be processed without being checked by the signature. If a field was already used, it could even be overwritten. I like this bug since it's a fairly deep implementation flaw of the algorithm. Good find!

Running a bug bounty program has a lot of difficulties. The program has a budget for the amount it's allowed to spend. The managers need to understand resourcing and time commitments to the program as well. This article has two tips on making the program better for yourself and hackers.

Three types of hackers do bug bounty: greenhats, passion players, and professionals. The green hats are in it for the money. Passion players do it for the technical intrigue. Professionals are looking to increase their reputation with a nice quote on a website or a CVE to pad their resume. Each of these types has different ways to keep them around. Although all are great things to do as a program manager, I personally appreciate #2 the most.

For the greenhat, bonus's are helpful. Even a $100 bonus for a bug gets them excited and makes them feel like that you appreciate their work. This $100 will go a long way and will likely keep them working on the program for a while. Additionally, pay consistently. If you paid $X for a bug before, don't change it.

For the passionate player, you should compliment their skills. Making them feel like a top-notch hacker will keep them around. Another mechanism to keep these technical folks around is root causing the issue with more technical details than they can see. For instance, information about the backend architecture and why this vulnerability occurred. The passionate players LOVE to understand every little detail of vulnerabilities they find.

The final one is the professional who is trying to improve their resume. For these folks, allowing them to post about the bug publicly, adding them to the hall of fame or any public items are what they want. Job offers also make their day, even if you don't really mean it.

The most important part of the program is the publicly facing policy page. This gives hackers an insight into your program and why they should hunt on it. The first tip is to keep the rules concise and broad, living off of the primacy of impact rather than semantics. The second thing is making it easy to start on. Things like async comms for an email, VPNs or anything else are a major turn off.

For vulnerabilities that are out of scope or long-lasting issues, make sure to publish these changes. It's the worst when you're hunting for something and are dupped by a ten-year-old bug or get out-of-scoped by a recent change to the program that you missed.

The final point is probably the most important: define your threat model. What impacts do you like and dislike? What are the security boundaries of your threat model? All of these things help hackers give the highest-quality reports they can.

I love this post, even though I typically only like the very technical things. Running a bug bounty program well is a skill that is often not talked about. I think this post really helps shine some light into making the program better.

The beginning of the article goes through dumping the firmware from a serial flash chip and accessing UART interface. In the UART interface, they noticed that the Linux OS was not giving any output. To fix this, they modified some UBoot settings to turn on the output. They popped them into a limited but not root shell, limiting their initial capabilities. Now, time for a chain of vulnerabilities!

In the sonia binary, they found a super simple unauthenticated stack buffer overflow. The systems has ASLR enabled, stack canaries and the write is via a strcpy, which limits the amount of NULL bytes we can write. Luckily, there is no PIE. By using a partial overwrite of the stack address (3 bytes), we don't need to break ASLR. In some cases, the 4th byte will be NULL and we will write to that with our NULL byte then. I'm guessing they brute forced this 1/256 chance.

This really limits our exploitation though. We can't write bytes after our address or any null bytes before that. The authors used this exploit to open up a new attack surface: the Image Quality Service (IQ). By calling the function sonia!thread_listen_handle, an unauthenticated listener is created that will loop infinitely. Neat!

Within the IQ functionality, they found a heap out-of-bounds read that returns information directly to the caller. Typically, this is used for an ASLR leak, but the authors had a better idea. In a separate service (DHIP) on the same binary, there are several unauthenticated commands like resetPassword that require a special 8-byte Auth Code with secrets known to the device and technican. By using the heap leak, the secrets for the string can be leaked by continually calling checkAuthCode! Wow, that's a pretty neat exploit and usage of an information leak!

The DHIP service contains an authenticated buffer overflow as well - it's a stack-based overflow into a stack buffer in JSON parsing. Now that we have leaked the password reset information, we have authenticated access to the service. The overflow occurs in a strncpy, which doesn't allow the writing of nullbytes with [ being overwritten with nullbytes after the overflow occurs.

The bug above allows writing a single pointer so the gadget must be chosen wisely and then overwrite the return address of the function. At 0x002C0A2C, there is a gadget that will execute arbitrary bash commands from a single provided stack buffer input. I'm slightly confused on how this works alongside ASLR but they say it does :) They had to do some shenanigans to force this not to crash after this point too. Now, we have a command execution on the system!

For whatever reason, this wasn't enough for them - they wanted the ability to execute arbitrary binaries. Since the kernel had ELF binary signature verification, this wasn't directly possible though. LD_PRELOAD can be used to load a library in an approved command to easily circumvent this protection though.

Overall, it is a super interesting blog post on the exploitation of this device. The usage of pre-existing functions to exploit the binary twice instead of a traditional ROP chain is cool to see. Additionally, the heap OOB read to leak secrets is a rare feat as well. To me, this means that binary exploitation will never die but the tricks may become different.

I was curious about the order in which the bugs were found and got a response from the author. They found the RCE bug first to allow for better debugging. Then, they wanted an auth bypass, which led to them finding the overflow and OOB read in the IQ stack. Upon realizing this wasn't hittable code, they found a way to turn it on. So, they effectively did this in reverse!

Spectral V2 allows people to create on-chain AI agents. Each agent owns a wallet that allows on-chain actions. There are three main contracts:

• AutonmousAgentDeployer.sol: handles swaps between SPEC and Agent tokens.
• AgentToken.sol: Goverance token with a taxing functionality. This tax is important for later.
• AgentBalances.sol: Manages and distributes tokens that came from taxes.

When transferFrom() is used on the token, a tax is applied to the funds being moved in AgentToken. Whenever this occurs, the AgentBalances contract is given an infinite approval to spend funds on behalf of the caller contract. Infinite approvals are prone to abuse, but they typically involve simply stealing funds.

The swapExactTokensForSPEC() function on the AutonomousAgentDeployer contract calls transferFrom(). If an attacker calls this function it gives the AgentBalances an infinite approval on this contract.

The attacker called a public deposit() function that allowed for the specifying of the from, tokenAddress and amount values on the AgentBalances contract. They don't have the ability to steal the tokens though - only transfer them somewhere else by mode of approvals. Why is this useful though?

The AutonomousAgentDeployer contract balances were used as part of the constant product market maker algorithm between AgentTokens and SPEC. Hence, if tokens were removed from the contract to somewhere else it would then change the price of the swap drastically!

So, the attacker triggered the infinite approval and exploited the approval to manipulate the price of the SPEC token. Since there is almost not AgentToken left only a small amount of AgentToken needs to be used in order to take all of the SPEC tokens. This exploit stole about 250K worth of tokens.

Overall, it is an interesting exploit! Sometimes, you find yourself with a primitive, like moving tokens from one account to another, but it isn't immediately useful. From there, you must find an exploitation route to profit from it. This feels like a good example of that.

I personally have no idea how Dark Web marketplaces work outside of them using Tor. This seems to have some good insight into how it works. I also learned that Donald Trump plans on releasing Ross Ulbricht, the founder and convicted felon of the Silk Road.

JavaScript is not seen on modern Darknet websites. Why? Websites can be actively fingerprinted, regardless of Tor's efforts to prevent this. Not using JavaScript drastically reduces the attack surface. But how does a modern website even work without JavaScript?

Captcha uses a weird feature of the browser's input type that will send the X and Y coordinates that were clicked in the image. People also do some crazy things with CSS. Most of the complicated code is run server-side instead of client-side as a result.

The onion links are nasty to look at. So, phishing becomes even easier against non-tech-savvy users. This is particularly bad because there are multiple mirror links of the same website. To get around this, there are multiple points where you are forced to think critically about the decision you are about to make.

Messages are typically encrypted using PGP, which is registered at account creation. If a message needs to get sent to the user, such as for 2FA, it's done using PGP.

After a user is logged in, they are given a publicly accessible website link to access the "clearnet". Since these are more risky, a given group of authenticated users is given a unique mirror to make the URL private and unique. After a user makes a transaction, the pool is upgraded. I'm not super clear on the terminology here but it sounds like a lot of defense-in-depth measures.

Many websites have an integrated wallet. This way, you can send your funds in once and just use them on the provided account all the time. To prevent exit scams, it's typically a 2 out of 3 (user, vendor and market) multisig wallet. Once you want to buy something, you communicate the shipping details using the PGP key information.

Remaining perfectly anonymous is really hard. Things like language and region-specific writing, such as commas vs. decimals on large amounts, made it possible to narrow down the location of the operators.

Overall, an interesting look into the design and usage of a darknet site. Good write up!

needrestart is a tool that probes the system to see if a system or service needs to be restarted. It's called when using apt-get upgrade when a shared library does not exist on the system anyone. The authors of this post for 3 LPEs in the application that runs as root.

To determine whether a Python process needs to be restarted, needrestart extracts the PYTHONPATH variable from the process before executing a pre-loaded script. Since an attacker can set the variable and the process uses the interpreter, we can put our binary at this path and execute it as root. The same issue also exists in Ruby as well.

To determine whether a process is Python or not, it checks the processes /proc/pid/exe file then matches it against a regular expression. A previous vulnerability existed on this that the regex was not anchored at the beginning and end. They realized that there is a time of check vs. time of use (TOCTOU) issue that allows for the verification to read one path but then the execution to use another by switching it out. Both Python and Ruby were vulnerable to this attack.

In Perl, the functionality was different than the other two. Instead, it calls into scan_deps to analyze a Perl script but reads its source files recursively. Unfortunately, it feel victim to a super bad pitfall in Perl: insecure usage of file operations. In Perl, open() will execute bash commands if there's a pipe (|) inside of it. By passing in /home/jane/perl| as the file name to read, the bash script gets run. Crazy!

After finding the insecure usage of open, there were several eval() calls vulnerable to code injection vulnerabilities as well. It's interesting how these vulns got through - many of them are fairly simple issues that I thought had died out years ago.

I love the Qualys posts. Straight to the point on the vulnerability with zero fluff. They keep finding really bad vulnerabilities in things on Ubuntu. On the Day Zero Podcast, they mentioned that the easiest way was the Kernel for a long time. Since that has been hardened, people have started looking elsewhere such as the userland apps that run as Root.

Cross-Site Request Forgery (CSRF) attacks have been mitigated largely by browser protections like SameSite cookie flags and pre-flight requests. Some technically work because of browser behavior but shouldn't be considered security-safe because the functionality could change.

One mechanism for detecting CSRF is the rejection of requests with a Content-Type not equal to application/json. Since JSON triggers a pre-flight, it's common to use other content types, such as text/plain, to avoid this.

There are some notable bypasses for this though. For instance, 307 redirects with Adobe Flash player in Firefox and in Chrome the navigator.sendBeacon had a vulnerability to set the content type header to an arbitrary value.

The fetch API in JavaScript is used to make web requests. This function accepts both a string and a Blob object. By passing in a Blob object without a type into the fetch function, it will send a request without CORS or a content type header! The actual data in the blob will become the body of the request.

They give an example of a Ruby on Rails endpoint that first checks the existing content type and then checks for the application JSON. Since it doesn't exist, the check is effectively skipped. Although this is unlikely to work as a complete bypass, it's an interesting trick none-the-less.