[Unbound-users] DNS poisoning - any ideas how this can happen?

Tue Feb 10 09:18:44 UTC 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Martin,

Looking through that forum thread, I see that unbound's cache contains
bad items and that the NS records for com, net org edu are point to
nsX.csof.net.  And I wonder if unbound is getting cache poisoned or if
your 'upstream resolver' or upstream captive-resolver (i.e. the
8.8.8.8 has been hijacked by your ISP and is serviced by other
software) is getting cache poisoned.

The unbound logs should tell you if you enable verbose logging (I
would recommend level 4, or perhaps level 5 so you can see who
requests those bad domain names in your network).  Or when unbound is
misbehaving dig @8.8.8.8 from a box with similar routing, and see if
those responses have been cache poisoned.

When I try to resolve api-nyc01.exip.org here I see unbound complain
that it has to remove potential poisonous DNS RRsets from the answers.
 It does so and is not poisoned:

reply from <exip.org.> 54.77.72.254#53
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 26841
;; flags: qr aa ; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;; api-nyc01.exip.org.	IN	A

;; ANSWER SECTION:
api-nyc01.exip.org.	10	IN	A	195.22.26.248

;; AUTHORITY SECTION:
org.	172800	IN	NS	ns1.csof.net.
org.	172800	IN	NS	ns2.csof.net.
org.	172800	IN	NS	ns3.csof.net.
org.	172800	IN	NS	ns4.csof.net.

;; ADDITIONAL SECTION:
ns1.csof.net.	100	IN	A	54.77.72.254
ns2.csof.net.	100	IN	A	212.6.183.201
ns3.csof.net.	100	IN	A	195.22.26.199
ns4.csof.net.	100	IN	A	54.72.8.183

Humourously (if you think this is funny), it could be a
misconfiguration and bad DNS ISP practices interfering here.  Some
domain hosters serve .org and .com zones and they have *.com and *.org
wildcards on those servers.  Thus they do not reconfigure their DNS
servers when they buy or sell a domain.  But that produces these types
of 'poisonous' answers.  Badly written DNS software could then get DNS
cache poisoned as a result.  Unbound should not get DNS cache
poisoned, there is explicit fixup code for this.

Because setting different upstream IP forwarders changes the outcome,
I think it may be the upstream DNS server that gets cache poisoned
(after a lookup of one of these affected domains), and some ISPs
interpose all DNS traffic with their own DNS servers, that may be
getting poisoned or maybe only traffic to 'popular' DNS sites.  I
doubt google DNS itself is getting cache poisoned, but it is a
technical possibility.

Best regards,
   Wouter

On 10/02/15 09:27, W.C.A. Wijngaards wrote:
> Hi Martin,
> 
> On 09/02/15 18:33, Martin Bachmann wrote:
>> Hi all,
> 
>> We've run into a dns poisoning issue in our company network since
>>  Friday. The issue is being discussed here: 
>> https://forum.pfsense.org/index.php?topic=87491.0 - we use
>> Unbound on a pfSense. A few other users have the same problem:
> 
>> - All of a sudden, all host names resolve to a malware host. -
>> It stops automatically after some time - There's no arp
>> poisoning going on, so it really comes from Unbound on the
>> pfSense
> 
> So, unbound comes with a set of commands for unbound-control that 
> allow you to monitor the runtime settings, and these are exactly
> meant to be able to audit the settings in the runtime daemon and if
> they are still correct.  unbound-control list_forwards.
> 
> You could try to use packet capture of traffic going to 8.8.8.8
> and the responses.   Or you can get unbound to log verbosely (high 
> verbosity setting), although much slower at level 4 it'll print a 
> dig-like output for packets received from upstream, so you can see 
> where the malicious data comes from.
> 
> Or just dig @8.8.8.8 from the commandline, that has the same
> routing as the pfSense firewall box with unbound on it, and look at
> the result.
> 
> Unbound has DNSSEC capabilities that are meant to protect against 
> these sorts of things (only for DNSSEC signed domains of course).
> You can easily turn it on with unbound-anchor -a /etc/root.key and
> putting auto-trust-anchor-file: "/etc/root.key" in unbound.conf.
> 
> Best regards, Wouter
> 
>> Example:
> 
>> While "on":
> 
>> $ host omx.ch <http://omx.ch> omx.ch <http://omx.ch> has address 
>> 195.22.26.248 omx.ch <http://omx.ch> mail is handled by 10 
>> mx1.csof.net <http://mx1.csof.net>. omx.ch <http://omx.ch> mail
>> is handled by 10 mx2.csof.net <http://mx2.csof.net>.
> 
>> Normally:
> 
>> $host omx.ch <http://omx.ch> omx.ch <http://omx.ch> has address 
>> 62.48.3.132 omx.ch <http://omx.ch> mail is handled by 10 
>> mxhost1.omx.ch <http://mxhost1.omx.ch>
> 
>> Other wrongly resolved ips lead to sso.mlwr.io 
>> <http://sso.mlwr.io> (which tries to redirect back to 
>> xsso.<correcthost.com
>> <http://correcthost.com>>/<someidentifier>)
> 
>> Any ideas?
> 
>> - Martin
> 
> 
> 
> 
>> _______________________________________________ Unbound-users 
>> mailing list Unbound-users at unbound.net 
>> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
> 
> 
> _______________________________________________ Unbound-users
> mailing list Unbound-users at unbound.net 
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJU2cz0AAoJEJ9vHC1+BF+NKI4P/iZQ40YhFqKL46rv4MMKPQa3
LkbO4uqiww1qpM4zm7VCx983IeefCe35befg6Zf0C4jMzHL+xZfvbefXV4H1FDMk
POTT3wxqYywquZYAzxMXez4GMlQikHZ4oyySetezjeIve3yDnaywL8LVc0j3NJXk
FEUNUca4eKxR21dmDnlzJ7Rml5eqOBVfHQKFzkoBhaHOSXqmXoaQtYsgJrOSTMi7
skbuFYl0+45liPpxoMqyymet4DwTmPQAbsZpQ8zy98sZVdpRR6gmEq7jnN1g1N0v
Lur8RtEkyH59VYpL2EBGYN8j2e0Gy+L2HzD1R1GjIEX8phOaNUj3DNfLbn8O/Fso
oumBK9MYoHNeZJUjssD5lgEwbAjGjOIBL+gocP9FVUy4z7WNzjkqrSi51Q5o44gc
mseLIc4Bk9Rdg88Nwq6zK6IGG/4l8ISc5CGeEdLK6zRdO1WwwQP8sDLJmLK+2+UW
n6PyzQjfsgPtkM4BKQjeTMQS/0aZNwPn9LuUcxr5qtGQZCJLH9CcOLUJl5xeEf8N
SKqFI7ZjubglsHq2ffqFq6rq5tVpYENIrPbJI/Ipl7ZAFP8ojd7W7nyCb4INihdP
P1nCmOikiIgfh5M+alHQOOn7/AtVwXIs33sKKuYGYNvWJOiBMOX3x7u04vTEFoBM
XPW77I/RniEsMgu83DC0
=vqV1
-----END PGP SIGNATURE-----