Recently, I have been job hunting! I am a senior at Gonzaga University (graduating in May of 2019) looking to dive into the cybersecurity space. One morning, I strapped myself into my car, turned on Darknet Diaries and headed off! Sadly, the icy morning got the best of me. I got in a car accident 20 minutes away from the building I was meeting the company at... I missed the interview, and a major opportunity. I just wanted to put this whole situation behind me... Alas, I had to pay a traffic ticket for getting in a car accident; the worst hackers are angry hackers! This is where the story of the information disclosure issue begins:

In the Garage Sale episode of the Office, Dwight trades a thumbtack for a used candle, then the candle for collection of books then... Until, he claims to have the best item at the entire garage sale. This is in reference to the one red paperclip story where a man started with a paperclip, then ended up with a house. Although, a single paperclip is not a lot, he initially traded it for fish-shaped pen, then for a doorknob...Until, the house. The trick is, each individual trade solves a need for the buyer, but also gains value for the seller. In terms of information, a small and insignificant piece of information can lead someone to a slightly more trusted space. Then, this can get deeper, and deeper and deeper... Until, we have logged in as a person. In terms of the paperclip analogy, we have traded for the house.

Setting the Stage

The website to pay for the ticket had three different options for searching for a ticket: name and date of birth, ticket number and vehicle number (only for parking violations).

The name and DOB search option would bring me to a page to search using my first name, last name and DOB. If a valid result was found, it would redirect me to a page with the search results on it. On this page, the user was given an option to pay, that also displayed the ticket number. Furthermore, the tickets were incremental based upon the city.

The ticket search functionality was quite simple; just search for the ticket number! If the ticket number inserted is valid, then a similar looking page as Figure 2 would appear. The only difference between the two pages was the value being searched on.

Subtle Bug

The web application did a great job at validating that the DOB and name matched on this search option. However, once the validation was done on this page, it redirected to a new page with the ticket number for the user. The URL looked like this: https://some_website.gov/paymentonline/SearchResult.aspx?dataInd=NameDOB&inName=DULIN,%20MAXWELL&inDOB=1996-07-11. On this new page, the next step in the process only assumes the validated data from the previous step. However, this data is very clearly alterable. A malicious user has now bypassed the validation process.

This validation mishap ended up being the downfall of this application. From there, a user could input arbitrary information into these two queries, without suffering at the constraints of validation. After some fiddling, I realized that the DOB was not even necessary! It was possible to just search based upon a name. However, even this wasn't the end... The name parameter was being sent into a like query with a wildcard ('%' for a like query). A query, such as https://some_website.gov/paymentonline/SearchResult.aspx?dataInd=NameDOB&inName=D would return all tickets with the recipient starting with the letter D. At the end, I realized that using a single '%' as the input parameter for inName would return all tickets that had ever been issued to a person or corporation. The output for all of the tickets can be seen in Figure 3.

Paperclip to House

Ticket Number to Name

Armed with just a paperclip, where do we start? In this case, we are armed with only ticket numbers to gather more information about our law breakers. Can we gather any more information from a ticket number? As stated before, there was a second option for searching: based upon a ticket number. From this search option, the search displayed a ticket number, as well as a first and last name of the recipient of the ticket. A ticket number, which feels like a relatively unimportant value, had just turned into a way to find a ticket associated with a person.

Name To Login

Now, we have traded a ticket number for the names of the individuals with the ticket. After looking through this website, I realized that the information gathered could take me no further. So, I started scouring the internet for other places to use this data. Until, I came across the counties court site with a login page (as seen in Figure 4).

All this page wanted to login was a ticket number and last name! Bingo! With both of these pieces of information already known, we could now login as any user that had received a ticket.

Login to All The Information

Within the authenticated user portal was a page with 3 options: Pay the fine (which just redirects back the previous site), request a mitigation hearing or request a deferred hearing. While playing around with the last two options, a very hefty amount of information suddenly appears (as seen in Figure 5).

This page has a mailing address, city, state, zip code, phone number and email addresses! The best part is that all of this information was autofilled into the form based upon previous knowledge payment portal on the previously visited website.

Is this all the information that can found on a person? Well, it is as far as I went. But, there was a possibility to go deeper with it. By going through the court mitigation requests it was possible to get the court to send an email with "Confirmation of the receipt and the court’s findings will be emailed to you if an email address is provided". Although, I did not follow through with this step, there is a very high chance that a full report about the incident would have been sent. This could have included a driver's license number or a license plate number, among other things.

From a slight information disclosure issue of a seemingly useless piece of data, it is quite amazing the amount of additional information that can be discovered. From a red paperclip to a house, or from a ticket number to an authenticated user.

Malicious Fun

Besides the information disclosure, while logged in as a person it was possible to sign up for a mitigation hearing or a deffered hearing without the person knowing! This could ruin someone with the law (for skipping a court date) or really get back at the justice system to have plenty of no-shows for the hearings. Both of these options could be catastrophic to either the person who requested the court date or the county court system.

Mitigations

Finding bugs is by far the most fun about these writeups. However, being able to fix them is more important to the client. So, when I sent this report in, I attached a few potential options for patching the issue:

• Client side data cannot be trusted. Either validate the data in all areas where the client can supply it or save the information in a server side object.
• Do not assume users go through steps in the correct order. Ensure this!
• Validate the input data coming in. I would consider this an SQLi because the query itself was manipulated.
• Have a better authentication system than just a ticket number and last name for such critical actions. A better mechanism would be an email address, ticket number and another private piece of information. Or, even better, have an automated phone bot that asks personal questions that only you could answer. Although, this is slightly inconvenient for a user.

Report

Initially, I was really scared to actually report the vulnerability that I had found; I remember reading stories of people going to jail for trying to help a companies security posture. However, I realized if I reported this in a nice and friendly manner, while conveying I was trying to help them (not myself) then they were going to be much more accepting of the issue. In the end, the people I talked to were very receptive about fixing the issue (also, I'm not in jail!)
Report process:

• 1/20/2019: Initial email with a report of the vulnerability sent to multiple employees.
• 1/21/2019: Chief Information and Privacy Officer contacts me.
• 1/28/2019: The searching capabilities are patched.
• 2/14/2019: Review is complete. The CISO claims that no private data had been stolen and a promise to improve the security posture, as well as promising that further testing will be done. This came with a notice that I may post about it, without including the county information.

Overall, I was very happy with the response time of the county! The initial search function that I exploited has been fixed. At the time of writing, the DOB and name search function is disabled at the county site.

Conclusion

In terms of security I learned a few things: do not trust any client side data coming in, users do not always do actions in the correct/expected order and a paperclip can turn into a house quite quickly. If you thought this article was fun or learnful, feel free to check out the rest of my website's content. Feel free to contact me with the email in the footer with any questions, comments or concerns. Cheers, Maxwell Dulin (ꓘ).