VXers pass stolen card data over DNS The NewPosThings malware has spawned an offspring that exploits the DNS protocol to sneak data past firewalls. The VXers have reasoned DNS has a couple of advantages for data exfiltration. Since the enterprise network can't talk to the Internet without it, it's unlikely to be blocked; and since it's probably thought of as more …
I assume the quick fix to that is to run your own local DNS server(s) and block DNS at the firewall for any local IP/MAC address except that of the server. That forces everyone on your network to use your local DNS rather than use Google or OpenDNS. An exploit that was good enough to be able to spoof the DNS IP/MAC might still get around it. It also assumes that the local DNS won't forward incomprehensible packets on the basis that it wouldn't know where to send them.
the fix is just to permit DNS to known external DNS servers (Google, BT etc)
the better fix is to just permit specific internal hosts (like the internal DNS system) access to external DNS, blocking all and sundry access.
if your processing PCI/DSS no internal host should be allowed to connect to an external host without first passing through a proxy (no not just a web proxy), the initial connection must be to a trusted internal and that then must spawn a new connection to the external third party.
How would limiting access to other DNS servers but permitting normal access from your internal DNS server prevent this sort of thing?
If I were wanting to pass card details over DNS, I'd query something like:
56.10.59.10.81.01.82.50.myevil.site (obviously with a valid TLD).
Hosting my own authoritative server for myevil.site and enabling logging (effectively) is all that is needed.
That could be extended simply enough to include card validity and CVV number etc.
This is an old trick. Someone even built an HTTP proxy around this idea (to get free service on walled-garden hotspots)
What you want to do is transparently redirect all traffic on the DNS port to your internal DNS server. This way, you benefit from security alerts when those seemingly-corrupt packets from infected machines are logged. DNS (and SMTP) redirection is standard for captive portals (public wifi hotspots). If you don't capture the DNS, then a bit of software on your portable can tunnel everything over 53 TCP and you get free wifi.
Hackers only need to look up an A record to a (sub)domain they control. The victim's IP and credit card(s) can be encrypted and encoded into an ASCII DNS name eg ip.creditcard.comprimised.dyndns.org
The lookup might fail but the hackers' DNS server would have a log of the lookup or they could just reply with whatever data they want ie an IP thats really a fragment of remote command data.
Therefore remote command requests and replies wouldn't even need to rely on TXT records and any usual proxying and UDP/TCP filtering of port 53 would not help.
I guess the thing to look out for is to be suspicious of A records that aren't the root or www AND to clamp down on excessive lookups on the same domain.
Practical solution? Get payment service providers to host "secure DNS".
The way I see the problem as pointed out already, everybody uses a card to buy things, and a shop must check if the card will give them money before selling things. So without instant credit check a shop would be frauded out of business and with a queued delay nobody would shop there. <blah blah> therefore you can't explicitly stop DNS... but it seems a POS device should probably really only ever need to lookup one domain. I can see why that's slightly less than desirable, but does it really need to lookup xyz.com, no all it needs is primarycardprocessor.com and possibly secondarycardprocessor.com.
I have lost my train. I think the solution is to use some form of payment that would be transferable from person to person without relying on the Internet. Perhaps there could be different types that would represent different values? I don't know we'd have to think about it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
