BetterOS.org : An attempt to make computer machines run better


home | better linux | games | software | tutorials | reference | web log |

Web Log: index |

Web Log

February 22, 2016 - Dynamic DNS and Basic Security

February 22, 2016

Dynamic DNS and Basic Security

Recently, I moved into a new apartment. The move itself went fairly well, one truck, one trip. However, the real challenge started after that, and is still an ongoing effort: setting up my home network.
I assume most people plug in their router (or have their ISP do it for them) and turn on WPA, and then they are happy. I, however, would never be happy with any part of that. I demand that my ISP allow me to use my own router, which isn't good enough if I can't ssh into it. I need at least a 16 port switch in addition to that. Everything must be connected via ethernet. Each device must have a unique and memorable hostname following my own naming convention, and the router must have a DNS server that allows those hostnames to resolve correctly. Finally, I need to be able to securely access my network from anywhere. As you can imagine, the whole process takes time, but the last part is what I want to talk about.

Port forwarding is no issue, since I have a beautiful router running on open source software. SSH is no problem thanks to Dropbear. However, remembering an IP address is not fun, and it's dynamic anyway, so it changes all the time. The solution of course is a dynamic DNS service.
In the past, I used hopper.pw, which was a very excellent service, all free and open source and all around perfect. But alas, hopper.pw is no more. So I set out to look for another service. A family member was using ddns.net. Since most of my family is reasonably more competent than even the "tech savvy" individual, I thought it was a safe bet, and it was my first destination. I signed up, entered my username and password, and then it asked me to download their client. Of course I ignored that and clicked stuff until I found the page that said "API".
On the API page there is a bunch of nonsense about setting user-agents to prevent getting blocked and stuff, bet essentially, it's just an HTTP GET request, for the layman, I'll summarize it in plain English: "go to a webpage".

So yeah, that is now considered an API. Anyway, I implemented a client using their API as a shell script. It didn't work. Response everytime was "nochg x.x.x.x" (with x.x.x.x being the IP I made the request from, and I tried it from several. Not once was the DNS record updated, and the server refused to even send me an error if I put in the wrong password. So they don't even follow their own API properly.
I did this all using a dummy password because I fortunately noticed the really disturbing part (and glaring) issue with their API, the fact that it uses HTTP Basic Access Authentication, and the update password is the same as the account password.

Now this might not sound so bad if you are familiar with security, you hear "authentication" and "password", and think you are good, which might be just what the developers did. However, this is just about the worst case scenario from a security point of view. HTTP Basic Access Authentication uses base64 encoding for everything, which is not encryption, it's just a different way of encoding data. Effectively, its plain text. This means that anybody listening on your connection just got your password and username, and can now hijack your hostname and do all kinds of nasty stuff. It opens the door for man in the middle attacks, STARTTLS stripping attacks, or just listening for more passwords. It's real not good. On top of that, since the password is the same as your account password, your whole account is now compromised, hope you didn't pay for the "upgraded" service and save your credit card info.
And then what if the server gets compromised? What does their database look like? Are they doing unhashed password matching on their server (as it really looks like they are doing)? If so, this means they have a database with your plain-text passwords. If not, then an intruder need only do a packet capture and build the database themselves.

Anyways, before demonizing ddns.net or noip.com, I decided to check their official client. I had to give them the benefit of the doubt because I saw a few things which could save them from being the worst ever. One, it appeared that they accept HTTPS connections for updating, if this is what the client does, it mitigates the massive security hole they created with their stupidity, and two, since their API doesn't work, maybe their official client doesn't follow it (and uses something secure). So I downloaded their client and ran it (with all dummy info, of course), and here is what I found:
http://dynupdate.no-ip.com/ducupdate.php?requestL=dXNlcm5hbWU9ZmFrZSZwYXNzPXBhc3N3b3JkJmhbXT1mYWtlLmRkbnMubmV0JmlwPTE0LjE0LjE0LjE0

Cool, worst fears confirmed. They don't use Basic Access Authentication, nor do they use their own API, but what they use is %100 just as bad:

 $ base64 -d <<< "dXNlcm5hbWU9ZmFrZSZwYXNzPXBhc3N3b3JkJmhbXT1mYWtlLmRkbnMubmV0JmlwPTE0LjE0LjE0LjE0"
username=fake&pass=password&h[]=fake.ddns.net&ip=14.14.14.14

Of course that's not my real information, my real account has been deleted. Please, do not use ddns.net or noip.com (they are the same). Also, make sure any online service you are using is using reasonable security. I'm not even a security expert, but I know a glaring vulnerability when I see it. Don't just assume you are safe because you entered a password.

Anyways, that's all for now. Peace.