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!

Acala is an L2 blockchain built around the Polkadot ecosystem. Polkadot acts as the relay chain which coordinates with other blockchains in the network. Acala, in this system, is referenced to as a "Parachain". The parachain is able to create lots of custom functionality for their needs.

On a Parachain, there are para-validators. These validators are responsible for block creation and block finalization on a specific block.

Home module specific to Acala is the Homa module. Homa is a Tokenized Liquid Staking Protocol. The idea is that DOT (Polkadot tokens) could be put into the module and a representation called LDOT returned to the user. Everyone wins - the protocol has more funds to use in staking, the user gets a little bit of that profit and the user is able to use LDOT on the blockchain for other things. If a user wants to withdraw their DOT token, the user submit an unbond request. Every 24 hours all of the unbond requests are processed at once.

The vulnerability is something relatively simple but complicated to know if it's exploitable: a missing size limit on the amount of unbond requests. Since this list of unbounded (see what I did there), it can be filled up and force the blockchain to process too many in a single call. There's just a big loop that it iterates over.

When I see vulnerabilities like this, I think "PoC or GTFO". Is this actually exploitable? In reality, it is! The blog post says that Acala blocks have a time limit and if this isn't met then the chain halts. By creating 22K withdrawal requests, it slows down the chain enough to prevent the block from being created.

The payout was interesting to me. According to Immunefi, a Governance proposal takes 15 days to go through on Acala - meaning that a downtime of 15 days is likely because the proposal is required for the upgrade. Additionally, DefiLlama has a 15 day volume of 712K per day. Given that the payout should be 10% of that, the whitehat got 10% of it.

To me, this calculate is strange. If a chain was indeed really down the governance would pass significantly faster. Additionally, a denial of service paying 10% of funds at risk is weird to me; it's an L1 that can fix the chain. The funds were never permanently stuck, like if it was a smart contract that couldn't be changed.

A good bug, a good payout and a good writeup!

The original implementation of Elliptic Curve Digital Signatures Algorithm (ECDSA) worked the same as DSA besides it used EC math. It has a known bad flaw: if you use reuse the nonce, then it's trivial to recover the private key with only two different messages. This has been the root cause for many hacks, such as the Playstation 3s key leak from Geohot.

To prevent the duplicate usage of nonces on different data, deterministic signatures were created. The nonce, k, is deterministic based upon the private key and message used. For instance, hash(key||message) would always be the same for every message. Since the attack described above requires two separate messages, this removes the attack vector entirely. Or, so we thought. Since a bug in ellipitic.js was announced, this is being rethought.

If two different messages can create the same nonce value then we have the same issue as before. In RFC6979 the JavaScript implementation converted a Uint8Array to a bigint. This had a bug that doesn't properly add leading zeros to a hex value. So, the arrays [1, 1, 30] and [17, 30] led to the same nonces being used. If an attacker could trick the system to sign these two pieces of data, they could recover the key as a result.

So, if both are bad then how about we combine them? This is the concept behind hedged signatures. If there is BOTH a deterministic portion and a random portion, then BOTH would need to be done incorrectly for this to fail. There are some downsides, mentioned in the post, but it's interesting none-the-less.

The video explores the Cosmos SDK and highlights some of the key security considerations. The person giving the talk is a protocol engineer at Osmosis, a very prominent blockchain in the web3 space.

The Cosmos SDK provides developers with significantly more control over the environment in which they work. Many of the issues surrounding Cosmos SDK chains stem from a central concept: "with great power comes great responsibility."

With general-purpose smart contract platforms, many of the issues are taken care of for you. For instance, smart contracts will price you for each instruction that is executed. They also handle panics for you. In the world of the Cosmos SDK, this is not the case; all of this needs to be manually considered for each blockchain.

In the BeginBlocker/Endblocker, the code is free of most restrictions. There is no gas; there is no timeouts; there is no panic handlers. So, ensuring that a Golang Panic doesn't occur in this section of code by a malicious adversary is essential. It's common for projects to have generic panic handlers to deal with this.

Unbounded operations cannot exist here. Apparently, it's common for a sudo call to CosmWasm to a user-controlled contract to be called. Since there is no gas limit, a user can run an infinite loop, allowing this process to continue indefinitely. Simply adding a gas meter on user-controlled operations is a wise move.

Another big one is non-determinism issues. This just means code that may run differently on someone else's machine, leading to a consensus failure. Things like time-based checks, random number generators, floats and Go iteration over maps are not guaranteed to give the same result. The main solution is just to not use functionality that does these things.

Most L1 handles fees for you. In Cosmos, you can create your own fee markets. For instance, you can make execution free or free in specific scenarios. However, it's important to recognize the ability to exploit this - if you can infinitely add TXs for nothing then an attacker can halt the chain.

Overall, a good video from a knowledge developer/auditor. It's interesting because most of these issues stem from real world issues found on Osmosis.

Meta is known for not taking the privacy of people seriously. It wants to track people and sell the data at all costs. This post is about a mechanism for tracking on Android that bypassed the sandbox restrictions to link what you do in the browser with your real identity even if you never logged into your account.

The Meta Pixel is a piece of code to measure the effectiveness of advertising. This is on many, many websites that help track individual users. The Facebook app runs in the background once opened on Android. It opens a listener on a TCP or UDP port on the device. This is not that abnormal for an app to do.

The combination of the two above is what causes the issue. When you visit a website that has the Facebook pixel on Android, it will attempt to connect to this port. In particular, it will send the _fbp cookie limited to a particular session. Based upon this cookie, Facebook knows what website this was linked to. Once it's sent to the user app, it now knows who was visiting the site!

What's crazy about this is that you could be on a VPN or incognito mode and it still can track you. This has been coined localhost tracking. The captured data includes browsing history, products, registrations on websites and more. The author estimates that fines will be around 164 billion, which is an insane amount.

The localhost tracking is an interesting technique! It's sad that this was found in the wild though.

GitHub Actions provides a policy mechanism to limit the kinds of actions and reusable workflows that can be used. The policies eliminate the failure mode of adding malicious or harmful workflows without further consideration.

The restrictions can be applied to specific tags or commit hashes, as well as to particular organizations or repositories. It's a reasonably practical system for ensuring that a developer doesn't harm themselves.

This policy system can be "bypassed" via calling git clone on the repository and using a relative path. To me, this is a sane. If you downloaded something locally, then you're making an active choice to run the code. At the same time, is does work around the policy preventing of foot-guns.

The author suggests adding a new policy type that can explicitly allow or deny local usage of workflows. I'm personally on the fence about this though. Regardless, an interesting thing to know about for GitHub Actions.

The primary smart contract development language is Solidity. However, this contains many, many footguns that the developers of Stacks have tried to fix. This post goes into he design of their custom language Clarity, and the vulnerabilities that it helps prevent.

The most famous vulnerability in Solidity is reentrancy. This is when a smart contract can call into another contract that eventually recalls your contract. This allows for the manipulation of the state that shouldn't be possible. Clarity doesn't allow for reentrancy at all. Integer overflows/underflows are prevented at the VM level as well.

Clarity requires external contract calls to be explicitly handled. This ensures that errors are handled properly. On top of this, all functions return something similar to a Result type in Rust. This makes the error handling very explicit in Clarity.

All code in Clarity knows the exact amount of gas before execution. To do this, unbounded iterations and dynamic lists are not possible. This prevents many standard classes of DoS vulnerabilities in Solidity. Clarity contains a native VRF function that the VM can call to obtain actual random data. This prevents weird randomness vulnerabilities like in Ethereum-based blockchains.

The final section is my favorite: unknown unknowns. To prevent users from getting exploited, they have post-conditions on the outcome of the contract execution. If these are violated, then the contract just fails. This helps proactively protect assets even if you don't know the vector.

Overall, a good post on the benefits of the Clarity language.

Golang's parsing for JSON, XML, and YAML has some peculiar properties that the author of this post decided to investigate. When unmarshalling JSON, the fields in Golang can be explicitly set with the settings for decoding. For instance:

type User struct {
    Username string `json:"username_json_key,omitempty"`
    Password string `json:"password"`
    IsAdmin  bool   `json:"is_admin"`
}

If the json: string is not included, then Golang will still unmarshal it to the exact name of the field - in this case Username. A less-senior developer may not know this and assume that a field without the `json:"is_admin"` cannot be set at all. To actually tell the parser to skip something - text can be used.

There's a funny quirk about this though! If - is used with any other data then the parser will assume that - is the literal field name! For instance, the definition `json:"-,omitempty"`. The author found two occurrences of this that they reported as vulnerabilities, and several thousand are currently on GitHub. Another misuse is setting omitempty in the JSON as the keyname instead of a setting. Both of these can be trivially found with semgrep rules.

The next class of issues revolves around parser differentials. They label several common issues of misuse: duplicate fields, and case-insensitive key matching. This mostly applies when parsing data in one language and then having it be processed by another.

The final bug class is data format confusion. In some cases, parsers are too lenient and try to get valid data out of whatever you need. The example they use is parsing a JSON file with an XML parser. In the case of Hashicorp, Felix from P0 found that they could smuggle in XML to an endpoint intended for JSON. By doing this, the controlled XML was processed instead of the legitimate one. Eventually this led to an auth bypass.

The XML parser will accept leading or trailing garbage data. All of the parsers in Golang will accept unknown keys that don't match the struct. Although this doesn't have an impact by itself, it helps construct malicious payloads when exchanged between parsers.

Overall, a good post into the weirdness of parsing libraries in Golang.

A list of all crowdsourced audit platforms. CodeArena (C4), Cantina, Sherlock, and HackenProof are all on there. This makes it easier to choose a contest platform by being informed about what's going on.

Rohan summarized a research paper about the effects of LLMs and Google on brain usage alongside effectiveness. The study took people in three situations when writing essays: brain only, Google + brain and LLM + brain.

For brain usage, it's what you would expect. The usage was the highest with only brain, lowest with LLM and in the middle for Google.

Essays produced with ChatGPT were clustered in terms of words and thoughts. Google was more spread out but was very much influenced by the search engine results. The creativeness of just the brain was the best.

In terms of memory, Google and Brain Only were the best - they were able to recall most passages from the essay. With ChatGPT, only 17% of sentences were remembered.

The scariest part to me was the lingering effects. When a ChatGPT only user tried to write only using the brain, they had 32% less brain activity. I guess the brain thinks that the tool is coming?

When the brain-only writers switched to ChatGPT, their revisions were fantastic and brain usage increased. To me, this demonstrates that starting with only your brain is better than starting with the LLM tools.

Overall, an interesting study into the effects of LLMs!

Tips and strategies for writing better prompts. In short, be concise + positive, use examples, and specify the format of output.