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

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?

• It really depends on how many requests per second you can make and it depends on the server not client. So if the server can do 1000 requests per second which is a lot and more then most websites can do (either big which do not allow or small which are on shared hosting), this gives 9999999999/1000/3600/24 = 115 days. The curl script below would take approx 31 years assuming it can do 10 requests per second.
– Aria
Aug 25, 2016 at 16:41
• This is called Online Brute Force. There is another kind of called Offline Brute Force where you try to determine the plain text of a stolen hash in situations where a rainbow table is not available. Aug 25, 2016 at 16:44
• You will probably be unable to. On average, the brute force will actually take only 5Bn attempts, not 10Bn (or 4.5 if the first digit cannot be zero). However, this will create a terabyte or so of serverside logfiles. This is reasonably likely to fill the disk and crash the server. Aug 26, 2016 at 2:46
• Any reasonably designed system will detect and prevent this attack. Aug 26, 2016 at 7:50
• Just because there are 10 billion possible numbers doesn't mean there is only 1 valid number/URL (unless that's exactly the case you're describing). Take eBay for example. Auction pages are at `eBay.com/itm/[12-digit-number]`. Aug 27, 2016 at 7:24

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 * 1010 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.

• I think the assumption is a valid page would be the only thing with a valid header, or would have a different header than a bad or missing page. Aug 25, 2016 at 17:08
• @YorickdeWid - It's pretty likely the headers would be different. I have done this in a real pen test (although it was 6 digits not 10) and HEAD requests worked fine. Aug 25, 2016 at 17:16
• @Eclipse maybe that's why (s)he says "This is best case, in practice there are likely to be issues that prevent it working so fast" ? Aug 25, 2016 at 17:42
• @YorickdeWid because it sets a threshold -- it tells you it will take at least a day. Sure, in a real world scenario it might take you 3-4 days, but there is now at least a lower limit. You can't define an upper limit, because sure you could run this on a 486 with a 9600bps modem... or you could run it on an ATTiny85 communicating at 2400bps over serial... you can make it take as long as you want. Short of throwing enterprise- or government-grade hardware at it though, there will be a lower limit on how much time it takes, and this answer approximates one. Aug 25, 2016 at 19:49
• @Eclipse - It's fair enough you think that, but I'd encourage you to explain WHY you think that, rather than just stating your opinion. My answer is optimistic, but not grossly so. If the server doesn't have throttling, then the other assumptions will usually be met. And I have done this for real with a 6-digit code, so it's not entirely theoretical. Aug 25, 2016 at 20:09

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.

• The example would connect, perform the request with more headers than needed, and disconnect every time. A better idea is described in the accepted answer, where you just keep streaming tiny requests over one connection (per worker). Aug 27, 2016 at 20:03
• @Rhymoid which is why is was chosen as the answer Aug 27, 2016 at 20:08
• "A good configured system will block too many requests that originate from the same address." It should be noted that this may not be an effective defense, since botnets exist. Aug 28, 2016 at 0:19

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

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.

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.

• Nice take. One but pick: you've not accounted for threaded/async programming - a single core can handle multiple requests at once Aug 29, 2016 at 10:45
• @paj28: That only helps to the extent that servicing a request involves sleeping (I'm not considering hyperthreading because you can just use logical cores instead of physical cores, if that's more accurate for your performance characteristics). You may well be sleeping a lot if your serving path is highly I/O-bound, but even with async you will need a lot of capacity to make the math work in that situation. In particular, the bandwidth of your I/O channel becomes a bottleneck. Aug 29, 2016 at 17:30