New malware spotted that answers to DHCP-Requests to send clients to malicious DNS-servers

December 9th, 2008 by Holger Bauer

There’s a new threat in the wild where a single infected machine in your network can harm all other dhcp clients on the same net: A trojan answering to dhcp-requests.

If that trojan is answering faster than your real dhcp-server it will assign some malicious dns-servers to the client that sent out the request. This is making phishing pretty easy but could also lead to the installation of faked updates.

You can find some more information about that trojan at the symantec page.

A way to prevent this using pfsense is to use a firewallrule on your internal networkinterface that is blocking all outbound tcp/udp port 53 (DNS) connections to any destination. Make sure your internal dns-server, that is manually configured and not affected by this dhcp attack, has a pass rule on top of this block rule or if you use the pfsense as dns-forwarder create a rule that grants access to the pfsense ip on port 53 tcp/udp. This way a client with faked dns-server will not be able to resolve dns anymore which will be noticed pretty soon instead of possibly using the malicious dns servers without noticing it.

Tags: , , ,

15 Responses to “New malware spotted that answers to DHCP-Requests to send clients to malicious DNS-servers”

  1. Jonathan Says:

    DHCP snooping (Cisco I am sure others have similar features) on your managed switches will help prevent this at the switch level also.

  2. Kevin Bowling Says:

    This seems like a really easy attack vector. Thank you for the quick fix, hopefully something more robust will be released in the future.

    DNS and name resolution are clearly vulnerable and exploits like this aren’t exactly new (though the use of a trojan and DHCP are pretty novel).

    There seems to be a lot of inertia toward change in internet architecture, especially with important things like DNSSEC and IPv6. Nobody is rising to the challenge to drive these changes forward: government, academia, or commercial.

  3. Chris Buechler Says:

    I definitely recommend checking into switch functionality like DHCP snooping, as Jonathan mentioned, as that’s the only way to prevent this from happening rather than just limiting its impact. It also prevents human error of inadvertently bringing up a rogue DHCP server from taking down your network.

    A rogue DHCP server detection package is something you may see available for pfSense in the future.

  4. Marco Pannetto Says:

    Off course if all clients within your net are using static IPs, no malicious dns-servers will be assigned to the clients even if one or more machines are infected by the malware.

  5. Chris Buechler Says:

    Well yeah, but statically assigning addresses isn’t a reasonable option in most environments. If you have a handful of devices it’s not a bad option, but any more than that and your ability to make network changes is severely hampered and administrative efforts significantly increased if you don’t use DHCP.

  6. Slick Says:

    At the mortgage company I administrate the network for. I have 53 blocked for everything but OPENDNS and internal. All other DNS servers are blocked. I actually didnt do it for this reason, I actually did it for content filtering purposes. However, its nice to know that Im already protected against this as well.

  7. Pete Boyd Says:

    I found the wording above of “A way to prevent this using pfsense..” not easy to understand, so here’s the translation I did for myself, for anyone else having difficulty with it:

    * On LAN interface block all DNS traffic to WAN

    Action: Block
    Interface: LAN
    Protocol: TCP/UDP
    Destination: WAN address
    Destination port range
    from: DNS
    to: DNS
    Log: Log packets that are handled by this rule – for short-term testing so as to find out who might mistakenly have an external DNS set, or picked up a rogue DNS
    Description: Block outgoing DNS in case of rogue DNS servers

    * Allow outgoing DNS access by pfSense, or by a dedicated DNS server (whichever you use)

    Action: Pass
    Interface: LAN
    Protocol: TCP/UDP
    Source
    Type: Single host or alias
    Address: LAN IP of your pfSense, or of your stand-alone DNS server
    Destination: WAN address
    Destination port range
    from: DNS
    to: DNS
    Description: allow outgoing DNS for our pfSense DNS forwarder

    The firewall rules page says the order matters, which to me would mean the pass rule needs to go above the block rule, but in practice this doesn’t appear necessary. Maybe someone can correct me if I’m wrong.

  8. Chris Buechler Says:

    The destination in that rule must be “any”, not “WAN IP address”. All you’re doing there is blocking DNS traffic destined to your WAN IP, which isn’t what you want to do.

    The pass rules must come before any matching block rules. If that block rule were setup correctly you would have been dropping all DNS traffic if it weren’t passed first.

  9. Pete Boyd Says:

    Thanks Chris. For completeness’ sake, here’s my updated config:

    The rules must appear in the following order.

    Allow outgoing DNS access by pfSense, or by a dedicated DNS server (whichever you use)
    Action: Pass
    Interface: LAN
    Protocol: TCP/UDP
    Source
    - Type: Single host or alias
    - Address: LAN IP of your pfSense, or of your stand-alone DNS server
    Destination: any
    Destination port range
    - from: DNS
    - to: DNS
    Description: Allow outgoing DNS for our pfSense DNS forwarder

    On LAN interface block all DNS traffic to any network
    Action: Block
    Interface: LAN
    Protocol: TCP/UDP
    Destination: any
    Destination port range
    - from: DNS
    - to: DNS
    Log: Log packets that are handled by this rule – for short-term testing so as to find out who might mistakenly have an external DNS set, or picked up a rogue DNS
    Description: Block outgoing DNS in case of rogue DNS servers

  10. Chris Buechler Says:

    Pete: that’s right on.

    I’d leave the logging enabled on the block rule, I like logging what gets dropped egress because it typically indicates either a misconfiguration, compromised host, or somebody trying to do something they aren’t supposed to be doing.

  11. Slick Says:

    “somebody trying to do something they aren’t supposed to be doing”

    Thats usually the case!

  12. phil Says:

    if you use the pfsense as dns-forwarder create a rule that grants access to the pfsense ip on port 53 udp is enough . You don’t need tcp.

    only first rule with ie. enable udp dns(port 53) to 192.168.1.1 (let’s assume 192.168.1.1 is your lan0 IP@)

    2nd rule reject tcp/udp dns(port 53) to any

  13. Chris Buechler Says:

    You do need to allow both TCP *and* UDP for DNS to work properly. Queries with large responses will be re-issued as TCP, so if you block TCP 53 some queries will fail.

  14. Sean McRobbie Says:

    Appears to be one problem with the workaround…

    I recently set up a test Windows 7 machine and joined it to my pfSense powered wifi hotspot.

    Turns out everything worked as normal to a point… got the correct ipv4 IP, gateway and DNS server from DHCP, However….

    Some other device on the wifi hotspot network has issued an ipv6 DNS server which the machine uses instead of the v4 server!

    I see this as a *HUGE* security issue as someone can simply plug in a v6 device to the network which Windows 7 (and possiblyWindows Vista and others) will use out of the box!

    Aside from the fact it is a security issue, it actually broke everything as far as captive portal is concerned because the captive portal hostname was of course not resolving correctly…

    Any workaround for this?

  15. Chris Buechler Says:

    Sean: Disable IPv6.

Please don’t post technical questions or off-topic comments. It is far more likely that your questions and concerns will be addressed effectively through one of our support channels.

Leave a Reply