How practical is it to bruteforce a 10-digit number via URL

Question

Example URL www.[somewebsite].com/[10_digit_number]

Getting the correct number loads a page.

I know there would be 10 billion possible digits to choose from, but how long would it take? What are the resources one would need?

Answer 1

About a day

If we're lucky: there's no throttling, we can perform each test with a HEAD request, can perform many tests on a single HTTP connection with Keepalive, and can have many concurrent connections.

In that case we're mostly limited by bandwidth. Say we craft a tight request that is 100 bytes, that means we need to send a total of 100 * 10¹⁰ bytes. And lets suppose we have a decent 100 Mbps connection, which will do about 10 megabytes per second. That would take 100,000 seconds - just over a day.

This is best case, in practice there are likely to be issues that prevent it working so fast. We could have multiple systems working simultaneously to make it faster - but at some point we'll overload the server.

Answer 2

Rolling a 10 digit number doesn't lake long on most systems, regardless of the script/language used. The bigger problem here is the number of connections you open simultaneously and the delay between requests. A good configured system will block too many requests that originate from the same address (either by the firewall or the daemon itself).

For example:

#!/bin/bash
for i in {1..1000}
do
   curl "www.[somewebsite].com/$i" > "${i}_out.txt"
done

You might want to thread this.

Answer 3

Depends on several factors.

Server side

• Server bandwidth
• Does this requested number generate a query on some database ?
• Any firewall/security script to detect this kind of activity and block it
• Any other resources that can be a bottle neck like cpu or memory.
• If you are that kind of lucky people who will try it on a server that logs are stored on a very limited file system, and this kind of activity will consume the every free byte of it making the application stop.

Client side

• Your bandwidth

My considerations regarding this activity:

First do a DNS query, and see if there is more than a server for that address. That will help, more server, more you can split the load.

Test the firewall, get a VPS and make some tests to get an ideia of your environment without blacklisting your ip address. Test some rates, 100, 1000, 10000, per second. Test the average response time for every hour of the day. If the response times changes, so your server has some time windows that receive more traffic/requests and that will be a good time to not stress the server.

With all above results you will know what to do. If the server has more bandwidth that you have, what happens almost all the time, you can get a VPS to help you, choose one near the server. You will have your plan about how many requests will be optimal to archive your solution, for example, if the servers receive more load in the morning, you can use 1000/s during the day, for example 8am to 10pm, and use as many the servers can answer during 10pm to 8am.

Just be aware that this kind of activity could lead to some services do crash or get a load so big, that it won't be able to answer the users and that can be considered a Denial Of Service attack. It can get you into some trouble because of several factors, I don't know about all countries, in several countries this kind of attack is a crime. Contact the system administrator about your intentions, before you crash any system and become responsible for a downtime.

Answer 4

A day is wildly unrealistic, regardless of resources.

There are 86,400 seconds in a day. Round up to 100k. Divide 1B by 100k and you get 10,000 queries per second. This is somewhat large. The server will need a decent load balancing story and a fair amount of computing capacity. For reference, if we have 100 machines with 8 cores each (for a total of 800 cores), we will need to turn around each request in at most 80 ms, which is tight but not entirely unreasonable. The client will also need capacity commensurate with that of the server, and assuming you're a black hat attacker, you are probably operating a botnet or something of that nature.

Actually, you have to be operating a botnet, because the client needs to be geographically distributed in such a fashion that the server can load balance it without traversing high-latency network links. This is critical because the latency between server and client counts towards our 80 ms budget. If the client is entirely in America but half the server is in Europe, the transatlantic latency will completely ruin our performance, and we will need significantly more capacity to make up for it (or else we will simply have to service all of the requests with the American half of the server, which runs into similar capacity issues).

But wait! You said 'regardless of resources.' Why are you throwing resource numbers at me?

Because the people who operate web services at this scale generally have good enough monitoring to detect a sudden 10k QPS flood of traffic from a botnet. In all likelihood, your target will determine that you are DDoS attacking them (which is basically what you are doing) and deploy standard mitigations (e.g. serving 503s or CAPTCHAs, black-holing the traffic, etc.). At this point, your attack will fail or at least take far longer than you planned for, and the authorities will now be working to dismantle your botnet.

So if you want your attack to actually work, you cannot do it at this velocity. Either your target cannot handle the traffic, or they are smart enough to detect and block it.