FirstBlood-#49 — New Account Patient Information restriction bypass
This issue was discovered on FirstBlood v1
On 2021-05-09, vermsec Level 4 reported:
Hello team, as the application puts restriction on new accounts so that they can't access the patient information, this restriction can be bypassed and patient sensitive information can be retrieved via newly created accounts.
Description
It was discovered that the application doesn't properly perform authorization on a critical functionality which leads to unauthorized users gaining access to or performing actions on restricted resources of the application.
Impact
Using this any newly registered account can be used to extract patient sensitive information.
Proof of Concept
Steps to Reproduce
-
After login into firstbloodhackers.com using a newly created doctor account (which in our case is user - jklio) try to search for patients we get restricted and the application responds with As your account is new you are unable to search for patients.
-
After viewing the source code of the web page /drpanel/index.php
using the drAdmin user we can see the following JavaScript code which executes the findPatient().
function findPatient() {
var patientName = document.getElementById("patient_name").value;
var xhr = new XMLHttpRequest();
xhr.open("POST", 'drapi/qp.php', true);
xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xhr.onreadystatechange = function() {
if (this.readyState === XMLHttpRequest.DONE && this.status === 200) {
document.getElementById("patientresp").innerHTML = this.responseText;
} else {
}
}
- Similarly we can construct our own HTTP request and retrieve patient sensitive information:
POST /drpanel/drapi/qp.php HTTP/1.1
Host: firstbloodhackers.com:49246
Content-Length: 9
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: */*
Origin: http://firstbloodhackers.com:49246
Referer: http://firstbloodhackers.com:49246/drpanel/index.php
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: drps=4e52e86122d43966449600d61
Connection: close
name=vemm
- And as the InviteCode which is used to register a new doctor on the application has a business logic flaw on it self where the same inviteCode can be reused to register multiple doctors (also an inviteCode is leaked in this reddit post - https://www.reddit.com/r/BugBountyHunter/comments/n4xzw1/firstbloodhackerscom_doctor_registration/). This makes this issue more critical because now an attacker can simple register a doctor on the application and access sensitive patient information bypassing any restriction of new accounts.
Remediation
Apply proper restriction on the drps
to restrict access of newly created accounts to sensitive endpoints of the application.
P1 CRITICAL
Endpoint: /drpanel/drapi/qp.php
Parameter: drps (Cookie)
Payload: 4e52e86122d43966449600d61
FirstBlood ID: 12
Vulnerability Type: Auth issues
If the request method is changed from POST to GET, then the endpoint /drapi/qp.php becomes available to ANY user due to an application logic error