How I (unintentionally) became a hacker

When working in a digital agency, you come across a lot of different technologies to work with. Some of these were in the market for a long time already, while others are still quite new. Often, new technologies are fun to work with. They bring fresh air to a tech stack, change paradigms or are just more elegant to use. But what if this fancy new technology you came across has undiscovered security holes? What if you not only detected a big security issue within your own application, but were able to exploit it to get sensitive, personal data from other companies using this technology?

In my case, I was taking over the backend of a client’s yet-to-be-released project from a coworker. This backend was a rather new open-source headless CMS. Having worked with Wordpress in the last couple of years (and not loving it), I found it quite refreshing to see other takes on the CMS topic. This headless CMS was written in JavaScript, offered the ability to add plugins and even had a GraphQL API. It ticked a lot of boxes for me, so I was quite happy with it.
Part of working with this CMS was to define a schema for the data types we needed, like a headline, image and content for articles. A Graph API based on this schema is exposed automatically. As the project required users to be able to login, we installed an official plugin that provides a schema for users, including signup and login logic. Like the self-defined one, this schema was also exposed via the API, but parts of it were only accessible for authenticated users. Also, authenticated users only had API access to their own data… or so I thought.

Something smells fishy

The user plugin I mentioned before brought a role and rights management with it. It enables you to treat anonymous and authenticated users differently. While playing around with the API, I noticed that I was not only able to see the role of my own user, but that I was also able to get all users assigned to the same role. Even worse, I could see the email addresses of those users. Thankfully, the user plugin offered an option to hide fields from the API, so I did just that with the email field. As there was no other personal data exposed, the problem was solved. I briefly discussed this topic with the coworker who previously worked on the project and closed the case.

Data leaks, data leaks everywhere

Some time later, my coworker contacted me again. He mentioned that the CMS’ official website shows some testimonials, along with websites that use the CMS. He found out that the problem we faced with email addresses being exposed was also affecting these testimonials.
In one example, we were able to download orders from a small online shop, including the full address of the users who made an order.
In another, we could download applications for job offerings, including full name, cover letter and even the resume (CV).
We were shocked. Was it really that easy to get sensitive information from websites using this CMS?

It’s not a bug, it’s a (missing) feature

Because of the importance of this topic, I decided to contact the company that builds the CMS immediately. I gave them all the information I had, including concrete examples of API requests. As I feared retaliation from the affected website operators, I decided against contacting them directly. After all, they could sue me for hacking their systems. Instead, I advised the CMS company to not only state the API problem on their website (and to fix it, of course), but to also contact all of their testimonials to have them review their APIs. They reacted quite quickly to my email, but called the problem a “known limitation” and gave some vague instructions on how to mitigate it. Although they mentioned forwarding this issue to the development team and contacting the affected website operators, it felt like they didn’t treat the issue with the necessary priority.

Bottom line

Security holes and data breaches come in all shapes and sizes. In this case, it was way too easy to get sensitive information that could be used to compromise people or businesses. Having an eye on privacy and security, for example by having an expert on board and perhaps by doing penetration tests, can help you make your website more secure.

Image by lalesh aldarwish