[PentesterLab] Play Session Injection
This is an exercise from PentesterLab to reproduce & demonstrate how to exploit XSS and SQL injection vulnerabilities. More information and ISO download please check here. The official course is highly recommended to read, which explains how the vulnerabilities happened and the ways to exploit.
Difficulty: 3 / 5
Links
watch video online:
Method
- Scanned the network to discover the target server [Net Discover]
- Port scanned the target to discover the running services and open ports [nmap]
- Interacted with the web server, found the (Cross Site Script) XSS vulnerable point. [Firefox]
- Register two new accounts which username are test and test2, analyze both session cookies to figure out the cookie’s construction rules. Inject evil codes into the session cookie to bypass the validation schedule. [firebug / Burp proxy]
- For goal one, inject “admin:1” to login with administration privilege. For goal two, inject “user:admin1” to login as admin user “admin1” with administration privilege. [Burp proxy]
Tools
All the tools used here can be found in Kali Linux
Walkthrough
By reading the training pdf, we know that there is a session injection in Play framework. (In this exercise, we have two goals to achieve. First one is to login as anyone but have administration privilege; Second one is to login as administrator name is “admin1”).
Find the Play session cookie
The attacker interacts with the web server, by using “Firefox” browser to graphically render the web application on the target. Upon viewing the page, the attacker know that this there are two goals need to be achieved. First one is create a user with admin privilege and the second one is to login as the user “admin1”. On the top left hand side, is the navigation menu to “Register”(which asks the attacker to register a new account), “Login”(which asks the attacker to login). The attacker tried to register a new account which the name is “test”, then run Burp proxy and login with the “test” account. After checking the request intercepted by Burp proxy, the attacker found that the session information is saved in the cookie called “PLAY_SESSION”. The cookie value is in the following format:
1
| |
In order to analyze the session cookie, the attacker register another new account which name is “test2” and the session cookie value is
1
| |
Here we can see that the username would be an injection point. And the encoding format is “%00key%3Avalue%00” (here %3A is URL encoded “:” and %00 means NULL for termination).
First goal is to login as anyone but have admin privilege
In order to login as any user (here the attacker choose user “test2”) with admin privilege, the attacker have to inject evil code into the Play session. As we found that username is an injection point in the session, the attacker need to construct the Play session like this:
PLAY_SESSION=xxx(hash code)xxx%00__AT%3Axxx(authenticityToken)xxx%00%00user%3Atest2%00%00admin%3A1%00
Here admin%3A1 means “admin:1” which usually indicates admin privilege). In order to construct the above Play session, the attacker have to register a new account which user name is “test2%00%00admin%3A1”. (note: Burp proxy is needed here to fulfill this injection.
Second goal is to login as admin user “admin1”
Same as above, in order to login as admin user “admin1”, the attacker have to inject evil code into the Play session. The attacker need to construct the Play session like this:
PLAY_SESSION=xxx(hash code)xxx%00__AT%3Axxx(authenticityToken)xxx%00%00user%3Atest2%00%00user%3Aadmin1%00
In order to construct the above Play session, the attacker have to register a new account which user name is “test2%00%00user%3Aadmin1”. (note: Burp proxy is needed here to fulfill this injection)