SWITCH Security-Blog

SWITCH-CERT IT-Security Blog


SWITCH Public DNS Resolver

SWITCH operates recursive name servers for its constituency, the Swiss research and education network. Over the last year we have continually added support for transport encryption protocols on our recursive name servers such as DNS over TLS (DoT) and more recently DNS over HTTPS (DoH).

In contrast to default unencrypted DNS which runs over UDP/TCP Port 53 , both of these standards (DoT, DoH) use encrypted protocols which provide privacy for DNS queries between the client (application) and the recursive name server. This eliminates opportunities for eavesdropping and on-path tampering with DNS queries on the network.

Our motivation for enabling encrypted DNS protocols on our recursive name servers have been that some client applications (mostly Android 9) probe for DoT support and use it if available by default. Over the last year, other widely used applications have added support for encrypted DNS protocols. Most notably the web browser Mozilla Firefox which supports DoH but has not turned it on by default.

Opportunistic encryption of DNS queries and responses as it is used by Android 9 by default is one use case of DoT. However, some users want to pin a specific recursive name server regardless in which network they are or also to authenticate the name server. To support this use case, we have opened our recursive name servers over encrypted transport protocols to the Internet. You will find more information about the SWITCH Public DNS service and how to use it on this website:

https://www.switch.ch/security/info/public-dns/

Continue reading

Mobile Malware


Rogue Mobile App

Rogue mobile apps are counterfeit apps designed to mimic trusted brands or apps with non-advertised malicious features. In both cases, the goal is that unaware users install the app in order to steal sensitive information such as credit card data or login credentials.

The common way to install apps is to use the official app store. By default, neither Android nor Apple’s iPhone allow users to install apps from unknown sources. However, this does not mean we can just trust the official app store. SWITCH-CERT has been monitoring Apple’s App Store and Google Play for some time and noticed that many rogue apps are able to sneak into Google Play especially.

Google Play

Attackers are abusing the weak app testing procedure of Google to sneak their rogue apps into Google Play. One can find counterfeit apps of Swiss brands on a regular basis. Typically, the apps reside on Google Play for some time until it is removed because of take down requests from security researchers. Until that happens, unaware users are likely to install such apps and put their data at risk.

The screenshot below shows apps found when searching for Bluewin. During the last months, Bluewin has been a common target for rogue counterfeit apps. The red circle indicates the rogue app.

Play Store result for the search key word “Bluewin”

Continue reading


1 Comment

Breaking security controls using subdomain hijacking

Users obtain a domain name to establish a unique identity on the Internet. Domain names are not only used to serve names and addresses of computers and services but also to store security controls, such as SPF or CAA records. Many of the Internet protocols were designed at a time where built-in security was not a requirement. The IETF continues to standardize protocol extensions to address today’s security needs.

For some protocols security is added with controls stored in your domain names zone file. In order to have the desired effect, the pre-condition is of course that your domain name is secure. In other words, the security of your application that makes use of controls in DNS is only as secure as the security of your domain name.

Hijacking a domain name because of weak credentials at the registrar may get the job done but this is far from stealthy and will likely not last long. In many cases it is sufficient to hijack an abandoned subdomain. Taking over abandoned subdomains may be unnoticed by the owner for a very long period of time making it also very useful for targeted attacks.

Picture 1: update.ft.com has been hijacked and the content from the ft.com front page is mirrored with a fake article about subdomain hijacking. Note: the website is not online anymore, Financial Times has been notified to remove the abandoned record from their zone file. A Certificate Transparency (CT) log proves that a TLS certificate has been issued for this demo site.

Continue reading


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


2 Comments

Attack of the killer Ads

By Daniel Stirnimann and Serge Droz

Recently I was quoted saying “… .ch and .li are the most secure (top-level) domains!”. In the same meeting, Security Rock Star Mikko Hyppönen claimed, “Surfing the Web with your laptop is the most dangerous thing you can do in the Internet.”  So what is true, what is false? Rather than speculate about obscure statistics I’d like to illustrate one of the big problems we face in .ch today, namely using ads as a back door to reach victims through reputable sites.

Ads: enter through the hallway

Malware distributors have one goal: spreading their stuff as widely as possible. This is achieved through different means. Malware was traditionally distributed – and still is – through e-mail attachments. This was the case, for example, with the Retefe malware. Alternatively, web pages can be hacked and used to spread malware by exploiting browser bugs. SWITCH has been very active, through its Safer Internet initiative, in working to reduce this infection vector. In fact, we’ve been so successful, that drive-by is very scarce in Switzerland, hence the statement that ” … .ch is one of the most secure ccTLDs”. Drive-by websites are always hacked, but in most cases they are not very popular websites, since popular websites are typically well protected. Many of the later ones offer a backdoor tough: ads! News sites in particular make most of their revenue by selling on line ads, which explains the “ad-war” arms race between ad-blockers an news agencies (see our Security Report on anti-anti-ad features). A very common way is malvertising, a term coined by William Salusky. Salusky found ads that were in fact carrying malicious payloads. Let’s look at a slightly different scenario, namely a legitimate but compromised ad server. While technically a different scenario it has the same effect on the end user.

Most people would think that visiting a website just serves you content from that site but this is not true for most of the large sites, in particular news sites. They import contents such as videos, trackers, counters, scripts and especially ads from third-party sites. These are not controlled by the original site, and often import content themselves from yet another site. Thus, a well maintained site with high security standards will often import stuff from sites with lower security. Think of it as sitting in a highly rated restaurant that has one bad food supplier.

The image below shows all the external sites involved whenever you visit three popular news sites.

 

Ohne Addon

The above example shows what happens when you visit three popular Swiss newspapers. Triangles denote third-party sites from which content is imported when you visit the respective news site. The visualisation was done using the Mozilla addon LightBeam

Continue reading