GOOGLE GRUYERE: INTRO INTO XSS (Basics & HTML file Upload)

 Google Gruyere is an intentional web application created with the sole purpose to study and learn on how to find and exploit well-known vulnerabilities. This blog posts will dive into this application for both learning and documenting for myself as well as those interested in finding out how web app vulnerabilties can be exploited.

Intro into XSS

XSS or 'Cross Site Scripting' is a web application vulnerability that basically allows you to inject either Javascript or HTML into a web application that can be injected in the victim's browser. In short, its a code-injection vulnerability, if you're looking at it in a "bird's eye" view. There are different types of XSS vulnerabilities (Reflected, Stored and DOM XSS) which will be elaborated upon in future blog posts.

File Upload XSS

We will utilize Google Gruyere and see how we discover that the vulnerability exists and see how we can exploit it if it does exist (of which it will in this case). Here, we will exploit XSS vulnerability in this application by injecting HTML code within the server and having the server execute the HTML file also known as a 'File Upload XSS'. within this HTML, will be the document.cookie payload which will leak the cookie for the user within this application.

But firstly...Whats a cookie?

HTTP cookies, or internet cookies, are built specifically for web browsers to track, personalize and save information about each user’s session. A “session” in this instance, is the word used to define the amount of time you spend on a site. Cookies are created to identify you when you visit a new website. The web server — which stores the website’s data — sends a short stream of identifying information to your web browser in the form of what we call, cookies. This data that identifies you (also known sometimes as “browser cookies”) is processed and read by “name-value” pairs. These pairs tell the cookies where to be sent and what data to recall.

So, where are the cookies are stored? It’s simple: your web browser will store them locally (on your computer) to remember the “name-value pair” that identifies you. When you return to the website in the future, your web browser returns that cookie data to the website’s server, triggering the recall of your data from your previous sessions. 

Let's say that an XSS payload has been injected on a site that is XSS vulnerable and the administrator of a site has no idea about the vulnerability. He has the ability to view, modify and retrieve any sort of critical data about the site and the server itself. The administrator then triggers the payload injected by the we application. with more advanced payloads, the attacker can be able to retrieve the cookie and send requests to the server utilizing the admins cookie, thus resulting in a scenario where the attacker will then "impersonate" the admin, allowing the attacker to then do anything and view anything stored on the server. This is just to give an overview on how severe of a vulnerability this can be.

Finding and confirming XXS Vulnerability

Lets take a look at Google Gruyure Vulnerable Web App:

PS: You can find the vulnerable web application here

Above is how the vulnerable web application looks (You will need to create a user within the site database). DO NOT USE CREDENTIALS YOU USE FOR REAL SITES AND USE THEM FOR THIS ONE. GOOGLE GRUYERE IS SIMPLY FOR EDUCATIONAL PURPOSES ONLY.

 For background, we already established that the site is vulnerable to XSS by looking clicking "All snippets", specifically the 'uid' parameter within the URL. Conisider the following:

here we see the URL of Cheddar Mac's "All Snippets". At the end of the url we see that the uid is equal to 'cheddar'. From this point, the most useful thing to do is to identify if the application can render any Javascript code. If it can, we will know for sureb that the site is vulnerable to XSS.

 

Lets have a look at what we get when we send this back to the server.

 

Immediately, we see a pop up box that CONFIRMS THAT THE WEBSITE IS VULNERABLE TO XSS. Now lets go on further to develop this payload and retrieve the cookie of this particular user. What we will do to achieve this is to modify the payload and include the document.cookie function in Javascript, that shows the cookie for any of the users that are logged in.

Like this

 

When we send this back to the server, we get the following results:

 We see that the vulnerable XSS application in the uid parameter in the URL shows the cookie of the authenticated user 'Kaizen'. An attacker can use this cookie and modify requests to the server through MITM means and use for malicious purposes. 

File Upload XSS Vulnerability

In the web app, we can confirm that the it is XSS Vulnerable through Javascript injection. The next one will be to demonstrate how to craft a payload within an html file, inject the HTML file through application functionality and have the server executed it that has been executed.

Consider the following:

 Here we just have an extremely basic HTML file, with the header displaying the message to the user that they're cookie has been stolen as well as the payload to be run on the victim's browser, enclosed within the alert() function with its origin in Javascript. We will use this file and upload in Google Gruyere vulnerable web app. After this the app will show the directory that the file has been saved in. At that moment, once we navigate to where the file will be stored in the server, the simple payload will be executed as well as the HTML file rendered!

Lets see that happening:

 

We will upload the file here and see the result of that.

 Above we see the directory within the server where the file has been uploaded. Let's navigate there.

 

The final result shows that the vulnerability has been exploited and the cookie has been stolen. This is really a very surface level demonstration of how XSS can be utilized and weaponized against a vulnerable web application.

 

Beginner Reversing

Reversing is a fundamental skill that requires understanding various low level concepts, both to uncover vulnerabilities as well as reverse algorithms. Within my time learning reversing, I've had to adapt my mindset to reading various patterns that assist me when playing CTFs or when doing my own independent security research. In this blog post, I will go over basic reverse engineering concepts and the methodology of what goes into it.

When reverse engineering is basically the process of tearing down software or hardware and analyzing its functions and information so that its functionality and behaviour can be better understood. To even begin looking at reverse engineering, we have to look at the various methods that can go into reverse engineering.  

I'm not gonna go through the details of what and how a computer handles an executed program. That will be covered in a future post or a future tutorial which I will compile and go through in detail. I will go into reverse engineering a "hello world" program, compiled in x64, on my linux machine. 

Take a look at the code below:

This is a simple "hello_world" program written in C. It simply prints out "Hello World!" on the command line using the puts() function. Looking at this program, it doesn't really do much. Let's start by first compiling this code into a working executable program that we will execute on our command line as well as debug. This tutorial is compatible on a linux system. You can apply the reverse engineering knowledge to a windows machine but for the sake of compilation, it is only linux based.

Copy this code and save it as "hello_world.c". After you do this, you can then use "gcc" which is a linux based compiler which will compile C programs in the terminal. To compile your "hello_world.c" program, the command is as follows:

gcc hello_world.c -o hello_world

Now that you have compiled the program, now its time to look at the assembly code of this program.

The code above is the assembly code of the hello_world program. Okay???? so what???? Well... with languages like C and C++, the code that we actually write is not the one being executed. The code we write is actually sent to a compiler, and that compiler will then translate our code into assembly code, which is essentially the "real" code that is being ran by the processor. It will serve you will to understand how assembly code really works so you can thrive and actually succeed in reversing. 

With assembly code, there are lots of other architectures available for them. This one that you see above is x64. There are others like x86-64, x32, ARM, MIPS and others.

To begin reversing, we have to understand what Registers are:

Registers are simply locations that the processor can store memory. They're quite similar to variables. 

Below are a list of registers available in x64.

rax

rbx

rcx

rdx

rsi

rdi

r8

r9

This blog post will end there for now. In a future post, I will expound more on the different x64 registers and how they can greatly impact your reverse engineering projects and hacks.

Happy Hacking.