OTP/SMS Flood Attack
(Budget Exhaustion Attack)
Protect your 2FA budget against SMS flooding attacks
Overview
We work with phone numbers. We send one-time PINs (OTP) through SMS, voice, etc. to phone numbers so users can recite the OTP back to us as proof that they have access to/own the phone, which is a form of 2-Factor Authentication (2FA).
We offer this service through an API to companies that need phone verification and 2FA. They need it for various purposes ranging from:
- Protecting signups against bots and Sybil attacks
- Offering password-less login
- Enhancing security for critical user transactions (transferring money, purchasing stock, etc.)
- Qualifying sales lead
- Etc.
Each phone verification attempt incurs cost as it involves sending a OTP through short message (SMS) or voice. Attackers can rack up phone verification bill by requesting for OTPs with no intention of use. We term this as a resource exhaustion attack.
There are many types of resource exhaustion attacks, and in this article, we will look at:
- High consumer OTP
- Random OTP
- Serial killer OTP
And also 2 variations of 'Serial Killer OTP'
- Unruly Serial Killer OTP
- Twister Serial Killer OTP
We analyze these attacks to understand them from the perspective of both an attacker and the defender.
For attack, the goals are:
- Minimize the preparation in terms of code and research required
- Minimize the computational (computing, memory, and latency) resources required
- Minimize the probability of detectability
For defence, the goals are:
- Minimize the complexity and maintenance of code to defend against an attack and its variants
- Minimize the computational (computing,memory, and latency) resources required
The defender is always at a disadvantage as the preparation, in terms of code, and computational resource required is a few magnitudes higher. Ideally she has to monitor all OTP requests to detect attack patterns, which is not scalable. In practice, the defender will monitor OTP requests for shorter periods, and use techniques like hashing, sampling, machine learning (look out for these in our future articles) to monitor longer periods.
Summary of All Resource Exhaustion OTP Attacks
First we compare the attack attributes to understand what it takes to mount each different attack. Next we compare the defence attributes to understand the difficulty of defending against certain attacks.
We compare the attack and defence attributes using different charts (radar and bar respectively) to utilize the strength of each chart type to highlight the main points.
Attacker Perspective: Resource Exhaustion Attack Attributes Comparison
You can see that 'Random OTP' attack is unique; it requires more resources and preparation than others but it has the benefit of low detectability. However it can also be inefficient. For others attacks, the preparation and resources are same but if they have high efficiency, they also tend to be detected easier. Thus the best attack depends on what the attacker has at her disposal; if she has a lot of resources she may not mind the inefficiency of an 'Twisted Serial Killer OTP' attack that has the lower detectability.
Defender Perspective: Resource Exhaustion Attack Attributes Comparison
Simple attacks like ‘High Consumer OTP’ attack can be accurately detected requiring little resources and preparation. At the other end of the spectrum, ‘Random OTP’ attack requires significant resources and preparation but yet has lower detection accuracy. Machine learning using Convolutional Neural Network (CNN) defence stands out as it has relatively high accuracy but yet requires little runtime resource. Moreover it can detect all OTP attacks except random without additional training data.
High Consumer OTP
High Consumer OTP Attack
This form of attack is the simplest. An attacker requests for OTPs for a single phone number as many times as possible.
Efficiency
This attack has high efficiency because each request is from a known valid phone number so it resembles a legitimate OTP request, which will trigger an OTP request.
Detectability
This attack has high detectability. However, attackers can rest in comfort that defenders will not shut out the phone number as that will deny the legitimate phone number access to the defender’s web service, culminating in ‘Denial-of-Service’, which is as costly.
Preparation
- The only effort required is to gather a valid phone number to be used for attack
- The code is simple, requiring a single loop to repeatedly request OTPs for that phone number
Resource
An attacker can ramp up the attack by requesting more OTPs for a phone number, which increases computational (mostly computing) resource proportionally. In mathematical terms, this is approximately O(n) where n is the number of attacks.
Alternatively an attacker can ramp up the attack by requesting OTPs from more valid phone numbers. This increases the one-time preparation effort required as she has to acquire a list of valid phone numbers. Mathematically, magnitude-wise the attack is still O(n).
- The only effort required is to gather a valid phone number to be used for attack
- The code is simple, requiring a single loop to repeatedly request OTPs for that phone number
High Consumer OTP Defence
The defender has to monitor every phone number making an OTP request for a configured period, and associate a count with that phone number, and when the count exceeds a configured threshold, the phone number is blacklisted.
Accuracy
Since the defence blacklists the offending phone number based on only a single tunable parameter - OTP request frequency threshold, it is easy to configure the parameter accurately.
Preparation
- Code-wise this is pretty straight-forward
Resource
An attacker can sustain the attack but mask it by using more attack phone numbers and reducing the OTP request rate for each phone number. The defender has to increase the monitored period thereby the amount of phone numbers monitored to detect such attacks, and this incurs additional computational resource.
In mathematical terms, this is approximately O(m), where m is the number of phone numbers that needs to be processed and stored in memory, which is proportional with the time period being monitored.
- Computing and memory resource scales proportional with the time period which OTP requests are monitored
Random OTP
Random OTP Attack
The attacker can randomly generate a series of digits and string them together to resemble a phone number to be used for attack. However, this strategy is inefficient, as common phone verification library, e.g., libphonenumber when implemented as defence can detect phone numbers with invalid syntax.
Gathering valid phone prefix, area codes, and phone number syntax, e.g., phone number length, etc., for each country to construct valid phone numbers improves attack efficiency.
However, even that may fall short because valid phone numbers may be inactive, used for voice-over-IP (VoIP), landlines, etc., and reliable OTP platforms like RingCaptcha will block such phone numbers from requesting OTP requests for security reasons.
Efficiency
The phone number generated will have a higher chance of being valid, and successfully triggering an OTP request if an attacker is willing to spend time and effort to refine the phone number generator code.
Detectability
The randomness of the phone numbers used in this attack ensures the attack has low detectability.
Preparation
- The effort required to gather country specific phone number details to generate a random but valid phone number is quite involving.
- The code is somewhat complicated as it needs to adhere to many rules in order to generate a random but valid phone number. In addition, the code needs to perform real-time checking to ensure that the generate phone number is not inactive, and it is not a VoIP or landline.
Resource
An attacker can ramp up the attack by generating more random phone numbers to request OTPs for, which increases computational resource (mostly computing) proportionally. In mathematical terms, this is approximately O(n) where n is the number of attacks.
In order to use only active phone numbers, the attacker can consult phone number lookup services before using a randomly generate phone number, however, this may incur costs, and will increase latency, which slows down the attack.
- Computing resource scales proportional with attack size
- The usage of external phone number lookup service will increase latency and this scales proportionally with attack size
Random OTP Defence
Random OTP is difficult is to detect as there is no discerning pattern from the phone numbers themselves. Checking further attributes of the phone number, e.g., whether it is VoIP, landline, activated, etc. or the attributes of the OTP requests, e.g., is the OTP request origin IP address in the same country as the phone number, is the phone number roaming, etc., reveals the legitimacy on the OTP requests but at the expense of code complexity and resource requirements.
Accuracy
The ability to accurately detect an attacking phone number depends on the effort and time spent to refine the attack detection code to correlate various attributes from phone numbers, and OTP requests.
Preparation
- The effort required to acquire phone number, and OTP request attributes is quite involving. Having said that, the most basic phone number module (libphonenumber) can be easily integrated into your defense, and it can flag out a phone number that is VoIP/landline, or if the phone number has valid syntax, which is a good first line of defence.
- The code to correlate both phone number and OTP request attributes into a single metric, which represents phone number validity is complex, and requires a lot of tuning
Resource
The phone validity metric is a sum of many sub-metrics, which depends on various phone number and OTP request attributes. Some sub-metrics require data from external services, which introduces latency, while others require analyzing a lot of historical data, which requires significant computing resources.
If we assume that attackers will eventually reuse some of these random numbers at some point later, we can lower latency and computing requirements through the caching some of these sub-metrics. This however increases memory requirements and lowers phone attributes liveness, i.e., some attributes data may be stale.
- Memory requirements will scale proportionally with cache lifetime
- Computing and latency requirements scale proportionally with attack size
Serial Killer OTP
Serial Killer OTP Attack
Based on a valid phone number, an attacker can easily guess and generate other valid phone numbers by incrementing/decrementing the phone number by a random integer. This strategy has a high likelihood of generating a valid phone number because phone numbers in the vicinity are likely to be the same ilk.
Efficiency
Within small increments/decrements the generated phone number will likely stay within a valid phone number block, and resembles a legitimate phone number that can trigger an OTP request.
Detectability
Serial phone numbers can be detected rather easily.
Preparation
- The only effort required is to gather a valid phone number to be used for attack
- The code is simple, requiring a single loop to repeatedly request OTP for a phone number derived by incrementing/decrementing the base phone number
Resource
An attacker can ramp up the attack by gathering and using more valid base phone numbers to derive multiple sequential sets of valid phone numbers. This increases the preparation effort required as she has to acquire a list of valid base phone numbers.
- Computing resource scales proportionally with attack size
- One-time preparation effort scales with base phone numbers required in attacks
Serial Killer OTP Defence
The defender has to monitor every phone number making an OTP request for a configured period, and check if it is within a few increments/decrements from existing phone number sequences that are being tracked. If it is not a part of any existing phone number sequences, it starts life as a new sequence of a single phone number. Once a sequence length exceeds a certain count, it will be flagged as an attack.
Accuracy
Serial phone numbers can be rather easily detected. However to defend against future attack phone numbers, the defender has to predict them and insert them into the blacklist, which can be tricky and inaccurate.
Preparation
- Code-wise this is straight-forward as it requires 2 nested loops
Resource
- Memory resource scales proportional with the time period which OTP requests are monitored
- Computing resource scales based on phone number sequences already tracked in memory. Mathematically, this means O(m), where m is the phone number sequences tracked in memory. The phone number sequences in memory scales proportionally with the time period OTP requests are monitored.
Unruly Serial Killer OTP Attack
This is a 'Serial Killer OTP' variant where an attacker requests OTPs for derived serial phone numbers out of order to make detection more difficult, and increase the code complexity and computational resource requirements of the defender.
Efficiency
Like serial killer, the phone number generated is likely to be valid, and resembles a legitimate phone number that will trigger an OTP request, as long as the random number added/subtracted to the base valid phone number is not too big.
Detectability
Like serial killer, detecting serial phone numbers is not overly difficult. However, unordered serial phone numbers reduces detectability.
Preparation
- The only effort required is to gather a valid phone number to be used for attack
- The code is simple, requiring a single loop to repeatedly request OTP for a phone number derived by adding the base phone number with a random number
Resource
- Computing resource scales proportionally with attack size
- One-time preparation effort scales with base phone numbers required in attacks
Unruly Serial Killer OTP Defence
The defender has to monitor every phone number making an OTP request for a configured period, and use the algorithm for detecting 'Serial Killer OTP' but with a feature to merge sequences that may initially appear as distinct short sequences whose lengths are below the threshold considered attack. The resulting merge reveals a longer phone number sequence that will be flagged as an attack.
Accuracy
Unordered serial phone numbers require more resource to reorder and detect but the detection algorithm is quite accurate. However to defend against future attack phone numbers the defender has to predict and insert them into the blacklist, which can be tricky and inaccurate.
Preparation
- Code-wise this is straight-forward like 'Serial Killer OTP' but it must include the logic to merge phone number sequences
Resource
- Memory resource scales proportional with the time period which OTP requests are monitored
- Computing resource is that of ‘Serial Killer’ multiplied by a factor of m, where m is the number of phone number sequence tracked in memory. This factor of m is incurred when the sequence that a phone number is added is compared with all other existing sequences to check for merge. Thus mathematically, this has a runtime of O(m^2).
Twisted Serial Killer OTP Attack
In 'Serial Killer OTP', valid base phone numbers are incremented/decremented, which results in a derived phone number where the last few digits are different. In this variation, a new phone number is derived by changing 2-4 digits somewhere in the middle. This simple change drastically increases the code complexity and computational resources required by the defender.
Efficiency
The phone number generated is less likely to be valid than that of 'Serial Killer OTP' and 'Unruly Serial Killer OTP', but a valid one that resembles a legitimate phone number, which can trigger an OTP request is still generate sufficiently often enough to be somewhat efficient.
Detectability
Detecting phone numbers with slight modifications in the middle is tricky as the modifications can occur almost anyway in the middle.
Preparation
- The only effort required is to gather a valid phone number to be used for attack
- The code is simple, requiring a single loop to repeatedly request OTP for a phone number derived by modifying 2-4 digits in the middle of the base phone number
Twisted Serial Killer OTP Defence
The defender has to monitor every phone number making an OTP request for a configured period, but as the modification can be anywhere in the middle of the phone number, this exponentially increases the code complexity and computing/memory resources to discover phone number sequences. For each phone number, you need to convert each digit into a 3-bit binary coded decimal (BCD) format and XOR with a few phone numbers in each tracked phone number sequence.
Accuracy
The parameter that needs to be tuned to detect phone numbers with slight variations in the middle is the bit-size width where variations are permitted. A bigger width detects more variants of attacks but also increases false positive, while a smaller width reduces the ability to pick up variants of this attack.
Preparation
- Code-wise this is straight-forward like 'Serial Killer OTP'; it requires a single loop to check if a phone number is in a tracked phone number sequence through BCD conversion, followed by XOR.
Resource
- Memory resource scales proportional with the time period which OTP requests are monitored
- Computing resource scales based on phone number sequences already tracked in memory. Mathematically, this means O(m), where m is the phone number sequences tracked in memory. The phone number sequences in memory scales proportionally with the time period OTP requests are monitored.
A Step Into The Future of Machine Learning Defence
We have moved into the realm of machine learning, to create a unified model to detect all types of attack. Machine learning can reduce the computational resource required from O(m), where m is the tracked phone numbers ('High Consumer OTP'), or phone number sequences ('Serial Killer OTP' and variants), which is dependent on the time period to monitor for attacks, to O(1), i.e., independent of m.
Preparation
- Generate attack data that simulates 'High Consumer OTP', 'Serial Killer OTP' variants, etc.
- Train convolutional neural network (CNN) to detect these attack patterns
Resource
- A Macbook Air (2014 model with 1.7 GHz Intel Core i7 and 8GB RAM) can train the CNN within 2 hours to achieve 80% detection rate
- Once trained the CNN can execute detection
