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.

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 “Was kommt nach DNS Response Rate Limiting?”

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 “DNSSEC Deployment in .CH”

DNSSEC Signierungs-Algorithmus wechseln

Eine DNS-Zone zu signieren ist mit heutiger Software nicht mehr schwierig oder kompliziert. Die Schwierigkeiten im Betrieb von signierten Zonen sind selten angewendete Prozeduren, wofür teilweise noch die Software-Unterstützung fehlt, sei dies in der Signierungssoftware oder in Monitoring- und Debugging-Tools. Eine solche selten angewendete Prozedur ist der Wechsel des DNSSEC Signierungs-Algorithmus.

Als SWITCH die DNSSEC-Signierung für die ccTLDs CH und LI im Jahr 2009 entwickelte und testete, entschied sie sich für den DNS Security-Algorithmus RSASHA1-NSEC3-SHA1 (RFC 5155). Aktuell ist der DNS Security-Algorithmus RSA/SHA-256 (RFC5702) einer der verbreitetsten Signierungs-Algorithmen unter TLDs (NANOG 56, E. Lewis), welcher auch von der Root-Zone verwendet wird. SWITCH hat in den letzten Wochen einen sogenannten Key Algorithm Rollover durchgeführt und auf den DNS Security-Algorithmus RSA/SHA-256 gewechselt.

Continue reading “DNSSEC Signierungs-Algorithmus wechseln”

Analysing DNS traffic using PacketQ

Our authoritative only name-servers are every once in a while hit by strange DNS queries. To spot anomalies we use DSC (DNS Statistic Collector), which allows exploring many details of DNS requests and responses to and from our name-servers. Usually one can already get a good sense of what has happened with DSC. However often, deep packet inspection is needed to get the full picture.

DSC Statistic showing query-type MX and ANY traffic anomalies
DSC Statistic showing query-type MX and ANY traffic anomalies

DNS traffic heading towards our authoritative only name-servers is stored for a few days in PCAP. Should we have any need to analyse some of the data we can then easily do so. Analysing very large PCAP files may sound cumbersome but thanks to PacketQ this is actually very easy and fast. PacketQ was originally developed by IIS.SE and is open source. It is a command line tool to run sql queries directly on PCAP files. It exports some IP and UDP header fields and most importantly all DNS protocol fields.

Continue reading “Analysing DNS traffic using PacketQ”

CH-Zone Opfer eines DNS-Amplifikations-Angriffes

Erst ein paar Wochen ist es her, dass wir über DDoS-Angriffe durch Reflektierende DNS-Amplifikation gepostet haben. Heute Morgen um 4 Uhr wurde nun erstmals auch die CH-Zone für einen solchen DNS-Amplifikations-Angriff missbraucht.

NetFlow Daten: Ein- und Ausgehender Datenverkehr der SWITCH CH-Nameserver
NetFlow Daten: Ein- und Ausgehender Datenverkehr der SWITCH CH-Nameserver

Die DNS-Anfragen lauten auf ‘CH’. mit dem Query-Type ‘ANY’. Zusätzlich wird die EDNS-Erweiterung aktiviert, was es ermöglicht in einer UDP-Antwort mehr als 512 Bytes zu erhalten. Ohne EDNS würde der autoritative DNS-Server mit dem gesetzten Flag „TC“ (Truncated) antworten, womit der Client aufgefordert wird, die DNS-Anfrage nochmals über TCP zu schicken. Bei gespooften DNS-Anfragen will man das natürlich verhindern, deshalb ist hier EDNS aktiviert. Wir sehen die DNS-Anfragen von mehreren Quell-Adressen, jedoch ist eine IP-Adresse besonders benutzt. Diese IP-Adresse, welches das Opfer des DDoS-Angriffes ist, empfängt alle Antworten.

Warum wird gerade die CH-Zone missbraucht?

Continue reading “CH-Zone Opfer eines DNS-Amplifikations-Angriffes”

DDoS-Angriffe durch Reflektierende DNS-Amplifikation vermeiden

Das DNS (Domain Name System) Protokoll ist momentan das häufigst missbrauchte Protokoll für Distributed Denial of Service (DDoS) Angriffe. Wurden früher vor allem öffentlich erreichbare DNS-Resolver (Open Resolver) als Amplifikator verwendet, werden heute zunehmend autoritative DNS-Server benutzt.

Was sind reflektierende DNS-Amplifikation-DDoS-Angriffe?
Bei reflektierenden DNS-Amplifikation-DDoS-Angriffen versenden infizierte Clients (meistens aus einem Botnet) tausende von DNS-Anfragen an autoritative DNS-Server, welche als Amplifikator missbraucht werden. Die DNS-Anfragen werden mit der IP-Adresse des Opfers gefälscht. Die autoritativen DNS-Server beantworten die DNS-Anfragen, wobei die Antwort ein Mehrfaches der Anfragegrösse sein kann. Für DNSSEC-signierte Zonen kann schnell ein Amplifikationsfaktor von über 40 entstehen.

Continue reading “DDoS-Angriffe durch Reflektierende DNS-Amplifikation vermeiden”

DNSSEC – Einführung zu DNS Security Extensions

Das Domain Name System (DNS) ist ein wichtiger Bestandteil des Internets. Aus Endbenutzersicht erscheint das Internet oft zusammengebrochen, wenn die Namensauflösung nicht funktioniert. In den letzten Jahren wurden Schwachstellen im Protokoll aufgedeckt, welche es erlauben, DNS-Antworten für einen DNS-Resolver zu manipulieren. Um die Vertrauenswürdigkeit der Daten sicherzustellen, wurde die Erweiterung DNSSEC entwickelt.

Was ist DNSSEC?

DNSSEC ist eine Erweiterung des Domain Namen Systems (DNS), die dazu dient, die Echtheit (Authentizität) und die Vollständigkeit (Integrität) der Daten von DNS-Antworten sicherzustellen.

Continue reading “DNSSEC – Einführung zu DNS Security Extensions”