Misconfigured API endpoint on portal.skge.nl leaks PII data of registered healthcare providers
Background
Ransomware attacks in healthcare are our biggest threat according to the annual report of Z-Cert.nl. In this report it’s mentioned that the vendors of the healthcare providers are targeted more often compared to the individual practices or professionals (page 16).
The reason could be that the impact could be bigger if you hack a vendor, as they likely supply multiple customers at the same time.
Most people think of healthcare vendors that are used by patients; for example the alarm systems we use for our elderly. Last year one of those vendors became victim of a ransomware attack; Tunstall.
But what about the vendors that host sensitive data about the healthcare providers, for example the complaints officers and dispute resolution bodies? What if they have bugs that leak data?
If we could figure out who has signed up with them we could spear phish those healthcare providers: “You received a complaint, enter your password now”.
Today we will hack the firm I use as a complaints and disputes committee for my healthcare work; SKGE.nl
Missing coordinated vulnerability disclosure policy
More than a year ago we discussed the data leak at HAwebsso.nl which led to the leak of +15k Dutch doctors their private details, including their email and hashed passwords. This was an interesting finding, as it uncovered a bug that was there for at least +3 years (regarding Archive.org logs maybe even +5 years).
The LHV quickly mitigated the bug and coordinated the disclosure, a great example of how coordinated vulnerability disclosure can be applied in healthcare.
However the vendor of today SKGE.nl does not future such coordinated vulnerability disclosure at the time of reporting.
The good news is that after the report SKGE published a CVD that matched the NCSC guidelines. However the sad news is that the influx of bogus reports was too high for them to keep it online, at the time of writing (17–03–2024) they were searching for solution to this (Z-Cert might be able to help out here).
An interesting lesson learned and something we need to fix on a wider scale if we want to give everyone access to CVD. Is this something our government should fix, for example by provide grants to nonprofits who are in need of CVD triaging services? Or offer themselves such a thing as a service?
One might ask themselves, is it unethical to hack a system if you’re not explicitly allowed to hack it?
Doing this sort of security research is serving the public interest and could be compared with being a journalist trying to research stuff that has serious impact on our society. Especially if it hosts your own data.
Also see the Code of Conduct of the DIVD:
We are aware that we operate at the edges of what is legally allowed, so we proceed by these three criteria commonly used in court cases on vulnerability disclosures:
Societal need: we do vulnerability disclosure to prevent online damage to as many internet users as possible and don’t serve any particular financial, political or individual interests.
Principle of Proportionality: we serve this need with appropriate means. Our research should increase and not decrease the integrity and availability of online systems.
Principle of Subsidiarity: if several means are available to meet the need, we opt for the one which has the least impact.
A real world example is when the Dutch Journalist Daniel Verlaan hacked the video conference of the EU defence ministers. As far as I know he did not had permission to research it, but he’s not being charged for this hack. Mr Borrell told him during his hack:
“You know it’s a criminal offence, huh? You’d better sign off quickly before the police arrives.” — Mr. Borrell, 21 November 2020
A clear signal we still got work to do convince (political) leadership that we need to endorse ethical journalists/hackers like Daniel. Not charge or intimidate them or even have laws that make their work risky.
Sharing insights and let everyone learn from previous bugs is the only way forward; you have to compete with threats that are state actors (unlimited budgets) or ransomware groups having millions of dollars in their (bitcoin wallets) bank accounts.
A good development is the recent endorsement of DIVD by our Minister of Justice (dutch); as the DIVD scans the full internet non stop for vulnerabilities and responsible disclose those bugs to the owners of the systems. Wherever they are on the world, despite if they have a responsible disclosure policy. Nobody would prosecute a firefighter right? By the way they always look for talent, so join them if you can!
Recon phase, where to look for bugs?
The platform has a portal that is used by health care providers to change their contact details.
The actual complaints are not registered in any portal. If you don’t store it, you can’t lose it. A smart move as that reduces the attack surface.
So let's have a look if we could access other providers their data. A good start is always to have a look at the spots where we can download invoices.
Whenever we see numeric IDs we try to change the ID to a number lower or higher. We might endup with the data of another user. Lets try!
Boom! We have an IDOR bug that leaks all the health care providers their invoices. The impact is a bit limited as it requires login, however everyone is able to signup (there is no identity check being done).
Furthermore I did not test other IDs, but a good question could be if only invoices are reachable through this endpoint (and not other documents uploaded for example regarding a complaint). I did not test for that so I don’t know and have to trust the vendor on their investigation.
Time to report!
IDOR Bug 2: Exposed healthcare PII when signing up.
When looking for ways to sign up I found out that I could not re-use my previous registered email for a new account. It gave an error.
However I found something odd in one of the logged requests in Burp Proxy; the request to https://portal.skge.nl/api/afas/nieuwe_aansluiting_zelfstandig has the following response:
What happens is that if someone uses a previously registered email address, it would spit out all the related PII data. Full address, email and phone. Mmm. That’s not how it should be.
The same happens for Medical License IDs (Bignummer), a number that is public data and you could easily look it up using a website from our government https://zoeken.bigregister.nl/zoeken/kenmerken
So if you were interested in the (often private) address and phone number of your healthcare provider this was an easy way to leak the details, no authentication required.
Time to report!
Conclusion
Authenticated attackers were able to download invoices from other users. Those document contained PII data like full address and bank account numbers. Unauthenticated attackers were able to leak PII data (full address, phone and email) whenever they had the medical license id number (public data) or email of the registered healthcare provider.
Discussion
SKGE was super responsive, within a few hours they reached out and pulled offline the affected parts of the website. A great example of how you should be responsive!
They audited their logs for abuse of the bugs and could confirm I was the only one who discovered the bugs.
Remember, everyone makes bugs; it’s the way you handle them that counts. Transparency is trust. As a I client I fully trust them and they confirmed to me my data is in safe hands with them.
After 2 days they patched the bugs and everything was online again.
In the end they supported my ethical research; trying to get healthcare vendors more secure. Thanks to them I’m able to share this story so we all could learn from it. This is an good example of strong leadership.
What about other firms in this industry, do they also have this level of transparency? If not, what is necessary for them to reach that maturity level?
Timeline
07–01–2024 — Discovered the IDOR bug that leaks invoices and PII data on signup
08–01–2024 — SKGE confirms the bug and instructs developer to deploy a fix
08–01–2024 — SKGE pulls offline the affected web asset
10–01–2024 — SKGE deployed a fix, I confirm the fix, SKGE finished its audit log (no abuse of the bug found)
18–01–2024 — SKGE sends 250 euro of gift cards and a letter of thanks
10–01–2024 — I wrote this write up and shared draft with SKGE
13–01–2024 — Received feedback from SKGE, improved the write up
19–01–2024 — Shared new draft of this write up
20–01–2024 — Write up published