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!

Flow suffered a major hack of about $3.9M USD. This was not an application but an issue with the blockchain itself. No existing user balances were accessed; the attacker was able to duplicate assets out of thin air. This is the story of vulnerability and how Flow handled it.

Cadence is a resource-oriented programming language similar to Move. In many blockchains, such as EVM, tokens are in a ledger (a map of balances), and that's it. In Flow, they are programmable objects that exist in a user's account storage, mimicking a physical dollar. These Resources, mimicking a physical asset, cannot be copied or accidentally discarded; they can only be moved or explicitly destroyed. The resources are great, but rigorous static and dynamic checks are performed to ensure resource integrity. If this could be bypassed, it would be a major problem.

In Cadence, Attachments are designed to allow developers to extend a struct or resource type with new functionality. they are values that are just attached to existing resources. When making a transaction, the imported struct and the value types were passed in dynamically. The validation for attachment types was not strict enough, which is the main reason for the issue. Mainly, the fields passed in were not checked against their static declared types, AND the runtime types field information could be specified incorrectly.

So, what's the consequence of this? By specifying an attachment with invalid fields, Cadence would believe that a type is a struct when it was actually a Resource during execution. During execution, this allowed the resource to be duplicated repeatedly. By duplicating coins, you could create tokens out of thin air. The verification system, like this, is scary because the consequences of a mistake are so deadly.

The authors considered this occurrence and did not perform these checks on some internal types because they should only be creatable by the runtime itself. A small number of these internal types, such as PublicKey used in the exploit, can be created with user code. So, the attacker declared a value as a PublicKey and then encoded a resource-containing structure as a value in its place. This allowed for smuggling a resource inside a struct context.

The previous two bugs were nice for copying values. But the resource is a public key type. So, a type-confusion bug was needed to restore the object as a useful resource. On the contract initialization function add(), the static types being used on the call were not validated to match the contract itself. This allowed turning a static public key into a resource. An absolutely crazy chain of three bugs!

The vulnerabilities above were fixed with specific checks. They upped the rewards on the bug bounty program and added a regression test for this exploit. To prevent this from happening in the future, several other things were done:

• Hardened Argument Validation: Prevent rogue fields from being passed in.
• Extended defensive checks for built-in types: Member access checks are done on all types now. This would have prevented the exploit in the first place.
• Strict Deployment Semantics: Match between static and dynamic types on the order of contract instantiation.

The attacker obtained a small number of each of the 13 tokens. Then, duplicated these small amounts in a sequence 42 times to get much more than the total supply of tokens. The attacker tries to cash out on a centralized exchange but is flagged/stopped due to the massive size. A small number of assets are bridged through Celer, deBridge, and Stargate.

So, now what? Are assets gone? Four hours after the exploit took place, the bug was fixed, and validators halted transaction ingestion. Two days later, the counterfeit assets are recovered, destroyed, and the malicious accounts are restricted. Although a lot of tokens were duplicated, the realized damage was about $3.9M via bridged assets prior to the chain halt.

How were the tokens recovered? Via a special contract that had Governance authority to delete counterfeit tokens. Funds that were stolen via DEX's were recovered from the attacker-controlled addresses and designated as liquidity pool rebalancing funds.

An absolutely crazy exploit and an interesting resource. It's wild to me that Flow could delete resources or change ownership via Governance. Still, it seems like most of the impact was limited by this response so I can respect it.

When React2Shell happened, the Vercel WAF needed to block all of these exploits. To incentivize the discovery of these, they offered a $50K bounty for each unique bypass technique. This led to 156 reports and $1M being given out. This article is the learnings from that.

Seawall is the internal request inspection layer of Vercel's WAF. The goal is to block malicious patterns before it reaches the application. Whenever they got a new way to bypass the WAF from a researcher they A) reproduced, B) created a test case and C) added a new rule. Most reports came within 24 hours but some came in the second 24. After that, lots of very sophisticated techniques were used.

At the compute layer (I presume for hosted React applications by Vercel), they wanted to add a mitigation. Since the exploit relies on accessing constructor directly, the runtime denies access to this during React rendering. This broke the exploit path. Even with a WAF bypass, this runtime check would remove all exploitation.

The article doesn't discuss every single bypass. It does go through two bypasses that come from the authors of the React2Shell exploit though. The first bypass that is discussed is around Unicode parsing. Many bypasses try to confuse the parser by replacing regular characters with the Unicode representation in JSON. By normalizing the JSON, this isn't a problem anymore. However, if you Uncode encode the Unicode multiple times, this protection no longer works. Now, the WAF will decode recursively over and over again.

Most of the exploits were around the prevention of :constructor with a colon. By finding another gadget for property access that used property access and string interpolation, it was possible to use constructor instead. This shows the power of slight deviations in the original exploit.

Why did they do this? To test their infrastructure against real attacks. This could not have been simulated. The bypasses to the WAF are now permanent additions to the Firewall product, making it useful for the future. Overall, a great blog post and a great campaign by Vercel.

The React Flight protocol is used to encode inputs/outputs for React Server Functions and Server Components (RSC). This is a Backend For Frontend, similar to GraphQL. When requirements for complex UIs are made quickly, Flight enables data to be transmitted back and forth. By using streaming like this, the UI can render as soon as it receives requests from the backend with promises.

In the Flight protocol, data is sent in Chunks. These chunks are labeled as integers for the keys of a JavaScript object, and the values are streamable data sent. Using $@0 allows for data to be streamed later on an as-needed basis, which is a promise. The twitter post linked is great but the wiz article has a little bit of an easier payload to follow.

The Flight protocol is only intended to transport user objects. By setting the status to be resolved_model, an attacker can express the internal state of the application for React.

In JavaScript, anything that has the function .then() is considered a Promise. Adding then to the internal object treats it as a promise and executes the provided then function. This gets executed as a promise because of the previously used $@0. So, chunk 1 triggers the resolution process for the promise in chunk 0, which causes the vulnerability. The then contains $1:then.

The vulnerable code that we're trying to trigger is this: response._formData.get(response._prefix + obj). By overwriting the get function of the response objects with another function and controlling the prefix, we can make an arbitrary function call within the context of React. By using the constructor() as the get and JavaScript code as the parameter, we get arbitrary execution.

The reason for the specific payload is to trigger deserialization. This deserialization occurs because of the type of object inserted into the flow. It's crazy to me that it's possible to overwrite a field on an object that will eventually execute a function in JavaScript. This is why the payload is recursive: to make this possible. They needed the internal reference to a chunk object in order to be able to access the prototype information. This is described here.

Overall, an absolutely crazy exploit that took hours to craft I'm sure. RCE in a large percentage of websites is a huge deal. Great find!

Xspeeder is a networking vendor that makes routers, SD-WAN appliances, and more. Their core firmware, SXZOS, powers a line of SD-WAN devices that are especially prevalent across remote industrial and branch environments.

The company that made this post is pwn.ai - autonomous hacking. The AI starts with nothing but a target and figures it out. From device emulation via VirtualBox to attack surface identification to finding and exploiting an RCE bug.

They published the logs of what the AI was doing/doing, which is really interesting. The installation of the ISO and usage in qemu is pretty straightforward. After that, it performs file system reconnaissance to locate a Django service.

In the Django service, the bot finds the pre-auth attack surface. This is its target. Within the unauthenticated GateKeeper, some code finds that uses a vulnerable sink; this was found through a simple grep for known bad things in Python, such as eval() and os.system().

At the end, it needs to create the request. The data is base64 encoded so they must prepare this. Additionally, since the real purpose of this is to convert a string to a dictionary, the fields in the payload must be strings. There are a few headers that must be set but this wasn't a problem for the bot.

This vulnerability is absolutely a low-hanging fruit. But, it was able to setup the IoT device and find the vulnerability all by itself. If computers can run all day, there's no stopping these bots from finding all of the bugs like this. Good find!

In Anchor, the main framework for developing Solana programs, there are two identifiers for creating accounts: init and init_if_needed. init requires for account creation to occur otherwise it exists. init_if_needed will always run but will create the account if it doesn't already exist.

So, is there anything an attacker can open where init is required? Associated Token Accounts (ATAs) are 100% permissionless to create. So, using init with ATAs is a bad idea.

AVideo is an open-source audio/video platform to create video-sharing websites, similar to YouTube, written in PHP. The information within an encrypted payload is assumed to be secure. For this reason, the project included a callback() parameter in the encrypted payload that triggered an eval(). So, if you could somehow get valid data to be decrypted, you'd get an RCE.

The encryption uses AES-256-CBC under the hood, where the key is a value known as the salt. Despite a change several years ago to fix this, legacy salt generation was kept around via the uniqid() command, which simply returns the machine's microseconds since installation. This timestamp can be leaked by inspecting the default categories in the setup.

Still, online brute forcing of the microseconds of the salt sucks. So, they decided to find an offline version. Each video exposes a hashId that is computed via md5(salt). Since all the information is public except the salt, we can compute hashes with different salts until we find the matching one. This allows us to leak salt.

The encrypt_decrypt() function uses the system root path as the IV. Either via educated guesses or using the the leaked posterPortraitPath from another API, this can be figured out. With the salt known and the RCE path identified, we can execute RCE on the machine. Pretty neat!

Besides this, they found that file uploads and deletions could be performed without authentication, and that an open redirect resulted from a lack of domain validation. Additionally, there were several IDORs from simple missing ownership checks.

The vendor said all issues had been patched. However, the critical RCE issue and everything surrounding it were not. Notably, the salt could still be leaked, and the eval() callback remained.

At the end of the article, they have a few good takeaways. First, if fallback mechanisms are available, they can still be exploited. Second, the more information you provide to an attacker, the more likely they are to have all of the pieces to the puzzle for exploitation. Finally, always check the patches for vulnerabilities; they are often not done properly. Great bugs!

The author of this post has a strict policy on when they will use a product or not for a strict 24-hour research window. This is a hands-on source code review to see how the product would behave in their environment. This is why they were looking into this product in the first place.

The architecture has a UI that makes calls to a backend Django server. The server will trigger Celery tasks that get executed on ClicHouse for SQL. There is a PostgresDB for storing status information about the Celery task as well. PostHog supports thousands of external integrations used for CRMs, support, billing systems, and other purposes.

The promise is to analyze product/customer data, wherever it is generated. To an attacker, this sounds like a SSRF vulnerability waiting to happen. They found a bypass for CVE-2023-46746 by directly calling a PATCH request to store the endpoint used for a webhook. There's also a TOCTOU bug in the verification. Now, we can set the domain to be localhost.

SSRF is excellent, but each one of them has unique exploitation constraints. The vulnerability creates an incoming POST request. Using a 302 redirect, it's possible to change the request method to GET. This is a reasonably powerful SSRF as a result.

The ClickHouse database runs on port 8123 via HTTP; this is enabled by default on localhost. GET requests operate as READ ONLY calls and POST for data modifications. This gives us a primitive for executing SQL queries against the underlying Clickhouse datastore. Using the SSRF, it's possible to extract large amounts of data.

ClickHouse has a ffeature called Table Functions; these are temporary and query scoped tables that only exist during the duration of the query. While reviewing the escaping functionality of preventing SQL injection, they noticed a Postgres-specific flaw: backslashes don't escape. The code would turn 'posthog_table' into 'posthog_table\'', but the backslash is a literal here. So, we now have SQL injection on the incoming query that can be used to write on a GET request as well.

The exploit payload is pretty slick after the SQL injection. First, the internal query must be completed by adding ;END, which makes it read-only. Next, execute a command using cmd_exec and put the results into a payload. An important trick is to use $$ instead of single quotes within the payload. Otherwise, the single quotes would have been escaped once again.

This appears to require permissions on PostHog. It'd be weird to be able to add arbitrary webhooks as an anonymous user. Still, the flow control bypass to get the SSRF and the SQL injection within the ClickHouse endpoint were both great finds!

This is a list of AI hacking techniques. Some of these are prompt injection methods, while others are ways to trick the system. They are broken down into four categories: intents, techniques, evasions, and attacker-controlled inputs.

While setting up Gemini Code Assist tools for personal use, they noticed that the State parameter on the OAuth Authorization flow contained an origin key. This key was used to verify the target origin of post messages, ensuring that only authorized domains request information via post messages. So, a very security-sensitive value.

The domain check was flawed. Notably, it assumed that only a domain string was being passed and nothing else. So, it only checks that the end of the string matches a set of allowlisted domains. By using a path with an allowlisted domain and an attacker-controlled URL, the origin validation could be bypassed. For example, https://attacker.com/codeassist.google.com.

The result is the stealing of an Authorization code for Gemini Code Assist end users. To fix the issue, the origin was treated as a URL with strict validation. Overall, a solid bug in a weird section of code.

The author was reviewing a website when they found two separate issues: a cache decption issue and a client-side path traversal (CSPT) bug. Separately, they were useless. Together, they created an account takeover.

Web cache deception is getting data to be cached that shouldn't be cached via crafted links. While reviewing the application, they appended .css to an endpoint that returned an authentication token. Unfortunately, this API had to include the X-Auth-Token header, which wouldn't be automatically added to the request. This is issue number 1.

They were reviewing client-side code and noticed that a URL parameter was being included directly into part of a path to make an API request. Using a malicious API parameter, the ../ can be used to make the client-side execute an arbitrary API call that is authenticated. They weren't able to do anything useful with this by itself.

Now, let's combine the bugs! Use the CSPT to make an authenticated API request with .css at the end of it. This would cache the API token! The exploit is just the user clicking on the following link: https://example.com/user?id=../../../v1/token.css.

This is a super neat chain of bugs. CSPT and web cache deception have always felt like black magic to me.