As my wife recently started an at-home daycare, we have done testing of different child activity tracking applications that provide parents with updates about their child throughout the day (e.g. foods eaten, frequency of bathroom, playtime, etc.). Being a security researcher and not trying to judge a book by its cover, it seems like it’s hard to not bring out Burp Suite and verify a couple of things before settling on an application.
One of the researched applications appeared to perform proper authorization and authentication, but as you might guess, this was not the case. Let’s walk through one of the authorization issues discovered within the application.
Creating an entry (activity / update about the child)
Activity has been successfully created
The specific issue that I came across – and I’m finding this in an increasing number of tested web applications – arises from a lack of attention to verbose error messages in relation to functionality the user account shouldn’t have access to. For example, the application allows users to add activities (what occurred during the day for your child – eat/sleep/bathroom use/etc.) and every parent can delete their child’s activities. When attempting to delete an activity associated with a different parent’s child, the request doesn’t work (which is great)! However, the error messaged received displays the parents name. The following screenshots walk through the process –
Delete child’s activity
Here is the delete request as we would see through Burp Suite
We can see from the HTTP response that the status has been deleted. In the HTTP request the “ID” parameter refers to the specific activity entry. If we modify the “ID” parameter by incrementing / decrementing the number, the server will respond with messages containing other parent names. The following screenshots are examples of the responses –
First / Last name of parents
If someone wanted to enumerate several account users, the Burp Suite Intruder functionality could be utilized by setting the payload position to the ID parameter like in the following screenshot:
To start returning some valid responses, we can configure the payload with the following options –
Intruder also allows the configuration to display specific strings contained within the HTTP response. In this instance we can have the Intruder results display the account name:
With Intruder running, we can see that we are getting different length responses – resulting in different account users being disclosed.
When a user attempts to access information about other accounts within the application, the application should respond with “Your account does not have access” and nothing more. This message is perfect in relaying the correct amount of information. Applying the same concept to the activity delete functionality would prevent attackers from obtaining information about other users of the application. A resource that is commonly referred to at times would be OWASP – Access Control:
Disclosure Timeline:
Discovered: July 26th, 2019
Disclosed to vendor: July 29th, 2019
Vendor fix issued: August 1st, 2019
Confirmed fix: August 5th, 2019
NOTE – There’s a part 2 coming next week on another day care application!!!Talk to an Expert