57

I've found a little vulnerability in a web application running on Node.js server.

It works by sending some crafted payload to the application server, which makes the application server code to throw an error and due to lack of error handling - It crashes (until someone runs it again).

I'm not sure what is the appropriate name for this kind of attack. I assume it's a DOS (Denial Of Service) attack because it makes the server Deny Serving its clients. On the other hand, Until now, I've only heard of DOS attacks which works by flooding the server in some way (which isn't the case here).

So, is it correct to consider it as a DOS attack? If the answer is no, so how should it be called?

Rubydesic
  • 178
  • 5
Matías
  • 507
  • 1
  • 4
  • 4
  • 5
    If an application is well-written then it won't have any crash-type DOS bugs and an attacker will have to resort to a full DDOS (which will always work if the attacker has a bigger firehose than the target). However if the target app has an easy-to-trigger crash, then I'm sure any attacker would rather send the single crafted packet and save themselves the $$ of running a DDOS network. – Mike Ounsworth Jan 29 '19 at 23:06
  • 33
    As long as it prevents users from using the service it is a DOS. I have worked on a website that was DOS attacked by Google and Bing simply because Drupal cannot handle the load (I wanted to say **could** not but I believe it still can't). – slebetman Jan 30 '19 at 02:25
  • This would be a DoS attack, specifically I have seen such attacks called “poison pill” attacks before... but I am unable to find a reference for this right now – Josh Jan 30 '19 at 04:11
  • 11
    I would change your title to a “triggered” software crash. Random crashing isn’t really DoS, but the fact that you can cause it on command is the key part. – zero298 Jan 30 '19 at 06:30
  • @zero298 I'd mildly disagree: the title doesn't need to contain the whole context and nuance of the question, that's what the question body is for. I'd be fine with an even shorter title, like "Is a software crash a DoS attack?" The answer to the *title* would be "sometimes", but if someone posted that, it would be clear they were too lazy to read the actual question. – IMSoP Jan 30 '19 at 11:38
  • 3
    I think a little bit more detail about this point is important: `It crashes (until someone runs it again).` What happens to future requests, exactly? If the server crashes for you, but continues operating normally for all other users, then I would say you have more of a bug then a DOS attack, because the service is still available to other people. Technically you have DOS'ed yourself, so there is a bug for them to fix, but if the only impacted user is yourself then you don't have much of an attack (typically). – Conor Mancone Jan 30 '19 at 13:50
  • You hear about flood-based DoS attacks because they're very simple to do: the attacker just needs more bandwidth than the target. This makes them by far the most common form of attack. – Mark Jan 31 '19 at 00:01
  • @ConorManconeI read that as the service crashes until restarted, E.G. "run again (on the server)" for example, starting a `node` process in a `screen` session: if there's an uncaught exception the NodeJS server process dies until restarted. Obviously one mitigation here is that critical services would be auto-restarted on failure by something like systemd or monitoring software but that doesn't mitigate against a flood of poison pill attacks – Josh Jan 31 '19 at 04:34
  • @Josh Thanks Josh. I ended up adding an answer to talk through that distinction anyway, as the technology set matters. I haven't ever done node hosting (just PHP and Python) and wasn't clear from his terminology what exactly he was describing. That seems a bit crazy to me though, which is probably why I was confused in the first place. I'm used to application and server being separate, in which case no amount of unhandled exceptions can cause problems for the service itself - just for the one request that generated the application error. – Conor Mancone Jan 31 '19 at 13:55
  • This isn't much different from a Ping of Death, and those are considered DoS attacks. – Polygnome Feb 01 '19 at 12:00

7 Answers7

137

Yes. Any attack which has as a goal to deny the normal usage of a service by legitimate users is by definition a DoS (Denial of Service).

DarkMatter
  • 2,671
  • 2
  • 5
  • 23
60

DDoS (Distributed DoS) is characterised by floods creating a DoS (in all available definitions). A single node causing a flood successfully is kind of rare.

But DoS can be caused by a broad range of triggers.

CVSS even has an example of a software crash classified as DoS for you:

Due to a flaw in the handler function for RPC commands, it is possible to manipulate data pointers within the Virtual Machine Executable (VMX) process. This vulnerability may allow a user in a Guest Virtual Machine to crash the VMX process resulting in a Denial of Service (DoS) on the host or potentially execute code on the host. [empasis mine]

And from Wiki:

Denial-of-service attacks are characterized by an explicit attempt by attackers to prevent legitimate use of a service. There are two general forms of DoS attacks: those that crash services and those that flood services. The most serious attacks are distributed.

So, yes, a simple crash is a DoS.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 17
    DDoS is characterised by being a *distributed* attack, but not necessarily by being a flood. When you send a single crash-payload whenever the server comes back online and always use a different botnet zombie to do it in order to avoid IP blacklisting, that would also be a form of a DDoS attack. – Philipp Jan 30 '19 at 12:11
  • 2
    @Philipp I'm not sure about that. That seems like a serial DoS. Every reference I can find to describe DDoS has been to characterise the event as a flood from multiple sources creating a DoS, not a DoS from multiple sources. Can you provide anything to support your example? – schroeder Jan 30 '19 at 12:18
  • 5
    @schroeder I _suspect_ that's because many (or, at least, the easiest to achieve) DoS attacks involve flooding, and flooding from multiple sources is more likely to overwhelm a target. Thus _most_ DDoS attacks _do_ involve multiple-source flooding, but – I would argue – "flooding" that isn't the _definer_ of DDoS attacks, whereas "multiple-source" is. A carefully crafted attack, such as the OP asks about, coming from multiple sources (to hamper IP blacklisting) would legitimately be a DDoS. – TripeHound Jan 30 '19 at 13:58
  • 1
    @TripeHound sure, I get the supposition, and I might agree, if I had anything to support the hypothesis. I cannot find any support. – schroeder Jan 30 '19 at 13:59
  • 3
    Just speaking from a logical perspective, it makes sense to me that the defining charactaristic of a DDOS is that the distributed of the attack prevents the defender from mitigating the attack. The defender really needs to be specified for that to make sense. I would not consider sending single crash-payloads to a server application whenever it comes online a DDoS against the server application, but it might be seen as a DDoS from the perspective of a lower tier defender (perhaps a firewall) that may not be able to block this attack because it keeps coming from different IPs each time. – Cort Ammon Jan 30 '19 at 16:45
  • 5
    Yes, everyone, I fully agree that DDoS ***could*** possibly, logically mean a distributed attack of any kind. But, I can find ***no reference*** to this meaning being used in practice and even the proposed example seems to me like a string of attacks, and not a single attack (although distributed). If ***anyone*** can help with a concrete example, I'd be grateful. [Actually go out and count the horse's teeth](https://bedejournal.blogspot.com/2008/02/francis-bacon-and-horses-teeth.html). – schroeder Jan 30 '19 at 16:53
  • DDoS can absolutely include attacks that use a different mechanism besides mere flooding. I say this as someone who recently was a software developer on an anti-DDoS team for a well-known worldwide company. – ErikE Feb 01 '19 at 18:29
  • https://www.paloaltonetworks.com/cyberpedia/what-is-a-denial-of-service-attack-dos - but good on you for holding out until someone actually provided a citation! Way too many internet discussions are ended by mob fiat. – Alex H. Feb 01 '19 at 19:59
10

Quite often security is looked at as providing three properties:

  • Availability
  • Integrity
  • Confidentiality

In your case, you've found something that allows a user to affect the availability of the service. Depending upon what the service provides, that might be annoying or it might be catastrophic.

Quite often failed services will be automatically restarted. These can mitigate occasional crashes, but restarting a service is usually far more expensive than the usual cost to handle a connection. In this case, executing your 'crash the server' request five or six times a second might not be much bandwidth but is still probably pretty rough on the average server.

sarnold
  • 721
  • 4
  • 7
  • 2
    Also, good service managers don't restart services without limit. Chances are, something that makes the service crash might also be exploitable in other ways, and blindly restarting the service gives the attacker another shot. – Simon Richter Jan 31 '19 at 10:28
9

I wanted to add one more important detail not explicitly stated in the other answers. You said this:

It works by sending the server some crafted payload, which makes the server code throw an error, and due to lack of error handling - It crashes (until someone runs it again).

(emphasis mine). That caveat is important because the way such services respond to a crash can vary wildly between technology sets.

Not a DoS

For instance in PHP or most cgi implementations, a single crashed request has absolutely no impact on other requests. The server fails to send a proper response for the crashed request, but other requests coming in from legitimate users continue to be handled properly by the server. In this case the crash only affects yourself - not others - and so it would be hard to qualify that as a DoS attack. Sure, there is a bug, and you are denying yourself service, but if the server continues to operate normally for everyone else then there isn't really any denial of service going on.

A DoS

If, however, your payload causes the actual service to go down and no more requests can be received by the server until some action is taken to restore services (whether by an admin or automatic restoration after a short period of time) then you definitely have a denial of service because the crash you caused stopped the service from responding to legitimate users (as discussed in other answers).

Under some circumstances the "Not a DoS" attack that doesn't take down the server could possibly be promoted to an actual DoS attack if you can "trick" a legitimate user to visit a URL with your malicious payload. Most of the time though such attacks don't have much practical impact since the service will continue to operate normally when they later use the service normally. However there could be rare circumstances when the payload is persisted to the session and therefore permanently locks out the user (I've seen people accidentally trigger such circumstances in real life before).

From your description, it's hard to tell which of these categories your particular payload falls into, but there is an important distinction to be made.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • DoS can also apply if you trick a valid user into running the payload. The DoS is localised, but it still counts as a DoS. – schroeder Jan 30 '19 at 14:02
  • @schroeder Yes, true, although it is hard to make such attacks have substantial impact, which is why I left it out (I'll add a comment about it though). Typically that kind of attack can get the affected user to have a failed page load, but if they return to the page in normal usage everything works like normal. It is possible to have a case where the bad payload gets persisted to the session in some way, which can end up effectively DoS'ing a single user - that can be a very effecitve DoS attack. – Conor Mancone Jan 30 '19 at 14:19
  • 2
    In node you have a small number of single threaded servers. so a server crash affects all active users (of course automatic restart is a good idea but continually crashing the process will severely hurt the service). However what should be more of a concern is what kind of crash that is... could be exploitable (logical processing aborts would not terminate the node binary). – eckes Jan 31 '19 at 01:01
  • 1
    PHP FastCGI or FPM uses one PHP worker process per request and a fatal error would only kill your worker process, and the FastCGI daemon would span another. But what happens if your error is so bad that it kills _apache_ (or whatever webserver you're using) -- _then_ it's a DOS attack. I've seen this before (where the bug was in an Apache module) and the result was nothing listening on port 80 anymore and a total loss of service – Josh Jan 31 '19 at 04:37
  • Thanks @eckes, I'm not a node guy so I don't know much about how it handles unhandled exceptions. – Conor Mancone Jan 31 '19 at 11:45
  • @Josh Yes and no. Indeed, if you managed to get apache killed then you are back to a DoS. However, that typically requires a bug in apache. However, triggering a fatal error in a PHP application doesn't cause the underlying worker process to die. To cause the worker to die you need to find a bug in PHP *itself*, which is much harder than finding a bug in the PHP application. Same with apache - to kill apache you need to trigger a bug in apache (note that trognanders answer includes an example of such an incident). Those make for DoS attacks, but are much harder. – Conor Mancone Jan 31 '19 at 11:48
  • @ConorMancone, ...finding an arbitrary-code-execution attack on a PHP application, by contrast, tends to be a frequent occurrence, and leveraging *that* into a denial-of-service that impacts Apache as a whole is straightforward. – Charles Duffy Jan 31 '19 at 16:12
  • @CharlesDuffy Unless I've misunderstood you, I feel like that's a bit of a hasty generalization. A remote-code-execution attack is the most dangerous kind of attack. There certainly are vulnerable sites out there (they show up here asking about random files they found on their server), but that doesn't mean that it is frequent or that it is easy to find such a vulnerability on a random site. Also, if you had gotten execution privileges on a server, I don't see why you would therefore go and DoS the site - there are probably juicier attacks to be had, and a DoS is loud. – Conor Mancone Jan 31 '19 at 17:16
4

Your attack is basically the definition of DOS, it literally denies service and you are using the term correctly.

Consuming bandwidth is a naive approach that does not require the sever to have a specific vulnerability, but is certainly not the only one.

Here is a real CVE about Apache describing a similar DOS attack (crashes with segfault) using that terminology:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8011

Even more complicated attacks are sometimes trivially DOS attacks and are given that label as well. A stack smashing remote code exec bug without a shellkit still smashes the stack with incorrect values causing a segfault.

trognanders
  • 2,925
  • 1
  • 11
  • 12
1

Yes this could be called a DOS vulnerability. I have heard this called an "Application DOS Attack".

Another example: a site that runs a virus scanner over uploaded files, where someone uploads a zip file of 100,000 zip files containing 100,000 2gb files of zero bits. A super small zip file that uses all of the available memory to open and scan.

If you are denying a legit user from utilizing a resource [CPU, Ram, Disk, Network bandwidth (password resets?] then you could call it a DOS attack.

If however the attack just corrupts the application's state (say lets an unauthorized user set the app into read-only mode) then I might be inclined to just call that an application (or security) vulnerability.

DarcyThomas
  • 1,298
  • 1
  • 10
  • 15
-7

Does it make sense to consider a server software crash, as a DOS attack?

Any actor will act in at least two dimensions with regard to any activity: ability and permission.

Ability has 2 possibilities: able and unable.

Permission also has 2 possibilities: allowed or denied.

Therefore, a nice actor will perform an action only if able and allowed.

From my point of view, software crash=unable and DOS=denied. Since the two are "values" on different dimensions, they cannot be considered similar, even if the effects to the end-user may be similar. However, the effects seen by the network admin may be totally different - the solutions for them are usually different.

Also, a DOS attack may lead to a software crash, but they are still not similar - they are only related - cause and effect.

Example: any software may crash for uncountable number of reasons even in the absence of any attack.

Note: software crash usually means that the process is stopped by the OS because of a faulty operation. DOS are possible usually because the software just misbehaves, but does not crash.

virolino
  • 99
  • 1
  • DoS is not a permissions issue. The basic definitions of the terms contradict your premise. – schroeder Jan 30 '19 at 12:57
  • Even so, the terms are not similar. Therefore I assume that my answer is correct, even if the "metaphor" is not perfect. So the downvote should not refer to the whole answer. Moreover, D in DOS is "Denial" (exactly as I wrote) - so again I do not really understand the downvote. – virolino Jan 30 '19 at 13:17
  • 5
    You are factually, linguistically, and logically incorrect. You are trying to apply definitions of parts of terms out of context to devise a meaning and the result makes no sense. I could walk through the errors in logic, but the fact is that the term "DoS" is *defined* by the intentional loss of service to legitimate users, and a crash is one core example of this classification of attack. – schroeder Jan 30 '19 at 13:21
  • If I use your terms, the malicious actor is `able` and `allowed` (that is, not denied, given your definitions) to send a crafted packet to stop the service. So your conclusion is faulty from the start. Your next point makes no sense whatsoever given the context you gave the terms you are using, so your argument is based on a change in definitions. The result is that your logic has no flow. – schroeder Jan 30 '19 at 13:25
  • Just curious: who `allows` anything malicious? How are malicious actors allowed? Yes, they are able, yes, they act, no, they are not allowed. They just act. I think your definitions are not very sound either. And my answer is the only one addressing the question in the title, even if other answers are more technically correct. Can you please explain - maybe in an answer - `how is a software crash similar to a DoS attack`? Please. – virolino Jan 30 '19 at 14:20
  • The question is the *entire* post, not just the title. The entire post provides context. I am using ***your*** definitions when I say that malicious actors are `allowed`, because they are not `denied`. that's ***your*** dichotomy. And, if you will look for yourself, you will find that I *have* provided an answer. That, is, I provided an answer to the question, not your re-interpretation of it. – schroeder Jan 30 '19 at 14:23
  • 1
    A software crash counts as a Denial of Service because it prevents otherwise legitimate users from using the service (i.e. denies them service), because the service can't be used when the process is not running. One might ask, how does a DDoS reduce legitimate users' privileges? – HAEM Jan 30 '19 at 14:43