Sicherheitsanalyse secunet fangreicher, sensibler und wertvoller Kommunikationsinhalte, als beson- ders kritisch einzuschätzen. Version: 1.0            Stand: 30.05.2018                                        1 Seite 11

Sicherheitsanalyse secunet 2           Konventionen im Dokument Im vorliegenden Dokument werden die in den Systemen und innerhalb der Organi- sation identifizierten Schwachstellen beschrieben. Die Beschreibung der identifizierten technischen Schwachstellen setzt sich aus den drei Komponenten Schwachstelle {S}, Risiko {R} und Maßnahme {M} mit einer zu- gehörigen Nummer zusammen. Der Bereich Schwachstelle beschreibt die identifizierte Schwachstelle. Dabei wer- den Bedrohungen der Integrität (können die Daten unberechtigt verändert werden), der Verfügbarkeit (kann die Erreichbarkeit eines Systems/ Dienstes eingeschränkt werden) und der Vertraulichkeit (kann ein Unberechtigter auf die Daten lesend zu- greifen) unterschieden. Pro Kategorie werden die Klassen hoch, mittel und niedrig unterschieden, die angeben, wie kritisch die jeweilige Bedrohung eingeschätzt wird. Der Bereich Risiko stellt das Risiko dar, welches durch das Vorhandensein der Schwachstelle hervorgerufen wird . Die Ausnutzbarkeit bzw. Wahrscheinlichkeit des Risikos wird auch hier in den Klassen hoch, mittel und niedrig unterschieden. Der Bereich Maßnahme beschreibt schließlich Maßnahmen, die getroffen werden sollten, um die Schwachstelle zu beseitigen. Die Maßnahmen stellen Empfehlungen dar, die durch den Betreiber implementiert werden müssen. Die Priorisierung der Maßnahmen, die sich direkt aus der Kritikalität der Schwach- stellen und dem identifizierten Risiko ableitet, und anhand der im Felgenden defi- nierten Kategorien: A-Betriebsverhindernde Schwachstelle Die Behebung \Ur Wiederinbetriebnahme wird dringend empfohlen. B-Betriebsbehindernde Schwachstelle Die Behebung \Ur Wiederinbetriebnahme oder sehr zeitnah danach wird empfohlen. C-Sonstige Schwachstelle Lediglich unerhebliche Auswirkung auf den Betrieb, eine Behebung kann später erfolgen. Zusätzlich werden (falls verfügbar) zu den identifizierten Schwachstellen die zuge- hörigen Common Vulnerabilities and Exposure (CVE) IDs aufgeführt. Bei CVE han- delt es sich um einen Industriestandard, der eine einheitliche Namenskonvention für Sicherheitslücken und andere Schwachstellen in Computersystemen bereitstellt. rv1ehrfachbenennungen gleicher Gefahren werden um eine laufende Nummer (z. B. CVE-2006-3086) ergänzt, um eine eindeutige Identifizierung der Schwachstellen zu gewährleisten. Dadurch ist ein reibungsloser Informationsaustausch zwischen den Version : 1.0                    Stand : 30.05.2018                                             1 Seite 12

Sicherheitsanalyse secunet verschiedenen Datenbanken einzelner Hersteller möglich. Basierend auf den CVE- IDs können auf der Web-Seite http://cvedetails.com/ weiterführende Informationen zu der Schwachstelle nachgelesen werden. Version : 1.0               Stand : 30 .05.2018                                         1 Seite 13

Sicherheitsanalyse secunet 3          Penetrationstests In dem nachfolgenden Kapitel findet sich eine ausführliche Zusammenfassung der bis zum Stichtag gefundenen wesentlichen Ergebnis$e. Nach kurzer Erläuterung der Rahmenbedingungen finden sich in dem Kapitel „Identifizierte Schwachstellen" die Schwachstellen mit der Einstufung „betriebsverhindernd". 3.1        Rahmenbedingungen Die secunet hat im Auftrag der BRAK im Februar und l\tlärz 2018 einen Penetrati- onstest ausgewählter Systeme durchgeführt. Ziel dieser Analyse war es, verschie- dene sicherheitsrelevante Schwachstellen zu identifizieren und zu bewerten. Die Analyse orientierte sich am OWASP Testing-Guide V4. 3.1.1      Abgrenzung Bei einer technischen Sicherheitsanalyse oder einem Penetrationstest handelt es sich naturgemäß um eine stichprobenartige Analyse, in der versucht wird, mit einem vertretbaren Aufwand möglichst viele Schwachstellen innerhalb eines Untersu- chungsobjektes zu finden. Im Normalfall lässt sich nur ein Teil der gefundenen Systemeigenschaften ohne wei- teres eindeutig als Schwachstelle einstufen - der andere Teil benötigt eine weiter- gehende Überprüfung. Im Rahmen dieser Überprüfung wird untersucht, inwieweit die identifizierten auffälligen Eigenschaften eines Systems auf Funktionen zurückzu- führen sind, die anforderungsgemäß implementiert wurden, und inwieweit durch die Art und Weise der Implementierung Schwachstellen entstanden sind, die durch eine alternative Implementierung vermieden werden können. Bei diesen Überprüfungen muss aufgrund der sich ergebenden Anzahl der Kombinationsmöglichkeiten im Rahmen des zur Verfügung stehenden Zeitkontingentes eine Abwägung zwischen der Menge der zu bewertenden Eigenschaften insgesamt und der Tiefe der durch- zuführenden Untersuchung getroffen werden. Weiterhin muss eine technische Sicherheitsanalyse immer als Betrachtung zu ei- nem Stichtag aufgefasst werden. Die zu diesem Tag bekannten Schwachstellen und Angriffstechniken werden genutzt. Aussagen über die Zukunft lassen sich jedoch nicht treffen: Ein System, bei dem keine Schwachstelle gefunden wurde, kann bereits einen Tag später durch eine neu entdeckte Schwachstelle angreifbar werden. Auch Änderungen der Systemeinstellungen können positive oder negative Auswirkungen auf die Systemsicherheit haben. Version : 1.0                   Stand: 30.05.2018                                           1 Seite 14

Sicherheitsanalyse secunet 3.1.2     Beschreibung des Analysegegenstandes Zunächst wurde die beA-Systemumgebung erfasst und in zwei Testphasen aufge- teilt. Innerhalb der ersten Phase - bis Ende März 2018 - wurden die beA-Client- ' Security einschließlich der bei Nutzung der beA-Client-Security angesprochenen Korn m unikationsendpunkte der beA-Anwendung betrachtet. Der Fokus des Penetra- tionstest lag hierbei auf den externen ansprechbaren Schnittstellen der beA- System kom ponenten. Innerhalb der zweiten Testphase wurden weitere Webservices , Webportale und der sogenannte RAK-Client auf Schwachstellen hin untersucht, die im erweiterten Rah- men des Betriebs bzw. der Nutzung der beA-lnfrastruktur bereitgestellt werden. Die- se Dienste sind über das Internet ansprechbar und entweder ohne oder nur nach erfolgreicher Client-Authentifizierung nutzbar. Während der zweiten Testphase wurde - soweit bereits möglich - auch die Behe- bung der bis dahin gefundenen Schwachstellen überprüft. Im Folgenden sind die während der Analysen geprüften Software-Versionen der beA-Komponenten aufgeführt: •   beA-Client-Security v3.1 .3.6 •   beA-Client-Security (Retests) v3.1.3. 7 •   beA-Anwendung (Testphase 1) v2.0.10 •   beA-Anwendung (Testphase 2) v2.1 •   beA-Anwendung (Retests) v2.1.1 •   BRAV-Suche (BRAVSEARCH) v2.1.1.1 Version: 1.0                  Stand : 30 .05 .2018                                      1 Seite 15

Sicherheitsanalyse secunet ,-------------                         l ~mmc r : l~ndl! !l ~n l                                        Kammersoftware BRAV Suche    Flnd..,,.-lawyar l : 1    Hleme Kompon!n~n 1 1   A wrwrndt-t 8 l8-+EJ : Tnn l lulchr.in1 SAfE-Omnector L:_:-_::_::::__ :       Kanzlei 1oftware SAFE BRAK         --;nn--;---- r -                    SAFE Justiz 1 1 Ben utzer                                                                                  1 - ------ ... - Intermediär ..........  1                                       1------~--                             Justiz beA- Anwendung        lntermedl.lr                     EGVP·Chenl BRAK        ....-;---.,...-;     Jus112 Browser     14--'-----'------.i beA·HSM                                                          1 1 1 L----- be:A-Zrn l ral1ws~m --   -     - - Abbildung 1: Architektur der externen beA-Schnittstellen 3.1 .3    Vorgehenswe ise und Inhalte der Untersuchung Ausgangspunkt für das verwendete Angriffsszenario ist die Perspektive eines exter- nen, aus dem Internet agierenden Angreifers (Greybox-Ansatz). Dieses wird durch die zusätzlich durchgeführten Quelltext-Analysen und die konzeptionellen Analysen ergänzt (Whitebox-Ansatz). Basierend auf dem OWASP Testing-Guide v4 wurden die im Internet üblicherweise auftretenden Angriffsvektoren geprüft, ausgewertet und dokumentiert. Die OWASP-Testfälle wurden basierend auf Erfahrungswerten vergangener Analysen und in Bezug auf die untersuchte Architektur der beA- Systemumgebung um weitere Tests ergänzt. Der Penetrationstest wurde nach folgendem Ablauf durchgeführt: •       Einarbeitung in die Dokumentenbasis •       Einrichtung der Testumgebung •       Durchführung der Analysen (einschließlich der Verifikation der Behebung bereits auf andere Weise bekanntgewordener Schwachstellen) •       Dokumentation, Auswertung und Kommunikation der Ergebnisse •       Überprüfung behobener Schwachstellen 3.2       Identifizierte betriebsverhindernde Schwachstellen Nachfolgend werden die in Testphase eins und zwei gefundenen Schwachstellen aufgeführt, welchen insgesamt das höchste Bedrohungspotenzial (Priorität A Be- triebsverhindernde Schwachstelle) mit Blick auf die Schutzziele Vertraulichkeit, In- Version: 1.0                           Stand : 30.05.2018                                                                                     1 Seite 16

Sicherheitsanalyse secunet tegrität und Verfügbarkeit des Zielsystems beigemessen wird. Diese Schwachstellen lassen sich thematisch wie folgt kategorisieren: •    Autorisierungsmechanismen •    Sessionmanagement •    Transportsicherung •    Informationssammlung •    Identitätsmanagement 3.2.1      Autorisierungmechanismen: Umgehen des Autorisierungsschemas Es konnte festgestellt werden, dass authentifizierte Benutzer über die beA-Client- Security potenziell auf die rvletadaten aller Anhänge von Nachrichten anderer Be- nutzer zugreifen können. Hierfür muss man lediglich eine einfache numerische Nachrichten-ID und den Dateinamen des Anhangs erraten. Als verifizierte IVetada- ten in diesem Kontext konnten folgende Informationen identifiziert werden: •    „reference": [realer Dateiname im Klartext wie z.B. 2011000000-VR16000- 12345678_1.pdf oder Klage.pdf] •    „alias": [Entspricht der in der beA-Anwendung im Browser hinterlegte Be- zeichnung des Anhangs . Dieser kann Fließtext wie ,,falsche Zeugenaussa- ge Person X" sein] •    „type": ATTACHMENT oder STRUKTURDATENSATZ [Zweck zum aktuel- len Zeitpunkt nicht bekannt] •    „data": [nicht lesbarer Inhalt, mit hoher Wahrscheinlichkeit tatsächlicher verschlüsselter Anhang] •    „key": [Kryptografischer Schlüssel] •    „sizeKB": 1 [Größe des Anhangs in KB] •    „hashValue": [Hash-Wert zur Überprüfung der Integrität] •    „sizeEncryptedKB": null [Zweck zum aktuellen Zeitpunkt nicht bekannt] Ein in der beA-Anwendung angemeldeter Angreifer kann hier mittels automatisierter Skripte über Nacht bzw. über mehrere Tage versuchen die numerischen IDs der Anhänge und der Dateinamen zu erraten und so bei Erfolg aus seinem eigenen Nutzerkontext innerhalb der beA-Anwendung ausbrechen und auf die aufgeführten rvleta-lnformationen von Daten Dritter zugreifen. Benutzer sollten, trotz der Ver- schlüsselung der konkreten Nachrichten- bzw. Dateiinhalte, nur auf Anhänge und In- formationen über Anhänge zugreifen können, die ihrem Konto zugeordnet sind. Es sollte geprüft werden, warum das implementierte Nutzer- und Rollenkonzept an die- ser Stelle einen Zugriff nicht verhindert. {S 1}        Es ist angemeldeten Benutzern möglich, auf die rvletadaten von einem Anhang einer Nachricht von anderen Benutzern zuzugreifen. Version : 1.0                    Stand: 30.05.2018                                           1 Seite 17

Sicherheitsanalyse secunet Beispiel: https ://tes t. bea-brak.de/bea/rest/m es sage/2421295/attachm ent/tes t. txt (Bedrohung Integrität:                  niedrig) (Bedrohung Verfügbarkeit:               niedrig) (Bedrohung Vertraulichkeit:             hoch) {R1}      Ein Angreifer kann die Details der Anhänge von anderen Konten abru- fen. (Wahrscheinlichkeit:                     mittel) {M1}      Benutzer sollten nur auf Anhänge und Informationen über Anhänge zu- greifen können, die ihrem Konto zugeordnet sind. Zusätzlich sollte ge- prüft werden, warum aus dem aktuellen Rollenkonzept ausgebrochen werden kann und auf dritte Nutzerobjekte zugegriffen werden kann. (Bewertung:                             A-Betriebsverhindernde Schwach- stelle) 3.2.2     Autorisierungsmechanismen: Path-Traversal bei Dateiupload Beim Upload von Dateien mithilfe des RAK-Clients an den entsprechenden Webs- ervice werden in den HTTP-Requests an den Server sowohl die Dateiinhalte als MIME-Attachment, sowie der Dateiname im Parameter „Content-ID" übermittelt. Dieser Parameter innerhalb des TLS-Kanals ist durch IVlanipulation anfällig für Path- Traversal-Angriffe, die es einem Angreifer erlauben könnten, beliebige Dateien an einem vom Angreifer kontrollierten Speicherort auf dem Server abzulegen und die- sen dadurch ggf. zu kompromittieren. Beim Download von Dateien im Client wurde eine vergleichbare Schwachstelle beobachtet. Während der Analyse zeigte das Antwortverhalten des Servers deutliche Hinweise auf die Ausnutzbarkeit der Schwachstelle, die genauen Auswirkungen auf Serverseite konnten aufgrund der Natur von Blackbox-Tests jedoch nicht vollständig verifiziert werden. {S2}     Die Content-ID wird nicht ausreichend geprüft und ist damit anfällig Path- Traversal-Angriff beim Dateiupload. (Bedrohung Integrität:                    hoch) (Bedrohung Verfügbarkeit:                 mittel) (Bedrohung Vertraulichkeit:               niedrig) {R2}     Ein Angreifer kann eventuell Daten auf dem Server überschreiben, andere Kammern beeinflussen und lokale Angriffe auf den Client reflektieren. (Wahrscheinlichkeit:                      hoch) {S3}     Die Content-ID sollte keinen Pfadwechsel erlauben und auf die Kammer des Clients beschränkt werden. (Bewertung:                               A-Betriebsverhindernde Schwach- stelle) Version: 1.0                    Stand: 30 .05.2018                                             1 Seite 18

Sicherheitsanalyse secunet 3.2.3      Session-Management: Parametrisierung der Session-Cookies Innerhalb des normalen Nutzungsverlaufs der beA-Client-Security wird das Session- Cookie als GET-Argument innerhalb der URL an die beA-Anwendung übermittelt. Nicht autorisierte Mtarbeiter könnten durch Auslesen der Sitzungsinformationen, z.B. aus dem Log eines Webproxys mit TLS-lnterception oder lokalen Debug- Logdaten, eingeschränkt die Identität des betroffenen Anwalts bzw. Benutzers im beA-Webportal übernehmen. Die Exposition der Sitzungsinformationen sollte mög- lichst gering sein, um Session-Hijacking zu verhindern. {S4}       Die JSESSIONID wird als GET-Argument in URLs geschickt. (Bedrohung Integrität:            niedrig) (Bedrohung Verfügbarkeit:         niedrig) (Bedrohung Vertraulichkeit:       hoch) {R3}       Diese Session-ID kann z.B. vom Browser gecached werden. Wenn ein Angreifer Zugriff auf den Rechner oder einen zwischengeschalteten Webproxy hat, kann er den Wert ggf. übernehmen und Zugriff auf das Konto des Benutzers gewinnen. (Wahrscheinlichkeit:              mittel) {M2}       Die JSESSIONID sollte nicht als Teil der URLs übertragen werden. (Bewertung:                       A-Betriebsverhindernde Schwach- stelle) 3.2.4     Verschlüsselungsmechanismen der Kommunikationskanäle Durch eine nicht ausreichend gehärtete Konfiguration der Transportverschlüsselung zwischen der beA-Client-Security und der beA-Anwendung werden Man-in-the- Mddle-Angriffe erleichtert. Innerhalb einer gemeinsam mit weiteren Benutzern ge- teilten Netzwerkumgebung, wie beispielsweise in einem Hotel-WLAN, könnte es hierbei zu Man-in-the-Mddle-Angriffen (MITM) kommen. Bei einem erfolgreichen Angriff auf die Kommunikationsverbindung könnte ein Angreifer nicht zusätzlich ver- schlüsselte Informationen mitlesen, manipulieren oder die Sitzung mit dem beA- Webportal des betroffenen Nutzers übernehmen. Ein Identitätsdiebstahl in diesem Sinne ist auf die Funktionen begrenzt, welche ein normaler Nutzer ohne die Signa- turkarte am beA-Anwendungssystem durchführen kann. Die Konfiguration des beA- Anwendungsservers sollte überarbeitet werden. 3.2.5     Informationssammlung: Applikationsarchitektur Die beA-Anwendung verwendet veraltete Javascript-Bibliotheken UQuery und Bootstrap) mit bekannten Schwachstellen. Je nach Einbindung der Javascript- Bibliotheken können erfolgreiche Angriffe durchgeführt werden. Eine konkrete Schwachstelle durch die Javascript-Bibliotheken konnte nicht identifiziert werden. Können die Schwachstellen der veralteten Software-Komponenten tatsächlich aus- genutzt werden, kann ein Angreifer theoretisch beispielsweise einen manipulierten Link auf die bea-brak.de Webseite erstellen und diesen per Nachricht an einen Nut- Version: 1.0                    Stand : 30.05.2018                                        1 Seite 19

Sicherheitsanalyse secunet zer der bea-brak.de Seite oder beliebigen anderen Nutzer schicken. Klickt der Nut- zer auf den manipulierten Link, so wird ihm eine manipulierte Webseite unter der Domain bea-brak.de angezeigt. Der Angriff zielt auf die Benutzer der beA- Anwendung ab und betrifft nicht die Sicherheit des Backend-Servers. Die im Rah- men der Anwendung verwendeten Software-Bibliotheken sollten regelmäßig über- prüft und ggf. aktualisiert werden. Ein ganzheitlicher Patchmanagement-Prozess auf alle im beA-Kontext befindlichen Softwareelemente sollte aufgebaut bzw. verbessert werden. {S5}     Die Webseite verwendet veraltete Javascript-Bibliotheken UQuery und Bootstrap) mit bekannten Schwachstellen. (Bedrohung Integrität:               niedrig) (Bedrohung Verfügbarkeit:            niedrig) (Bedrohung Vertraulichkeit:          hoch) {R4}     Ein Angreifer könnte die Schwachstellen dieser Versionen ausnutzen, um unerwünschte Skripte auf dem Rechner eines Opfers ausführen. (Wahrscheinlichkeit:                 mittel) {M3}      Die verwendeten externen Bibliotheken sollten regelmäßig überprüft und ggf. aktualisiert werden. (Bewertung:                          A-Betriebsverhindernde Schwach- stelle) 3.2.6     Identitätsmanagement: Umgehung des Authentisierungsschemas Nicht angemeldete Angreifer können beliebigen Text auf dem beA- Anwendungsserver hochladen. Der Angreifer benötigt hierfür keine Authentisierung am beA-System. Ein Angreifer kann hierfür mittels einer einfachen Anfrage Daten auf dem Server abspeichern und zu einem späteren Zeitpunkt wieder abrufen. Die- ser Umstand könnte für das Abspeichern von sehr großen Datenmengen oder bei- spielsweise als Ablage für illegale Daten bzw. Informationen missbraucht werden. In einer ersten Maßnahme sollte diese Funktion nur authentifizierten Benutzern bereit- gestellt werden. Weiterhin kann, falls erforderlich, das Abspeichern von Daten auch zeitlich begrenzt werden, um die Angriffsfläche bzw. das Mssbrauchspotenzial zu minimieren. {S6}      Nicht angemeldete Benutzer können beliebigen Text auf dem Server hochladen. (Bedrohung Integrität:               niedrig) (Bedrohung Verfügbarkeit:            mittel) (Bedrohung Vertraulichkeit:          niedrig) {R5}      Mögliche Angriffsszenarien: 1) Ein Angreifer kann beliebige Daten hochladen und den Server zur Ab- lage und Verteilung der Daten verwenden. 2) Ein Angreifer kann mehrere großen Tickets hochladen, um die Ser- verressourcen auszulasten. (Wahrscheinlichkeit:                 hoch) Version: 1.0                  Stand : 30 .05.2018                                          1 Seite 20