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 both EVM and Solana programs, a common security issue is not validating external calls properly. This can led to DOS issues, reentrancy or loss of funds bugs. This article has a list of 7 issues to consider.

There are many ways that calls can fail. "If you don't know how it can fail, you don't know enough" is a great title for this section. In EVM, contracts without receive() cannot receive ETH. In Solana, there are multiple ways this can happen that was already documented in another post. Apparently, ATA creation in Solana fails if the address has already been created.

In EVM, gas griefing can be used to make the main function work but have external calls fail. If the errors are not handled correctly then partial state updates can occur. This isn't possible in Solana because it will always completely rollback on errors.

In EVM, reentrancy is really the output of bad validation of the state and the caller. Sometimes, you do need to make calls to an arbitrary callee though. Solana doesn't have this specifically but it DOES have issues with account reloading. In Solana, once a runtime account has been loaded in an instruction, they are not automatically reloaded after making a CPI. So, if the CPI changes the data you will be left with accounts with stale data.

The final bug is the dreaded arbitrary CPI in Solana. This is when the address of a program being used for a CPI is not properly validated. I've talked a lot about this here already. This can be used to skip function calls, such as token transfers or be used to abuse permissions. Regardless, they can be very bad.

Overall, an interesting piece of literature. Most posts are very focused on one specific set of technology; I enjoy the back and forth between EVM and Solana. It's good to have this stuff documented!

Ethereum storage is very simple: a 32-byte slot with 32-byte values. Mapping these slots back to meaningful variable names and use cases is difficult to do though. This post is about going from storage back to the usage of the data. EVM itself has no concept of variable names. To begin with, everything just starts from slot 1. Maps and other dynamic types compute the slot number using a hash, which is unrecoverable of course.

To figure out this, we need the execution information of a given transaction. debug_traceTransaction can be used to replay the transaction and return trace data. Notably, with prestateTracer, we can get a summary of the before and afters of slots. Sadly, this is only the final state though.

structLogs is a trace format of every single EVM step. It includes opcodes, stack, memory and everything else. From this, the author extracts the SSTORE for immediate writes and SHA3 operations for preimages of mapping slots. This is much more powerful than the previous tracer but is too bulky. A mixture of these is used to make it faster.

delegateCall allows contract B to write to contract A's storage, as long as the delegate call was originally made from contract A. structLogs doesn't include the address field on each step. So, the stack must be manually tracked to know the code context that is being written to.

The strategy for mapping SHA3 calls to get the preimage of a hash works well. In some cases the compiler will optimize the code>SHA3 away and just use a constant. In this case, they parse the source code to get the value of it.

Their code needed to handle the decoding of all types with care, nested writes and proxy detection for Solidity. Vyper had it's own differences in writing data. The constructor also had some weird quirks in it. They created SlotScan to make this easier to see. Pretty sick stuff!

While reviewing the application, the author of the post found a self-XSS vulnerability. Normally, this doesn't have any impact on other users but they wanted to create it. Thus starts the chain! The application was vulnerable to login/logout CSRF. So, any user could be forcibly logged into or out of their account.

With the login CSRF and XSS, it's possible to execute code within the context of the users account. But, that's not very helpful... so now what? Browsers have a Path attribute. If two cookies share the same name then the one with the most accurate path information is used on the request.

This doesn't entirely do much because we can't set the cookies path directly. So, they created a bot that would login, copy the cookies and store them at a URL. Once the creds were needed, the XSS payload could set the cookie at a direct path. This bypasses the issue around the HTTPOnly cookie but still allows for the attacker and user to be logged in at the same time.

Here's the full chain:

1. Victim visits the attackers page. Gets hit by login CSRF to attackers account. This includes a redirect to the page with self-XSS.
2. XSS triggers on the page. Attacker gets their cookie information and sets at the settings/phone path.
3. Logout CSRF.
4. Victim logs into their normal account, which redirects back to the page with the XSS once again.
5. There are now two active cookies depending on the page. So, this allows for the page to have the XSS from the attackers account to make API requests with the victims cookie to another account.

Overall, a pretty nifty set of tricks! I had never thought of having a bot get credential information for me and manually setting the token data. But, this actually worked pretty well!

Security Assertion Markup Language (SAML) is an authentication standard built on XML. This article dives into some of the issues around SAML and XML parsers that lead to major security issues.

The Service Provider-Initiated SAML flow is the most common way that users authenticate through SAML. When a user tries to access a protected resource, a redirect to the Identity provider is made for verification. The IdP receives the request, verifies its validity and issues a SAML response with a digitally assertion. The response is sent back via the user's browser to the service provider. The service provider then verifies the digital signature and extracts the user information required for authorization checks.

XML Signature Wrapping Attacks (XSW) occur when the signature validation and assertion process are handled by different modules or even different XML parsers. This is a classic difference between the verification and use steps. In a previous blog post on Gitlab, another Portswigger researcher showed how it was possible to bypass authentication using differences between parsers. This is discussed as a way to start looking for other issues in the same Ruby SAML parser.

The new issue is around Canonicalization. In SAML, the XML needs to be put into a canonical state in order to be signed. According to the specification, relative URIs cannot be used. When a parser comes across this limitation it will return an error instead of an empty string. Since most parsers continue on this means that the data being signed over is effectively null! If you had a signature for null, then you'd be able to abuse this issue as a golden ticket.

How do we get the signature? Sometimes, the error message are signed. By causing an error prior to being signed, an empty string may be signed. SAML metadata can be another route for this as well.

Overall, a good post on XML processing for SAML. I personally found the article a little hard to follow with what was novel/new and what was prior knowledge. The void-canonical issue was super interesting!

HttpWebClientProtocol has several variants of it - the main focus in this post is SoapHttpClientProtocol. Since this has HTTP in it, it's completely understandable that it would only support HTTP. In reality, it will handle other file URIs. When calling the creation code for the request, it can return different types. Naturally, the HttpWebRequest type is casted to. If the types don't match, this will fail though.

For whatever reason, the proxy code for Microsoft doesn't do the casting check. So, if you can trick the code to use an arbitrarily URL, the response object will also be different. When using the SOAP proxy, it's possible to "send" SOAP requests to a local file. Why would this ever be needed? Who knows! This behavior can be use to perform arbitrary writes but requires control over the file content. This attack can only be used on SOAP XML content and is application specific.

When they reported this to Microsoft, they decided not to fix it. This feels like a bug in Microsoft libraries based on the naming convention and reasonable assumptions. They blamed users for the issue and said that SoapHttpClientProtocol should never be user controlled. So, the quirk sat around for a while... Since Microsoft said this wasn't their fault, they started looking for ways to exploit this further.

A year later, a colleague of the author decided to look into Barracuda Service Center. While reviewing this code, they found some code that was generating WSDL proxy classes on the fly. While doing this, it's possible to set the soap address to be a file. When the proxy is generated, the application writes SOAP messages to the attacker controlled path. This appeared to be a common pattern in several applications.

Since the WSDL code is mainly controlled by the attacker, the generated SOAP HTTP client proxy has a lot of control as well. So, we don't only control the location of the file write but much of the content as well. XML tag names were the main thing that could be controlled. In some cases, the values could be controlled too. For getting RCE, the location and the value both matter.

Their first major exploit was creating an ASPX webshell. ServiceDescriptionImporter doesn't have a simple method for controlling the attributes in the tags. Luckily enough, complex types can be used to smuggle in XML attributes in various paths. With this, you have enough control over a SOAP body through WSDL to create a functional ASPX webshell.

In cases where none of the input arguments are controllable, there is one other to exploit: namespaces. By defining a namespace in the WSDL as a valid URL, the query string gets smuggled in as special characters. When the SOAP method is executed, the request body will include the namespace information. This can be used to create CSHTML webshells and run malicious Powershell scripts. This feels like a template injection more than anything else into the valid C# proxy code.

Microsoft still rejected the issue, even after finding several applications that were vulnerable. They claim this is still the developers fault. At least some documentation was added for this. This was an absolutely beautiful class of vulnerabilities. I appreciate the concise description about the issue, what is required to exploit this and the impact of it. Great post!

XSS is cool and all but there's more to it. This wiki goes into other frontend security issues like CSRF, prototype pollution, CSS injection and many other things. Just a good reference overall.

The author of this post created a long-tail MEV strategy around the hourly Bean emissions on the Beanstalk protocol. By coordinating with several other MEV's, they were able to collectively earn money instead of running the marginal cost to zero. This is a classic prisoners dilemma problem. After the decrease of the output by 95%, only a single actor remained. The author decided to get in on the action!

One of the functions sunrise() or gm() needs to be called once an hour with up to a 5 minute relay. The reward amount appears to be dependent on how fast the function was called.

The initial strategy is simple: call the same function one second faster than their competitor. If they did this, their competitor would do the same. Eventually, this would hit the minimum award and nobody would be winning. To deal with this game theory issue, they decided to share the rewards. This made sure that A) they maximize the profits coming from the Beans and B) it's distributed equally. The overall gain is better in the cooperation case so this works.

To do this, they created a smart contract called the Pact. Only two people can call the contract. Once the beans are received they are perfectly split and sent to each other evenly. This sounds fine and danty but there are some issues with this... sybil attacks are real. Anyone can undercut at anytime.

How do you contact the person on chain? They tried sending a UTF-8 but that didn't work. They tried splitting the funds manually and that didn't work. Finally, they tried undercutting the bot but this led to the other bot doing more undercutting until it ran to zero. After 3 weeks of doing this, the author of the other bot said they would use the new one instead of their own.

Once they started this up, they ran into a few issues. First, congestion of the gain would lead to higher gas prices. When this happened, the other bot would call the main contract directly and undercut them. Since this wasn't all the time, it was okay. But then another player enter the game. They thought about burning out the competition but decided to let a third person in. The other bot (second one) tried undercutting the third bot but they stayed around. Eventually, the second bot released a contract that contained a 40-40-20 split. The third bot created a new contract that had a perfectly even split.

They thought of ways to fix this problem for themselves. Undercut slightly to gain a profit. Make a new contract with better proportions. Burn out the competition until they become uninterested. They tried undercutting occasionally but it didn't work; stray bots would come and then race to zero. From there, they created a new pact with the second operator and cut the third out entirely. This new contract also included an escape hatch if one of the parties wasn't co-operating.

Overall, a great post into the wild world of MEV and game theory!

AI tools are being integrated deeper and deeper into our workflow. As this happens, this opens up the attack surface to trick the bot into doing malicious things with attacker controlled input. Google docs, Google Calendars, Mail and many other things are now sources of potentially malicious input. Google Gemini Enterprise integrates all of the Google products into Gemini for usage. This is the beginning of the bug.

Google Gemini Enterprise AI contains a Retrieval-Augmented Generation (RAG) architecture that allows organizations to query for mail, calendar, docs and other Google Workspace components. When a user makes a query, Gemini will search the configured data sources for relevant content, match the content, load the content into the agent's context and generate contextual responses from this content. The data sources for the RAG system must be preconfigured by the enterprise admin.

There is a lot of trust within this content. By using a prompt injection within one of the returned data sources, an attacker can add malicious instructions within the content. This can be a meeting link, shared google doc and many other things. What can this do? By including a adding a image to a remote server and asking the AI to put this as part of the URL, RAG-based information can be stolen. This leads to data exfiltration.

I find that "zero-click" is the wrong word. It still requires user interaction to exploit but they don't need to click on a specific attack controlled link. To me, zero click means that a user has to do nothing. Maybe 0.5 clicks is better. Still, this is really impactful and interesting! There's an assumption that prompt injection is always possible. So, content isolation and more permissions seems like the future of security here.

Gemini's Markdown renderer fails to sanitize HTML-like content within code blocks when there are premature code fence terminations (```).

An example payload:

```
  test
```
```
````
<tag>...</tag>

The payload exploited a parsing inconsistency. The Markdown processor would close the code block early, which allowed for the HTML to be rendered without a direct escape. Initially, this only allowed for a few specific tags. However, after an update, it allowed for direct HTML injection.

To exploit this, they setup UI spoofing to get sensitive information, like creds. In Firefox, it prioritizes referrerpolicy attribute over server-set Referrer-Policy headers. This meant that Firefox could leak the full URL, including autofilled creds in query strings, via the referrer header. Pretty neat!

The vulnerability doesn't allow for the injecting of JavaScript directly. Still, it's able to perform various attacks. To exploit this, I think Gemini would have to return malicious content. Although this is claimed and probably is "zero click", I don't think you can trigger this on arbitrary users.

Samsung Android contains an internal DNG format decoding library. Notably for attack surface, many applications use the MEDIA_SCANNER_SCAN_FILE from remote contexts to index media files that are downloaded.

DNGs TrimBounds opcode does an in-place modification to the image's bounds. This causes the backingstore to be reallocated and updated.

Later, when performing linearization, this modification ins not taken into account. During usage, srcImage is now smaller than dstImage. This leads to an out of bounds read during linearization.

My hypothesis for the bug: non-obvious side effects. If functions are making modifications to objects, they may violate assumptions somewhere else without realizing it. I suppose that functions with side effects are useful to track for bugs in other code bases.