Interne IP-Adressen und Hostnamen offengelegt

Ein Angreifer, der hereinkommt, weiß nicht, wie Ihr Netz aussieht. Das zu erfassen kostet Zeit und erzeugt Verkehr, der auffallen kann. Interne Adressen, die Ihre Anwendung selbst preisgibt, ersparen ihm diesen Schritt. Im Folgenden lesen Sie, über welche Wege das geschieht und warum es vor allem im Zusammenspiel mit anderen Schwachstellen zählt.

Was gelangt dabei nach außen?

Von offengelegten internen Adressen spricht man, wenn eine Anwendung Adressen oder Namen preisgibt, die nur innerhalb Ihres eigenen Netzes Bedeutung haben. Es geht um private IP-Adressen aus den reservierten Bereichen, um Servernamen und um interne Domainnamen, die nicht öffentlich sind.

Diese Angaben sind nicht in dem Sinne geheim, dass sich damit etwas öffnen ließe: Ein Angreifer im Internet kann eine private Adresse nicht erreichen. Was sie preisgeben, ist Struktur: wie viele Server es gibt, wie sie heißen, wie die Nummerierung aufgebaut ist, welche Rollen bestehen. Ein Name wie db-prod-02.intern.firma.de sagt in einer Zeile, dass es eine Produktionsdatenbank gibt, dass vermutlich eine db-prod-01 besteht und dass die interne Domain intern.firma.de heißt.

Es ist ein Grundriss, der aus einem Gebäude nach draußen weht. Ein Schlüssel liegt nicht bei, und dennoch ist er für denjenigen wertvoll, der vorhat hineinzugehen.

Woher stammen diese internen Adressen?

Verwundbar:

HTTP/1.1 500 Internal Server Error
X-Backend-Server: app-node-03.intern.firma.de
Via: 1.1 proxy-dmz-01 (squid/5.2)

Verbindung zu 10.0.4.12:5432 (datenbank-prod-02) nicht möglich

Drei Zeilen, drei Lecks. Der Header verrät den Namen des Anwendungsservers und die interne Domain. Der Proxy-Header nennt ein System in der demilitarisierten Zone. Und die Fehlermeldung gibt die IP-Adresse, den Port und den Namen des Datenbankservers preis.

Andere Stellen sind weniger auffällig, aber ebenso ergiebig. Eine Weiterleitung, die die interne Adresse statt der öffentlichen enthält. Ein HTML-Kommentar mit einem Verweis auf einen Testserver. Ein E-Mail-Header, der den vollständigen internen Weg zeigt. Ein Location-Header, der nach einem falsch konfigurierten Proxy die Adresse des dahinterliegenden Servers trägt.

Sicher:

# Der Proxy bereinigt, was der dahinterliegende Server hinzufügt
proxy_hide_header X-Backend-Server;
proxy_hide_header X-Powered-By;
proxy_hide_header Via;

# Weiterleitungen auf die öffentliche Adresse umschreiben
proxy_redirect http://app-node-03.intern.firma.de/ https://portal.example/;

// Und Fehlermeldungen enthalten nie Adressen
app.use((fehler, req, res, next) => {
  const referenz = randomUUID();
  logger.error({ referenz, nachricht: fehler.message, stack: fehler.stack });
  res.status(500).json({ fehler: 'Es ist etwas schiefgegangen', referenz });
});

Der Proxy ist hier die richtige Stelle, denn dort bereinigen Sie in einem Zug, was jeder dahinterliegende Dienst hinzufügt, auch Dienste, deren Konfiguration Sie nicht in der Hand haben. Die Fehlerbehandlung sorgt dafür, dass nie eine Adresse in der Antwort landet; die Einzelheiten stehen in Ihrer Protokolldatei, verknüpft mit einer Vorgangsnummer.

Welche Auswirkungen haben offengelegte interne Adressen?

Der Schweregrad ist niedrig, und das bleibt in praktisch jeder Lage so. Durch diese Angaben wird kein Angriff möglich; es wird kein Zugang erlangt, und es gelangen keine Nutzerdaten nach außen.

Der Wert liegt in der Erkundung. Ein Angreifer, der auf anderem Weg hereingekommen ist, über ein kompromittiertes Konto, einen Arbeitsplatzrechner, eine Schwachstelle in einem anderen Dienst, muss herausfinden, wo er ist und was zu erreichen ist. Dieses Herausfinden kostet Zeit und erzeugt Netzwerkverkehr, den Erkennungssysteme bemerken können. Kennt er die Adressen bereits, kann er gezielt vorgehen und bleibt länger unbemerkt.

Es gibt eine zweite Überlegung. Die Stellen, an denen interne Adressen nach außen gelangen, sind fast immer dieselben Stellen, an denen auch andere Informationen abfließen: ausführliche Fehlermeldungen, nicht bereinigte Header, stehen gebliebene Kommentare. Das Aufräumen erfasst deshalb meist mehr als nur diesen Befund.

Wie spürt man offengelegte interne Adressen auf?

Ein Tester durchsucht sämtliche Antworten nach Mustern, die auf private Adressen hindeuten, und nach Hostnamen mit einer intern wirkenden Domain. Das geschieht nicht nur auf den gewöhnlichen Seiten, sondern gerade dort, wo etwas schiefgeht: auf Fehlerseiten, bei Weiterleitungen, bei Antworten auf fehlerhaft aufgebaute Anfragen und bei vorübergehenden Störungen.

Zusätzlich werden die Header verschiedener Arten von Antworten verglichen, denn eine statische Datei und eine API-Antwort werden von unterschiedlichen Komponenten verarbeitet und tragen daher unterschiedliche Header. Auch HTML-Kommentare erhalten Aufmerksamkeit, ebenso JavaScript-Dateien mit hinterlegten Adressen und die Header der E-Mails, die die Anwendung versendet. Ferner werden Dateien betrachtet, die aus einer internen Umgebung veröffentlicht wurden, denn darin können Pfade zu Netzwerkorten stehen. AssistSec fügt diese Befunde zu einem Bild Ihrer inneren Struktur zusammen, genau wie ein Angreifer es täte, und dieses Bild macht oft deutlicher als die einzelnen Zeilen, warum sich das Aufräumen lohnt.

Wie verhindert man offengelegte interne Adressen?

• Bereinigen Sie Header an Ihrem Reverse Proxy, damit dahinterliegende Dienste ihre Namen nicht mitsenden.
• Schreiben Sie Weiterleitungen auf die öffentliche Adresse um, statt die interne durchzureichen.
• Nehmen Sie nie Adressen oder Servernamen in Fehlermeldungen auf, die der Nutzer zu sehen bekommt.
• Entfernen Sie HTML-Kommentare und hinterlegte interne Adressen aus Ihren Frontend-Dateien.
• Lassen Sie Ihren ausgehenden Mailserver die internen Weiterleitungszeilen aus E-Mail-Headern entfernen.
• Prüfen Sie, ob Location-Header nach einem Proxy die öffentliche Adresse enthalten.
• Verwenden Sie neutrale Servernamen, die weder Rolle noch Nummerierung verraten.
• Nehmen Sie diese Prüfung in Ihren Abnahmeprozess auf, denn solche Lecks entstehen meist bei einer Konfigurationsänderung.