$25k GitHub account takeover & justCTF 2023 CSRF+XSS writeup

Summary

This video explores the nuances of web application security vulnerabilities, highlighting how developers' assumptions can lead to security flaws. The presenter demonstrates two examples, one involving a GitHub account takeover that earned a $25,000 reward, and another showcasing a CTF challenge. The video delves into the intricacies of CSRF protection, the misuse of the HEAD method in frameworks, and the critical distinction between tokenizing and parsing in sanitization processes, which can inadvertently introduce XSS vulnerabilities. The speaker also invites viewers to participate in an upcoming CTF event to sharpen their hacking skills, emphasizing the importance of understanding these concepts in web security.

Takeaways

• 🔒 Every security vulnerability often stems from a developer's incorrect assumption or an unexpected behavior from frameworks.
• 🎯 The speaker created a CTF challenge inspired by a $25,000 GitHub account takeover incident.
• 🛤️ In web applications, routes are typically defined by specifying the path, methods, and the function to handle requests, with CSRF protection often applied to state-changing requests.
• 🔄 The HEAD method in HTTP can sometimes bypass CSRF protection if frameworks treat it similarly to GET, despite differences in request handling.
• 🤹‍♂️ The speaker invites participants to a CTF event organized by their team, justCatTheFish, emphasizing the opportunity to develop hacking skills.
• 📅 The online teaser for the CTF event is scheduled from June 15th for 24 hours, with a link provided in the description for registration.
• 🙏 Sponsors such as Trail of Bits, OtterSec, HexRays, and SECFORCE are acknowledged for their support, with links to them in the description.
• 🕵️‍♂️ The script discusses the nuances of sanitization in web applications, highlighting the difference between tokenizing and parsing HTML inputs.
• 🧩 The mistake in the script's example was not in the sanitization logic but in how the input was tokenized, leading to a potential XSS vulnerability.
• 🌐 The importance of understanding HTML namespaces is underscored, as tags behave differently across namespaces, affecting the effectiveness of security measures.
• 🎖️ The final payload in the script's example exploits an XSS vulnerability, which could be used to exfiltrate sensitive information like flags in a CTF challenge.
• 📚 The speaker encourages viewers to check out another video for a write-up on a SQL injection task, providing a link on the screen.

Q & A

What is the primary cause of security vulnerabilities in web applications according to the video?

The primary cause of security vulnerabilities in web applications is developers making wrong assumptions, either through their own mistakes or due to the unexpected behavior of frameworks.

What is the purpose of the CTF challenge mentioned in the video?

The purpose of the CTF challenge is to demonstrate two examples of security vulnerabilities inspired by a $25,000 reward account takeover on GitHub, and to encourage participants to develop their hacking skills.

How does the CSRF protection work in the context of the video?

CSRF protection works by automatically requiring a CSRF token for all POST, PUT, DELETE, and other requests that are intended to change something on the server. It is not required for GET requests, which are only supposed to serve the response.

Why is the HEAD method significant in the context of the video?

The HEAD method is significant because many frameworks treat it the same as GET during the routing stage, but it can bypass CSRF protection if the if statement in the function checks specifically for GET, allowing access to the block of code that should be protected.

What is the difference between tokenizing and parsing in the context of the video?

Tokenizing is the process of breaking down code into tokens without applying namespace rules, while parsing applies these rules, which can lead to different outcomes especially when dealing with namespaces like SVG that can alter the behavior of tags.

How does the video explain the exploitation of the XSS vulnerability?

The video explains that the exploitation of the XSS vulnerability occurs when the sanitizer's tokenization process fails to recognize an XSS payload within an SVG namespace, allowing the script to execute in the browser.

What is the role of the 'textarea' tag in the context of the XSS vulnerability discussed in the video?

In the HTML namespace, the 'textarea' tag can only contain text, making it resistant to XSS payloads. However, when wrapped in an SVG tag, changing the namespace, it becomes vulnerable to XSS attacks.

What is the significance of the 'script' tag in the XSS vulnerability discussed?

The 'script' tag is significant because it is used to execute JavaScript code. In the video, it is shown that when the 'script' tag is within an SVG namespace, it can bypass sanitization and lead to an XSS attack.

What is the role of the CTF challenge organizer 'justCatTheFish' in the video?

The role of 'justCatTheFish' is to organize the CTF challenge, provide a platform for participants to develop their hacking skills, and to offer a new task for the current year's competition.

How can participants join the CTF challenge mentioned in the video?

Participants can join the CTF challenge by following the link provided in the video description, which leads to the event's registration or information page.

What is the significance of the sponsors mentioned in the video?

The sponsors, Trail of Bits, OtterSec, HexRays, and SECFORCE, are significant because they support the CTF challenge, making it possible for the event to occur and providing resources for the participants.

Outlines

00:00

🛠 Security Vulnerabilities and Developer Assumptions

The video script begins by discussing the common root of security vulnerabilities: developers' incorrect assumptions. It distinguishes between simple developer mistakes and complex framework behaviors that are difficult to predict. The speaker introduces a CTF challenge inspired by a $25,000 GitHub account takeover, which involves web application routing and handling different HTTP methods within the same function. The script highlights the importance of CSRF protection, which is automatically applied to state-changing requests, and the peculiarities of handling GET requests differently due to the absence of a body. The speaker invites viewers to participate in an upcoming CTF event organized by 'justCatTheFish' and thanks the sponsors for their support.

05:02

🤔 The Confusion Between Tokenization and Parsing in HTML

The second paragraph delves into the nuances of HTML processing, specifically the difference between tokenization and parsing. It clarifies that while both processes yield the same result for simple HTML, they diverge when HTML namespaces are involved, such as with SVG or MathML. The script uses the example of the 'textarea' tag, which behaves differently across namespaces, to illustrate how a seemingly harmless string of text can become an XSS vulnerability when wrapped in an SVG tag. The video aims to educate viewers on the importance of understanding these differences to prevent security flaws and encourages participation in the CTF to challenge and improve their skills. It also provides a link to a related video for further exploration of CTF tasks.

Keywords

💡Security vulnerability

A security vulnerability is a flaw or weakness in a system that can be exploited to compromise the system's integrity, confidentiality, or availability. In the video, it is mentioned that security vulnerabilities often stem from developers making incorrect assumptions. Understanding these vulnerabilities is crucial for preventing attacks such as the one discussed in the CTF challenge.

💡CSRF protection

CSRF (Cross-Site Request Forgery) protection is a security measure used to prevent unauthorized commands from being transmitted from a user that the web application trusts. In the video, it is explained that middleware is used to enforce CSRF protection for requests that change the server's state, such as POST, PUT, and DELETE requests, but not for GET requests.

💡CTF challenge

CTF (Capture The Flag) challenge is a type of competition in which participants solve security-related tasks to capture 'flags.' In the video, the speaker discusses a CTF challenge inspired by a $25,000 account takeover on GitHub, highlighting the importance of such challenges in developing hacking skills.

💡Routing

Routing is the process of determining how an application responds to a client request to a particular endpoint. The video explains how routes are defined in web applications, specifying the path, methods, and functions that handle the requests, and the implications of different HTTP methods on security.

💡HTTP methods

HTTP methods are standardized request types used in web applications, such as GET, POST, PUT, DELETE, and HEAD. The video discusses how the HEAD method, which is often treated like GET by frameworks, can bypass CSRF protection due to differences in handling within the application logic.

💡Middleware

Middleware is software that connects different components or applications, often used to manage communications and data exchange. In the video, middleware is used to automatically enforce CSRF protection, illustrating its role in enhancing application security.

💡XSS (Cross-Site Scripting)

XSS is a type of security vulnerability where an attacker injects malicious scripts into content from otherwise trusted websites. The video describes an XSS exploit used in a CTF task, where the attacker manipulates HTML namespaces to bypass sanitization and execute scripts in the browser.

💡HTML namespaces

HTML namespaces are used to distinguish between different types of content, such as HTML, MathML, and SVG. The video highlights how the same tag can behave differently in different namespaces, a crucial point in understanding how XSS attacks can exploit these differences.

💡Tokenizer vs. Parser

A tokenizer breaks down text into smaller parts called tokens, while a parser analyzes the tokens to understand their structure. The video explains how a tokenizer ignoring namespaces can lead to security vulnerabilities, such as allowing XSS attacks by not recognizing the context of tags.

💡Account takeover

Account takeover is a form of identity theft where an attacker gains unauthorized access to a user's account. In the video, an account takeover vulnerability in GitHub is used as an example to illustrate the potential impact of security flaws and the importance of protecting web applications.

Highlights

Every security vulnerability comes from a developer making a wrong assumption.

Frameworks sometimes do things so strange that it's hard to blame anyone for not understanding what happened.

The video shows two examples of security vulnerabilities and a CTF challenge inspired by a $25,000 account takeover on GitHub.

When creating a new route in a web application, you specify the path, methods, and the function that serves the request.

Different methods can be handled within the same function using an if statement.

CSRF protection requires a CSRF token for all POST, PUT, DELETE, and other requests that change something on the server.

CSRF protection is not required for GET requests that only serve a response.

Using the HEAD method can bypass CSRF protection and reach a block without a proper CSRF token.

A lot of frameworks treat the HEAD method the same as GET during routing, but they are separate at the controller level.

Exploiting this behavior can allow account takeover in GitHub by changing the description through an XSS vulnerability.

Sanitization code can fail when it does not properly handle HTML namespaces.

The same tag can behave differently in HTML and SVG namespaces.

A tokenizer does not apply namespace rules, making it possible to bypass sanitization.

Wrapping HTML in an SVG tag can make a payload look innocent to the sanitizer but execute in the browser.

Participating in CTF challenges is a great way to develop hacking skills.

Transcripts

In a sense, every single security vulnerability

comes from a developer making some wrong assumption.

Just the difference is one time,

it's just a mistake by the developer

to make this assumption.

And another time, frameworks do something so strange

that it's hard to even blame anyone

for not understanding what happened.

In this video, I will show you two examples like this

based on which I created a CTF challenge,

which was actually inspired by a reward $25,000

account takeover on GitHub.

Enjoy.

When you create a new route in a web application,

you usually, regardless of the framework

or the programming language, do something like this.

You specify the path, you specify the methods,

and you specify the function

that wants to serve this particular request.

Sometimes you may want to create different functions

to handle different methods,

but you can also handle different methods

within the same function,

just you have an if statement inside

to serve something else for the get

to just serve a static response

and to actually process some parameters

and make some changes if the request is post,

put, delete, or whatever.

Also, the implicit difference that you cannot see here

is the CSRF protection.

Both GitHub and my CTF task used middleware

to protect against CSRFs,

and the way it works is it automatically requires

the CSRF token for all post, put, delete,

and other requests that are supposed to change

something on the server,

and the CSRF protection is not required

for requests like get

that are only supposed to serve the response.

Because of this, even with SameSite=None cookies,

you couldn't reach this block without a proper CSRF token.

If you could, in GitHub,

it would allow you to take over the account,

and in my CTF task, you would have to also exploit

the XSS, to which I'll get later in this video.

Just the question is how to do it,

and I'll get to answer it in a second,

but before I do, I'd like to invite you

to take part in this year's CTF organized by my team,

justCatTheFish.

The task I'm showing you is my task from last year.

Of course, for this year, I have a new one,

and I promise you, it is a fun one,

so you should definitely try.

And apart from this, my teammates have also prepared

amazing, amazing tasks,

so you should definitely challenge yourself,

because it's an amazing way to develop your hacking skills.

The online teaser starts on 15th June and lasts 24 hours.

The link is in the description.

I'd also like to thank our sponsors,

Trail of Bits, OtterSec, HexRays, and SECFORCE

for making it possible.

We have links to sponsors in the description,

and remember, by checking them out,

you support both me and my team.

With this said, let's go back to our task.

The trick is to use the head method,

and you may ask, what head method?

We can see in the controller,

it's only supposed to route get and post,

so how on earth do you get a head method here?

But the thing is, a lot of frameworks on the routing stage

treat head the same way as they treat get,

because the logic is head will be the same thing as get,

just the body of the response will be stripped

before sending it to the client.

So the head method will also be routed to the same function,

but at this stage, with this if statement,

it is no longer true.

At this stage, head and get are separate methods,

so if you have an if statement

that checks if the method is get,

it will also be false for the head method,

which means the head method will not be,

will not require the CSRF protection,

yet you can get to this block down there.

And yes, we do not have the request body,

but the way parameters are processed,

it is equivalent to have the request body with a post

and to have URL parameters of a head.

And this way, you could take over account in GitHub,

and in my task, you could change the description

where you had to exploit an XSS.

And let's now take a look at it,

because there is some robust, almost robust sanitization.

And this is the code that was used

to sanitize the description, and it is quite aggressive.

It only allows a few basic tags with no attributes.

And to my knowledge, you cannot execute JavaScript code

if you cannot use either a script tag or some attributes.

But this is not where the mistake was made.

The mistake was made a few lines above this,

here, when the code was not parsed, but tokenized.

And if you are confused as to what on earth

is the difference between tokenizing and parsing,

I don't blame you.

I also don't blame developers

that do not know this difference,

because most Stack Overflow answers are confused as well.

Well, the difference between tokenizer and a parser

with a simple HTML will be none.

If you have a simple code like this,

the outcome would be the same.

But it becomes confusing when you introduce HTML namespaces,

because every HTML tag has a namespace.

Most of them, in most websites that we use,

are just in the HTML namespace.

But within the HTML, you can also embed objects

from a math or SVG namespace.

And the thing is, the same tag can behave differently

in HTML namespace and in SVG namespace.

For example, the text area tag in the HTML namespace

can only contain text inside.

So this code will not work.

You can put any XSS payload from the world,

and it will not execute until you close the textarea tag.

Because of this, according to the rules I've shown you

before, this payload is fine,

because even though it looks like so,

it does not contain the script tag.

It only contains a text that looks like the script tag.

But this stops being true when we wrap this in the SVG tag,

which changes the namespace.

And this is when we finally get to the difference

between the tokenizer and the parser.

The parser will apply these namespace rules to this,

and we'll see the script tag being inside.

The tokenizer will ignore the namespace,

so it will still not see the XSS payload here.

The browser, of course, parses our HTML,

so this code will look innocent to the sanitizer,

but it will execute in the browser,

thus giving you the XSS.

Once you had this, you could easily exfiltrate the flag,

so this would be the final payload that you had to use.

Last year, nine teams found a solution to my task,

and we believe this year you can be one of them.

Challenge yourself by participating in the CTF.

The link is in the description.

In the meantime, if you want to check another video

with a CTF task, check out my write-up

to LiveOverflow's SQL injection task.

The link is on the screen right now.

For now, thank you for watching, and goodbye.