The interesting part is the ICC-ID. It consists of 19 digits. But the structure of the ID means that this attack was possible because it's not necessary to cycle through 10^19 numbers.
The first two digits will always be 89 (which means that the SIM card was issued for telecommunications purposes), the next two digits will be 01 (which indicates that this is a card from the US), the next four digits will be 4104 (which indicates who made the card). And the final digit is calculated by the Luhn algorithm.
So, of the 19 digits, 9 are fixed. So you've got 10 possible digits. If you started your search from a known iPad SIM ID you could probably get a lot of the IDs without having to search from the start of the 10^10 space.
Would anyone care to put forward a solution to proactively tackle a similar script.
What I am specifically after, methods to know that this one computer ( keep it simple ) has sent x 1,000 requests in a short time ( ie to quick to be human ).
Before some of you lay the blame purely on AT&T for having poor code.
Other scenarios which are similar but different.
Perhaps we want to use this to throttle api requests, or to tackle a brute force attempt on the login.
A little more info, but not alot. More monitoring.
Equally discovered PHPIDS, reading how it works. Im not sure this would have picked up on this attack vector, as it would have been legitimate traffic. Just rapidly used.
The first two digits will always be 89 (which means that the SIM card was issued for telecommunications purposes), the next two digits will be 01 (which indicates that this is a card from the US), the next four digits will be 4104 (which indicates who made the card). And the final digit is calculated by the Luhn algorithm.
So, of the 19 digits, 9 are fixed. So you've got 10 possible digits. If you started your search from a known iPad SIM ID you could probably get a lot of the IDs without having to search from the start of the 10^10 space.