Hey, das ist nicht mein Server!

Wir werden oft von Kunden und Forschern angesprochen, die sich fragen, warum vertrauenswürdige, legitime Zertifikate plötzlich auf Hosts in einem weit entfernten Land angezeigt werden. Fast jeder Fall, den wir untersucht haben, war darauf zurückzuführen, dass die großen CDN-Anbieter (Content Delivery Network) wie Cloudflare und Akamai bei der Bearbeitung von SNI-Anfragen ( Server Name Indication ) mit Nullwerten nicht vorsätzlich vorgingen.

Wenn Sie"https://example.com" anfordern, leitet Ihr Client, in der Regel ein Webbrowser, einen TLS-Handshake ein. Im Rahmen dieses Vorgangs teilt der Client dem entfernten Server den Hostnamen mit, mit dem er sich verbinden möchte(example.com). Dieser Schritt ermöglicht es dem Server, den angeforderten Hostnamen dem entsprechenden SSL-Zertifikat zuzuordnen, bevor eine sichere Verbindung hergestellt wird.

Ein gut implementierter Server würde in der Regel ein Dummy-/Standardzertifikat zurückgeben, wenn die SNI-Anfrage null ist. Viele Implementierungen liefern jedoch stattdessen ein gültiges Zertifikat für andere (legitime) Domänen, die zufällig mit der Nullabfrage übereinstimmen.

Warum ist das so?

Wenn ein Zertifikat auf einem Host außerhalb der erwarteten Bereiche zu sehen ist, ist dies ein deutlicher Hinweis darauf, dass der Host als Proxy fungiert und auf einen CDN-Bereich oder einen legitimen Server umleitet.

Da TLS-Zertifikate auf Domänenebene ausgestellt werden und nicht an bestimmte IP-Adressen gebunden sind, kann ein Administrator einen Proxy so konfigurieren, dass er den Datenverkehr zwischen dem Client und dem legitimen TLS-Dienst transparent weiterleitet. Solange der Client die korrekte SNI angibt, kann der Proxy die Daten unverändert weiterleiten, so dass die Integrität des TLS-Handshakes gewahrt bleibt. Dadurch ist der Proxy nicht von dem legitimen TLS-Server zu unterscheiden.

In den folgenden beiden Screenshots sehen wir zum Beispiel links einen Host in Russland, auf dem der Sliver C2 Multiplayer Server auf Port 31337 läuft, was an sich schon verdächtig ist, aber wenn wir rechts zu Port 443 scrollen, sehen wir einen HTTP(s)-Dienst, der ein legitimes (und vertrauenswürdiges) Zertifikat für microsoft.com ausführt.

Das Zertifikat ist echt, aber der Host, der dieses Zertifikat präsentiert, gehört definitiv nicht zu Microsoft. Es handelt sich lediglich um einen Trick - einen Proxy-Server zu einem von mehreren Akamai-Hosts, der das Microsoft.com TLS-Zertifikat ausgibt, wenn ein Client keine SNI angibt. In diesem Fall ist es möglich, dass der Akteur den Port 443 so eingerichtet hat, dass er an Microsoft weitergeleitet wird, um den Host bei einer schnellen Überprüfung als legitim erscheinen zu lassen.

Sie können dies selbst ausprobieren, indem Sie nach IP-Adressen suchen, die gültige TLS-Zertifikate bereitstellen, ohne eine SNI zu verlangen. Akamai und CloudFlare sind gute Ausgangspunkte, da sie einen großen Teil des HTTPS-Verkehrs im Internet abwickeln und oft nicht mit Dummy-Zertifikaten reagieren. Sobald Sie einen Server mit einem TLS-Zertifikat gefunden haben, das Sie replizieren möchten, können Sie ein Tool wie socat wie folgt verwenden:

Dadurch wird eine Verbindung zwischen dem lokalen Port 443 und dem Port 443 auf dem Remoteserver hergestellt. Jetzt sieht Ihr Server so aus, als wäre er für das TLS-Zertifikat, das von der bloßen IP-Adresse des Remoteservers ausgestellt wurde, autorisiert. Unten habe ich bereits einen Tunnel zwischen localhost und 184.24.14.218 eingerichtet, der gerade ein Zertifikat für "intel.com" ausgibt. Wir haben dann ein curl gegen localhost ausgeführt, wobei die Domäne intel.com als SNI festgelegt wurde. Beachten Sie, dass es bei dieser Anfrage keine Zertifikatswarnungen gab.

Aber ist das schlecht? Das ist schwer zu sagen. Sie können die zwischen dem Client und dem Proxy-Server übertragenen Daten nicht einsehen oder manipulieren, aber man könnte dies nutzen, um für einen Außenstehenden "legitimer" zu wirken. In Wirklichkeit kann es sich dabei um alles Mögliche handeln, von einem böswilligen Akteur, der versucht, legitim zu wirken, bis hin zu einer seltsamen Routing-/Proxy-Konfiguration. Es geht darum, zu wissen, wie TLS funktioniert, wenn Zertifikate an unbekannten Orten auftauchen, damit man sich nicht in zu viele Kaninchenlöcher begibt.

Für eine schnelle Analyse haben wir uns jedes Zertifikat angesehen, das auf bloßen IP-Adressen innerhalb von AS16625 (AKAMAI-AS), einem der autonomen Systeme von Akamai, entdeckt wurde. Anschließend haben wir nach diesen Zertifikatsduplikaten in Nicht-Akamai-Netzwerken gesucht, und zwar an anderen Ports als denen, die von Akamai verwendet werden. Wenn zum Beispiel ein Zertifikat auf dem Akamai-Port 443 gefunden wurde, aber auf dem Port 4444 eines Nicht-Akamai-Hosts erschien, wurde es gezählt. Außerdem wurden nur Nicht-Akamai-Hosts berücksichtigt, die das passende Zertifikat auslieferten und gleichzeitig den Server-Header "Akamai Ghost" zurückgaben.

Mit diesen Regeln haben wir knapp 7.000 verschiedene Hosts im Internet gefunden, die 1:1-Proxys zu verschiedenen Akamai-Hosts durchführen, die legitime TLS-Zertifikate auf der bloßen IP ausliefern.

Censys Perspektive

Wenn legitime Zertifikate auf unerwarteten Remote-Systemen angezeigt werden, ist dies zwar ein Grund zur Untersuchung, aber nicht immer ein Hinweis auf bösartige Aktivitäten. Mit Tausenden von Hosts, die als Proxys fungieren und von Scannern mit legitimen TLS-Zertifikaten erkannt werden, ist dieses Verhalten eine der einzigartigen Eigenheiten des Internets. Während einige dieser Proxys wahrscheinlich absichtlich eingesetzt wurden, um einen Malware-Kontrollserver als legitimes Drittanbietersystem zu tarnen, sind andere wahrscheinlich das Ergebnis von nicht gewarteten Proxys, die auf IP-Adressen umleiten, die den Besitzer gewechselt haben.