SWITCH Security-Blog

SWITCH-CERT IT-Security Blog


Leave a 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


1 Comment

11th October 2017, DNSSEC key rollover of the root zone, be ready the key is here!

On the 27th September, ICANN announced the postponement for the KSK rollover. More information can be found here.

No, this is not a kind of secret message nor a new ice-cream. On 11th October 2017 the root zone will be signed with a new key. Ladies and gentlemen, update your DNS resolver. As of July 11th, the new key is published in the root zone and your resolver should start updating its trust anchors automatically!

Continue reading


16 Comments

94 .ch & .li domain names hijacked and used for drive-by

A Swiss domain holder called us today telling us that the .ch zone points to the wrong name servers for his domain.

The NS entries were ns1.dnshost[.]ga and ns2.dnshost[.]ga. We contacted the registrar and soon realized that this is not the only domain that had unauthorized changes. We identified 93 additional .ch and .li domain names that pointed to the two rogue name servers. While domain hijacking by pointing to a rogue NS is a known attack,  94 domains on a single day is very unusual. So we analyzed what the hijacked domains were used for and soon found out that they are used to infect internet users with malware.

Visitors to the hijacked domains were redirected to the Keitaro TDS (traffic distribution system):

hXXp://46.183.219[.]227/VWcjj6

A TDS decides where to redirect the visitor to, often depending on its IP address (i.e. country),
user agent and operating system.

A dead end may look like the following:

hXXp//46.183.219[.]227/favicon.ico
hXXp://46.183.219[.]227/www.bingo.com

And the visitor will be redirected to Google.

However, in some cases, the visitor is redirected to the Rig Exploit Kit:

hXXp://188.225.87[.]223/?doctor&news=...&;money=...&cars=236&medicine=3848
hXXp://188.225.87[.]223/?health&news=...
...

And the visitor gets infected.

The payload is Neutrino Bot:

MD5: a32f3d0a71a16a461ad94c5bee695988
SHA256: 492081097c78d784be3996d3b823a660f52e0632410ffb2a2a225bd1ec60973d).

It gets in touch with its command and control server and grabs additional modules:

hXXp://poer23[.]tk/tasks.php
hXXp://poer23[.]tk/modules/nn_grabber_x32.dll
hXXp://poer23[.]tk/modules/nn_grabber_x64.dll

A little later, it also gets an update

hXXp//www.araop[.]tk/test.exe

MD5: 7c2864ce7aa0fff3f53fa191c2e63b59
SHA256: c1d60c9fff65bbd0e3156a249ad91873f1719986945f50759b3479a258969b38)

Status

The rogue NS were inserted in the .ch zone file at around 13:00 today. The registrar discovered soon what happened and rolled back the unauthorized changes. At 16:00 all of the changes in the .ch & .li zone were reverted and the NS records pointed to the legitimate name servers again.

[Update 10.7.17 17:15]

Gandi the registrar of the 94 domain names has written a blog post, as well as SCRT the domain holder that initially informed us about the domain name hijacking of scrt.ch. SCRT also showed how Strict Transport Security protected their recurring visitors from being redirected to the bogus website!


1 Comment

DNSSEC Signing for .ch and .li on the Rise

The share of DNSSEC signed domain names in .ch and .li reached 1% for the first time in June 2017. While this is still a very low number compared to other ccTLDs, the number of DNSSEC signed domain names is increasing at a high rate for the last two quarters.

DNSSEC

The Domain Name System Security Extensions (DNSSEC) is a set of technologies that secures the origin authentication and data integrity of the Domain Name System. It allows to detect DNS records that have been modified on the way from the authoritative name server to the client using a domain name. This helps to protect Internet users from going to bogus websites.

In addition from protecting Internet users from cybercriminals and state sponsored actors, DNSSEC is the base for important standards such as DNS-based Authentication of Named Entities (DANE).

DNSSEC in .ch and .li

DNSSEC was enabled for the .ch and .li zones in 2010 but unfortunately received a slow adaptation by domain holders. From 2013 there was a slow but steady growth of domain names signed with DNSSEC. In November 2016 we noticed a increased rate of DNSSEC signed domain names that accelerated in April 2017.

From now on SWITCH will publish statistics about the number of signed domain names for both ccTLDs .ch and .li on the nic.ch and nic.li website.

DNSSEC Signed Domain Names in .ch   DNSSEC Signed Domain Names in .li
Continue reading


6 Comments

Usage of .ch domain names for spamming malware Tofsee stopped

It is rare that a malware family uses .ch or .li domain names in their domain name generation algorithm (DGA). The last time I remember, that we had to take action against a malware using .ch or .li domain names was about 8 years ago. It was Conficker that infected millions of computers worldwide. The malware was generating about 500 .ch and .li domains a day to be potentially used as a command and control server. By then SWITCH joined the conficker working group to prevent the use of domain names by this malware.

Since then we have been watching the use of .ch and .li domain names in malware DGAs and prepared for this by making an agreement with the Registrar of Last Resort (RoLR) to prevent the registration of domain names used in DGA algorithms of malware.

This week the Swiss Govermental Computer Emergency Response Team (GovCERT) informed us about the malware Tofsee using .ch as one of the TLDs in its DGA. 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