This is a customer’s story of a recent security incident and how Glasstrail helped them discover it. For privacy reasons we have not identified the customer. If you have a story you’d like to share for the benefit of the Glasstrail usercommunity, please get in touch.
I am a longtime customer of Glasstrail and my SecOps team reviews our Glasstrail findings on a regular basis, processing any critical and high issues found in our external attack surface with a matter of urgency.
Usually this might be a new breached account, where they will contact the end user and walk them through updating their password to something long, strong and unique, other times it might be a certificate expiring or a new vulnerability.
Last week, one of my SecOps engineers noticed a high vulnerability for a website associated with one of our domains in our Glasstrail report.
Details of the Glasstrail finding
AJavaScript library has been found on a website with some security vulnerabilities.
If you have JavaScript vulnerabilities you should be performing some form of vulnerability scanning to ensure you don't have any other issues that could beused against the site.
A high severity issue was found in library AngularJS@1.3.1 which has 14 vulnerabilities.
More details ... https://snyk.io/vuln/npm:angular?lh=1.3.1
Sometimes, vulnerabilities can be indirect. For example, the identified vulnerability may relate to:
- 3rd party applications running on your site
- Scripts added – e.g. by Google Tag Manager or similar
- A dependency – e.g. your site uses a package, which in turn uses a library with a vulnerability
They immediately contacted our developers to understand whether this site was under their care. But it wasn’t. The more we investigated, the more suspicious things looked.
The website being hosted on a URL that at face value looked like one of our sites, but on taking a closer look, the content wasn’t on brand and some of the links didn’t link to anything related to our business. It was a fake site with fake data. Not good!
Had our website been hacked? How was this possible? We have robust security on our web development tools and related processes – what had gone wrong?
Upon closer look at the impacted URL, it belonged to a service we had decommissioned last year. The server and service it was hosting were offline, but the service at the URL was still very much alive, online and not in our control!
And that’s when we realised we had a ‘dangling DNS’!
What is a dangling DNS?
A ‘dangling DNS’ refers to an obsolete DNS record that points to a resource or service that no longer exists, is no longer in use, or is not under the control of the original domain owner.
A common scenario where this happens is when an organisation uses a cloud service and creates a DNS record pointing to it. The service is later decommissioned or deleted, but the DNS record is not updated or removed and as a result itbecomes "dangling".
What can happen then, and happened to us, was that we were victims of a ‘subdomain takeover’. A malicious actor discovered this dangling DNS record, in fact they use automated tools to scan for such vulnerabilities! Once identified, the attacker registers or provisions a new service or resource with the same name or IP address that the dangling DNS record is pointing to. And because our DNS record is still pointing to that name, any traffic intended for our service was now routed to the attacker's newly controlled service/website. Genius.
We were extremely lucky – in this particular case, the service this hijacked DNS record hosted was just a site used to create backlinks to websites for SEO purposes. But it still had elements of our brand on the page – to avoid easy detection – so there was brand reputation impact from this association.
A more malicious hacker could have used the sub-domain to host a phishing or malware site which, given it was associated to our domain, would have had much bigger reputation problems.
All we needed to do was delete the DNS record and the malicious hacked site was no longer online.
There’s a lot we’ve learned from this incident! We needed to improve our DNS hygiene, we now have processes in place to regularly audit and cleaning up DNS records that are unused and which can lead to dangling entries. We are improving our change processes when decommissioning services.
We are super grateful for the service Glasstrail provides us and for helping us identify this particular issue – keep up the great work!
– Happy Glasstrail Customer
If you’d like to learn more about how Glasstrail can help you keep your external attack surface clean then please let get in touch.
