Last Updated: 2022-10-26 13:09:23 UTC
by Johannes Ullrich (Version: 1)
My cat, Gluon, is having a problem. Last year, a new cat, Einstein, invaded her property, and since then, she has no longer ventured outside after some unfortunate encounters with Einstein. Gluon now spends most of her time inside doing cat stuff like grooming and sleeping; unfortunately, she has gained an unhealthy amount of weight. To help, we got her an automated cat feeder to better control her food intake. The cat feeder is sporting not just the obligatory WiFi and Cloud/App connectivity but also a camera, so it was immediately moved to our "IoT" network.
The IoT network is pretty much locked down and closely monitored. So I soon noticed these DNS queries originating from the cat feeder:
0 catfeeder → dnsserver DNS 73 Standard query 0x0002 A baidu.com
301 catfeeder → dnsserver DNS 73 Standard query 0x0002 A baidu.com
602 catfeeder → dnsserver DNS 73 Standard query 0x0002 A baidu.com
About every 5 minutes (300 seconds), the cat feeder attempts to resolve "baidu.com." Why baidu.com? What is my cat trying to search for?
After investigating this on different devices showing similar behavior, I finally figured out that some networking libraries use "baidu.com" for internet connectivity checks. Even if the DNS lookup succeeds, there is no actual outbound connection in this case. The device is happy as long as an IP address is returned.
But why baidu.com and not google.com or '184.108.40.206' (or bing.com)? This is likely due to these devices and some libraries manufactured and coded in China. First of all, "Baidu" is more commonly used than "Google", and due to the censorship regime, which may not only block DNS lookups for Google but may also use these DNS lookups to identify non-regime-conform behavior not to get Chinese users into trouble, they may opt for the use of Baidu which works fine globally.
There is another interesting issue with these DNS queries. Let's look at the DNS query IDs:
% tshark -nr sessions.pcap -T fields -e 'dns.id' | sort -u
So all the queries use the same query id (I have also seen "1" and "3"). This is a known issue with many IoT devices using specific networking libraries. For example, the uClibc and uClibc-ng libraries were recently found to have vulnerabilities like this.
As for the cat feeder, I haven't been able to verify which library it uses, and it does have; however, an open telnet server to be compliant with the minimum number of vulnerability rules for IoT devices. Not sure if anybody has an idea what the username or password would be. The login prompt: