[dns-operations] Passing card data through the DNS

[dagon]

On Wed, Apr 20, 2016 at 12:08:09PM -0400, Robert Edmonds wrote:

> A more likely reason is because Base32 is impervious to character case
> perturbations on the way to the evildomain.com nameservers.

CoRreCt; tHe FireEYe rEPoRt mISseD RfC 4343, etC, ETc, :)

The malware (md5: f924cec68be776e41726ee765f469d50, sha1
f7125695a1c59970b7557362c67f81d93d871373) uses a modified base32
encoding to generate DNS labels, since stock base32 will actually
result in some invalid domain names (e.g., padded encoding strings
ending in '='), requiring either character substitution of the encoded
label, and/or padding of the plain text to result in a base32 encoding
ending on block boundary.  (Plus, some registries prohibit domains
ending in '-', or labels with a '-' in the 3d or 4th character
position, etc.)

Since the attackers encode the payload with RSA, it is further
difficult to pad the plain text properly to avoid the need for base32
padding, and therefore substitution in DNS labels, e.g., 's/=/-/g'.

The malware uses 1024 bit RSA, likely because the output size is the
size of the modulus (the encrypted payload plus any PKCS1 padding),
and this is a "somewhat" secure key size.  Moreover, there's a need to
keep qnames short.  Compare: A 2048-bit RSA would result in ~256 bytes
encoded, and even more when base32 encoded, and even more octets for
rfc 1034 s2.3.4 interlabel cuts, leaving no room for a parent zone.

This problem could be avoided by using block ciphers for example.

Some notes:

  -- The malware uses stock dnsapi.dll system calls, DnsQuery_A, etc.
     The encoded qnames therefore use the normal user DNS path (the
     malware does not change DNS settings), and queries are therefore
     candidates for passive DNS collection and local logging.

  -- The malware first beacons an initial infection using a unique
     domain name (again, a custom base32 encoding of a DJB2 hash (the
     "magic 33" algo), hashing the victim computer volume, etc.,
     resulting in uint_t output).  Thus it would be possible to use
     passive DNS to enumerate all victims of this malware.

     (Just sort qnames by label depth, and qname total bytes; the top
     end of the scale is always covert channels, malware, and Georgia
     Tech research.  One can also use flags, qtype and the diversity
     of reply data to filter out OzymanDNS, dns2tcp, iodine, heyoka,
     dnscat, element53, etc., resulting in malware-only qnames.  Stray
     CDNs, facebook load balacing domains, and sinkholes are easily
     whitelisted by parent zone.)

     And with many networks using ECS-enabled recursives, and qname
     minimization not widely deployed ... this means the parent zones
     and TLDs can further enumerate most of the networks that are
     infected, using EDNS0 client subnetwork information.

  -- One rule of thumb for those looking into this: if the qname is
     long, the flows to/from the hosts in the rdata should be
     proportionally large for legitimate CDN use.  I.e., legitimate
     lengthy qnames are associated with media content or ads.  The
     simple ratio of qname length to flows to/from the rdata hosts
     also lets one filter out covert channels (e.g., theft-of-service
     use of DNS for tunnels.)

     Short flows to long host names scream "malware".

  -- The small size of the RSA key suggests it may soon be possible
     for some adversaries to break the RSA encoded payloads, and use
     DNS alone to list victim networks (easily done today) and even
     individual credit cards (perhaps soon, by some powerful
     adversaries).

So using DNS for exfiltration is very risky, and easily detected.
It's not the mid 2000s anymore.

-- 
David Dagon
dagon at sudo.sh
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717