Security Incident - DNS Hijacking
This post is intended to provide an accurate record and notification about a Security Incident (SI) that affected a RustProof Labs owned and operated website. The SI was a case of DNS Hijacking that took place on 2/19/2018 starting around 9:00 AM MST and affected all domains under the trackyourgarden.com domain. The SI was resolved by RustProof Labs staff and normal site operations were resumed at 3:20 PM MST on the same day.
No RustProof Labs owned data, systems, or servers were affected or compromised.
In the early hours of 2/19/2018, I logged into our domain registrar's website in order to renew a couple domain names, one of them being the domain for Track Your Garden. While I was logged in, I double checked a few settings, one of them being that the domains were locked against accidental change. The settings were set correctly as I expected, I logged out, and went about my day. A few hours later at 1:50 PM I discovered that all Track Your Garden domains were throwing an invalid TLS certificate error.
It was instantly obvious that there was something wrong, and a big clue was that the TLS certificate that was being served by the browser was for *.domain.com. I quickly found that the DNS nameservers had been updated to a site I had never heard of. This was bad.
I immediately knew it wasn't right because our DNS for this site has pointed to Digital Ocean's nameservers for a long time. I had also never seen the invalid nameserver URL before. Immediately, I checked all our other domains and this was the only one affected. I updated the settings to fix this domain and started documenting what I had found.
The above steps took a total of 7 minutes, including capturing the screenshots before fixing the problem. Due to the nature of DNS, it took until 3:20 PM for our site to start resolving properly. Considering the slow nature of DNS propagation, I was pleased with only waiting 83 minutes.
How It Happened
We don't know for sure. Based on the terrible reaction I got from domain.com's "help", we'll probably never know. My best guess is that there is some sort of vulnerability in their system that allowed either an true insider there or a malicious 3rd party the ability to change my settings. Domain.com's support has claimed they don't have an audit trail showing who made the change, and instead tried to flip blame me.
The point I would like to make here, is that even if my claim and suspicions are incorrect, domain.com has a responsibility to care about claims of major security violations, and this shows an obvious lack of concern.
While I was "on hold" with their support chat I did some searching for the names involved in this issue. One reference I found talked about the specific domain that my hijacked domain was pointed to.
It appears that this particular domain is owned by a conglomerate with iffy ethics and business practices in general. Considering that my nameservers were automatically updated to point to that domain, apparently from within domain.com, it seems probably that there's an affiliate thing, or partner relationship going on.
While this is far from proof, it does seem suspicious.
No RustProof Labs owned data, systems, or servers were affected or compromised beyond being unavailable for a short time. The larger impact of an SI like this is the staff time it takes to deal with a situation like this. With zero data breached, it has already cost RustProof Labs a few thousand dollars between hard costs and lost opportunity costs. Because while I'm typing these words right now, I would much prefer to be working with code. This time represents features we aren't building and bugs we aren't fixing.
Reducing Future Risk
We are currently working on moving our domains to a new domain registrar. Unfortunately, this incident has proved that there is no way to fully protect against problems like this from occurring. We are working on improvements to our automated monitoring and reporting systems to report this type of error more quickly. The resolution can't get much faster due to DNS propagation timing, but our initial detection can improve.
Published February 21, 2018
Last Updated February 21, 2018