SWITCH Security-Blog

SWITCH-CERT IT-Security Blog


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


1 Comment

A Yeti in the DNS

written by Yves Bovard

Most of the time, the Internet works without any problem; we can just power on our computer and start surfing… ok, most of the time. Many things have to be reliable to make this possible: power, cables, routers, computers, software and, last but not least, the DNS. This last point is one of the most critical parts of the Internet. Each time we read our favorite online newspapers, each time we check our e-mails, write and reply to them, or more generally, each time we use the Internet, many queries are sent to DNS servers to convert (more or less) meaningful Web addresses to IP addresses. And this is only the tip of the iceberg.

In the early days of the Internet, this task was handled by a single file. During the 1980s, however, it became clear that such a method was not scalable enough. The DNS was thus born. Three parts were designed. First, the stub resolver is located on your computer. It receives your question: what is the IP of www.switch.ch? This question is transformed to a standard DNS message and sent over the network to the second part, the resolvers. These are able to find an answer almost instantly, either because somebody has already looked for it or by querying the third part, the authoritative servers, located somewhere on the Internet. They are structured in a hierarchical tree, with root servers at the top. Some of them know the answer to the question you asked.

Nowadays, the authoritative root of the tree is made up of 13 servers named alphabetically from a.root-servers.net to m.root-servers.net. In reality, a technique named anycast allows a much larger number of servers around the world to listen out for (and answer with) the same address. For example, k.root-server.net actually comprises 33 nodes spread all across the globe. To analyse the workload of the DNS, DNS OARC (DNS Operations Analysis and Research Center) computes yearly statistics (Day in The Life of the Internet, DITL). In 2015, it used a time window of three days and found that 10 of the 13 root servers answered about 60 billion queries in this period.

The current state of this infrastructure is robust. A single server failing to respond does not affect the availability. When a server is overloaded, we can just add more servers to spread the traffic. The size and complexity of this infrastructure make it hard to analyse. The new Yeti DNS Project (www.yeti-dns.org) aims to study it by asking the following questions and more:
Continue reading


2 Comments

So Long, and Thanks for All the Domains

While Trojans like Dyre and Dridex are dominating malware-related news, we take the time to have a closer look at Tinba (Tiny Banker, Zusy, Illi), yet another Trojan which targets Windows users. In the first part of this post, we give a short historical review, followed by hints about how to detect (and remove) this threat on an infected system. In the second part, we have a look at a portion of the Trojan’s code which enhances its communication resilience, and how we can leverage these properties for defensive purposes.

Tinba is a fine piece of work, initially purely written in assembly. CSIS discovered it back in May 2012, and it contained WebInject capability and rootkit functionality in a binary of just 20 KB. The source code of Tinba leaked in July 2014, helping bad guys to create their own, extended versions.

Tinba Rootkit ZwQueryDirectoryFile

The source code of Tinba leaked in July 2014. Shown are some preparations to hook ZwQueryDirectoryFile.

Tinba on steroids was discovered in September 2014. Two main features are worth noting: First, each binary comes with a public key to check incoming control messages for authenticity and integrity. Second, there is a domain generation algorithm (DGA), which we will discuss later. In October 2014, Tinba entered Switzerland, mainly to phish for credit card information.

Tinba Inject

Tinba tried to phish credit card information.

Like other commodity Trojans, Tinba checks whether it is running in a virtual machine/sandboxed environment by checking the hard-disk size or looking for user interaction. According to abuse.ch, there was an intense distribution of Tinba in Switzerland early this year. Such spam campaigns can happen again at any time, so it is of use to know how to detect Tinba on an infected system and remove it.

Even though Tinba has the ability to hide directories and files (rootkit functionality), cybercriminals were wondering why they should bother using it. Why not simply hide directories and files with the “hidden” flag, which works for most users? Thus, it is relatively simple for a computer-savvy user to remove this version of Tinba from an infected (see instructions below).

Tinba Directory Hidden

A randomly named directory, which contains the Trojan itself, can be hidden by setting its attributes to “hidden”.

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

Update Nov 2017: DNSSEC zone signing as described here is outdated. We strongly recommend against the method described in this blog post. Newer BIND versions or other DNS software have greatly simplified DNSSEC 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

News


IT-Security-Links #61

  • McAfee Labs reports that a new ransomware called CryptoWall uses Tor for communication and demands Bitcoin from the user in exchange for the private key to decrypt the files. “The use of Tor and Bitcoin in this operation make tracing the attackers more difficult” writes McAfee.
  • Firefox version 31 is improving malware detection. Firefox has long been using Google’s Safe Browsing service to check for malicious web sites, now it also checks downloaded files.
  • Isreal’s Homeland Security writes that anonymous hackers have launched DDoS attacks against network infrastructure from Israel. The attacks also affected DNS name resolution on domain names ending in .co.il.
  • The Register writes that Security outlet VUPEN has revealed it held onto a critical Internet Explorer vulnerability for three years before disclosing it at the March Pwn2Own hacker competition. VUPEN makes money by selling exploits to its customers.
  • The Moscow Times writes that Russia’s Interior Ministry has put out a tender on its official government procurement website for anyone who can identify Tor users. On a related note, the Tor team issued a security advisory this week, warning operators of hidden services about attacks to deanonymizing users. And if that’s not enough Tor news for this week, according to the Tor project’s latest annual financial statements (PDF), the US government increased its funding to 1.8 million US dollars in 2013!

German:


2 Comments

Taking Advantage of DNSSEC

According to measurements by APNIC’s Geoff Huston currently 16 percent of Swiss Internet users use a DNSSEC validating DNS resolver. If you want to benefit from the added security with DNSSEC in your network then I suggest you enable DNSSEC validation in your network as well. SurfNet published a deployment guide recently that takes BIND 9.x, Unbound and Microsoft Windows Server 2012 into account.

Enabling DNSSEC validation on your DNS resolvers is one simple step and it protects you from DNS Cache Poisoning. However, if it were only for this, then the DNSSEC protocol complexity would come at a high cost for only providing this one benefit. In fact, DNSSEC is much more than only a protection from Cache Poisoning. It’s a new PKI in DNS and if you have signed your zone and are already validating then you can take advantage of that PKI. Some use cases are described below but there are many more ideas which are currently discussed.
Continue reading

News


IT-Security-Links #56

German:


Verbindungsprobleme bei der DNS Namensauflösung erkennen

Die ursprüngliche Spezifikation von DNS-Nachrichten (RFC 1035), welche über UDP gesendet werden, ist auf 512 Bytes begrenzt. Bereits Ende der Neunzigerjahre wurde mit dem “Extension Mechanisms for DNS (EDNS0)” (RFC 2671) eine Erweiterung für das DNS-Protokoll festgelegt, welche es u.a. dem Client erlaubt eine grössere Buffergrösse bekannt zu geben.

Die meisten DNS Resolver-Implementierungen kündigen eine Buffergrösse von 4096 Bytes an. Das heisst aber auch, dass bei einer maximalen Paketgrösse (Maximum Transmission Unit, MTU) von 1500 Bytes eine Fragmentierung der Datenpakete stattfindet. Die Vergangenheit hat gezeigt, dass viele Netzwerk- und Sicherheitsprodukte diese Protokolländerung noch nicht mitgekriegt haben und auf eine kleinere Paketgrösse bestehen. Für DNSSEC ist die EDNS0-Erweiterung eine Voraussetzung, da durch die Signierung der Daten die Paketgrösse ansteigt.

Die Unterstützung einer grossen Buffergrösse von Ihrem DNS-Resolver zur Aussenwelt ist aber auch relevant, wenn Sie keine DNSSEC-Validierung auf dem DNS-Resolver aktiviert haben. Aktuelle DNS-Resolver kennzeichnen die Unterstützung von DNSSEC (durch das DO-bit, Bezeichnung “DNSSEC OK”-bit, RFC 3225) und erhalten deshalb in der Antwort die DNSSEC-Signaturen, auch wenn der DNS-Resolver die Validierung nicht aktiviert hat.
Continue reading


DNS Zone File Time Value Recommendations

When setting up a zone file for a domain name, the administrator can freely choose what time values he would like to set on the SOA record or regarding the Time To Live (TTL) value on the Resource Records (RR). There are already many useful documents describing recommendations for these time values but most lack the reference to signed zones using DNSSEC because at the time these documents were published, DNSSEC did either not exist or had no relevance. We tried to update the recommendations for these time values so that the none-experts can adapt their template or have a reference. Our recommendations work for both signed and unsigned zones and in the best case it helps improve the stability and resilience of the DNS.

Our recommended DNS example.com zone file in BIND format looks as follow:

$TTL 86400 ; (1 day)
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
                2014012401 ; serial YYYYMMDDnn
                14400      ; refresh (4 hours)
                1800       ; retry   (30 minutes)
                1209600    ; expire  (2 weeks)
                3600       ; minimum (1 hour)
                )

         86400    IN   NS    ns1
         86400    IN   NS    ns2

                   IN   A     203.0.113.10
                   IN   AAAA  2001:DB8:BEEF:113::10
www                IN   CNAME example.com.
ftp                IN   CNAME example.com.

ns1      86400    IN   A     192.0.2.22
         86400    IN   AAAA  2001:DB8:BEEF:2::22
ns2      86400    IN   A     198.51.100.22
         86400    IN   AAAA  2001:DB8:BEEF:100::22
...

Please read the following sections for a more detailed explanation.

Continue reading


SWITCH DNS/DNSSEC Audit

SWITCH is regularly assessing parts of the registry infrastructure in technical audits. The goal of these audits is to find operational or software vulnerabilities before attackers do. For 2013 we wanted to audit the DNS/DNSSEC related aspects of the registry and DNS name server service operation. The introduction of DNSSEC for the ch. and li. zones in early 2010 brought a lot of changes to our DNS management software, the registry application and to the registrar interface. Naturally, most changes occurred in the DNS management software, which is responsible for properly signing the zones and rolling the keys.

In 2009, when we started the DNSSEC project internally, mature support for DNSSEC was close to inexistent, so we ended up writing our own scripts and tools around ISC BIND. In the mean time BIND added support for inline-signing and OpenDNSSEC matured a lot, just to name a few examples. If you are on the verge of signing your zone, I suggest you look at already existing solutions first. I don’t think that today there is still a need to develop your own script and tools. However, ours have been in production since then. So we felt, it was high time to get an independent view on our implementation.

Continue reading


DNS Hijacking nimmt zu

Internetbenutzer die den Domainnamen nytimes.com in der Navigationsleiste ihres Browsers eingegeben hatten, sahen gestern für sechs Stunden nicht etwa die Webseite der Zeitung, sondern eine Seite der “Syrian Electronic Army” oder eine Fehlermeldung. Wie die Los Angeles Times berichtet, wurden die Zugriffs-Credentials eines Resellers von Melbourne IT missbraucht um die DNS-Einträge für nytimes.com zu ändern und die Besucher so auf einen anderen Webserver zu leiten.

Angriffe über das Domain Name System (DNS) häufen sich in der letzten Zeit. Statt eine gut gesicherte Webseite zu hacken, versuchen Kriminelle den Domainnamen auf den eigenen Server umzuleiten. Der Web-Traffic ist viel wert, sei es für Propaganda, wie im Fall der Syrian Electronic Army, oder für kriminelle Zwecke, wie das Verteilen von Malware, Clickfraud oder zur Search Engine Optimierung.

Statt einzelne DNS-Server zu hacken, versuchen die Kriminellen verstärkt, Registries, Registrare und Reseller von Domainnamen anzugreifen. Gelingt es ihnen in die Systeme oder an Credentials zu gelangen, können so oft gleich tausende von Domainnamen auf den eigenen Server umgeleitet werden. Prominente Opfer sind vor allem viel besuchte Webseiten wie Suchmaschinen oder Nachrichtenportale.

Auch Schweizer Domainnamen waren in der vergangenen Woche von falschen DNS Antworten betroffen. Continue reading

News


IT-Security-Links #30

  • Geoff Huston (APNIC) published a long post on his DNSSEC validation measurements. Since March 2013 he has seen an rise in the number of DNSSEC validating resolvers from 3.3% to 8.1%. This increase is mainly because Googles public DNS has started to validate a few weeks ago. For Switzerland the number of validating DNSSEC resolvers is at 5.13%.
  • Mac OS X Malware: Malwarebytes.org reports that FBI ransomware is now targeting Apple’s Mac OS X users. The news received a lot of attention and so Malwarebytes.org posted a Q&A.
  • AndroRAT, is a free Trojan horse for Android devices that allows a remote attacker to gain control over the device and steal information from it. Cybercriminals have now created a tool called “binders” that easily allows users to repackage and Trojanize legitimate Android applications with AndroRAT. To date, Symantec has counted 23 cases of popular legitimate apps being Trojanized in the wild with AndroRAT.
  • You would think that server compromises have advanced a lot. This does not mean that old style attacks such as simple account brute-forcing still don’t work. According Sucuri SSH brute-force, an attack 10 years old still persists.
  • Harlan Carvey from the Windows Incident Response Blog posted the first part of the HowTo serie “Malware Detection”. An interesting read on how to easily detect malware on an infected computer.


3 Comments

Was kommt nach DNS Response Rate Limiting?

Werden autoritative DNS-Server über reflektierende DNS-Angriffe missbraucht, zum Beispiel um in einem Distributed Denial of Service (DDoS) Angriff ein Zielsystem zu überlasten, so ist eine der vorgeschlagenen Massnahmen DNS Response Rate Limiting (DNS RRL) zu aktivieren.

SWITCH hat auf diesem Blog bereits in früheren Posts über DNS Angriffe und Massnahmen berichtet. In diesem Artikel möchten wir unsere neusten Beobachtungen im Betrieb von DNS RRL teilen und zeigen, dass es Anzeichen gibt, dass die Angreifer die Schwächen von DNS RRL ausnutzen um weiterhin ihre Angriffe durchführen zu können.

Stärken und Schwächen von DNS RRL
Für viele autoritative DNS Serverbetreiber war DNS RRL eine ersehnte Lösung um die Serverlast und vor allem die ausgehende Serverbandbreite aufgrund von reflektierenden DNS-Angriffen einzuschränken. DNS RRL lässt für einen IP-Adressbereich nur eine bestimmte Anzahl identische DNS Antworten zu. Wird der konfigurierte Schwellwert überschritten, verwirft DNS RRL zum einen die DNS-Antwort. Für einen anderen Teil der Antworten wird das “Truncated”-Bit (TC) in der Antwort gesetzt, damit wird der DNS Resolver aufgefordert, die Anfrage noch einmal über TCP zu stellen. Da bei reflektierenden DNS-Angriffen die Quelladresse gefälscht wird, kommt nie eine Verbindung über TCP zu Stande. Im Gegensatz zu Firewall-Regeln hat der DNS RRL Ansatz den Vorteil, dass bei einem leicht geänderten Angriffs-Pattern (z.B. Query-Name ändert) die implementierten Firewall-Regeln nicht angepasst werden müssen. Kurz, DNS RRL ist sehr effektiv gegenüber Angriffen, bei denen DNS-Anfragen gesendet werden, welche in identischen Antworten resultierten.
Continue reading


DNSSEC Deployment in .CH

It has now been three years since SWITCH officially signed the .CH and .LI ccTLDs. Since then adoption of DNSSEC for the .CH domains has been very slow. During the last few weeks we have seen a small increase, but noticeable, including one registrar (OVH.de); who have started to sign a few hundert domain names. It may be the start to something bigger; however we trail other TLDs in the number of singed delegations (See https://xs.powerdns.com/dnssec-nl-graph/) by a large margin

Currently, SWITCH does not publish statistics about DNSSEC, as only 0.05% of all active domains use DNSSEC. Therefore publishing any DNSSEC statistics remain unjustified.

In this blog article we want to give you a look at the numbers nonetheless. Please keep in mind that: because the number of DNSSEC enabled domains is so low, the interpretation of the data and graphs should not be taken too seriously, the numbers can change very quickly.

Continue reading