I was doing a security review of CrushFTP, a multi-platform FTP application, and I came across a DoS stemming from lack of validation of user input.
Originally, I thought there was broken function level authentication, or something similar, when making a request to this particular endpoint with a specific post body, but I was informed by the dev that it is supposed to be an unauthenticated function call.
An unauthenticated user can make a POST request to the /WebInterface/function/ endpoint, with a body containing the following:
This request will cause a DoS by supplying massive passwords to be encrypted. Although CrushFTP does have some preventative measures in place for DOS attacks, an attacker is able to send a small amount of requests and bog down the system, as seen in the next picture.
The issue stems from a lack of input validation for the password parameter, as seen on lines 752 through 786 of ServerSessionAJAX.java.
The developer is very responsive and fixed the issue in a couple of hours. As we can see, the password parameter is now limited to 2000 characters.
And he was gracious enough to give me a shout out in the build logs.
All in all, CrushFTP is an awesome application, and it seems to have a great track record in regards to security. There are only a handful of published CVEs for it, and this seems to be the only thing I’ve found in my testing, so far. The dev is also quick to implement fixes, so users aren’t stuck without a fix for long. I wouldn’t hesitate to use CrushFTP in any environment.
With that said, I did some Shodan searching for instances of CrushFTP running with a slightly non-standard default username and password, and I found a fair amount of them. I tried reporting those to the companies that were running them, but I’ve yet to receive any responses.