A friend was having unexpected results with DNS queries on a Windows machine. I told him to use nslookup's debug options.

When you execute a simple DNS query like "nslookup example.com. 8.8.8.8", you get an answer like this (notice that in my nslookup query, I terminated the FQDN with a dot: "example.com.", I do that to prevent Windows from adding suffixes):

You see the result of a reverse DNS lookup (8.8.8.8 is dns.google) and you get 2 IP addresses for example.com in your answer: an IPv6 address and an IPv4 address.

If my friend would have been able to run packet capture on the machine, he would have seen 3 DNS queries and answers:

A PTR query to do a reverse DNS lookup for 8.8.8.8, an A query to lookup IPv4 addresses for example.com, and an AAAA query to lookup IPv6 addresses for example.com.

One can use nslookup's debug options to obtain equivalent information, without doing a packet capture.

Debug option -d displays extra information for each DNS response packet:

Here is nslookup's parsed DNS response packet for the PTR query:

Here is Wireshark's dissection of this packet:

You can see that the debug output contains the same packet information as Wireshark's, but presented in another form.

The same applies for the A query:

And the AAAA query:

If you also want to see the DNS query packets, you can use debug option -d2:

Besides the parsed DNS query, you now also see the length in bytes of each DNS packet (the UDP payload).

Here is the A query:

And here is the AAAA query:

Didier Stevens
Senior handler
blog.DidierStevens.com

Before diving into the vulnerability, a bit about the affected devices. LB-Link, the make of the devices affected by this vulnerability, produces various wireless equipment that is sometimes sold under different brands and labels. This will make it difficult to identify affected devices. These devices are often low-cost "no name" solutions or, in some cases, may even be embedded, which makes it even more difficult to find firmware updates.

Before buying any IoT device, WiFi router, or similar piece of equipment, please make sure the vendor does:

1. Offer firmware updates for download from an easy-to-find location.
2. Provide an "end of life" policy stating how long a particular device will receive updates.

Alternatively, you may want to verify if the device can be "re-flashed" using an open source firmware.

But let us go back to this vulnerability. There are two URLs affected, one of which showed up in our "First Seen URLs":

/goform/sysTools
/goform/set_LimitClient_cfg

The second one has been used more in the past, the first is relatively new in our logs. The graph below shows how "set_LimitClient.cfg" is much more popular. We only saw a significant number of scans for "sysTools" on May 1st.

The full requests we are seeing:

POST /goform/set_LimitClient_cfg HTTP/1.1
Cookie: user=admin

And yes, the vulnerability evolves around the "user=admin" cookie and a command injection in the password parameter. This is too stupid to waste any more time on, but it is common enough to just give up and call it a day. The NVD entry for the vulnerability was updated last week, adding an older PoC exploit to it. Maybe that got some kids interested in this vulnerability again.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|