WSL2 DNS Oddness
Wed 24th Feb 2021
Last night I was doing a round of patching on some of my servers and had a small panic when I was hit with what looked like some kind of DNS manipulation. After some investigation, it turned out not to be malicious, just WSL2 doing things in, what looks to me like, the wrong way.
A quick background, if you do a DNS look up with dig on a normal Linux host you'll see a number of sections returned, these include the QUESTION asked, the ANSWER, the list of AUTHORITY's and then some ADDITIONAL detail.
If you look at a packet capture of the response to the request you will see the same fields mapped out.
Now, look at the response when the same lookup is done in a Linux box running under WSL2.
Rather than putting E.ROOT-SERVERS.net. and G.ROOT-SERVERS.net. in the additional section as the are on the stand-alone Linux host, they are included with the answer.
Look at the packet, and you will see why, rather than the WSL2 DNS server returning the same sections as a normal DNS server, it dumps the two additional records in with the answer.
Why does this matter? I had just upgraded one my servers and asked it to reboot so lost my SSH connection. To connect back in when it was back online, I normally fire off an SSH connection request every few seconds watching them fail till the server comes back up and SSH is restarted. In this instance, I got a connection right away, but not to the box I was expecting.
The initial give away was the SSH client telling me it had found a new IP for the server and asking me to confirm the signature. As each of my boxes only has a single IP, that should never happen after the initial connection. As the new IP was also one on my network, not some random internet IP, there was only mild sweaty palms panic rather than full out "declare disaster" panic.
I disconnected, gave it a minute, tried again, and went straight into the correct box. I repeated this a handful of times and got the right box each time. I tried a different workstation and that connected to the right box every time as well.
I was going to write it off as a one-off glitch, but they don't happen, so I did a bit more digging, literally.
I thought I'd check what dig said the IP address of the affected server was, and that is when I saw the multiple answers and it all clicked. SSH did the DNS lookup and got two replies, the correct IP and the one that should have been in the additional section. As I run my own internal DNS server, the second IP was for that server which explains why it was an internal IP and not for one of the root servers which is what I would have got if I'd rebooted my main web server.
As far as SSH was concerned, it tried the first IP in the answer section, got nothing back, so moved on to the second IP, as that had a running SSH service, it connected. As it was the first time it had seen that IP, it gave me the question about confirming the signature. Panic over, DNS was to blame, I hadn't been hacked. I'm going to submit this issue to the WSL2 GitHub issue list to see if it is a known issue and something they want to fix, hopefully they do, as I can definitely see it causing problems in some environments, especially if it is a one off thing as it was for me.
I've been thinking about whether this could be used in a malicious way and I think it possibly could, but to do it, the attacker would need so much access, that they would probably have many other, better, options, before having to fall back to this. But, there are people way smarter than I am out there, so if someone does come up with a viable attack, I'd love to hear about it.
