Schwachstelle öffnet Türen in mehr als 3.000 Hotels

Es mag bequem klingen: Die Zimmertür im Hotel lässt sich ganz ohne Schlüssel oder Karte vom Smartphone aus entriegeln. Doch was passiert, wenn die Logik eines solchen Systems nicht ausreichend abgesichert ist?

Zimmertüren von Hotels aus über 25 Ländern ließen sich mit einer neu entdeckten Schwachstelle öffnen. Bequem? Ja, über das Internet und ohne Zugangsdaten. Dazu konnten sämtliche Reservierungsinformationen (u. a. Name, E-Mail, Reservierungszeitraum und Raumnummer) eingesehen werden. Doch wie kam es dazu?

Zusammenfassung

Die Firma straiv ist ein innovativer und digitaler Begleiter für Hotelbranchen. Als solcher bieten sie unter anderem Online-Check-ins und digitale Türöffnungen an. Was den Sicherheitsforschern Björn Brauer, Deniz Adrian und David Mathiszik bei einem Hotelbesuch jedoch auffiel: Angreifenden wäre es dank einer fehlerhaften Zugangskontrolle in der API möglich, den Check-in und das Öffnen von Türen auch ohne Autorisierung über das Internet zu bedienen.

Im Rahmen einer vertraulichen Offenlegung (engl. Responsible Disclosure oder auch Coordinated Vulnerability Disclosure – CVD) wurden die technischen Details daraufhin direkt an den Hersteller übermittelt. straiv reagierte zeitnah und behob die Sicherheitslücke in ihrer Anwendung umgehend.


Dank ihres Software-as-a-Service-Ansatzes konnte das Unternehmen das Sicherheitsrisiko zeitgleich für alle Kunden mitigieren. Es wird daher auch keine CVE-ID für diese Schwachstelle vergeben. Die Veröffentlichung der Schwachstelle erfolgt in Abstimmung mit dem Hersteller frühestens einen Monat nach der erfolgreichen Behebung.

Die Ursache: Broken Access Control

Broken Access Control belegt aktuell Platz 1 unter den beliebtesten (lies: häufigsten) Schwachstellen in Webanwendungen (siehe: A01:2021 – OWASP Top 10). Auch hier war eine fehlerhafte Zugriffskontrolle die Ursache.

Für gewöhnlich erhalten Gäste eine E-Mail mit einem Link zu ihrer Reservierung. Über diesen werden sie auf die Webanwendung von straiv weitergeleitet. Dort können Buchungsinformationen, die Reisedaten und alle Begleiterprofile eingesehen werden. Ein weiterer Menüreiter führt zu den digitalen Zimmerschlüsseln. Darüber kann die Zimmertür während des eigenen Buchungszeitraums gesteuert werden. Dies geschieht über die API von straiv.io.

Normale API-Anfragen schienen mindestens durch einen HTTP-Header (X-Token), einen Code (cryptcode) und die Reservierungsnummer (reservation) geschützt zu werden. Wurde auch nur einer der Werte verändert, so wurde der Zugriff erwartungsgemäß verwehrt. Fehlten jedoch alle Werte gleichzeitig, wurde nur noch die Reservierungsnummer interpretiert.

In der folgenden beispielhaften Anfrage wurden sämtliche Authentifizierungsparameter, bis auf die Reservierungsnummer, leer gelassen und die API antwortete dennoch mit Informationen zur Reservierung.

POST /api/v2/auth HTTP/2
Host: start.straiv.io
X-Token:
X-Code:
X-Version: 12.3.0
Content-Type: application/json
{
    "cryptcode":"",
    "platform":"linux",
    "browser":"Firefox",
    "version":"115.0",
    "tokens":[],
    "reservation":"3XXXXX"
}

Das Ergebnis enthielt neben anderen Informationen auch einen validen token, der für weitere API-Anfragen genutzt werden konnte.

So lieferte der folgende API-Aufruf noch mehr Kundendetails:

GET /api/v2/vblo/pms/reservation?reservation_id= HTTP/2
Host: start.straiv.io
Accept: application/json, text/plain, */
X-Token: sXXXXXXXXXXXXXXXXXXXh
X-Code: XXXX
X-Version: 12.3.0

Statt die API zu verwenden, kann auch die remote_url aus der Antwort der ersten API-Anfrage verwendet werden, um bequem über die Webanwendung auf die Reservierung zuzugreifen:

HiSolutions hat keine Enumeration von Nutzerdaten durchgeführt und über das Abschätzen der Auswirkungen dieser Schwachstelle hinaus nicht mit der API oder den Buchungen interagiert. Prinzipiell standen alle Funktionalitäten des legitimen Benutzers uneingeschränkt zur Verfügung.

Mitigation

Für die Kunden von straiv bestand kein weiterer Handlungsbedarf. Die Sicherheitslücke wurde von den Entwicklern ernst genommen und umgehend geschlossen.

Grundsätzlich lassen sich Fehler dieser Art durch folgende allgemeine Empfehlungen verhindern:

  • Vertrauen Sie keinen Nutzereingaben – validieren Sie diese.
    Verlassen Sie sich nie auf die Gültigkeit von jeglichen Werten, die von den Endbenutzern beeinflusst werden können. Dazu gehören auch Cookie-Werte, Anfragenparameter und HTTP-Header. Auch auf serverseitig gespeicherte Informationen sollte nich blind in allen Kontexten vertraut werden.
  • Überprüfen Sie Gültigkeit aller Werte serverseitig. Weisen Sie leere oder ungültige Authentifizierungsinformationen zurück. Achten Sie bei der Implementierung von Tests auf eine vollständige Abdeckung aller Randszenarien (ein, mehrere oder auch alle Werte sind unerwartet, NULL, nicht definiert, vom falschen Typ, etc.).
  • Verwenden Sie starke Authentifizierungsmethoden.
    Implementationen sind stets abhängig von der Anwendung und dem Kontext. Greifen Sie, wenn möglich, auf bewährte und praxiserprobte Bibliotheken und Authentifizierungslösungen zurück. Verwenden Sie besonders in Bezug auf sensitive Informationen Zwei-Faktor-Authentifizierung. Stellen Sie zudem sicher, dass alle automatisch generierten Schlüssel, Codes und Token nicht leicht zu erraten und somit vor Brute-Force-Angriffen geschützt sind (vgl. UUID v4).
  • Durchsatzbegrenzung (engl. Rate Limiting) der API-Anfragen:
    Begrenzen Sie die mögliche Anzahl der Anfragen von einzelnen Systemen, um dem Missbrauch, wie der schnellen Enumeration von gültigen Reservierungen, vorzubeugen.

In ihrem Update hat straiv mindestens eine Anfragenbegrenzung aktiviert und Reservierungsnummern auf ein nicht-erratbares Format geändert.

Wie HiSolutions helfen kann

HiSolutions bietet spezialisierte Penetrationstests für Webanwendungen und Infrastrukturen an. Hierbei greifen wir auf langjährige Erfahrung zurück und kombinieren die Fähigkeiten modernster Scantechnologien mit manuellen Prüfverfahren, um die bestmögliche Testabdeckung zu gewährleisten.

Stellen Sie sicher, dass Schwachstellen gefunden und behoben werden, bevor Sie ausgenutzt werden können und kontaktieren Sie uns unter +49 30 533 289 0 oder dem Kontakformular für ein kostenloses Erstgespräch.

Koordinierte Veröffentlichung

  • 22.05.2024 HiSolutions sammelt Details zur Schwachstelle.
    Finder: Björn Brauer, Deniz Adrian & David Mathiszik
  • 23.05.2024 HiSolutions informiert betroffene Hotelkette und wird an straiv weitergeleitet.
  • 25.05.2024 straiv vereinbart einen Termin für die Übermittlung aller Details.
  • 04.06.2024 HiSolutions teilt alle Details mit straiv.
  • 06.06.2024 straiv veröffentlicht ein Update und HiSolutions bestätigt den Fix.

CVE-2024-24272 – DualSafe Password Manager Leaks Credentials

During an investigation, HiSolutions discovered a credential leak of a password manager that was installed as browser extension. After reporting the vulnerability, the vendor was quick to respond and implemented a fix.

Summary

The DualSafe Password Manager by iTop before version 1.4.24 leaks credentials as plaintext in a log file that can be accessed by the local user without knowledge of the master secret (CWE-532). This vulnerability was assigned CVE-2024-24272.

Update to the newest version (at least 1.4.24) as soon as possible and replace potentially leaked credentials.

Vulnerability Details

The following details were produced in a test setup with the vulnerable version 1.4.21 of the DualSafe Password Manager installed in Chrome. After storing and using several credential pairs via the blue extension icon on the top right corner, the log file started showing some entries that contain the plaintext credentials.

Logging is done via a text file in the directory of the browser extension, in this case: C:\Users\User\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\lgbjhdkjmpgjgcbcdlhkokkckpjmedgc\000003.log (file name may vary).

The following image depicts the credential pair stored in DualSafe (right) as well as the log file that contains the same password as plaintext (left).

DualSafe password manager and its log file. Cleartext credentials are marked in the log file.
DualSafe Password Manager leaks plaintext password in log file.

One interesting thing to note is that, while the log file contains some credentials as plaintext in a structure like this one: cacheTabinfoes1_1Þ{"[...]":{"confirmItem":{"pwd":"<password>",[...], "type":"login","uname":"<user>","uri":["<url>"]}}}, there are also similar structures with the key pwd but their value is encrypted. Though the observed log events did not indicate the exact trigger for an entry with a plaintext password, passwords could already be extracted after just a few login attempts.

Usually, the password manager requires a master secret to unlock and access the stored credentials. This vulnerability allows an attacker to harvest stored credentials from the log file without knowing the master secret.

Remediation

iTop announced a fix in version 1.4.24.

Shortly after reporting the vulnerability details to iTop, a fix was implemented and rolled out across Firefox, Edge, and Chrome. Update to the newest version as soon as possible and check for potentially leaked passwords in the described location (the exact path depends on the browser).

Should passwords have been leaked this way, rotate them after updating the extension.

Responsible Disclosure Timeline

  • 04.01.2024 – HiSolutions contacts iTop
  • 30.01.2024 – HiSolutions contacts iTop again after no response
  • 31.01.2024 – iTop responds and requests vulnerability details
  • 31.01.2024 – HiSolutions provides all vulnerability details
  • 01.02.2024 – iTop announces that a fix has been implemented and will be published soon
  • 02.02.2024 – iTop requests a delay before publication to roll out the fix
  • 05.02.2024 – iTop releases 1.4.24 on Firefox and Edge
  • 15.02.2024 – iTop releases 1.4.24 on Chrome
  • 12.03.2024 – HiSolution requests green light for publication
  • 13.03.2024 – iTop accepts and states that 1.4.24 fixes the vulnerability

Credits

This vulnerability was discovered by Paula T., Joshua Z. and Pascal B. (HiSolutions AG). We also thank iTop for their swift response and remediation regarding this vulnerability.