Not-So-Private Personal Data
While browsing the internet looking for interesting things, I happened upon a site used for research purposes around DNA kits. The site was interesting; it lets users compare DNA kits to learn a range of information about their ancestry. Researchers can also use the information for various scientific applications.
The problem, is that after spending 15 minutes or so on the site, it was apparent that it was designed without any concerns for security or privacy. DNA and all of the personal information stored on the site was exposed in an insecure manner. I searched to see if there was a bug bounty program associated with the site, but was unable to find anything. I quickly wrote up my findings and sent them over to the administrators of the site so that they could hopefully implement a fix. The issues were resolved, and the site is now much more secure as a result.
The first issue was our old favorite, Cross Site Scripting (XSS). Most of the search fields were vulnerable to XSS. This could be used in conjunction with some of the other issues present on the website to target users and their data.
In this case, we demonstrated the issue with our old standby Corporate Cat, a benign option.
The second issue was much worse: it allowed anyone to see the data uploaded by any user, even if it was set to ‘private’.
Each user can upload a DNA kit which can be set to public or private. The creators of the site understand that users may not want others to be able to search their DNA or their family’s as this is personal data.
However, by using insecure direct object references, an attacker can access any DNA kits and any groups created by any user regardless of privacy settings.
The site refers to groups created by users as ‘Tag Groups’. Inside these groups, users can add their DNA kits for analysis. In this case, when accessing a Tag Group, the post contained a field called “Tag_ID,” a number that refers to the ID of the Tag Group. By iterating through the IDs, an attacker could view every other Tag Group. We quickly wrote a script to iterate through numbers sequentially until we found a valid Tag_ID that did not belong to us.
Additionally, an attacker could edit any field in these groups; they could even delete them! An attacker could hold the data for ransom if they chose to; it’s a small variation on the ransomware concept that could be employed on a web app.
Mitigating the Risks
The issues I found are common; Ninjas find them routinely during assessments. These weaknesses can expose many users’ personal data to theft. This risk can be mitigated by ensuring that a user has permission to access each page before it is displayed.
In this case, we reported our findings to the owners of the website, who promptly resolved the issues.