MintDNS dynamic DNS software – multiple vulnerabilities

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

Users table

Admin 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:; 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>

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

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:
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?

Cookie with original password

That’s right! It puts the original password into the cookie, base64 encoded!


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.

Leave a Reply

Your email will not be published. Name and Email fields are required.

This site uses Akismet to reduce spam. Learn how your comment data is processed.