SWITCH Security-Blog

SWITCH-CERT IT-Security Blog


Why the most successful Retefe spam campaign never paid off

Switzerland is one of the main targets of the Retefe banking trojan since its first appearance in November 2013. At that time, it changed the local DNS resolver on the computer (See also blog post “Retefe Bankentrojaner” in German only). Almost a year went by until they changed to the still current approach of setting a proxy auto-config (PAC) URL (See also blog post “The Retefe banking Trojan has targeted Switzerland“). To understand the story of this blog post, it helps to understand the modus operandi of the Retefe malware. We recommend you read up on it on our blog links posted above if you are not familiar with it.

While the Retefe actors are constantly changing tactics, for example their newest campaigns also target Mac OS X users, their malware still works the same. One of notable changes was the introduction of Tor in 2016. At first, they started using Tor gateway domain names such as onion.to, onion.link within the proxy auto-config URLs, later on they switched to Tor completely. The advantage of using Tor is of course, anonymity and the difficulty to block or take down the infrastructure.

Onion domain names don’t use DNS or do they?
The Tor network can use .onion domain names but these names are not resolved over DNS but instead work only in the Tor network. RFC 7686 (The “.onion” Special-Use Domain Name) goes into more details on the special case of .onion domain names. However, the fact is that .onion domain names do leak into the DNS system. For potential reasons and more information on this subject we recommend the paper by Versign Labs “Measuring the Leakage of Onion at the Root” (PDF).
Continue reading


2 Comments

SWITCH DNS recursive name service improvements with dnsdist

SWITCH operates recursive name servers for any user within the Swiss NREN. While larger universities typically run their own recursive name server, many smaller organisations rely on our resolvers for domain name resolution. During the consolidation of our name server nodes into two data centres, we looked for opportunities to improve our setup. Dnsdist is a DNS, DoS and abuse-aware load balancer from the makers of PowerDNS and plays a big part in our new setup. While the first stable release of dnsdist (version 1.0.0) is only a few days old (21 April 2016), it feels like everyone is already using it. We are happy users as well and want to share with you some of the features we especially like about dnsdist.

Our old setup consisted of several name server nodes which all shared the same IP address provided by anycast routing. Our recursive name server of choice was and still is BIND, and we have been providing DNSSEC validation and malicious domain lookup protection through our DNSfirewall service for some time. While this setup worked very well, it had the disadvantage that some badly behaved or excessive clients could degrade the performance of a single name server node and as such affect all users routed to this node. Another disadvantage was that each name server node got its share of the whole traffic. While this may sound good, it has the disadvantage that we have several smaller caches, one on each node. My favorite quote from Bert Hubert, founder of PowerDNS, is: “A busy name server is a happy name server“. What it means is that it is actually faster to route all your queries to a single name server node because this will improve the cache-hit rate.

Dnsdist provides a rich set of DNS-specific features
Our new setup still makes use of anycast routing. However, it is now the dnsdist load balancer nodes that announce this IP address, and they forward the queries to the back-end recursive name servers for domain name resolution.

The server nodes are located in two data centres, and both load-balancers announce the same IP address to make use of anycast routing. Query load is typically sent to resolvers within the same data centre but is distributed to the other site as well in the event of a higher load or server loss.


Continue reading


6 Comments

Optimizing Negative Caching Time in DNS

A recent presentation by SIDN (.nl) at the Spring 2016 DNS-OARC workshop reminded me of the importance of Time-To-Live (TTL) values in TLD zones. Specifically, it got me thinking about lowering the negative caching time in .ch/.li from currently 1 hour to 15 minutes.

What is negative caching?
When a resolver receives a response to a query, it caches it for the duration of the TTL specified by the record. For positive responses, the record contains the TTL, but for negative responses (response code NXDOMAIN), there is no answer to the query question. For this case, the response contains the SOA record of the zone in the authority section. Negative caching is specified in RFC 2308 as the minimum of the SOA record’s TTL and the SOA minimum field. For example, the original SOA record of the .ch zone looked as follows:

dig +nocmd +noall +answer @a.nic.ch ch. soa
ch. 3600 IN SOA a.nic.ch. helpdesk.nic.ch. 2016041421 900 600 1123200 3600

The SOA TTL is 3600, and the SOA minimum time is also set to 3600. The minimum of these two values is of course 3600 too. That means the negative caching time for any .ch domain lookup is one hour.

A lower negative caching time is more user-friendly
People who are about to register a new domain name may also look up the name over DNS. However, this means that they just cached the non-existence of the name in the resolver they are using. A domain can be registered in a matter of minutes, and this can prevent them from using the domain name on their network for the duration of the negative caching time.
Continue reading


Protect your network with DNS Firewall

If you run your own mail server, you will quickly find out that 90% of the e-mails you receive are spam. The solution to this problem is e-mail filtering, which rejects or deletes unwanted spam. This solution is generally well accepted, and most users would not want the old days back when your inbox was filled with scams. Those people who want spam can also work around it by disabling spam filtering for their e-mail address or opting to run their own mail server.

Spam, scammers and other malicious abuse are not unique to e-mail. One possible approach is to invent a filtering technology for every protocol or service and allow the service owners to block misuse according to their policy. On the other hand, most services on the Internet make use of the Domain Name System (DNS). If you control DNS name resolution for your organisation, you can filter out the bad stuff the same way you filter out spam on e-mail. The difference and the advantage of DNS is that DNS filtering is independent of the service you use.

Back in 2010, ISC and Paul Vixie invented a technology called Response Policy Zones (RPZ) (See CircleID Post Taking back the DNS). While it has always been possible to block certain domain names from being resolved on your DNS resolver, adding host names manually as an authoritative zone does not scale.

(Illustration Christoph Frei)

(Illustration Christoph Frei)

Continue reading


DNSSEC signing your domain with BIND inline signing

With BIND 9.9, ISC introduced a new inline signing option for BIND 9. In earlier versions of BIND, you had to use the dnssec-signzone utility to sign your zone. With inline signing, however, BIND refreshes your signatures automatically, while you can still work on the unsigned zone file to make your changes.

This blog post explains how you can set up your zone with BIND inline signing. The zone we are using is called example.com. In addition, we look at how to roll over your keys. In our example, we do a Zone Signing Key (ZSK) rollover. We expect that you are already familiar with ISC BIND and have a basic understanding of DNSSEC. More specifically, you should be able to set up an authoritative-only name server and have read up on DNSSEC and maybe used some of its functions already.

Architecture

Before we set up inline signing with BIND, let us look at a typical network architecture. We will set up inline signing on a hidden master name server. This server is only reachable from the Internet via one or more publicly reachable secondary name servers. We will only cover the configuration of the hidden master as the secondary name server configuration will not differ for the signed zone (assuming you are using DNSSEC-capable name server software).
Continue reading


Retefe with a new twist

A few months ago, we blogged about the banking trojan Retefe (Blog post in German) that was and still is targeting Switzerland. First off, Retefe is different because it only targets Switzerland, Austria and Sweden (and sometimes Japan). Contrast this to many other banking Trojans, which have a much more global and dynamic target list. Not only that, but the Retefe infrastructure also prevents computers from not affected countries to connect to its systems by using geo-location aware access lists and filters. The second unique property of Retefe is the fact, that it only modifies the operating system by adding a fake root certificate and by changing the DNS server for domain name resolution. After infection, the installer removes itself, which makes life hard for anti-virus software trying to detect a malicious Retefe component or activity.

Since a few days, Retefe is back again with a new twist. It still targets the same countries and the same banks. Not too exciting, the spam campaign has changed. However, in this wave Retefe is picky and only installs itself on selected computers. And some icing to the cake, it also installs another malware called DOFOIL. In this blog post, we give a technical analysis of the new Retefe.
Continue reading


1 Comment

A look at a phishing website

Yesterday we came across a phishing website under .ch where we were able to download the phishing kit. A phishing kit is an archive file which contains all the relevant files for hosting a phishing website. In this case, the archive contained some static HTML, JS and image files for hosting the phishing form, but also a PHP file for sending the data to the perpetrator, and – most interestingly –an .htaccess file. The .htaccess file is a configuration file used by some popular web servers, which allows the user of a website to override a subset of the server’s global configuration for the directory that the file is located in and all its sub-directories.

A phishing website is frequently only accessible from the targeted country. In our case, this was controlled by the .htaccess file which contained a large list of IP address ranges from where it is allowed to access the site. As an incident handler, we often get reports of malicious websites that we cannot verify with IP addresses from Swiss ISPs. An unwary user might think that the phishing website has already been taken down, but that is not the case. The user is just not allowed to access the phishing website from its IP address.

Continue reading