SWITCH Security-Blog

SWITCH-CERT IT-Security Blog


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


1 Comment

There is no such thing as a free domain

Since quite a long time now SWITCH actively cleans up drive-by sites. Attackers using the ever same tricks, analysing has become quite a routine, if not to say a bore. However recently, we stumbled over a new pattern. Many of the reported domains looked like

law-enforcement-XXX.domain.ch

where XXX are three random letters. Most of the domain names didn’t give anything back when we tried. And they all had their name-servers with afraid.org, a free DNS hoster, which indeed provides quite a comprehensive service.

All these domains are used by malware, mostly ransomware. A lot has been written about this topic, so I won’t add another blog post about this.

What is the issue with afraid.org? In a nut shell: Their business model: The default, free, setting when you register a domain is public. You forked out some money to get a domain name, obviously it should be public, or no one can see it. However public in afraids terminology means:

Public – If you add your domain as public, […] , others will be permitted to create sub domains off your domain without involving you.

Indeed, creating a sub domain pointing to something totally unrelated is easy. Only premium members ($5/month) have full control over their domain.

Obviously miscreants will be busy finding new, creative, ways of using this service. And we are not the only ones concerned about this, so are our colleges at Check and Secure. But just blaming afraid.org would be too easy. Running a quality DNS service is not a simple task. It needs resources, time – know-how and, last but not least, money to buy hardware, pay power bills etc. The folks at afraid.org are very helpful and quick in fighting misuse.

So maybe it’s us (the internet community) who all too often confuse free with free beer: We are happy to use free services, free software and don’t care about the implications of a low price. Not convinced yet? Let’s rephrase this: Would you run your important e-business on infrastructure developed by a couple of aficionados in their spare time? No? Yes, you probably do. Only after a major disaster like heartbleed do people realize that there is no such thing as free as in free beer software. The same is true for free DNS.

So zooming back: How bad was this really: According to afraid.org there where about 100 ransomware sub domains with the “law-enforcement” pattern. Looking at Dynamoo’s Blog there were many more domains and patterns. They are, thanks to the afraid.org folks gone. As we have seen many other .ch/.li domains hosted at afraid.org abused, we informed about 700 owners of afraid.org hosted .ch/.li domains with the default public shared state. Our recommendation: Pay $5 / month!

 

 


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