The hidden risks of public SMS services - How your messages are being exposed

I recently needed to register on an web application, but I didn’t want to provide my real phone number, so I used a temporary phone number to receive a validation SMS. To achieve this, I took a look at those websites proposing free phone numbers to receive SMSs, visible by anyone: this is what I call Public SMS Services (PSSs). The reason I decided to investigate PSSs is that their content may be useful from both a Cyber-Threat Intelligence (CTI) and Open-Source Intelligence (OSINT) perspective, and even Offensive Security (OffSec).

Plan

• Introduction
• Automation
• Results
• Conclusion

Introduction

A really quick word about existing reasearch on this topic : the only source I could find is from the Canadian ZATAZ that published a short post about Public SMS Services.

What are Public SMS Services?

While browsing the Internet, you probably searched for a temporary email address at least once. For example, you created a user account on some web app, and you didn’t want to provide real information. In the same way, you may need a temporary phone number if the app requires it: in this case, you probably used a virtual phone number, which allows you to receive a confirmation SMS or so, in order to validate your registration on the concerned web app. Although this use case is quite simple, let’s give a proper definition of what I call SMS services.

A SMS Service is an online service that provides virtual phone numbers to their customers in order to receive SMSs. If a service provides additional services, such as VoIP, it will still be considered a SMS Service.

There are plenty of such services out there. Using any simple online research such as receive sms online using your favorite search engine will lead you to multiple websites.

An example

Let’s take an example real quick and have a look at https://smstome.com. Just select a phone number : congratulation, you can read all messages received.

If you want to do some testing, simply try to register on a web app that requires a phone number, and check if you receive a verification SMS. Actually it might not work, because after some time, those phone numbers are considered malicious or suspicious by carriers and applications. To ensure the service is still available, SMS service providers simply retire old phone numbers and replace them with new ones.

You may notice that some messages seem truncated, and they actually are. I don’t know why, but this is a common issue shared by many SMS services, which maybe need to optimize their data storage, especially for free services.

Security issue

When looking at these services, we can see that some are billed, others are free. There are two main differences between the two :

• Privacy - For users looking for privacy, free services are prefered because they don't require users to create an account, while paid services require to do so i.e. require users to provide personal information.

• Access control - When subscribing to a paid service, virtual phone numbers are private i.e. a user can have multiple virtual phone numbers, but a virtual phone number can be owned only by one user. However with free services there is no form of access control, and virtual phone numbers can be shared, so are SMSs.

Obviously, the only thing we can exploit here is free SMS services, that I will now call Public SMS Services (PSS), which is not an official term.

A Public SMS Service (PSS) is a SMS Service that do not provide any access control mechanism, and allows multiple users to share the same virtual phone numbers, and thus allows users to read each other messages.

Here is a quick summary of the different SMS Services categories.

Before digging those services, here is a scheme representing our study scope. As you can see, I only studied SMS received on https://receive-smss.com/, which is a public and free SMS service. I decided to focus only this data source because it was pretty simple to automate data collection, but also because this web sites received a lot of messages.

Exploiting the security issue

You may wonder why would anyone spend their time reading strangers SMS. Well, let me give an example: while refreshing a “received messages” web page on a PSS to see the message I was waiting for, I took a look at already received messages, and one of them was something like the following: Hi redacted@gmail.com, your new access code is 458953. You can now connect on https://REDACTED.com..

Since I couldn’t believe it, I quickly configured an anonymization pipeline and accessed the account. The website was a cryptocurrency application that allowed users to access their different wallets. I had access to personal information and to a significative amount of 65 Bitcoins.

Besides the message received that represented itself a flaw, I had three hypothesis in mind:

1. This is a human mistake – The person owning the account used a Public SMS Service ignoring what the consequences could be.
2. This is a development environment – In this case, the account is not a real one, or at least this is a test account, with mocking data.
3. This is some kind of aggressive honeypot – Since the message is received on an PSS, and that it leaks the three key information needed to access the account (website, username and password), it seemed too obvious not to be a honeypot.

In the end, the domain was created three months ago, and all features were not implemented yet, so it probably was a development environment.

Altough this is a quite simple use case, let’s define some kind of attack model. We have two major use cases which are SMSs without URL, and SMSs with URL.

Case 1 - SMS without URL

In this first case, User A gets a virtual phone number from a PSS, they use this phone number to register on a web application that will store all user-related data into its database. At some point, the application will be triggered to send a SMS, for instance to invite the user to come back to the app : Hey John DOE, you have a new offer on your house located at Av. de Cointe 5, 4000 Liège, Belgium!. The SMS will be sent to the phone number associated to User A and thus sent to the PSS.

Now, if a malicious User B spends their time watching SMSs on the PSS, they could read PII, which is the equivalent of an indirect read access to the application database. Alternatively, the SMS may also contain some PIN or password that can be used to authenticate on an app with the phone number as a user ID. In this case, User B could compromise the account, and have an indirect read/write access to User A information.

Case 2 - SMS with URL

In this second case, User A gets a virtual phone number from a PSS, they use this phone number to register on a web application that will store all user-related data into its database. At some point, the application will be triggered to send a SMS, for example Hey John DOE, you have a new match, send them a message : https://findamatch.com/messages?token=eyf652s4fz6e621sdf65z4szdfzrgzd62x1fz6ver5g1. The SMS will be sent to the phone number associated to User A and thus sent to the PSS.

Now, if a malicious User B spends their time to watch SMSs on the PSS, they could navigate to the URL, and either reset a password, or directly compromise User A account, and have an indirect read/write access to User A information.

Regulatory compliance

GDPR

If you see a message containing personal information, this may not be GDPR compliant because of the Article 32 that says the following.

[…] the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

• (a) the pseudonymisation and encryption of personal data;
• (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
• (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
• (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing. </i>

From the PSS point of view, data is simply received and displayed as is. We can compare it to a forum where users can post anything they want, but here users are actually senders. From the senders point of view, the end user is supposed to provide real information. Based on that assumption, the sender will trust the provided phone number and assume it is private. Finally, the end user is informed that a real information is expected, and that PSS will publish SMS associated to the app. The problem is that the end user doesn’t know when SMS will be sent (except for password reset and verification), and what the content will be.

Electronic Communications Privacy Act

A few insights

In order to get some information about the interest in PSSs, we can use any trend analysis tool. Here are my results for keywords free sms online on https://semrush.com. We can see in the bottom right corner that these keywords belong to a cluster where users seem to look for test or verification phone number. This already give insight about data we will find. Additionally, we can take a specific domain to analyze its traffic and see how it is used, which may be useful in order to select a high traffic PSS for analysis.

After a few week of SMS collection on https://receive-smss.com/, we can observe that the number of messages received on a hourly basis approaches 2000 SMS/h.

Then, we can observe how phone numbers are used based on their countries. This is only an approximation because phone are periodically retired and replaced by new ones, not necessarily from the same country. What we can see on the following chart is the number of message receive for each country.
Then, if we divide this total by the number of phones belonging to that country, we get the mean number of messages received by phone by country, which is in other terms how frequently a phone will receive messages. We can see that Indian phone numbers are the most active with 47801 total messages received on the 7 last days, with only two phone numbers available, while UK received 82937 with 14 phone numbers available.

Besides the amount of received message, the most valuable type of SMS are the ones that contain URL. The following chart shows the number of message containing URLs received per hour, which approches 49 SMS/h, which which is 2.45% of the total 2000 SMS/h. Alternatively, if we take a look at the total of messages received over the last 14 days, this is approx. 2.49% of messages containing URLs. But don’t be fooled, this doesn’t mean that 2.49% of messages received are interesting : actually most messages containg URL are spams, ads, or are incomplete messages. That’s why we need AUTOMATION!

Automation

Why?

My primary need was to collect data and store it in a database, becauses the source data source I rely on only provides the last 40 SMS received. Then, I needed to develop a searching feature that would allow to identify interesting patterns e.g. messages with PII. Finally, once patterns are identified, a last feature was needed to exploit them.

How?

First approach

I developed a first very basic version of the solution. It parses https://receive-smss.com/ and stores any unique SMS identified. After a few hours spent collecting SMSs, I was excited to analyze the data, and I quickly figured out that there were two interesting cases.

• The first one is when messages directly contain sensitive data, like credentials or PII. However, this is a very rare case, and it is complex to automate without false positive, and I didn’t want to deal with false positive at this point.
• The second one is when messages contain URLs. This is a much more frequent case, and it represents a huge part of interesting messages. Why? Because anything can hide behind a URL, a scam or an account compromise.

I abandoned the first case and focused on messages that contain URLs.

Improvements

To make the analysis a bit simpler, I developed a web interface where I can look for messages collected, and easily navigate to URLs. Thanks to this tiny improvement, I built a list of all URLs and I manually navigated to each one of them, and some of them simply gave me access to user accounts. Thus, I decided to develop the last core feature: the aggressive mode. This can be turned on to navigate to URLs known to hide interesting data, then it will add this data to the database!

However, I faced a challenge that is still not resolved: race conditions. Some URLs, such as password reset URLs, have either an expiration date, or can be accessed only once to prevent someone else to reset a password a second time. I decided not to focus on that problem for now, because there are a lot of URLs to explore.

Architecture

The whole architecture is made of Docker containers. The entry point from the user perspective is the Flask web server. Its role is to render and serve web pages, and to enqueue different jobs in a Redis queue:

• A job that will initialize various things
• A job that will collect messages (infinite loop)
• A job that will collect data, only in aggressive mode (infinite loop)

These jobs will be executed by two workers. Finally, we have a database with SMSs, targets, configuration, and so on.

Latest release

Aggressive mode is great to collect data, but the issue is that each domain must be parsed differently to retrieve data. To resolve this, I created a parent class named DataModule with several generic methods that will used by different children classes.

Let me explain a practical example: in multiple cases, data can be retrieved simply by reading the Location header of a HTTP 302 Redirect, which directly contains data. Thus, I wrote a method for the DataModule class named _retrieve_data_redirect() that simply return data found in the location header. Now, when I want to add a new parser for a given domain, I simply need to call this method, which makes the parser very simple to implement c.f. complete class for REDACTED parser below.

class REDACTED(DataModule):
    def __init__(self):
        name        = 'REDACTED'
        base_url    = 'https://nps.REDACTED.in/'
        super().__init__(name, base_url)
    
    def retrieve_data(self, url, msg):
        return self._retrieve_data_redirect(url)

Limitations

SMSs sources

As previously mentioned, the only SMS source is https://receive-smss.com/. At some point, additional SMS sources may be needed for this tool to handle more data. I didn’t plan to work on that yet.

Data collection

Again, as mentioned before, data collection is limited in multiple ways :

• Race conditions, which happens to be a problem when the URL expires, or when the URL can be accessed only once.
• Requests rate limiting, which causes the targeted server to return a HTTP 429 Too Many Requests and prevents us to parse additional data for a few seconds or minutes.
• Other security controls, that may be related to users agents, locations, and so on.
• Sometimes, URLs can be accessed only from the corresponding mobile application. In some cases, the HTTP response prevents access and does not provide any useful data. In some other cases, this behavior may be bypassed by changing the user agent.

Results

Now is the time to finally talk about cybersecurity, OSINT, CTI, and OffSec! This section describes the different use cases I encountered while analyzing hundreds of thousands of SMS. For each use case, I tried to dig as deeper as I could to provide a real world impact analysis.

Also, from an attacker perspective, all the presented results are opportunistic, which means the attacker is not able to choose its target and entirely relies on which account or data URLs may redirect to.

Use cases

The following table shows the different use cases encountered.

Password reset URLs

This use case is very simple and common: the message received contains a password reset URL as shown below.

You can reset your password by clicking on this link: https://pprod.mycompany.com/account?reset-token=RANDOM_GUID

Bypass access control

This scenario is even simpler, and simply gives access as an authenticated user when clicking on the URL. For example:

Click here to access your account : https://shrtn.com/0123456789abcdefgh

Data exposure

While this scenario is not as critical as the previous ones, it gives the opportuniy to collect various types of data, base on the concerned application business.

Click here to check your analysis results : https://shrtn.com/0123456789abcdefgh

Data discovery

This scenario is very rare and not very sensitive. The only example is the enumeration of subdomains, where the URL is not accessible i.e. does not lead to account compromise from the public Internet. For example :

Hello admin, click on the URL to reset your password : https://internal.and.sensitive.domain.com/0123456789abcdefgh

Scams

Among all messages, many are scams that look like this.

Your shipment could not be delivered because the transport fee was not paid. Click here to pay.

Missed opportunities

Missed opportunities are almost exclusively use cases where the whole URL can’t be read, because it is too long. For example :

Hi, how are you? Did you ask for a password reset? Here is your URL, don’t share it! https://superlongandweirddomainnamerightquestionmark.com/?reset=A

Statistics

Statictics must be added.

Real world examples

Venmo

According to Wikipedia, Venmo is an american company owned by PayPal with approximately 70 millions users in 2021. This is some sort of banking application that allows users to send payment to their friends and to manage their business revenues, which makes it a sensitive business application. There is only one message pattern sent from Venmo to its users, and it looks like this.

Reset your Venmo password: https://venmo.com/account/password-new?utm_medium=phone&reset_key=40b11eeecc001f5a6d2cc4f40eae408c7bc953f11478eb028032c4f86

When navigating to the URL, no other information than just setting a password. In this case, an attacker could reset the password and then what?

Impact

Well, as you can see on the picture, the phone number can be used as the identifier to login into the application.

This scenario typically involves a race condition for the attacker to compromise the account, because the link may expire, and because the legitimate user may reset their password before the attacker does. Also, when the link expires, it is still possible to navigate to the URL and set up a password. Obviously this won’t work, but it is a waste of time from an attacker perspective.

Responsible disclosure

02/05/2024 - Issue reported.

Back to the table ⬆️

Instagram

Instagram is very similar to Venmo, which seems very exciting at first glance. I detected this simply because there were a lot of Instagram shorten URLs e.g. https://ig.me/0123456789abcdef. This kind of URL is not necessarily sensitive and may for instance redirect to a simple public picture hosted on https://instagram.com/. You can use a simple Google dork like site:ig.me to get shorten URLs and get redirected to any kind of Instagram content.

About Instagram SMS collected, navigating to those URLs would redirect to an Instagram error page displaying something like The URL has expired. I needed to dig deeper, created an Instagram account, and triggered a password reset procedure using a temporary phone number. Then, I was able to confirm that these URLs would allow an opportunistic account compromise. The text messages received look like these.

• Tap to reset your Instagram password: https://ig.me/1ZZOeHuLUwa4Ttq
• Instagram link: https://ig.me/r6LPOYK87HRyT73. Don't share it.

When navigating to those URLs, and based on the message pattern received, we are redirected to different web pages.

Redirection - First case

In the first case, we can just skip the password reset and be logged in as the user i.e. the URL gives direct access to the account. I actually rarely saw this behavior and I have no screenshot for now.

Redirection - Second case

In the second case, we must complete the password reset procedure, and then authenticate to the account with the phone number and password just set.

Redirection - Third case

In the third case, the account is locked, but we can still retrieve the username, either by analysing source code or by clicking on the top right menu icon. This may be used for OSINT and CTI.

Redirection - Fourth case

In the fourth case, the URL has expired or was used.

Impact

A common intuition would be that one Instagram account is associated with one phone number. Thus, if a Public SMS Service provides a hundred phone numbers, an attacker could only compromise a maximum of a hundred user accounts. Actually, this is wrong. I observed that for a given phone number, multiple Instagram password reset URLs were received, leading to different user accounts. This seemed irrelevant to me. After some testing, I observed that it is not possible to register a new Instagram account with a phone number when the phone number is already used by an existing account. However, it is possible to edit the contact information to add a phone number.

Imagine that Instagram has a user jdoe@email.com registered with +4591457271. If this user triggers a password reset, a text message will be received on the Public SMS Service hosting this phone number, and the account could be stolen. Now, imagine that a new user creates a new account with an email address leoagata@proton.me, and then edit their contact information and set their phone number to +4591457271. The immediate consequence is that this phone number will be removed from jdoe@email.com account. Now, if leoagata@proton.me triggers a password reset, a text message will be received on the Public SMS Service hosting this phone number. This means that we can receive multiple passwords reset URLs from different user accounts on the same phone number. The following example shows two SMSs received in a 10 min timeframe, with two different URLs leading to two different user accounts, received on the same phone number.

In the end, it is not possible to create an Instagram account with those virtual phone number, because all of them are already used. This makes Instagram account compromise possible in a very specific case where a user edits its information to provide one of those virtual phone numbers, then triggers a password reset. This would probably lead to testing accounts compromise only.

Responsible disclosure

When reporting this behavior to Instagram, I was told that Instagram won’t do anything about those phone numbers, although it would be very simple to implement a blacklist feature in my opinion.

Back to the table ⬆️

Biedronka

According to Wikipedia, Biedronka is the largest chain of discount shops in Poland, with 70,000 employees and a nice 11B€ revenue in 2019. Messages received from Biedronka look like this.

• Link do zmiany hasła https://bdr.page.link/S8CpNMGEgdUjL41B6 ważny 5 minut

Yes this is Polish, and it means Link to change password https://bdr.page.link/S8CpNMGEgdUjL41B6 valid 5 minutes. If you’re not familiar with page.link, this is a Google Firebase feature that was designed a few years ago to set up easy to share URLs that handle redirections (see Google documentation for more details).

Anyways, navigating to the URL would lead this page, inviting user to reset their password, and of course we are able to login with the phone number and password we just set.

Another way to compromise a user account is simply to download the mobile app, and enter the targeted public virtual phone number. Then a message is received on the Public SMS Service hosting that virtual phone number, providing a code. Based on the phone number country e.g. German phone number, the SMS showned on the picture may be cropped, and the last digit must be “bruteforced”, which is possible since the number of tries seems to be unlimited.

Finally, I took a look at the application and analysed its HTTP traffic to see if the 6 digit code could be bruteforced, and luckily it can’t be bruteforced in a reliable.

Impact

When connecting to a user account, there is not much to do. Of course it discloses email address when fullfilled, and maybe credit card information since Biedronka works with a partner called BLIK, but I didn’t investigate this.

Responsible disclosure

TODO

Back to the table ⬆️

Job Logic

JobLogic is an Enterprise Resource Management SaaS application that provides many different services such as payment integration, jobs management, planning, and so on. Here is the message received : “Your Job has been completed Please follow the link for details https://staging-portal.joblogic.com/Portal?id=GUID.”

Navigating to this URL directly provides access to a portal, authenticated as a user. As you noticed, this is a staging environment, which means that no real data should be found.

Impact

Responsible disclosure

12/04/2023 - Issue reported Back to the table ⬆️

Free ads

Free Ads is a UK application that allows user to publish ads to sell whatever they want, for free. The service proposes a paid version for users who want their ad to have more visibility. The message received looks like this:

• Hi REDACTED, you have a new message, click to go to your messages >> https://go.freeads.co.uk/REDACTED.

This URL redirects to https://my.freeads.co.uk/messages/list/all?c=REDACTED%3D%3D&utm_source=message_reminder&utm_medium=sms&utm_campaign=message and sets a cookie session that allows to be authenticated as a user. Unlike most of these URLs, this one does not expires!

Impact

This URL gives full access to the user account, and enables an attacker to read/write personal information. As far as I can tell, credit card information is not stored by FreeAds since a premium account is a one time payment.

Responsible disclosure

12/04/2023 - Issue reported

Back to the table ⬆️

AirIndia

According to Wikipedia, AirIndia is the second-largest airline in India in terms of passengers carried, after IndiGo, as of July 2023. The text message received for Air India was the following.

• Thank you for flying with us. Please take a few moments to share your thoughts. To rate your experience, click: https://nps.airindia.in/rEDaCt3d -Air.

When navigating to the URL, we are redirected to Qualtrics, a SaaS solution to create various things, including surveys. In order for me to understand how it works, I created a test survey available here that reads a URL parameter Name and display its value in the first question. Example with a survey for Molx, or for Bender.

With AirIndia, the issue is that all surveys include very sensitive data, including PII and also the PNR unique identifier. Or course I double checked this data using services like https://flightstats.com/, and all of it was real!

The following table shows all information disclosed by AirIndia as URL parameters.

If you ever travelled by plane, you may understand what an attacker could do right? Here is the answer.

Impact

So an attacker can connect to the check-in web page, but what does this mean?

• Situation 1 - If the flight is in a few weeks or month, travellers are not allowed to check-in. In this situation, an attacker can’t do anything except get the list of flights related to the PNR.
• Situation 2 - If the traveller can check-in, well, an attacker could check-in.
• Situation 3 - If the traveller already checked-in, an attacker would have access to a boarding pass that provides additional information such as a Passport number or a VISA number, and can still modify information on the boarding pass.

A curious thing is that the survey is meant to get get a feedback about reservation, check-in, in-flight meal, arrival and exit, but it seems to be sent immediately after tickets are bought i.e. before the flight date.

Responsible disclosure

15/04/2023 - Issue reported

Back to the table ⬆️

e.lilly

According to Wikipedia, Eli Lilly and Company is an American pharmaceutical company headquartered in Indianapolis, Indiana, with offices in 18 countries. Its products are sold in approximately 125 countries. People who sign up on https://zepbound.lilly.com need to register a phone number. Then, the following messages are sent.

First URL By navigating to the first URL (1/2), I was redirected to the following web page, allowing to access personal information such as : email address, first name, last name, signature (by accessing the signed HIPAA document).

By navigating to the second URL (2/2), I was redirected to a web page allowing me to download my wallet on Apple Wallet or Google Pay. I connected to my Google account and saved the savings card.

Impact

PII disclosure.

Responsible disclosure

16/07/2024 - Issue reported 04/09/2024 - Evaluated as not applicable

Back to the table ⬆️

Texts from my ex

A funny name right? The concept is also funny : this is a SaaS app where users upload a part of their conversation (WhatsApp, Messenger and so on) with their crush or ex, and an AI evaluates how compatible the two persons are. Unfortunately, I got rid of the message, so I can’t tell how it looks like, but I have a URL example :

• https://textsfrommyex.com/analysis/65bdREDACTED3655

Impact

The impact entirely relies on the messages content. In the following example, the only sensitive infomation are first and last names. However, since this ‘report’ quotes the conversation, any sensitive information in that conversation could be present.

Responsible disclosure

Not reported.

Back to the table ⬆️

Stickermule

Stickermule is a website where sticker can be bought. The message received looks like this.

• Items from Sticker Mule order R236623233 shipped! http://stickermule.com/orders/R236623233?token=REDACTED

Impact

When navigating to the URL, an attacker can access shipment information i.e. first name, last name and physical address and the list of stickers bought. Thus, the user account is not compromised.

Responsible disclosure

01/05/2023 - Issue reported

Back to the table ⬆️

Abinitio solutions

In the context of the received message, Abinitio solutions is a subcontractor of the Spanish Naturgy Iberia energy provider. In the following message, the user is required to pay their bills.

• ABINITIO INFORMA REDACTED Pulse https://abinitio-solutions.com/n.php?p=RUIzNlREDACTED para el abono de sus facturas con NATURGY IBERIA

When navigating to the URL we have a bill detail with the customer personal information i.e. first name, last name and address.

When navigating to the provided URL, we are redirected to a payment page.

Impact

PII disclosure.

Responsible disclosure

TODO

Back to the table ⬆️

Communidad madrid

This is one of the few cases where I could discover data about the target itself. The message received looked like this.

• Codigo de activacion para Y5****67J: 746656. Valide su identidad y confirme su codigo en: https://registroidentifica.val.communidad.madrid/#/activacion
• Codigo de activacion para 71****17M: 340352. Valide su identidad y confirme su codigo en: https://intranet.val.communidad.madrid/#/activacion

This gives the opportunity to discover additional scope about the communidad.madrid domain.

Impact

Subdomain discovery.

Responsible disclosure

Not reported.

Back to the table ⬆️

UPS Scam

Not many things to say about this : this is a typical scam reproducing the UPS website, hosted at https://zpr.io/NDcExv3zuFmX.

Impact

N/A

Responsible disclosure

N/A

Back to the table ⬆️

Payfone

This is a missed opportunity because the URL is truncated. The URL looked like this :

• https://device.staging.payfone.com:4443/fortified/2015/06/01/continueAuth?vfp=some-truncated-random-string

Impact

N/A

Responsible disclosure

N/A

Back to the table ⬆️

Validahealth

This is a missed opportunity because the URL is truncated. The message looked like this :

• Here you can find an access code for Valida Health. Code : 4203, link to the confirmation page : https://validahealth.io/myresults/confirm/230649ae-3918

Impact

N/A

Responsible disclosure

N/A

Back to the table ⬆️

Experian

This is a missed opportunity because the URL is truncated. The URL looked like this :

• https://usa.experian.com/registration/v?r=some-random-string

Impact

N/A

Responsible disclosure

N/A

Back to the table ⬆️

Conclusion

Based on the sample of results we saw, there are two main outcomes I would like to highlight.

First, by assuming that phone numbers are private, companies allow themselves to send sensitive information by SMS e.g. URL to access a user account. Of course password reset is a specific case that requires the phone number to be trusted, but this is quite difficult to exploit because of race conditions and additional limit rate protection that can be set up (c.f. the Instagram case). Otherwise, companies may set up a blacklisting system to prevent users to register with PSS phone numbers : this is quite easy to implement.

Second, when registering on an application with a PSS phone number, we have no way to know what SMS will be sent. Thus, I would recommend the use of such phone number for testing purposes, and to avoid associating real data to whatever account was created with the phone number.

Thanks for reading