tl;dr 🔗

Gjensidige Forsikring - one of Norway's biggest insurance companies - was leaking information about customers' cancelled insurances to other customers. First they used 3.5 months to falsely conclude there was no issue, and then one additional month to fix it. Also, their web site can be abused for sending e-mails.

Summary 🔗

Background 🔗

I have had some insurances with Gjensidige for quite some time. Luckily I haven't had much use for them, but from the little contact I have had I must say I'm a happy customer.

As my insurance company I'm logged in at their site from time to time. Back in May I also took a quick peek at their web site in regards of data security.

Approach (technical stuff) 🔗

When I was logged in I opened Vivaldi developer tools to inspect the pages and network traffic. There were quite a few Ajax calls in the different pages asking for data to display.

The missing authorization check 🔗

As should be,for most calls the browser didn't specify any customer ID or anything like that. Those calls were safe. They do, however, have some calls that include some sort of ID, which is specified on the client side. Most of them seemed to do a proper authorization check, but as shown in the cases presented on this blog, there sometimes are exceptions to this.

The REST endpoint giving back a list of cancelled insurances did not check if the ID sent in by the client. This ID seems to be an auto increment integer and I could just step one number to get another customer's cancelled insurances.

The Curl command copied from the browser looked like this:

curl 'https://www.gjensidige.no/ip-web/forsikringer/annullerte/<customer ID>' \
    -H 'x-klient-lokasjon: Meldingsboks' \
    -H 'Applikasjon: INTERNETT' \
    -H 'Accept-Language: nb-NO,nb;q=0.8,no;q=0.6,nn;q=0.4,en-US;q=0.2,en;q=0.2' \
    -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.97 Safari/537.36 Vivaldi/1.9.818.49' \
    -H 'Accept: application/json' \
    -H 'Referer: https://www.gjensidige.no/no/1/Din+side/forsikring/administrer-forsikringer/forsikringsdokumenter-new' \
    -H 'Accept-Encoding: gzip, deflate, sdch, br' \
    -H 'Cookie: JSESSIONID=<session cookie>; <a bunch of more cookies>;' \
    -H 'Connection: keep-alive' --compressed \
    | python -m json.tool

I added | python -m json.tool just to get a "pretty print" of the JSON returned to the command line.

Faking e-mails 🔗

I reported the authorization issue using an online form on their site. When I submitted I noticed that the POST request in fact included the name and e-mail address from the sender, and also the e-mail address to whom it should be sent to.

This, of course, got my attention. I saw that you could craft your own e-mails, choosing your own contents, topic, sender and receiver. I copied the Curl command from the browser and easily changed it to send a "fake" e-mail.

E-mail spoofing is nothing new, but there are a few interesting points here. There should be no reason why you would need the send and receiver addresses sent from the client. That's what makes it possible to forge e-mails in this case. Gjensidige uses Sender Policy Framework (SPF) for their domain, but that wouldn't help in this case as the server sending the e-mails should be whitelisted. However, the server used in this case is not whitelisted, and Gjensidige has the rule ~all set. That rule allows for any servers to send e-mails (with SOFTFAIL) from this domain. So, this again means that you don't really need Gjensidige's server to send spoofed e-mails from Gjensidige. So, maybe this is a feature and not a bug? I hope that they don't think this is all right.

Having this issue opens up for nice opportunities for phishing, or just abuse their server to send spam.

Security issues 🔗

The information leaked that I saw for cancelled insurances was this:

• Customer ID
• Insurance type
• Insurance number
• Price
• Start date
• Cancellation date
• Reason for cancellation:
  • Missing payments
  • Missing self-declaration
  • Need ceased
  • Insurance converted to other type
• Depending on insurance type there some extra information:
  • Full name and year of birth of customer
  • Full name and year of birth of child
  • Street address
  • Car type and plate number
  • Labour union membership

Some customers, if not most, have several types of insurances which would open for combining information about them. Now, I always minimize the amount of data I access to ensure no one can question my intentions, so I have to make an educated guess that there might even be other types of information on some customers.

Further more - and this is not fixed, so I'm not sure if they consider it a security issue - it's possible to use their own server to send fake e-mails from their own e-mail addresses.

Reception and handling 🔗

Day zero 🔗

It wasn't very easy to find the correct contact point, but the closest I got was a general contact form originally to be used for whistle-blowers. I submitted the form Friday night.

It was when submitting this form the first time that I noticed that - as described in more details in the "Approach" part - it was actually possible to use this form as a way to send e-mails from anyone to anyone through their site. So I submitted the form one more time telling them about that as well.

Day 3 🔗

Early Monday morning I got a confirmation that they had received information about the two issues and would inform the right persons. They also asked for me for a phone number where I could be reached.

I wrote back and told them my phone number. I don't think they ever tried to call me.

Day 80 🔗

Having not heard anything back and not seeing any fixes I asked them for a status.

Day 83 🔗

In the morning I got a reply telling me that they had "taken care of it" and named another guy who would contact me when he would be back from vacation.

At night I got copied in on an e-mail from that guy where he asked a third guy about giving me feedback.

A couple of minutes later the second guy told me that he knew they had taken this seriously and worked on the issue. I would be contacted by a third guy when he was back from vacation.

Day 111 🔗

I got a response from the Director of Group Security. He thanked me and quoted a security technician saying that the service in question would return an empty list if the logged in user wasn't authorized to get the list from the customer id it used for the request. The director also said that the reason it had taken me so long to get a reply was that they had gone thoroughly through all aspects of this issue.

Gjensidige used more than 3.5 months to "thoroughly" go through "all aspects" of the issue and falsely concluded that the issue was not an issue.

I wrote back and asked if I had misunderstood something and gave concrete examples of customer ids that actually would give data back.

Day 112 🔗

I got a reply back telling me that they had forwarded this information to the person responsibly for the security of gjensidige.no.

Day 125 🔗

I got more feedback telling me that they had confirmed that there was an issue and re-opened the case.

Day 148 🔗

I got a new e-mail telling me that they had fixed and closed the issue in production 9 days earlier.

Day 163 🔗

Writing this post I was surprised to see that the issue with e-mail spoofing remained. I had assumed they closed it earlier on. I sent a new e-mail asking about this.

Day 164 🔗

I got a reply telling that the second report with the e-mail spoofing was stopped before it reached Group Security and the IT department.

It actually Gjensidige 4.5 months to fix an information leak of this severity.

Conclusion 🔗

Gjensidige has been very polite and nice in their communication, and also grateful for getting the reports. I would have said their reception and handling was great, had it not been for my own and other customers' data were accessible for all of 4.5 months after the initial report.

While I understand that not everybody has the flexible server environments like Digipost or Skandiabanken, even using 4 weeks from the second report before fixing it in production isn't very impressive. This is an insurance company. They need to ensure that their customers' data is safe with them.