Microsoft: Parkhaussteuerung in Redmond ungeschützt per Internet erreichbar

[English]Noch ein Sicherheitssplitter zum Wochenende: Microsofts Parkhäuser in Redmond (USA) haben ein Problem. Deren Parkhaussteuerung samt Servern sind wohl ungeschützt per Internet erreichbar.


Anzeige

Tim Philipp Schäfers, Gründer des Portals Internetwache.org ist mal wieder einer Schwachstelle auf die Spur gekommen. Schäfers nimmt sich immer mal wieder Parkhäuser vor, um deren IT auf Schwachstellen abzuklopfen. Vor einigen Jahren hatte er herausgefunden, dass die Steuerungssoftware für Parkhäuser von manchen Firmen nicht ausreichend abgesichert wurde. Er hatte einen Fall aus der Schweiz 2016 bei Golem in diesem Artikel öffentlich gemacht. Sogar Parkhausschranken an den Ein-/Ausfahrten hätten sich manipulieren lassen.

Auch Du Microsoft!

Naiv, wie ich nun mal bin, hätte ich gesagt: Bei Microsoft ist alles sicher, bombensicher. Aber weit gefehlt, denn Tim Philipp Schäfers ist im November auf einen neuen Fall gestoßen. Schäfers sucht mit dem Netzwerkscanner Zmap wohl nach Installationen einer Parkhaus-Software, die öffentlich per Internet erreichbar sind. Dabei tauchte plötzlich auch ein Parkplatzübersicht für ein Parkhaus auf, bei der es ein Microsoft-Logo gab. Schnell war klar, dass es sich um die Parkhausverwaltung des Microsoft-Hauptsitzes in Redmond, USA, handelte.

Schäfers konnte ohne einen Schutz, über eine unverschlüsselte Verbindung, auf die Parkhausverwaltungs-Software des Microsoft-Hauptsitzes in Redmond, USA, zugreifen. Über eine Weboberfläche ließ sich eine Karte des Microsoft-Geländes in Redmond mit den dort vorhandenen Parkhäusern abrufen. Die haben einige Parkhäuser auf dem Campus – hier gibt es sogar Fotos. Zur Überraschung von Tim Philipp Schäfers konnte er sich alle Parkhäuser und Parkdecks sowie die Belegung der Parkbuchten ansehen. Das wird über Sensoren gesteuert.

Auch war es möglich, abzufragen, ob ein Parkplatz reserviert und wann er genutzt wurde (wenn auch keine Kennzeichen oder persönliche Daten der Mitarbeiter dort abfragbar sind). Allerdings gab es die Möglichkeit, aufgelaufene Alarme für Sensorfehler ohne weitere Authentifizierung zu quittieren.

Schäfers hat die Informationen an Golem weitergegeben, die das Ganze in einem Artikel veröffentlicht haben. Dort lässt sich nachlesen, dass neben der Parkhaus-Steuerung auch die RDP- und SMB-Ports der betreffenden Server offen im Internet erreichbar waren. Da haben die Admins wohl die Empfehlungen Microsofts nicht gelesen. War das alte Leid: Der Azure-Server wurde von Drittanbietern betrieben, so die Antwort Microsofts auf Hinweise Schäfers.

Und wie das bei Großunternehmen so ist – wer Tickets bei denen absetzt kennt das – das Versprechen 'wir kümmern uns drum' ist dann versandet. Am 28. November wurde das Ganze von Schäfers an das Microsoft Cert (Computer Emergency Response Team) gemeldet. Eine Woche später hieß es: Wir untersuchen es, am 12. Dezember wurde die Meldung geschlossen (das zuständige Team sei über die gemeldeten Probleme informiert). Bug Bounty gab es dafür nicht, und der Fall bzw. die Wartung gehört nicht zum Aufgabenbereich des Teams.

Immerhin verschwand die Weboberfläche des Azure-Servers aus dem Internet, die RDP- und SMB-Ports blieben jedoch immer noch offen. Golem hat kurz vor der Offenlegung des Vorfalls in Form dieses Artikels nochmals einen Scan probiert. Über die gemeldete IP-Adresse war die Parkhaus-Software wieder abrufbar. Golem beschreibt im Artikel die Stellungnahme Microsofts sowie des österreichischen Software-Herstellers Indect. Nach einer weiteren Anfrage verschwand zwar die Parkhaussoftware aus dem Internet, aber die Ports blieben weiter erreichbar. Sieht so aus, als ob der Fall der an Auftragnehmer ausgelagerten Parkhaus-Server in keinen guten Händen ist.


Anzeige


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

3 Antworten zu Microsoft: Parkhaussteuerung in Redmond ungeschützt per Internet erreichbar

  1. Rainer Winkler sagt:

    Gelegentlich taucht bei einem Server eine IP-Adresse aus dem Microsoft-Bereich (APIPA) auf, und das sogar dann, wenn die IP-Adressen aller angeschlossenen Interfaces von Installationsbeginn fest vergeben sind.

    Beispiel: die ominöse IP-Adresse 169.254.71.100 geistert bei einem Kunden herum, und ich finde keine Ursache. Ein ping auf diese Adresse vom Server aus funktioniert natürlich; aber ein arp -a zeigt diese Adresse nicht an. ipconfig zeigt sie auch nicht, genausowenig wie der Status der Schnittstellen über die GUI. Es handelt sich in diesem Fall sogar um einen HP-Server, dem die richtige IP-Adresse bereits vorm Installieren des Betriebssystems zugeordnet wurde!

    Das Problem ließ sich nicht ohne Weiteres lösen. Der DHCP-Bereich war einem nicht angeschlossenen Interface zugeordnet. Wird dieses deaktiviert, dann funktioniert der DHCP-Server überhaupt nicht mehr! Umbenennen des Bereiches geht auch nicht. Einen neuen Server mit dem korrekten Namen kann man auch nicht anlegen, den alten aber auch nicht einfach löschen. Nach einigen Abstürzen der DHCP-Verwaltungskonsole war es aber dann doch möglich, einen neuen korrekten DHCP-Server zu installieren. Ohne weiteres Zutun hatte dieser die alten Einstellungen korrekt übernommen.

    Nun hätte man die falsche Konfiguration auch stehen lassen können. Aber sobald eins der beiden freien Interfaces benötigt oder auch nur angeschlossen wird, ist guter Rat teuer!

    Offensichtlich wurde die DHCP-Abfrage im Server weitergeleitet („geroutet").

  2. Hans sagt:

    169.254.xx.xx – ist ein DHCP Problem. Der Client versucht eine IP zu bekommen aber bekommt sie halt nicht.

Schreibe einen Kommentar zu ralf Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.