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!

Many website uses Static Site Generators alongside an Image CDN to optimize the images on the website being loaded, such as NextJs, which this website uses. The image CDN behind the scenes has a URL parameter for the image. The allowed URLs are typically inside an allowlist with some Content-Type validation as well.

On Netlify, the endpoint is /.netlify/images?url=. The author placed the main paeg into this endpoint, with the requested content-type being text/html, and got a response of HTML! So, if we could find an arbitrary file upload on the site, we could achieve XSS through this endpoint.

For the website, all of the images are uploaded on the same CDN website. Using this, it's trivial to upload a file with arbitrary content but it must have a valid content-type. When going to the CDN, it pops an alert box. However, when trying the same through the image endpoint it doesn't work because of the CSP.

How does this CSP work? It turns out that it's a dynamic nginx configuration! If the location was on the /.netlify/images?url= path, then it returned script-src: 'none'. If we could trick nginx to see a different URL but have it parse the images endpoint then we would have a CSP bypass.

The author tried /./.netlify/images?url=... which nginx will parse differently than the underlying application. Neat! The CSP now contains a script-src that allows our script. In order to have this work in the browser, the page above needs to be URL encoded with /.netlify%2fimages though. This gives us XSS!

Netlify fixed the issue but the author found another bypass with an additional leading slash. For whatever reason, this has not been patched yet though. They fixed this by changing the types of files allowed on the CDN but left the parsing issue the same as before.

Overall, a super interesting bug report! A mix of new technology with old bugs is fun to see.

Private Network Access (PNA) is a new browser security feature to prevent direct access to local networks. Segmenting the local network is important for preventing CSRF-like attacks to compromise a users network.

The mechanism for fixing this is Access-Control-Allow-Private-Network header. If this header is not included for a particular website, then it will reject the local network request.

In Flask, the default for this header was true. This effectively removed the protections of the new PNA specification. So, it just sets the default to false now.

pyspider is a web crawling framework. It has a standalone and locally hosted website. pyspider has a flag for using authentication and not using authentication. With authentication turned on, it uses Basic Auth - the username and password prompt from the browser.

When submitting a cross-domain request with cookies, the cookies are automatically attached to the request. At least, before the creation of the SameSite cookie flag. Additionally, there is a pre-flight request in many cases that would prevent CSRF. This works well for functionality but is scary for cross-site request forgery (CSRF) attacks, otherwise known as the session riding attack.

Browsers do not have any CSRF mitigations for Basic HTTP authentication. So, once you log in, all requests made will now include the credentials. If a malicious actor makes the call then it's a major issue for making calls. I'm unsure if the pre-flight request has any bearing here but I'd guess it does.

According to the author, it's trivial to pop a shell. The website has a request to execute arbitrary code. So, using a CSRF alongside this is leads to RCE. Sadly, the project is not longer maintained. Finding the security issue led to the project being archived. Regardless, this was completely new information to me on the Basic HTTP Authentication.

WhatsUp Gold gives a user visbility into applications, network devices and servers. To do this, it requires a lot of credentials, making it a good target for attackers.

While tracing out some inputs, Sina noticed that user controlled input was being placed into a SQL query. Classic SQL injection vulnerability! Now what? Credential leakage? Command injection? From understanding the configuration of the DB, they noticed that command execution wasn't possible because of a secure database configuration. Additionally, the credentials for the admin-user were encrypted.

Reverse engineering the application found that the encryption was fairly faulty. It was a combination of funny hardcoded keys or keys stored in another table. This made decryption inconsistent and unreliable, which was frustrating.

The idea was to find a primitive from the application to either decrypt the password or encrypt a user controlled password to overwrite the existing one. While browsing around, they found some code that was using the same key and encrypting arbitrary user data. This gave us an encryption oracle.

So, here's the full exploit chain:

1. Use the encryption oracle to encrypt data for us that we will use as a password later.
2. Use the SQL injection to retrieve the encrypted value. We don't know how its encrypted but we know the encrypted value!
3. Use the SQL injection again to overwrite the admin password with the encrypted value.
4. Login!

Overall, a solid post! I enjoyed the reverse engineering breakdown and the creativity to turn this into an authentication bypass.

Thorchain is a cross chain bridging platform with DeFi elements. In the Thorchain router on EVM, there is a call made to an arbitrary contract with a low level call. If this fails, then an ETH transfer is attempted to be made to the target. If this fails, then the msg.sender is simply refunded. Naturally, the refund amount is just msg.value.

There are two functions that can trigger this functionality: transferOutAndCallV5 and batchTransferOutAndCallV5. When calling this function in a loop, it will reuse msg.value multiple times and refund this to the user. This allows all ETH from the contract to be stolen.

The vulnerability was only rated as medium by the judges instead of high like the author proposed. My guess is that the router shouldn't normally have ETH, making it a way to steal value when people send it their by accident. Besides the stealing of funds, it leads to a self-DoS is more than one revert occurs and there is no funds in the contract.

Using msg.value in loops is bad practice because of this. Instead, the amount of funds being sent should be kept in a separate variable and should not be more than the value passed in originally. Regardless, a great find and a solid write up!

Cross chain bridging platforms require on-chain and off-chain components. For Ethereum, the common practice is emitting an event in the EVM, which will be processed off-chain. After the processing of the event is done, it can be sent to the destination chain. Of course, the event emission must be 100% correct for this to work.

In Thorchain, if a transaction fails a refund is triggered. This is done by handling the failed contract call then emitting an event to acknowledge that the transfer happened. When the failure happens, it gets placed into a vault contract.

The bug is that the TransferOut event is emitted for a successful transfer. When in reality, the rollback to the user should have occurred. This leads to funds being lost for the user. To fix the bug, the event should only be emitted when the transfer to the target is successful.

Cross chain stuff is hard! Solidity error handling is also hard. Put this together and we have a lot of bugs I'm sure.

Roundcube is an open source webmail software that enables users to check emails in their browser. Many government agencies use it, making it a good target for exploitation. Naturally, the biggest threat is XSS on an email.

Roundcube contains its own email sanitization called washtml, which they couldn't find any vulnerabilities in. Once the sanitization is done though, some modifications were being made. When rendering emails, it doesn't put the content into an iFrame - it just creates a raw HTML page. When rendering, it needs to remove all of the body, head and other tags in it though. This is where the first issue is at.

The replacement of tags and values is done using a simple regex. When processing the bgcolor regex, its performing attribute parsing and substitution. The regex /\s?bgcolor=["\']*[a-z0-9#]+["\']*/i handles for all possible delimiters. However, it does not consider the case that bgcolor=XXX could be placed inside of another attribute.

The author provides an example of a body field with <body title="bgcolor=foo" name="bar onload=alert(origin)">. The bgcolor and closing double quote are matched and removed. This leads to the new tags looking like <body title="name=" bar onload=alert(origin)">. What's interesting about the regex is that it should only work if it finds the same element (",') to open and close. However, it will happily parse the value with no quotes and close on a quote. Man, regexes are terrible!

Clicking on the open button for an attachment simply adds the _download=1 query parameter. The Content-Disposition header will set this as an attachment or inline it. The filename, MIME type and charset are all sent with the data. The MIME type being used has no checks and comes only from the filetype. While html and svgs are sanitized, nothing else is. The author of the post found that XML files could bypass check and still render HTML.

This last bug was a known issue but theoretically fixed by disabling the Open button for xml files. If it was possible to get a link to the file directly, the XSS would be possible but IMAP uses a random ID. Since Roundcube is missing good protections like CSP and sandboxing, the author looked to find a way to leak this link.

The main defense against CSS leaks is via a regex-based blocklist filter on the CSS text. It tries to ban usages of url() and @import for remote connections. For @import rules, the word is blocked except when followed by an a to allow for the important keyword. Notably, a stripped down version of CSS is being verified and not the full CSS page.