From DNS Attacks to Input Validation and (Zero) Trust

I have been reading this article on DNS attacks which also reminds us that if an attacker controls a DNS server or is able to poison a DNS cache, malware or at least unsafe data can be transmitted to a target application. DNS data is anyway data in input to an application, and as such it should be validated prior to any processing. Instead it can happen that it is considered as trusted data, in particular if DNSSEC is used. 

Unfortunately the situation is a little complex: with very few exceptions (as for example “DNS over HTTPS – DoH“), applications do not directly retrieve DNS data but make the Operating System do that for them. And any application trusts the Operating System on which is running, which should imply that data received from the Operating System should be trusted, or not? Which System Calls should an application trust and which it should not? Which kind of data validation should an application expect to be done by the Operating System on data passed through System Calls? The Devil and unfortunately the Security is in the details…

Which brings me to consider the concept of zero trust in this respect: first of all, in IT we always need to trust the security of something, at least of the Hardware (eg. the CPU), and unless we look at Confidential Computing (see here for example), then we need to trust also quite a lot of Software. 

So we are back to Input Validation, which can make applications bigger and slower and in some cases even more difficult to maintain, but accepting in input only data in the format and content that we expect, make for sure life much safer.

The evolution of DNS

DNS, that is the Domain Name System protocol and services, is a fundamental pillar of Internet since it allows to resolve domain names in IP addresses. Recently the number and severity of attacks to the DNS infrastructure have increased noticeably (see for example this US-CERT Alert). At the same time, the discussion on who should manage and how this global infrastructure should be managed, keeps expanding.

Alternative proposals to the ICANN overseen global DNS infrastructure have appeared, starting from the “.onion” hidden TOR domains to, among others, the more recent OpenNIC project and the Blockchain-based BDNS system.

The security and privacy of Internet access and navigation depend crucially on the resolution of domain names to IP addresses. Even if the deployment of DNSSEC will help to improve security and privacy, it is badly needed to give more consideration DNS and help designing a forward path for it as a global service which must be able to guarantee access, privacy, security, integrity, fairness etc. It is a lot to ask, but we will really need it.

Monitoring Outgoing Traffic to Detect Intrusions

Monitoring outgoing traffic to detect intrusions in IT systems is not a new concept but often it does not seem to be enough appreciated, understood and implemented.

IT security defences cannot guarantee us against every possibile attack, so we must be prepared to the event of an intrusion and to manage the associated incident.

The first step in incident management is to detect an intrusion. Traditional tools like Anti-Virus, Intrusion Detection/Prevention Systems (IDS/IPS) etc. do their job but they can be bypassed. But intrusions can also be detected by monitoring the outgoing traffic.

In my recent personal experience, some intrusions have been detected and stopped because the outgoing traffic was monitored and blocked. Since the deployed malware was not able to call back home, it did not do anything and there was no damage; and since the outgoing traffic was monitored, the intrusion was immediately detected.

But monitoring the outgoing traffic to detect intrusions is becoming more and more difficult. For example attackers are adopting more often stealth techniques like using fake DNS queries. An interesting example has been recently described by FireEye in “MULTIGRAIN – POINT OF SALE ATTACKERS MAKE AN UNHEALTHY ADDITION TO THE PANTRY” . In this case, malware is exfiltrating data by making DNS calls to domains with names like log.<encoded data to exfiltrate>.evildomain.com . Obviously the DNS query fails, but in the logs of the receiving DNS server it is written the name of the requested domain, that is the data that the malware is exfiltrating.

As attackers are getting more creative to hide the back communication between malware and their Command & Control services, IT Security will need to devise more proactive approaches to monitoring and blocking outgoing traffic.

Social Engineering, Password Reset and DNS Hijack

The DNS provider Web.com has been subject to a Social Engineering attack which allowed a pro-Palestine hacking gang to successfully reset the password of a few important customers, and use the new password to change the resolution of their domain name to other sites. See for example here for a description of the attack.

Again and again, as of today the technical side does not look to be the weak side of  ICT Security. In particular cryptography is sound and reliable, and many technical ICT security products deliver what the promise.

On the other side, username + password show another time how much inappropriate they are to support our current security needs. But what can we use instead?

The general problem lies mostly in our ability to make a system “secure” by including logical, physical and procedural measures to give a 360 degrees protection. Indeed, the security level of a system is that of its weakest point, which for most systems means that they are really insecure.