Advanced Class: Introduction

Date	2. Oktober, 2024
Hosted by	Milan @cryp70m4n
Location	Reykjavik University
Knowledge Level	Advanced
MATERIAL	Link to Slides & Link to Code

TOPICS

Topic 1: Let's talk web escalating XSS to RCE on electron apps.

Topic 2: Binary exploitation, reverse engineering and code analysis. Diving into why your code might be vulnerable, how attack might be able to exploit the vulnerability and how to write code that is more secure.

Topic 3: Introduction to real-world cryptography Predicting random number that roulette will generate.

[CHAPTER 1]

X -> All the code and commands related to this chapter can be found under class1/samples/web <- X

Vulnerabilities such as XSS are much more dangerous within Electron apps rather than usual web apps.

Having a XSS Vulnerability on an Electron app will most of the times lead to RCE, even if NodeIntegration is disabled and ContextIsolation enabled.

For this showcase NodeIntegration will be enabled and ContextIsolation disabled, but we will learn workarounds for this in future events.

[ Slide 4 ]

As you can see, we are presented with a very basic web app that lets us post comments and see them. The usual first assumption upon seeing the input box is to either try XSS or SSTI.

[ Slide 5]

A possible way to test the input box for XSS is by inputting:

<img src="x" onerror="alert('XSS in Electron!');">

After confirming that XSS is possible, the following input (next slide) can be used to list all files (or do any other commands you can imagine, as we have RCE! 😊 )

[ Slide 6 ]

<img src="x" onerror="require('child_process').exec('ls', (err, stdout) => { console.log(stdout); });">

We can see that the exploit worked by opening the developer tools console!

[CHAPTER 2]

X -> All the code and commands related to this chapter can be found under class1/samples/bof <- X

[ Slide 9 ]

As a preface, this won't be the most theoretically and technically precise explanation of the stack.

Despite this, the architecture we will cover is x86_64.

This architecture and many other popular ones implement the stack as growing downwards.

The picture in slide 9 has a few registers represented, but for now we will cover the most important things related to the basics of stack-based buffer overflow attacks.

The only register that we need to know about for now is rip (eip on 32bit CPU) which is the "Instruction pointer", which points to the next memory address that the program should go to and execute.

In slide 10 we can see our vulnerable program that we will experiment on.

This sort of vulnerabilities are usually unfeasible in the real world, due to the fact that the usage of "insecure" functions like gets has become deprecated, and new versions of glibc do not even have it.

Also glibc added _s to functions like strcpy, so it’s possible to have built-in safety.

Vulnerabilities like these happen due to poor size definitions when taking inputs or copying data (sizes are usually defined in macros, like we did).

While fgets is considered a safe function, if there is confusion about the taken input size, it can still be used to do a buffer overflow attack.

[ Slide 11 ]

This slide shows a small breakdown of the attack plan, but put simply, we use a debugger like gdb to "fuzz" the program with inputs of random sizes, until we find the correct offset (offset finding will be further covered in future).

After we found the correct offset, we can use a tool like objdump to find the addresses we need. Once we run objdump we find that the address of the function ‘win’ is at 0x0000000000401146.

But before we jump to the exploit, we must remember that the ‘win’ function does not contain \n when printing, which means our flag won't be printed.

For this, we will use a trick I learned some time ago from a British friend.

If we jump to the ‘win’ function and then jump to any function that prints anything followed by \n we can get the program to print the flag.

In this scenario, we can jump to ‘junk’ or ‘main’, since both have \n when printing. We will jump to main in this scenario.

So, our exploit would be:

"A" * (offset we found using gdb) + ‘win’ function offset + ‘main’ function offset A is just a random character, it could be any character we use to get to our offset (40 in this case).

You can find the actual exploit and its output in slide 12.

In the future we will dive much deeper into binary exploitation.

[CHAPTER 3]

X -> All the code and commands related to this chapter can be found under class1/samples/roulet <- X

[ Slide 14 ]

We start by opening the page and spinning the roulette, finding that it prints a random "winning" number.

Our goal is to predict that same number.

In slide 14 we open the developer tools console, and we can see the request that is sent to the server, asking what the winning number is.

By opening the request, we see that numbers are not rounded, which gives us everything we need to know regarding the number prediction.

Here, we can often assume that the backend runs NodeJS, which uses V8 random algorithm. We can also run a tool like wappalyzer, which will confirm that website uses NodeJS.

[ Slide 15 ]

By looking at the backend, we can see how numbers are generated, before being sent to the client.

Now, our task is to predict random number.

It is recommended to use this to help get the idea on how to do it (just modify this code for this specific scenario):

https://github.com/PwnFunction/v8-randomness-predictor

If you have any questions regarding these tasks, the last slide of the presentation has multiple ways on how get in contact with me.