tl;dr 🔗

Digipost - one of two "digital mailboxes" in Norway where you can get mail from public authorities - leaked users' full real name, IP addresses and login timestamps.

Summary 🔗

Background 🔗

In Norway we have two official suppliers for a "digital mailbox" where Norwegian public agencies can send you letters and documents. It's considered a more secure way than regular mail for delivering important letters and documents. The mailboxes have been pushed pretty hard the last couple of years, ensuring that as many as possible will sign up for it.

I've personally used Digipost for quite a few years now. I think it's a great service for receiving important documents. One day I was wondering if my information and documents were safe with them.

Approach (technical stuff) 🔗

HATEOAS 🔗

Earlier on I used to attend the very good Java conference JavaZone every year. Five years ago I was at a talk from a couple of consultants working with Digipost, called Hypermediadrevet API i praksis (Hypermedia driven API in practice). It was an inspiring talk which made me make at least the next REST API hypermedia driven.

Little did I know that I would use this "Hypermedia as the Engine of Application State" (HATEOAS) to an advantage when looking for security issues at the same site years later. Simply explained, the HATEOAS makes REST APIs more self-documenting and easier to browse through using the links provided.

Browser developer tools 🔗

I logged in to Digipost having Chrome DevTools open to see what was going on. I opened one or more of the REST URLs in a different tab. Having a JSON viewer browser extension like JSON Formatter (that hopefully doesn't ship everything it sees to a third party server) makes looking at JSON a pleasure. The API being hypermedia driven meant that you get instant linkification and can browse through the data quickly.

Digipost seemingly uses an auto increment integer as ID for the user, making it easy to check if your data is secured against the access of others. (Remind me to write a post about the pros and cons against IDs like that (and no, security by obscurity does not make your data safe)). I changed a few IDs here and there and mostly got different kinds of error messages thrown back at me. However, I quickly found two URLs that didn't seem to have a proper authorization check.

Security issue 🔗

Two URLs without proper authorization checks was found.

The first URL apparently returned the number of unpaid invoices you have. Not something you would care about if someone accessed.

The second one was the alarming one for me. It returned the account activities for the past 30 days. The data had the following elements:

• Date of activity
• Full name of the person performing the activity
• Type of activity (e.g. level of authorization and authentication method)
• IP address of client
• The role of the person

What's the big deal about this? 🔗

The information exposed isn't sensitive, so why should you care? Well, I think there are two important points here.

The first point is that a service like this - promoted and pushed by the government - should have zero tolerance on any kind of information leak. As system developers we make mistakes all the time. Every week we go to work and create new bugs. Hopefully they aren't security related, but sometimes they are. When working with services like this it's so incredibly important to have proper methods and routines to minimize the chance that this can't happen.

The second point is that I think the combination of a full real name and a fresh IP address is unfortunate. It doesn't really matter for me, and probably not for you, but what about public figures or persons with unlisted addresses?

Reception and handling 🔗

Day zero 🔗

At night I sent an e-mail to the customer service.

Day 2 🔗

Less than 48 hours afterwards I got an e-mail apologizing that I didn't receive an answer before and telling that they had fixed the issue and were going to deploy it the same day.

Day X 🔗

I received a reward of some gift cards which I appreciated, but what might've impressed me the most was that the chief of security actually took the time to add hand written thank you note.

I think the issue in question was handled very well. Digipost responded quickly, fixed it quickly, and communicated in a clear and professional way. Even when reaching out telling about this post they responded in the same manner.

Conclusion 🔗

It's important to underline that I never got access to any documents, communication or any information regarded as sensitive. But for me this is a type of service that should have the same level of security as a bank. There just shouldn't be any information leaks. I truly believe that the information leaked could've be used for bad purposes.