I can only imagine it’s a high stress job doing IT support for Kim Jong Un as he’s the kind of manager who probably watches you over your shoulder, touches your screen a lot and drops dark hints about “disappearing” your family for three generations if the patches don’t get deployed properly.
While we often hear lots about massive companies leaking data, state sponsored hacking and the latest about exotic encryption methods, most security issues that you’re likely to see day-to-day are the result of easily made mistakes in system configuration.
Which is exactly what happened to the Democratic Republic of North Korea’s (DPRK) root DNS servers last week. The misconfiguration accidentally allowed anyone on the internet to query their Top Level Domain (TLD) for a full listing of all their internet connected servers:
https://github.com/mandatoryprogrammer/NorthKoreaDNSLeak
The only website in North Korea with a smiling tiger on it.
While regrettable, this is still a fairly minor security issue as it didn’t actually provide access to any systems. What was exposed was simply the very knowledge that these systems exist.
Look – there are plenty of ways to do inbound host discovery on a network if you’re attempting to break into it, so it’s not like this data was particularly unknowable or sensitive. Two factors make this exposure particularly embarrassing:
One: This was definitively not the result of some kind of nation state zero day attack by an elite red team.
Two: The fact that the DPRK has only 28 servers on their entire network. If not for this, it probably wouldn’t be news (though honestly, it is legitimately HILARIOUS that they have fewer hosts than the branch office of some sleepy midwestern insurance company).
What makes this so relatable are the really mundane aspects of the situation, which could happen with almost any IT project, at any size company, in any industry, in any country:
- They were likely trying to migrate/backup to a secondary server their DNS configuration. Exactly the same as you might do if you were worried about your own sites going offline if your were trying to dual home the DNS services for your sites.
- The issue was discovered by an automated system that is continually requesting zone transfers from all TLDs and many corporations – just waiting for someone to screw up.
- It’s a wildly _undramatic_ issue, with no outward indication that something is wrong. No user is going to call your helpdesk complaining about zone transfers outside the network suddenly being possible.
It’s actually really simple to test to see if you’re accidently exporting a map of your network out the greater internet.
How To Test if you have externally accessible DNS zone transfers enabled:
With the dig utility run the command on a computer outside of your network:
dig axfr yourdomain.com (optional nameserver)
You should see a “Transfer Failed” response:
If you don’t have dig handy, you can also try the online scanner: https://hackertarget.com/zone-transfer/
What should I do now?
Below are three ways you can continue your journey to reduce data risk at your company:
Schedule a demo with us to see Varonis in action. We'll personalize the session to your org's data security needs and answer any questions.
See a sample of our Data Risk Assessment and learn the risks that could be lingering in your environment. Varonis' DRA is completely free and offers a clear path to automated remediation.
Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things data security, including DSPM, threat detection, AI security, and more.