Sicherheitsanalyse secunet {M4}     Nicht angemeldete Benutzer sollten keine Tickets auf dem Server erstel- len können. (Bewertung:                            A-Betriebsverhindernde Schwach- stelle} 3.3       Identifizierte betriebsbehindernde Schwachstellen Nachfolgend werden die in Betrachtungsphase eins und zwei gefundenen Schwachstellentypen zusammengefasst, welche insgesamt ein mittleres Bedro- hungspotenzial (betriebsbehindernd) im Sinne der Schutzziele Vertraulichkeit, Integ- rität und Verfügbarkeit des Zielsystems darstellen: Schwachstelle ntyp                    Risiko Preisgabe von Versionsinformatio- Genaue Versionsinformationen eingesetzter nen                                   Komponenten erlauben es einem Angreifer gezielt nach bekannten Schwachstellen oder öffentlichen Quelltexten zu recherchieren. Informationslecks    von      System- Die identifizierten Informationslecks können kom ponenten                          Angreifern bei weiteren Angriffsschritten hilfreich sein (z.B. Stack-Traces oder W AF- Regeln). Fehlende Lock-Out-rvlechanismen       Authentifizierungs-Endpunkte sollten gegen automatisierte Brute-Force-Angriffe geschützt sein, die zum Erraten von Logindaten durch- geführt werden können. Lokale Speicherung von Passwör- Auf Benutzersystemen gespeicherte Passwör- tern bzw. Passphrasen im Klartext ter sollten je nach Nutzungskontext vor zu ohne Mssbrauchsschutz                 einfacher Entwendung und entsprechend einfachem Mssbrauch geschützt sein. Inkonsistenzen in der Business- Bei der Verarbeitung von Kommandos durch Logik des Ticketsystems               das Ticketsystem wurden Inkonsistenzen identifiziert, die jedoch nur geringes Miss- brauchspotenzial aufweisen. XSS-Schwachstellen                    Bei den Analysen wurden einzelne XSS- Schwachstellen identifiziert, die jedoch nur unter sehr speziellen Bedingungen und mit begrenztem Schadenspotenzial ausgenutzt werden können. Version: 1.0                  Stand : 30.05.2018                                             1 Seite 21

Sicherheitsanalyse secunet Path-Traversal in Clientsoftware        Durch fehlende Validierung eines Parameters in der Serverantwort beim Download von Dateien könnten durch einen l\tlan-in-the- Mddle ungewünschte Dateien an einen anderen als den vorgesehenen Speicherort im Dateisystem abgelegt werden. Signature-Wrapping        bei     SOAP- Verschiedene          Webservice-Schnittstellen Webservices                             zeigten sich anfällig für Signature-Wrapping- Angriffe,    bei    denen      signierte SOAP- Nachrichten manipuliert werden könnten. Bei der Einschätzung des Risikos wurden ggf. weitere Schutzfunktionen (W AF, Client- Zertifikat) und die Limitierung eines möglichen Angriffs auf den Kontext des authentifizierten Benutzers berücksichtigt. Klartext-Übertragung der Namen Die Namen der Nachrichtenanhänge ein- von Nachrichtenanhängen inner- schließlich der Dateiendungen sollten eben- halb einer TLS-Verbindung.              falls vom HSM verschlüsselt werden und können Rückschlüsse auf Teile übertragener Dateien zulassen (z.B. Dateiheader). Die Namen von          Nachrichtenanhängen sind schützenswerte Informationen, die auch auf dem Anwendungsserver nicht im Klartext vorliegen sollten. 3.4        Verifikation der Behebung gefundener Schwachstellen Insgesamt wurden bei den Penetrationstests zehn betriebsverhindernde Schwach- stellen identifiziert. Von diesen konnten während der zweiten Analysephase bereits sieben erneut getestet werden, von denen fünf erfolgreich und zwei nicht erfolgreich behoben wurden. Zusätzlich wurden bei den Penetrationstests achtzehn betriebsbehindernde Schwachstellen identifiziert. Von diesen konnten während der zweiten Analysepha- se sieben erneut getestet werden, von denen vier erfolgreich, zwei teilweise und ei- ne nicht erfolgreich behoben wurden. 3.5        Verifikation der Behebung vorab bekannter Schwachstellen Im Rahmen der Analyse wurde geprüft, in wieweit die vor Beginn der Analyse be- kannt gewordenen Schwachstellen in den aktuell vorliegenden Softwareversionen (Client-Security 3.1.3.6-HF1 und beA-Anwendung 2.1 .0-r5871) behoben wurden. Version : 1.0                    Stand : 30.05.2018                                               1 Seite 22

Sicherheitsanalyse secunet Dabei wurde auch geprüft, ob durch die dafür vorgenommenen Veränderungen an der Software möglicherweise neue Schwachstellen verursacht haben. In der folgenden Tabelle sind die bis zum Testbeginn bekannten Schwachstellen und die Ergebnisse der erneuten Überprüfung aufgeführt: Beschreibung der                           Behebungsstatus Kommentar secunet Schwachstelle                              Schwachstelle Anwendung stürzt in U:>untu 16.04 ab, ist Funktionstests wurden nicht durchge- in U:>untu 14.04 lauffähig. Die Anwen- #2355 #CCC.04: Es werden nur End of        führt. Support-A'ozess für aktuelle dung sollte auf Systemen lauffähig sein, Life Linux-/11/ac-Versionen unterstützt    Betriebssysteme zwingend erforderlich. die noch rrit aktuellen Sicherheits- Siehe auch Kapitel 6.1.2. Updates versorgt werden. Signierung der XM...-Datei und der #2379: beA-Clieri-Security-Updater Schwachstelle wurde behoben.           Softwareartefakte Gar-Dateien) erfolgt enthält abgelaufenes Zertifikat anhand eines gültigen Zertifikats . #2402: Signatur des lnstallers ( .msi) mit Schw achstellewurde behoben. MSI-      MSl-lnstaller war nicht digital signiert, Governikus-Schlüssel                       lnstaller ist fachgerecht signiert.    wurde behoben ( s. Anhang). #2403: beA-Clieri-Security. Jetty- Schwachstelle wurde behoben. Versionsnummer im HTTP-Header Während der Analyse wurden Sessio- #2404: Request-Parameter SessionlD         Schwachstelle wurde nicht vollständig  nlDs in GET-Requests zur REST-API bei REST-Schnittstellenaufrufen            behoben.                               identifiziert (lbealrestlticketl[SESS/ONID/). Die Logdateien auf höchstem Log-Level #2405: beA-Clieri-Security. Websocket-                                            wurden auf sensible Inhalte untersucht. Schwachstelle wurde behoben. Key in CS-Logs enthalten                                                          Hierbei wurde kein Websocket-Key gefunden. Der Aufbau einer Websocket-Verbindung #2413: beA-Clieri-Security: Fehlender Schw achstelle wurde behoben.          war ohne korrekten Origin-Header nicht Origin-Header wird akzeptiert möglich. Schwachstelle konnte aus Pentestsicht- #2417: beA-Clieri-Security. Keine          weise nicht verifiziert werden. Die A'aktische MTM-Angriffe wurden Überprüfung des Hostnames bei Aufbau       Bewertung aus der Quelltextanalyse evaluiert. der TLS-Verbindung                         steht noch aus bzw . ist nicht abge- schlossen. Schwachstelle konnte aus Pentestsicht- weise nicht verifiziert werden. Die #2418: beA-Clieri-Security. Fehlendes                                             A'aktische MTM-Angriffe wurden Bewertung aus der Quelltextanalyse Zertifikatspinning für beA-Server                                                 evaluiert. steht noch aus bzw . ist nicht abge- schlossen. Die verwendeten Algorithmen RSA und #2419: beA-Cliert-Security-lnstaller: SHA256 mit einer Schlüssellänge von Schwache kryptografische Signaturprü-      Schw achstelle wurde behoben. 2048 Bit sind zeitgemäß und als sicher fung der Update-XM...-Datei zu bewerten. Schwachstelle konnte aus Pentestsicht- #2420: beA-Clieri-Security-lnstaller:      weise nicht verifiziert werden. Die Signaturprüfung der Update-XM...-Datei     Bew ertung aus der Quelltextanalyse nur optional                               steht noch aus bzw. ist nicht abge- schlossen. #2421: beA-Clieri-Security-lnstaller:                                             Die Update-XM... ist nun mit gültigem Veraltete Zertifikate für Signaturprüfung  Schwachstelle wurde behoben.           einem Zertifikat signiert. Die Algorithmen von Java-Komponenten-                                                             RSA und SHA256 mit einer Schlüssel- Version : 1 .0                         Stand : 30 .05.2018                                                           1 Seite 23

Sicherheitsanalyse secunet Beschreibung der                            Behebungsstatus Kommentar secunet Schwachstelle                                Schwachstelle Aktualisierungen                                                                       länge von 2048 Bit sind als zeitgemäß sicher einzustufen. #2423: beA-Cliert-Security. Ticket- System nicht für alle .secure" -                                                       Bei den praktischen Tests wurden Die Bew ertung aus der Quelltextanalyse Kommandos verpflichtend (loadMessa-                                                    diesbezüglich keine Schwachstellen im steht noch aus bzw . ist nicht abge- ge, getFolderOverview, /oadAttachmert,                                                 Rahmen der Businesslogik-Prüfungen schlossen. printMessage, exportMessage,                                                           festgestellt. /oadProcesscard, verifyAttachment) Individuelles lokales Zertifikat für 127.0.0.1/localhostw ird von der beA- #CCC.01: SSL-Zertifikat für bealocal-        Schwachstelle wurde behoben. Siehe Qient-Security generiert und im Browser hast.de korrprorrittiert                     auch Kapitel 6.1.2. hinterlegt. Das Zertifikat ist nicht für bealocalhost.de ausgestellt. Schwachstelle wurde durch obligatori- sehen Origin-Header behoben, die Überprüfung auf eine gültige SessionlD    Der Websocket ist nur teilweise per sollte jedoch konsistenter irrplementiert SessionlD abgesichert, der Wert wird #CCC.02: beA-Client-Securitystartet          werden. Die Prüfung des Origin-Headers    nicht für jeden Befehl geprüft bzw . kann unsicheren Webserver und Websocket           zeigte sich als Schutzmaßnahme            je nach Befehl auch beliebig gesetzt sein. auf lokalem R::>rt (per Javascript auf einer wirkungsvoll, ist jedoch auch von der     secunet sind derzeit keine Methoden beliebigen Webseite angreifbar)              Vertrauenswürdigkeit des Browsers         bekannt, den Origin-Header in Webso- abhängig. Für ein höheres Schutzniveau    cket-Verbindungen durch Javascript- wird errpfohlen, hier den 6nsatz einer    Code im Browser zu manipulieren. Token-basierten Authentisierungslösung zu evaluieren. Siehe auch Kapitel 6.1.2. #CCC.03: beA-Client-Securitynirmt serialisierte Java-Objekte via Websocket Siehe Quelltextanalyse Kapitel 6.1.2.     Siehe Quelltextanalyse Kapitel 6.1.2. entgegen und führt sie aus Uackson readvalue-Funktion) Innerhalb der beA-aient-Security wurden #CCC.05: aient besteht aus stark                                                       kritische Bibliotheken aktualisiert, jedoch Schwachstelle wurde teilw ase behoben. veralteten Paketen (zum Teil aus                                                       existieren weitere und teilweise bereits Siehe Quelltextanalyse Kapitel 6.1.2. 2011/2013)                                                                             neuere vorhandene Updates für verwendete Bibliotheken. Es konnte kein Payload für einen #CCC. 06: XSS-Schw achstelle in der                                                    Mssbrauch der GET-Parameter dswrid Schwachstelle wurde behoben. beA-Webanwendung                                                                       und dswidfür lnjection-Angriffe identifiziert werden. Die SessionlD wurde aus GET-Requests nicht vollständig entfernt. Das Session- Cookie ist nun korrekt parametrisiert #777: Durch Session-Hijacking ist ein                                                  (httponly-F/ag, secure-Rag). Die 6nloggen ohne Authentisierung                Schwachstelle wurde behoben.              SessionlD ist darüber hinaus an kein möglich                                                                                weiteres Merkmal des ordentlich authentifizierten Systems gebunden und kann bei Entwendung für die Übernahme einer Sitzung genutzt werden. Der Aufbau einer Verbindung zum Websocket ist nur noch mit obligatori- schem, korrektem Origin-Header möglich. Eine konkrete Identifikation des Dienstes anhand von Befehlen ist nun #1960: Die beA-Qient-Security-lnstanz Schwachstelle wurde behoben.              ohne SessionlD nicht mehr möglich. ist durch fremde Webseiten erkennbar HTTP-Requests von besuchten Webseiten an den lokalen Dienst können gesendet werden, umz.B. beim versuchten Abruf einer nicht vorhande- nen Ressource eine 404-Antwort zu Version: 1.0                            Stand: 30.05.2018                                                                   1 Seite 24

Sicherheitsanalyse secunet Beschreibung der                         Behebungsstatus Kommentar secunet Schwachstelle                            Schwachstelle erhalten. Die Same-Origin-Policy in Brow sem greift nur für Skriptsprachen und CSS, nichtjedoch für Websockets. Diese rrussen daher den vom Browser gesetzten Origin-Header evaluieren (siehe0efect#2413) . Es konntewährerd der Analyse keine Möglichkeit gefunden werden, auf fremden Webseiten die Präsenz eines lokalen KTlP-Dienstes auf Port 9998 zu bestätigen. Es wird nur noch eine Anmelderraske zeitgleich angezeigt. Es ist jedoch durch #1959: b eA-C/ieri-Securityermöglicht                                     Absenden von n entsprechenden Schw achstellewurde behoben (nit Denial-of-Service-Argriffe                                                Websocket-Befehlen möglich, n Einschränkung) . (Anmelderraske)                                                           hintereinander erscheinende Anmelde- rrasken hervorzurufen, sofern kein Login erfolgt. Der Prozess zum Erkennen und #2358, #2359: beA-Client-Security                                         Beenden von bereits gestarteten beA- ermöglicht Denial-of-Service-Angriffe    Schwachstelle wurde behoben.     Client-Security-lnstanzen wurde (Serviceinstanz beenden)                                                  grundlegend überarbeitet und findet nicht mehr über den Websocket statt. Version : 1 .0                       Stand : 30.05.2018                                                     1 Seite 25

Sicherheitsanalyse secunet 4        Quelltextanalysen 4.1       Rahmenbedingungen 4.1.1    Allgemeines Die im Folgenden identifizierten Schwachstellen sind getrennt nach werkzeug- gestützter statischer Quelltext-Analyse und manuellem Quelltext-Audit identifi- ziert worden. Identifizierte Schwachstellen werden nach Schwachstellentyp unter Angabe der betroffenen Java-Klasse angegeben. Es muss dabei beachtet werden, dass es in Bezug auf die verwendeten Java-Abhängigkeiten viele Überschneidungen innerhalb der einzelnen Korn ponenten gibt. Dabei kann eine Komponenten und Java Klassen mehrfach vorkommen da diese aus unter- schiedlichen Blickwinkeln betrachtet wurden. Ein Teil der gefundenen Schwachstellen wurde während der Projektphase be- hoben und anschließend mittels manueller Nachtests verifiziert. Bibliotheken, die während der Laufzeit vom Application-Server (JBoss EAP) zur Verfügung gestellt werden , konnten nicht betrachtet werden und sind somit nicht Bestand- teil des Review. Dabei handelt es sich nicht nur um JEE-Bibliotheken, sondern auch um Bibliotheken wie die Verschlüsselungsbibliothek BouncyCastle oder die JSF-lmplementierung Primefaces. Die Analyse wurde als Whitebox-Test durchgeführt. Durch den Auftraggeber wurde der Source-Code der Komponenten in unterschiedlichen Versionen be- reitgestellt. 4.1.2    Beschreibung des Analysegegenstandes Im Rahmen der Analyse wurden die beA-Client-Security, die beA-Anwendung sowie die BRAV-Search betrachtet. Die Analysen wurden als Whitebox-Test durchgeführt, das heißt der Auftraggeber hat den relevanten Source-Code und die Dokumentation in unterschiedlichen Versionen bereitgestellt. Die zur Verfü- gung gestellten Sourcen wurden zum einen in Form von lauffähigen Java- Projekten (Client-Security) und zum Teil in Form von *.jar bzw *.war Dateien ausgeliefert. Während Java-Projekte ohne weitere Anpassungen in einer kom- patibelen Build-Umgebung geöffnet und geladen werden konnten, mussten das bei den *.jar bzw. *:war Dateien, wie sie im Rahmen eines Maven-Build-Laufes erzeugt werden, manuell erfolgen. Die beA-Client-Security in Version 3.1.3.6 wurde einer statischen Quell- textanalyse unterzogen. Der Quelltext-Audit sowie die erneuten Tests der zuvor gemeldeten Schwachstellen erfolgten auf Basis der Version 3.1.3.7. Folgende Version: 1.0                Stand : 30 .05 .2018                                         1 Seite 26

Sicherheitsanalyse secunet technische und logische Bereiche der beA-Client-Security wurden nach Abspra- che näher betrachtet. •   Verbindungsaufbau zur beA-Anwendung •   Deserialisierung JSON Objekte am Websocket •   Deserialisierung von XML Dateien Die beA-Anwendung wurde einer statischen Quelltextanalyse unterzogen. Un- tersucht wurden die Version 2.0.10 sowie die Version 2.1 .0. Für die erneuten Tests behobenen Schwachstellen wurde Version 2.1.1 genutzt. Bibliotheken, die während der Laufzeit vom Application-Server (JBoss EAP) zur Verfügung gestellt werden, konnten nicht betrachtet werden und sind somit nicht Bestandteil des Review. Dabei handelt es sich nicht nur um JEE-Bibliotheken, sondern auch um Bibliotheken wie die Verschlüsselungsbibliothek BouncyCast- le oder die JSF-lmplementierung Primefaces. Die BRAV-Search wurde in der Version 1.2.0 einer statischen Quelltextanalyse unterzogen. 4 .1.3   Vorgehensweise und Inhalt der Untersuchung Angewandt wurden werkzeuggestützte statische Quelltextanalyse und ein Quelltext-Audit. Werkzeuggestützte Quelltextanalysen überprüfen den gesamten Java-Quelltext anhand eines vordefinierten Regelwerks. Dieses Regelwerk wurde von der 0- pen-Source-Gemeinde erstellt und wird regelmäßig erweitert und gepflegt. Ab- hängig vom eingesetzten Regelwerk und Werkzeug werden Treffer in unterschiedliche Kategorien eingeordnet. Die Treffer können unsauberem Code bis hin zu schwerwiegenden Schwachstellen umfassen. Nicht jeder Treffer ist zwingend eine Schwachstelle, der eine Bedrohung der IT-Sicherheit darstellt. Die Beurteilung, ob ein Treffer eine Schwachstelle ist, muss durch einen Code Review erfolgen. Konzeptionelle Fehler in der Software Architektur oder dem Programmablauf können in der Regel über dieses Verfahren nicht identifiziert werden. Die Anzahl der Treffer und ihre Einstufung ist nur ein schwacher Indika- tor für Code Qualität. Beim Quelltext-Audit wird im Gegensatz zur statischen Quelltext-Analyse der logische und korrekte Programmablauf überprüft. Werkzeug-Unterstützung, bis auf den Einsatz einer Programmierumgebung, ist nicht vorhanden. Der logische und korrekte Programm-Ablauf wird anhand des geprüften UseCases und des zugehörigen Feinkonzeptes belegt. Logische und software-architektonische Un- zulänglichkeiten können erkannt werden. Alle Schwachstellen, die nicht den lo- gischen Ablauf oder die Software Architektur betreffen, werden nicht näher betrachtet. Vers ion: 1.0                Stand: 30.05.2018                                            1 Seite 27

Sicherheitsanalyse secunet Nach Absprache mit der Bundesrechtsanwaltskammer wurde der Quelltext der beA-Client-Security, BRAV-Search und der beA-Anwendung mittels statischer Quelltextanalyse und einem in Umfang und Tiefe begrenzten Quelltext-Audit für die beA-Client-Security auf Schwachstellen überprüft. Bibliotheken wurden auf Basis ihres Versionstandes nur anhand öffentlich be- kannter Schwachstellen geprüft sowie ihre Verwendung begutachtet. Beim manuellen Audit der beA-Client-Security wurde bedingt durch den Umfang des Quellcodes der Komponenten das Audit auf folgende Funktionsbereiche eingeschränkt werden. • die beA-Client-Security bzgl. Verbindungsaufbau zur beA-Anwendung • Deserialisierung JSON Objekte am Websocket • Deserialisierung von XML Dateien Ausgewählt wurden diese Bereiche wegen ihrer Kritikalität (Wahrscheinlichkeit vs. Auswirkung) und anhand von Erfahrungswerten. 4.2       Identifizierte Schwachstellen Im Folgenden werden die identifizierten Schwachstellen überblicksweise darge- stellt. 4.2.1     Anfällige Java-Bibliotheken Eine Überprüfung der verwendeten Bibliotheken hat für diverse Java Bibliothe- ken bekannte Schwachstellen ergeben. Mt dem Einsatz dieser Bibliotheken ist ein Kompromittieren der beA-Client-Security, beA-Anwendung und BRAV- Search von extern möglich. Die untersuchten Applikationen verwenden Bibliotheken von Drittherstellern, die zum Teil veraltet sind und bekannte Schwachstellen aufweisen. Dabei handelt es sich um Schwachstellen, die • beim Aufbau von SSUTLS gesicherten Verbindungen die Zertifikate unzureichend prüfen und so Man-in-the-Mddle Schwachstellen liefern, • anfällig sind für Java Serialization/Deserialization Attacken, • SSUTLS Verbindungen mit veralteten kryptografischen Verfahren zu- lassen und • anfällig sind für Deny-of-Service Attacken. Für manche Bibliotheken sind gar keine Sicherheitsupdates mehr erhältlich. Folgende geprüften Komponenten wiesen verwundbare Bibliotheken auf: • beA-Client-Security Version : 1.0                  Stand: 30 .05.2018                                              1 Seite 28

Sicherheitsanalyse secunet •   beA-Anwendung •   BRAV-Search Diese Schwachstelle wird als A-Betriebsverhindernde Schwachstelle eingestuft. 4.2.2      Mögliche Ausführung von Schadcode (JSON) Die Serialisierung von Java Objekten wird an diverse Stellen im Code durchge- führt. Eingesetzt wird hierfür folgende Java Bibliothek: jackson-core-2.9.3.jar. Für diese sind derzeit folgende CVE gelistet: •   CVE-2017-17485 (Score 7,5) •   CVE-2018-7489 (Score 7,5) •   CVE-2018-5968 (Score 5.1) {S7}        Die Komponenten sind potentiell verwundbar gegenüber JSON Ja- va-Objekt-Deserialisierung. Die Quelle der JSON-Objekte ist hierbei die beA Anwendungsseite im Browser. Mt der Absicherung der Websocket-Schnittstelle nimmt die beA-Client-Security nur noch JSON-Objekte von der beA Webseite entgegen. (Bedrohung Integrität:               hoch) (Bedrohung Verfügbarkeit:            hoch) (Bedrohung Vertraulichkeit:          hoch) {R6}        Ein authentifizierter Angreifer könnte das System eines Anwenders durch Übergabe modifizierter JSON Daten übernehmen. Ein gleich- zeitiger Angriff auf alle Client-Systeme wäre vorstellbar, wenn es dem Angreifer möglich ist von einer beliebigen Quelle aus JSON- Objekte an die Websocket-Schnittstelle zu versenden. (Wahrscheinlichkeit:                 mittel} {M5}        Es sollte nach alternativen Lösungen für eine kurzfristige Entschär- fung dieser Sicherheitslücke in Betracht gezogen werden. Der Einsatz einer alternativen Bibliothek oder Validierung der JSON Daten. Wie und auf was das validiert werden soll, müsste noch er- arbeitet werden ist aber tendenziell anfällig. (Realisierungszeitraum :           A-Betriebsverhindernde Schwachstelle) Nur die Komponente beA-Client-Security wies diese Schwachstellen auf. Die schwachstellenbehaftete-Bibliothek wurde im laufe des Projektverlaufes durch eine aktuellere Version (2.9.5) ersetzt. Für diese sind derzeit keine Schwachstellen (CVE) bekannt. Version: 1 .0                  Stand: 30.05.2018                                              1 Seite 29

Sicherheitsanalyse secunet 4.2.3       Mögliche Ausführung von Schadcode (XML) Das Deserialisieren von XML-Dateien ist potentiell immer eine Gefahr. Einern An- greifer wäre es möglich über ein manipuliertes XML das System des Anwenders zu kompromittieren. Die XML Spezifikation erlaubt den Download und das Ausführen von externen (z.B. aus dem Internet) Programmen. Hat der Entwickler diesen Sach- verhalt während der Entwicklung nicht berücksichtigt ist es einem Angreifer potenti- ell möglich beim Laden einer manipulierten XML Datei das System des Anwenders zu kompromittieren. Zudem können beim Deserialisieren Schwachstellen der einge- setzten Bibliothek ausgenutzt werden. {S8}        Die Applikationen sind potentiell verwundbar gegenüber XM... Java- Objekt-Deserialisierung. Durch nicht ausreichend Konfigurierte Ja- va-Bibliotheken zum Deserialisierung von XML-Dateien ist es einem Angreifer potentiell möglich das System des Anwenders zu über- nehmen. Es werden ausschließlich XML-Dateien vom beA-Server entgegen genommen. (Bedrohung Integrität:            hoch) (Bedrohung Verfügbarkeit:         hoch) (Bedrohung Vertraulichkeit:       hoch) {R7}        Ein authentifizierter Angreifer könnte an alle Clients modifizierte XML-Dateien schicken und damit den Rechner des Anwenders übernehmen Es ist nicht auszuschließen, dass durch eine Kompromittierten beA Server oder einem Innentäter diese Sicherheitslücke ausgenutzt wird.       Hierdurch   betroffen    wären     alle    Client-Rechner (Wahrscheinlichkeit:              mittel) {tvf>}     Validierung      der XML-Strukturen vor der Deserialisierung. (Realisierungszeitraum:           A-Betriebsverhindernde Schwachstelle) Dieses Finding konnte im Quelltext der beA-Client-Security und der beA- Anwendung nachgewiesen werden. Diese Schwachstelle wurde zwischenzeitlich geschlossen. Die Überprüfung der be- troffenen Quelltext-Zeilen hat ergeben, dass die eingesetzten Bibliotheken so konfi- guriert werden, dass die beschriebenen Schwachstellen der XM...-Objekt Deserialisierung so nicht erneut auftreten können. 4.2.4      Möglicherweise unsicherer Quelltext - Zufallszahlengenerator Die Verwendung von java.util.Random in Zusammenhang mit kryptografischen Funktionen ist ein schwerwiegendes Problem , da schwache Zufallszahlen eine Viel- zahl von Angriffen ermöglichen. Bei der Verschlüsselung sollte der JCE-Provider einen zufälligen Initialisierungsvek- tor generieren. Ein Eingriff (Programmänderung) ist hier nicht erforderlich. Die Quali- Version : 1.0                  Stand : 30.05.2018                                           1 Seite 30