FirstBlood-#853Unauthorized modification of mailbox
This issue was discovered on FirstBlood v2



On 2021-10-29, axe Level 4 reported:

Summary

  1. Hi, mate. I am very sorry for the length of this report. I want others to understand this report as well.

  2. I mainly want to explain why I use this cookie:doctorAuthed=eyJkb2N0b3JBdXRoIjphdXRoZWR9

Steps

  1. Create an appointment (/api/ba.php)

  2. Find an Appointment(/yourappointments.php)

    2.Click Retrieve Appointment -> Get /manageappointment.php?success&aptid=ab7b231a-7819-4abd-8aa3-6a65aab58bf6 endpoints

  3. Click Modify Appointment -> Get /api/ma.php?success&aptid=ab7b231a-7819-4abd-8aa3-6a65aab58bf6 endpoints

    1. Use BURP to grab the packet and add [email protected]

  4. Revisit /manageappointment.php?success&aptid=ab7b231a-7819-4abd-8aa3-6a65aab58bf6 -> It was found that the email parameter value did not change.

  5. Why would this not produce a change? There should be no problem with our thinking.

    1. When I logged the user back in, I used BURP to grab the packet and I made some different discoveries.

    2. We found that the cookie is composed of two parameters, drps=6610c3a690c8031664a93ba3e AND doctorAuthed=eyJkb2N0b3JBdXRoIjphdXRoZWR9

  6. So when we add doctorAuthed=eyJkb2N0b3JBdXRoIjphdXRoZWR9 to the request package in step 3 , see what happens?

    1. Add and send

    2. Revisit /manageappointment.php?success&aptid=ab7b231a-7819-4abd-8aa3-6a65aab58bf6

    3. Something magical happened, we succeeded in modifying

    4. To eyJkb2N0b3JBdXRoIjphdXRoZWR9 -> Base64 decryption -> {"doctorAuth":authed}

  7. When I authed change to something else will it test successfully?!

    1. {"doctorAuth":admin} -> Base64 encryption -> eyJkb2N0b3JBdXRoIjphZG1pbn0=

    2. Revisit /manageappointment.php?success&aptid=ab7b231a-7819-4abd-8aa3-6a65aab58bf6 -> Access failure

  8. Proves that {"doctorAuth":authed} is the key factor that determines the success of modifying a user's mailbox!!!

Vulnerability Exploitation

  1. Login to admin account -> View HTML code -> Get id -> Modify other user's mailbox by sub id value any (unfortunately, test failed)

Impact

  1. unauthorized modification of e-mail address

P3 Medium

Endpoint: /api/ma.php?success&aptid=ab7b231a-7819-4abd-8aa3-6a65aab58bf6

Parameter: email

Payload: Any email address


FirstBlood ID: 33
Vulnerability Type: Application/Business Logic

Our mistake: We did not intentionally leave the code to change emails if the correct values were set, however it created interesting results because most discovered this but missed bug ID 20 and 21 and whilst it was not possible to modify via integer, if the ID was known it would still work.