MintDNS is a piece of software used to provide dynamic DNS services. It runs under Windows, and I can find ~50 different CCTV/NVR providers using it.
I’ve only had a very quick check of this piece of software, but it appears to suffer from multiple, fairly serious, vulnerabilities.
User input validation is performed client side
There are a number of checks on things like password length done client side. These can easily be bypassed by setting values directly in requests. For example, custom security questions can be set, and empty passwords.
Passwords stored in the plain
The database stores passwords, encoded as base64, in the Admin and Users tables:
Users table
Admin table
dGVzdHBhc3M= is “testpass”
It is not advised or forgiveable to store passwords in the plain anymore.
Passwords stored in the plain in a cookie
When logging in, the base64 password is stored in the plain in a cookie.
HTTP/1.1 302 Found Cache-Control: no-cache Pragma: no-cache Content-Type: text/html; charset=utf-8 Expires: -1 Location: /devices.aspx Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 Set-Cookie: DDNS=user=a@test.com&pass=dGVzdHBhc3M=; expires=Fri, 05-Jun-2015 14:25:24 GMT; path=/ X-Powered-By: ASP.NET Date: Thu, 04 Jun 2015 14:25:24 GMT Content-Length: 132 <html><head><title>Object moved</title></head><body> <h2>Object moved to <a href="%2fdevices.aspx">here</a>.</h2> </body></html>
There really is no excuse for this either. This is what session tokens are for.
Password check from cookie is case-insensitive
Each time a page is viewed, the password is checked from the cookie. Because the database stores the password in base64 and the cookie is in base64, they are directly compared.
However, this is done in SQL which is by default case-insensitive.
This means that the base64 string of dGVzdHBhc3M= (testpass) is just as valid as DgvZDhbHC3m= or any of the other variations.
No password brute-force protection on cookie
Whilst the login form has brute-force protection (“FloodCheck”), the cookie doesn’t have any brute-force protection. You can just chug through passwords as quickly as you like.
Brute-force cookie password – long response indicates success
A lack of brute-force protection is common on cookie values, but usually the token is a lengthy session token with enough entropy to mean this is not an issue.
Password reset is insecure
On attempting to reset a password, the first step is to provide the email address.
Once this is done, you are presented with a security question:
This has no brute-force protection in the form of lockout or captcha, so off we go with a brute-force attack – against something that has a lot lower entropy than a password. I’d wager that a list of 100 common foods, 100 common cities and common phone number formats would yield a vast majority of accounts.
But when we get the question right, how does it deal with it?
That’s right! It puts the original password into the cookie, base64 encoded!
Conclusion
I stopped looking at this point. MintDNS has enough issues that I wouldn’t use it. Reviewing the .aspx files indicate to me that the development is ad-hoc and a bit naive. The website doesn’t really indicate that the software has been updated in the last 5 years.
I found a couple of instances where user input was reflected back in the response, but there are basic XSS checks combined with the IIS/ASP checks, so it did not appear to be exploitable.