eggheads
(RFC) CWE-350 add option to check for dns spoofing
Found by: michaelortmann Patch by: michaelortmann Fixes: #13
One-line summary: Add option dns-spoof-protect (default 0) to check for dns spoofing.
Additional description (if needed): If dns-spoof-protect is set to 1 then for any successful reverse lookup from ip to hostname, a lookup from that hostname to its ip-list is done and it is checked that the ip is in the ip-list. Failed lookup / spoof is logged and eggdrop will use the ip instead of the reverse lookedup hostname. Based on #1015 This will fix the dns resolver in eggdrops core that is using libc functions. The dns mod could be having other dns spoofing problems more similar to what a dns server could have. This (any such) check can only detect some kinds of dns spoofing by design.
Test cases demonstrating functionality (if applicable): Tested with dns server unbound adblocking s3-1-w.amazonaws.com (mapping to 127.0.0.1):
.tcl dnslookup 52.216.85.251 foo
[05:38:22] tcl: builtin dcc call: *dcc:tcl -HQ 1 dnslookup 52.216.85.251 foo
[05:38:22] tcl: evaluate (.tcl): dnslookup 52.216.85.251 foo
Tcl:
[05:38:22] net: dns spoof protect: host s3-1-w.amazonaws.com could not be resolved to ip 52.216.85.251
[05:38:22] Tcl error [foo]: invalid command name "foo"
invalid command name "foo"
while executing
"foo 52.216.85.251 52.216.85.251 0"
o_O This isn't dns spoofing.. You're effectively breaking an established part (dare I say feature), of the internet. Hosts are not required to have matching forward/reverse dns.
No that is not required. So the optional spoof check doesn't reject any ip missing reverse resolution or any host missing forward resolution. It rejects only the case that a hostname, resolved from an ip, doesn't resolve back to that ip. There are the following cases of reverse resolving, and thats how they are handled with this PR:
ip without reverse lookup -> bot will use ip
ip with reversed lookup:
if the lookedup hostname can be resolved back to that ip-> bot will use that hostname
if the lookedup hostname cant be resolved back to that ip -> bot will use ip and write a log about it
Its the only way to detect what CWE-350 describes with (2): [...] The software performs reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname. [...] Attackers can spoof DNS names by either (1) compromising a DNS server and modifying its records (sometimes called DNS cache poisoning), or (2) having legitimate control over a DNS server associated with their IP address. [...]
And its the reason, why i named it dns spoofing:
- Cache poisoning is DNS spoofing, but thats not what this PR is for.
- Hostname spoofing is DNS spoofing, thats what this PR is for.
IRC servers are using the same method to detect spoofed hostnames: https://superuser.com/questions/160718/how-does-hostname-spoofing-customization-work-on-irc-networks/161040#161040 So i think we can also.
No that is not requred. But its the only way the bot can detect what CWE-350 describes: The software performs reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname.
It doesn't need to nor can it. Hostname based auth of any kind was never really meant to be secure, some protocols like ssh warns very loudly about it too. SSH of course has a cert it can verify but even smtp has preflight data it can use (the helo for example).
If the term dns spoofing doesnt cover this case, then what is the correct term?
That would depend how you're configuring the connect string and what your expected risk is. The risk in the attack is not so much a spoof but poison. I can mount an offline attack against your resolver (dnssec is a whole other issue).
The optional check also doesnt reject ips missing forward/reverse dns, it only rejects reverse lookedup hostnames that dont resolve back to the ip, there are the following cases now:
ip without reverse lookup -> bot will use ip ip with reversed lookup: if the lookedup hostname can be resolved back to that ip-> bot will use that hostname if the lookedup hostname cant be resolved back to that ip -> bot will use ip and write a log about it
I realize it's somewhat pedantic, it is worth pointing out though that even ssh's assumption about this is annoying because ips do not need to resolve to their host.
From the linked bug:
So, this could be a problem, as any net-block admin can spoof hostnames and telnet to your bot as a known user's hostname, rendering protect-telnet ineffective.
That still remains especially if they are an admin or some third party upstream.
tl;dr is don't use hostnames alone for anything security related :)
Sry, i modified my comment between your answer. I think we talk about 2 different things. Cache poisoning cs. hostname spoofing by modifying the name server of my ip.
Yes, i fully agree about the tl;dr. So let me add, that we don't rely on hostname alone, we rely on it additionally to username/pass/cert. And we are not talking only about authentification, we are talking also about spoofing hostnames in logfiles, which can also be dangerous. This PR is one mitigation of one specific problem and its, yeah, optional.
If you modify your name server and poinson mine, yes, then im lost, even with this PR.
The alternatives would be: Reject #13 with words like: the dns system is broken by design, wont try to fix any part of it in eggdrop. In this case we could discuss adding some warning like better not using hostnames, but IPs for telnet access to the bot or warning about a matched hostname during access. We could also change this PR is not rejecting such hostnames, but only warn about the fact that it cant be resolved back. Or we could make the new config option have 3 choices: OFF, WARN(LOG) and REJECT(LOG).
Thank you h1z1 for your input.
Hostname spoofing is DNS spoofing, thats what this PR is for.IRC servers are using the same method to detect spoofed hostnames:
ircds do attempt to validate but doesn't really trust the result for anything. You're not given +O for example without further attestation. I'm sure there are still networks using broken y-lines..
If you modify your name server and poinson mine, yes, then im lost, even with this PR.
I don't need to modify mine. One surprisingly still effective attack is simply flooding yours to brute force the id (16 bit). Need not even go that far if I''m upstream from you.
In this case we could discuss adding some warning like better not using hostnames,
Or "it's 2020 you really, really shouldn't be using telnet" :)
CANT FIX reasoning: http://jdebp.info/FGA/dns-avoid-double-reverse.html