DNS Queries in the LAN: an interesting source of information

Observing DNS queries inside your LAN is a very simple way to detect security problems and/or various misconfiguration issues.

The only pre-requisite for the operator: a good knowledge of his network infrastructure and technologies. The operation can be realized with the builtin Windows features, enabling the DNS debugging (http://technet.microsoft.com/en-us/library/cc759581(v=ws.10).aspx)

I prefer use a simple tool “NirSoft DNS Query Sniffer” available here: http://www.nirsoft.net/utils/dns_query_sniffer.html

1/ Copy and launch it locally on your DNS server. DNS queries appear in real-time.

2/ Stop the acquisition

3/ Analyze in the GUI or export in a file

...easy and simple.

Examples of use:

-          Internet Explorer configuration issue:

A request to wpad.landnssuffix indicates the use of Web ProxyAuto-Discovery Protocol by clients. Of course you can always retrieve IP adress of the requesting source in the dedicated column on the right side (not shown on screenshot) and modify the browser settings as convenient.

 

-          Misconfiguration of a client process:

Here we can see a double dns suffix generating an error. The client, for an unknown reason append the lan dns suffix twice.

 

-          Browser Addon characterization and detection

Look at the Ask toolbar in action and find the clients

 

 

-          Usage of Network Connectivity Status Indicator:

A good explanation can be find here http://www.techrepublic.com/blog/data-center/what-do-microsoft-and-ncsi-have-in-common/

-          CRL checking :

 

And this…

Microsoft puts non-qualified domain name in some certificates. They contain the following CRL distribution point: http://corppki/crl/Microsoft Secure Server Authority.crl which probably only works inside Microsoft LANs.

 

-          Malware detection:

The more powerful usage according to me. Example of requests done by an infected client.

-          Other cases:

Be aware of isolated systems that don’t have internet access and realize outside DNS requests. It can be a data exfiltration in a covert channel
(see https://blog.gdatasoftware.com/blog/article/new-frameworkpos-variant-exfiltrates-data-via-dns-requests.html and http://bernardodamele.blogspot.fr/2012/06/data-retrieval-over-dns-in-sql.html )
 

Capturing DNS queries is an easy way to observe your network infrastructure in action. There's a lot of stuff to do with this little tool. Thanks Nirsoft!

Chicks & Risks

A few years ago, when I started to study Infosec, I was living in the countryside of Provence.
My home was in the middle of a walled garden. I had a dog too. Good, but very unruly! Always jumping everywhere and eating everything. I never succeeded in training him.
One year, at Easter time,some members of my family decided to be innovative when thinking of a gift for my children. They bought 4 young chickens. Wow “What a nice idea !” I replied but with a bad feeling.

At that time, the young chickens were small and lived in a box under a warming light. They had to stay inside the house for 3 or 4 weeks. It was at that time I noticed the behaviour of my dog. He remained outside, his face stuck to the glass window, looking for the chickens with the ever-present idea to “play” with them.

At that time, I realized too that there was only 4 weeks left before the chicks needed to housed outside, I needed to build a strong hen house. A henhouse the dog could never defeat!

So I do ! Building a henhouse is a nice family project. Everybody was involved but I was the project manager: solid metal wire was pegged around the perimeter. Fixing fence posts were cemented in to the ground. Inside the enclosure we built a though wood house where the chickens could be safe. Quickly, the work was done and the hen house and enclosure completed. Before releasing the chicks inside, I checked on several times the overall security off the building. I was proud of our work and was in no doubt that it was impossible for the dog to get inside.

So the chicks were released. It was a success. During the first few days, the dog kept looking at these new guests, sometimes barking but never trying to penetrate the henhouse defences. From their ivory tower, the chickens got used to his presence and behaviour. They were so used to the dog that eventually they paid no attention to him. Instead, they spent their lifes walking around the enclosure eating and sleeping.

I noticed that the chickens particularly appreciated eating blades of grass within the hen enclosure. They systematically ate them all so it was progressively impossible to find any grass inside the run.

One day a chicken passed his head through the metal wire to eat a blade of grass. The dog quickly appeared, grabbed the chicken’s head and well you can guess the rest!

What Infosec lessons can we learn from my henhouse?

When conducting a risk assessment it is often the case that we concentrate on the external threat. Or, in this case, the threat from the dog to the chickens. As the story highlights this is not a thorough or complete assessment of risk.
In my case by only considering the threat of the dog’s behaviour, it led me to develop controls, in this case a wire mesh fence, to prevent the dog getting inside the hen coup where my chickens could be found.  I had forgotten that the objective of my efforts  was to protect the chicken and not just stop the dog.

Thinking in the context of the asset you are trying to protect should never be limited to the malicious threat. In my analogy  I did not consider the chickens behaviour as a threat in its self. Neither did the risk assessment consider the role of grass or the lack of it play in the chickens behaviour, would result in an increased risk. If I had, I would have recognised  that chickens eat grass, and that, when they had eaten all  the grass in the hen coup,  they would be tempted to eat the grass outside of the coup. And, for them to eat the grass outside of the hen coup, they would need to stick their head through the wire mesh fence which was designed to keep the much larger dog from getting through. Recognising this I would have used a finer wire mesh that even the chicken could not get their heads through.
In Infosec, a risk assessment ought to consider the whole environment, within which the asset operates, which may influence the likelihood or impact of an event happening. This should include both internal and external factors.

Processes, information systems, people, facilities which host these systems and people and the geographical location of the assets  to all need to be considered. But this is all only part of the picture. Political, economic, social, technological, environmental and legal factors, all outside of the control of the organisations can also have an effect on our exposure to information security risks.

Le monde après Snowden

Les retranscriptions du colloque par la Chair Castex à l’assemblée nationale le 13 Mars dernier «le monde après snowden » publiées en intégralité sur le site le Monde.fr.

 

http://www.lemonde.fr/pixels/article/2014/06/27/geopolitique-big-data-et-democratie-le-monde-apres-les-revelations-d-edward-snowden_4446858_4408996.html?xtmc=castex&xtcr=1#