[RPZ] Trojan.Spachanel - Using SPF records for malware signaling (problem for RPZ sinkholing?)

Tue Jan 29 23:06:48 UTC 2013

At 20:24 29/01/2013  Tuesday, Rod Rasmussen wrote:
>It looks like some malware author has gotten very cute, and good at figuring out how to get around some standard detection methods for DNS tunneling/signaling.  The miscreants are burying hostnames and IPs to use for assembling URLs in SPF records for domains they control.  Thus you won't see weird looking TXT records or some other odd stuff that could indicate signaling/tunneling in DNS queries, but rather vanilla-looking SPF records.  Clever.  Further, I'm wondering how this will affect certain RPZ implementations.  Clearly I can still use the NX Domain approach to cut-off signals if I have the DGA cracked, but what about if I'm redirecting to a sinkhole?  What happens to the TXT lookup that my infected computer is asking for?  Can I provide a fake answer under RPZ, will it provide nothing, or will it give the actual value published by the AUTH servers for the domain?  I think the first, but can someone confirm? 

i think it won't matter as according to the below article it will only query 0-few day old domains thus none are likely to be RPZ listed
(also it won't matter as they are only using this data to populate their own payloads for the IM/smtp/http connections they will make outward)
so as long as you block/alert outbound smtp(25)
non authenticated/proxied http
and other ways the malware can pass on its payload you will detect the malware quickly
(if anything its an opportunity to log/alert on txt/spf record lookups from desktops and use this as another early warning signal that the desktop might be compromised)
(after you have whitelisted the few static domains that use txt records to signal software updates to legitimate clients)

> My sinkhole will never see traffic though, as a TXT lookup won't result in actual malware traffic to my sinkhole IP like an A record would.

an a record equally won't cause traffic if its equally being used to pass encrypted data, as can be done easily if regarded as a list of 32bit chunks (or aaaa for 128 bits at a time [as this is easier to scrifice a few top bits for ordering the message])

>  That's a nasty problem for detection of these, and I would suppose I'm then limited to logging of the requestor on the internal network side in order to track down my bot.

yup with all its worth logging rpz hits I think, whether looking for click happy users or bots
equally the sinkhole ip should not just be a webserver logging, it should log all syn traffic as many bots arn't trying port 80 on their c&c machines

>Thoughts on how to deal with the sinkhole issue presented here via RPZ?

its not a sinkhole issue, its a type of data transmission RPZ can never handle (new domains)

but RPZ i was told back in the day (but my memory may be flawed, has a potential fix (but no public zones as yet)
to allow a zone to be configured that lists IPs of registrars/dns-servers that will not be conversed with /talked to, thus allowing all current and all future domains by that 'owner' to fail. without knowing the domains they registered today

as a large amount of these malicious domains are hosted/registered via  a small fraction of the legit DNS servers worldwide.
unfortunately nearly all have some human shield legit customers too, but like DNSBLs in the past blacklisting malicious hosters just causes the grey-areas to split into black and white as 'legit but dirty' hosters start reacting to negative domains, and negative/abusive domains seek 'like-minded' hosters

but i could be wrong maybe RPZ features don't allow a automated (BIND bogus) listing of a name-server, and thus all the domains hosted theirin

fast-flux is still an issue but an equivalent to spamhauses PBL (PBL lists all policy defined non-smtp servers) could be designed to voluntarily list all your non-dns-server netblocks so the bots therin cannot be fast-flux hosts

so one for never use hosts, one for malicious hosts and we clean up a lot (people can choose which malicious hosts list they wish to use by the policy of the operator)

currently 

>Thanks,
>
>Rod
>
>>
>>
>><http://www.pcworld.idg.com.au/article/452057/browser-hijacking_malware_talks_attackers_using_spf_email_validation_protocol/>http://www.pcworld.idg.com.au/article/452057/browser-hijacking_malware_talks_attackers_using_spf_email_validation_protocol/
>>
>>
>>A new Trojan program that displays rogue advertisements during browsing sessions uses a DNS-based email validation protocol called the Sender Policy Framework (SPF) in order to receive instructions from attackers without being detected, according to security researchers from Symantec.
>>
>>The new malware is called Trojan.Spachanel and its purpose is to inject malicious JavaScript code into every Web page opened on infected computers, Symantec researcher Takashi Katsuki said Friday in a <http://www.symantec.com/connect/blogs/trojan-horse-using-sender-policy-framework>blog post.
>>
>>The malware injects HTML script elements that load JavaScript files from remote URLs. The role of the JavaScript code is to display rogue advertisements inside pop-up windows and trick users to click on them, which generates income for the attackers, Katsuki said.
>>
>>However, the most interesting aspect of this malware is the way in which it receives updated URLs from attackers to use in the rogue HTML script elements.
>>
>>The malware periodically generates a domain name according to a predefined algorithm and makes an SPF lookup for it. Knowing in advance which domain will be generated, the attackers register it and configure its SPF record to contain IP (Internet Protocol) addresses or host names that will be used by the malware to construct new malicious URLs.
>>
>>SPF was designed to detect email spoofing and is implemented using the DNS (Domain Name System).
>>
>>A domain name owner can specify an SPF policy -- a number of IP addresses or host names that are allowed to send emails from that particular domain -- inside a DNS TXT or SPF record. Email servers can then perform SPF lookups via DNS in order to check that email messages appearing to have been sent from that domain actually came from an IP address authorized by the domain administrator.
>>
>>If the sender IP address or host specified in an email's header is not listed in the SPF policy for the corresponding domain name then the email sender's address was probably spoofed.
>>
>>In the case of Trojan.Spachanel, the SPF policy for the domain name is not used to validate emails, but to provide a new list of malicious host names to be used by the malware.
>>
>>Using this technique, attackers can hide the malicious traffic from firewalls and other security products that might otherwise block direct connections to known malware command-and-control servers.
>>
>>That's because in order to perform SPF lookups, the malware queries a trusted DNS server located on the local network or the Internet service provider's network. This server then queries other DNS servers up the chain until the request reaches the authoritative DNS server for the domain name, which responds with a TXT or SPF record containing the SPF policy.
>>
>>"In some cases, specific domains are blocked by a local DNS server, but this malware generates a domain that is rarely filtered," Katsuki said
>>
>Rod Rasmussen
>President/CTO
>
>
>[]
>
>
>
>E-mail: <mailto:rod.rasmussen at internetidentity.com>rod.rasmussen at internetidentity.com
>Office: +1.253.590.4088 | Mobile: +1.253.297.0377 | Fax: +1.425.699.6597 
>24/7 Service Line: +1.253.590.4100 ext. 0 | 888.239.6932 ext. 0
>
>
>
>
>
>
>_______________________________________________
>dnsrpz-interest mailing list
>dnsrpz-interest at lists.isc.org
>https://lists.isc.org/mailman/listinfo/dnsrpz-interest