Post Syndicated from Akshada Umesh Lalaye original https://aws.amazon.com/blogs/messaging-and-targeting/how-to-prevent-sms-pumping-when-using-amazon-pinpoint-or-sns/
SMS fraud is, unfortunately, a common issue that all senders of SMS encounter as they adopt SMS as a communication channel. This post defines the most common types of fraud and provides concrete guidance on how to mitigate or eliminate each of them.
Introduction to SMS Pumping:
SMS Pumping, also known as an SMS Flood attack, or Artificially Inflated Traffic (AIT), occurs when fraudsters exploit a phone number input field to acquire a one-time passcode (OTP), an app download link, or any other content via SMS. In cases where these input forms lack sufficient security measures, attackers can artificially increase the volume of SMS traffic, thereby exploiting vulnerabilities in your application. The perpetrators dispatch SMS messages to a selection of numbers under the jurisdiction of a particular mobile network operator (MNO), ultimately receiving a portion of the resulting revenue. It is essential to understand how to detect these attacks and prevent them.
Common Evidence of SMS Pumping:
- Dramatic Decrease in Conversion Rates: A common SMS use case is for identity verification through the use of One Time Passwords (OTP) but this could also be seen in other types of use cases where a clear and consistent conversion rate is seen. A drop in a normally stable conversion rate may be caused by an increase in volume that will never convert and can indicate an issue that requires investigation. Setting up an alert for anomalies in conversion rates is always a good practice.
- SMS Requests or Deliveries from Unknown Countries: If your application normally sends SMS to a defined set of countries and you begin to receive requests for a different country, then then this should be investigated.
- Spike in Outgoing Messages: A significant and sudden increase in outgoing messages could indicate an issue that requires investigation.
- Spike in Messages Sent to a Block of Adjacent Numbers: Fraudsters often deploy bots and programmatically loop through numbers in a sequence. You will probably notice an increase in messages to a group of nearby numbers frequently for example, +11111111110, +11111111111
How to Identify and Prevent SMS Pumping Attacks:
Now that we understand the common signs of SMS pumping, lets discuss how to use AWS Services to identify, confirm the fraud and how to place measures in place to prevent it in the first place.
Identify:
- Spike in Outgoing Messages and SMS requests to unknown countries: If you are using Amazon Simple Notification Service (SNS), in the SNS console, you can navigate to Mobile → Text Messaging(SMS) , Delivery statistics and Delivery statistics by country to understand the message requests. You can also check to see if there is any spike.
If you are using Amazon Pinpoint, you can use transactional messaging under analytics section to understand the SMS patterns
- Spikes in Messages Sent to a Block of Adjacent Numbers: If you are using SNS you can use CloudWatch logs to analyse the destination numbers.
You can use CloudWatch Insights query on below log groups
sns/<region>/<Accountnumber>/DirectPublishToPhoneNumber
sns/<region>/<Accountnumber>/DirectPublishToPhoneNumber/failure
The below query will print all the logs that have the destination number like +11111111111
fields @timestamp, @message, @logStream, @log
| filter delivery.destination like '+11111111111'
| limit 20
If you are using Amazon Pinpoint, you can enable event stream to analyse destination numbers.
If you have deployed Digital User Engagement Events Database Solution You can use the below sample Amazon Athena query which displays entries that have the destination number like +11111111111
SELECT * FROM "due_eventdb"."sms_success" where destination_phone_number like '%11111111111%'
SELECT * FROM "due_eventdb"."sms_failure" where destination_phone_number like '%11111111111%'
How to Prevent SMS Pumping:
- Geo Protection
- You can integrate your SMS API with AWS Web Application Firewall (WAF). With WAF you can set up rules to inspect the body and query parameters to allow only requests that your app expects.
-
-
- Example: If you expect only users from India to sign up in your application, you can include rules such as “\+91[0-9]{10}”, which allows only Indian numbers as input.
- Note: SNS and Pinpoint APIs are not natively integrated with WAF. However, you can connect your application to an Amazon API Gateway with which you can integrate with WAF.
- How to Create a Regex Pattern Set with WAF – The below Regex Pattern set will allow sending messages to Australia (+61) and India (+91) destination phone numbers
-
-
-
-
-
- Sign in to the AWS Management Console and navigate to AWS WAF console
- In the navigation pane, choose Regex pattern sets and then Create regex pattern set.
- Enter a name and description for the regex pattern set. You’ll use these to identify it when you want to use the set. For example, Allowed_SMS_Countries
- Select the Region where you want to store the regex pattern set
- In the Regular expressions text box, enter one regex pattern per line
- Review the settings for the regex pattern set, and choose Create regex pattern set
-
-
-
-
-
- Create a Web ACL with above Regex Pattern Set
-
- Sign in to the AWS Management Console and navigate to AWS WAF console
- In the navigation pane, choose Web ACLs and then Create web ACL
- Enter a Name, Description and CloudWatch metric name for Web ACL details
- Select Resource type as Regional resources
- Click Next
- Click on Add Rules > Add my own rules and rule groups
- Enter Rule name and select Regular rule
- Select Inspect > Body, Content type as JSON, JSON match scope as Values, Content to inspect as Full JSON content
- Select Match type as Matches pattern from regex pattern set and select the Regex pattern set as “Allowed_SMS_Countries” created above
- Select Action as Allow
- Click Add Rule
- Select Block for Default web ACL action for requests that don’t match any rules
- Set rule priority and Click Next
- Configure metrics and Click Next
- Review and Click Create web ACL
-
- Create a Web ACL with above Regex Pattern Set
-
For more information, please refer to WebACL
-
-
- Configure Amazon SNS SMS via API Gateway and Lambda to validate phone number and send SMS from SNS via Amazon API Gateway and AWS Lambda. You can also setup Pinpoint SMS via API Gateway and Lambda
- Associate the WebACL created above with the API Gateway stage
-
- Rate Limit Requests
- AWS WAF provides an option to rate limit per originating IP. You can define the maximum number of requests allowed in a five-minute period that satisfy the criteria you provide, before limiting the requests using the rule action setting
- CAPTCHA
- Implement CAPTCHA in your application request process to protect your application against common bot traffic
- Turn off “Shared Routes”
- Review this blog post and the use of the “SharedRoutesEnabled“ parameter within pools in the Pinpoint V2 SMS API
- Exponential Delay Verification Retries
- Implement a delay between multiple messages to the same phone number. This doesn’t completely eliminate but will help slow down the attack
- Set CloudWatch Alarm
- Configure an Amazon CloudWatch alarm to get notified if the SNS SMSMonthToDateSpentUSD or Pinpoint TextMessageMonthlySpend metric goes beyond a specific threshold
- Validate Phone Numbers – You can use the Pinpoint Phone number validate API to check the values for CountryCodeIso2, CountryCodeNumeric, and PhoneType prior to sending SMS and then only send SMS to countries that match your criteria
Sample API Response:
{
"NumberValidateResponse": {
"Carrier": "ExampleCorp Mobile",
"City": "Seattle",
"CleansedPhoneNumberE164": "+12065550142",
"CleansedPhoneNumberNational": "2065550142",
"Country": "United States",
"CountryCodeIso2": "US",
"CountryCodeNumeric": "1",
"OriginalPhoneNumber": "+12065550142",
"PhoneType": "MOBILE",
"PhoneTypeCode": 0,
"Timezone": "America/Los_Angeles",
"ZipCode": "98101"
}
}
Conclusion:
This post covers the basics of SMS pumping attacks, the different mechanisms that can be used to detect them, and some potential ways to solve for or mitigate them using services and features like Pinpoint Validate API and WAF.
here
here
here
https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-phone-number-as-subscriber.html
https://aws.amazon.com/pinpoint/
https://aws.amazon.com/sns/
https://aws.amazon.com/waf
https://aws.amazon.com/api-gateway/
https://aws.amazon.com/athena/
https://aws.amazon.com/lambda/
https://aws.amazon.com/solutions/implementations/digital-user-engagement-events-database/