This report was fully disclosed on 19 August 2020
Due to the lack of rate limiting or captcha on a specific end-point it is possible for an unauthenticated attacker to send a large number of SMS text messages to a phone number of their choosing.
This allows a remote unauthenticated attacker to abuse the service and perform “SMS Flooding”, resulting in the target receiving hundreds or thousands of SMS text messages per minute.
About Text Logistics: “Text Logistics provides easy to use tools to help you connect with your customers and promote retention while gaining valuable insight and information. We provide text marketing, appointment reminders, click-to-call service and instant group text alerts.”
Proof of Concept
First we must craft a request to the vulnerable end-point. The request body is as follows.
GET /clients/smsAPI.asp?do=requestInfo&phoneNumber=16475551337&list=mobile&calledID=17084062165 HTTP/1.1 Host: www.textlogistics.com User-Agent: Hacker 7.23 Connection: close
In this case we used a phone number provided by our friends at Twilio as our target for testing.
Once we have crafted this request, we can use Burp intruder to repeat the request a desired number of times. To do this we can append
&req=§0§ to the
GET request and create a payload list of a numerical sequence of 100.
We use throttling to limit the requests to 50ms each as leaving this unset resulted in some requests erroring out.
As shown in the following screenshot sms messages were received by the target.
At 2:57 AM on 25 Feburary, Twitter user
@scottbix posted a video of his phone being flooded with messages from various platforms, including but not limited to BAS Health which uses textlogistics. Based on this example we can determine with a high degree of certainty that this vulnerability is actively being exploited for malicious purposes.
- Implement captcha and other rate limiting controls to prevent abuse.
- Discontinue unused end-points
- Implement security and bug reporting information such as a security.txt file so security researchers can more easily report findings in the future.
- Perform a full penetration test of the web platform and API to identify further issues.
Response From Affected Party
At the time of publishing no response has been received.
- 26 February 2020: Affected Party Notified
- 19 August 2020: Report Published (+175 days)