For some research I'm looking for a working DOS exploit for OpenSSH. The OpenSSH version, vulnerable to the exploit is irrelevant. The only requirement that I have is, that the exploit should work for Debian or more general on Linux.

I've searched for exploits for these CVE's (on cvedetails.com), but found only one actual exploit, which didn't work for me.

I'd be very grateful for any hint.

edit: I believe my intentions as well as my background knowledge have been misinterpreted. My research does not target exploit development, nor exploitation. I'm working on various mitigation techniques for a number of issues with OpenSSH and other tools. As of now, I'm trying to test a couple of mitigation techniques for DOS vulnerabilities in OpenSSH, but can't find a working POC.

  • 3
    I think this may be one of those "If you have to ask......" moments. – Little Code Jun 4 '16 at 15:29
  • I understand what you mean, however the research I'm conducting does not focus on exploit development, rather on mitigation techniques. This is why I require a working POC, to actually test my mitigation methods. – boolean.is.null Jun 4 '16 at 15:30
  • 1
    Do you know that (D)DOS is a problem even without bugs in the software? – deviantfan Jun 4 '16 at 15:32
  • Yes, I'm aware of what a (D)DOS attack is with and without bugs in the software. – boolean.is.null Jun 4 '16 at 15:39

I'd recommend looking for non-recent versions of OpenSSH in your search. Since it's a relatively well maintained library, if there's any known exploits, they've likely already been patched. However if you look through the CVE list for working DOS methods on older OpenSSH versions, you'll be able to access all those nasty bugs that have already been patched! Both Yum and APT allow you to downgrade packages and as far as I know, neither operating system has any dependencies of the library in terms of versioning (I've never actually tried downgrading OpenSSH, but I'm fairly certain it has no upstream dependencies preventing you from doing so). Once you find a CVE and version for you, just google the "CVE-Number-Here POC" and you'll likely find some code for it.


Please for the love of God run this on an internal network where it cannot be accessed from the Internet. You may not think you're at any risk exposing yourself like that, but you definitely are.

  • That's exactly what I did but could only find one POC, which doesn't work, that's the problem. The vulnerable SSH server is running on a lab system, disconnected from the Internet. – boolean.is.null Jun 4 '16 at 15:49
  • 1
    Most POCs will work in their target environment. Make sure your OpenSSH version matches that which the CVE requires! – duper51 Jun 4 '16 at 15:50
  • Thank you but I made sure that the requirements are matching, the exploit launches successfully, however the service is never denied. – boolean.is.null Jun 4 '16 at 15:54
  • 1
    Odd... I'm assuming you tested without your potential DOS prevention techniques in place (you seem like a smart enough person), perhaps the environment is not correct in every way to make the CVE work. Sometimes even the OS has to be correct, as well as other system libraries (which would be far more difficult to downgrade). You're better off finding a different CVE. As a side note, you could just fake a DOS with a service like Fail2ban, which would satisfy your requirement for a DOS, as well as allow you to configure it to your specifications. – duper51 Jun 4 '16 at 16:01
  • 1
    That's what I'd recommend. Good luck! – duper51 Jun 4 '16 at 16:05

DoS is just may request at the same time. Proof of concept is to run many requests to authenticate to one server in some time period. I don't know what more do you want to hear.

Current OpenSSH version mitigates this with random early drop if the amount of the connections exceeds some limit and starts rejecting all the connection if the hard limit of connections is reached.

By default, there 30% chance for rejection with 10 connections, increasing linearly to 100% on 100 connections, which is really hard to reach.

The attacher also needs to start a lot of new sessions, because server disconnects the clients that were not able to authenticate after some period (by default 120 s).

Some older version might handle the case in different way so they might have been more vulnerable.

In short, running something like this should do the job:

for i in `seq 1 128`; do ssh host id & done

Not the answer you're looking for? Browse other questions tagged or ask your own question.