Target: EspressReports ES Version 7 Update 7
Brief: POST requests can be made to the server exploiting a CSRF vulnerability. This can lead to unauthenticated attackers or low privileged accounts performing privileged functionality via session surfing. In this write up, we exploit the CSRF vulnerability to create a new administrator account.
Attacker IP – 192.168.1.29
Server IP – 192.168.1.30 (http://192.168.1.30:8080/ERES/)
During some research time at ECSC, I stumbled across a few bugs within a piece of software that I had previously seen in the wild. During this period I was able to find 2 specific vulnerabilities that were submitted for CVE IDs (CVE-2019-9957 and CVE-2019-9958). Following the research time, I continued to analyse the target software in attempt to find more bugs and vulnerabilities.
There are a small number of requirements that are needed to successfully exploit this CSRF vulnerability. In this case, we are going to create a new administrator account via a crafted request. To accomplish this, we will need:
- Crafted POST request with our custom parameters
- A target administrator to trigger the request
This write up will walk through the creation of a new admin account, exploiting CSRF vulnerabilities via a maliciously crafted webpage. Following the write up is an additional action that can be performed via the same vulnerability.
Obtaining the target request
The first requirement we need is to capture and tweak the target POST request for the functionality we require. To obtain this, we can set up the target software locally and perform requests as if we were targetting the server itself. Luckily, in this case, there is a trial version of EspressReports ES available to download and use for 45 days.
Once the software is up and running, navigate to the login screen: http://192.168.1.30:8080/ERES/login.jsp
Once logged in, we can open the admin panel via the button on the bottom left of the dashboard/welcome page. Once there, we can see the “Add new user” button.
A form should appear that requires some details for the new user, upon submitting this data – we need to capture the POST request that is sent to the server with our submitted data. We can do this with Burp.
The request that was sent on my local instance can be seen here:
POST /ERES/Admin_UserList.jsp HTTP/1.1 Host: 192.168.1.30:8080 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://192.168.1.30:8080/ERES/AddUser.jsp Content-Type: application/x-www-form-urlencoded Content-Length: 109 Cookie: JSESSIONID=F315D25CCA67B21597BAB5A9E50078BD Connection: close Upgrade-Insecure-Requests: 1 username=John_Doe&fullname=John+Doe&email=john%40doe.com&pass=secretpassword&pass2=secretpassword&role=VIEWER
Studying this request, we can see the following key information:
- POST request made to /ERES/Admin_UserList.jsp
- Username = John_Doe
- Password = secretpassword
- Role = VIEWER
- JSESSIONID is sent to authenticate the requestIf we log in to this account, we can see the immediate difference between the admin and viewer roles.
Crafting our malicious request
Now we know what the request looks like to create a new user from the web view, we can craft a malicious webpage that performs the same request via CSRF and, with the correct parameters, create our new administrator account.
In order to gain the additional privileges, we only have to change the “role” parameter from the previously shown POST request. Once tweaked, our new set of parameters will look like the following:
A malicious web page can be crafted to trigger this CSRF exploit. The quickest way to do this is use Burp to generate a CSRF PoC for the target request. This can then be hosted on the attacker’s machine.
In this case, if the target administrator were to fall for the malicious website and click the “Submit request” button, then the user “John_Doe_adm” will be created with administrator privileges.
Finally, we can log into the new account with the following credentials:
– username = john_doe_adm
– password = password
Creating an entire new account on the target could cause immediate suspicion. If the user list is being monitored closely, or the user count suddenly increases, then the target could quickly remove the account. In an attempt to be less obvious, we can use the same vulnerability to escalate a current existing account. The following request was captured and tweaked within Burp to elevate the “low_level_user” account’s privileges.
POST /ERES/Admin_UserList.jsp HTTP/1.1 Host: 192.168.1.30:8080 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://192.168.1.30:8080/ERES/EditUser.jsp?EDITUSER=low_level_user Content-Type: application/x-www-form-urlencoded Content-Length: 135 Cookie: JSESSIONID=F315D25CCA67B21597BAB5A9E50078BD Connection: close Upgrade-Insecure-Requests: 1 EDITUSER=low_level_user&editedLDAPUser=false&fullname=Low+Level+User&email=lowlevel%40user.com&pass=password&pass2=password&role=ADMIN
Combined with a malicious web page, this would result in the privilege escalation of a current existing account.
The same approach could be used for a number of admin functionality across the site.
There is currently no available fix from the vendor (as of June 15th, 2019).
24/06/2019 – CVE published (link)
23/03/2019 – CVE number assigned (CVE-2019-9958)
22/03/2019 – findings sent to and acknowledged by vendor
19/03/2019 – told vendor about findings