Varonis announces strategic partnership with Microsoft to accelerate the secure adoption of Copilot.

Learn more

How to setup your DNS Server like North Korea

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...
Michael Buckbee
2 min read
Last updated October 22, 2021

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:

michaelbuckbee_-_bash_-_80x24

If you don’t have dig handy, you can also try the online scanner: https://hackertarget.com/zone-transfer/

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.

Try Varonis free.

Get a detailed data risk report based on your company’s data.
Deploys in minutes.

Keep reading

Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.

securityrwd---introduction-to-aws-lambda
SecurityRWD - Introduction to AWS Lambda
Join Kilian Englert and Ryan O'Boyle from the Varonis Cloud Architecture team as they discuss AWS's serverless computing platform, Lambda. Find out what the Lambda functions allow for, see an everyday example of how it all comes together, and learn why it's so important for organizations to monitor Lambda's behavior within the entire Amazon Web Service ecosystem.
securityrwd---introduction-to-aws-services
SecurityRWD - Introduction to AWS Services
Kilian Englert and Ryan O'Boyle from the Varonis Cloud Architecture team kick off a new series diving into the various services found under the AWS umbrella. In this video, they introduce and provide an overview of some of the core services including IAM, S3, and EC2.
how-a-doggo-can-teach-you-the-difference-between-salesforce-objects-and-records
How a Doggo Can Teach You the Difference Between Salesforce Objects and Records
What can Fido teach you about Salesforce? Kilian Englert and Ryan O'Boyle from the Varonis Cloud Architecture team host a special, goodest boy guest to explain the difference between objects, fields, and records in the popular CRM.
securityrwd---introduction-to-aws-simple-storage-service-(s3)
SecurityRWD - Introduction to AWS Simple Storage Service (S3)
Kilian Englert and Ryan O'Boyle from the Varonis Cloud Architecture team compare and contrast Amazon Web Services S3 to traditional on-prem storage systems. Listen in as the team discusses how AWS S3 goes beyond basic data storage, and enables programmatic access to apps and services inside and outside the AWS environment.