Publicly available results of coronavirus tests – how not to secure your data

TL;DR – date of birth or social security number is not a good idea to secure access to data.

Puzzle – what's the difference between the two pictures below?

But let's start from the beginning. Unfortunately, as is often the case in the IT world, convenience does not go hand in hand with security. I think this time it was similar. However, there is a set of sensitive data where compromises must not be made. Such data include, but is not limited to, information about our health.

Alarmed by a message from my friend Kacpra about how access to laboratory results is granted, I decided to investigate the solution responsible for this in more detail.

As you can see in the graphics above – to access your result through the functionality of "simplified login" you need two information:

  • Order ID, where subsequent order numbers are increasing;
  • ordering person's date of birth [day=X&month=X&year=X]

Under certain assumptions, the number of birth date combinations that can be assigned to an order ID is only about 19,000 combinations. It is not difficult to guess that it is not a major problem to generate all such combinations and check whether they match the order number.

It turned out that my assumptions were correct and after several hundred enumerations managed to match the access data:

enumeration intruder

This allowed for sensitive patient information such as:

  • first name;
  • name;
  • pesel;
  • date of birth;
  • address of residence;
  • the result of the tests;
coronavirus test results
coronavirus test results

Another example of a successful enumeration attempt:

enumeration burp intruder
coronavirus test results

As soon as I confirmed my susceptibility, I reported this error to the software responsible, along with repair recommendations:

e-mail reporting a security bug

What to do, how to live?

One of the most common security measures against these types of attacks is to implement captcha. After several (e.g. three) failed attempts to access the order data, the user of the application will be asked to rewrite the displayed captcha code. Please note, however, that the implementation of such a mechanism is only (or until) a slowdown of the attacker, who in the simplest cases will be able to further brutforss the date of birth with OCR scanners or dedicated captcha reading services.

A better and recommended security feature is to access the results of the order through a sufficiently long, random passwordthat will come to the customer's phone number.

Fortunately, the bug was fixed quite quickly by implementing the reCAPTCHA mechanism from google:

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach (zero spamu!). Dodatkowo otrzymasz, moją prywatną listę 15 najbardziej przydatnych narzędzi (wraz z krótkim opisem), których używam przy testach penetracyjnych.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *