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!

The Content Security Policy (CSP) is a mechanism for restrictions various components of a web page to prevent attacks. Github had revamped their CSP in 2016 and this is their article explaining how they did it.

First, they restricted the script-src to only allow content from their CDN. They removed the self from the list (which I thought would be fine on the page tbh) which removed some weird edge cases. In particular, mime sniffing issues from the browser and weird JSONP endpoints.

The next thing they restricted was object-src (used for emebeds) to not include self either. They removed this because of a person who found a CSP bypass from it. The hacker had found a content injection bug that allowed them to control the class attribute with some automatic behavior from JavaScript to fetch the href associated with the element. By doing this with a content sniffing issue they were able to get Flash code to execute within the embed alongside a Chrome browser bug.

They restricted the img-src to be much lower as well. Why is this important? Dangling Markup issues can allow for parts of a page to be sent in a URL if the source of an image isn't seriously considered. On a newer post they did, Cure53 found a way to abuse the dangling markup on Google Analytics and another website to exfiltrate information.

connect-src restrictions what domains can actually be connected to for fetch, websockets and other things. This limits various attacks by inherently not allowing interactions with the outside world.

form-action can be used to restrict where formed can be submitted to. Using password manager autofill or attacks similar to the dangling markup, this can be very useful. They have a few more restrictions on iframes as well, which is always a good thing.

Overall, an interesting dissection of the security of CSPs and how Github made theirs much more robust. Even though the article is quite old, it's still a great resource.

Content Security Policies (CSP) are a secondary line of defense for XSS bugs in the browser. So, as an attacker, having ways to circumvent the CSP is important for a full exploit chain.

The case for form hijacking is when you have an HTML injection vulnerability but can't escalate it to XSS because of the CSP. By adding a form to the page it may be possible to extract sensitive data, especially from over-eager password managers.

In the case of Mastadon, this worked to steal passwords with Chrome and a single user click. In this Gareth made the inputs have an opacity of zero to make it invisible.

The form-action was created as a directive in CSPv2. However, default-src doesn't cover form actions for some reasons. Overall, an interesting CSP bypass that will probably exist for a while.

GPUs are parallel and fast co-processors. They are designed to handle high throughout graphics and machine learning workloads. GPUs are made up of compute units for various computations, all of which have global memory. These have both compute and memory components.

Some of the GPUs have section of memory called local memory for a given compute unit. This is a cache for processing elements within a given compute unit where global memory is too slow.

The execution model is different than most programs called kernels. A GPU program is written in a Shader language like OpenCL, Metal or Vulkan with a single entrypoint function to be executed by various invocations.

The vulnerability is that the local memory of programs being executed by different users on a compute unit are not properly cleared. As a result, it's possible to steal information across the different program runs!

For instance, if there's a GPU job being executed by one process then a malicious process could execute a job directly after this one to steal information from local memory of the original one.

The rest of the post is doing this on specific platforms and actually extracting the information from various platforms. The main interesting thing is that all applications on various platforms (like Android) have access to GPUs, making any application an potential attacker to exploit this. Although this is interesting, I don't think it's worth putting into this post but may be worth coming back to.

The disclosure process was done through all GPU providers such as Apple, AMD, ARM and many others. Many of these were fixed, which is awesome. Overall, a good post for a relatively simple bug. I personally felt that it was theatricized too much with the name, impact, images, etc. I just love when bugs are talked about and explained :)

Sonar Source people go crazy on web security issues! Definitely one of the best blogs to read through for cutting edge security research. In this case, they have a wild XSS in the Joomla CMS.

The CMS was removing all HTML tags besides ones that were not explicitly allowed. To do this, the function cleanTags removes all of the illegal content about the tag (attributes and things) but leaves the value within the tag alone.

This code is very security sensitive. So, while reviewing the implementation in detail, they noticed that mb_strpos and mb_substr handle invalid UTF-8 sequences differently. Formb_strpos, if it encounters an invalid sequence it jumps back to the second byte being processed. The other function skips over the continuation bytes when this happens.

The inconsistency creates a major problem - it may be possible to smuggle in angle brackets and other useful characters by abusing this. Since one function uses a different index than another, it processes different information. By inserting multiple invalid UTF-8 sequences to break the offsetting math in the various functions.

By inserting multiple invalid UTF-8 sequences to break the offsetting math in the various functions. For instance, \xF0\x9FAAA<BB will see the invalid sequence and add the <BB as a valid part of the processing even though much of it was thrown out.

PHP actually fixed the underlying issue to this problem but didn't backport it because they didn't consider it a security issue. Overall, a fascinating issue of exploiting the intricacies of multibyte characters. Super post with awesome diagrams explaining the vulnerability.

Multi-signature wallets are a mechanism to defend against a single key compromise leading to the stealing of all funds. Additionally, it's common for timelocks to exist to allow for auditing of changes.

However, this creates an issue: what if there's an emergency? We need to be able to act first to make changes sometimes. So, there's a balance to be had here.

Chainlink CCTP has a one day timelock. However, for an instant action, 6 out of 6 signatures can be used. For 24 hours, 4 signatures can be used. Finally, 2 sigs are a complete veto.

Overall, it's interesting. This feels like a good balance of decentralization as well as the ability to act fast in an emergency.

Being able to debug live code deployed on mainnet is a real pain in the butt. So, this is a strategy to do that.

First, fork the chain you want to work with using Foundry. This gives us control over a network to do what we want.

Next, download the flattened source code from Etherscan. Now, we can make changes, such as print statements to the code to help out. We need to be careful not to modify the state or storage slots of anything.

Finally, call vm.etch with our new code. This will overwrite the code at our target contract with our debug version but with the state of the mainnet one! Just a small tip to debug live contracts deployed on mainnet better.

Carriage Return - Line Feed (CRLF) or response splitting is a vulnerability where a newline can be added to an HTTP response in order to modify it. For instance, it can be used to change incoming headers, force save a response and much more. It's always felt like a mystery to me and how it works. So, I just read through some reports.

The one linked is fairly simple: add in a %0d%0aKey:Value. The %0d%0a allows the adding of an arbitrary header. This report also has more linked reports that are interesting that are related to Twitter.

This one is interesting because the CRLF injection did not work with CRLF. Instead, they had to do some funky unicode encoding with %E5%98%8A. If I had to guess, this was a server-level protection and had nothing to do with the software that Twitter built.

Another pattern I noticed was this occurring with redirects. With these, a redirect from http to https sets the path of the URL to be the content of the path. Since this wasn't escaping the newlines, this led to a serious CRLF injection within the redirect.

I tend to blame the server implementation for this. Anything being added into an HTTP response that contains a newline should simply be escaped - there's no reason this shouldn't be the standard. According DayZeroSec, this is also a common Nginx misconfiguration with some variables being used in locations that are unintended.

Super weird bug class but CRAZY impact when discovered. Redirects and different encodings seem to do the trick in many cases.

Seneca did virtually everything wrong and then got hacked. So, sort of a funny setup.

Seneca was supposed to do an audit with Sherlock but was suddenly closed for code licensing issues. They decided to launch with only an audit from Halborn (which reported a similar bug but not the terrible one that was used).

In the Post Mortem, Seneca details the vulnerability. The function PerformOperations contained a mechanism for making an arbitrary call to an arbitrary contract from the context of their contract at here. There is a denylist here but probably not a great one.

With an arbitrary call from the context of the Seneca smart contract, there are many paths to go. However, the easiest one is abusing allowances from other users. By making calls to tokens that had approvals from other users, a malicious actor can trick the contract to send them funds.

To me, this is a pretty clear sink within the smart contract. Arbitrary calls are catastrophic like this. This would have been quickly found by lots of people on Sherlock; it's weird that this wasn't found by Halborn tbh.

Overall, the takeaway is take security seriously! If you don't you'll get hit hard. As security folks, it's okay to call things out as insecure in order to protect users.

Woo is some sort of finance platform that is on various blockchains. Recently, they had deployed everything on Arbitrum.

WOOFi has a system that adjusts the oracle prices based on trade value. By using oracle manipulation within a low-liquidity environment, it was possible drop the price of the asset to steal funds.

The attacker borrowed 7.7M WOO then sold the WOO into WOOFi. Now, the algorithm for the price incorrectly created an extreme price close to zero. From there, an attacker swapped out 10M WOO for almost nothing in USDC. They did this 3 times in order to make a large profit of about 8.75M.

Instead of using a standard Automated Market Maker (AMM), they used their special sPMM (synthetic proactive market maker). Within their protocol, the error resulted in this going outside of the range to $0.00000009. In theory, a fallback should execute Chainlink but the threshold wasn't reached, resulting in this major issue.

A few things stood out to me and rekt.news. First, going to different chains doesn't come without any risk. Having low liquidity can be an issue for these types of attacks. Second, things that are not battle tested and well audited shouldn't have millisions in them.

Facebook has an extra security mechanism after logging in to ensure the user is valid. This could be a captcha, MFA but is commonly referred to as a chcekpoint. This is implemented within an iframe that is a sandboxed URL.

When implementing this, the outside domain URL is shared with the sandbox URL. Since this could be within some OAuth flow, the code for OAuth could be leaked inside of this iframe. So, if we could communicate with this iframe we could potentially steal oauth codes to takeover accounts.

By chance, the author already had an XSS with the domain www.fbsbx.com. Since the domain is a sandbox, it's actual by design though. On a particular page, it's possible to upload HTML files on this domain.

To steal the URL passed to the iframe we need to have a relation to the two windows. First, we need access to the Facebook checkpoint page. Next, we need a window with the XSS on the Facebook sandbox referenced as well.

To do this, we can open the first window in a new tab from our malicious website. For the second one, we can create an iframe on this page with the sandbox within it.

The iframe for the sandbox and the window with the login code with the page have the same origin. Hence, they are able to read the some of the same information! In particular, the location.href can be stolen to get the code.

The one other complication to this is that we need to force the account into this checkpoint state. So, we can use a login CSRF and a logout CSRF to do the trick. However, if we do this to Facebook directly then we won't get anything out of it. So, the trick is to do this to a OAuth provider, like Gmail.

To perform the attack, do the following steps:

1. Logout CSRF
2. Login CSRF
3. Open up the Gmail OAuth provider with a redirect to Facebook with window.open(). This will redirect to Facebook's checkpoint page with a code in the iframe.
4. Wait a few seconds for all of the interactions to happen.
5. Access the frames information using the XSS to get the Google OAuth code.
6. Start the password recovery process on Facebook.com and connect via Gmail.
7. Use the code and state in order to login to Google.

The deep understanding of client side security of this hacker always amazes me. On top of this, just having an XSS in the pocket was awesome. I wonder if there's a good place to find all of the client side security things? If you see one, please let me know!