DNS fuckery: investigation leads to a pair of servers in China

The situation came to my attention on April 30 and nothing has changed since. Random IP addresses for 8kun have been infecting DNS servers worldwide. It does not appear, at this point, that there is a "trap" waiting to be sprung. I finally decided to write a bot to poll the DNS servers in an effort to gather information which might lead to some theory of what is going on besides "black hats hacking the Internet".

I tested nearly 300 DNS servers and what I found was a huge discrepancy where some servers are badly poisoned at a rate as high as 30% and other servers at a rate of just 5% or less. It seems to be always the same servers affected at about the same rate. The problem is not worse by region or service provider so that seems to rule out the possibility that it is a targeted attack. What could be going on? I decided to learn more about how DNS works and find some way to trace the DNS lookups across the Internet to find out if there could be a specific server in the chain that might be at fault.

DNS works in a hierarchical fashion. There are 13 root servers which are the first step to resolving Top Level Domains (TLD) like "com" or "top". The root server returns a list of TLD servers which will either deliver the final result or a list of "authoritative" servers which must be queried next. Generally, you don't expect a final result from a TLD server and that would be a red flag if it happens. The next step, querying the authoritative server, is usually the final step which leads to one or more IP addresses as the answer to the original question. In the case of "8kun.top", the authoritative servers are "ns1.vanwanet.com" and "ns2.vanwanet.com". I tested these servers and found no instance of a bad IP address.

The TLD servers for the "top" domain are these:

a.zdnscloud.com (203.99.24.1), b.zdnscloud.com (203.99.25.1), c.zdnscloud.com (203.99.26.1), d.zdnscloud.com (203.99.27.1),

f.zdnscloud.com (114.67.16.204), g.zdnscloud.com (42.62.2.16), i.zdnscloud.com (IPv6 address), j.zdnscloud.com (IPv6 address)

Go here to perform the DNS trace: https://simpledns.plus/lookup-dg

Run the DNS trace a few times (just reload the page) until you see a message like this:

Received response:

''-Answer: A-record for 8kun.top = 199.96.58.177''

*** Lame response - not authoritative and no referral

This happens ONLY with "f.zdnscloud.com" and "g.zdnscloud.com". These two servers are "ground zero" for the DNS fuckery.

Continued next post…

DNS fuckery: who in China wants to poison 8kun?

Use this tool to trace the IP addresses indicated in the previous post: https://www.whatismyip.net/

The 6 IP addresses to test are: 203.99.24.1 - 203.99.25.1 - 203.99.26.1 - 203.99.27.1 - 114.67.16.204 - 42.62.2.16

The first four servers are managed by Beijing Engineering Research Center. The last one is managed by China Telecommunications. The second last one (f.zdnscloud.com) is in question as to who really manages this server because I get different answers from other web sites. It appears to have originally been under VMware which owns a product called vCloud and which has a business relationship with China Telecom. I think it is safe to say that China Telecom runs this. Also, the server might be in Guangdong rather than Beijing. The details don't really matter. The fact is that "8kun.top" is at the mercy of Chinese goodwill for its DNS service. In other news, the DDoS protection service is located in Russia and the actual 8kun servers might be hidden on a pig farm in the Philippines. Seems pretty bizarre but the idea is to eliminate the possibility of a single entity taking the site down.

The next step in my investigation was to figure out just how to verify the fuckery on my own desktop rather than relying on web sites. It turns out that a tool called "nslookup" can do the job. Boom! Caught red-handed. The two servers (f.zdnscloud.com and g.zdnscloud.com) identified earlier in the investigation are undeniably the source of the DNS fuckery. I suppose the next step would be to notify 8kun management (meaning Jim Watkins) that this is happening so he can make a polite phone call to China and ask them to knock it off. Kek. Anyway, here's the command line:

nslookup -type=A 8kun.top a.zdnscloud.com

Try this with servers a,b,c,d to see what the DNS result should look like. Then try the f and g servers to see the fuckery. Every damn time, no matter which 8kun subdomain, the result is a random IP address. The servers are in charge of the following domains: baidu, citic, ren, sohu, top, unicom, wang and a bunch of weird ones. Try these domains that I dug up (brandon.wang, crackstreams.top, angebot.top) to see that the servers are doing what they are supposed to do. They're just not doing their job with 8kun. It appears that someone on the inside has inserted a rather sizable IP address list and then misconfigured the system to deliver IP addresses instead of links to the Vanwanet downstream servers. I suppose that this COULD have been pulled off from the outside but I don't think so.

Continued next post…

DNS fuckery: how bad is it and who is vulnerable?

Here's the math. We have two TLD servers handing out an IP address when they are supposed to be serving links for the Vanwanet DNS. With two bad servers out of six there is a 1 in 3 chance of a bad hit. A server that accepts the bogus response FAILS BIGLY. A smart server will try again with one of the other five servers. If it hits the other bad server then it may give up and accept the result. This is a 1 in 15 chance of a bogus IP address reaching the user. A very smart server will always get the correct result on the third try (error rate of zero). The math agrees with my observations when I polled the DNS servers with a bot though that doesn't totally explain everything just yet.

Many servers have an error rate much lower than 1 in 15 (but still greater than zero). This can be explained as a consequence of redundancy or workload mitigation. If the task of performing DNS lookups is parcelled out to several machines (connected to appear as a single server) then the error rate will be lowered by the fact that not all of the machines are vulnerable. It depends on what software the individual machines are running. This is just good network design since proper redundancy dictates diversity. A bad design would be all of the machines being the exact same. Analysis over.

I have tested all of the big public servers such as Google, Cloudflare, OpenDNS and Quad9. They have proven to be totally error-free or very nearly so. One, however, stands out as failing bigly and it is Yandex DNS (77.88.8.1 and 77.88.8.8). The failure rate is 1 in 3 and this can be easily verified if you care to change your DNS provider to Yandex. You may get lucky and be able to connect to 8kun but your luck is unlikely to last more than 15 minutes. It is BAAAAD! Yandex works very nicely otherwise. There are a bunch of Internet service providers that fail the test including Verizon, Shaw, Primus, Comcast and many smaller outfits. I don't intend to publish a list because only some of their DNS servers are vulnerable. For example, I tested 11 Verizon servers and only two of them failed. Servers are not created equal so it is impossible to lay blame on any particular ISP.

What's next? I don't know. If an insider did this to the two servers owned by China Telecom then that person might be unable to do the same to the other four because they are owned by a different entity. If it is an outside job then maybe the other four are not vulnerable to the exploit. Is this where it ends or will there be an attempt to elevate the threat? Is China Telecom even aware of this? Could Jim Watkins call them up and get the problem fixed? Maybe somebody should tell him. I leave that task to another anon. Maybe it would suffice to drop a note with Codemonkey.

Here's some additional resources till my next report:

Delegation Record for the "top" domain: https://www.iana.org/domains/root/db/top.html

Master root zone file (plain text): https://www.internic.net/domain/root.zone

Find this and my previous report here: https://8kun.top/alleycat/res/968.html

P.S. Maybe the fuckery will stop now that I've outed the source on this board? We are the news!

>>13773327

>Why not simply take them out of rotation until the issue is resolved?

Someone would have to talk to these guys: https://www.iana.org