Skip to content

My Expenses 1

by ssanjua

September 20, 2024 | 04:55 PM
Share this post:

Description

MyExpense is a deliberately vulnerable web application that allows you to train in detecting and exploiting different web vulnerabilities. Unlike a more traditional “challenge” application (which allows you to train on a single specific vulnerability), MyExpense contains a set of vulnerabilities you need to exploit to achieve the whole scenario.

Scenario

You are “Samuel Lamotte” and you have just been fired by your company “Furtura Business Informatique”. Unfortunately because of your hasty departure, you did not have time to validate your expense report for your last business trip, which still amounts to 750 € corresponding to a return flight to your last customer.

Fearing that your former employer may not want to reimburse you for this expense report, you decide to hack into the internal application called “MyExpense ” to manage employee expense reports.

So you are in your car, in the company carpark and connected to the internal Wi-Fi (the key has still not been changed after your departure). The application is protected by username/password authentication and you hope that the administrator has not yet modified or deleted your access.

Your credentials were: samuel/fzghn4lw

Once the challenge is done, the flag will be displayed on the application while being connected with your (samuel) account.


Recognition

First we try to recognize the IP of our target with arp-scan.

sudo arp-scan -I eth0 --localnet --ignoredups

Descripción

Here we see that our target’s ip is 192.168.0.24. With our target identified we check if it is on and operational.

ping <IP_VICTIMA>

We can see in the output that the victim machine is on and that we are dealing with a Linux system since the ttl is 64, corresponding to Linux operating systems.

myExpense

We place the IP in the browser to see what we are dealing with

myExpense

Now we do an nmap scan to see what services the victim machine is running.

nmap -p- --open -sS -vvv -Pn <IP_VICTIMA> -oG allPorts

myExpense

Port recognition gives us an important piece of information in the robots.txt file contained an entry disabling access to /admin/admin.php.

The robots.txt file usually contains directives that specify paths or files that should not be crawled by robots.

We tried in the browser the path http:<IP_VICTIMA>/admin/admin.php and discovered an administration panel where we see our inactive samuel and the rest of the users of the company.

myExpense

Now we have samuel’s username and we can login to his account since we have his credentials

myExpense

The credentials are correct but the user is disabled so we can’t continue that way.

Idea

We need to be able to activate Samuel’s user, so we need a privileged user to be able to activate it. If we click on the ‘Inactive’ button we can see the query with which apparently we could change the status to ‘Active’.

myExpense

Let’s try to create a user and see if the site is prone to the XXS [[(Cross-Site Scripting)]] vulnerability.

We create a user with a small JavaScript script.

<script>alert("injection")</script>

myExpense

As we can see in the image above the Sign up!'' button is blocked, but by deleting the disabled“ instruction through the browser console the button is enabled and we can create the user.

We return to http:192.168.0.24/admin/admin.php and we verify that we have indeed violated the web.

The next step we try is to try to activate Samuel’s account by appropriating the cookie of a privileged or managed user. We will try [[Cookie Hijacking]].

We create a small script in JavaScript where by listening on port 80 with a Python server. The hypothesis is that the administrator user must be running and controlling the service in the admin.php panel so we can steal the session cookie to be able to activate the Samuel account again.

myExpense

myExpense

We change in the browser the current cookie for the one we retrieved in the python server and we will see that one of them is equivalent to the administrator user.

myExpense

But unfortunately the simultaneous session of this administrator user is not allowed, so we do not have permissions to see what happens on the page but we can send requests since we are authenticated as the administrator user having stolen his cookie. So we can create or modify the script to make the request we want: that the user slamotte is active.

myExpense

We send this new script as XSS again and wait a few seconds and recheck the admin/admin.php panel with the cookie of a user other than the administrator.

myExpense

Now slamotte is active so having his credentials we can log in with his account to try to pass the expenses.

user: slamotte
password: fzghn4lw

Effectively now we can log in since your account is active and send the expense report.

myExpense

Now we have to validate the expense, the info we get from the chats that can be seen in Samuel’s profile indicate that his superior is Manon Riviere so we have to get his credential to be able to approve the expense.

In Samuel’s profile you can send messages so if he publishes a message we could try to steal the cookie of the authenticated users. We are going to try this by injecting the JavaScript script to steal the cookie in the body of the message. Now we check on our Python server if the script returns something interesting.

myExpense

We can see several cookies probably from all the employees who receive the message. We try to change all of them in the browser until we find the one of our manager.

myExpense

Once inside we approve the payment.

myExpense

We find that there is one more person who must approve it for it to reach Samuel.

myExpense

His superior Paul Baudoin is in charge of approving financial transactions, so we need to get hold of his credentials now so we can finally approve the expense.

SQLI

We are going to create a [[SQLI]] (SQL injection) manually. First we try to see if the vulnerability exists on the page of the user Manon Riviere.

myExpense

We try the following SQL query and it does indeed return interesting information, the database user.

192.168.0.24/site.php?id = 2 union select 1,user()--

myExpense

192.168.0.24/site.php?id = 2 union select 1,schema_name from information_schema.schemata-- -

myExpense

myExpense

myExpense

myExpense

myExpense

myExpense