SWITCH Security-Blog

SWITCH-CERT IT-Security Blog

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