· Executed daily operations of forming small reading groups with second and third graders.
· Assisted as needed.
Johannes Ullrich, who is the CTO of the SANS Internet Storm Center, wrote recently on what appears to be a new rash of malware that attempts to directly threaten network services. Once a host has been infected, this trojan sets up a rogue DHCP server on the host machine. Because DHCP works on a broadcast mechanism in which the response supplied by the first server will be used by a querying client, it is possible for workstations renewing their DHCP lease to be tricked into utilizing the IP address of a malicious domain name server.
This is not the first time that such a trojan has appeared though. Indeed, this appears to be a variant of the Trojan.Flush.M, but it is modified to be harder to detect — it does not specify any DNS domain name and sets a relatively short DHCP lease time of one hour, among other changes.
The bottom line here is that it is relatively trivial for a single infected machine to undermine DHCP to corrupt the DNS settings of all workstations on the network, assuming that they are not configured with static IPs.
So how can one defend against this trojan as well as similar attacks?
The simplest way to defend against such trojans would surely be to hardwire the DNS settings for every workstation on the network. However, such a solution is impractical for networks larger than even a couple of dozen nodes at the most. Indeed, the increasing use of wireless networks in the enterprise — as well as laptops — serves only as additional deterrents due to the inconvenience of static settings in such circumstances.
A simpler way for larger corporations to defend against the vulnerability exposed by this trojan would be to monitor outbound DNS connections. This could mean logging down all DNS queries — which is also useful to track down suspicious traffic trends from phishing attacks. Of course, such a drastic measure comes with its own bag of user and possible managerial resistance due to its invasive nature.
An even cleaner method would be to configure an internal DNS server tasked with all domain name queries. All other DNS queries not originating from this machine are to be barred. If the resources are not available to set up an internal DNS server, more sophisticated firewalls can be used to filter only DNS queries to addresses that are not in an approved list.
In the meantime, you might want to run a quick check that the IP of the malicious DNS server — at 220.127.116.11 and 18.104.22.168 — are not currently being queried on your network.