XSS auf Abwegen

Cross-Site-Scripting (XSS) ist ansich eine altbekannte Schwachstelle, die in den meisten gängigen Frameworks mittels Eingabevalidierung standardmäßig mitigiert wird. Auch viele Individualanwendungen im Netz behandeln Eingabefelder, die von Dritten ausgefüllt werden, inzwischen sehr vorsichtig.

Zweckentfremdete DNS-Records

Dass derartige Angriffsvektoren oft auch von unerwarteter Seite kommen, zeigte sich, als ich nach der Lektüre des sehr lesenswerten Artikels The Joy of TXT von Peter Lowe ein wenig mit meinen DNS-Einträgen herumspielte – und prompt auf verschiedenen Seiten, die TXT-DNS-Records auslesen und anzeigen, mit meinen eigenen Popups begrüßt wurde.

TXT-Records werden oft für Validierungszwecke eingesetzt, die über die Standard-DNS-Records nicht abgedeckt werden können. Hierzu zählen meist SPF-, DMARC- und DKIM-Einträge sowie verschiedene Validierungen von Drittanbieter-Services. Unter anderem kann ein derartiger Eintrag zum Beispiel von LetsEncrypt genutzt werden, um die Domain zu verifizieren.
Doch die Möglichkeiten sind praktisch unbegrenzt. TXT-Records können, wie im Artikel beschrieben, sogar relativ große Mengen an Text bereitstellen. Und damit natürlich auch Javascript-Snippets, die auf abfragenden Webseiten mit XSS-Schwachstellen dafür sorgen können, dass Code im Webbrowser angezeigt wird.

Die bekanntesten Anbieter für DNS-Validierungsdienste und artverwandte Services entschärfen derartige Einträge standardmäßig. Auf der Webseite wird der bereinigte Inhalt der TXT-Records angezeigt, das Script kommt nicht zur Ausführung. Doch Ausnahmen bestätigen die Regel: Einige Anbieter scheinen davon auszugehen, dass von dieser Seite keine Gefahr droht und binden die Inhalte ungefiltert im Browser ein – unerwünschten Code inbegriffen.

Unübliche Server-Header

Bei meiner Recherche stieß ich auf eine weitere oft unvalidierte Quelle von fremdem Input: Server-Header. Auch hier wird bei den meisten Anbietern viel vorgefiltert, doch eben nicht bei allen. Und während das Einfügen von Javascript-Code in den meisten Standard-Headern vermutlich zu sehr unvorhersehbarem Verhalten führen würde, gibt es mindestens einen Header, der offensichtlich noch harmlos genug erscheint, um ihn ungefiltert wieder auszugeben: Der “Server”-Header.

Wer sich ein wenig mit den üblichen Verdächtigen Apache, Nginx und IIS auseinandergesetzt hat, wird sicherlich bemerkt haben, dass das Ändern des Server-Headers nicht ganz trivial ist, was diese Wahrnehmung möglicherweise bestärkt. Und während böswillige Aktoren zwar das Wissen haben mögen, wie man den Quellcode eines Webservers anpasst und ihn neu kompiliert, scheint das doch ein recht sperriger Weg zu sein. Doch es gibt mindestens für den Apache Möglichkeiten, den Server-Header nahezu komplett umzuschreiben – kurioserweise mittels des Standard-Moduls “security2”, also known as “modsecurity”.

So gelingt es in einigen Fällen relativ einfach, JavaScript auf Seiten, die Server-Header anzeigen, im Browser zur Ausführung zu bringen. Abhilfe schafft auch hier nur serverseitige Filterung – oder ein Scriptblocker auf Clientseite, der oft aber auch die Funktionalität der Webseite beeinträchtigt, da der eingeschleuste Inhalt ebenfalls im Kontext der Webseite ausgeführt wird. Ein Scriptblocker kann das fremde Script nicht von den regulär eingebundenen Scripten unterscheiden.

Eingeschränkt sinnvoll: Der User Agent

Eine eher esoterische Möglichkeit, Scripte im Browser zu injizieren, ist die Manipulation des User Agent des verwendeten Browsers. Dies kann relativ simpel über Add-Ons geschehen, führt aber in vielen Fällen dazu, dass Aufrufe von Webseiten fehlschlagen. Schuld ist hier ein vorgelagerter Security-Proxy oder – Kuriosum Nummer zwei – das bereits erwähnte “security2”-Modul im Apache. Diese Maßnahmen erkennen das Script im User Agent und sperren den aufrufenden Browser direkt aus.

Der Nutzen dieser Variante ist hingegen fraglich: Sie muss auf dem lokalen Client eingestellt werden und betrifft damit auch nur diesen. Für Angriffe auf Fremdsysteme ist sie unbrauchbar. Man benötigt also bereits Zugriff auf das anzugreifende System – ein Henne-Ei-Problem. Zum Testen der serverseitigen Validierung und aktiver Sicherheitsmechanismen taugt die Methode jedoch allemal. Vorausgesetzt, dass der Server den User Agent auf einer seiner Seiten auch anzeigt.

Fazit: Vertraue niemandem!

Gelingt es, jemanden dazu zu bringen, eine verwundbare Seite aufzurufen und die präparierte Domäne in das entsprechende Textfeld einzutragen, ist ein erfolgreicher Angriff durchaus wahrscheinlich. Und einem Hilferuf in einem beliebigen Supportforum, die Validierungsseite zeige beim eigenen Server Fehler an, können viele Techies nicht widerstehen. Manche Webservices erlauben sogar das Angeben der zu überprüfenden Domäne über einen URL-Parameter, das manuelle Eingeben der Domain entfällt durch den Klick auf den Link damit komplett. Dass derartige Seiten Fremdcode einbetten vermutet auch in der technisch versierten Community bei weitem nicht jeder. Und da diejenigen, die sich gerne als Helfer in Support-Foren tummeln, oft auch in der technischen Administration in Unternehmen tätig sind, ist der Sprung zu Supply-Chain-Attacken nicht nur theoretisch denkbar.
Selbstverständlich können auf Seiten des potenziellen Opfers Virenscanner und Scriptblocker aktiv sein und den Angriff abfangen, doch dieses Risiko geht ein Angreifer immer ein.

Es zeigt sich jedenfalls wieder, dass generell bei jedem Input, bei jeder Variable, bei jedem Datenbankeintrag, der nicht vom eigenen System(-verbund) kommt, Vorsicht geboten ist. Eine zusätzliche Absicherung der Systeme, beispielsweise mittels Web Application Firewall, Security-Modulen oder vorgelagerten Prüfsystemen, sollte Standard sein. Zusätzliche Sicherheit bietet beispielsweise eine restriktive Content Security Policy (CSP), die das Ausführen von Inline-Scripten und das Nachladen von fremden Domains im Browser komplett unterbindet.

Lesetipps September 2020

Fail Safe

Wunderschöne Liebeserklärung von Bloggerlegende Felix von Leitner (Fefe) an die Programmiersprache Rust im Speziellen und an sichere Programmiersprachen im Allgemeinen.

https://www.heise.de/hintergrund/Entwicklung-Warum-Rust-die-Antwort-auf-miese-Software-und-Programmierfehler-ist-4879795.html


Priceless

Der Privacy-Forscher Lukasz Olejnik rechnet vor, was anderen unsere Datenspuren im WWW wert sind.

https://lukaszolejnik.com/rtbdesc


Spannend

Sherrod DeGrippo von Proofpoint erzählt von den neuesten Entwicklungen in der Ransomware-Industrie. „Fallen zwei oder drei Gangs weg, kommen fünf neue.”

https://www.sueddeutsche.de/wirtschaft/cybersicherheit-fallen-zwei-oder-drei-gangs-weg-kommen-fuenf-neue-1.5024654


It’s always DNS – aber sicher!

Das Tunneln von DNS-Anfragen über TLS (DoT) oder HTTPS (DoH) verspricht Sicherheits- und Datenschutzvorteile, die unser Kollege Michael Sehring hier untersucht:

Securing DNS Traffic: An Introduction to DoT & DoH

In recent times, operating systems including Windows and macOS have been adding support for encrypted DNS. But how do the involved protocols work? And what are their benefits?

To understand them, we first have to look at the Domain Name System (DNS) itself, which is one of the fundamental backbones of the Internet. However, DNS alone does not provide any encryption or authentication, which makes DNS communication vulnerable to eavesdropping and in-transit modifications. Adversaries can use DNS information in cache poisoning attacks to lure victims on phishing websites. On a larger scale, state-level agencies can use pervasive monitoring of DNS for surveillance purposes and therefore attack users’ privacy. Other third parties can use DNS data for Open Source Intelligence (OSINT) purposes, which may harm users’ security altogether.

Timeline of DNS history

Encrypted DNS protocols were first introduced in 2008 when Daniel J. Bernstein proposed DNSCurve. In the following years DNSCrypt followed but both protocols failed to gain noteworthy adoption. In hindsight of the Snowden revelations in 2013, DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) were developed and standardized by the IETF. They aim to secure DNS by adding confidentiality, integrity and server authenticity.

But how do these protocols work? Let’s have a short look at each.

DNS-over-TLS

DoT, described in RFC 7858, is using the well-known Transport Layer Security (TLS) protocol and thus inherits all its security benefits. By default, DoT resolver listen on port 853 for incoming DNS queries that must be encrypted. This non-standard port was chosen to ease the differentiation between DoT and non-DoT connections. However, administrators deploying DoT can choose a different port, provided that both resolver and clients agree. A fallback to cleartext DNS messages within the protocol is not allowed, neither for the client nor the server.

DoT protocol

The protocol, as shown above, consists of two Round-Trip Times (RTT) on first contact. First, the DNS client performs the TCP handshake with the resolver it has chosen to connect to. Next, the DNS client performs the TLS handshake with the server. The client does not necessarily have to authenticate the server as this depends on the used profile. Therefore, self-signed certificates are also acceptable. After the successful completion of the handshake, both parties obtain a session key that is used for subsequent packets. In a third step, the DNS client sends its DNS queries through the established TLS channel. Multiple DNS queries may be pipelined to reduce bandwidth. Messages sent through this TLS channel are hidden from any intermediate party; therefore the DNS queries and answers stay confidential, with any Manipulation detectable.

Privacy Profiles

DoT supports two usage profiles that are defined in RFC 8310 and differ in the privacy they provide. Clients can choose which profile to follow and can thus match their DNS settings to their requirements. Administrators can also force the use of a usage profile.

  • Opportunistic: This profile does not guarantee privacy but tries to achieve as much as possible. Therefore, if connections to servers cannot be authenticated or encrypted they are still acceptable for the client. This profile consciously rates availability as a primary and privacy as a secondary goal and can thus result in insecure connections.
  • Strict: This is a privacy-oriented profile and does not allow establishment of connections to servers that cannot be encrypted or authenticated. It restricts availability but guarantees privacy of DNS messages. A fallback to insecure connections is prohibited.

Use of the strict privacy profile is recommended to establish adequate security in most settings.

DNS-over-HTTPS

DoH, as described in RFC 8484, is the most recent standard for encrypted DNS and uses HTTPS sessions to exchange DNS messages. This enables masking within other HTTPS traffic.
DoH uses URI templates to send DNS requests and can either use GET or POST methods. When using Cloudflare‘s 1.1.1.1 resolver, the requests are structured as followed:

  • The GET request is sent to https://1.1.1.1/dns-query?dns, where the value of the DNS parameter contains the DNS message encoded in base64url.
  • The POST request is sent to https://1.1.1.1/dns-query within the message body. In addition, the header application/dns-message is specified.

It is interesting to note that the RFC does not specifiy the path dns-query. However, lists of public resolvers show that resolvers generally follow this format. Web browsers are able to conduct the requests on their own as they ship with an HTTP engine. An example GET request that recursively resolves the domain name www.hisolutions.com is shown below:

https://1.1.1.1/dns-query?dns=AAABAAABAAAAAAAAA3d3dwtoaXNvbHV0aW9ucwNjb20AAAEAAQ

The answer includes the corresponding IPv4 address of the resolved domain. For more information about the structure of DNS messages, refer to RFC 1035.

DoH protocol

Overall, the DoH protocol works similar to DoT. Their protocol messages include the same content, except for the additional wrapping of DoH messages. However, this wrapping in combination with operating on the same port as common web traffic yields additional privacy benefits that are discussed below.

Discussion

DoH offers the best privacy guarantees of the encrypted DNS protocols. The use of the common port 443 could help prevent censorship of DNS lookups, as third parties observing the traffic are not able to differentiate between regular web and DNS traffic. Therefore, they must block access to the full website to block DNS lookups. A blacklist only works partially as it can only block the access to well-known DoH resolvers. Another point includes the additional masquerading of DNS messages through the use of HTTP. This decreases the likelihood of successful fingerprinting through observing third parties. On the other side, DoT does not interfere with common web traffic by operating on a dedicated port. This enables adversaries to simply drop traffic on that port, such that clients must switch to an (insecure) alternative. However, in managed environments this may be done on purpose, e.g. to force the use of predefined resolvers.

Both protocols add a performance overhead compared to traditional DNS. Although researchers found higher response times for individual DoT/DoH queries, page load times performed similar to traditional DNS given stable network connections. When network conditions degraded, traditional DNS significantly outperformed DoT/DoH. However, this is critique on a high level and the elevated response time is rarely noticeable on the user side.

Usability of both protocols has increased over time, and further adoptions are already planned. As of now, DoT/DoH is already available in Firefox, Chrome and Opera, and therefore supported in the most common web browsers. When it comes to operating systems, both Windows and macOS have added DoH to their pre-release channels and are planning to release it anytime soon. On mobile, Android has been supporting DoT since Android 9. Overall, users are mostly able to enable encrypted DNS on their devices.

We performed some measurements on the Internet and found that, while the number of users of DoH has increased significantly over time, the number of DoH resolvers has not. This highlights a consolidation in the DNS resolver market, which can be problematic in case of untrustworthy resolvers. Even for trustworthy ones, it introduces a single point of failure that other systems rely on, as a recent Cloudflare outage showed. Therefore, the defined secondary resolver should not be of the same provider as the primary one. When using open resolvers we recommend the use of resolvers that have clear privacy directives, prove successful third party audits and have a clean compliance history.

In the future, other encrypted DNS protocols such as DNS-over-QUIC (DoQ) may be used as well. They will probably increase in adoption once HTTP/3 starts rolling out, but DoQ does not include additional privacy benefits as long as most web traffic is still conducted over HTTPS.

Stille Post von hinten durch die Brust: Daten-Extraktion via DNS-over-HTTPS

DNS war lange ein beliebtes bzw. gefürchtetes Mittel, um Daten aus sicheren Unternehmensnetzen hinauszuexfiltrieren. Man hat dies heute halbwegs unter Kontrolle, indem Techniken wie Sinkholing und Filterung eingesetzt werden – theoretisch, denn in der Praxis hinken viele Unternehmen hier noch hinterher. Doch die Behebung eines anderen Problems von DNS – fehlende Verschlüsselung – bringt nun die alten Gespenster wieder zurück. Zwar kann durch Techniken wie DNS-over-HTTPS (DoH) die Namensauflösung gesichert bei einem der großen Anbieter geschehen – doch wenn diese dann wieder per DNS bei einem vom Angreifer kontrollierten DNS-Server anfragen, hat der Angreifer nicht nur den Exfiltrationskanal wieder geöffnet, sondern er hat auch noch die perfekte Tarnung dafür. Denn welche Firewall oder welche DLP-Lösung würde schon Böses hinter DNS-Verbindungen zu Google oder Cloudflare vermuten? 
https://sensepost.com/blog/2018/waiting-for-godoh/