secunet

Technische Analyse und Konzeptprüfung
des beA

Abschlussbericht

n ——
Version: 1.0 \ -_
Stand: 30.05.2018
Bl
\

Sicherheitsanalyse
secunet

Copyright © 2018 by secunet Security Networks AG

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenzeichen usw. in die-
sem Dokument berechtigt auch ohne besondere Kennzeichnung nicht zu der An-
nahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-
Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt wer-
den dürfen. Alle Marken und Produktnamen sind Warenzeichen oder eingetragene
Warenzeichen der jeweiligen Zeichenhalter.

Version: 1.0 Stand: 30.05.2018 Seite 2

Sicherheitsanalyse

secunet

Inhaltsverzeichnis
Technische Analyse und Konzeptprüfung des beA..............uun0u02u0200enensnnennnnnnnnnnennennannunnnnensnn nn 1
Abschlussbericht.................222r202se20r200n0nnnnonnnnnnnnnnnnnsnnnnnenennnnnnonssnnnensonnnnnennnnnnnnnennenesnnnsunnnnenannnnn 1
Inhaltsverzeichnis...............u02u422002002202000n00Rn0n0nnnnnnannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnsnnnnsnnnannenannnn 3
1 Management Summary.....unsrsrsnnsnnsonsnnnonnnenannnnonnnnnannenenorsnnnnssnnsnnnnnnnnnannnnnnnnennanannnnnnnnann 5
1.1 Zielsetzung und Abgrenzung des Betrachtungsgegenstandes .......uununanesnennnnnnennn 5
1.2 Ergebnisse Penetrationstests ..........eseseeseeseresenssnannnnnnnnnnnnnnnnnnnnnannennnnnnnnnennnnnnnnnnen 6
1.3 Ergebnisse Quelltextanalyse .......unenonenennnnnnsennnnnnennnnnnnnnnnnnnnonnnennonnanasnnnnnunnnnnnnnnn 8
1.4 Ergebnisse konzeptionelle Analyse .........unu2uronsonsnnnenonnnnnnnonnonsnnnnansnnnnnnnnnnnnnnnnnnnnnnnn 8
1.5 Resümee und Empfehlung ............ssr2n00n00042000nnsonenennonnennonenensnunnnunnnnnunnunnnnnnnnnnnnnn 10
2 Konventionen im Dokument........uu.u22u42200n20unnnnnssnnnnnnensnnnnnsnnsennnennnnnunnennannnensnnnanenanonnnnnnnnnen 12
3  Penetrationstesis.........unsnsnnennnonnnunsnnennnnnannnnnannannnonnonsnnnsnnennnnnnnnensnnnanennnnennnrannnennannnnanann 14
3.1  Rahmenbedingungen ...........2...222242202220020000200000000000nnnnnnnnsnnnnnannnnannnnnnnnnnsannnannennnnnnn 14
3.1.1 Abgrenzung ..............2@422sre00nnnnnnonnnnnnnnnnnunsnssssnnsnonnnnnannnnnnnnennmennnnnnnnnnasnnnene 14
3.1.2 Beschreibung des Analysegegenstandes ..........unsuu0u0022u@2asnennnneennnnennnenn 15
3.1.3 Vorgehensweise und Inhalte der Untersuchung ..........2.u22220200002002nnn0n 16
3.2  Identifizierte betriebsverhindernde Schwachstellen .................220.200000222020000000nnne» 16
3.2.1  Autorisierungmechanismen: Umgehen des Autorisierungsschemas .... 17
3.2.2 _Autorisierungsmechanismen: Path-Traversal bei Dateiupload .............. 18
3.2.3 _ Session-Management: Parametrisierung der Session-Cookies ............ 19
3.2.4  Verschlüsselungsmechanismen der Kommunikationskanäle ................ 19
3.2.5  Informationssammlung: Applikationsarchitektur ............uunsenenenaneennnnnen 19
3.2.6  Identitätsmanagement: Umgehung des Authentisierungsschemas....... 20
3.3  Identifizierte betriebsbehindernde Schwachstellen ................2.222u200200000000000000000000 21
3.4 _ Verifikation der Behebung gefundener Schwachstellen..............u.2.222u200002000000000.0 22
3.5 Verifikation der Behebung vorab bekannter Schwachstellen.............u0000000000 22
4  Quelltextanalysen.......nnnnssnnnnsnonsnonnnnnnnnennnennnonnnnnnnnnnnnennannnnnnsensensennnnnnnnnnersnunnnnunnnnnnnnnnnnnn 26
4.1 Rahmenbedingungen ..............4220020n000000nnnnnnennennnennennnnnnnnennsnesnnnennnnnnssnannnanunennnsnnnnnn 26
4.1.1 Allgemeines ............ursur000s0onssnoennnnnnenennenensnesnensnennennennnnnsnannnnnnnnnnnnannnennnenn 26
4.1.2 Beschreibung des Analysegegenstandes .............200u@00nnennnnennnnnnnennnnnnn 26
4.1.3 Vorgehensweise und Inhalt der Untersuchung .......cunseuseenesseenennnnnnnnnenenn 27
4.2  Identifizierte Schwachstellen.....................2us2222022222282000200000200000000n00nnnann anne nnnnrannnnen 28
4.2.1  Anfällige Java-Bibliotheken ........ueussunnsnnnnennannnnnannannsnensennnnnnnnnennnnnnnnnnnnnenn 28
4.2.2 Mögliche Ausführung von Schadcode (JSON)........uunneneesssnnnnnennnnnnnnanenn 29
4.2.3 Mögliche Ausführung von Schadcode (XML) ..........uu20uu00sn00nnn00 nn nn nnnnnn 30

Version: 1.0 Stand: 30.05.2018 Seite 3

Sicherheitsanalyse

secunet
4.2.4 Möglicherweise unsicherer Quelltext - Zufallszahlengenerator ............. 30
425 TLS-Zertifikate-Validierung ...................ernnrennnenonnsnnnnnennnnnnennnernnnennn nen 31
4.2.6 Log-Ausgaben ......neeeenoenennnnsernnnannnnnnnennennnnnnnnnenunnnensnnnnnennennersersnanennsnenennon 31
4.2.7 Unfertiger bzw. system-spezifischer Quelltext .............ussesssnsnasersennnenne 32
4.2.8 Eventuelle Ausführung von Datenbankbefehlen (SQL/JPQOL injection). 33
4.2.9 _Unsichere Generierung von iInitialisierungsvektoren.........ueeseneeneneeenene 33
4.2.10 Unsicheres Auffüllen von Daten bei Verschlüsselung... 34
4.3 Durch den CCC gemeldete Schwachstellen ..........suursesnenssnennssnnnennnnnnnernennenennannne 34
43.1  CCC 1: SSL-Zertifikat für bealocalhost.de kompromittiert ........uee 34
4.3.2 _CCC 2: beA-Client-Security startet unsicheren Webserver und
Websocket.....uusnssnsennnnsnennnnnrsonennnennnonnnnnnernannnunmennnnnnsnnensnnnnnnnnnnnnnensnnennnnsnsosnnnnnnn nen 34
4.3.3 CCC 3: beA-Client-Security nimmt serialisierte Java-Objekte via
Websocket entgegen und führt sie aus ..........c..sr0snessnnnonennnnnsonnnennnennensnnnssnanne nen 35
4.3.4 CCC 4: Unterstützte Betriebssysteme sind veraltet ...............- en 35
43.5 CCC5: Client besteht aus stark veralteten Paketen (zum Teil aus
2011/2013) .uueeeaenanesneannnnnnennennnnunnnnnnnnnnnennnennennannnnnssennnnnnssnsnnnnnnnnnsnnensnsnenenerannenennte 35
43.6 CCC 6: XSS-Schwachstelle in der beA-Webanwendung .........ureee- 35
5 _ Konzeptionellen Analyse ...........uneernesenennnnsnnnnnnnnnnnensnsnensennsenessstennnnenennnesnnsnennansersnensennnnn 36
5.1  Rahmenbedingungen. ..............-....srsnrannnnnnnsnennnnnsnnnsnnnnnnnsnnessonnnsnnnerenennensonnannaen 36
5.1.1 Beschreibung des Analysegegenstandes ..............2.40sr0een0nnnnennnnnnnnennans 36
5.1.2 Inhalte der Untersuchung...........2......-.4-4400nn nn nnnnnnnnananssnnnennnnsnnnnnnnnnnnenn 36
5.1.3  Vorgehensweise............ennsonnnnnsnsennnensunnunnenonnunnnnnnnnnnnsnnnsenssnsnnnennannsennann 36
5.1.4 Anmerkungen zu Betriebs- und Sicherheitskonzepten ............ne 43
5.2 _ Identifizierte Schwachstellen in der Konzeption ..............„-„.sussrensesnsnnnnnnsnsonnsnnnane 44
5.21 _BNotK kann Ursprung der Zertifikatsanträge aus HSM nicht erkennen 44
5.2.2 Berechtigungen können nicht entzogen werden .....ersersersnseneneneeenerenennnn 45
5.2.3 Signatur für Rechteweitergabe enthält nicht die Postfach-ID ................ 46
5.2.4 Verwendung von Javascript beim beA_Client ..........unssenessennennnnnnnnennnn 46
525 _EGVP-Bürger-Verzeichniseinträge im SAFE können irreführend sein .. 47
5.2.6 Client prüft Postfachzertifikate nicht ........neernernernnenneneeensensonennennnenenenn 48
5.2.7 HSM-Schlüssel existieren außerhalb des HSM .........nnunsusenrsensnnsnnnnnnnann 49

Version: 1.0 Stand: 30.05.2018 Seite 4

Sicherheitsanalyse
secunet

1 Management Summary

1.1 Zielsetzung und Abgrenzung des Betrachtungsgegenstandes

Die secunet Security Networks AG (secunet) wurde beauftragt, die Umsetzung des
besonderen elektronischen Anwaltspostfachs (beA) hinsichtlich IT-Sicherheit zu
analysieren und zu bewerten. Ziel der Analyse ist, bereits bekannte technische, or-
ganisatorische und konzeptionelle Schwachstellen zu validieren und gegebenenfalls
vorhandene neue Schwachstellen zu identifizieren und zu beurteilen. Im Rahmen
der Untersuchungen wurden neben Penetrationstests ausgewählter beA-
Komponenten und Schnittstellen ebenfalls Quelltextanalysen sowie eine konzeptio-
nelle Analyse durchgeführt.

Im Auftrag war die Erstellung eines Abschlussgutachtens vorgesehen, das mit die-
sem Dokument an die Bundesrechtsanwaltskammer übergeben wird. Das hier vor-
liegende Abschlussgutachten bildet den Stand der Untersuchungen zum Stichtag
28.05.2018 ab. Eine Vielzahl der im Laufe der Analyse erkannten Schwachstellen
wurde bereits im Projektverlauf zur Behebung an den Hersteller bzw. Betreiber des
beA-Systems kommuniziert. Ein Teil der gemeldeten Schwachstellen konnte bereits
vor Erstellung dieses Gutachtens behoben und einem erneuten Test durch secunet
unterzogen werden. Zum Zeitpunkt der Gutachtenbereitstellung ist die Behebung
von Schwachstellen durch den Betreiber noch nicht abgeschlossen. Dementspre-
chend konnten nicht alle erfolgten Maßnahmen einem erneuten Test unterzogen
werden. Der erneute Test der nach dem Stichtag für die Erstellung des Abschluss-
gutachtens behobenen Schwachstellen ist beabsichtigt.

Bei der Lektüre und Nutzung dieses Berichts sind unbedingt folgende Hinweise zu
berücksichtigen:

= Bei allen durchgeführten Tests handelt es sich um stichprobenartige Über-
prüfungen, in denen versucht wird, mit einem vertretbaren Aufwand mög-
lichst viele Schwachstellen innerhalb des Betrachtungsbereichs zu
identifizieren.

= Die vorliegenden Ergebnisse müssen stichtagsbezogen beziehungsweise
bezogen auf einen speziellen Versionsstand aufgefasst werden und enthal-
ten keine Aussagen über die Sicherheit der zukünftigen technischen und
organisatorischen Anpassungen bzw. Lösungen.

= Im Rahmen der Analysen wurde lediglich der wesentliche Teil der für das
beA erforderlichen technischen Komponenten, Schnittstellen oder Anwen-
dungsfälle betrachtet. Es kann somit nicht vollständig ausgeschlossen wer-
den, dass in anderen Teilen weitere nicht erkannte Schwachstellen
vorhanden sind. Es kann auch nicht völlig ausgeschlossen werden, dass
bereits behobene Schwachstellen in zukünftigen Versionen erneut auftre-
ten oder in zukünftigen Versionen neue Schwachstellen implementiert wer-
den. Exemplarisch ist auch zu berücksichtigen, dass die konzeptionelle

Version: 1.0 Stand: 30.05.2018 Seite 5

1.2

Sicherheitsanalyse

secunet

Analyse sich auf die Sicherheitsziele „Vertraulichkeit“ und „Authentizität
konzentriert hat und somit insbesondere eine Betrachtung der „Verfügbar-
keit“ nur am Rande erfolgt ist. Innerhalb der technischen Analysen standen
die beA-Client-Security, die beA-Anwendung und externe Schnittstellen im
Fokus.

= Nicht alle der bis zum Stichtag gefundenen Schwachstellen wurden vollum-
fänglich hinsichtlich ihrer Ausnutzbarkeit, deren Wahrscheinlichkeit und po-
tenzieller eintretender Schäden bewertet. Beispielsweise fand keine
vollständige Betrachtung der technischen und organisatorischen Gegeben-
heiten innerhalb der produktiven Betriebsumgebung, z. B. innerhalb des
Rechenzentrums, statt. Das Ausnutzen einzelner identifizierter Schwach-
stellen kann eventuell durch geeignete technische und organisatorische
Maßnahmen - seitens der BRAK oder des Betreibers — deutlich erschwert
oder sogar vereitelt werden. Umgekehrt können aber auch Schäden durch
fehlende bzw. ungeeignete technische und/oder organisatorische MaßR-
nahmen entstehen. Die vorgelegten grundlegenden Konzepte zur IT-
Sicherheit (Sicherheitskonzept, Betriebskonzept etc.) ermöglichten keine
abschließende Einschätzung.

= Darüber hinaus war es erforderlich, Annahmen zu treffen und Abgrenzun-
gen des Betrachtungsgegenstandes vorzunehmen, damit der Aufwand ins-
gesamt vertretbar blieb. Beispielsweise wurden der von einem Anwalt
genutzte Rechner und dessen Einsatzumgebung als hinreichend abgesi-
chert angesehen. Die Absicherung des Anwaltsrechners sowie der Ein-
satzumgebung war dementsprechend nicht Gegenstand der Untersuchung.

= Auch eine Analyse, ob die beA-Lösung alle rechtlichen und funktionalen
Anforderungen erfüllt, war nicht Gegenstand der Betrachtung.

Es ist möglich, dass einzelne identifizierte Schwachstellen von Dritten nachvollzo-
gen und ausgenutzt werden können, auch wenn sie bereits behoben wurden, z.B.
bei nicht erfolgter Deinstallation älterer Versionen der beA-Client-Security. Außer-
dem könnten durch die Darstellung von detaillierten technischen Informationen
Rechte Dritter verletzt werden, z.B. durch Angabe von Quellcode, oder schützens-
werte Informationen aufgedeckt werden, wie z.B. IP-Adressen. Aus diesem Grund
werden die Schwachstellen in diesem Gutachten ohne Angabe von detaillierten
technischen Informationen dargestellt. Die detaillierten technischen und inhaltlichen
Informationen zu den einzelnen Schwachstellen werden zu deren gezielter Behe-
bung laufend an die BRAK übermittelt.

Die Inhalte und Ergebnisse der bisherigen Analysen werden in den folgenden Un-
terabschnitten 1.2 bis 1.5 überblicksweise dargestellt und in den Kapiteln 3 bis 5
ausführlicher erläutert.

Ergebnisse Penetrationstests

Die secunet hat im Auftrag der Bundesrechtsanwaltskammer (BRAK) zwischen Feb-
ruar und Mai 2018 Penetrationstests ausgewählter Systeme durchgeführt. Ziel die-

Version: 1.0 Stand: 30.05.2018 Seite 6

Sicherheitsanalyse
secunet

ser Tests war es, sicherheitsrelevante Schwachstellen zu identifizieren und zu be-
werten. Die Analyse wurde angelehnt an den OWASP (Open Web Application
Security Project) Testing-Guide durchgeführt. Darüber hinaus wurden systematisch
weitere Aspekte analysiert, welche die OWASP-Testfälle in Bezug auf die jeweilige
Anwendungsarchitektur erfahrungsgemäß sinnvoll ergänzen.

Zunächst wurde die beA-Systemumgebung erfasst und in zwei Untersuchungsge-
genstände separiert. Innerhalb der ersten Phase bis Ende März 2018 wurde die
beA-Client-Security mitsamt den Kommunikationsendpunkten zur beA-Anwendung
betrachtet. In der zweiten Phase wurden darüber hinaus externe Schnittstellen
(Webservices, Webportale und eine weitere Client-Software) analysiert, die im
Rahmen des beA-Betriebs bereitgestellt werden.

In der ersten Analysephase konnten verschiedene Schwachstellen identifiziert wer-
den, durch die das Rechtekonzept der beA-Anwendung umgangen werden und auf
teilweise sensible Metadaten von Nachrichten-Anhängen Dritter zugegriffen werden
kann. Für die Konfiguration der Transportsicherung wurde Verbesserungsbedarf er-
kannt. Die Übernahme einer Benutzersitzung innerhalb der beA-Anwendung wird
durch ein potenzielles Abspeichern der Sitzungsinformationen in Log-Dateien er-
leichtert. Zudem konnte festgestellt werden, dass der beA-Anwendungsserver unau-
torisiert als globale „Drop-Box“ für beliebige Inhalte missbraucht werden kann.

In der zweiten Analysephase konnten weitere Schwachstellen identifiziert werden.
Die Implementierungen einiger Webservices zeigten sich anfällig für Signature-
Wrapping-Schwachstellen, die einem Man-in-the-Middle-Angreifer das Manipulieren
der übertragenen Daten ermöglichen können. Das kann z. B. dazu führen, dass die
Gültigkeit von qualifizierten Signaturen falsch angezeigt wird. Der RAK-Client, als
auch der entsprechende Server bzw. Webservice, mit dem bidirektional Dateien
ausgetauscht werden können, sind verwundbar für sogenannte Path-Traversal-
Angriffe. Diese können es Angreifern durch Manipulation der innerhalb einer TLS-
Verbindung übertragenen Parameter und Attachments erlauben, beliebige Dateien
an beliebigen Speicherorten im Dateisystem des Clients oder des Servers abzule-
gen. Dies erlaubt unter Umständen die Übernahme der Kontrolle über den Anwalt
PC oder eine betroffenen Server im beA-System. Weiterhin wurde festgestellt, dass
innerhalb der Kanzleisoftware-Schnittstelle die Namen von Dateianhängen unver-
schlüsselt übertragen werden. Insgesamt wurden in beiden Analysephasen zehn
betriebsverhindernde, achtzehn betriebsbehindernde und vierundzwanzig sonstige
Schwachstellen identifiziert.

Während der zweiten Phase wurden sechs betriebsverhindernde, sechs betriebsbe-
hindernde und eine sonstige Schwachstelle behoben und deren Behebung verifi-
ziert. Zwei betriebsbehindernde Schwachstellen und eine sonstige Schwachstelle
wurden nur teilweise behoben. Eine Schwachstelle bezüglich der Härtung von TLS-
Verbindungen wurde nach Rücksprache mit allen Beteiligten aufgrund der aktuellen
Entwicklung technischer Standards nicht überprüft. Die weitere Überprüfung beho-
bener Schwachstellen ist vorgesehen, wobei darunter mindestens zwei betriebsver-
hindernde Schwachstellen offen sind.

Version: 1.0 Stand: 30.05.2018 Seite 7

1.3

1.4

Sicherheitsanalyse

secunet

Ergebnisse Quelltextanalyse

Die beA-Anwendung, beA-Client-Security und die BRAV-Search wurden einer werk-
zeuggestützten, statischen Quelltextanalyse-Analyse unterzogen. Für die beA-
Client-Security wurde darüber hinaus ein Quelltext-Audit vorgenommen, bei dem
der als kritisch identifizierte Teile der beA-Client-Security geprüft und der korrekte
Programmablauf nachvollzogen wurde. Quelltext-Analyse und -Audit können
Schwachstellen in Software erkennen, die mit Werkzeugen des Penetrationstests
nicht entdeckt werden können.

Die statische Quelitext-Analyse hat in der Summe folgende Treffer mit unterschiedli-
chen Einstufungen erbracht: beA-Client-Security 337 Treffer, beA-Anwendung ca.
1000 Treffer und BRAV-SEARCH 85 Treffer.

Die Anzahl der Treffer an sich erlaubt keinen Rückschluss auf die Quelltext-Qualität.
Die Gewichtung der Treffer erstreckt sich von ‚eher‘ kleineren Unsauberkeiten bis
hin zu potentiell gravierend eingestuften Mängeln. Eine Betrachtung wurde nur von
den im verwendeten Analysetool höher eingestuften Treffern vorgenommen.

Dabei wurden Schwachstellen gefunden, von denen drei als betriebsverhindernd
eingestuft wurden, weil sie potentiellen Angreifer Angriffswege anbieten, die mit be-
kannten Techniken ausnutzbar sind und dem Angreifer ermöglichen können, die
Kontrolle über die angegriffenen Systeme zu übernehmen. Diese Schwachstellen
wurden in der Zwischenzeit beseitigt. Detailliert beschrieben werden die gefundenen
Schwachstellen in Kapitel 4.

Im Rahmen der Quelitext-Analyse (teilweise unterstützt durch die Penetrationstests)
wurden auch die vom Chaos Computer Club e. V. (CCC) bemängelten Schwach-
stellen überprüft, die in der vorliegenden Fassung von beA-Client-Security und beA-
Anwendung nicht mehr vorhanden sind.

Ergebnisse konzeptionelle Analyse

Gegenstand der konzeptionellen Analyse waren wesentliche Sicherheitsfunktionen
des beA, die dem Schutz von Vertraulichkeit und Authentizität der via beA über-
mittelten Nachrichten dienen.

Es wurde in der ersten Phase geprüft, ob der erforderliche Schutz der Vertraulich-
keit der Nachrichten durch das implementierte Verschlüsselungskonzept erreicht
wird, das ganz wesentlich darauf beruhen soll, dass alle kryptographischen Operati-
onen zum Schutz der Vertraulichkeit von Nachrichten in HSM gekapselt sind und
Nachrichten nicht außerhalb der HSM entschlüsselt werden können.

Durchgeführt wurde eine Analyse nach Dokumentenlage, insbesondere durch Aus-
wertung der relevanten UseCases (Ablaufbeschreibungen für bestimmte fachliche
Vorgänge im beA). Des Weiteren wurden das Feinkonzept HSM und andere Fein-
konzepte analysiert. Die Ergebnisse der Analyse wurden gemeinsam mit dem Be-
treiber und der BRAK im Rahmen von Telefonkonferenzen erörtert und verifiziert.

Version: 1.0 Stand: 30.05.2018 Seite 8

Sicherheitsanalyse
secunet

Durch die Analyse konnten sieben betriebsverhindernde Schwachstellen identifiziert
werden, die ein Angreifer ausnutzen kann, um sich unbefugten Zugang zu Nachrich-
ten zu verschaffen. Allen Schwachstellen ist gemeinsam, dass die HSM keinen oder
keinen ausreichenden Schutz vor diesen Angriffen bieten, d.h. Nachrichten bei er-
folgreichem Angriff auch außerhalb der HSM entschlüsselt werden können. Fast al-
len konzeptionellen Schwachstellen ist allerdings auch gemeinsam, dass sie nur
durch oder mit Hilfe von Innentätern, darunter auch Personen mit besonderer Ver-
trauensstellung, durchgeführt werden können. Diese Eigenschaft beschränkt den
Kreis potentieller Angreifer neben böswilligen Innentätern auf solche, die über aus-
reichende Mittel verfügen, um Innentäter z. B. durch Bestechung zur Mithilfe zu be-
wegen. Die Bedrohung ist daher zunächst gering, wächst aber stark, sobald das
beA intensiv für den elektronischen Rechtsverkehr genutzt wird und dann viele sehr
wertvolle Informationen transportiert und speichert, die einen Angriff mit erheblichen
Investitionen bzw. Risiken für Innentäter rechtfertigen.

Das mit Blick auf den Schutz der Vertraulichkeit von Nachrichten schwerwiegendste
Ergebnis ist, dass alle kryptographischen Schlüssel, die in den HSM verwendet
werden, auch außerhalb der HSM bei der BRAK vorliegen bzw. aus diesen Schlüs-
seln abgeleitet werden können und dass nicht nachgewiesen wurde, dass dem Be-
treiber, der die Schlüssel erzeugt, die Schlüssel nicht auch bekannt sind. Die
Schlüssel sollen ausschließlich dazu dienen, bei höherer Last des beA-Systems o-
der Ausfall eines HSM weitere HSM für das beA in Betrieb zu nehmen. Doch durch
ihre Existenz außerhalb der HSM können sie Gegenstand von missbräuchlicher
Nutzung werden, um alle im beA-System gespeicherten Nachrichten auch ohne
HSM entschlüsseln zu können. Die Nutzer des beA müssen daher dem Betriebs-
personal des beA und der BRAK dahingehend vertrauen, dass diese nicht von der
Möglichkeit der Nachrichtenentschlüsselung Gebrauch machen, und müssen darauf
vertrauen, dass physikalisch-organisatorische Schutzmaßnahmen hinreichend si-
cher sind, um auch einen Missbrauch durch Dritte auszuschließen. Bei Ende-zu-
Ende-Sicherheit ist durch technische Maßnahmen (insbesondere Kryptographie) mit
hinreichender Sicherheit ausgeschlossen, dass Dritte Einblick in die übertragenen
Nachrichten nehmen können. Das ist beim beA-System nicht der Fall. Daher kann
beim beA-System nicht von Ende-zu-Ende-Sicherheit gesprochen werden.

Für die Details und die Beschreibung der weiteren konzeptionellen Schwachstellen
wird auf den ausführlicheren Statusbericht zur konzeptionellen Analyse verwiesen.
Alle Schwachstellen scheinen behebbar.

In der zweiten Phase der konzeptionellen Analyse wurden vom Betreiber neu er-
stellte Konzepte begutachtet, z. B. Kryptokonzept, Betriebshandbuch und verschie-
dene Sicherheitskonzepte. Die vorgelegten Dokumente sind einzeln und in ihrer
Gesamtheit nicht geeignet, die Sicherheit der beA-Anwendung nachzuweisen. Die
Dokumentenlage wird als betriebsbehindernd eingeschätzt.

Version: 1.0 Stand: 30.05.2018 Seite 9

1.5

Sicherheitsanalyse
secunet

Resümee und Empfehlung

Im Rahmen der Analyse wurden die wichtigsten Komponenten, Schnittstellen, An-
wendungsfälle und vorliegenden Dokumente berücksichtigt. Die Bewertung der ge-
fundenen Schwachstellen erfolgt, wie in der BRAK praktiziert, in den drei Stufen
„betriebsverhindernd“, „betriebsbehindernd“ und „sonstige“:

A-Betriebsverhindernde Schwachstelle
Die Behebung vor Wiederinbetriebnahme wird dringend empfohlen.

B-Betriebsbehindernde Schwachstelle
Die Behebung vor Wiederinbetriebnahme oder sehr zeitnah danach wird empfohlen.

C-Sonstige Schwachstelle
Lediglich unerhebliche Auswirkung auf den Betrieb, eine Behebung kann später erfolgen.

 

Im Rahmen der Penetrationstests wurden insgesamt 52 Schwachstellen gefunden.
Davon wurden zehn Schwachstellen als betriebsverhindernd und 18 als betriebsbe-
hindernd klassifiziert. Davon konnten zum Zeitpunkt des Gutachtens fünf betriebs-
verhindernde und vier betriebsbehindernde Schwachstellen nach Behandlung durch
den Betreiber erneut getestet und als geschlossen festgestellt werden.

Innerhalb der Quellcodeanalysen wurden insgesamt zehn Schwachstellen gefun-
den. Davon wurden drei Schwachstellen als betriebsverhindernd und sechs als be-
triebsbehindernd klassifiziert. Davon konnten zum Zeitpunkt des Gutachtens alle
betriebsverhindernden Schwachstellen nach Behandlung durch den Betreiber er-
neut getestet und als geschlossen festgestellt werden.

Die konzeptionelle Analyse hat sieben betriebsbehindernde Schwachstellen aufge-
zeigt. Zusätzlich hat sich die sicherheitsrelevante Dokumentation als unzureichend
für die abschließende Beurteilung der IT-Sicherheit erwiesen.

Insbesondere auf Grundlage der identifizierten betriebsverhindernden Schwachstel-
len wird empfohlen, die beA-Anwendung erst nach deren vollständiger Beseitigung
wieder in Betrieb zu nehmen.

Darüber hinaus empfehlen wir ebenfalls, die als „betriebsbehindernd“ eingestuften
Schwachstellen vor Wiederinbetriebnahme bzw. recht zeitnah danach zu beheben.
Dieser Empfehlung liegen folgende Überlegungen zugrunde:

s Insbesondere die im Rahmen der Penetrationstests und Quellcodeanaly-
sen identifizierten Schwachstellen können auch durch außenstehende Drit-
te identifiziert und ggf. ausgenutzt werden.

= Besonders einzelne konzeptionelle Schwachstellen, obwohl als betriebs-
behindernd eingestuft sind unter dem Blickwinkel einer flächendeckenden,
intensiven und ggf. zukünftig verpflichtenden Nutzung des beA und der
damit einhergehenden vorübergehenden zentralen Speicherung sehr um-

Version: 1.0 Stand: 30.05.2018 Seite 10