|
||
FireEye announced a new piece of malware yesterday named MULTIGRAIN. This nasty piece of code steals data from Point of Sale (PoS) and transmits the stolen credit card numbers by embedding them into recursive DNS queries.
While this was definitely a great catch by the FireEye team, the thing that bothers me here is how DNS is being used in these supposedly restrictive environments. Even the FireEye researchers state that in order to resolve hostnames in the corporate environment, the recursive DNS servers must be able to access the public Internet.
That’s not really true, though.
The best protection against attacks like this is to block recursive queries to the public Internet. The great thing with going cold turkey is that one can still configure his DNS to be able to resolve all hosts inside the perimeter defence of the enterprise network.
Here’s a simple two-step guide on how to do it:
When a recursive query is made to a DNS server that is also authoritative for the queried zone, the query will be replied from the memory. In cases where the DNS server is not authoritative for the queried zone—and the DNS server has no access to the public Internet—the resolution process will fail and no authoritative response will be provided to the client that made the query.
The great thing about this simple solution is that it works much better than the “monitor and review” recommendation made by the FireEye research team. After all, if the DNS servers in protective network environments can only function within the boundaries set by the perimeter defense, it becomes impossible to use attacks like MULTIGRAIN to transmit stolen data outside.
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byCSC
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byRadix
Sponsored byVerisign
A World-Renowned Source for Internet Developments. Serving Since 2002.
DNS is mostly seen as the protocol that translates names into addresses.
As such a mandatory service in most networks and DNS is more or less considered to be part of the furniture.
Hardly anybody expects a piece of furniture to be dangerous.
But the way DNS operates it is actually a connectionless transport protocol.
As such it allows data exfiltration, like card numbers, and infiltration out and in of any network where nodes are allowed to have public DNS resolving.
By no means new, and my own talk on the subject, in october 2014, was by no means the first (nor will it be the last) to warn and show safer approaches :
Designing DNS flows for security.
That's true Marco, my suggestion only works well in restricted environments where access to the outside world is not needed. This is relatively common, though - PoS is a good example but there are also various kinds of management and government networks where DNS connectivity to the outside world isn't really needed. Here's how I would draw the line myself. In environments where regular traffic (HTTP, FTP, etc.) is being considerably restricted or even blocked, allowing DNS traffic to the outside should be blocked by default. In case there is a good reason to allow the traffic the default-deny can and should be reconsidered, but I think default-deny is the best policy in restricted environments. I think this is actually quite an important consideration because down the road we'll likely see a lot of new networks dedicated to IoT only. In these networks, there's not really much use for public DNS since the traffic is supposed to flow between a cloud and the dedicated IOT network. At the same time, though, there will surely be valuable tidbits of data that could be stolen and transmitted outside using DNS.