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!

Amazon SageMaker is a fully managed machine learning service hosted on AWS. With SageMaker, data scientists and developers can quickly and easily build and train machine learning models, and then directly deploy them into a production-ready hosted environment.

While looking at the source code of the website via view-source:, they noticed an interesting file path being used for the environment. This directory called home/ec2-user/anaconda3/envs/JupyterSystemEnv/share/jupyter/lab/static had several HTML, JavaScript and CSS files inside of it. By modifying the HTML page, the author trivially achieved XSS! But here is the thing: this was a self-XSS. What can we really do with that?

Since all domains are of the form <my_instance><region>.sagemaker.aws, self XSS could potentially be escalated away from the hosted instance. They noticed that all of the cookies were scoped to ONLY .sagemaker.aws! In particular, the anti-csrf token was on this domain.

The author thought to use an attack that I had never considered before: cookie tossing. This is when an attacker can set a cookie on the domain that is used for critical actions. In the case of our XSS, we can do exactly that on our domain.

Sagemaker used the double submit CSRF protection. This works by sending the CSRF token in a cookie and the other one as a header or a field in the request. Since the attacker cannot normally see the CSRF token cookie, this works quite well. However, in this case, the cookie tossing issue allows us to specify the cookie CSRF token! This means that the double submit method has been compromised since we can control both values being sent.

There are a couple of other things to consider with CSRF though: origin validation, non-safe request issues and the Same-Site cookie flag. The origin validation was non-existent, so this part was fine. In the land of browsers, CORS becomes a major problem for CSRF attacks because of pre-flight OPTIONS request is made. As a result, only certain types of request, known as simple can be used. This disallows us from setting custom headers, using JSON and any non GET/POST request.

The application puts the CSRF token into a header. However, the author figured out that this could be included as a GET parameter and the request would still work! One more problem though: the request being made was a JSON request. The trick was to send the data as the Content-Type to plain/text in order to get the JSON to be sent but still interpreted as JSON! That's a new trick for me.

The final CSRF mitigation problem is the SameSite cookie flag. There are three settings for this: none, lax and strict. The default in Chrome and Firefox is lax, but the default in Safari is none. When the setting is lax, some cross-domain requests are allowed, such as GET requests to the top level domains. strict will never send cookies from cross-domain requests.

In Chrome, if the SameSite attribute is never set (defaults to lax), then there is a 2 minute grace period where all requests will contain the cookies. So, the author figured out a GET request (which does not get affected by SameSite with the lax setting) to reset the Authtoken of the user! Since the cookie was now set less than 2 minutes ago, the auth cookie will be used. Damn, that is a real fancy workaround!

With the CSRF protections defeated, an extension can be added to a notework to execute code in there. Now, the access tokens for the role can be stolen, leading to much more damage being caused.

I learned a few new tricks with this. First, cookie tossing makes sense and is a large weakness with the double submit CSRF protection. Second, the plain/text simple request and setting the csrf value as a parameter. Finally, the trick for resetting the auth token was really awesome to abuse the Chrome grace period on the SameSite cookie header. Overall, a crazy article about how a self-XSS lead to a compromise.