Exploiting an unknown vulnerability

I found this vulnerability around 2 months ago in a consulting application. Their security team told me this application is already pentested and they will reward bonus if I could find a vulnerability. For new targets, first I analyze application and make a data flow diagram of its functionality then I start hunting for vulnerabilities. I extensively test for logical vulnerabilities because I know from my experience that there will be some critical transitions which might have been missed by application developers or testers.

I have named it as “unknown” vulnerability because I want to make it as an exercise as well as write up that’s why I haven’t written details in the title.

There are two types of user roles: consultant and client in target application. The application’s core functionality is to provide consulting services to various clients.

  • Consultant set fee in coins for their service.
# consultant request

POST /set/fee/
{"value": 5, "timing":2}
  • Clients visits consultant’s timeline, select an appropriate time slot and book that timing, coins get deducted from client’s account according to fee shown in timeline respective to time slot.
# client request

POST /consultant_username/book
{"timing":2}

Before reading further, I will suggest you guys to write your test case or your approach to exploit the above functionality. Good luck 👍

...

I came up with following test cases 🤔.

  1. Injection vulnerability like Sqli, Command injection
  2. Modify content type and request data to xml for testing XML injection
  3. Booking consultant’s higher value time slots in less coin
  4. Injecting “value” parameter from consultant request and using it in client request
  5. Parameter pollution by injection two timing values in client request
  6. Array based injection using timing value in client request i.e {“timing[0]”:2}
  7. HTTP method tampering by changing POST to PUT
  8. Booking two or more time slots of same consultant by playing multi-threaded client request (Race condition)
  9. Booking two different consultant’s time slots by playing multi-threaded client request (Race condition)

I am sure, you might have come up with different test cases so please comment below your test cases.

Unfortunately, none of the above test cases worked for me 😥. May be their security team mitigated these vulnerabilities or experienced developers built the application.

Next day, I took a look again and this time my attention goes to more in booking request since there is no coin passed in the request and coins get automatically deducted from client’s account after submitting the client request.

POST /consultant_username/book
{"timing":2}

What will happen if consultant change fee to some higher amount just before client book the time slot. I was excited 🤩 thought this should work but again it didn’t work out for me. Since it showed the message “Consultant’s fee for this slot is 10”.

...

I was going to give up but the idea of race condition came into my mind, for testing it out I sent multi-threaded request to web server with four different consulting fee (5, 15, 15, 5) in four different requests at a time and put those requests in a loop for half an hour. When a client visits consultant timeline during this time period there are 50% chances that client will end up paying higher fee. This way, I was successfully able to exploit 😄 this vulnerability by changing consulting price quickly. Application also has an offer features in which consultants can set discount for a certain period of time.

Attack flow

  1. Consultant set fee 5 coins for a time slot ‘x’.
  2. Consultant set offer period i.e 30–60 minutes during a day.
  3. Clients visit consultant timeline during offer period.
  4. Consultant quickly change consulting price by playing multi-threaded consultant request in loop and send it to server.
  5. Clients pay the fee by sending booking request to the server.
  6. Extra coins get deducted from the clients account.

Impact

Consultants can trick clients in paying higher amount then shown in their timeline for their services.

Takeaway

As a defender, make a checklist of vulnerabilities and test it for every feature implemented in the application. Rate limiting and race condition based locking system should be implemented for preventing these kind of vulnerabilities.

As application’s functionalities grow, its complexity grows exponentially and more chances to miss some test cases during design, development or security testing phases of the application. Analyze application functionality by going through request history again and again, understand data flow in application etc. Spend your energy & time in building smarter test cases that can break application’s use case.

Thank you very much!

Learn, Build & Break!