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!

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.