tl;dr 🔗

Iterating on an ID in a short URL sent via SMS made it possible to collect personal data and belonging shipment information.

Summary 🔗

Who:	Bring
Severity level:	Low to medium
Reported:	August 2020
Reception and handling:	Fair
Status:	Fixed
Reward:	Nothing at first, a thank you in the end
Issue:	Leak of personal information - perfect for phishing

Background 🔗

Bring is a part of the Norwegian postal service aimed at the business market.

I ordered a freezer from the consumer electronics retailer Elkjøp. Before delivery I got an SMS from Bring containing a link to the shipment information. The web address in the SMS immediately caught my attention. The address was so short that I knew that I would be able to iterate through shipments. And to my surprise the destination web page displayed personal data.

The shipment information 🔗

The SMS I got contained a link to the shipment information.


At first look the page didn't seem to contain anything special for my package. There was a zoomed out map and information about the delivery time.


Then I saw that there was a page with my name, address and phone number.


At last there was a page with the latest events on the package's trip.

The problem 🔗

The link with the shipment information was https://glow.bring.com/track/969986d2-3403-42ff-ae12-1c06868bb0f4. That address contains a long unique unguessable identifier. An identifier like that is normally considered an OK way of concealing that kind of personal data - at least if it's for a limited time.

The problem was the link in the text message. The link was https://s.bring.se/XRP3. This was the key to the castle. 🗝️ 🏰

Looking at the part XRP3 from the link I would guess that all addresses would be in the range [A-Z0-9]. Codes like XRP2, XRP1, XRP0, XRO9 etc. seemed to give valid redirects to other URLs containing personal data shipment information.

I only tested a few to get an idea if this was a problem or not. Not all codes I tested gave a result. I believe almost all of them gave a redirect to a UUID, but some of them gave a "page not found" message. I don't know how many persons were affected by this, or what time range we are talking about, but I did see past, present, and future deliveries.

Security issues 🔗

Using the short link sent in customer SMSes it was possible to iterate through and collect the following information:

• Full name
• Full address
• Phone number
• Sender's company name
• Information about the delivery:
  • Shipment number
  • Status
  • Dates
  • Waypoints

It was possible to enter a gate code that could be used when doing the delivery. Hopefully no codes were available. I didn't see any (in my very small dataset). Unfortunately I didn't test to enter any value on my own delivery. What I did see in the data returned by the backend API were keys/values like these: "lockCodeOrdered", "eventType": "lock-code-entered", "gateCode"

It's important to emphasize that this wasn't an issue harming all or most of Bring's customers or recipients. My understanding is that this issue applied to a subset of recipients of shipments sent using the platform called Glow - used within the service Bring Express. I have no idea of the volume here. It looks like it affected people in Norway 🇳🇴, Denmark 🇩🇰, Sweden 🇸🇪 and Finland 🇫🇮.

Reception and handling 🔗

Day zero 🔗

Wow, either I can't spell and/or read or that was a bad tip I got from @bringnorge. pic.twitter.com/DBU9gIhdbe

— Roy Solberg (@roysolberg) August 12, 2020

As seen so many times it was really hard to find somewhere to report a security issue. Bring did not have security.txt, there was no response on Twitter, and their chat bot certainly was of no help. When I got in touch with a real human being I got a non-existing email address. The customer service had mixed up .no and .com.

Day 2 🔗

Two days later I got a response from a customer advisor asking if this was a real shipment meant for me. I confirmed that one of the shipments was indeed for me.

I got a reply telling me that I was supposed to get all this personal information. So everything was fine. I replied begging that the customer advisor would forward the email to someone who was responsible for IT security or the IT department itself. They would understand.

I never heard back from the customer advisor. I had no clue what happened.

Day 21 🔗

Luckily - when I was a bit upset by their customer advisor on the third day - they gave me a questionnaire asking how I much I enjoyed their service. I replied that it was impossible to report a security issue. Someone had actually read the questionnaire and acted on the information I gave. I got an email asking for information about the issue I had found.

I forwarded the email thread I had with their customer service. I got a reply that they had looked into it and the customer advisor had actually forwarded my email on the third day, and they had fixed the issue. I was also told that they would send a notification to the IT security department and Data Protection Officer (DPO). They would also use the case internally for educational and improvement purposes. 👏

How this security issue could be exploited 🔗

There were maybe especially two ways to misuse this information leak:

• Collecting personal data over time
• Make a great spear phishing attack

Bonus tip for developers 🔗

Very often I see that Google has indexed pages that contains personal information. I want to do a post on Google dorking, but every time I do some test searches I find security vulnerabilities and information leaks and that makes me postpone it. Luckily I couldn't see any personal information indexed by Google in this case, but my guess is that that is more of a coincident, because doing a search like https://www.google.com/search?q=site:bring.com+inurl:track&filter=0 shows that Google has been indexing pages that GoogleBot has come across in one way or another. As a developer you need to remember to Google your sites, and ensure to exclude the right paths in robots.txt + add the HTTP response header X-Robots-Tag: noindex (or meta tag <meta name="robots" content="noindex">).

Conclusion 🔗

Developers: Please think it through if you are making some sort of shortcut to personal data. Or if you are changing a page to now include personal data: Are there existing shortcuts to the URLs? And is it really necessary to have the personal data on that page in the first place?

Companies: Please train customer service to handle someone reporting a security issue. And please offer some information on where and how to report an issue.

All of us: Be aware when you get that phone, SMS or email regarding some shipment supposedly on the way. Are links going to legitimate domains? Are they asking for personal information? Are they asking for money? Is the grammar and spelling correct?