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!

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.

This article goes through the math required for being in Web3. This includes Linear Algebra, Abstract Algebra and number theory. Additionally, there are many points around real protocols that are using this math to explain why it's useful. Finally there are some other use cases, like Formal Verification that are thrown in there as well. This seems like a good reference for looking at things in the future.

Google Chrome is a browser that runs everywhere. Chromium is the open source browser engine underneath of Chrome that underlies Chrome, Edge, Brave and many more browsers. The post is about a memory safety issue that they found in the Chromium engine. The blog post really pushes towards autonomous security reviews because of the amount of new code that is being pushed. I understand the sentiment but not a huge fan of how it's pushed in the article.

WebXR is an API for virtual and augmented reality experiences in the browser. It's a great target to hit for memory safety issues because of the complexity. It's an evolving API that's under active development and is interfacing with complex 3D graphics plus new hardware components. Applications can manipulate positions, rotations and transformations using interfaces that represent data in a 3D space.

The vulnerable code path is around WebXR's matrix caching and JavaScript's ArrayBuffer semantics. A page can detach a typed array by transferring its underlying buffer to another context. This is a legitimate API and is used for zero-copy data transfers.

When handling the case of a cached array being detached, the Chromium engine had a bad fallback. It returns a freshly created zero-length array. So, what's the problem? During this code path, there's only a length check on the size in DEBUG builds. So, when ColMajorF accessing 16 array indexes, it reads 64 bytes past the end of the buffer that was just initialized. This creates an out of bounds read in the Chromium Engine.

To fix the vulnerability, the matrix is recalculated from the authoritative internal state instead of the cached array. This is in accordance to the WebXR specification. The Aisle tool additionally found two other locations where this was happening but the exploitability isn't mentioned in the article.