zurück zum Artikel

Fehlkonfigurierte Webserver von Bundesbehörden und IT-Firmen präsentierten Besucher-IPs, Benutzernamen, Meeting-Kennungen und mehr offen im Internet.

Um Server zu debuggen und zu überwachen, ist es nützlich, Konfigurations- und Statusinformationen einfach abrufen zu können. Das geht leicht schief, wie weit verbreitete Konfigurationsfehler belegen. Der bekannte Webserver Apache bietet unter anderem die Module mod_info und mod_status an. Beide stellen HTML-Seiten bereit, die allerlei Daten über den Server anzeigen und standardmäßig unter den Pfaden /server-info und /server-status zu erreichen sind.

Seit Jahren kommt es immer wieder zu Fällen, in denen Server falsch konfiguriert sind und die Seiten dieser Module unabsichtlich veröffentlicht werden. Das ist aber kein lässliches Kavaliersdelikt, das nur dröge Verwaltungsdaten betrifft. Konkrete Nachforschungen fördern oft sensible Information zutage, etwa Links, die unberechtigte Downloads erlauben, oder Kennungen, die Zugang zu internen Meetings verschaffen.

Weitverbreiteter Fehler

Das IT-Sicherheitsunternehmen "Deutsche Gesellschaft für Cybersicherheit" wollte sich ein Bild der Lage verschaffen und hat alle .de-Domains systematisch gescannt. Das Ergebnis war verheerend. Die Fachleute fanden mehr als 70.000 Domains, die Informationen von mod_info oder mod_status veröffentlichten. Um der Problematik mehr Aufmerksamkeit zu verschaffen, wandten sie sich an c’t.

Die Liste enthält Systeme verschiedenster Betreiber. Stichproben fanden alles – von privaten Homepages über kommunale Webseiten bis zu Servern großer Organisationen: Banken, IT-Firmen wie AVM oder G Data, das Bundesfinanzministerium und sogar CERT-Bund, das "Computer-Notfallteam des BSI", finden sich in der Liste.

Ursachenforschung

Dass die Fehlkonfigurationen so verbreitet sind, ist auf den ersten Blick verwunderlich. Die Apache-Dokumentation warnt davor [1], dass die beiden Module sicherheitsrelevante Auswirkungen haben können, und gibt auch Beispiele, die Zugriffe auf diese Module einschränken. Für das Server-Status-Modul sieht das etwa so aus:

<Location "/server-status">
    SetHandler server-status
    Require local
</Location>

Die Direktive Require local erzwingt, dass nur Anfragen, die vom Server selbst kommen, beantwortet werden. Allerdings ergeben sich unter Umständen zwei Folgeprobleme, die viele Admins offenbar nicht im Auge haben: Zum einen befinden sich Webserver häufig hinter einem Loadbalancer oder einem anderen vorgeschalteten System, das oft auf der gleichen Maschine läuft. Aus Sicht des Webservers kommen dann aber alle Anfragen von der eigenen Maschine und entsprechend bekommt auch jedermann Zugriff auf die Status- und Infoseiten.

Das andere Problem ist, dass sich Apache-Server ihre Konfiguration aus verschiedenen Quellen zusammensammeln, die einander kompliziert überlagern und ergänzen können. Eine Require-Anweisung an einer Stelle wird dadurch leicht mit einer anderen, die mehr Zugriff erlaubt, kombiniert und der Schutz wirkungslos.

Mehr Infos

c’t 26/2020

Dieser Artikel stammt aus c’t 26/2020 [2]. Darin hat die Redaktion den Bausatz für das c’t-Notfall-Windows aktualisiert, mit dem Sie einen bootfähigen USB-Stick erzeugen können, um Daten zu retten, Viren zu jagen oder Bootprobleme zu lösen. Außerdem gibt es einen Test aktueller High-End-Smartphones, spannender Fitness-Tracker und Streaming-Sticks zum nach- und aufrüsten von TV-Funktionen. Dazu gibt es weitere Tests, jede Menge Praxis und eine ganze Ladung voller Tipps zur Heimnetz-Verkabelung. c't 26/2020 ist ab sofort im Heise-Shop [3] und am gut sortierten Zeitschriftenkiosk erhältlich.

Auswirkungen

Beabsichtigt war die Konfiguration in keinem von c’t untersuchten Fall; nach der Kontaktaufnahme unsererseits haben alle hier genannten Organisationen ihre Serverkonfiguration schnell angepasst. Wie schwerwiegend die Auswirkungen solcher Fehlkonfigurationen sind, ist allerdings von Fall zu Fall ganz unterschiedlich und hängt davon ab, welche anderen Probleme ein Server mit sich herumträgt. Die von mod_info exponierte Seite listet beispielsweise die Versionen des genutzten Apache-Servers sowie eingesetzter Module und SSL-Bibliotheken auf. Das ist fatal, wenn es sich um alte Versionen mit bekannten Sicherheitslücken handelt.

Beim CERT-Bund – das mod_info, aber nicht mod_status exponiert hatte – war das nicht der Fall. Aber die Infoseite enthält trotzdem zahlreiche Informationen, die man potenziellen Angreifern nicht liefern möchte. c’t konnte so zum Beispiel nachvollziehen, wie mod_info den Zugriffsbeschränkungen beim CERT-Bund entgangen war.

Veröffentlichte IP-Adressen

Schlimmer sind häufig die Auswirkungen von mod_status. Das Modul zeigt zwar weniger Konfigurationsdetails an, veröffentlicht standardmäßig aber aktuelle Requests. Die Requests geben zum einen Aufschluss über IP-Adressen, die einen Server kontaktieren. Dabei handelt es sich üblicherweise um personenbezogene Daten, die nicht ohne Weiteres veröffentlicht werden dürfen.

Ironischerweise helfen hier Systeme wie Loadbalancer, obwohl sie, wie gesagt, die Lücke oft überhaupt erst aufreißen: Bei Requests, die durch so ein System gehen, sieht der Apache-Server nur die feste IP-Adresse dieses Systems und nicht die Adressen der Besucher. Etwa bei einem Server des Bundesfinanzministeriums verhinderte ein so vorgeschalteter Cache, dass Besucheradressen öffentlich wurden.

[4]

Vertrauliche URLs

Neben den IP-Adressen zeigt die Request-Liste der Statusseite auch die genutzten URLs an. Es ist keine gute Praxis, aber oft enthalten URLs sensible Informationen, welche die Server-Status-Seite dann publiziert.

Größeren Problemen gerade noch entgangen ist die Sparda-Bank München. Deren System publizierte URLs mit Teilen von IBANs. Dabei handelte es sich allerdings nur um die vordere Hälfte der Nummern, womit sich Land und Bank identifizieren lassen, aber keine Konten.

Schlechter sah es bei der IT-Security-Firma G Data aus. Der betroffene Server wurde zum Dateiaustausch im Unternehmen genutzt und publizierte über die URLs unter anderem Benutzernamen von Firmenmitarbeitern. Die entsprachen oft den Klarnamen der Mitarbeiter nach dem Schema "Vorname.Nachname" und erlaubten so zumindest Rückschlüsse auf Unternehmenszugehörigkeiten. Außerdem fanden sich in den URLs Datei-Hashes. Darüber war es sogar möglich, die jeweiligen Dateien unbefugt herunterzuladen. G Data betont allerdings, dass diese Dateien keine personenbezogenen Daten enthielten. Personenbezogene Daten würden grundsätzlich nur in Dateien mit einem Passwortschutz geteilt.

Problematisch war auch ein System des Fritzbox-Herstellers AVM. Es exponierte den Server-Status eines Jitsi-Servers für Videokonferenzen zwischen Mitarbeitern. Die Namen der virtuellen Konferenzräume waren dadurch frei zugänglich und jedermann konnte an Konferenzen teilnehmen, die nicht individuell passwortgeschützt waren. Gerade in größeren Konferenzen kann es leicht passieren, dass solche unerbetenen Gäste nicht weiter auffallen und dem internen Meeting ungestört beiwohnen können.

Serverkonfiguration prüfen

AVM, G Data und das BSI zeigen, dass niemand gegen Unachtsamkeit gefeit ist. Zehntausende weitere Systeme sind noch betroffen und die Experten der Gesellschaft für Cybersicherheit wollen bald mit einer aktualisierten Liste an die Öffentlichkeit gehen. Zeit also, sich die Konfigurationen der eigenen Server sorgfältig anzusehen und nicht nur schnell die Pfade /server-info und /server-status zu testen. Es lassen sich auch andere Pfade nutzen und es gibt ähnliche Probleme mit anderen Statusseiten: Der Hoster von CERT-Bund schaffte es offenbar, den öffentlichen Zugang zu /server-info abzudrehen und dabei zu übersehen, dass auf die gleiche Weise auch Statusinformationen eines Perl-Interpreters unter /perl-status publiziert wurden. Nach einem weiteren Hinweis von c’t wurde auch dieses Verhalten korrigiert.

(syt [14])

URL dieses Artikels:
https://www.heise.de/-4971830

Links in diesem Artikel:
[1] https://httpd.apache.org/docs/2.4/mod/mod_info.html#security
[2] https://www.heise.de/select/ct/2020/26
[3] https://shop.heise.de/c-t-26-2020
[4] https://www.heise.de/ct
[5] https://httpd.apache.org/docs/2.4/mod/mod_info.html
[6] https://httpd.apache.org/docs/2.4/mod/mod_status.html
[7] https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#require
[8] https://httpd.apache.org/docs/2.4/sections.html#merging
[9] https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#authmerging
[10] https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#authmerging
[11] https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#authmerging
[12] https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#authmerging
[13] https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html
[14] mailto:syt@ct.de

Copyright © 2020 Heise Medien