DNS and Depression

Hello everyone, I hope you had an excellent winter break, and an awesome new year.

I wanted to talk about a couple of things that have been inextricably linked for me. Obviously I am talking about DNS and depression.

I suffered from depression some time ago, or at least that was when my depression was at its worst. I feel like it never really leaves me. It hangs around like a miasma, a putrescent bad smell.

I got better.

I’m not sure it is something that I will ever beat, in that it seems like it is a part of me. There are good days, and there are bad days. As when people say that others are battling cancer. You are fighting with a part of yourself. It is probably the least good part of me, but it is a part of me none the less.

This may come as a shock to most of you who know me, as I do not seem like the stereo-typically depressed person, whatever that is. I am perennially upbeat, always smiling and making jokes. Terrible, terrible jokes.

The first time it found me, my depression gradually crept up on me a day at a time, until I could no longer bear it, and a few days of hiding under a duvet kicked me into the realisation that something was seriously wrong with me. I say wrong, but I see it as more of a error in configuration or bad calibration of my brain. That is not what it is, but it is how I choose to view it.

I feel like it is actually a part of me, to the same extent that the terrible jokes and the smile are.

I do not think the long Swedish winters help. Working in an office where I would rarely see daylight, and its fleeting embrace could be felt only en-route or returning from the lunch restaurant had certainly contributed.

Depression is an immensely complicated mental disease, and absolutely nothing I write here will do the complexity of it justice. In fact what I have written so far is already doing it, and its millions of sufferers an injustice.

I felt the creeping dread that was so familiar, just a few weeks ago. The sensation of its tendrils slowly emerging from the darkness and wrapping themselves around me, slowly and softly as to not make me startle and see it for what it truly was.

DNS saved me.

I had been working on an update to a script that I had made a few months ago. You can find that original script in this post here. I had been working on this second version of an information gathering script for at least a week during the holidays, and for a day or two at work. My hope was that I could use it as a big signal if something changed.

The big picture idea was that you would run the script, it would gather the information in a file, then you could make a hash of that file, and compare it to the previous one.

It was ballooning in size, and I kept adding features. This is usually termed ‘feature bloat’ in the software industry. I was getting things done, but I was also trying to make everything consistent, and to make sure there were no bugs. I was acting like a developer.

I was writing everything in Python, and trying to make it as elegant as possible. No calling obscure third party programs that the user would have to install (dependencies), I would examine them and add the functionality from them wherever possible.

Well the script got bigger and bigger. The functions harder and harder to track. The more I wrote, the more I admired the people at my job who do this for a living. Their codebase is likely a thousand times bigger than my few hundred lines, and orders of magnitude more complex.

Those tendrils started enveloping me. I could feel them.

Then I read an article that someone posted to LinkedIn about the “two types of programmers in this world”. Give it a read if you have time, it is only about 5 minutes, and is a really good comparison of what I see as two different approaches to problem solving.

The long and short of it is that if you hack things together, they will work straight away, but be difficult to maintain going forwards. If you are an “academic” as the author styles it, then you will deliver quality software in a less swift manner. The features may come, and they will be maintainable when they do.

Hackers are for startups, academics for healthcare/finance.

I would disagree only in that I would call the academics straight up developers. I have not been developing software for anywhere near the amount of time the author has, so will defer to his expertise. Perhaps I have just been exposed to developers that are also academics, or are working in that fashion.

I am, as we have discussed innumerable times previously, not a developer.

It was this realisation that I do not actually have to make giant elegant solutions to problems that made me feel as if the tentacles could be beaten back. My script was imagined to do around 15 things, and to do them perfectly. I was never going to get it right.

I even had user stories up on the white-board next to me along with a map of the functions, and what they all did. Did they return lists, dictionaries or tuples? Strings?

It was all too much.

I had been here before, I knew the territory, and still had a mental map of the route out from under these clouds. I had read a few times years previously that Abraham Lincoln used his work to battle what everyone around him called “his melancholy”, but has been since recognised as a clinical depression. It had worked for me the last time, and to my mind there is no reason for its efficacy to be doubted to work this time. To work we would go.

Stark realisation beneath my belt, I hacked something together in 90 minutes, and the metaphorical clouds lifted. My disposition illuminated by an order of magnitude, and I could finally smile and feel like it was real, and not just going through the motions. The energy I felt and still feel is what has compelled me to write this.

So let’s start talking about DNS, which is what saved me.

At a high level, DNS (Domain Name System) is a (suprise!) naming system for “stuff online”. If you want to go to google.com, you type that into your browser. As google.com actually resides at an IP address, your computer will ask a couple of servers online if they have the IP address of “google.com” and then once they retrieve it, they will direct your browser to that IP address.

This is super useful for us humans, as words are easier to remember that four sets of between 1 and 3 digits, strung together with dots. And that is just for IPv4. IPv6 is crazy long. Imagine having to remember this for every website you wanted to visit.

“2001:0db8:85a3:0000:0000:8a2e:0370:7334”

DNS is super useful.

DNS also has its downsides. One of those is in the way that DNS is trusted. Imagine if you could be that server in the above example which replied to our computer telling us which IP address to visit. We could tell everyone that they should be visiting our malicious site instead of the real google.com.

Let’s walk through a very brief example with “www.google.com”.

The server that our operating system asks is called a Name Server. Unbeknownst to us, our computer is actually asking for “www.google.com.”. That period at the end there is not a mistake. That last dot represents the ‘root’ name server. It is the name server that, if nothing else, knows in which direction to point us.

Let’s imagine that the root name server does not know where www.google.com. is. It will direct us to the “next best area”. The next best area in this case would be the Name Server for all domains with the suffix “.com”. “www.google.com” is made up of three parts. Subdomain (www), domain (google), and suffix (com).

The name server for the “.com” suffix is said to have a “zone of authority”. This just means its the place to go for asking where .com related stuff is. Let’s again imagine that this name server also has no idea where www.google.com resides. It will forward us to the next branch in the tree.

The name server we are now asking is authoritative for “google.com”, and does know where “www.google.com” is, and sends us the IP address, and our browser requests the page.

That name server that knows where “www.google.com” lives also knows where all other subdomains of googles live too. That means that it know where “api.finance.google.com” lives.  It also knows where “testing.firewall.all.ports.open.google.com” lives. That sounds like an incredibly weak and insecure place.

I have chosen these names at ‘random’. I don’t know that they exist, but the theory is there, and ripe for exploitation. The only question is, how to get the name server that is authoritative for “google.com” to give us the answers?

I have covered subdomain brute-forcing in a previous post. That is one way to get the list of subdomains, by exhaustively asking for a DNS record, and hoping that it exists. If it does, we add it to the list of known good subdomains, and keep asking until the list is empty.

There is, however, another way.

It is called a “DNS Zone Transfer”, and is one of the ways in which name servers update each other. Most domains will have between 3-5 Names Servers, for redundancy and latency requirements. This site has 3.

If you can perform a zone transfer against a name server, then you can receive every record that name server contains about a given domain. Name servers are usually configured to prevent exactly this transfer of data.

Linux contains a tool called dig, which stands for Domain Information Groper. Dig can ask a domain for the names of its name servers. It can also ask a name server for a zone transfer of all records it contains for a given domain.

The syntax for asking for name servers in dig is as follows.

dig NS example.com

It returns output that is preceeded by a few semi-colons, and other pre-amble. It looks like this.

 

We can reduce the noise here a bit by using a few extra options, such as

dig +noall +answer NS example.com

Then we get back a list with five fields, and those periods at the end of the name servers. We now know which name servers are authoritative for example.com!

Next we can ask the name server if it would (kindly) transfer all records it has on the domain in question to us. The syntax for that is as follows.

dig axfr +noall +answer example.com @name.server.example.com

This will then return a list of all the records that name server keeps for the domain. Pretty simple, but obviously we want to automate it. I spent perhaps around 8 hours wrangling with a library called dnspython, which I’m sure you can guess the purpose of.

The script was supposed to ask the virus total api for a list of name servers, along with known subdomains, and then try to transfer all those domains. This was walking down the path of development.

Once I had overcome the miasma, I banished all thoughts of elegant solutions from my mind. Let’s just call dig from the shell from within the script. It is the opposite of elegant, it is certainly not portable, and error handling is at best, bad.

The syntax for running this is “python script.py example.com”, obviously provided you save it as script.py.

For 18 lines, its not as hacky as I thought it would be, but from a maintainability/features standpoint, it is very hacky. I feel remarkably OK with that.

You should also expect this script to fail. You should expect it to fail all the time. That is fine. Zone transfers are not something that should be enabled on any name server at any time. It is obviously a huge security risk.

There is one exception.

Zonetransfer.me is a domain set up by a security researcher called DigiNinja that I follow on Twitter. It is set up specifically to allow zone transfers as a way of demonstrating how insecure they can be. I have included the output of a full zone transfer against the zonetransfer.me domain at the end of this post, so that you can see what one looks like, and how insecure they can be.

There are 200+ lines of potentially very valuable information, including comments from the person maintaining the name server, which contain email addresses, names, telephone numbers etc. Some of the subdomains are also very interesting, including, in this fictitious example, the fact that the company has more than one office (Canberra and dc_office are mentioned).

There are test servers and staging environments and many more tidbits of information in just these records. If you want to read the full take on DigiNinja’s site, then I absolutely encourage you to do so here. I would also like to apologise to him if I was spamming his domains with zone transfer requests too much in the making of this script. I think I managed to get myself rate limited (just a bit 🙂 ).

So that is it for this blog post, I hope you all have a fantastic week!