Can a DDoS attack reveal any information or be used to mount a hack? My understanding is that the whole point of DDoS or DoS is to consume all of the resources/overload the server causing it to crash. And that being the only reason to do a DDoS.
I have heard that DDoS is used to get information. Is that true or totally false?
A DDoS will certainly give an attacker information about response times, load capability and routing.
It may also give information about how incidents are handled internally and externally, as well as how they are reported to the public.
But this is not what the main uses are.
Generally the two key reasons for DDoS are to:
The first is well known, very popular, and is relatively straightforward to carry out, with the only defence against a large attack being a high volume DDoS mitigation service.
The second is more rarely used, but is being seen as a part of an attacker's toolset. Loading the incident response team can make it harder for them to detect an intrusion, can hide the real reason for the attack, and can hide evidence of an intrusion in amongst large numbers of log entries from the DDoS.
A full answer would be depending on the attack and what would be attacked, so I will keep it general.
A DoS can leak information as a side-effect. In earlier times switches were used in networks to prevent machines to listen to the communication between 2 other machines. Due to a design problem you could turn it into a big collision domain again by launching a DoS attack against the switch and you can listen to any communication again. Explanation of the attack: Switches learn which machine is connected to which port. When a machine sends a packet to another machine the switch looks up in his memory at which port this machine is and forwards the traffic to only this port. A machine on another port wouldn't see the traffic. A problem arises when there are more machines on the network then what would fit in the memory of the switch. Common behaviors are:
Especially common were the first type. A attacker would let his machine to pretend to have a hugh amount of machines to be at this port by DoSing it with announcement-broadcasts.
Another attack related to DoS is a security downgrade attack. You have a system consisting of 2 sub-systems, A and B. B is used by A to do additional security checks. If B doesn't respond in time, A would skip this check and consider it successfull. If the attacker can DoS system B he has an easier game because he only needs to pass the security checks on system A. Some systems are designed this way because availibility of system A is important and nobody thought some attacker might DoS system B or would accept the risk. I can't give you the details of an actual attack but some anti-spam blacklists work this way.
It is also known that some advanced groups/organizations launch (D)DoS attacks to distract from their real attack by attracting the focus of the security staff on the target of the DDoS or hide the attack traffic between the DDoS traffic.
Another option is that you need that amount of traffic but don't need to (D)DoS it. For example some attacks on SSL require enough packets to recover/manipulate information. Here the DoS would be a side effect of the amount of traffic.
A Denial of Service attack, distributed or not, can be used to successfully identify machines which share resources. If you want to hack a service, you can launch an attack against it, while monitoring other services. If those also disappear, it is likely that they are hosted on the same machine. These other services may be more prone to hacking, and can be used as a "crowbar" to gain access to the service you want.
This can be devastating when used against hidden services in the Tor network. If you have reasons to believe that a certain individual is hosting a hidden service, you can test this by launching an attack against an open service on the same hardware or in the same data center. If the hidden service goes down, you may have confirmed that your guess is correct, and the identity behind the hidden service has been compromised.
Each time you test this, you will get one sample, which may be a false positive. Doing it enough times at random intervals, you can increase the probability of being right.
It is possible to use a DDOS attack to gain information. In addition to the answers by Rory Alsop and H. Idden which focus on gaining infrastructure information or overloading the incident response team so other attacks stay undetected longer, there are a few other possibilities.
Auto Scale Applications - When working with an application platform that auto scales a DDOS attack may use the fact that they auto scale to do something. This would have to be in concert with some other kind of attack or information, but the general idea is that if you know enough to exploit the "reboot" process you could use DDOS to force a new server online witch would go through the reboot process, allowing your exploit. It's important to note that this is in addition to an already existing security problem. It's just the tool by which the totally different exploit is brought online (or maybe tested). A sample I can think of is a Production server hosting it's code base in a public github repo, when scales pulls new code into the server, then starts. You could add bad code to that github repo (if not managed correctly), force a restart and have your exploit.
First come First served applications - There are some applications that are "first come first serve" in some part of their process. IRC (from comments) is an example but there are others. Any service that reserves something for a user on a first come first served approach, can be exploited via DDOS. Either by taking up all the slots till a specific person get's theirs, or by forcing a reboot and getting anther chance at "slots" after the restart. These are pretty common, and while a service that uses this for authentication is a bit odd, it's not unheard of. In fact licencing services do this all the time. First user with a licence of "ABC" is the qualified user of ABC. If that data is lost after a reboot then DDOS could cause that reboot, and get their foot in the door.
Startup Vulnerabilities - I have seen, quite a few times where a server boot resulted in services being "left on" just in case. For example , let's leave SSH passwords on after reboot then turn them off after a couple of hours just in case we need emergency access. Or, FTP is on for 30 mins after reboot. This is more common on network appliances. Things like "insecure wifi access for the first 2 mins" or "anything can upload anything for 2 mins". Usually this is part of an upgrade/update mechanism. For example a Cisco router may accept any TFTP data it finds after reboot. Some computers will listen for ANY netboot server at restart. DDOS can kick off the restart and allow your "bad code" a way in.
In essence, a DDOS by it's self can tell you some things, but usually only stuff that is useless on it's own. A DDOS in conjunction with other attack vectors can be extremely effective.
Note The methods used here would work in a lab, but there low hanging fruit for a security team (or even just regular IT). While they do exist in the wild an attacker would have to have gained access/knowledge of internals way beyond that of someone just doing a DDOS.
A real world example of this happening is with Steam. They experienced an DoS attack on christmas day. In response to that they changed the caching rules of the steam service, so customers could still access the store page. Unfortunately, they ended up making a configuration error, which sometimes caused users to see the personal information of other users.
Systems sometimes have unexpected behavior under heavy system load, which can lead to security vulnerabilities. Its a possibility for hackers to exploit this, but they are unlikely able to plan for this, and the exploit is likely unpredictable. They also have to deal with the fact that the server is probably slow to respond due to the heavy load.
In theory a DDOS attack could not only distract from an exploit as mentioned in another answer, but it could also be combined with one.
Consider the Heartbleed bug, that returned information when a server was contacted in a particular way.
One could increase the information gained from the server by contacting the server in a DDOS attack and collecting the information that was released in this way.
Forcing the Server Boot Time
One thing that has been mentioned tangentially in the comments, but not addressed in any of the other quite excellent answers is that it can occasionally be useful to know when an application/server booted up. For example, certain horribly insecure random number generators (which should never be used for security related tasks, but invariably are every now and again) use the system time as their "random" seed.
With that being the case, if you can deduce when the RNG was seeded (preferably within a couple of minutes of accuracy) and have some samples of generator output, it is reasonably trivial to find the seed and rebuild the RNG state to predict future tokens. Now, ordinarily a server should not expose it's start time (though again, some invariably do), however if a DDoS attack can be used to force a server reboot then you've gained knowledge of the server start time.
This can lead to a variety of token based attacks like session hijacking.
It may be fixed but I know in the early days of Group Policy one exploit was to overload the Group Policy server and in some configurations the local policy would be applied. So we would configure local policy as minimal. You could only use the denial as an exploit the server policy reduced authority. I know I don't have all the terms correct - it has been a while since I did Group Policy admin.
Let say you had compromised a router but that router was not getting the traffic you wanted. You could do a DoS on a good router to hopefully get traffic to the hack router.
I assume that DoS attack can be used alongside with race-condition kind of exploit. When server is heavily loaded, exploit will be easier to use.
However, DoS-attack alone can yield some info, as it was shown in previous answers - about routing, response time and internal incident handling.
What about a timing attack? This has been discussed as a possible security vulnerability in Java, Python, probably many others, and actually might appear to be a DOS attack.
When various libraries check for equality, generally they ready byte by byte and compare, returning false if not matching - if something like that is used in checking password/cookie, theoretically they can time the longest request, and assume it got farther through the comparison.
It's usually not incredibly intrusive. It depends on the ports that are open and the packets that are sent. DDoS can come from people bruteforcing your server's details and databases, especially over LAN, and can imply a discreet bruteforce attack in some cases. A typical web server is hard to hack, I host web and for video games. Ask a professional, or I'd assume it's an unavoidable vulnerability.
