Security Bulletin IBM Rational DOORS

Dossier und Bewertung der kritischen Sicherheitslücke CVE-2018-1457

Auswirkungen

Mit einem manipulierten Client oder einem selbstgeschriebenen Tool ist es möglich, Daten vom Server zu lesen oder zu schreiben, ohne dass es einen Schutzmechanismus gibt.

Erlangung von Administrator-Rechten
So läßt sich z.B. innerhalb von Sekunden der Passworthash des Administrator-Benutzers auslesen oder durch einen Passwort-Hash ersetzen, dessen Klartextpasswort bekannt ist. So kann in wenigen Augenblicken die vollständige Kontrolle über den Server erlangt werden und im Anschluss jede erdenkliche Operation auf dem Server mit einem regulären Client ausgeführt werden. Im Anschluss kann der alte Passworthash und das Last-Login-Datum zurückgesetzt werden, so dass niemand die Ausnutzung der Lücke im Nachhinein bemerken wird.

Sabotage und Datenveränderung
Darüber hinaus können auch direkt Befehle an den Server geschickt werden, welche Daten exportieren oder verändern, die Datenbank zerstören oder latente Inkonsistenzen hinterlassen, welche über die Zeit die Datenbank zerstören werden.

Abstufungen

Die Ausnutzbarkeit der Sicherheitslücke ist je nach "Serverbetriebsart" unterschiedlich.

Out-of-the-box-Betrieb
Dies ist die Betriebsart, in der der Server durch den Installer bereitgestellt wird. Diese Betriebsart ist daher auch die am häufigsten eingesetzte.
In dieser Betriebsart erfolgt die Kommunikation zwischen Client und Server unverschlüsselt.
Hier kann der Angriff mittels eines kleinen Skriptes oder sogar per Telnet durchgeführt werden, da das Protokoll zwischen Server und Client ein Klartextprotokoll ist.
Einzige Voraussetzung: Zugriff auf den TCP-Port des Servers (im Standardfall Port 36677)

mit SSL-Zertifikaten
Wenn SSL-Zertifikate auf Server und Client eingesetzt werden, um die Kommunikation zu verschlüsseln, benötigt man für den Angriff ein gültiges Client-Zertifikat, um die Kommunikation zum Server aufbauen zu können. Der Zertifikat wird jedoch nicht zur Autorisierung eingesetzt, sondern nur, um den Kommunikationskanal aufzubauen. Es reicht daher ein beliebiges Zertifikat, es muss kein Zertifikat eines priviligierten Benutzers sein.

mit aktiver Server Side Security
Die Server-Side-Security von IBM sichert den Server durch eine Reihe von "InterOp"-Clients ab, die jede Anfrage an den Server prüfen sollen, bevor diese ausgeführt wird. Damit dieses funktioniert, benötigen diese jedoch einen priviligierten Zugriff auf die Datenbank.
Dieses lässt sich ausnutzen, indem man sich dem Server gegenüber als "Interop"-Client ausgibt. In diesem Fall unterbleiben die Sicherheitsprüfungen, die für Anfragen von normalen Clients in diesem Betriebsmodus gelten.
Dieser Betriebsmoduls läßt sich mit dem Einsatz von SSL-Zertifikaten kombinieren.

Bewertung

Daten
Da die Software IBM Rational DOORS vom Einsatzweck her eine Software zur Erhebung, Speicherung und Verwaltung von Anforderungen ist, enthält die Datenbank meist als vertraulich oder sogar als geheim klassifizierte Daten.

Verbreitung
Die Software ist von der Verbreitung her klar als Marktführer zu bezeichnen. Die Branchen, die diese Software einsetzen ist daher auch entsprechend breit gefächert (z.B. Automobilkonzerne, Automobilzulieferer, Flugzeughersteller, Versicherungsunternehmen, Öffentliche Verwaltung, Rüstungsunternehmen, Bundeswehr...)

Angriffskomplexität
Für die Ausnutzung der Lücke ist nur ein Zugriff auf den TCP-Port des Servers (und sofern SSL-Zertifikate eingesetzt werden: ein gültiges Client-Zertifikat) notwendig .
Sofern dies für einen Mitarbeiter oder externen Dienstleister leicht zu erlangen ist, ist dringender Handlungsbedarf gegeben, um einen möglichen Abfluss von Informationen zu verhindern.

Entdeckungswahrscheinlichkeit
Da die Lücke durch die Architektur der Software entsteht und seit Jahrzehnten besteht, ist es möglich dass diese bereits in der Vergangenheit ausgenutzt wurde.
In verschiedenen Foren kursierten bereits in der Vergangenheit Code-Fragmente eines nachgebauten Clients, die hierfür hätten verwendet werden können.

Fazit
Mit dem richtigen Wissen ist jede Standardinstallation eines DOORS Server für einen Angreifer lesbar und manipulierbar, sofern der Angreifer Zugriff auf das Netzwerk hat. Da keine Admin-Rechte benötigt werden und eine Schadsoftware geringem Zeitaufwand (1-2 Tage) entwickelt werden kann, ist die Gefahr, die von der Sicherheitslücke ausgeht, groß.

Einstufung

In Abweichung zur Herstellerangabe von IBM kommen wir zu folgender Einstufung:
(Unterschiede sind Fett gekennzeichnet)

Cvss Basis Score - 9.8

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Cvss Temporal Score - 9.3

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:F/RL:W/RC:C

Ursachen

Die Architektur von IBM Rational DOORS sieht eine vollständige Implementierung aller Sicherheitsprüfungen auf dem Client vor. Die Daten auf dem Server liegen in tausenden von einzelnen Dateien vor, die der Client vom Server abruft.
Der Server führt keine Rechteprüfungen durch, sondern liefert alle Daten ohne weitere Prüfung aus, sofern nicht die Server Side Securty von IBM zusätzlich implementiert wurde.

Lösungen

Beide hier aufgeführte Lösungen stellen im Prinzip einen Work-Around dar, der eine zusätzliche Prüfung der vom Client gesendeten Befehle implementiert. Beide Lösungen verhindern den unberechtigten Zugriff auf die Datenbank.

Server-Side-Security ab Version 9.6.1.11

Ab der DOORS-Server-Version 9.6.1.11 gibt es eine Zusatz-Option"-secureInteropbyIP" mit welcher der DOORS-Server gestartet werden kann. Danach können sich nur noch Clients als Interop-Clients anmelden, deren IP-Adresse in einer Whitelist-Datei (whitelist.dat im Doors-Data-Ordner des Servers) steht. Versionen vor 9.6.1.11 bieten keinen Schutz gegen die Sicherheitslücke!
Hinweis: Diese Lösung wird von IBM als offizieller Fix der oben genannten Sicherheitlücke geführt und daher wird die Sicherheitslücke von IBM offiziell als behoben betrachtet.

requisis_DSP

requisis_DSP arbeitet als Security Proxy und wird "vor" den DOORS-Server geschaltet.
Für jeden Anwender wird hier ein individuelles Zertifkat genutzt, in dem alle DOORS-Benutzer kodiert sind, mit denen sich
der Anwender anmelden darf. Der Verbindungsaufbau vom Client erfolgt dabei nicht direkt zur DOORS-Datenbank, sondern zu requisis_DSP.
Bei jedem Lese- und Schreibzugriff wird geprüft, ob einer der hinterlegten Benutzer lese- oder schreibberechtigt ist. Nur dann wird die Anfrage an den Server weitergeleitet. Wenn ein manipulierter Client oder ein Hacking-Tool versuchen, Daten ohne Berechtigung vom Server zu lesen oder zu schreiben, werden die Anfragen nicht an den Server übergeben.

Wir helfen Ihnen, Ihre Daten zu schützen

Audit vor Ort

Um zu prüfen, ob Ihr DOORS-Server betroffen ist, bieten wir Audittermine an, bei denen wir gemeinsam mit Ihnen vor Ort prüfen, ob Ihr System betroffen ist. Dabei führen wir auf Wunsch die verschiedenen Angriffe live vor.
Bitte haben Sie Verständnis dafür, dass wir die eingesetzten Tools und Code für den Angriff aus Sicherheitsgründen nicht aushändigen und dass wir auch keine Audits per remote durchführen.
Gerne stellen wir Ihnen jedoch ein Video mit einem beispielhaften Angriff zur Verfügung.

Bereitstellung einer Lösung

Gerne unterstützen wir Sie bei der Installation einer Lösung, um Ihren Server gegen möglich Angriffe abzusichern oder führen diese für Sie aus. Dabei können Sie zwischen beiden verfügbaren Lösungen oder auch alternativen Ansätzen wählen. Gerne beraten wir Sie, welche Lösungen welche Vor- und Nachteile haben und finden gemeinsam mit Ihnen die für Sie optimale Lösung.

Ihr Ansprechparter

Nikolai Stein-Cieslak

Telefon:	+49 (30) 536506-711
Fax:	+49 (30) 536506-311
E-Mail:	nikolai.stein@requisis.com