HTTP 200 OK
Allow: GET, PUT, PATCH, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept
{
"resource_uri": "https://fragdenstaat.de/api/v1/document/7551/",
"id": 7551,
"site_url": "https://fragdenstaat.de/dokumente/7551-pe-18-anlage1/",
"title": "pe-18-anlage1",
"slug": "pe-18-anlage1",
"description": "",
"published_at": null,
"num_pages": 92,
"public": true,
"listed": true,
"allow_annotation": false,
"pending": false,
"file_url": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/pe-18-anlage1.pdf",
"file_size": 1484341,
"cover_image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p1-small.png",
"page_template": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p{page}-{size}.png",
"outline": "",
"properties": {
"title": null,
"author": "-",
"creator": "Microsoft® Word 2010",
"subject": null,
"producer": "Microsoft® Word 2010",
"_format_webp": true
},
"uid": "9741c360-2161-4f71-ab5e-3e5a1ee8c237",
"data": {},
"pages_uri": "/api/v1/page/?document=7551",
"original": null,
"foirequest": null,
"publicbody": null,
"last_modified_at": "2020-10-04 12:02:25.798984+00:00",
"pages": [
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 1,
"content": "Technische Analyse und Konzeptprüfung des beA Abschlussgutachten im Auftrag der Bundesrechtsanwaltskammer Körperschaft des öffentlichen Rechts Littenstraße 9 10179 Berlin Version: 1.0 Stand: 18.06.2018",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p1-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 2,
"content": "Technische Analyse und Konzeptprüfung des beA 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.",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p2-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 3,
"content": "Technische Analyse und Konzeptprüfung des beA Inhaltsverzeichnis Inhaltsverzeichnis .................................................................................................................. 3 Abbildungsverzeichnis ........................................................................................................... 6 Tabellenverzeichnis ............................................................................................................... 7 1 Management Summary ................................................................................................. 8 1.1 Zielsetzung .......................................................................................................... 8 1.2 Ergebnisse der Penetrationstests ........................................................................ 9 1.3 Ergebnisse der Quelltextanalyse ........................................................................10 1.4 Ergebnisse konzeptionelle Analyse ....................................................................11 1.5 Resümee und Empfehlung .................................................................................13 1.6 Abgrenzung ........................................................................................................14 2 Verfahren zur Schwachstellenbewertung ......................................................................16 2.1 Darstellungsform ................................................................................................16 2.2 Schwachstelle ....................................................................................................17 2.3 Risikobewertung.................................................................................................17 2.3.1 Ausnutzbarkeit ......................................................................................18 2.3.2 Bedrohung ............................................................................................18 2.3.3 Bestimmung des Risikos ......................................................................21 2.4 Maßnahme .........................................................................................................23 2.5 Angaben zum Status der Schwachstellenbehebung ...........................................23 3 Detailergebnisse der Penetrationstests.........................................................................24 3.1 Beschreibung des Analysegegenstandes ...........................................................24 3.2 Rahmenbedingungen und Abgrenzung ..............................................................28 3.3 Methodik und Vorgehensweise ..........................................................................28 3.4 Übersicht der Schwachstellen ............................................................................30 3.5 Beschreibung der A-Schwachstellen ..................................................................32 3.5.1 Nicht autorisiertes File-Sharing .............................................................32 3.5.2 Auslesen von Metadaten fremder Nachrichtenanhängen......................33 3.5.3 Modifikation von signierten Nachrichten ...............................................35 3.5.4 Veraltete Softwareelemente .................................................................36 3.6 Beschreibung der B-Schwachstellen ..................................................................37 3.6.1 Veraltete Javascript-Bibliotheken in der beA-Anwendung .....................38 3.6.2 Überschreiben von Dateien ..................................................................39 3.6.3 Session-ID als GET Parameter in der URL ...........................................40 3.6.4 Transportverschlüsselung der beA-Anwendung: Client-TLS- Renegotiation .....................................................................................................40 3.6.5 Transportverschlüsselung der beA-Client-Security: Client-TLS- Renegotiation .....................................................................................................41 3.6.6 Transportverschlüsselung der beA-Client-Security: Logjam ..................42",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p3-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 4,
"content": "Technische Analyse und Konzeptprüfung des beA 3.6.7 Detaillierte Fehlermeldungen der Webapplikationsfirewall ....................43 3.6.8 Schwache Lock-Out-Mechanismen in der beA-Anwendung .................44 3.6.9 Qualität der genutzten Session-Cookies ...............................................45 3.6.10 Automatisches Ausführen und Öffnen von Dateien...............................46 3.6.11 Modifikation von signierten XML-Nachrichten .......................................48 3.6.12 Logdaten: Detaillierte Struktur der REST-Endpunkte ............................48 3.6.13 Nicht konsistente Zertifikatsprüfung ......................................................49 3.7 Auflistung der C-Schwachstellen ........................................................................51 4 Quelltextanalysen .........................................................................................................53 4.1 Beschreibung des Analysegegenstandes ...........................................................53 4.2 Methodik und Vorgehensweise ..........................................................................53 4.3 Übersicht der Schwachstellen ............................................................................54 4.4 Beschreibung der A-Schwachstellen ..................................................................56 4.4.1 beA-Anwendung - Mögliche Ausführung von Schadcode (XML) ...........56 4.4.2 Java-Abhängigkeiten mit bekannten Schwachstellen ...........................57 4.4.3 Mögliche Ausführung von Schadcode in der beA-Client-Security (JSON) 59 4.4.4 Mögliche Ausführung von Schadcode in der beA-Client-Security (XML) 60 4.4.5 Verwendete Bibliotheken der beA-Client-Security.................................62 4.4.6 Verwendete Bibliotheken in der BRAV-Suche ......................................63 4.5 Beschreibung der B-Schwachstellen ..................................................................64 4.5.1 beA-Anwendung: SQL-Injection............................................................64 4.5.2 Initialisierungs-Vector (IV).....................................................................66 4.5.3 Unsicheres Auffüllen von Daten bei Verschlüsselung ...........................67 4.5.4 TLS-Zertifikate-Validierung ...................................................................68 4.6 Auflistung der C-Schwachstellen ........................................................................70 4.7 Durch den CCC gemeldete Schwachstellen .......................................................70 4.7.1 CCC 1: SSL-Zertifikat für bealocalhost.de kompromittiert .....................70 4.7.2 CCC 2: beA-Client-Security startet unsicheren Webserver und Websocket .........................................................................................................71 4.7.3 CCC 3: beA-Client-Security nimmt serialisierte Java-Objekte via Websocket entgegen und führt sie aus ..............................................................71 4.7.4 CCC 4: Unterstützte Betriebssysteme sind veraltet ..............................71 4.7.5 CCC 5: Client besteht aus stark veralteten Paketen (zum Teil aus 2011/2013) .........................................................................................................71 4.7.6 CCC 6: XSS-Schwachstelle in der beA-Webanwendung ......................71 5 Konzeptionelle Analyse ................................................................................................72 5.1 Beschreibung des Analysegegenstandes ...........................................................72 5.1.1 Form des Analysegegenstands und Betrachtungsweise .......................72 5.1.2 Inhaltliche Beschreibung des Analysegegenstands ..............................72 5.2 Methodik und Vorgehensweise ..........................................................................78 5.3 Übersicht der Schwachstellen ............................................................................79 5.4 Beschreibung der A-Schwachstellen ..................................................................80 5.4.1 Verwendung von Javascript beim beA_Client .......................................80 5.4.2 Client prüft Postfachzertifikate nicht ......................................................81 5.5 Beschreibung der B-Schwachstellen ..................................................................83",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p4-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 5,
"content": "Technische Analyse und Konzeptprüfung des beA 5.5.1 BNotK kann Ursprung der Zertifikatsanträge aus HSM nicht erkennen .83 5.5.2 EGVP-Bürger-Verzeichniseinträge im SAFE können irreführend sein ..84 5.5.3 HSM-Schlüssel existieren außerhalb des HSM ....................................86 5.6 Auflistung der C-Schwachstellen ........................................................................88 5.7 Anmerkungen zu Betriebs- und Sicherheitskonzepten .......................................89",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p5-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 6,
"content": "Technische Analyse und Konzeptprüfung des beA Abbildungsverzeichnis Abbildung 1: Externe Architektur des beA-Zentralsystem .....................................................25 Abbildung 2: Anhang test.txt .................................................................................................34 Abbildung 3: Anhang xjustiz_nachrict.xml ............................................................................34 Abbildung 4: Session-Cookie-Entropie, Quelle: Burp Suite Professional ..............................45 Abbildung 5: Postfach einrichten ..........................................................................................73 Abbildung 6: Management von Administrations- und Leserechten .......................................74 Abbildung 7: Ablage von Nachrichten im beA .......................................................................75 Abbildung 8: Abruf von Nachrichten (Teil 1) .........................................................................76 Abbildung 9: Abruf von Nachrichten (Teil 2) .........................................................................77",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p6-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 7,
"content": "Technische Analyse und Konzeptprüfung des beA Tabellenverzeichnis Tabelle 1: Darstellungsform C-Schwachstellen ....................................................................17 Tabelle 2: Beispielkriterien zur Bestimmung der Ausnutzbarkeit ...........................................18 Tabelle 3: Einstufung Vertraulichkeit ....................................................................................19 Tabelle 4: Einstufung Integrität .............................................................................................20 Tabelle 5: Einstufung Verfügbarkeit ......................................................................................21 Tabelle 6: Bewertung des Risikos ........................................................................................22 Tabelle 7: Externe Schnittstellen und analysierte Versionen im beA ....................................27 Tabelle 8: Schwachstellenübersicht Penetrationstests .........................................................30 Tabelle 9: Pentest C-Schwachstellen ...................................................................................51 Tabelle 10: Schwachstellenübersicht Quelltextanalysen.......................................................54 Tabelle 11: Bibliotheken mit Schwachstellen (beA-Client-Security) ......................................62 Tabelle 12: Bibliotheken mit Schwachstellen (BRAV-Suche) ................................................63 Tabelle 13: Quelltext C-Schwachstellen ...............................................................................70 Tabelle 14: Schwachstellenübersicht Konzeptanalyse .........................................................79 Tabelle 15: Konzept C-Schwachstellen ................................................................................88 Version: 1.0 Stand: 18.06.2018 Seite 7",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p7-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 8,
"content": "Technische Analyse und Konzeptprüfung des beA 1 Management Summary 1.1 Zielsetzung Die secunet Security Networks AG (secunet) wurde von der Bundesrechtsanwalts- kammer (BRAK) beauftragt, die Umsetzung des besonderen elektronischen An- waltspostfachs (beA) hinsichtlich IT-Sicherheit zu analysieren und zu bewerten. Ziel der Analyse ist, bereits bekannte technische, organisatorische und konzeptio- nelle Schwachstellen zu validieren und gegebenenfalls vorhandene neue Schwach- stellen zu identifizieren und zu beurteilen. Im Rahmen der Untersuchungen von Februar bis Ende Mai 2018 wurden neben Penetrationstests ausgewählter beA-Komponenten und Schnittstellen ebenfalls Quelltextanalysen sowie eine konzeptionelle Analyse durchgeführt. Der Auftrag sieht die Erstellung eines Abschlussgutachtens vor, das mit diesem Do- kument an die Bundesrechtsanwaltskammer übergeben wird. Das hier vorliegende Abschlussgutachten bildet den Stand der Untersuchungen zum Stichtag 28.05.2018 ab. Die im Laufe der Analyse erkannten Schwachstellen wurden soweit möglich, be- reits vor der Fertigstellung des Gutachtens an den Betreiber kommuniziert. Ein Teil dieser gemeldeten Schwachstellen konnte bereits vor Erstellung dieses Gutachtens behoben und einem erneuten Test (ReTest) durch den Gutachter unterzogen wer- den. Zum Stichtag ist die Behebung von Schwachstellen durch den Betreiber oder ihr erneuter Test (ReTest) noch nicht abgeschlossen. Der ReTest aller vom Betrei- ber behobenen Schwachstellen ist beabsichtigt. Im Rahmen der Analyse wurden die für die Sicherheit wichtigen Komponenten, Schnittstellen, Anwendungsfälle und vorliegenden Dokumente berücksichtigt. Die Bewertung der gefundenen Schwachstellen erfolgt angelehnt an die in dem Fehler- managementsystem des Betreibers verwendeten Stufen „betriebsverhindernd“, „be- triebsbehindernd“ und „sonstige“: A - Betriebsverhindernde Schwachstelle Die Behebung vor Wiederinbetriebnahme wird dringend empfohlen. B - Betriebsbehindernde Schwachstelle Eine Behebung sobald wie möglich wird empfohlen. C - Sonstige Schwachstelle Lediglich unerhebliche Auswirkungen auf den Betrieb sind zu erwarten, eine Behebung wird empfohlen, soweit dies mit verhältnismäßigem (am möglichen Schaden bemessenen) Aufwand möglich ist. Version: 1.0 Stand: 18.06.2018 Seite 8",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p8-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 9,
"content": "Technische Analyse und Konzeptprüfung des beA Die Risikobewertung wurde aus technischer Sicht vorgenommen. Dabei gingen die Menge der potentiellen Angreifer, die Komplexität des Angriffs und die Schäden durch einen erfolgreichen Angriff in die Risikobewertung ein. Die mögliche Motivati- on der Angreifer (ihre Bereitschaft, die erforderlichen Mittel für einen Angriff aufzu- bringen und die erforderlichen Risiken einzugehen) wurde mangels Schätzbarkeit nur sehr grob berücksichtigt. Sie ist allerdings ein Faktor, der die Eintrittswahr- scheinlichkeit eines erfolgreichen Angriffs beeinflusst und bei genauerer Berücksich- tigung die Risikobewertung verändern kann. Eine fachliche Sicht (z.B. Bewertung der Bedeutung eines Verlustes von Vertraulichkeit aus juristischer Sicht) von beA- Betreiber und -Anwenderseite kann mögliche Schäden oder ihre Eintrittswahr- scheinlichkeit und damit das Risiko ebenfalls anders bewerten. Das Verfahren zur Risikobewertung ist in Kapitel 2 dargestellt. Die Inhalte und Ergebnisse der Analysen werden in den folgenden Unterabschnitten 1.2 bis 1.4 überblicksweise dargestellt und in den Kapiteln 3 bis 5 ausführlich erläu- tert. 1.2 Ergebnisse der Penetrationstests In dem Analysezeitraum konnten zusammenfassend Schwachstellen in den nach- folgenden Ausprägungen identifiziert werden: ■ A - Betriebsverhindernd: 4 Schwachstellen 2 behoben ■ B - Betriebsbehindernd: 13 Schwachstellen 4 behoben ■ C - sonstige Fehler: 19 Schwachstellen 2 behoben Bei den identifizierten betriebsverhindernden Schwachstellen handelt es sich um die nachfolgend kurz aufgeführten Schwachstellen: ■ Nicht autorisiertes File-Sharing (behoben) Angreifer können die beA-Anwendung als einfachen „Cloud-Dienst“ nutzen um dort beliebige Daten, ggf. auch mit krimineller Absicht, abzulegen und zu einem späteren Zeitpunkt wieder herunterzuladen. ■ Auslesen von Metadaten fremder Nachrichtenanhänge (behoben) Innerhalb der beA-Anwendung angemeldete Angreifer können auf ver- schlüsselte Anhänge von verschlüsselten Nachrichten Dritter zugreifen. Dadurch wird das Rollenkonzept des beA umgangen und Metadaten können eingesehen werden. Die Verschlüsselung selbst kann dadurch zwar nicht überwunden werden, aber auch die einsehbaren Metadaten können z.B. in den Bezeichnungen für Anhänge sensible Informationen offenbaren. ■ Modifikation von signierten XML-Nachrichten Signaturen können umgangen und so XML-Nachrichten manipuliert werden. Diese Schwachstelle wurde in zwei Schnittstellen gefunden, von denen eine kritisch ist, weil dort Gültigkeitsaussagen zu qualifizierten Signaturen ver- Version: 1.0 Stand: 18.06.2018 Seite 9",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p9-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 10,
"content": "Technische Analyse und Konzeptprüfung des beA fälscht werden könnten. Die Ausnutzung ist aber nur Innentätern im beA- Betrieb und Angreifern, die erfolgreich beA-Teilkomponenten unter ihre Kon- trolle gebracht haben, möglich. ■ Veraltete Softwareelemente in der beA-Client-Security Es werden Softwareelemente verwendet, die Sicherheitsupdates erfordern. Des Weiteren konnten durch zeitnahe Meldungen des Gutachters während des Analysezeitraums bereits 8 Schwachstellen durch den Betreiber behoben und durch ReTests als tatsächlich gegenüber der gemeldeten Schwachstelle als geschlossen verifiziert werden. Eine detaillierte Auflistung der gefundene Schwachstellen und der durchgeführten ReTests findet sich in den Detailergebnissen in Abschnitt 3 wieder. Dort werden auch der Analysegegenstand und die Vorgehensweise beschrieben. 1.3 Ergebnisse der Quelltextanalyse Die beA-Anwendung, beA-Client-Security und die BRAV-Search wurden einer werk- zeuggestützten, statischen Quelltextanalyse unterzogen. Für die beA-Client-Security wurde darüber hinaus ein Quelltext-Audit vorgenommen, bei dem die als kritisch identifizierte Teile der beA-Client-Security geprüft und der korrekte Programmablauf nachvollzogen wurde. Quelltext-Analyse und -Audit können Schwachstellen in Soft- ware erkennen, die mit Werkzeugen des Penetrationstests nicht entdeckt werden können. Die statische Quelltext-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. Mit Hilfe der statischen Quelltext-Analyse und des Quelltext-Audits wurden sechs als betriebsverhindernd eingestufte Schwachstellen gefunden. Dies bieten Angrei- fern potentielle Angriffswege an, die mit bekannten Techniken ausnutzbar sind und dem Angreifer ermöglichen, die Kontrolle über die angegriffenen Systeme zu über- nehmen. Diese Schwachstellen wurden in der Zwischenzeit beseitigt. Detailliert be- schrieben werden die gefundenen Schwachstellen in Kapitel 4. Im Rahmen der Quelltext-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 zum Stichtag vorliegenden Fassung von beA-Client- Security und beA-Anwendung fast alle nicht mehr vorhanden sind. Die Unterstüt- zung von aktuellen Betriebssystemen konnte noch nicht bestätigt werden. Version: 1.0 Stand: 18.06.2018 Seite 10",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p10-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 11,
"content": "Technische Analyse und Konzeptprüfung des beA 1.4 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 geprüft, ob der erforderliche Schutz der Vertraulichkeit der Nachrichten durch das implementierte Verschlüsselungsverfahren erreicht wird, so dass alle kryptographischen Operationen zum Schutz der Vertraulichkeit von Nachrichten in HSM gekapselt sind und Nachrichten nicht außerhalb der HSM entschlüsselt wer- den können. Durchgeführt wurde eine Analyse nach Dokumentenlage, insbesondere durch Aus- wertung der relevanten Use-Cases (Ablaufbeschreibungen für bestimmte fachliche Vorgänge im beA). Des Weiteren wurden vorgelegte Feinkonzepte (vor allem zum Gesamtsystem, zur HSM-Verwendung und zur beA-Client-Security) analysiert. Die Ergebnisse der Analyse wurden gemeinsam mit dem Betreiber und dem Auftragge- ber im Rahmen von Telefonkonferenzen erörtert und verifiziert. Grundsätzlich ist das dem beA zugrundeliegende Verschlüsselungskonzept geeig- net, die Vertraulichkeit der Nachrichten während der Übertragung und Speicherung von Nachrichten durch das beA zu gewährleisten, auch gegenüber dem Betreiber des beA. Nachrichteninhalte liegen unverschlüsselt nur bei den Kommunikations- partnern vor. Die Umverschlüsselung ist in einem HSM gekapselt, schützt daher dort vorübergehend entstehende Schlüsselinformationen in einer besonderen mani- pulations- und ausspähsicheren Umgebung. Das erkennbare Ziel, die Sicherheit der Nachrichten ausschließlich durch Kryptographie zu schützen, ist aber nicht in vollem Umfang erreicht worden. An einigen Stellen verlässt sich das beA in seiner dem Gutachten zugrunde liegenden Realisierung auf organisatorisch-physikalischen Schutz wichtiger Systemkomponenten (HSM-Schlüssel, SAFE BRAK), was bei vol- ler Ausnutzung der kryptographischen Möglichkeiten, die das Konzept und die ein- gesetzte Technik bieten, nicht notwendig wäre. Durch die Analyse konnten aus technischer Sicht zwei betriebsverhindernde, drei betriebsbehindernde und zwei sonstige Schwachstellen identifiziert werden, die ein Angreifer ausnutzen kann, um sich trotz des kryptographischen Schutzes unbefug- ten Zugang zu Nachrichten zu verschaffen. Allen Schwachstellen ist gemeinsam, dass das HSM keinen oder keinen ausrei- chenden Schutz vor diesen Angriffen bietet, d.h. Nachrichten bei erfolgreichem An- griff auch außerhalb des HSM entschlüsselt oder dem HSM Leseberechtigungen vorgetäuscht werden können. Fast allen konzeptionellen Schwachstellen ist aller- dings auch gemeinsam, dass sie nur durch oder mit Hilfe von Innentätern, darunter auch Personen mit besonderer Vertrauensstellung, durchgeführt werden können, die dabei physikalisch-organisatorische Schutzmaßnahmen unterlaufen müssen. Außentäter können sich in die Position eines Innentäters bringen, wenn es ihnen ge- lingt, durch Ausnutzung von Schwachstellen der Serverkomponenten in diese ein- zudringen und die Kontrolle über sie zu übernehmen. Nur in einem Fall, einer Version: 1.0 Stand: 18.06.2018 Seite 11",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p11-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 12,
"content": "Technische Analyse und Konzeptprüfung des beA Täuschung eines beA-Anwenders mittels einer irreführenden EGVP-Adresse, ist auch ein Angriff durch einen Außentäter denkbar, der dafür die beA-Anwendung nicht angreifen muss. Die Ausnutzbarkeit der Schwachstellen ist in der Regel auf- grund des eingeschränkten Täterkreises und einer angenommenen geringen Moti- vation und besseren Überwachbarkeit von Innentätern gering. Die konzeptionellen Schwachstellen erhalten ihre Bedeutung in der Regel durch ihr hohes (teilweise sehr hohes) Schadenspotential. Betriebsverhindernd bewertet ist, dass Verschlüsselungszertifikate in der beA- Client-Security vor dem Versand von Nachrichten nicht geprüft werden. Dadurch verlieren die Zertifikate ihre Schutzwirkung, die beA-Client-Security kann durch ge- fälschte Zertifikate leicht getäuscht werden, und versendet dann Nachrichten lesbar für einen Angreifer. Betriebsverhindernd bewertet wird auch, dass die Integrität des Javascript-Codes, mit dem die beA-Client-Security gesteuert wird, nicht gewährleis- tet ist. Es besteht die Gefahr, dass durch böswillig manipulierten Javascript-Code bei allen beA-Anwendern Nachrichten im Klartext an einen Angreifer ausgeleitet werden. Für die Details der konzeptionellen Schwachstellen wird auf die Analyse in Kapitel 5 verwiesen. Im Rahmen der Gutachtenerstellung wurden vom Betreiber für alle be- schriebenen Schwachstellen Lösungsvorschläge unterbreitet und teilweise aus Gut- achtersicht bewertet. Alle Schwachstellen erscheinen grundsätzlich behebbar, allerdings mit unterschiedlichem Aufwand. Die betrachteten Signatur- und Signaturprüffunktionen des beA wurden ebenfalls untersucht. In diesem Bereich wurde keine konzeptionelle Schwachstelle gefunden. Auch die Authentisierungsfunktionen für den Zugriff auf ein Postfach und die Ver- waltung der Administrations- und Leserechte sind angemessen konzipiert. Die vom Betreiber vorgelegte Dokumentation zum Nachweis des sicheren IT- Betriebs des beA belegt einen geregelten, auch den Aspekt IT-Sicherheit beachten- den Betrieb. Grundlage ist ein ISO-27001-zertifiziertes Informationssicherheitsma- nagement. Erkennbar adressiert wird auch der besondere Schutzbedarf des beA. Es fehlt aber für das beA ein geschlossenes Sicherheitskonzept mit Begleitdoku- menten, das basierend auf einer Bedrohungs- und Risikoanalyse einen Nachweis darüber führt, dass allen Risiken für die hoch schutzbedürftigen Daten und IT- Systeme des beA in ausreichendem Maße entgegengewirkt wird. Dadurch war es nicht möglich, sich von der physikalisch-organisatorischen Sicherheit des beA und der vollständigen Abwehr aller nicht tragbaren Risiken zu überzeugen. Es wird emp- fohlen, ein Sicherheitskonzept und Begleitdokumente nach üblichem Muster zu er- stellen, die die fehlenden Teile enthalten und vorhandene Informationen über Sicherheitsmaßnahmen bündeln, um sowohl den Vollständigkeitsnachweis über die Abwehr aller Risiken zu führen als auch eine Grundlage für ein Sicherheits-Audit be- reitzustellen. Außerdem sollte ein unabhängiger Auditor den sicheren Betrieb des beA regelmäßig überprüfen. Dies kann als ergänzendes Audit zum bereits regelmä- ßigen stattfindenden ISO-27001-Audit geschehen. Version: 1.0 Stand: 18.06.2018 Seite 12",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p12-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 13,
"content": "Technische Analyse und Konzeptprüfung des beA 1.5 Resümee und Empfehlung Im Rahmen der Penetrationstests wurden insgesamt 36 Schwachstellen gefunden. Davon wurden vier Schwachstellen als betriebsverhindernd und 13 als betriebsbe- hindernd klassifiziert. Von diesen konnten zum Stichtag zwei betriebsverhindernde und vier betriebsbehindernde Schwachstellen nach Bearbeitung durch den Betreiber erneut getestet und als geschlossen festgestellt werden. Im Rahmen der Quellcodeanalysen wurden insgesamt zehn Schwachstellen gefun- den. Davon wurden sechs Schwachstellen als betriebsverhindernd und vier als be- triebsbehindernd klassifiziert. Bis zum Stichtag konnten alle betriebsverhindernden Schwachstellen nach Behandlung durch den Betreiber erneut getestet und als ge- schlossen festgestellt werden. Die konzeptionelle Analyse hat zwei betriebsverhindernde, drei betriebsbehindernde und zwei sonstige Schwachstellen aufgezeigt. Besonders problematisch sind hier der unsichere Umgang mit Verschlüsselungszertifikaten in der beA-Client-Security sowie die Verwendung von Javascript zur Steuerung der beA-Client-Security. Es wurde auch Verbesserungsbedarf bei der Dokumentation und der Kontrolle des si- cheren Betriebs erkannt. Grundsätzlich ist das beA ein geeignetes System zur vertraulichen Kommunikation im elektronischen Rechtsverkehr. Das Verschlüsselungskonzept bietet technisch gesehen einen hinreichenden Schutz für die Vertraulichkeit der vom beA übermittel- ten Nachrichten. Nicht tragbare Risiken, die noch bestehen, können beseitigt wer- den und sind teilweise auch schon beseitigt worden. Die erneute Inbetriebnahme ist bei Beachtung der folgenden Empfehlungen aus sicherheitstechnischer Sicht mög- lich. Für die noch nicht behobenen betriebsverhindernden Schwachstellen wird empfoh- len, 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 baldmöglichst zu beheben. Für den nachhaltig sicheren Betrieb des beA wird empfohlen, ein Sicherheitskon- zept, ein Kryptokonzept und ein Konzept für die Behandlung von Sicherheitsvorfäl- len in üblicher Form und Inhalt zu erstellen, bzw. vorhandene relevante Dokumente hier per Verweis einzubetten und auf der Grundlage dieser Dokumente ein regel- mäßiges Audit des ordnungsgemäßen Betriebs durchzuführen. Dies kann in Ergän- zung des regelmäßigen ISO-27001-Audits des Betreibers im gleichen Rhythmus geschehen. Version: 1.0 Stand: 18.06.2018 Seite 13",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p13-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 14,
"content": "Technische Analyse und Konzeptprüfung des beA 1.6 Abgrenzung Bei der Lektüre und Nutzung dieses Gutachtens sind folgende Hinweise zu berück- sichtigen: ■ 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-System erforderlichen technischen Komponenten, Schnittstellen oder Anwendungsfälle betrachtet. Es kann somit nicht vollständig ausgeschlos- sen werden, 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. Zu berücksichtigen ist auch, dass die konzeptionelle Analyse sich auf die Sicherheitsziele „Vertraulichkeit“ und „Authentizität“ konzentriert hat und somit insbesondere eine Betrachtung der „Verfügbarkeit“ nur dort erfolgte, wo eine gefundene Schwachstelle diese unmittelbar bedroht. Innerhalb der technischen Analysen standen die beA-Client-Security, die beA- Anwendung und externe Schnittstellen im Fokus. ■ Die vorgelegten grundlegenden Konzepte zur IT-Sicherheit (Sicherheits- konzept, Kryptokonzept etc.) ermöglichten keine abschließende Einschät- zung der technisch-organisatorischen Sicherheit des beA. Das Ausnutzen einzelner identifizierter Schwachstellen kann eventuell durch geeignete technische und organisatorische Maßnahmen – seitens des Auftraggebers oder des Betreibers – deutlich erschwert oder sogar vereitelt werden. Um- gekehrt können aber auch Schäden durch fehlende bzw. ungeeignete technische und/oder organisatorische Maßnahmen entstehen, die erst bei einer Vollständigkeitsprüfung, wie sie im Rahmen der Erstellung eines ge- schlossenen Sicherheitskonzeptes durchzuführen wäre, auffallen. Ein sol- ches Sicherheitskonzept liegt nicht vor. Es war nicht Gutachterauftrag, ein solches Konzept auf der Basis der vorgelegten Informationen und Doku- mente zu erstellen. ■ Darüber hinaus war es erforderlich, Annahmen zu treffen und Abgrenzun- gen des Betrachtungsgegenstandes vorzunehmen, damit der Aufwand ins- gesamt vertretbar blieb. So wurde angenommen, dass der Anwaltsrechner eine sichere Einsatzumgebung für den Einsatz der beA-Client-Security darstellt und frei von Schadsoftware ist. Die Absicherung des Anwaltsrech- ners sowie der Einsatzumgebung war dementsprechend nicht Gegenstand der Untersuchung. Version: 1.0 Stand: 18.06.2018 Seite 14",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p14-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 15,
"content": "Technische Analyse und Konzeptprüfung des beA ■ Eine Analyse, ob das beA-System alle rechtlichen und über die Sicherheit hinausgehenden funktionalen Anforderungen erfüllt, war nicht Gegenstand der Betrachtung. ■ Es ist möglich, dass einzelne identifizierte Schwachstellen von Dritten nachvollzogen und ausgenutzt werden können, auch wenn sie bereits be- hoben wurden, z. B. bei nicht erfolgter Deinstallation älterer Versionen der beA-Client-Security. Außerdem könnten durch die Darstellung von detail- lierten technischen Informationen Rechte Dritter verletzt werden, z.B. durch Angabe von Quellcode, oder schützenswerte Informationen aufgedeckt werden, wie z.B. IP-Adressen. Aus diesem Grund werden die Schwachstel- len in diesem, zur Veröffentlichung vorgesehenen Gutachten, ohne Angabe von detaillierten technischen Informationen dargestellt. Die detaillierten technischen und inhaltlichen Informationen zu den einzelnen Schwachstel- len werden zu deren gezielter Behebung laufend an den Auftraggeber übermittelt. Version: 1.0 Stand: 18.06.2018 Seite 15",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p15-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 16,
"content": "Technische Analyse und Konzeptprüfung des beA 2 Verfahren zur Schwachstellenbewertung In diesem Kapitel wird beschrieben, wie gefundene Schwachstellen in den folgen- den Kapiteln dargestellt werden und auf welche Art und Weise sie in Risikostufen eingeordnet worden sind. 2.1 Darstellungsform Bei der Beschreibung und Bewertung der identifizierten Schwachstellen wurde die folgende Darstellungsform gewählt. {S1} Schwachstellenbeschreibung Beschreibung der Schwachstelle {R1} Risikobewertung: Einstufung in Risikokategorie (A, B, C) Ausnutzbarkeit der Schwachstelle: Bewertung der Ausnutzbarkeit gemäß Kriterien, die noch erläutert wer- den Bewertung Ausnutzbarkeit: hoch, mittel oder niedrig Bewertung der Bedrohung: Beschreibung des Schadens eines Angriffs auf diese Schwachstelle im Erfolgsfall, Einstufung des Schadensausmaß in den drei Schutzziele Integrität, Vertraulichkeit, Verfügbarkeit gemäß Kriterien, die noch er- läutert werden Bedrohung Integrität: hoch, mittel oder niedrig Bedrohung Verfügbarkeit: hoch, mittel oder niedrig Bedrohung Vertraulichkeit: hoch, mittel oder niedrig {M1} Maßnahmenempfehlung, Darstellung, auf welche Weise die Schwach- stelle beseitigt werden könnte Die Beschreibung der identifizierten Schwachstellen setzt sich aus den drei Kompo- nenten Schwachstelle {S}, Risiko {R} und Maßnahme {M} mit einer zugehörigen eindeutigen Nummer zusammen. Die Schwachstellen der Kategorie C-Sonstige Schwachstellehaben geringe Aus- wirkung auf die Schutzziele und eine Behebung erscheint nicht zeitkritisch. Aufgrund der damit zusammenhängenden geringeren Relevanz für die Sicherheit des beA- Version: 1.0 Stand: 18.06.2018 Seite 16",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p16-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 17,
"content": "Technische Analyse und Konzeptprüfung des beA Systems, wurden diese in übersichtlicher tabellarischer Form aufgelistet. In der Ta- belle sind zusätzlich die Ergebnisse der einstufungsrelevanten Bewertungen hin- sichtlich Ausnutzbarkeit und Bedrohungen zu finden. Tabelle 1: Darstellungsform C-Schwachstellen Legende: h=hoch; m=mittel; n=niedrig; J=Ja Bedrohung Ausnutzbarkeit Schwachstelle Vertraulichkeit Verfügbarkeit Integrität behoben Kurzbeschreibung Komponente Die REST-API des Wikis ist öffentlich erreichbar und Webportal m n n n - stellt teilweise sensible Informationen bereit, die für den XWIKI Anwendungszweck des Wikis nicht benötigt werden. 2.2 Schwachstelle Der Bereich Schwachstelle beschreibt die identifizierte Schwachstelle. Zusätzliche Erläuterungen zum Verständnis der Schwachstelle finden sich in der Regel in einem der strukturierten Bewertung vorangestellten Fließtext. Zusätzlich werden (falls ver- fügbar und relevant) zu den identifizierten Schwachstellen die zugehörigen Common Vulnerabilities and Exposure (CVE) IDs aufgeführt. Bei CVE handelt es sich um ei- nen Industriestandard, der eine einheitliche Namenskonvention für Sicherheitslü- cken und andere Schwachstellen in Computersystemen bereitstellt. Mehrfachbenennungen 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 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. 2.3 Risikobewertung Der Bereich Risikobewertung stellt das geschätzte Risiko dar, welches durch das Vorhandensein der Schwachstelle hervorgerufen wird. Zur Einschätzung des Risi- kos werden zum einen die Ausnutzbarkeit der Schwachstelle sowie die Bedrohung (die im Erfolgsfall des Angriffs eintretenden Schäden) bewertet. Version: 1.0 Stand: 18.06.2018 Seite 17",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p17-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 18,
"content": "Technische Analyse und Konzeptprüfung des beA 2.3.1 Ausnutzbarkeit Nach kurzen Erläuterungen zur Ausnutzbarkeit der Schwachstelle wird diese in die Klassen hoch, mittel und niedrig eingestuft. Beispiele für ausgewählte Fragestellungen, anhand derer die Einstufung der Aus- nutzbarkeit erfolgt, sowie diesbezügliche Kriterien für eine Einstufung sind in der fol- genden Tabelle dargestellt. Tabelle 2: Beispielkriterien zur Bestimmung der Ausnutzbarkeit Beispiele für Kriterien zur Bestimmung der Ausnutzbarkeit Fragestellung hoch mittel niedrig (Auswahl) Auf welchem Wege Der Angriff ist durch Ein berechtigter Zugriff auf Die Schwachstelle kann kann ein Angriff direkten Zugriff aus dem den lokalen Rechner des nur durch Innentäter durchgeführt Internet möglich. Er Anwalts oder Server ist ausgenutzt werden. werden? erfordert kein Spezialwis- erforderlich. sen. Wie komplex ist die Die Ausnutzung ist mit Es müssen nur wenige Für die Ausnutzung der Durchführung des geringem technischem Sicherheitsmaßnahmen Schwachstelle müssen Angriffs? und zeitlichem Aufwand überwunden werden. vorab verschiedene möglich. Sicherheitsmaßnahmen Die Schwachstelle lässt überwunden werden. Für die Ausnutzung der sich mit verhältnismäßigen Schwachstelle ist geringer Mitteln Ausnutzen. Das Ausnutzen der Fachverstand erforderlich. Schwachstelle ist nur mit unverhältnismäßig Informationen zum hohem Aufwand Nutzen der Schwachstelle möglich. sind frei verfügbar. Welche Rechte Der Angriff ist nicht durch Für die Ausnutzung der Es sind administrative sind für den Angriff eine Rechteprüfung Schwachstelle sind Berechtigungen erforderlich? behindert. Zugriffsberechtigungen erforderlich. erforderlich. Sind bei einen Der Angriff kann ohne Für den Angriff ist ein Der Zugriff ist nur im 4- Angriff Nutzerinter- Mitwirkung eine Nutzers aktives Handeln des Augenprinzip möglich aktionen erforder- oder Administrators Nutzers erforderlich lich? durchgeführt werden. (Eingaben, Mausklick etc.). 2.3.2 Bedrohung Im Bereich Bedrohung werden die im Erfolgsfall des Angriffs eintretenden Schäden allgemein bewertet. Die Bewertung erfolgt dabei für die Schutzziele Integrität (kön- nen Daten unberechtigt verändert werden), die Verfügbarkeit (kann die Erreichbar- keit eines Systems / Dienstes eingeschränkt werden) und die Vertraulichkeit (kann ein Unberechtigter auf die Daten lesend zugreifen). Pro Kategorie werden die Klas- sen hoch, mittel und niedrig unterschieden, die angeben, wie kritisch der jeweilige Schaden eingeschätzt wird. Version: 1.0 Stand: 18.06.2018 Seite 18",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p18-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 19,
"content": "Technische Analyse und Konzeptprüfung des beA Einen besonderen Stellenwert bei der Betrachtung hat die Vertraulichkeit der Nach- richteninhalte und sonstiger sensibler Informationen zu Mandatsinhalten. Dies ist insbesondere auf die möglichen sensiblen Nachrichteninhalte in Verbindung mit der erforderlichen anwaltlichen Verschwiegenheitspflicht zurückzuführen. In die Beurteilung der Bedrohungen für die Integrität wurde ebenso das Schutzziel Authentizität (die Echtheit, Zuverlässigkeit und Glaubwürdigkeit einer Mitteilung, ein vertrauenswürdiger Identitätsnachweis) einbezogen. In die Bewertung der Integrität fließt ebenfalls die Bedrohung einer Übernahme der Kontrolle einer beA- Teilkomponente durch einen Angreifer ein (Störung der Systemintegrität). Exemplarische Kriterien zur Einstufung der Bedrohung des jeweiligen Schutzziels in die Kategorien „hoch“, „mittel“ und „niedrig“ werden in den nachfolgenden Tabellen dargelegt. Tabelle 3: Einstufung Vertraulichkeit Einstufung zum Schutzziel Beispiele für Bedrohungen Vertraulichkeit ■ Unberechtigte können Einblick in den Klartext von Nach- richten nehmen. Der Angreifer kann frei wählen, welche hoch Nachrichten er lesen kann. ■ Sensible schützenswerte Informationen können unbe- rechtigt gelesen werden (Inhalte der Nachrichtenanhän- ge im Klartext, Metadaten mit vertraulichen Inhalten) ■ Administrative/technische Informationen (Passwörter), die einen gezielten Angriff direkt ermöglichen, liegen un- berechtigt vor Vertraulichkeit ■ Unberechtigte können Einblick in den Klartext von Nach- richten nehmen. Bei der Auswahl der Nachrichten ist der mittel Angreifer auf maximal ein Postfach eines beA- Anwenders beschränkt. ■ Metadaten zu Nachrichtenanhängen, die Rückschlüsse auf die sensiblen Nachrichteninhalte ermöglichen kön- nen unberechtigt gelesen werden Vertraulichkeit ■ Metadaten/Informationen/Fehlermeldungen oder sonsti- ge Systeminformationen mit geringem Informationsge- niedrig halt zum Auffinden oder Ausnutzen von Schwachstellen sind betroffen. Version: 1.0 Stand: 18.06.2018 Seite 19",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p19-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 20,
"content": "Technische Analyse und Konzeptprüfung des beA Tabelle 4: Einstufung Integrität Einstufung zum Schutzziel Beispiele für Bedrohungen Integrität ■ Der Angreifer kann die komplette Kontrolle über eine hoch beA-Systemkomponente übernehmen. ■ Der Urheber einer Nachricht kann beliebig verfälscht werden ■ Die Gültigkeitsinformation über qualifizierte Signaturen kann verfälscht werden. ■ Wichtige Sicherheitsfunktionen können deaktiviert wer- den, zum Beispiel können signierte Daten verfälscht werden. Integrität ■ Daten können nur im eingeschränkten Maße geändert mittel werden. ■ Der Angreifer kann mit der Identität eines Anderen in der beA-Anwendung agieren ■ Eine teilweise Übernahme zentraler Komponenten oder Systeme erscheint möglich. Ein unberechtigter Einblick in vertrauliche Informationen oder ein Ausfall des beA- Systems scheint jedoch nicht möglich. ■ Der Anwender kann Funktionen nutzen oder missbrau- chen, zu denen er nicht berechtigt ist. Integrität ■ Integrität ist nicht betroffen oder die Änderungen haben niedrig keine oder kaum Konsequenzen für den Betrieb auf dem Zielsystem. ■ Es enstehen keine unmittelbaren Konsequenzen für an- dere Systemkomponenten. ■ Ein System stellt kein attraktives Angriffsziel dar, da der mögliche Gewinn aus einer Integritätsstörung gering o- der gar nicht erkennbar ist. Version: 1.0 Stand: 18.06.2018 Seite 20",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p20-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 21,
"content": "Technische Analyse und Konzeptprüfung des beA Tabelle 5: Einstufung Verfügbarkeit Einstufung zum Schutzziel Beispiele für Bedrohungen Verfügbarkeit ■ Das beA-System steht vollumfänglich nicht zur Verfü- hoch gung (Komplettausfall des primären Dienstes). ■ Allen Teilnehmern ist es vorübergehend nicht möglich, Nachrichten entgegenzunehmen oder zu versenden. Verfügbarkeit ■ Einzelnen Teilnehmern ist es vorübergehend nicht mög- mittel lich, Nachrichten entgegenzunehmen oder zu verwen- den. ■ Es bestehen alternative Kommunikationswege bzw. Al- ternativen zur Erlangung von Informationen. Verfügbarkeit ■ Nur eine einzelne Komponente oder Teilfunktion des niedrig beA ist betroffen. Die grundlegenden Funktionalitäten zum Empfang und Versand von Nachrichten sind jedoch nicht beeinträchtigt. 2.3.3 Bestimmung des Risikos Das Risiko wird aus der Ausnutzbarkeit und der Bedrohung abgeleitet. Das Risiko kategorisiert den statistischen Erwartungswert für eintretende Schäden, der sich gemäß den Regeln der Statistik aus dem Produkt der Eintrittswahrscheinlichkeit ei- nes Schadens und dem Umfang dieses Schadens bestimmt. Die Eintrittswahr- scheinlichkeit ist durch den Faktor Ausnutzbarkeit, der Umfang des Schadens durch den Faktor Bedrohung bewertet. Das sich daraus ergebende Risiko wird in drei Ri- sikostufen eingeordnet: A-Betriebsverhindernde Schwachstelle Die Behebung vor Wiederinbetriebnahme wird dringend empfohlen. B-Betriebsbehindernde Schwachstelle Eine Behebung sobald wie möglich wird empfohlen. C-Sonstige Schwachstelle Lediglich unerhebliche Auswirkungen auf den Betrieb sind zu erwarten, eine Behebung wird empfohlen, soweit dies mit verhältnismäßigem (am möglichen Schaden bemessenen) Aufwand möglich ist. Die Begrifflichkeiten entsprechen der Kategorisierung von Systemfehlern im Fehler- behandlungsprozess des beA. Mit der Einordnung von Schwachstellen in die Risi- kostufen ist eine Priorisierung ihrer Behebung verbunden, die dem Ausmaß des Risikos entspricht. Version: 1.0 Stand: 18.06.2018 Seite 21",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p21-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 22,
"content": "Technische Analyse und Konzeptprüfung des beA Die Einstufung des Risikos anhand der Bewertung für Ausnutzbarkeit und Bedro- hung in betriebsverhindernd, betriebsbehindernd und sonstiges leitet sich aus der nachfolgenden Grafik ab. Der Einstufung liegen Erfahrungswerte des Gutachters sowie eine vergleichbare Einstufung aus dem Standard 200-3 Risikomanagement des BSI (Version 1.0, S. 27) zugrunde. Dabei wurden Risiken für die Vertraulichkeit und Integrität als bedeutsamer angesehen, da hier unmittelbar und ohne nachträgli- che Abhilfe die Kommunikation der beA-Anwender betroffen ist, während bei einer Einschränkung der Verfügbarkeit alternative Kommunikationswege und Möglichkei- ten der Abhilfe (z.B. Wiedereinsetzung in den vorherigen Stand) zur Verfügung ste- hen. Tabelle 6: Bewertung des Risikos Ausnutzbarkeit Ausnutzbarkeit Ausnutzbarkeit hoch mittel niedrig Bedrohung der Schutzziele Vertraulichkeit hoch A A B Vertraulichkeit mittel A B C Vertraulichkeit niedrig B C C Integrität hoch A A B Integrität mittel A B C Integrität niedrig B C C Verfügbarkeit hoch A B C Verfügbarkeit mittel B C C Verfügbarkeit niedrig C C C Dieses Bewertungsschema wurde spezifisch für die Begutachtung des beA entwickelt. Streng genommen ist die Bestimmung des Risikos über Ausnutzbar- keit und Schaden durch einen erfolgreichen Angriff unvollständig, weil sie die Eintrittswahrscheinlichkeit nur zum Teil berücksichtigt. Die Eintrittswahrscheinlich- keit wird durch die Komplexität des Angriffs, Größe des potentiellen Angreiferkrei- ses (alle, nur beA-Nutzer oder Innentäter) und Motivation der Angreifer (Bereitschaft, die erforderlichen Mittel aufzuwenden und Risiken einzugehen, um einen Angriff durchzuführen) bestimmt. Das beschriebene Bewertungsschema berücksichtigt die Komplexität des Angriffs und die Größe des potentiellen Angrei- ferkreises und fasst diese im Faktor Ausnutzbarkeit zusammen. Die Motivation der Angreifer wird nur sehr grob berücksichtigt, in dem die Ausnutzbarkeit für Innentäter deutlich niedriger eingeordnet wird, als sie es rein technisch gesehen ist, weil sie im Kontext des beA eine schwer schätzbare Größe ist. Sie hängt beim beA ganz wesentlich davon ab, welchen Nutzen für sich selbst potentielle Angrei- fer z.B. aus der Einsichtnahme in vertrauliche Nachrichten im elektronischen Rechtsverkehr ziehen können. Darüber liegen keine Erfahrungswerte vor. Version: 1.0 Stand: 18.06.2018 Seite 22",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p22-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 23,
"content": "Technische Analyse und Konzeptprüfung des beA 2.4 Maßnahme Der Bereich Maßnahme beschreibt Maßnahmen, die getroffen werden könnten, um die Schwachstelle zu beseitigen. Die Maßnahmen stellen lediglich mögliche Lösun- gen dar, und sollen belegen, dass die Schwachstelle beseitigt werden kann. Die Notwendigkeit und Priorität der Schwachstellenbehebung hängt aber nur von der bereits beschriebenen Risikoeinstufung ab. 2.5 Angaben zum Status der Schwachstellenbehebung Der Status zur Schwachstelle beschreibt den aktuellen Stand, ob die Schwachstelle bereits gutachterlich verifiziert behoben wurde). Dabei gelten die nachfolgenden De- finitionen: ■ „-“ Eine Bearbeitung der Schwachstelle durch den Betreiber liegt nicht vor oder es wurde noch kein erneuter Test durch den Gutachter (ReTest) zur Schwachstelle durchgeführt. ■ verifiziert: Schwachstelle behoben Die bemängelte Schwachstelle konnte nicht mehr nachgewiesen werden bzw. es wurden aus Sicht des Gutachters adäquate Sicherheitsmaßnahmen ergriffen. Die Schwachstelle wird somit zum Stichtag als vollständig behoben angesehen. ■ verifiziert: Schwachstelle nicht behoben Bei der Überprüfung, ob die ursprüngliche erkannte Schwachstelle beseitigt wurde, wurde die Schwachstelle erneut vorgefunden bzw. die vorgenomme- nen Verbesserungen wurden als nicht ausreichend eingestuft. Version: 1.0 Stand: 18.06.2018 Seite 23",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p23-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 24,
"content": "Technische Analyse und Konzeptprüfung des beA 3 Detailergebnisse der Penetrationstests In den nachfolgenden Abschnitten wird nun zunächst der genaue Analysegegen- stand des Gutachtens beschrieben. Dazu wird die gesamte Systemumgebung im beA-Kontext erläutert und die dazugehörigen Schnittstellen kurz beschrieben. In dem Kapitel „Rahmenbedingungen und Abgrenzung“ werden sowohl allgemeine, im Rahmen von Penetrationstests als auch spezifische Abgrenzungen in Bezug auf den beA-Kontext vorgenommen. Nach dem Kapitel zur Methodik und Vorgehensweise, in dem die allgemeine Vorge- hensweise bezüglich der Penetrationstests beschrieben wird, werden in einer Über- sichtstabelle alle Schwachstellen der Kategorien A und B aufgeführt. Diese Schwachstellen werden anschließend in dem Detailkapitel erläutert und be- zogen auf das definierte Verfahren zur Schwachstellenbewertung beschrieben. Die als Kategorie C eingestuften Schwachstellen werden abschließend zusammenge- fasst in einer kompakten Tabelle aufgeführt. 3.1 Beschreibung des Analysegegenstandes Das besondere elektronische Anwaltspostfach, kurz beA, ist ein über das Internet erreichbarer Systemverbund, der einen Austausch von gesicherten Nachrichten zwischen registrierten Benutzern. Um den Dienst zum Senden und Empfangen gesicherter Nachrichten nutzen zu können, werden sowohl eine lokale Java-Anwendung, ein Webbrowser sowie eine beA-Karte mit dazugehöriger PIN benötigt. Wie in Abbildung 1 dargestellt, besteht das beA-Zentralsystem aus verschiedenen Komponenten bzw. Bereichen. So interagiert der Benutzer entweder mit der beA- Client-Security oder mit einer Kanzleisoftware. Weiterhin gibt es den, in der Grafik im oberen Bereich abgebildeten Bereich der Kammern, sowie rechts den Bereich der mit dem beA interagierenden Justizsysteme. Version: 1.0 Stand: 18.06.2018 Seite 24",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p24-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 25,
"content": "Technische Analyse und Konzeptprüfung des beA Abbildung 1: Externe Architektur des beA-Zentralsystem Zur Übersicht werden nun sowohl externen Schnittstellen als auch die allgemeinen relevanten Komponenten kurz erläutert. beA-Client-Security Die beA-Client-Security ist eine Anwendung, die als lokale Java-Anwendung auf ei- nem Benutzersystem installiert wird. Sie besteht aus dem Nachrichtenformatmodul, dem Governikus-Signer und dem Krypto-Modul. Die Anwendung kommuniziert über HTTPS mit den Servern der beA-Anwendung. Auf dem lokalen Rechner stellt sie ei- nen Secure-Websocket Dienst bereit. Die Anwendung kommuniziert mit einer Be- nutzer-Smartcard über das PC/SC Protokoll. Die Kommunikation zwischen verschiedenen Modulen der beA-Client-Security findet über Java-native Schnittstel- len statt. beA-Anwendung Die beA-Anwendung ist eine Webanwendung. Der Dienst wird in einem JBoss- Applikationsserver betrieben und unterstützt den Download der beA-Client-Security, die Verwaltung von Postfächern, Benutzern und Nachrichten und das Aktualisie- rungsverfahren der beA-Client-Security. Die beA-Anwendung ist die eigentliche Be- nutzeroberfläche. Der Browser kommuniziert mit der beA-Anwendung über HTTPS. Der Austausch von Daten erfolgt entweder mit allgemeinen GET- und POST-, oder mit JSON-formatierten REST-Anfragen. Innerhalb der Webapplikation kommunizie- ren Javascript-Module mit der beA-Client-Security über den lokalen Websocket. Version: 1.0 Stand: 18.06.2018 Seite 25",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p25-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 26,
"content": "Technische Analyse und Konzeptprüfung des beA Webservice Kanzleisoftware Bei dem System handelt es sich um einen Webservice zur Nutzung des beA- Postfaches. Der Dienst benötigt ein gültiges Client-Zertifikat. Der Dienst kann ver- wendet werden, um die Funktionalitäten der beA-Client-Security in einer eigenstän- digen Anwendung zu implementieren. Webservice Kanzlei SAFE BRAK Bei dem System handelt es sich um einen SAML-Webservice zur Nutzung des beA- Postfaches. Für die Anbindung von Kanzleisoftwareprodukten wird eine Webser- vice-Schnittstelle zur Verfügung gestellt. Dieser Webservice ist mittels einer HTTPS- Client-Authentisierung abgesichert und kann somit nur von freigegebener Kanzleis- oftware angesprochen werden. Die benötigten Funktionen der beA-Anwendung für die Nutzung durch die Kanzleisoftware werden über diese Schnittstelle bereitge- stellt. Der Service erwartet eine korrekt formulierte Nachricht, da er sonst aus- schließlich mit Fehlernachrichten antwortet SAFE Justiz SAFE BRAK Die SAFE BRAK stellt einen Webservice für die SAFE Justiz zur Verfügung. Über diesen angebotenen Dienst können Informationen zu Identitäten aus einer Identi- tätsdatenbank innerhalb der SAFE BRAK gesucht werden. Webservice OSCI Intermediär BRAK Der Intermediär BRAK wird für die Anbindung des besonderen Anwaltspostfachs beA an die EGVP/OSCI-Infrastruktur der Justiz genutzt. Der Webservice dient zur kryptographisch abgesicherten Kommunikation zwischen der Justiz und der BRAK. Hierbei kommt OSCI als Protokoll zum Einsatz. Kammersoftware Bei dem System handelt es sich um einen User-Provisioning-Mechanismus, der durch einen HTTP-Upload von CSV-Dateien realisiert wird. Der Dienst verlangt ein Client-Zertifikat. Der Untersuchungsgegenstand umfasste auch den zugehörigen Webservice Webportal BRAV-Suche Bei dem System handelt es sich um eine webbasierte Suchfunktion für Rechtsan- wältinnen und Rechtsanwälte. Die Suchmaske ist nicht von einer vorherigen Anmel- dung oder sonstiger Authentisierung gegenüber dem System abhängig sind. Webservice Find a Lawyer Bei dem System handelt es sich um einen Webservice zum Suchen von Anwälten in einer Datenbank des SAFE BRAK über den SAFE-Connector. Der Service verlangt ein Clientzertifikat. Version: 1.0 Stand: 18.06.2018 Seite 26",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p26-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 27,
"content": "Technische Analyse und Konzeptprüfung des beA Kanzleisoftware / beA-Client-Security Webservice OSCP Relay Bei dem System handelt es sich um einen Webservice mit OCSP Relay Funktionali- tät. Der Webservice dient zur Statusüberprüfung von Zertifikaten und zum Extrahie- ren von Zertifikatinformationen. Der Service ist ohne Authentifizierung nutzbar. Webservice BNoTK Postfach beaPostfach Bei dem System handelt es sich um einen Webservice zum Abruf der öffentlichen Verschlüsselungszertifikate von Postfächern der Postfacherstellung. Für den Aufruf der Schnittstelle wird von der beA-Anwendung unter Einbindung der HSM ein Zerti- fikatsrequest erstellt und zusammen mit der SAFE-ID des Postfachs an die Schnitt- stelle übermittelt. Die Schnittstelle liefert anschließend asynchron das signierte Verschlüsselungszertifikat zurück. Der Service verlangt ein Clientzertifikat. Webservice BNoTK Antragsportal beA Bei dem System handelt es sich um einen Webservice zur Versorgung des Karten- anbieters mit Adressdaten. Diese Daten werden zur Erstellung der beA-Karte ver- wendet. Der Kartenanbieter fragt bei der beA-Anwendung Daten mittels SAFE-ID an, welche dann Adressdaten von SAFE BRAK anfordert und diese an den Karten- anbieter zurücksendet. Der Service verlangt ein gültiges Clientzertifikat. Webportal XWIKI Bei dem System handelt es sich um ein Webportal zur Bereitstellung von statischen Informationsseiten bzw. Anleitungen rund um die Verwendung des beA für die beA- Benutzer. Übersicht der externen Schnittstellen im beA In Tabelle 7 sind die während der Analysen geprüften Software-Versionen der beA- Komponenten aufgeführt. Die hier aufgeführten externen Schnittstellen spiegeln den Gutachtergegenstand im Bereich der Penetrationstest wieder. Dabei wird die Kom- munikationsrichtung als Kommunikationspartner aufgeführt. Tabelle 7: Externe Schnittstellen und analysierte Versionen im beA Kommunikationspartner A Kommunikationspartner B Analysierte Versionen - beA-Client-Security v3.1.3.6 v3.1.3.7 (ReTests) Browser beA-Anwendung v2.0.10 v2.1.X v2.1.1 (ReTests) Kanzleisoftware beA-Kanzleisoftware- v2.1.X ( Schnittstelle v2.1.1 (ReTests) Version: 1.0 Stand: 18.06.2018 Seite 27",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p27-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 28,
"content": "Technische Analyse und Konzeptprüfung des beA Kommunikationspartner A Kommunikationspartner B Analysierte Versionen Kanzleisoftware SAFE BRAK v2.1.X ( v2.1.1 (ReTests) SAFE Justiz SAFE BRAK v2.1.X ( v2.1.1 (ReTests) OSCI-Empfang Intermediär BRAK v2.1.X v2.1.1 (ReTests) Kammersoftware SAFE-Connector v2.1.X v2.1.1 (ReTests) Browser BRAV-Suche v2.1.X v2.1.1 (ReTests) v2.1.1.1 (ReTests) Browser Find-a-lawyer v2.1.X v2.1.1 (ReTests) Kanzleisoftware / beA-Client- OCSP Relay Service v2.1.X Security v2.1.1 (ReTests) BNotK Postfach-Zertifikatservice beA Postfach- v2.1.X zertifikatschnittstelle v2.1.1 (ReTests) BNotK Antragsportal beA Adressdatenschnittstelle v2.1.X v2.1.1 (ReTests) Browser beA Xwiki v2.1.X v2.1.1 (ReTests) 3.2 Rahmenbedingungen und Abgrenzung Ein Penetrationstest muss immer als Betrachtung zu einem Stichtag aufgefasst werden. Die zu diesem Zeitpunkt bekannten Schwachstellen und Angriffstechniken werden genutzt. Aussagen über die Zukunft lassen sich jedoch nicht treffen. Demzu- folge kann ein System, bei dem keine Schwachstelle gefunden wurde, bereits kurze Zeit später durch eine neu entdeckte Schwachstelle oder neue Angriffsverfahren angreifbar werden. Auch Änderungen von Systemeinstellungen in dessen Kontext der Prüfgegenstand läuft, können positive oder negative Auswirkungen auf die Sys- temsicherheit haben 3.3 Methodik und Vorgehensweise Ausgangspunkt für die Festlegung des für die Penetrationstest relevanten Prüfge- genstände ist die Perspektive, einem aus dem Internet agierender Angreifer (Grey- box-Ansatz). Weitere Angriffsszenarien werden durch die durchgeführten Quelltext- Analysen und die konzeptionelle Analyse ergänzt (Whitebox-Ansatz). Zu dem ge- nannten Ausgangspunkt gehören auch Angreifer, welche einen einfachen Zugang zum beA-System mittels valider beA-Karte und dazugehöriger PIN besitzen. Der Version: 1.0 Stand: 18.06.2018 Seite 28",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p28-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 29,
"content": "Technische Analyse und Konzeptprüfung des beA Analysegegenstand ergibt sich somit primär aus den im Internet verfügbaren exter- nen Schnittstellen des gesamten beA-Systems. Der Penetrationstest wurde nach folgendem Ablauf durchgeführt: ■ Einarbeitung des Analysten in die Dokumentenbasis ■ Einrichtung der Analyseumgebung ■ Durchführung der Analysen (einschließlich der Verifikation der Behebung bereits auf andere Weise bekanntgewordener Schwachstellen) ■ Dokumentation, Auswertung und Kommunikation von Analyseergebnissen ■ Überprüfung behobener Schwachstellen Zunächst wurde die mögliche Angriffsfläche der Anwendung und ihre Kommunikati- onskanäle evaluiert. Hierbei wurde das Angreifermodell „externer Angreifer“ zugrun- de gelegt, welches lokalen Zugriff auf ein beA-Client-Security-System, sowie mögliche Schadsoftware bzw. konkreter von Angreifern eingerichtete Hintertüren auf dem System ausschließt. Ein „externer Angreifer“ kann hier sowohl ein aus dem In- ternet agierender Angreifer als auch ein im beA-System registrierter Benutzer sein. Auf Basis des zugrunde gelegten Angreifermodells wurden insbesondere die TLS- geschützten Kommunikationskanäle zur beA-Anwendung, sowie der Zugriff auf den lokalen Websocket über den Client-Browser als mögliche Angriffsflächen identifi- ziert. Die Überprüfung eines möglichen Zugriffs bzw. die Manipulation lokaler Kom- munikation, wurde auf die Steuerungsmöglichkeiten der Websocket-Schnittstelle fokussiert. Diese muss primär über den Client-Browser als Schnittstelle für externe Kommunikation zur beA-Anwendung ansprechbar sein. Der Browser fungiert in die- ser Architektur sowohl für die Bedienung der Web-Anwendung durch den Benutzer, als auch für die Steuerung der beA-Client-Security. In dem nächsten Schritt der Penetrationstests wurden ergänzend zum beA- Kernsystem, wie es sich für Benutzer des beA darstellt, weitere externe Schnittstel- len und Portale untersucht, die für den technischen Betrieb der Infrastruktur einge- richtet sind. Hierzu zählen unter anderem: verschiedene Webservices (SOAP und REST), ein Client für Datenexporte (Kammersoftware), sowie Webportale für die Be- reitstellung von Hilfeseiten oder die Suche im Bundesrechtsanwalts-Verzeichnis (BRAV). Die Webportale und Webservices wurden hierbei angelehnt an den OWASP- Standard auf Schwachstellen hin untersucht, wobei erneut hauptsächlich das An- greifermodell „externer Angreifer“ zugrunde gelegt wurde. Ein „externer Angreifer“ kann hier sowohl ein aus dem Internet agierender Angreifer als auch ein im beA- System registrierter Benutzer sein. Bei der Analyse wurde sowohl das technische, als auch das logische Missbrauchspotenzial der jeweiligen Schnittstellen bzw. Dienste geprüft. Version: 1.0 Stand: 18.06.2018 Seite 29",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p29-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 30,
"content": "Technische Analyse und Konzeptprüfung des beA 3.4 Übersicht der Schwachstellen In der nachfolgenden Tabelle werden alle Schwachstellen zum Bereich der Penetra- tionstests vorab dargestellt. Die A und B Schwachstellen, werden in den nachfol- genden Bereichen detailliert beschreiben. Die Tabelle benennt sowohl die jeweils betroffene Komponente als auch den Behebungsstatus der Schwachstelle zum Stichtag des Abschluss der Analyse. Die Spalte „Einstufung“ benennt die Einstufung des mit der Schwachstelle verbundenen Risikos gemäß Beschreibung in Kapitel 2. Tabelle 8: Schwachstellenübersicht Penetrationstests Komponenten Schwachstellen Ein- behoben stu- fung beA-Anwendung Nicht autorisiertes File-Sharing A J beA-Anwendung Auslesen von Metadaten dritter Nachrichten A J Kanzleisoftware / beA-Client- Modifikation von signierten Nachrichten A - Security Webservice OSCP Relay beA-Client-Security Veraltete Softwareelementen A - beA-Anwendung Veraltete Javascript-Bibliotheken in der beA- B - Anwendung Kammersoftware Webservice Überschreiben von Dateien B - beA-Anwendung SessionID als GET Parameter in der URL B - beA-Anwendung Transportverschlüsselung der beA-Anwendung B J Client-TLS-Renegotiation beA-Client-Security Transportverschlüsselung der beA-Client- B J Security: Client-TLS-Renegotiation beA-Client-Security Transportverschlüsselung der beA-Client- B J Security: Logjam beA-Anwendung Detaillierte Fehlermeldungen der Webapplikati- B onsfirewall beA-Anwendung Schwache Lock-Out-Mechanismen in der beA- B J Anwendung beA-Anwendung Qualität der genutzten Session-Cookies B - beA-Anwendung Automatisches Ausführen und öffnen von B - Dateien Webservice OSCI Interme- Modifikation von signierten XML-Nachrichten B - diär BRAK beA-Client-Security Innerhalb den Logdateien stehen Informationen B - zur REST Schnittstelle der beA-Anwendung Kammersoftware Nicht konsistente Zertifikatsprüfung B - Version: 1.0 Stand: 18.06.2018 Seite 30",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p30-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 31,
"content": "Technische Analyse und Konzeptprüfung des beA Komponenten Schwachstellen Ein- behoben stu- fung Webportal XWIKI Die REST-API des Wikis ist öffentlich erreichbar C und stellt teilweise sensible Informationen bereit, die für den Anwendungszweck des Wikis nicht benötigt werden. Webportal XWIKI Das Portal ist anfällig für eine Reflected-XSS- C Schwachstelle, die jedoch nicht ohne weiteres auszunutzen ist. Webportal BRAV-Suche Das Webportal hat eine XSS-Schwachstelle. C Webservice Kanzlei-SAFE Der Webservice gibt Fehlerbezeichnungen mit C BRAK Paketnamen und Stack-trace an den Client weiter, wodurch Rückschlüsse auf die Architek- tur möglich sind. beA-Client-Security In den Logdateien der lokal installierten beA- C Client-Security des Benutzers findet sich die Session-ID der Anwendung. beA-Anwendung Die Analyse des Datenverkehrs ergab, dass in C einem Großteil der betrachteten Seiten mit vertraulichen Inhalten der Browser-Cache nicht deaktiviert wird. beA-Anwendung Die Passwort-Policy für den Mitarbeiterlogin ist C J nicht ausreichend, da kein Brute-Force Schutz vorhanden ist. beA-Anwendung Das Passwortfeld auf der Anmeldeseite C J „Registrierung beA Benutzer“ begrenzt die Eingabe eines Passwortes auf 8 Zeichen. beA-Anwendung An mehreren Stellen innerhalb der Web- C Applikation können Fehlermeldungen ausgelöst werden. Webservice Attribute-Service Der Webservice gibt Fehlerbezeichnungen aus C VAS => SAFE BRAK Java an den Client weiter, die Rückschlüsse auf die Architektur zulassen. RAK Client Passphrasen werden im Klartext gespeichert. C Kammersoftware Endpunkte Der Webserver gibt per HTTP-Server-Header C seine genaue Version preis. Webservice Find a Lawyer Der Webservice gibt im Response-Header die C Server-Software und -Versionsnummer über das Server-Response-Header-Feld bekannt. Find a Lawyer Der Webservice gibt Fehlerbezeichnungen aus C Java an den Client weiter, die Rückschlüsse auf die Architektur zu lassen. Webservice BNotK Postfach- Der Webservice gibt im Response-Header C beA-Postfach Server Software und Versions-nummer bekannt über das Server-Response-Header-Feld. Version: 1.0 Stand: 18.06.2018 Seite 31",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p31-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 32,
"content": "Technische Analyse und Konzeptprüfung des beA Komponenten Schwachstellen Ein- behoben stu- fung Webservice BNoTK Postfach- Der Webservice gibt Fehlerbezeichnungen aus C beA-Postfach Java an den Client weiter, die Rückschlüsse auf die Architektur zu lassen. Xwiki Der Webserver gibt auf Fehlerseiten seine C genaue Version und Stack-Traces preis. Xwiki Es konnte eine Benutzerlogin-Maske öffentlich C abgerufen werden, die durch einen Angreifer ausgenutzt werden könnte und keinen Schutz vor Brute-Force-Angriffen oder lokaler Pass- wort-Speicherung bietet. Xwiki Auf dem Server konnten Stack-Trace- C Meldungen hervorgerufen werden, die ggf. für weitere Angriffe genutzt werden könnten. 3.5 Beschreibung der A-Schwachstellen In dem nachfolgenden Kapitel werden alle im Bereich der Penetrationstests identifi- zierten Schwachstellen der Kategorie A der Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit des Zielsystems beschrieben. Jede Schwachstelle wird in einem Unterkapitel aufgeführt und die dazugehörige technische Komponente benannt. Die Methodik und Vorgehensweise der Schwachstellenbeschreibung, der Definition der Risikobewertung, der Ausnutzbarkeit der Schwachstelle sowie zur Einstufung der Bedrohungen wurden in Kapitel 2 erläutert. 3.5.1 Nicht autorisiertes File-Sharing Untersuchungsobjekt beA-Client-Security und beA-Anwendung Schwachstellenstatus verifiziert: Schwachstelle behoben {S1} Ein im beA-Kontext genutzter Mechanismus kann für nicht autorisierten Austausch von Daten missbraucht werden. Daten können nicht autori- siert auf dem beA-Anwendungsserver abgespeichert und zu einem spä- teren Zeitpunkt wieder abgerufen werden. {R1} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit der Schwachstelle Um den betroffenen Mechanismus auszunutzen ist folgender Ablauf nö- tig: 1. Beliebige Anfrage an den Server schicken um SessionID zu erhalten 2. Ticket auf dem Server erstellen Version: 1.0 Stand: 18.06.2018 Seite 32",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p32-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 33,
"content": "Technische Analyse und Konzeptprüfung des beA 2.1 Mit SessionID Daten auf den Server schicken 2.2 Rückgabe: TicketID 3. Abruf der Daten mittels TicketID Die Schwachstelle kann aus dem Internet ohne Kenntnis gültiger Zu- gangsdaten zur beA-Anwendung ausgenutzt werden. Entsprechend hoch ist die Ausnutzbarkeit. Ausnutzbarkeit: hoch Bewertung der Bedrohung Der nicht autorisierte Datenaustausch kann eine Vielzahl an Bedrohun- gen auslösen. Ein Angreifer kann beispielsweise beliebige Daten hoch- laden und den Server zur Ablage und Verteilung von legalen oder illegalen Inhalten als einfachen Cloud-Dienst nutzen. Die Bedrohung der Integrität ist hoch. Auch ein Upload von Daten mit großem Speicherbe- darf wäre denkbar, um die Serverressourcen auszulasten und so die Verfügbarkeit beeinträchtigen. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: mittel Bedrohung Vertraulichkeit: niedrig {M1} In einer ersten Maßnahme sollte diese Funktion nur authentifizierten Benutzern bereitgestellt werden. Weiterhin sollte das Abspeichern von Daten auch zeitlich begrenzt werden, um die Angriffsfläche bzw. das Missbrauchspotential zu minimieren. 3.5.2 Auslesen von Metadaten fremder Nachrichtenanhängen Untersuchungsobjekt beA-Client-Security und beA-Anwendung Schwachstellenstatus verifiziert: Schwachstelle behoben Es konnte festgestellt werden, dass authentifizierte Benutzer über die beA-Client- Security potenziell auf die Metadaten der Anhänge von versendeten Nachrichten anderer Benutzer zugreifen können. Metadaten in diesem Sinne sind bezogen auf eine verschlüsselte Nachricht, die im beA-Kontext versendet wurde. Diese be- schreiben beispielsweise Eigenschaften, welche dem Anhang zugrunde liegen. Als Metadaten in diesem Kontext konnten folgende Informationen identifiziert werden (Einsatzzweck der einzelnen Daten spekulativ): ■ „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] Version: 1.0 Stand: 18.06.2018 Seite 33",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p33-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 34,
"content": "Technische Analyse und Konzeptprüfung des beA ■ „data“: [nicht lesbarer Inhalt, mit hoher Wahrscheinlichkeit tatsächlicher verschlüsselter Anhang] ■ „key“: [variable längere Zeichenfolge] ■ „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] Abbildung 2: Anhang test.txt Abbildung 3: Anhang xjustiz_nachrict.xml Wie in Abbildung 2 und Abbildung 3 zu sehen ist, können die genannten Metadaten lesbar im Browser eingesehen werden. Dabei gelten nun die folgenden Rahmenbe- dingen: ■ Angreifer muss in der beA-Anwendung angemeldet sein ■ /<Nachrichten_ID>/ muss erraten werden ■ /<Dateiname>/ muss erraten werden Version: 1.0 Stand: 18.06.2018 Seite 34",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p34-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 35,
"content": "Technische Analyse und Konzeptprüfung des beA {S2} Innerhalb der beA-Anwendung ist es angemeldeten Angreifern möglich, auf die Metadaten von Nachrichtenanhängen anderer Benutzer zuzu- greifen. Der Angreifer kann somit seinen eigenen Nutzerkontext inner- halb der beA-Anwendung erweitern. {R2} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit der Schwachstelle Ein in der beA-Anwendung angemeldeter Angreifer kann hier mittels au- tomatisierter Skripte über Nacht bzw. über mehrere Tage versuchen die numerischen IDs der Anhänge und der Dateinamen zu erraten und so bei Erfolg auf die aufgeführten Metadaten zugreifen. Die Ausnutzbarkeit ist hier hoch definiert, da Schwachstelle einfach auszunutzen ist und ei- ne sehr hohe Nutzerzahl potenziell Zugriff auf diese Schwachstelle hat. Ausnutzbarkeit: hoch Bewertung der Bedrohung Ein Angreifer kann die Metadaten der Anhänge von fremden Nachrich- tenanhängen abrufen. Er kann diese Informationen für weitere Angriffe missbrauchen. Die Vertraulichkeit des verschlüsselten Anhangs selbst ist durch die genannte Schwachstelle nicht bedroht. Bedrohung Integrität: mittel Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: niedrig {M2} Benutzer sollten, trotz der Verschlüsselung der konkreten Nachrichten- bzw. Dateiinhalte, nur auf Anhänge und dazu gehörige Informationen zugreifen können, die ihrem Konto zugeordnet sind. Es sollte geprüft werden, warum das implementierte Nutzer- und Rollenkonzept an dieser Stelle einen Zugriff nicht verhindert. 3.5.3 Modifikation von signierten Nachrichten Untersuchungsobjekt Webservice OSCP Relay => KSW Schwachstellenstatus - {S3} Bei der Verwendung von signierten XML-Nachrichten sind keine Vor- sichtsmaßnahmen getroffen worden, um den Inhalt der signierten XML- Nachricht gegen Modifikation zu schützen. Die vorgesehene Signatur- prüfung kann umgangen werden, in dem man dem signierten Daten- block einen weiteren mit identischem Namen hinzufügt, der dann der Modifikation offen steht. Dieser Angriff wird Signature-Wrapping ge- nannt. Version: 1.0 Stand: 18.06.2018 Seite 35",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p35-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 36,
"content": "Technische Analyse und Konzeptprüfung des beA {R3} Risikobewertung: A-Betriebsverhindernd Der Angriff steht nur einem Innentäter oder erfolgreich eingedrungenen Außentäter zur Verfügung, der Zugriff auf den Übertragungsweg zwi- schen beA-Anwendung und OCSP-Relay hat. Ist der Zugriff vorhanden, ist die Durchführung des Angriffs einfach. Ausnutzbarkeit: mittel Bewertung der Bedrohung: Signierte Nachrichten des OCSP-Relays, die Gültigkeitsauskunft über qualifizierte Signaturzertifikate geben, können unter Ausnutzung der Schwachstelle verfälscht werden mit der Folge, dass der Prüfbericht über eine Nachricht beim Empfänger falsch Auskunft über den Status einer qualifizierten Signatur gibt. Die Bedrohung der Integrität ist daher hoch. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: niedrig {M3} Die Referenz des signierten Elements sollte die Lokalität mit abdecken. Z.B. realisierbar mittels einer absoluten XPath-Expression. 3.5.4 Veraltete Softwareelemente Untersuchungsobjekt beA-Client-Security Schwachstellenstatus - In der auf dem Computer installierten beA-Client-Security gibt es eine Funktion zum Anzeigen der installierten Third-Party-Bibliotheken. Unter dieser Funktion wird eine größere Liste von Softwarekomponenten aufgeführt. Die folgenden Third-Party- Bibliotheken sind installiert aber nicht aktuell (zum Zeitpunkt der Analyse): ■ Apache Commons Code ■ Apache Fontbox Installiert: 1.10 Installiert 2.0.5 ■ Apache Commons Com- ■ Apache PDFBox press Installiert: 2.0.5 Installiert: 1.4.1 ■ Apache Jackson ■ Apache Commons IO Installiert: 2.9.3 Installiert: 2.4 ■ GlassFish Community ■ Apache Commons Lang Installiert: 3.1.0 Installiert: 3.0 ■ Apache Log4J Installiert: 2.10.0 Version: 1.0 Stand: 18.06.2018 Seite 36",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p36-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 37,
"content": "Technische Analyse und Konzeptprüfung des beA ■ Jetty Websocket ■ Apache XML Security Installiert: 9.4.8 Installiert: 2.1.0 {S4} Verwendete Softwarebibliotheken bzw. Softwareelemente sind veraltet und enthalten öffentlich bekannte Sicherheitslücken . {R4} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit der Schwachstelle Im Allgemeinen identifizieren und veröffentlichen Softwarehersteller oder auch Sicherheitsforscher regelmäßig Schwachstellen zu verschiedenen Softwareprodukten. Je nach Art der Veröffentlichung, wird auch bereits der Angriffscode zum Ausnutzen der Schwachstelle mitgeliefert. An jeder Stelle, an der die Softwareelemente genutzt werden und der Angreifer Zugriff hat, kann er versuchen diese anzugreifen. Nicht alle aufgeführten Softwareelemente haben sicherheitsrelevante Updates. Fehlen allerdings sicherheitsrelevante Updates wie für Apache Jackson, kann ein Angreifer diese ausnutzen. Angriffe können entweder beim Besuchen von Webseiten über einen Browser oder wenn der Angreifer sich bereits eingeschränkt auf dem Benutzersystem befindet durchgeführt werden. . Ausnutzbarkeit: mittel Bewertung der Bedrohung Bei einem erfolgreichen Angriff kann der Angreifer das System des beA- Nutzers eingeschränkt kompromittieren. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: mittel Bedrohung Vertraulichkeit: mittel {M4} Alle Softwareelemente für die sicherheitsrelevante Updates verfügbar sind, sollten aktualisiert werden. 3.6 Beschreibung der B-Schwachstellen In dem nachfolgenden Kapitel werden alle im Bereich der Penetrationstest identifi- zierten Schwachstellen der Kategorie B der Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit des Zielsystems beschrieben. Jede Schwachstelle wird in einem Unterkapitel aufgeführt und die dazugehörige technische Komponente benannt. Die Methodik und Vorgehensweise der Schwachstellenbeschreibung, der Definition der Risikobewertung, der Ausnutzbarkeit der Schwachstelle sowie zur Einstufung der Bedrohungen wurden in Kapitel 2 aufgeführt Version: 1.0 Stand: 18.06.2018 Seite 37",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p37-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 38,
"content": "Technische Analyse und Konzeptprüfung des beA 3.6.1 Veraltete Javascript-Bibliotheken in der beA-Anwendung Untersuchungsobjekt beA-Anwendung Schwachstellenstatus verifiziert: Schwachstelle nicht behoben {S5} Die beA-Anwendung verwendet veraltete Javascript-Bibliotheken (jQuery und Bootstrap) mit bekannten Schwachstellen. Der Angriff zielt auf die Benutzer der beA-Anwendung ab und betrifft nicht die Sicherheit der beA-Anwendung selbst. Zum Zeitpunkt der Analyse konnten die nachfolgenden veralteten Versionen identifiziert werden JQuery 1.11.3 Bootstrap 3.3.2 . {R5} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle Je nach Einbindung der Javascript-Bibliotheken können erfolgreiche An- griffe durchgeführt werden. Können die Schwachstellen der veralteten Software-Komponenten tatsächlich ausgenutzt werden, kann ein Angrei- fer beispielsweise einen manipulierten Link auf die bea-brak.de Websei- te erstellen und diesen per Nachricht an einen Nutzer der bea-brak.de Seite oder an beliebige andere Nutzer schicken. Klickt der Nutzer auf den manipulierten Link, so wird ihm eine manipulierte Webseite unter der Domain bea-brak.de angezeigt. Auszug zur JQuery Schwachstelle der genannten Version: CVE-2015-9251 Ausnutzbarkeit: mittel Bewertung der Bedrohung Ein Angreifer könnte die Schwachstellen dieser Versionen ausnutzen, um unerwünschte Skripte auf dem Rechner eines Opfers auszuführen. So kann unter der vertrauenswürdigen beA-Domäne Angriffscode hinter- legt werden. Phishing Angriffe können durchgeführt werden. Bedrohung Integrität: mittel Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: niedrig {M5} Die genannten Software-Bibliotheken sollten aktualisiert werden. Version: 1.0 Stand: 18.06.2018 Seite 38",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p38-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 39,
"content": "Technische Analyse und Konzeptprüfung des beA 3.6.2 Überschreiben von Dateien Untersuchungsobjekt Client der Regionalen Anwaltskammern (Kammersoftware) Schwachstellenstatus - Sowohl der Upload als auch der Download von CSV-Dateien an dem zugehörigen Webservice des RAK-Client ist anfällig für sog. Path-Traversal Angriffe. Bei diesen Angriffen wird die Funktionalität zum Ablegen von Dateien missbraucht. So kann bei einem Download der Speicherort der Datei von einem Angreifer festgelegt werden. Bei einem Upload der CSV-Datei schien es während der Analyse auch serverseitig möglich, den Speicherort zu manipulieren. Dies konnte während der Analyse aller- dings nicht final verifiziert werden. {S6} Sowohl der Upload als auch der Download von CSV-Dateien an dem zugehörigen Webservice des Kammersoftware ist anfällig für Path- Traversal Angriffe. . {R6} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle Clientseitig: Kann sich ein Angreifer per Man-In-The-Middle in die Kom- munikation einschalten, so kann er eingeschränkt Daten innerhalb des Client-Dateisystems schreiben und so weitere Angriffe auf den Client durchführen. Serverseitig: Der Angreifer benötigt den Kammersoftware, welcher nur den regionalen Anwaltskammern vorbehalten ist sowie ein dazugehöri- ges Client-Zertifikat. Ist der (nicht verifizierte) Path-Traversal serverseitig erfolgreich, so kann der Angreifer das Zielsystem massiv manipulieren. Ausnutzbarkeit: niedrig Bewertung der Bedrohung Clientseitig: Bei einem erfolgreichen Angriff kann der Angreifer versu- chen das Clientsystem zu kompromittieren, um so Kontrolle über das Clientsystem zu erhalten und weitere Angriffe durchzuführen. Serverseitig: Bei einem erfolgreichen Angriff kann der Angreifer den be- troffenen Server kompromittieren, Daten überschreiben oder möglicher- weise eingeschränkte Kontrolle über das Zielsystem erhalten. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: mittel Bedrohung Vertraulichkeit: niedrig {M6} Die Content-ID sollte keinen Pfadwechsel erlauben und auf die Kammer des Clients beschränkt werden. Das serverseitige erfolgreiche Ausnut- zen der Schwachstelle wurde nicht verifiziert, sollte aber trotzdem in je- dem Falle überprüft werden Version: 1.0 Stand: 18.06.2018 Seite 39",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p39-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 40,
"content": "Technische Analyse und Konzeptprüfung des beA 3.6.3 Session-ID als GET Parameter in der URL Untersuchungsobjekt beA-Client-Security und beA-Anwendung Schwachstellenstatus verifiziert: Schwachstelle nicht behoben {S7} Innerhalb des normalen Nutzungsverlaufs der beA-Client-Security mit der beA-Anwendung wird die Session-ID als GET-Argument innerhalb der URL an die beA-Anwendung übermittelt. {R7} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle Angreifer könnten durch Auslesen der Sitzungsinformationen, z.B. aus dem Log eines Webproxys mit TLS-Interception oder aus lokalen De- bug-Logdaten, eingeschränkt die Identität des betroffenen Benutzers in der beA-Anwendung übernehmen. Ausnutzbarkeit: niedrig Bewertung der Bedrohung Durch erfolgreiches Auslesen der Sitzungsinformationen kann die be- troffene Identität eingeschränkt von dem Angreifer angenommen wer- den. Alle Mechanismen innerhalb der beA-Anwendung, welche ohne die beA-Karte nutzbar sind, können von dem Angreifer durchgeführt wer- den. Die Bedrohung der Integrität ist hoch, da der Angreifer wie genannt eingeschränkt mit der Identität des betroffenen Nutzers agieren kann und beispielsweise Nachrichten verschicken kann. Die Verfügbarkeit der beA-Anwendung kann dadurch gestört werden, dass eine aktive Sitzung von dem Angreifer übernommen und somit die allgemeine Prozessinteg- rität gestört wird. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: mittel Bedrohung Vertraulichkeit: niedrig {M7} Die Exposition der Sitzungsinformationen sollte möglichst gering sein, um Session-Hijacking zu verhindern. Die Sitzungsinformationen sollten nicht als Teil der URLs übertragen werden. 3.6.4 Transportverschlüsselung der beA-Anwendung: Client-TLS-Renegotiation Untersuchungsobjekt beA-Anwendung Schwachstellenstatus verifiziert: Schwachstelle behoben Verfahren zur Verschlüsselung von Inhalten veralten und müssen an neue Gege- benheiten angepasst werden. Es wurde geprüft, ob in der Kommunikationsverbin- dung von dem Browser zur beA-Anwendung aktuelle Algorithmen verwendet werden und ob sonstige Schwachstellen vorhanden sind. Die hier betrachtete Version: 1.0 Stand: 18.06.2018 Seite 40",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p40-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 41,
"content": "Technische Analyse und Konzeptprüfung des beA Transportverschlüsselung hat nichts mit der Verschlüsselung oder Kryptographie der im beA-Kontext verschlüsselt übertragenen Nachrichten oder Anhänge zu tun. {S8} Der beA-Anwendungsserver bietet Client-TLS-Renegotiation an. {R8} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle Um den Angriff durchzuführen muss der Angreifer sich zwischen die Kommunikationspartner schalten können. Dies kann er beispielsweise, wenn er bereits auf einem dritten Weg (eingeschränkt) Zugriff auf den Benutzer-Client des Anwenders hat. Ein weiteres Szenario wäre ein Man-In-The-Middle Angriff innerhalb eines öffentlich zugänglichen WLAN. Ausnutzbarkeit: niedrig Bewertung der Bedrohung Durch einen erfolgreichen Man-In-The-Middle Angriff und somit das Aus- lesen der Sitzungsinformationen kann die betroffene Identität einge- schränkt von dem Angreifer angenommen werden. Alle Mechanismen innerhalb der beA-Anwendung, welche ohne die beA-Karte nutzbar sind, können von dem Angreifer durchgeführt werden. Die Bedrohung der In- tegrität ist hoch, da der Angreifer wie genannt eingeschränkt mit der Identität des betroffenen Nutzers agieren und beispielsweise Nachrich- ten verschicken kann. Die Verfügbarkeit der beA-Anwendung kann überdies gestört werden, da eine aktive Sitzung von dem Angreifer übernommen wird. Die allgemeine Prozessintegrität wird somit gestört. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: mittel Bedrohung Vertraulichkeit: niedrig {M8} Die Konfiguration „secure client-initiated regenotiation“ sollte auf dem Server deaktiviert werden. 3.6.5 Transportverschlüsselung der beA-Client-Security: Client-TLS-Renegotiation Untersuchungsobjekt beA-Client-Security Schwachstellenstatus verifiziert: Schwachstelle behoben Es wurde geprüft, ob in der Kommunikationsverbindung von dem Browser zur beA- Client-Security aktuelle Algorithmen verwendet werden und ob sonstige Schwach- stellen vorhanden sind. Die hier betrachtete Transportverschlüsselung hat nichts mit der Verschlüsselung oder Kryptographie der im beA-Kontext verschlüsselt übertra- genen Nachrichten oder Anhänge zu tun. Version: 1.0 Stand: 18.06.2018 Seite 41",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p41-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 42,
"content": "Technische Analyse und Konzeptprüfung des beA {S9} Die beA-Client-Security bietet Client-TLS-Renegotiation an. {R9} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle Um den Angriff durchzuführen muss der Angreifer sich zwischen die Kommunikationspartner schalten können. Dies kann er beispielsweise, wenn er bereits auf einem dritten Weg (eingeschränkt) Zugriff auf den Benutzer-Client des Anwenders hat. Ausnutzbarkeit: niedrig Bewertung der Bedrohung Durch einen erfolgreichen Man-In-The-Middle Angriff und somit das Aus- lesen der Sitzungsinformationen kann die betroffene Identität einge- schränkt von dem Angreifer angenommen werden. Alle Mechanismen innerhalb der beA-Anwendung, welche ohne die beA-Karte nutzbar sind, können von dem Angreifer durchgeführt werden. Die Bedrohung der In- tegrität ist hoch, da der Angreifer wie genannt eingeschränkt mit der Identität des betroffenen Nutzers agieren und beispielsweise Nachrich- ten verschicken kann. Die Verfügbarkeit der beA-Anwendung kann überdies gestört werden, da eine aktive Sitzung von dem Angreifer übernommen wird. Die allgemeine Prozessintegrität wird somit gestört. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: mittel Bedrohung Vertraulichkeit: niedrig {M9} Die Konfiguration „secure client-initiated regenotiation“ sollte auf dem Server deaktiviert werden. 3.6.6 Transportverschlüsselung der beA-Client-Security: Logjam Untersuchungsobjekt beA-Client-Security Schwachstellenstatus verifiziert: Schwachstelle behoben Verfahren zur Verschlüsselung von Inhalten veralten und müssen an neue Gege- benheiten angepasst werden. Es wurde geprüft, ob in der Kommunikationsverbin- dung von dem Browser zur beA-Client-Security aktuelle Algorithmen verwendet werden und ob sonstige Schwachstellen vorhanden sind. Die hier betrachtete Transportverschlüsselung hat nichts mit der Verschlüsselung oder Kryptographie der im beA-Kontext verschlüsselt übertragenen Nachrichten oder Anhänge zu tun. Version: 1.0 Stand: 18.06.2018 Seite 42",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p42-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 43,
"content": "Technische Analyse und Konzeptprüfung des beA {S10} Der verwendete lokale Webserver der beA-Client-Security ist für den Logjam-Angriff anfällig. {R10} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle Um den Angriff durchzuführen zu können muss der Angreifer sich zwi- schen die Kommunikationsverbindung schalten können. Dies kann er beispielsweise, wenn er bereits auf einem dritten Weg (eingeschränkt) Zugriff auf den Benutzer-Client des Anwenders hat. Siehe dazu auch: https://weakdh.org/ Ausnutzbarkeit: niedrig Bewertung der Bedrohung Durch einen erfolgreichen Man-In-The-Middle Angriff und somit das Aus- lesen der Sitzungsinformationen kann die betroffene Identität einge- schränkt von dem Angreifer angenommen werden. Alle Mechanismen innerhalb der beA-Anwendung, welche ohne die beA-Karte nutzbar sind, können von dem Angreifer durchgeführt werden. Die Bedrohung der In- tegrität ist hoch, da der Angreifer wie genannt eingeschränkt mit der Identität des betroffenen Nutzers agieren kann und beispielsweise Nach- richten verschicken kann. Die Verfügbarkeit der beA-Anwendung kann auch gestört werden, da eine aktive Sitzung von dem Angreifer über- nommen wird. Die allgemeine Prozessintegrität wird somit gestört. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: mittel Bedrohung Vertraulichkeit: niedrig {M10} Die unsicheren cipher suites sollten auf dem Server deaktiviert werden. 3.6.7 Detaillierte Fehlermeldungen der Webapplikationsfirewall Untersuchungsobjekt beA-Anwendung Schwachstellenstatus verifiziert: Schwachstelle nicht behoben Eine Webapplikationsfirewall (kurz WAF) versucht bei Anfragen an Webanwendun- gen verdächtige Inhalte von Angreifern zu erkennen und zu blockieren. So sollen ty- pische Angriffe auf Webanwendungen erkannt und abgewehrt werden. Die beA- Anwendung nutzt auch eine solche Technologie. {S11} Die WAF zeigt den Hersteller, die genaue Version der WAF sowie detail- lierte Fehlermeldungen an. {R11} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle Werden bekannte Angriffsmuster an den Server gesendet, werden diese Version: 1.0 Stand: 18.06.2018 Seite 43",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p43-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 44,
"content": "Technische Analyse und Konzeptprüfung des beA von der Webapplikationsfirewall erkannt und blockiert. Die entsprechen- de Fehlermeldung wird angezeigt. Ausnutzbarkeit: hoch Bewertung der Bedrohung Wird eine Fehlermeldung der WAF an den Angreifer zurückgegeben, kann dieser seinen gerade durchgeführten Angriff weiter detaillieren. Da die Fehlermeldung den genauen Aufruf des Angreifers und die Stelle, die die WAF als gefährlich einstuft, zurückgibt, kann der Angreifer gezielt versuchen die WAF zu umgehen und seinen ursprünglichen Angriff er- folgreich durchführen. Die Analyse wurde auf der Testumgebung des beA durchgeführt. Zu Test, Entwicklungs- und Debugzwecken ist es üblich, diese Detailtiefe von Fehlermeldungen anzuzeigen. Wird die serverseitige Konfiguration der WAF auf der Produktionsumgebung oder auf weiteren dritten Sys- temumgebungen allerdings nicht angepasst, kann diese Schwachstelle erfolgreich ausgenutzt werden Bedrohung Integrität: niedrig Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: niedrig {M11} Die angezeigten Fehlerseiten sollten keinen Hinweis auf den Inhalt von Fehlermeldungen der Webapplikationsfirewall enthalten. 3.6.8 Schwache Lock-Out-Mechanismen in der beA-Anwendung Untersuchungsobjekt beA-Anwendung Schwachstellenstatus verifiziert: Schwachstelle behoben {S12} Account Lock-Out-Mechanismen werden vornehmlich gegen Brute- Force-Angriffe auf Benutzerpasswörter eingesetzt. Die beA-Anwendung setzt keinen Lock-Out-Mechanismus für die Anmeldung eines Mitarbei- ters ein. {R12} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle Ein Angreifer kann automatisiert versuchen Benutzer-Passwörter zu er- raten. Hierfür können gängige Angriffstools verwendet werden: Bei- spielsweise einzelne frei im Internet verfügbare Tools oder auch ein Botnetz. Ausnutzbarkeit: hoch Bewertung der Bedrohung Der hier betroffene Zugang wird einmalig und initial für einen bestimm- ten Anwendungsfall genutzt, wenn sich neue Benutzer registrieren. Da Version: 1.0 Stand: 18.06.2018 Seite 44",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p44-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 45,
"content": "Technische Analyse und Konzeptprüfung des beA in jedem Fall für eine vollständige Anmeldung an der beA-Anwendung die Zwei-Faktor Authentisierung genutzt werden muss, kann ein Angrei- fer selbst bei einer erfolgreich Nutzername/Passwort Kombination kaum etwas mit diesem Zugang anfangen. Entsprechend niedrig sind die Be- drohungen eingestuft. Bedrohung Integrität: niedrig Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: niedrig {M12} Es sollte ein Lock-Out-Mechanismus implementiert werden, der Benut- zer-Accounts nach einer definierten Anzahl von fehlgeschlagenen Login- Versuchen temporär sperrt. Alternativ kann auch ein Captcha in den Lo- gin-Prozess integriert werden. 3.6.9 Qualität der genutzten Session-Cookies Untersuchungsobjekt beA-Anwendung Schwachstellenstatus verifiziert: Schwachstelle nicht behoben Session-IDs sind nach der beA-Karte und der dazugehörigen PIN das zentrale Au- thentisierungsmerkmal bei der Benutzung eines Webportals. Entsprechend sicher müssen die Initiierung und der Transport von Session-IDs realisiert werden. Abbildung 4: Session-Cookie-Entropie, Quelle: Burp Suite Professional Version: 1.0 Stand: 18.06.2018 Seite 45",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p45-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 46,
"content": "Technische Analyse und Konzeptprüfung des beA {S13} Die statistische Qualität der SessionID ist gut, aber nicht optimal. (ca. 57 Bit Entropie bei 1% Signifikanz) {R13} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle Ein Angreifer kann automatisiert versuchen entsprechende Session- Cookies zu erraten. Hierfür können gängige Tools verwendet werden: Beispielsweise einzelne frei im Internet verfügbare Tools oder auch ein Botnetz genutzt werden, um möglichst schnell viele Sessions und somit Zugänge zu erraten. Die Erfolgswahrscheinlichkeit ist allerdings auch bei der genannten Entropie sehr gering. Ausnutzbarkeit: niedrig Bewertung der Bedrohung Kann ein Angreifer die Sitzungsinformationen erraten, kann die betroffe- ne Sitzung und somit die betroffene Identität eingeschränkt von dem Angreifer angenommen werden. Alle Mechanismen innerhalb der beA- Anwendung, welche ohne die beA-Karte nutzbar sind, können von dem Angreifer durchgeführt werden. Die Bedrohung der Integrität ist hoch, da der Angreifer eingeschränkt mit der Identität des betroffenen Nutzers agieren und beispielsweise Nachrichten verschicken kann. Die Verfüg- barkeit der beA-Anwendung kann auch gestört werden, da eine aktive Sitzung von dem Angreifer übernommen wird. Die allgemeine Prozes- sintegrität wird somit gestört. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: mittel Bedrohung Vertraulichkeit: niedrig {M13} Das Generieren der Session sollte mit kryptographischen Zufallszahlen- generatoren durchgeführt und in Bezug auf die Entropie geprüft werden. Eine effektive Entropie von mindestens 64 Bit bei 1% Signifikanz wird empfohlen. Eine exzellente Entropie sollte bei 128 Bit sein. 3.6.10 Automatisches Ausführen und Öffnen von Dateien Untersuchungsobjekt beA-Anwendung Schwachstellenstatus - Benutzer, die in der beA-Anwendung angemeldet sind, können empfangene Nach- richten mit Anhängen betrachten. Die beA-Anwendung besitzt dafür eine „Anhang anzeigen“- sowie eine separate „Speichern“-Funktion. Version: 1.0 Stand: 18.06.2018 Seite 46",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p46-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 47,
"content": "Technische Analyse und Konzeptprüfung des beA {S14} Anhänge werden basierend auf den Dateiendungen auf dem Benutzer- system ausgeführt. {R14} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle Eine manipulierte Datei wird auf dem Angreifer-System erstellt und dann an den Ziel-Empfänger versendet. Für das Erstellen solcher manipulier- ten Dateien kann auf bekannte Frameworks in der Security-Szene zu- rückgegriffen werden. Entsprechend einfach ist die Erstellung solcher Dateien. Es wird allerdings davon ausgegangen, dass unbekannte Da- teitypen zumindest Misstrauen beim Empfänger auslösen sollten und nicht einfach geöffnet werden. Die Schwachstelle wird ausgenutzt, wenn der betroffene Benutzer auf „Anzeigen“ des Anhangs klickt. Ausnutzbarkeit: niedrig Bewertung der Bedrohung Trotz der Ablehnung der beA-Anwendung von exe-, com-, bat-, cmd- und lnk-Dateien kann ein Angreifer diese Schwachstelle ausnutzen, um einen Angriff auf das Benutzersystem des Datei-Empfängers durchzu- führen. Bei Word-, sowie Excel-Dateien oder Bildern kann davon ausgegangen werden, dass der Benutzer der beA-Anwendung Kenntnis hat, was er hiermit öffnet. Bei einem ps1 oder sonstigem Script-Dokumenten eher nicht. Natürlich kann auch nach dem Abspeichern eine potenziell mani- pulierte Datei Schaden anrichten. Hier ist sich der Benutzer allerdings bewusst, dass er eine aus dem Internet erhaltene Datei auch tatsächlich auf seinem eigenen System öffnet bzw. ausführt. Dies gilt sowohl für MacOS, Linux und Windows spezifische Dateien. Wird eine manipulierte Datei erfolgreich ausgeführt, kann der Angreifer das Benutzersystem kompromittieren und Kontrolle über dieses erhalten. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: hoch Bedrohung Vertraulichkeit: hoch {M14} Es existieren viele weitere Dateiendungen mit Potenzial für Angreifer. Das Nachrichtenformat-Modul sollte keine Datei automatisch vom Inter- net auf dem lokalen Rechner ausführen. Es wird empfohlen eine White- list für „vertrauenswürdigen“ Inhalt zu erstellen. Diese könnte beispielsweise Dateitypen wie docx, xlsx, pdf, txt, und csv enthalten. Ei- ne abgestimmte Whitelist könnte ca. 80% der versendeten Anhänge freigeben und für die restlichen 20% müsste dann die Speichern- Funktion verwendet werden. Eine Blacklist ist aufgrund der Vielfältigkeit von Linux, Windows und MacOS nicht zielführend. So gibt es diverse weitere ausführbare Dateitypen, die der Endanwender nicht einschätzen kann (z.B. ps1, ps1xml, ps2, ps2xml, psc1, psc2, msi, sh…). Version: 1.0 Stand: 18.06.2018 Seite 47",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p47-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 48,
"content": "Technische Analyse und Konzeptprüfung des beA 3.6.11 Modifikation von signierten XML-Nachrichten Untersuchungsobjekt Webservice OSCI Intermediär BRAK Schwachstellenstatus - {S15} Bei der Verwendung von signierten XML-Nachrichten sind keine Vor- sichtsmaßnahmen getroffen worden, um den Inhalt der signierten Nach- richt der XML-Nachricht gegen Modifikation zu schützen. {R15} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle: Der Angriff steht nur einem Innentäter oder erfolgreich eingedrungenen Außentäter zur Verfügung, der Zugriff auf den Übertragungsweg zwischen Webservice-OSCI und Intermediär BRAK hat. Ist der Zugriff vorhanden, ist die Durchführung des Angriffs einfach. Ausnutzbarkeit: mittel Bewertung der Bedrohung . Der Angriff erlaubt, die Container-Signatur einer OSCI-Nachricht zu umge- hen, um den Nutzdatenteil der OSCI-Nachricht zu manipulieren. Betroffen ist der Nachrichtenaustausch zwischen beA und EGVP. Es können so z.B. Anhänge entfernt werden. Es besteht eine mittlere Bedrohung der Nach- richtenintegrität. Die Nachrichteninhalte können mit diesem Angriff nicht eingesehen werden, weil sie verschlüsselt bleiben. Bedrohung Integrität: mittel Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: niedrig {M15} Die Referenz des signierten Elements sollte die Lokalität mit abdecken. Z.B. realisierbar mittels einer absoluten XPath-Expression. 3.6.12 Logdaten: Detaillierte Struktur der REST-Endpunkte Untersuchungsobjekt beA-Client-Security Schwachstellenstatus verifiziert: Schwachstelle nicht behoben Die beA-Client-Security speichert in ihrem Nutzungskontext je nach Einstellung des Log-Levels Daten und Informationen in den lokalen Logdateien auf dem Dateisys- tem des Benutzers. {S16} Innerhalb den Logdateien stehen Informationen, welche sensible Inhalte darstellen und einem Angreifer im Allgemeinen seine Angriffe erleich- tern. Beispielsweise werden detaillierte REST-Endpunkte in der beA- Version: 1.0 Stand: 18.06.2018 Seite 48",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p48-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 49,
"content": "Technische Analyse und Konzeptprüfung des beA Anwendung mit konkreten Sitzungsinformationen oder Parametern ab- gespeichert. {R16} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle; Ein Angreifer mit lokal installierter bea-Client-Security kann die Logda- teien auf seinem eigenen persönlichen Betriebssystem einsehen. Ausnutzbarkeit: hoch Bewertung der Bedrohung; Durch den Informationsgewinn über die REST-Endpunkte innerhalb der beA-Anwendung sowie auch über die Schnittstellen, welche bestimmte und konkrete Parameter erwarten, kann ein Angreifer gezielter die beA- Anwendung angreifen oder auch neue Angriffsvektoren identifizieren. Über diesen Weg konnten im Rahmen der Analyse weitere Schwach- stellen identifiziert werden. Bedrohung Integrität: niedrig Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: niedrig {M16} Die Logs sollten auf Produktiv-Installationen keine detaillierten Hinweise über die Anwendung geben. 3.6.13 Nicht konsistente Zertifikatsprüfung Untersuchungsobjekt Kammersoftware Schwachstellenstatus - {S17} Der Client prüft den Common Name (CN) des Zertifikats nicht. Dadurch wird jedes Zertifikat akzeptiert, welches durch eine Certificate Authority (CA) aus dem Keystore ausgestellt wurde. Da wenige CAs den Großteil der HTTPS Verbindungen des Internets absichern, ist es wichtig die Details der Zertifikate zu prüfen. Insbesondere der CN muss geprüft werden um ver- schiedene Webseiten voneinander zu unterscheiden {R17} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle; Eine Nutzerinteraktion des betroffenen Nutzers ist nicht nötig. Die Kam- mersoftware läuft wie gewohnt und baut regelmäßig eine Netzwerkverbin- dung auf. Der Angreifer braucht keine Berechtigungen innerhalb des beA- Systems, muss aber Zugriff auf den Datenverkehr haben, um den Angriff durchführen zu können. Dies kann an einer beliebigen Stelle zwischen Kammersoftware und dem beA-Endpunkt erfolgen, beispielsweise im loka- len Netz der Kammersoftware (unsichere Konfiguration des Firmennetz- werkes oder offenes WLAN), im Internet (Manipulation von DNS oder Routing, Massen Überwachung an Internetknoten wie dem DE-CIX) oder Version: 1.0 Stand: 18.06.2018 Seite 49",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p49-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 50,
"content": "Technische Analyse und Konzeptprüfung des beA innerhalb des beA-Netzwerkes (siehe Kammersoftware). Lokaler Zugriff ist auf das Betriebssystem des Clients ist nicht nötig. Ausnutzbarkeit: mittel Bewertung der Bedrohung; Ein Angreifer der für seine eigene Domain von einer im Keystore enthalte- nen CA ein Zertifikat erhalten hat, kann sich der Kammersoftware gegen- über als beA ausgeben. Dadurch kann dieser eine verschlüsselte Verbindung anstelle des beA annehmen. Bedrohung Integrität: mittel Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: niedrig {M17} Der Client sollte die Zertifikate der Gegenstelle vollständig prüfen. Version: 1.0 Stand: 18.06.2018 Seite 50",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p50-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 51,
"content": "Technische Analyse und Konzeptprüfung des beA 3.7 Auflistung der C-Schwachstellen In dem nachfolgenden Kapitel werden nun alle im Bereich der Penetrationstests identifizierten Schwachstellen der Kategorie C aufgelistet und in verkürzter Form dargestellt. Tabelle 9: Pentest C-Schwachstellen Legende: h=hoch; m=mittel; n=niedrig; J=Ja Bedrohung Ausnutzbarkeit Schwachstelle Vertraulichkeit Verfügbarkeit Integrität behoben Kurzbeschreibung Komponente Die REST-API des Wikis ist öffentlich erreichbar und Webportal m n n n - stellt teilweise sensible Informationen bereit, die für den XWIKI Anwendungszweck des Wikis nicht benötigt werden. Das Portal ist anfällig für eine Reflected-XSS- Webportal n n n m - Schwachstelle, die jedoch nicht ohne Weiteres auszu- XWIKI nutzen ist. Das Webportal hat eine XSS-Schwachstelle. Webportal n n m n - BRAV-Suche Der Webservice gibt Fehlerbezeichnungen mit Paketna- Webservice m n n n - men und Stack-trace an den Client weiter, wodurch Kanzlei-SAFE Rückschlüsse auf die Architektur möglich sind. BRAK In den Logdateien der lokal installierten beA-Client- beA-Client- m n n n - Security des Benutzers findet sich die Session-ID der Security Anwendung. Die Analyse des Datenverkehrs ergab, dass auf einem beA- n n n n - Großteil der betrachteten Seiten mit vertraulichen Anwendung Inhalten der Browser-Cache nicht deaktiviert wird. Die Passwort-Policy für den Mitarbeiterlogin ist nicht beA- m n n n J ausreichend, da kein Brute-Force Schutz vorhanden ist. Anwendung Das Passwortfeld auf der Anmeldeseite „Registrierung beA- m n n n J beA Benutzer“ begrenzt die Eingabe eines Passwortes Anwendung auf 8 Zeichen. An mehreren Stellen innerhalb der Web-Applikation beA- m n n n - können Fehlermeldungen ausgelöst werden. Anwendung Der Webservice gibt Fehlerbezeichnungen aus Java an Webservice m n n n - den Client weiter, die Rückschlüsse auf die Architektur Attribute- zulassen. Service VAS => SAFE BRAK Passphrasen werden im Klartext gespeichert. Kammersoft- m n n n - ware Der Webserver gibt per HTTP-Server-Header seine Kammersoft- m n n n - genaue Version preis. ware Endpunkte Der Webservice gibt im Response-Header die Server- Webservice m n n n - Version: 1.0 Stand: 18.06.2018 Seite 51",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p51-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 52,
"content": "Technische Analyse und Konzeptprüfung des beA Legende: h=hoch; m=mittel; n=niedrig; J=Ja Bedrohung Ausnutzbarkeit Schwachstelle Vertraulichkeit Verfügbarkeit Integrität behoben Kurzbeschreibung Komponente Software und -Versionsnummer über das Server- Find a Lawyer Response-Header-Feld bekannt. Der Webservice gibt Fehlerbezeichnungen aus Java an Find a Lawyer m n n n - den Client weiter, die Rückschlüsse auf die Architektur zu lassen. Der Webservice gibt im Response-Header Server Webservice m n n n - Software und Versions-nummer bekannt über das BNotK Post- Server-Response-Header-Feld. fach-beA- Postfach Der Webservice gibt Fehlerbezeichnungen aus Java an Webservice m n n n - den Client weiter, die Rückschlüsse auf die Architektur BNoTK zu lassen. Postfach-beA- Postfach Der Webserver gibt auf Fehlerseiten seine genaue Xwiki m n n n - Version und Stack-Traces preis. Es konnte eine Benutzerlogin-Maske öffentlich abgerufen Xwiki m n n n - werden, die durch einen Angreifer ausgenutzt werden könnte und keinen Schutz vor Brute-Force-Angriffen oder lokaler Passwort-Speicherung bietet. Auf dem Server konnten Stack-Trace-Meldungen Xwiki m n n n - hervorgerufen werden, die ggf. für weitere Angriffe genutzt werden könnten. Version: 1.0 Stand: 18.06.2018 Seite 52",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p52-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 53,
"content": "Technische Analyse und Konzeptprüfung des beA 4 Quelltextanalysen 4.1 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 Dokumentati- on in unterschiedlichen Versionen bereitgestellt. Die zur Verfügung gestellten Sour- cen wurden zum einen in Form von lauffähigen Java-Projekten (Client-Security) und zum Teil in Form von *.jar, *.war oder *.ear Dateien ausgeliefert. Die beA-Client-Security in Version 3.1.3.6 wurde einer statischen Quelltextanalyse unterzogen. Der Quelltext-Audit sowie die erneuten Tests der zuvor gemeldeten Schwachstellen erfolgten auf Basis der Version 3.1.3.7. Die beA-Anwendung wurde einer statischen Quelltextanalysen unterzogen. Unter- sucht wurde die Version 2.0.10 sowie die Version 2.1.0. Für die Überprüfung der als behobenen gemeldeter Schwachstellen wurde die Version 2.1.1 genutzt. Bibliotheken, die während der Laufzeit vom Application-Server (JBoss EAP) zur Ver- fügung gestellt werden, konnten nicht betrachtet werden und sind somit nicht Be- standteil des Reviews. Dabei handelt es sich nicht nur um JEE-Bibliotheken, sondern auch um Bibliotheken wie die Verschlüsselungsbibliothek BouncyCastle oder die JSF-Implementierung Primefaces. Die BRAV-Search wurde in der Version 1.2.0 einer statischen Quelltextanalyse un- terzogen. 4.2 Methodik und Vorgehensweise Angewandt wurden werkzeuggestützte statische Quelltextanalysen und ein Quell- text-Audit. Werkzeuggestützte Quelltextanalysen überprüfen den gesamten Java-Quelltext an- hand eines vordefinierten Regelwerks. Dieses Regelwerk wurde von der Open- Source-Gemeinde erstellt und wird regelmäßig erweitert und gepflegt. Abhängig vom eingesetzten Regelwerk und Werkzeug werden Treffer in unterschiedliche Ka- tegorien eingeordnet. Die Treffer können unsauberen Code bis hin zu schwerwie- genden 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 ein Code Review erfolgen. Konzepti- onelle 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 Indikator für Code-Qualität. Version: 1.0 Stand: 18.06.2018 Seite 53",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p53-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 54,
"content": "Technische Analyse und Konzeptprüfung des beA Beim Quelltext-Audit wird im Gegensatz zur statischen Quelltext-Analyse der logi- sche und korrekte Programmablauf überprüft. Werkzeug-Unterstützung, bis auf den Einsatz einer Programmierumgebung, ist nicht vorhanden. Der logische und korrek- te Programmablauf wird anhand des geprüften Use-Cases und des zugehörigen Feinkonzeptes belegt. Logische und software-architektonische Unzulänglichkeiten können erkannt werden. Alle Schwachstellen, die nicht den logischen Ablauf oder die Softwarearchitektur betreffen, werden nicht näher betrachtet. Nach Absprache mit dem Auftraggeber wurde der Quelltext der beA-Client-Security, BRAV-Search und der beA-Anwendung mittels statischer Quelltextanalyse und ei- nem in Umfang und Tiefe begrenzten Quelltext-Audit für die beA-Client-Security auf Schwachstellen überprüft. Bibliotheken wurden auf Basis ihres Versionsstandes nur anhand öffentlich bekann- ter 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 einge- schränkt; ■ 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 möglichen Bedrohung für die Integ- rität des Anwalts-PC und anhand von Erfahrungswerten. 4.3 Übersicht der Schwachstellen Tabelle 10: Schwachstellenübersicht Quelltextanalysen Komponente Schwachstelle Einstu- beho- fung ben beA-Anwendung Mögliche Ausführung von Schadcode (XML) A J beA-Anwendung Java-Abhängigkeiten mit bekannten Schwachstellen A J beA-Client-Security Mögliche Ausführung von Schadcode (JSON) A J beA-Client-Security Mögliche Ausführung von Schadcode (XML) A J beA-Client-Security Verwendete Bibliotheken A J BRAV-Suche Verwendete Bibliotheken A J beA-Anwendung beA-Anwendung: SQL-Injection B - beA-Anwendung Initialisierungs-Vector (IV) B - beA-Anwendung Unsicheres Auffüllen von Daten bei Verschlüsselung B - Version: 1.0 Stand: 18.06.2018 Seite 54",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p54-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 55,
"content": "Technische Analyse und Konzeptprüfung des beA beA-Client-Security TLS-Zertifikate-Validierung B J beA-Client-Security Unfertiger bzw. System-spezifischer Quelltext C - beA-Anwendung Verwundbarkeit über unsichere XML-Deserialisierung C - beA-Client-Security Möglicherweise unsicherer Quelltext - fest vergebene C - Namen für temporäre Dateien Version: 1.0 Stand: 18.06.2018 Seite 55",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p55-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 56,
"content": "Technische Analyse und Konzeptprüfung des beA 4.4 Beschreibung der A-Schwachstellen 4.4.1 beA-Anwendung - Mögliche Ausführung von Schadcode (XML) Untersuchungsobjekt Statische Quelltext-Analyse beA-Anwendung Schwachstellenbehebung verifiziert, behoben Das Deserialisieren von XML-Dateien ist potentiell immer eine Gefahr. Einem 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 die beA-Anwendung zu übernehmen. Hier ist es die beA-Anwendung, die XML-Objekte deserialisiert und von einem au- thentisierten Nutzer dazu gebracht werden kann, Schadcode auf dem Server der beA-Anwendung auszuführen. Dies stellt eine hohe Bedrohung der Integrität der beA-Anwendung dar, was sich mittelbar auch auf die Vertraulichkeit von Nachrich- ten auswirken kann, die unmittelbar allerdings aufgrund ihrer durch die HSM gesi- cherten Verschlüsselung nicht aufgedeckt werden können. Wenn der Angreifer aber in die Verteilung von Postfachschlüsseln an Absender oder die Beantragung von Postfachzertifikaten bei der BNotK eingreifen kann, besteht in Verbindung mit der in Abschnitt 5.4.2 oder der in Abschnitt 5.5.1 beschriebenen Schwachstelle die Gefahr, dass er Nachrichten mitliest. Es können außerdem unmittelbar Kommunikationsbe- ziehungen aufgeklärt werden (Partner, Zeitpunkte). Die Bedrohung für die Systemin- tegrität und –verfügbarkeit ist hoch, die für die Vertraulichkeit der Nachrichten unmittelbar niedrig (in Verbindung mit den oben referenzierten Schwachstellen wäre sie allerdings hoch. Die Ausnutzbarkeit wird als leicht eingeschätzt. {S18} Die beA-Anwendung ist potentiell verwundbar gegenüber XML-Java- Objekt-Deserialisierung. Durch nicht ausreichend konfigurierte Java- Bibliotheken zum Deserialisieren von XML-Dateien ist es einem Angrei- fer potentiell möglich, den Server der beA-Anwendung zu übernehmen. {R18} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit der Schwachstelle: Die Ausnutzung ist durch jeden beA-Anwender möglich und benötigt nur allgemein bekannte Techniken. Die Ausnutzbarkeit ist daher hoch. Ausnutzbarkeit: hoch Bewertung der Bedrohung: Der Angreifer kann den Server der beA-Anwendung übernehmen und dort die Integrität der Nachrichtenverarbeitung beeinträchtigen, mittelbar Version: 1.0 Stand: 18.06.2018 Seite 56",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p56-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 57,
"content": "Technische Analyse und Konzeptprüfung des beA unter Ausnutzung weiterer Schwachstellen auf Nachrichteninhalte zu- greifen. Das Schadenspotential wird für die Integrität und Verfügbarkeit als hoch, für die Vertraulichkeit niedrig bewertet. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: hoch Bedrohung Vertraulichkeit: niedrig Die Kombination aus hoher Bedrohung der Integrität und hoher Aus- nutzbarkeit führt zu einer Bewertung der Schwachstelle als betriebsver- hindernd. {M18} Korrekte Konfiguration der XML Bibliotheken 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 XML-Objekt Deserialisierung so nicht erneut auftreten können. 4.4.2 Java-Abhängigkeiten mit bekannten Schwachstellen Untersuchungsobjekt Statische Quelltext-Analyse beA-Anwendung Schwachstellenbehebung verifiziert, behoben Verwendung veralteter Drittbibliotheken bzw. Verwendung von Drittbibliotheken mit bekannten Schwachstellen. Drittbibliotheken, die zur Laufzeit vom Application Ser- ver zur Verfügung gestellt werden, konnten nicht geprüft werden. Die untersuchten Komponenten der beA-Anwendung verwenden einige Java- basierte Abhängigkeiten, die zum Teil sehr veraltet sind und bekannte Schwachstel- len aufweisen. Diese sind im Einzelnen: ■ not-yet-commons-ssl-0.3.9.jar › CVE-2014-3604 – Cryptographic Issues - CVSS Score 6.8 ■ xercesImpl-2.9.1.redhat-6.jar › CVE-2012-0881 – Denial of Service - CVSS Score 7.8 ■ commons-httpclient-3.1.jar › CVE-2014-3577 – Cryptographic Issues – CVSS Score 5.8 ■ log4j-1.2.17.jar › CVE-2017-5645 - Deserialization of Untrusted Data – CVSS Score 7.5 ■ webservices-rt-2.3.jar › CVE-2013-2566 - Cryptographic Issues – CVSS Score 4.3 ■ bcmail-jdk16-1.46.jar Version: 1.0 Stand: 18.06.2018 Seite 57",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p57-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 58,
"content": "Technische Analyse und Konzeptprüfung des beA › Letzte Aktualisierung 23-Febr-2011 Fortführung als bcmail- jdk15on-159.jar Die Ausnutzbarkeit der Schwachstellen dieser Bibliotheken kann im Rahmen einer statischen Quellcodeanalyse nicht abschließend bewertet werden. Sie kann je nach Schwachstelle und Art der Verwendung der Bibliotheken leicht, mittel oder schwer sein. Für die Risikobewertung wurde eine mittlere Ausnutzbarkeit angenommen. Der potentielle Schaden reicht von einer betriebsverhindernden Störung der beA- Anwendung durch Überlastung oder Absturz einer beA-Anwendungskomponente über ein Aufbrechen von TLS-Verbindungen bis zur Ausführung von Schadcode auf dem beA-Server, also zum vollständigen Verlust der Systemintegrität. Neben diesen Bibliotheken, die direkt den gelieferten Paketen entnommen werden konnten, gibt es noch die Bibliotheken, die der Application-Server zur Laufzeit zur Verfügung stellt. Diese waren nicht Bestandteil des Untersuchungsgegenstandes und müssen vom Betrieb auf Aktualität geprüft und in Rücksprache mit dem Herstel- ler der beA-Anwendung aktualisiert werden. {S19} Für einige verwendete Java-Abhängigkeiten existieren bekannte Schwachstellen. {R19} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit der Schwachstelle: Die Ausnutzbarkeit kann nicht abschließend bewertet werden, sie kann auch je nach Bibliothek und Schwachstelle unterschiedlich sein. Für die Risikoabschätzung wurde eine mittlere Ausnutzbarkeit angenommen. Ausnutzbarkeit: mittel Bewertung der Bedrohung: Ein Angreifer könnte eine veröffentlichte Schwachstelle ausnutzen, um die Integrität oder Verfügbarkeit und/oder Vertraulichkeit zu beeinträchti- gen. Besonders die Schwachstellen bzgl. der SSL/TLS Verbindungen (CVE-2014-3604, CVE-2014-3577, CVE-2013-2566) können ein erhöh- tes Risiko darstellen. Die Bedrohung für die System-Integrität und – Verfügbarkeit wird hoch, für die Vertraulichkeit von Nachrichten mittel eingeschätzt. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: hoch Bedrohung Vertraulichkeit: mittel Die Kombination aus mittlerer Ausnutzbarkeit und hohem Schadenspo- tential führt zu einer Einschätzung der Schwachstelle als betriebsverhin- dernd. {M19} Die Java-Abhängigkeiten sollten aktualisiert werden. Version: 1.0 Stand: 18.06.2018 Seite 58",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p58-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 59,
"content": "Technische Analyse und Konzeptprüfung des beA Diese Schwachstelle wurde zwischenzeitlich geschlossen. Die genannten Bibliothe- ken wurden durch aktuelle Versionen ersetzt, für die keine bekannten Schwachstel- len mehr vorliegen. 4.4.3 Mögliche Ausführung von Schadcode in der beA-Client-Security (JSON) Untersuchungsobjekt Quelltext-Audit beA-Client-Security Schwachstelle behoben verifiziert, behoben Die Serialisierung von Java-Objekten wird an diversen Stellen im Code durchge- führt. Eingesetzt wird hierfür die 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) Alle CVEs benennen eine Schwachstelle dieser Bibliothek bei der Verarbeitung ein- gehender JSON-Objekte. Mit speziell für einen Angriff auf diese Schwachstelle zu- sammengestellten JSON-Objekten kann ein Angreifer die beA-Client-Security dazu bringen, vom Angreifer vorgegebenen Code auszuführen. Das kann in der Über- nahme der Kontrolle der Client-Rechner, auf dem die beA-Client-Security läuft, re- sultieren. Hiermit ist auch die Vertraulichkeit aller vom angegriffenen Rechner versendeten und empfangenen Nachrichten kompromittiert. Weiterer Schaden für die Nutzer des Rechners muss befürchtet werden. Der Angriff kann ohne wesentli- chen Mehraufwand gegen alle beA-Anwender ausgeführt werden. Das Schadenspo- tential ist daher hoch. Um den Angriff auszuführen, müssen manipulierte JSON- Daten an die Websocket-Schnittstelle der beA-Client-Security gesendet werden. Die Ausnutzbarkeit ist daher leicht. Als Reaktion auf die vom Chaos Computer Club gefundene Schwachstelle der all- gemeinen Ansprechbarkeit der Websocket-Schnittstelle der beA-Client-Security wertet diese nun den sogenannten „Origin-Header“ einer JSON-Objekt-Nachricht aus. Diese gibt Auskunft über den Versender der Nachricht und ist schwer manipu- lierbar, was einen allgemeinen Zugriff auf diese Schnittstelle erschwert (vergleiche Abschnitt 4.7.2). Der Angreifer muss nun gegenüber der beA-Client-Security als die beA-Anwendung auftreten, was insbesondere erfordert, im Browser in die TLS- Verbindung zwischen beA-Anwendung und Websocket eindringen zu können. Die Ausnutzbarkeit der Schwachstelle wurde durch die beschriebene Maßnahme deut- lich reduziert. Durch die Aktualisierung der verwendeten Bibliothek ist die verwendete Version durch die bekannten Angriffe nicht mehr verwundbar, und damit wurde die Schwachstelle beseitigt. Die Aktualisierung der Bibliothek wurde verifiziert. Version: 1.0 Stand: 18.06.2018 Seite 59",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p59-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 60,
"content": "Technische Analyse und Konzeptprüfung des beA {S20} Die beA-Client-Security ist potentiell verwundbar gegenüber JSON Java- Objekt-Deserialisierung. {R20} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit der Schwachstelle: Die Ausnutzbarkeit in der vom Chaos Computer Club untersuchten Ver- sion war hoch, da es keinen Zugriffschutz auf die gefährdete Schnittstel- le gegeben hat. Durch die Einführung der Überprüfung des Origin- Headers, ist diese Schwachstelle noch als mittel einzustufen. Ausnutzbarkeit: mittel Bewertung der Bedrohung: Ein Angreifer könnte das System eines Anwenders übernehmen. Ein gleichzeitiger Angriff auf alle Client-Systeme ist möglich. Die Übernahme von Rechnern der beA-Anwender bedroht unmittelbar die von diesen Rechnern versendeten und empfangenen Nachrichten, sowie weitere Assets wie bspw. die von den Anwendern verwendeten Schlüssel, und kann darüber hinaus noch zu weiterem erheblichen Schaden führen. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: hoch Bedrohung Vertraulichkeit: hoch Die Kombination aus mittlerer Ausnutzbarkeit und hohem Schadenspo- tential führt zu einer Bewertung als betriebsverhindernde Schwachstelle. {M20} Die verwendete Bibliothek muss durch eine aktuellere nicht verwundba- re Version ersetzt werden. 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. 4.4.4 Mögliche Ausführung von Schadcode in der beA-Client-Security (XML) Untersuchungsobjekt Quelltext-Audit beA-Client-Security Schwachstellenbehebung verifiziert, behoben Das Deserialisieren von XML-Dateien ist potentiell immer eine Gefahr. Einem 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 Version: 1.0 Stand: 18.06.2018 Seite 60",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p60-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 61,
"content": "Technische Analyse und Konzeptprüfung des beA 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 übernehmen. Auch die beA-Client-Security nimmt XML-Nachrichten entgegen. Im Quelltext fehlen aber die notwendigen Vorsichtsmaßnahmen bei der Verarbeitung. Daher ist auch die beA-Client-Security wie die beA-Anwendung durch manipulierte XML-Dateien angreifbar (vgl. Abschnitt 4.4.1) und führt dann Code des Angreifers aus. Hoch be- droht sind unmittelbar die System-Integrität und –Verfügbarkeit des IT-Systems des beA-Anwenders sowie die Vertraulichkeit der auf diesem System versendeten und empfangene Nachrichten, da sie auf dem IT-System des Anwenders im Klartext vor- liegen. Die Ausnutzbarkeit verlangt das Eindringen in TLS-Verbindungen und mitt- lerweile die Manipulation des Origin-Headers und wird daher als mittel bewertet. In der letzten untersuchten Version der beA-Client-Security wurde die Schwachstel- le durch geeignete Konfiguration der XML-Verarbeitung geschlossen. Der geänderte Quellcode wurde verifiziert. {S21} Die beA-Client-Security ist potentiell verwundbar gegenüber XML-Java- Objekt-Deserialisierung. Durch nicht ausreichend konfigurierte Java- Bibliotheken zur Deserialisierung von XML-Dateien ist es einem Angrei- fer potentiell möglich, das System des Anwenders zu übernehmen. Es werden ausschließlich XML-Dateien von der beA-Anwendung entgegen genommen. {R21} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit der Schwachstelle: Die Ausnutzbarkeit ist mittel, da die beA-Client-Security den Origin- Header einer XML-Nachricht auswertet. Ausnutzbarkeit: mittel Bewertung der Bedrohung: Ein Angreifer könnte an alle Clients modifizierte XML-Dateien schicken und damit die Rechner des Anwenders übernehmen, mit unmittelbaren Folgen für die Vertraulichkeit der Nachrichten sowie weitere hohe Ge- fährdungen für die Anwender. Das Schadenspotential ist hoch. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: hoch Bedrohung Vertraulichkeit: hoch Die Kombination aus mittlerer Ausnutzbarkeit und hohem Schadenspo- tential ergibt eine Bewertung als betriebsverhindernde Schwachstelle. {M21} Korrekte Konfiguration der XML Bibliotheken Diese Schwachstelle wurde zwischenzeitlich geschlossen. Die Überprüfung der be- troffenen Quelltext-Zeilen hat ergeben, dass die eingesetzten Bibliotheken so konfi- Version: 1.0 Stand: 18.06.2018 Seite 61",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p61-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 62,
"content": "Technische Analyse und Konzeptprüfung des beA guriert werden, dass die beschriebenen Schwachstellen der XML-Objekt- Deserialisierung so nicht erneut auftreten können. 4.4.5 Verwendete Bibliotheken der beA-Client-Security Untersuchungsobjekt Quelltext-Audit beA-Client-Security Schwachstellenbehebung verifiziert, behoben Eine Überprüfung der verwendeten Bibliotheken hat für folgende Java-Bibliotheken Schwachstellen ergeben: Tabelle 11: Bibliotheken mit Schwachstellen (beA-Client-Security) CVE Dependency Highest Severity CPE Confidence Count jackson-databind-2.9.3.jar High 3 Highest jackson-databind-2.9.3.jar ■ CVE-2017-17485 ■ CVE-2018-5968 ■ CVE-2018-7489 Die genannten Schwachstellen erlauben einen Angriff mit manipulierten JSON- Daten, sogenannten JSON-Gadgets, der zur Übernahme des Rechners, auf dem die beA-Client-Security läuft, führen kann. Für die Vorgehensweise des Angreifers, die Ausnutzbarkeit und das Schadenspotential gilt das in Abschnitt 4.4.3 Gesagte. Die Ausnutzbarkeit ist mittel, das Schadenspotential hoch. {S22} Durch den Einsatz einer mit Mängeln behafteten-Bibliothek besteht das Risiko für das Anwender-System, von einem Angreifer übernommen zu werden. {R22} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit der Schwachstelle: Die Ausnutzbarkeit war hoch in der vom Chaos Computer Club unter- suchten Version, da es keinen Zugriffschutz für die gefährdete Schnitt- stelle gegeben hat, und ist noch mittel nach der eingeführten Auswertung des Origin-Headers. Ausnutzbarkeit: mittel Bewertung der Bedrohung: Ein Angreifer könnte das System eines Anwenders übernehmen. Ein gleichzeitiger Angriff auf alle Client-Systeme ist möglich. Die Übernahme von Rechnern der beA-Anwender bedroht unmittelbar die von diesen Rechnern versendeten und empfangenen Nachrichten, sowie weitere Assets wie bspw. die von den Anwendern verwendeten Schlüssel, und kann darüber hinaus noch zu weiterem erheblichen Schaden führen. Version: 1.0 Stand: 18.06.2018 Seite 62",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p62-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 63,
"content": "Technische Analyse und Konzeptprüfung des beA Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: hoch Bedrohung Vertraulichkeit: hoch {M22} Aktualisieren der eingesetzten Bibliotheken. In der beA-Client-Security Version 3.1.3.7 wurde die Jackson-databind-Bibliothek aktualisiert. Derzeit wird die Version 2.9.5 eingesetzt. Für die die Jackson-databind- Bibliothek 2.9.5 sind derzeit keine CVE gemeldet. Mit dem Einsatz dieser Version ist die gemeldete Schwachstelle behoben. 4.4.6 Verwendete Bibliotheken in der BRAV-Suche Untersuchungsobjekt Statische Quelltext-Analyse BRAV-Suche Schwachstellenbehebung verifiziert, behoben Eine Überprüfung der von dem BRAV-Suche-Service verwendeten Bibliotheken hat für folgende Java-Bibliotheken bekannte Schwachstellen gezeigt: Tabelle 12: Bibliotheken mit Schwachstellen (BRAV-Suche) CVE Dependency Highest Severity CPE Confidence Count primefaces-5.3.jar High 1 Highest commons-collections-3.2.1.jar High 2 Highest xstream-1.4.9.jar Medium 1 Highest xercesImpl-2.8.0.jar High 1 Low primefaces-5.3.jar CVE-2017-1000486 commons-collections-3.2.1.jar CVE-2015-6420 CVE-2017-15708 xstream-1.4.9.jar CVE-2017-7957 xercesImpl-2.8.0.jar CVE-2012-0881 Die Schwachstellen dieser Bibliotheken erlauben entweder die Ausführung von Code auf dem angegriffenen System oder Betriebsstörungen durch Absturz von Programmkomponenten oder Überlastung des Systems. {S23} Durch den Einsatz einer mit Mängeln behafteten Bibliothek besteht das Risiko für das Anwender-System, von einem Angreifer übernommen zu werden. {R23} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit der Schwachstelle: Version: 1.0 Stand: 18.06.2018 Seite 63",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p63-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 64,
"content": "Technische Analyse und Konzeptprüfung des beA Die statische Quelltextanalyse kann nicht abschließend die Ausnutzbar- keit bestimmen. Die Ausnutzbarkeit kann auch je nach Bibliothek und Schwachstelle unterschiedlich sein. Angriffe sind durch Außentäter mög- lich. Die Ausnutzbarkeit wird zum Zweck der Risikobewertung als mittel eingeschätzt. Ausnutzbarkeit: mittel Bewertung der Bedrohung: Der Angriff ermöglicht die betriebsverhindernde Störung oder die Über- nahme des BRAV-Suche-Servers durch den Angreifer. Die Bedrohung für die Systemintegrität und die –Verfügbarkeit wird als hoch einge- schätzt. Vertrauliche Nachrichten sind nicht unmittelbar gefährdet. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: hoch Bedrohung Vertraulichkeit: niedrig Die Kombination aus hoher Bedrohung für Integrität und mittlerer Aus- nutzbarkeit ergibt eine Bewertung der Schwachstelle als betriebsverhin- dernd. {M23} Aktualisieren der eingesetzten Bibliotheken. Die genannten Bibliotheken wurden entfernt bzw. aktualisiert. ■ PrimeFaces wurde aktualisiert (6.2.3) ■ Commons collections wird nicht mehr verwendet ■ XStream wurde aktualisiert auf Version 1.4.10 ■ XercesImpl wird nicht mehr verwendet Für die aktualisierten Bibliotheken PrimFaces und XStream sind keine CVE gemel- det. Mit dem Einsatz der genannten Bibliotheken und Version und dem Entfernen der Commons collections und der XercesImpl-Bibliothek ist die gemeldete Schwachstelle behoben. 4.5 Beschreibung der B-Schwachstellen 4.5.1 beA-Anwendung: SQL-Injection Untersuchungsobjekt Statische Quelltext-Analyse beA-Anwendung Schwachstellenbehebung - In der beA-Anwendung werden an verschiedenen Stellen Eingabeparameter in Da- tenbank-Befehle (SQL) eingebaut und ausgeführt. Ein authentifizierter Angreifer könnte durch geeignet gewählte Eingaben eigene SQL-Befehle an das Datenbank- Version: 1.0 Stand: 18.06.2018 Seite 64",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p64-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 65,
"content": "Technische Analyse und Konzeptprüfung des beA Backend absetzen und so Zugriff auf sensitive Informationen erhalten, diese verän- dern oder den Datenbankserver komplett übernehmen. Im Rahmen der Analyse konnte nicht evaluiert werden, inwiefern die Schwachstellen tatsächlich ausnutzbar sind, da hierfür ein Quelltext-Audit notwendig wäre (siehe Abschnitt 4.2). Diese Schwachstelle konnte an acht Stellen im Quelltext nachgewiesen werden. {S24} Die beA-Anwendung ist potentiell verwundbar gegenüber mehreren SQL-Injection-Schwachstellen. {R24} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle: Die Ausnutzbarkeit einer solchen Schwachstelle ist im Allgemeinen mit- tel. Die Schwierigkeit besteht darin, herauszufinden, welche Eingaben dazu führen, dass gewünschter SQL-Code ausgeführt wird. Beim beA ist die Schwachstelle aber nur beA-Anwendern zugänglich. Da auch kein konkreter Nachweis der Verwundbarkeit gefunden wurde, wird die Aus- nutzbarkeit niedrig eingeschätzt. Ausnutzbarkeit: niedrig Bewertung der Bedrohung: Mit einem Angriff ist es möglich zunächst die Datenbank und im An- schluss den gesamten Server zu übernehmen. Dadurch kann der An- greifer die Datenbank auslesen und verändern, was mittelbar auch die Vertraulichkeit von Nachrichten bedrohen kann, sofern eine Manipulati- on von Daten im SAFE BRAK gelingt (hierfür ist dann aber noch die Schwachstelle auszunutzen, dass der beA-Client Postfachzertifikate, die im Safe gespeichert sind, nicht überprüft, siehe Abschnitt 5.4.2). Im Rahmen der Analyse konnte nicht evaluiert werden, inwiefern die Schwachstellen tatsächlich ausnutzbar sind, da hierfür ein Quelltext- Audit notwendig wäre. Bedrohung Integrität: hoch Bedrohung Verfügbarkeit: hoch Bedrohung Vertraulichkeit: mittel Die Kombination hoher Bedrohung der Integrität mit niedriger Ausnutz- barkeit ergibt eine Bewertung der Schwachstelle als betriebsbehindernd. {M24} Es sollte verifiziert werden, dass alle SQL-Statements vor ihrem Einsatz korrekt maskiert werden. Von Entwickler-Seite wurde zugesichert, dass, bedingt durch die Software- Architektur, die Maskierung an vorgelagerten Stellen stattfindet. Eine Überprüfung der Aussage konnte aufgrund des Quelltext-Umfangs nicht durchgeführt werden. Version: 1.0 Stand: 18.06.2018 Seite 65",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p65-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 66,
"content": "Technische Analyse und Konzeptprüfung des beA 4.5.2 Initialisierungs-Vector (IV) Untersuchungsobjekt Statische Quelltext-Analyse beA-Anwendung Schwachstellenbehebung - Die Befunde der statischen Quelltext-Analyse der beA-Anwendung waren: de/brak/bea/application/services/hsmmock/AESHandler.java:23 The use of java.util.Random is predictable [Scary(7), Normal confidence] de/brak/bea/application/services/hsmmock/AESHandler.java:23 The use of java.util.Random is predictable [Scary(7), Normal confidence] de/brak/bea/application/services/hsmmock/AESHandler.java:54 The initialization vector (IV) is not properly generated [Scary(7), Normal confidence] de/brak/bea/application/services/hsm/util/HSMUtil.java:33 The use of java.util.Random is predictable [Scary(7), Normal confidence] de/brak/bea/application/services/hsm/util/HSMUtil.java:83 The initialization vector (IV) is not properly generated [Scary(7), Normal confidence] Die betroffenen Quelltext-Zeilen sind bspw.: private Random random = new Random(); byte[] usedIV = createRandomIV(); cipher.init(Cipher.ENCRYPT_MODE, spec, new IvParameterSpec(usedIV)); Die Verwendung von java.util.Random in Zusammenhang mit kryptographischen Funktionen ist ein schwerwiegendes Problem, da schwache Zufallszahlen eine Viel- zahl von Angriffen ermöglichen, die schlussendlich die Sicherheit der kryptographi- schen Funktionen aushebeln. Bei der Verschlüsselung sollte der JCE-Provider einen zufälligen Initialisierungsvek- tor generieren. Eingriffe sind hier nicht erforderlich. Die Qualität lässt sich nur ver- bessern, wenn man einen qualitativ hochwertigen Zufallszahlengenerator übergibt (z.B. HSM-Provider) Die einzige Stelle, wo die Klasse „AESHandler.java“ nach bisheriger Analyse aufge- rufen wird, ist das Package „de.brak.bea.application.services.hsmmock“. Mit hoher Wahrscheinlichkeit handelt es sich um Test Code, der in der Produktion durch HSM- Aufrufe ersetzt wird – was die Gefahr eines Angriffs relativiert. Auch bei der Klasse HSMUtil handelt es sich augenscheinlich um Test-Code, der nur unter bestimmten konfigurativen Bedingungen zum Einsatz kommt. Ohne zusätzliche Maßnahmen, insbesondere die Verwendung anderer Postfachzertifikate, würde eine Aktivierung dieses Codes dazu führen, dass das beA Nachrichten überhaupt nicht mehr umver- schlüsseln kann. Der Umstand, dass hier vermutlich Test-Code vorliegt, macht eine Bewertung der Schwachstelle schwierig. Die Ausnutzbarkeit von Test-Code ist abhängig von den Umständen, unter denen er aktiv wird, kann aber für die Zwecke der Risikobewer- Version: 1.0 Stand: 18.06.2018 Seite 66",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p66-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 67,
"content": "Technische Analyse und Konzeptprüfung des beA tung als niedrig eingestuft werden, da zusätzlich die Ausnutzung nur Innentätern of- fen steht. Die Gefährdung der Vertraulichkeit von Nachrichten ist aber bei Verwen- dung dieses Codes hoch. Bedroht sind die in der Datenbank abgelegten verschlüsselten Nachrichtenschlüssel, die aufgrund dieser Schwachstelle nicht aus- reichend kryptographisch gesichert wären. {S25} Schwächung der Kryptographie durch die unsichere Generierung von Initialisierungsvektoren {R25} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle: Niedrig, da vermutlich erst nach Aktivierung von Testcode zugänglich. Weiterhin ist die Ausnutzung nur Innentätern zugänglich, die Zugang zu den verschlüsselten Nachrichtenschlüsseln und -inhalten haben. Ausnutzbarkeit: niedrig Bewertung der Bedrohung: Mit einem erfolgreichen Angriff können Nachrichtenschlüssel und damit Nachrichteninhalte aufgedeckt werden. Bedrohung Integrität: niedrig Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: hoch Die Kombination aus niedriger Ausnutzbarkeit und hoher Bedrohung der Vertraulichkeit ergibt eine Bewertung der Schwachstelle als betriebsbe- hindernd. {M25} Nicht angemeldete Benutzer sollten keine Tickets auf dem Server erstel- len können. 4.5.3 Unsicheres Auffüllen von Daten bei Verschlüsselung Untersuchungsobjekt Statische Quelltext-Analyse beA-Anwendung Schwachstellenbehebung - Im Quelltext wurden Stellen gefunden, an denen im Zusammenhang mit Verschlüs- selungsoperationen unsichere Padding-Algorithmen (gemäß BSI-Vorgaben) ver- wendet werden. Das gefährdet die Vertraulichkeit der so verschlüsselten Daten, die dann ggf. ohne Kenntnis geheimer Schlüssel entschlüsselt werden können. Die Ausnutzbarkeit ist niedrig, die Bedrohung der Vertraulichkeit allerdings hoch. Version: 1.0 Stand: 18.06.2018 Seite 67",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p67-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 68,
"content": "Technische Analyse und Konzeptprüfung des beA {S26} Es werden unsichere Padding-Algorithmen verwendet, die Angriffe auf damit verschlüsselten Daten erlauben. {R26} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle: Die Ausnutzbarkeit wird niedrig bewertet, da die betroffenen Kryptodaten nur Innentätern zugänglich sind und die Schwachstelle nicht zuverlässig das Entschlüsseln der Daten erlaubt. Ausnutzbarkeit: niedrig Bewertung der Bedrohung: Ein erfolgreicher Angriff kann zur Offenlegung von Nachrichteninhalten führen. Hier sind potentiell alle im beA gespeicherten Nachrichten betrof- fen. Die Bedrohung der Vertraulichkeit ist daher hoch. Bedrohung Integrität: niedrig Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: hoch Die Kombination aus niedriger Ausnutzbarkeit und hoher Bedrohung der Vertraulichkeit ergibt eine Bewertung der Schwachstelle als betriebsbe- hindernd. {M26} Unsichere Padding-Verfahren durch zurzeit als sicher geltende Verfah- ren ersetzen. 4.5.4 TLS-Zertifikate-Validierung Untersuchungsobjekt Quelltext-Audit beA-Client-Security Schwachstellenbehebung verifiziert, behoben Für den SAML-Verbindungsaufbau wird ein vom Server nachgeladenes TLS- Zertifikat ohne weitere Überprüfung zur Nutzung freigegeben. Es agiert dann in der beA-Client-Security als Vertrauensanker für die Verifizierung weiterer TLS- Zertifikate. Auf diese Weise kann ein Angreifer die beA-Client-Security von Anwen- dern über die Identität der Server, mit denen die beA-Client-Security kommuniziert, täuschen. Er kann damit auch TLS-Verbindungen zwischen beA-Client-Security und beA-Anwendung aufbrechen. Dadurch erhält er Zugriff auf Metadaten der Kommu- nikation, aber noch nicht auf Nachrichteninhalte. Er kann in Benutzersitzungen ein- dringen und im Namen dieser Benutzer Nachrichten verschicken. Die Bedrohung für die Integrität ist daher mittel. Er kann auch die Nutzung des beA für alle Anwender gleichzeitig unterbinden. Die Bedrohung für die Verfügbarkeit ist daher hoch. Die Vertraulichkeit von Nachrichten ist nicht unmittelbar betroffen. Der Angreifer muss ein Innentäter oder ein bereits über eine andere Schwachstelle in die beA-Anwendung eingedrungener Außentäter sein. Die vorzunehmende Mani- Version: 1.0 Stand: 18.06.2018 Seite 68",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p68-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 69,
"content": "Technische Analyse und Konzeptprüfung des beA pulation hat jedoch geringen Umfang. Die Ausnutzbarkeit wird daher als mittel ein- gestuft. Diese Funktionalität ist laut Entwickler als Testcode im beA-System und nicht für den produktiven Einsatz gedacht. Eine Überprüfung der beA-Client-Security in die- sem Punkt am laufenden System zeigte, dass zwar der Code für die Annahme des Zertifikats in der beA-Client-Security vorhanden ist, von der beA-Anwendung aber kein Zertifikat übermittelt wird. In der für die Verifizierung der Schwachstellenbehe- bung zur Verfügung gestellten Version der beA-Client-Security war dieser Testcode entfernt und die Schwachstelle damit behoben. {S27} Nicht angemeldete Benutzer können beliebigen Text auf dem Server hochladen. {R27} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle: Ein Innentäter oder ein bereits durch eine andere Schwachstelle einge- drungener Außentäter kann den Angriff durchführen. Die Ausnutzbarkeit wird daher als mittel eingestuft. Ausnutzbarkeit: mittel Bewertung der Bedrohung: Es kann in Benutzersitzungen eingedrungen und dann im Namen eines Benutzers Nachrichten versendet werden. Es ist auch möglich die ge- samte Nutzung des beA-Systems zu unterbinden. Metadaten können eingesehen werden. Bedrohung Integrität: mittel Bedrohung Verfügbarkeit: hoch Bedrohung Vertraulichkeit: niedrig Die Kombination aus hoher Bedrohung der Verfügbarkeit, mittlerer Be- drohung der Integrität und mittlerer Ausnutzbarkeit ergibt eine Bewer- tung der Schwachstelle als betriebsbehindernd. {M27} Die Möglichkeit, beim Verbindungsaufbau TLS-Zertifikate vom beA- Server nachzuladen, sollte entfernt werden. Die Möglichkeit, TLS Zertifikate beim Verbindungsaufbau vom beA-Server nachzu- laden und anschließend zu verwenden, wurde entfernt. Eine erneute Prüfung des entsprechenden Quellcode-Teils hat das bestätigt. Version: 1.0 Stand: 18.06.2018 Seite 69",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p69-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 70,
"content": "Technische Analyse und Konzeptprüfung des beA 4.6 Auflistung der C-Schwachstellen In der nachfolgenden Tabelle werden alle im Bereich der Quelltextanalyse identifi- zierten Schwachstellen der Kategorie C aufgelistet. Tabelle 13: Quelltext C-Schwachstellen Legende: h=hoch; m=mittel; n=niedrig; J=Ja Bedrohung Ausnutzbarkeit Schwachstelle Vertraulichkeit Verfügbarkeit Komponen- Integrität behoben Kurzbeschreibung te Unfertiger bzw. System-spezifischer Quelltext beA-Client- m n n m - Security Die beA-Client-Security konstruiert an einer Stelle einen Dateinamen in einer Art und Weise, die nur unter dem Betriebssystem Windows funktioniert. Dies kann zu unerwar- tetem Verhalten auf anderen Betriebssystemen führen. Verwundbarkeit über unsichere XML-Deserialisierung. OCSP- n m m m - Würde Systemkontrollübernahme durch Innentäter erlauben. Relay Das Schadenspotential wurde herabgestuft, da der betroffe- ne Code augenscheinlich nicht aufgerufen wird. Möglicherweise unsicherer Quelltext - fest vergebene beA-Client- n n n n - Namen für temporäre Dateien. Security Durch fest vergebene Namen für temporäre Dateien im Quelltext ist es einem Angreifer potentiell möglich, die Anwendung zu kompromittieren. Vor dem Ausnutzen muss aber das System des Anwenders über einen anderen Weg kompromittiert worden sein. Wurde als niedriges Risiko eingestuft, da dem Angreifer in der benötigten Position bessere Angriffsmöglichkeiten zur Verfügung stehen. 4.7 Durch den CCC gemeldete Schwachstellen Der Chaos-Computer-Club Darmstadt meldete am 20.12.2017 sechs Schwachstel- len der beA-Anwendung an das BSI. 4.7.1 CCC 1: SSL-Zertifikat für bealocalhost.de kompromittiert Überprüfung: Quelltext-Audit Diese Schwachstelle wurde in der untersuchten Version der beA-Client-Security be- hoben. Version: 1.0 Stand: 18.06.2018 Seite 70",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p70-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 71,
"content": "Technische Analyse und Konzeptprüfung des beA 4.7.2 CCC 2: beA-Client-Security startet unsicheren Webserver und Webso- cket Überprüfung: Quelltext-Audit Bemängelt wurde der ungeschützte Zugriff beliebiger Websites auf die Websocket- Schnittstelle der beA-Client-Security. Die Absicherung der WebSocket-Schnittstelle erfolgt nun mittels Überprüfung des Origin-Headers der Web-Sessions, der die Her- kunft des Zugriffs ausweist und der vor böswilliger Manipulation besonders ge- schützt ist. Es werden nur Zugriffe durch die beA-Anwendung zugelassen. Das Setzen des Origin-Headers durch den Zugreifer in böswilliger Absicht scheint derzeit nicht möglich und ist dann wahrscheinlich auch nicht trivial. Sollte dies in der Zu- kunft z.B. durch einen Browser-Bug möglich sein, wäre diese Schutzmaßnahme ge- brochen. Dann sollte eine auf kryptographische Verfahren gestützte Variante eingesetzt werden. 4.7.3 CCC 3: beA-Client-Security nimmt serialisierte Java-Objekte via Web- socket entgegen und führt sie aus Überprüfung: Quelltext-Audit Diese Schwachstelle besteht nicht mehr. Durch die Aktualisierung der Bibliothek wurden die zuvor gemeldeten Schwachstellen bei der Deserialisierung behoben. Durch die Überprüfung des Origin-Headers wurde zusätzlich eine neue Schutzebe- ne eingezogen, so dass nicht mehr alle Daten, die an die beA-Client-Security über das WebSocket gesendet werden, deserialisiert werden. 4.7.4 CCC 4: Unterstützte Betriebssysteme sind veraltet Einer der benannten Mängel bezeichnete die Betriebssystemversionen, die das beA unterstützt, als veraltet. Funktionstests für aktuelle Betriebssysteme wurden nicht durchgeführt. Es wird empfohlen, in Zukunft das beA-System auf aktuellen Betriebs- systemen zu testen und freizugeben. 4.7.5 CCC 5: Client besteht aus stark veralteten Paketen (zum Teil aus 2011/2013) Durch Einsatz aktueller Bibliotheken besteht diese Schwachstelle nicht mehr. 4.7.6 CCC 6: XSS-Schwachstelle in der beA-Webanwendung Überprüfung: Nachweis durch Pentesting Diese Schwachstelle ist in der aktuellen Version der beA-Anwendung behoben. Version: 1.0 Stand: 18.06.2018 Seite 71",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p71-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 72,
"content": "Technische Analyse und Konzeptprüfung des beA 5 Konzeptionelle Analyse 5.1 Beschreibung des Analysegegenstandes 5.1.1 Form des Analysegegenstands und Betrachtungsweise Der untersuchte Analysegegenstand war die Konzeptdokumentation des beA in sei- nem zum Stichtag aktuellen, vom Betreiber vorgelegten Stand. Sie bestand aus Use-Case-Beschreibungen, Feinkonzepten zum Gesamt-System und wichtigen Teilkomponenten, sowie Sicherheitsdokumentation. Außerdem wurde die vorgelegte Sicherheitsdokumentation begutachtet. Betrachtet wurden wesentliche Sicherheitsfunktionen des beA, die der Sicherung der Vertraulichkeit und Authentizität der via beA übermittelten Nachrichten die- nen. Die benötigte Flexibilität beim Lesezugriff auf Empfängerseite erfordert eine Umverschlüsselung der Nachrichten, die einen Schwerpunkt der Analyse bildet. Ebenfalls betrachtet wurde die Zuverlässigkeit der Authentisierung bei der Anmel- dung am beA-System, die auch für die Vertraulichkeit von Nachrichten und Metada- ten Bedeutung hat. Schließlich wurde betrachtet, wie zuverlässig ein Empfänger den Urheber einer Nachricht erkennen kann. Im Fokus der Analyse stand daher der kritische Pfad der Nachrichtenübertragung: ■ Erstellen der verschlüsselten Nachricht durch einen Absender ■ Versand und Ablage der verschlüsselten Nachricht im beA-Postfach ■ Abruf von Nachrichten aus dem beA-Postfach durch berechtigte Leser ■ Relevante Verwaltungsfunktionen: Verzeichnis möglicher Empfänger, Ma- nagement von Administrations- und Leseberechtigungen, Einrichtung und Deaktivierung von Postfächern, Management von Zertifikaten und Schlüs- seln. 5.1.2 Inhaltliche Beschreibung des Analysegegenstands Im Folgenden werden Beschreibungen der Use-Cases zum besseren Verständnis 1 der späteren Ausführungen wiedergegeben : 1 Die Beschreibungen basieren auf der Präsentation „Ende-zu-Ende Verschlüsselung im besonderen elektronischen Anwaltspostfach (beA)“, welche unter https://www.rak-berlin.de/download/pdf_beA_bisEnde2018/HSM_Atos.pdf verfügbar ist Version: 1.0 Stand: 18.06.2018 Seite 72",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p72-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 73,
"content": "Technische Analyse und Konzeptprüfung des beA Postfach einrichten Beim Anlegen eines Postfachs wird ein asymmetrisches Schlüsselpaar generiert und mit dem symmetrischen Postfachschlüssel verschlüsselt in der Datenbank ab- gelegt. Für dieses Schlüsselpaar wird ein Zertifikatsrequest vom HSM signiert, das resultierende Zertifikat wird auch im SAFE BRAK abgelegt. Anschließend kann das Postfach durch den Eigentümer in Besitz genommen wer- den. Abbildung 5: Postfach einrichten Zur Erstellung des initialen Berechtigungscodes (Rechtevergabecode) eines Postfa- ches wird das Authentifizierungszertifikat der beA-Karte benötigt, welches die Post- fach-ID enthält. Dazu wird eine Zertifikatskette übergeben, die unter Zuhilfenahme eines im HSM installierten Trust-Anchors (Root-Zertifikat) validiert wird. Durch die Einbettung der Postfach-ID in dem für den Postfachbesitzer ausgestellten Zertifikat erfolgt eine eineindeutige Zuordnung zum Postfach in der Rechteverwaltung. Mittels dieser speziell für das Postfach erstellten Karte wird sichergestellt, dass ausschließ- lich der berechtigte Benutzer (= Postfachbesitzer) Zugriff auf das Postfach erlangt. Version: 1.0 Stand: 18.06.2018 Seite 73",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p73-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 74,
"content": "Technische Analyse und Konzeptprüfung des beA Management von Administrations- und Leserechten Abbildung 6: Management von Administrations- und Leserechten Berechtigungscodes werden nur durch das HSM erzeugt. Nur Benutzer, für die in der Benutzerverwaltung ein Berechtigungscode zur Vergabe von Rechten (Rechte- vergabecode) vorliegt, können vom HSM neue Berechtigungscodes für andere Be- nutzer erstellen lassen. Beim Rechteantrag handelt es sich um ein durch den Rechteverwalter signiertes Datenobjekt, welches den öffentlichen Schlüssel des zu Berechtigenden (bei Gewährung von Nachrichtenzugriff der öffentliche Schlüssel des Verschlüsselungszertifikats und bei Gewährung von Rechteverwaltung der des Authentifizierungszertifikats) und das gewünschte Recht (Zugriff oder Rechteverwal- tung) enthält. Zertifikatsmanagement Die meisten Zertifikate innerhalb der beA-Anwendung werden durch die Bundes- notarkammer ausgestellt. Dies umfasst u. A. die Zertifikate für die HSM, für die Postfächer sowie für die Nutzer von beA-Karten. In den HSM sind die notwendigen Root-Zertifikate der Bundesnotarkammer als Trust-Anchors (Vertrauensanker) hin- terlegt. Die Postfach- sowie Nutzerzertifikate werden mittels SAFE-Server verwaltet. Versand von Nachrichten Der Versand von Nachrichten spielt sich im Großen und Ganzen auf dem Client des Benutzers ab. Dazu wird ein symmetrischer Schlüssel gebildet, mit dem die Nach- richt und eventuelle Anhänge verschlüsselt werden. Dieser symmetrische Schlüssel wird dann mit Hilfe der Zertifikate der Empfänger der Nachricht mit den zugehörigen öffentlichen Schlüsseln (Postfachschlüssel, nicht Anwaltsschlüssel) verschlüsselt (sowie zusätzlich mit dem öffentlichen Schlüssel des eigenen Postfachs, um die ge- sendeten Nachrichten später einsehen zu können). Anschließend wird die Nachricht zur Ablage in den entsprechenden Postfächern an die beA-Anwendung übertragen. Version: 1.0 Stand: 18.06.2018 Seite 74",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p74-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 75,
"content": "Technische Analyse und Konzeptprüfung des beA Ablage von Nachrichten im beA Abbildung 7: Ablage von Nachrichten im beA Ablauf der Ablage einer empfangenen Nachricht im Postfach: 1. Ein verschlüsselter Nachrichtencontent wird ohne Veränderung im Postfach gespeichert. 2. Der zugehörige mit dem öffentlichen Postfachschlüssel verschlüsselte Nach- richtenschlüssel wird an das HSM zur Umverschlüsselung übergeben. 3. Entschlüsselung des mit dem öffentlichen Postfachschlüssel verschlüsselten Nachrichtenschlüssels mittels privaten Postfachschlüssels. 4. Verschlüsselung des Nachrichtenschlüssels mit dem symmetrischen Schlüs- sel des Postfaches. 5. Speicherung des mit dem symmetrischen Schlüssel des Postfaches ver- schlüsselten Nachrichtenschlüssels im Postfach. Der symmetrische Postfachschlüssel wird auch zur Ver- und Entschlüsselung der im Postfach abgelegten verschlüsselten Betreffzeilen (werden vom Client beim ersten Lesen an die beA-Anwendung verschlüsselt zurückgeschickt) verwendet. Version: 1.0 Stand: 18.06.2018 Seite 75",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p75-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 76,
"content": "Technische Analyse und Konzeptprüfung des beA Abruf von Nachrichten Bevor ein angemeldeter Benutzer Nachrichten abrufen kann, muss ein temporärer Kommunikationsschlüssel durch das HSM erstellt und dem Benutzer mitgeteilt wer- den. Abbildung 8: Abruf von Nachrichten (Teil 1) Ablauf der Erstellung eines symmetrischen Kommunikationsschlüssels, der Spei- cherung, der Übertragung und der Entschlüsselung auf dem Client: 1. Prüfung der Berechtigung der Nachrichtenentschlüsselung eines bestimmten Postfaches für einen Benutzers des beA durch ein HSM. 2. Nach der Anmeldung eines Benutzers am System wird beim ersten Zugriff auf ein Postfach ein temporärer symmetrischer Kommunikationsschlüssel (AES-256) im HSM gebildet. 3. Dieser Kommunikationsschlüssel wird zum einen mit dem öffentlichen Post- fach-Schlüssel des Benutzers und zum anderen mit dem symmetrischen Postfachschlüssel (für jedes PF, auf welches der Benutzer Zugriffsrechte hat) im HSM verschlüsselt. 4. Zwischenspeicherung der beiden verschlüsselten Kommunikationsschlüssel in der Benutzer-Session der beA-Anwendung. 5. Aufbau einer TLS-Verbindung und Übertragung des mit dem öffentlichen Schlüssel des autorisierten Benutzers verschlüsselten Kommunikations- schlüssels an den Client des Benutzers. 6. Entschlüsselung des Kommunikationsschlüssels mit dem privaten Postfach- Schlüssel des Benutzers beim Benutzer. Version: 1.0 Stand: 18.06.2018 Seite 76",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p76-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 77,
"content": "Technische Analyse und Konzeptprüfung des beA 7. Zwischenspeicherung des entschlüsselten Kommunikationsschlüssels in der Client-Session beim Benutzer. Anschließend kann der Client Nachrichten vom Postfach abholen. Abbildung 9: Abruf von Nachrichten (Teil 2) Ablauf der Abholung einer Nachricht aus dem Postfach und Entschlüsselung auf dem Client mit dem temporären symmetrischen Kommunikationsschlüssel: 1. Ein verschlüsselter Nachrichtencontent wird ohne Veränderung aus dem Postfach an den Client übertragen. Die Schritte 2-4 werden innerhalb der HSM durchgeführt. Als Resultat wird nur das Ergebnis aus Schritt 4 zurückgegeben. 2. Entschlüsselung des mit dem symmetrischen Postfachschlüssel verschlüs- selten Nachrichtenschlüssels innerhalb des HSM. 3. Entschlüsselung des mit dem symmetrischen Postfachschlüssel verschlüs- selten Kommunikationsschlüssels innerhalb des HSM. 4. Verschlüsselung des Nachrichtenschlüssels mit dem symmetrischen Kom- munikationsschlüssel innerhalb des HSM. Nur das Resultat dieser Ver- schlüsselung wird vom HSM wieder an die beA-Anwendung zurückgegeben. 5. Übertragung des mit dem symmetrischen Kommunikationsschlüssel ver- schlüsselten Nachrichtenschlüssels an den Client. 6. Entschlüsselung des Nachrichtenschlüssels beim Client mit dem Kommuni- kationsschlüssel. 7. Entschlüsselung der Nachricht beim Client mit dem Nachrichtenschlüssel. Version: 1.0 Stand: 18.06.2018 Seite 77",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p77-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 78,
"content": "Technische Analyse und Konzeptprüfung des beA Management der HSM-Schlüssel Die gesamte kryptographische Sicherung der Vertraulichkeit der Nachrichten im beA-System basiert auf der Geheimhaltung eines Satzes von Arbeitsschlüsseln, so- genannter Master-Schlüssel, die in den HSM gespeichert sind und dort verwendet werden, um Nachrichtenschlüssel oder private Postfachschlüssel zu ver- und ent- schlüsseln, was auch für die Umverschlüsselung genutzt wird. Insbesondere werden Nachrichtenschlüssel (siehe Ablage von Nachrichten, Schritt 4) mit einen symmetrischen Schlüssel des Postfachs verschlüsselt im beA-System in einer Datenbank gespeichert. Dieser symmetrische Postfachschlüssel wird unter Verwendung der Postfach-ID aus einem Master-Schlüssel gebildet, der in den HSM gespeichert ist. Die Kenntnis dieses Master-Schlüssels erlaubt die Entschlüsselung aller im BeA-System gespeicherten Nachrichten, da die Postfach-IDs selbst nicht geheim sind. Auf seiner Vertraulichkeit basiert die Vertraulichkeit jeder Nachricht im beA. Es gibt weiterhin Master-Schlüssel für die Erstellung von Berechtigungscodes und für die verschlüsselte Speicherung der privaten Postfachschlüssel außerhalb des HSM, sowie Master-Schlüssel, die beim Abruf von Nachrichten Verwendung finden. Diese Master-Schlüssel wurden vom Betreiber des beA in einem abgesicherten Re- chenzentrum erzeugt, mit einem sogenannten Key Encryption Key (KEK) verschlüs- selt, sodann der Key Encryption Key und die verschlüsselten Master-Schlüssel an den Auftraggeber übergeben, die diese seither verwahrt. Der Auftraggeber stellt den KEK sowie die Master-Schlüssel in Schlüsselzeremonien (abgesicherten Verfahren zur Eingabe oder Erzeugung von Schlüsseln) zur Verfügung, wenn ein HSM an ei- nem beA-Systemstandort mit diesen Schlüsseln in Betrieb genommen werden soll. Die Sicherheit des KEK wird durch Schlüsselteilung, physikalisch getrennte Verwah- rung und physikalisch auf spezifische Mitarbeiter des Auftraggebers, die sogenann- ten Key Custodians, beschränkten Zugriff geschützt. Die beiden Teile des KEK, die nur zusammen die Entschlüsselung und das Einspielen der Master-Schlüssel in ein HSM erlauben, sind auf Papier in versiegelten Briefumschlägen in Safes verwahrt. Zu jeder Art von Master-Schlüssel sind 100 Varianten erzeugt und gespeichert, von denen aber jeweils immer nur eine von allen HSMs verwendet wird. Die Master- Schlüssel werden im Jahresrhythmus gewechselt, indem eine neue Variante ge- wählt wird. 5.2 Methodik und Vorgehensweise Durchgeführt wurde eine Analyse nach Dokumentenlage, insbesondere der Be- schreibungen der Use-Cases des kritischen Pfades: ■ Postfach einrichten ■ Management von Rechten ■ Zertifikatsmanagement Version: 1.0 Stand: 18.06.2018 Seite 78",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p78-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 79,
"content": "Technische Analyse und Konzeptprüfung des beA ■ Versand von Nachrichten ■ Ablage von Nachrichten im beA ■ Abruf von Nachrichten ■ Management der HSM-Schlüssel Die Use-Case-Beschreibungen lagen als Ablaufbeschreibungen mit Auslöser, Vor- und Nachbedingungen sowie als Ablaufdiagramme vor. Des Weiteren wurden das Feinkonzept HSM und andere Feinkonzepte analysiert, wo Informationen über Sicherheitseigenschaften der Use-Cases gefunden wurden, die sich nicht aus der beschriebenen Prozesslogik selbst ergeben. Die durch die Use-Cases beschriebenen logischen Prozessabläufe wurden einer Bedrohungsanalyse unterworfen, wie sie für die Erstellung von Sicherheitskonzep- ten für Objekte mit hohem Schutzbedarf üblich ist. Als Schwachstellen wurden An- griffsmöglichkeiten bezeichnet, die nicht dem Schutzzweck entsprechend hinreichend durch die Prozesslogik oder die in den Dokumenten erkennbaren Si- cherheitsmaßnahmen abgewehrt werden. Die Darstellung der Schwachstellen und die Risikobewertung erfolgte dann nach dem in Kapitel 2 erläuterten Verfahren. Die vorgelegte Sicherheitsdokumentation wurde hinsichtlich der Frage beurteilt, ob sie eine vollständige Abwehr aller nicht tragbaren Sicherheitsrisiken nachweisen kann. 5.3 Übersicht der Schwachstellen Tabelle 14: Schwachstellenübersicht Konzeptanalyse Schwachstelle Einstufung behoben Verwendung von Javascript beim beA_Client A - Client prüft Postfachzertifikate nicht A - BNotK kann Ursprung der Zertifikatsanträge aus HSM nicht erkennen B - EGVP-Bürger-Verzeichniseinträge im SAFE können irreführend sein B - HSM-Schlüssel existieren außerhalb des HSM B - Berechtigungs-MACs können nicht sicher widerrufen werden C - Die Postfach-ID wird bei der Beantragung einer Berechtigung nicht C - mitsigniert. Version: 1.0 Stand: 18.06.2018 Seite 79",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p79-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 80,
"content": "Technische Analyse und Konzeptprüfung des beA 5.4 Beschreibung der A-Schwachstellen Im Folgenden werden die im Konzept des beA vorgefundenen Schwachstellen be- schrieben, die aufgrund hoher Ausnutzbarkeit und/oder hoher Bedrohung ein be- triebsverhinderndes Risiko darstellen und vor Wiederinbetriebnahme des beA beseitigt werden sollten. 5.4.1 Verwendung von Javascript beim beA_Client Der beA-Client-Security besteht aus mehreren Teilen. Ein Teil wird als Javascript- Code vom beA-Server ausgeliefert, welcher im Browser des Nutzers ausgeführt wird. Dieser Teil steuert die beA-Client-Security, welche für Verschlüsselung, Ent- schlüsselung und Authentisierung zuständig ist. Ein Innentäter kann diesen Code mit der Absicht modifizieren, Nachrichten beim Versenden unverschlüsselt in eine beliebige Richtung zu versenden. Bei Verwendung von Javascript gibt es keinen Mechanismus, der sicherstellt, dass es sich um den vorgesehenen (unmanipulierten) Code handelt. Ob der Code auf dem beA-Server manipuliert wurde, ist durch den Client nicht erkennbar. Die beA- Client-Security kann auch von manipulierten Javascript-Programmen angesprochen und verwendet werden (z.B. zur Anmeldung am Portal). Alle eingegebenen oder angezeigten Daten können jedoch kompromittiert sein und z.B. zusätzlich an den Angreifer gesendet werden. Mittels böswillig modifizierten Javascript-Codes können alle beA-Nutzer auf einmal angegriffen werden. Es ist dann möglich, alle versende- ten Nachrichten im Klartext auszuleiten. {S28} Der Javascript-Code liegt auf dem beA-Webserver gegen Veränderung ungesichert vor. {R28} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit der Schwachstelle: Der Javascript-Code kann durch einen Innentäter mit Schreibrecht auf dem beA-Frontend leicht, von einem Außentäter unter Ausnutzung einer ggf. noch vorhandenen Schwachstelle, über die er sich unberechtigt Zu- gang zum Frontend verschafft, ausgenutzt werden. Sobald ein schreiben- der Zugriff auf die Javascript-Seiten besteht, ist die Fortsetzung des Angriffs trivial. Da sowohl Innentäter als auch Außentäter nicht ausge- schlossen werden können, wird die Ausnutzbarkeit als mittel bewertet. Bewertung der Ausnutzbarkeit: mittel Bewertung der Bedrohung: Ein erfolgreicher Angreifer kann mit einem Angriff alle vom Beginn des Angriffs an versendeten Nachrichten aller beA-Nutzer einsehen. Aufgrund Version: 1.0 Stand: 18.06.2018 Seite 80",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p80-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 81,
"content": "Technische Analyse und Konzeptprüfung des beA des potentiellen Zugriffs auf alle Postfächer wird die Bedrohung der Ver- traulichkeit als hoch eingestuft. Bedrohung Integrität: niedrig Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: hoch Die Kombination aus hoher Bedrohung und mittlerer Ausnutzbarkeit ergibt die Bewertung als betriebsverhindernde Schwachstelle. {M28} Das ausgelieferte Javascript muss regelmäßig in kurzen Abständen von einem separaten System auf Unversehrtheit, z.B. durch Checksummen, geprüft werden. Zudem sollten die Nutzer darauf sensibilisiert werden, darauf zu achten, dass sich der beA-Server mit einem korrekten TLS-Zertifikat ausweist. Erwägenswert ist das Angebot eines elektronisch signierten „Fat Clients“, also ein vollständiges, lokal installierbares beA-Client-Security-Programm, welches keinen Code mehr von einem Server nachlädt und dessen Integ- rität kryptographisch gesichert ist. Ebenfalls zu erwägen ist eine Offenle- gung der Schnittstellen zwischen beA-Client-Security und -Server, was die Entwicklung von Open-Source-Implementierungen für den beA-Client- Security ermöglichen würde. Anmerkung: Kanzleisoftware, die nur die REST-API des beA-Servers verwendet, ist nicht betroffen. 5.4.2 Client prüft Postfachzertifikate nicht Beim Versenden von Nachrichten wird der öffentliche Schlüssel aus dem Postfach- zertifikat des vorgesehenen Empfängers verwendet. Die öffentlichen Schlüssel von Postfächern liegen im SAFE BRAK in von der BNotK zertifizierter Form vor. Der Client geht aber davon aus, dass die von der beA-Anwendung aus dem SAFE BRAK gelieferten Daten korrekt sind und prüft daher weder die Signatur der BNotK unter einem beA-Postfachzertifikat, noch seinen Sperrstatus. Dies ermöglicht es ei- nem Innentäter, der berechtigten Zugang zu den SAFE-Verzeichnisdaten hat, oder einem Angreifer, der sich via Internet unter Ausnutzung von Sicherheitslücken in der beA-Anwendung schreibenden Zugriff auf das Verzeichnis verschafft hat, ein fal- sches Postfachzertifikat für eine beliebige SAFE_ID einzuspielen, wobei er dabei ei- nen öffentlichen Schlüssel im Zertifikat verwenden wird, für den er den privaten Schlüssel besitzt (Schlüssel und Zertifikate lassen sich sehr einfach mit allgemein bekannten Mitteln erzeugen). Da der Client das Postfachzertifikat nicht prüft, ist es dabei unerheblich, dass es sich um ein offensichtlich falsches, weil nicht von der BNotK signiertes, beA-Postfachzertifikat handelt. Der Angreifer kann auf diese Wei- se die an die entsprechende SAFE_ID adressierten Nachrichten mitlesen. Dies kann er zudem unbemerkt tun, weil er die Nachrichten nach dem Lesen in für das Postfach korrekter Weise umverschlüsseln und an das beA weiterleiten kann. Er Version: 1.0 Stand: 18.06.2018 Seite 81",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p81-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 82,
"content": "Technische Analyse und Konzeptprüfung des beA kann dabei eine beliebige Menge von Postfächern auf einmal erfolgreich angreifen. Der Verzicht auf die Prüfung der Postfachzertifikate in der beA-Client-Security führt dazu, dass die Sicherheitsfunktion der von der BNotK ausgestellten Postfach- Zertifikate vollständig ohne Wirkung bleibt. Die Verwendung gesperrter beA-Postfachzertifikate ist allerdings hinreichend wirk- sam erschwert, da der zugehörige private Schlüssel innerhalb eines beA-HSM er- zeugt wurde und nur verschlüsselt außerhalb des HSM existiert. Die Möglichkeit, dass ein Angreifer ein ordnungsgemäß ausgestelltes beA-Postfachzertifikat ein- schließlich des zugehörigen privaten Schlüssels besitzt, besteht nur, wenn auf die Behebung der Schwachstelle 5.5.1 verzichtet wird. Vorbehaltlich einer Behebung der dort genannten Schwachstelle ist eine Prüfung des Sperrstatus der Postfachzer- tifikate bei der BNotK nicht notwendig. {S29} Der Client prüft Postfachzertifikate vor dem Versenden von Nachrichten nicht. {R29} Risikobewertung: A-Betriebsverhindernd Ausnutzbarkeit: Für die Ausnutzung der Schwachstelle benötigt ein Angreifer nur Schreib- zugriff auf den SAFE BRAK. Hierfür kommen neben einem Innentäter auch Außentäter in Frage, die den SAFE BRAK oder eine andere Kom- ponente des beA-Systems erfolgreich übernommen haben. Einem Angrei- fer stehen mehrere Angriffspunkte zur Auswahl, die Schwachstelle auszunutzen, Angriff auf den SAFE BRAK, dessen Datenbank oder das System, das die Postfach-Zertifikate an den SAFE BRAK liefert. Daher wird die Ausnutzbarkeit als mittel bewertet. Bewertung der Ausnutzbarkeit: mittel Bewertung der Bedrohung: Innentäter oder erfolgreiche Angreifer auf den SAFE BRAK könnten die ausgelieferten Zertifikate und zugehörigen Informationen unbemerkt durch eigene ersetzen und so umfassend Nachrichten mitlesen. Bedrohung Integrität: niedrig Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: hoch Die Kombination aus mittlerer Ausnutzbarkeit und hoher Bedrohung ergibt die Bewertung als betriebsverhindernde Schwachstelle. {M29} Die beA-Client-Security muss das beA-Postfachzertifikat prüfen (elektro- nische Unterschrift der BNotK). Auf die fehlende Prüfbarkeit von EGVP- Zertifikaten und die damit verbundenen Risiken muss der Versender hin- gewiesen werden. Eine Prüfung des Sperrstatus von Postfachzertifikaten, die die BNotK ausgestellt hat, erscheint nicht notwendig, da eine Reihe anderer Mechanismen eine Wiederverwendung eines kompromittierten Postfach-Schlüssels erschweren und eine Kompromittierung eines beA- Version: 1.0 Stand: 18.06.2018 Seite 82",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p82-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 83,
"content": "Technische Analyse und Konzeptprüfung des beA Postfachzertifikats nur unter Ausnutzung der Schwachstelle 5.5.1 möglich erscheint. Eine Aufdeckung privater Postfachschlüssel im beA erscheint nur möglich unter Ausnutzung der Schwachstelle 5.5.3, ist dann aber nicht mehr notwendig, weil im dort beschriebenen Fall die Nachrichten dem Angreifer schon ohne Kompromittierung privater Postfachschlüssel zugänglich sind. 5.5 Beschreibung der B-Schwachstellen 5.5.1 BNotK kann Ursprung der Zertifikatsanträge aus HSM nicht erkennen Die zentrale beA-Anwendung beantragt automatisiert Zertifikate für die Postfächer bei der BNotK. Dazu wird ein elektronischer Zertifikatsantrag benutzt, der den öf- fentlichen Postfachschlüssel enthält und mit dem privaten Postfachschlüssel signiert wird. Die BNotK kann allerdings nicht feststellen, ob ein Zertifikatsantrag tatsächlich – wie vorgesehen – in dem HSM signiert wurde und sich auf Schlüssel bezieht, die in dem HSM erzeugt wurden, da eine Authentisierung des HSM im Zertifikatsantrag nicht enthalten ist. Ein Innentäter oder ein erfolgreicher Angreifer der beA-Anwendung kann also auch Zertifikatsanträge mit eigenen Schlüsseln erstellen und an die BNotK zur Zertifikats- ausstellung senden. Das von der BNotK daraufhin erstellte Zertifikat kann der An- greifer dann zusammen mit den eigenen Schlüsseln für weitere Angriffe nutzen. Hier sind verschiedene Szenarien denkbar, z.B.: 1. Der Angreifer manipuliert die beA-Anwendung in der Weise, dass diese bei Postfächern, welche mit Schlüsseln des Angreifers angelegt wurden, eigene Krypto-Routinen des Angreifers verwendet anstelle des HSM. Somit kann der Angreifer im Namen des eigentlichen Postfachbesitzers agieren, also sowohl Nachrichten lesen als auch erstellen, ohne dass dies dem eigentlichen Post- fachbesitzer oder den Administratoren unmittelbar auffällt. Selbst die Daten- bankinhalte wären völlig unauffällig, da die Chiffrate als solche nicht als außerhalb des HSM erstellt erkannt werden können. Der Angreifer muss na- türlich zusehen, dass die Manipulation der beA-Anwendung möglichst (lange) nicht auffällt. 2. Der Angreifer kann gezielt einem potentiellen Absender das erstellte Zertifikat unterschieben, um dann die versendeten Nachrichten abzufangen. Um nicht aufzufallen, kann er dann das echte Zertifikat des Empfängers verwenden, um die Nachricht weiterzuleiten. Version: 1.0 Stand: 18.06.2018 Seite 83",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p83-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 84,
"content": "Technische Analyse und Konzeptprüfung des beA {S30} Zertifikatsanträge für Postfachschlüssel enthalten keine Authentisierung der signierenden HSM {R30} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle: Der Angreifer benötigt Zugriff auf die Schnittstelle, über die die BNotK Zerti- fizierungsanträge für Postfachschlüssel entgegennimmt und ausgibt, und Zugriff auf den SAFE BRAK, um das erschlichene Zertifikat Versendern von Nachrichten anzubieten. Dies ist unmittelbar nur einem Innentäter oder einem erfolgreichen Angreifer möglich, der über geeignete Zugriffs-Rechte auf zwei Teilkomponenten des beA verfügt (SAFE BRAK und Schnittstelle zur BNotK). Bewertung Ausnutzbarkeit: niedrig Bewertung der Bedrohung: Innentäter oder erfolgreiche Angreifer können neue oder bestehende ein- zelne Postfächer unbemerkt unter ihrer Kontrolle halten und Inhalte mitle- sen oder verändern. Sie können einen erfolgreichen Angriff gegen jedes beliebige Postfach ohne nennenswerten Mehraufwand wiederholen und somit, solange der Angriff läuft, potentiell Zugriff auf den Inhalt aller einge- henden Nachrichten bekommen. Das Schadenspotential ist somit deutlich höher als bei einem Angriff auf ein Postfach bei einem beA-Anwender über dessen IT-Infrastruktur. Bereits vor dem Angriff vorhandene Nachrichten sind nicht gefährdet. Bedrohung Integrität: niedrig Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: hoch Die Einstufung des Risikos als betriebsbehindernd ergibt auch aus der Kombination geringer Ausnutzbarkeit mit einem hohen Schadenspotential. {M30} Es wird empfohlen, dafür zu sorgen, dass die BNotK erkennen kann, dass der Zertifikatsantrag im HSM signiert wurde und Schlüssel enthält, die im HSM erzeugt wurden. Dies ist technisch z.B. durch eine elektronische Ge- rätesignatur realisierbar. 5.5.2 EGVP-Bürger-Verzeichniseinträge im SAFE können irreführend sein Damit auch Bürger mit den Nutzern des beA kommunizieren können, sind diese in der beA-Client-Security adressierbar. Die SAFE-Einträge, die der Bürger mit dem EGVP anlegen kann, werden allerdings bei der Einrichtung nicht geprüft, weshalb hier Phantasiedaten angegeben sein können. Dabei kann der Bürger auch Bezeichnungen wählen, die mit Institutionen oder an- deren Personen assoziiert werden. Es gibt einen Schutz dagegen, dass Bürger für sich selbst Bezeichnungen als Gerichte wählen, sie können sich aber bspw. für ei- nen Anwalt ausgeben. Die frei gewählten Bezeichnungen werden bei einer entspre- Version: 1.0 Stand: 18.06.2018 Seite 84",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p84-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 85,
"content": "Technische Analyse und Konzeptprüfung des beA chenden Suche im Client angezeigt, ohne dass ihr Ursprung (Rolle EGVP-Bürger) direkt erkennbar ist. Dies könnte zum Versand vertraulicher Informationen an den falschen Adressaten führen. Die Kommunikation von beA-Nutzern mit EGVP-Nutzern hat allgemein aufgrund mangelnder Authentifizierung für Bürger und ungeeigneter Verschlüsselungszertifi- kate (Verwendung nicht prüfbarer Zertifikate) nicht das Sicherheitsniveau der Ver- traulichkeit von Nachrichten, das vom beA angestrebt wird. Im EGVP wird der Vertraulichkeit von Nachrichten nicht die gleiche Bedeutung. {S31} In der Rolle EGVP-Bürger können beliebige ungeprüfte Verzeichnisein- träge in SAFE vorgenommen werden, z.B. auch auf den Namen eines Anwalts oder eines anderen Bürgers. Dies kann Versender irreführen und sie dazu bringen, Nachrichten falsch zu adressieren. {R31} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit der Schwachstelle: Für Angreifer ist eine Registrierung unter wirksam irreführenden Namen im EGVP leicht möglich. Der Angriff kann durch jedermann erfolgen und benötigt kaum Aufwand und keine Überwindung einer Sicherheitsmaß- nahme. Es ist nicht klar, in wie weit sich beA-Nutzer der Gefahr der Irre- führung durch EGVP-Nutzer bewusst sind. Für die Bewertung wird angenommen, dass dieses Bewusstsein teilweise vorhanden ist, was den Kreis der angreifbaren beA-Nutzer einschränkt (auf die, die sich der Ge- fahr der Irreführung nicht bewusst sind). Durch diese Annahme wird die Einstufung der Ausnutzbarkeit ein von „hoch“ auf „mittel“ gesenkt. Bewertung der Ausnutzbarkeit: Mittel Bewertung der Bedrohung: Angreifer können Zugang zu Nachrichten von beA-Nutzern an andere Anwälte und Mandanten erhalten, wenn die beA-Nutzer die Irreführung nicht erkennen. Dabei können eine Vielzahl von Kommunikationsbezie- hungen angegriffen werden. Der Zugang ist allerdings nicht umfassend auf alle Nachrichten des beA oder auf ein ganzes beA-Postfach, weshalb die Bedrohung für die Vertraulichkeit als mittel bewertet wird. Bedrohung Integrität: niedrig Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: mittel Die Kombination aus mittlerer Ausnutzbarkeit und mittlerer Bedrohung der Vertraulichkeit ergibt die Bewertung als betriebsbehindernde Schwach- stelle. {M31} In der beA-Client-Security sollte klar erkennbar sein, ob es sich bei einem Adressaten um einen authentisierten Nutzer handelt oder nicht. Auf jeden Fall sollte erkennbar sein, wenn der Adressat die Rolle EGVP-Bürger hat (Warnung vor ungeprüften Angaben). Version: 1.0 Stand: 18.06.2018 Seite 85",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p85-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 86,
"content": "Technische Analyse und Konzeptprüfung des beA 5.5.3 HSM-Schlüssel existieren außerhalb des HSM Das HSM verwendet zur verschlüsselten Ablage und zur Umverschlüsselung Ar- beitsschlüssel. Die Arbeitsschlüssel liegen auch außerhalb des HSM als verschlüs- selte Dateien vor, die mit ebenfalls außerhalb des HSM vorliegenden Key Encryption Keys entschlüsselt werden können. Elementar geht es um die Sicherheit der verschlüsselten Arbeitsschlüssel (Master- Key-Sets) für die verschiedenen Zwecke des HSM und der Schlüssel (Key Encrypti- on Keys, KEKs), mit denen die Arbeitsschlüssel verschlüsselt sind, sowie die Ver- wahrung der mit den KEKs verschlüsselten Master-Key-Sets. Wer sich in den Besitz dieses Schlüsselmaterials bringt, kann die im beA-System gespeicherten Nachrich- ten auch ohne HSM entschlüsseln, unverzüglich und umfassend, d.h. jede Nachricht kann davon betroffen sein. Die Arbeitsschlüssel sowie die Schlüssel, mit denen sie entschlüsselt werden kön- nen, sind vom Betreiber des beA erzeugt worden, an den Auftraggeber übergeben worden und seither in seinem Besitz. Sie sind dort mit organisatorischen Maßnah- men gesichert, die teilweise dokumentiert, teilweise mündlich beschrieben wurden (Verwahrung des KEK in zwei Teilen, mit getrenntem Zugriff auf jeden Teil durch ei- nen Key Custodian, Ablage in versiegelten Umschlägen in Safes). Der Zugriff ist dadurch stark erschwert, aber nicht unmöglich. Der Missbrauch dieser Schlüssel kann auf zwei Arten geschehen: die Key Custodi- ans des Auftraggebers und ein Helfer beim Betreiber des beA führen den verschlüs- selten Nachrichtenbestand und die Schlüssel zusammen und sind dann in der Lage, die Nachrichten zu entschlüsseln. Oder es wurde unberechtigt beim Betreiber des beA nach der Erzeugung der Schlüssel vor der Übergabe an den Auftraggeber an einer Stelle eine Kopie erstellt. Dann kann das Personal des Betreibers alleine die Nachrichten entschlüsseln. Vor diesem Hintergrund besteht zudem die Möglichkeit, dass der Auftraggeber im Rahmen von Beschlagnahmen von Postfächern gezwungen werden könnte, Nach- richten offenzulegen. Damit sind rechtliche Fragen verbunden, die im Rahmen die- ses Gutachtens nicht beantwortet werden können. Daher wurde diese Möglichkeit auch nicht in die Bewertung der Ausnutzbarkeit einbezogen. Die Verwahrung der Schlüssel außerhalb der HSM dient der Inbetriebnahme neuer HSM. Diese Praxis ist nicht unüblich und findet z.B. im Bankwesen oft Anwendung. Damit sie für das beA geeignet ist, ist es erforderlich, dass die beA-Anwender als potentiell vom Bruch der Vertraulichkeit Bedrohte dem Auftraggeber und dem Be- treiber des beA ausreichend vertrauen. Ob dies der Fall ist, kann im Rahmen dieses Gutachtens nicht beurteilt werden. Ist ausreichendes Vertrauen vorhanden, kann die hier aus technischer Sicht (Möglichkeit und Umfang des Schadens) als betriebsbe- hindernd riskant bewertete Praxis fortgesetzt werden. Version: 1.0 Stand: 18.06.2018 Seite 86",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p86-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 87,
"content": "Technische Analyse und Konzeptprüfung des beA {S32} Alle HSM-Schlüssel existieren auch außerhalb des HSM. {R32} Risikobewertung: B-Betriebsbehindernd Ausnutzbarkeit: Der Angriff ist nur durch bestimmte Innentäter durchführbar, die dabei ei- ne Vertrauensstellung haben müssen, die sie missbrauchen. Die Aus- nutzbarkeit ist daher niedrig. Bewertung der Ausnutzbarkeit: niedrig Bewertung der Bedrohung: Der Angriff erlaubt die umfassende Aufdeckung des Inhalts aller in beA- Postfächern gespeicherten Nachrichten. Die Bedrohung wird daher als hoch eingeschätzt. Bedrohung Integrität: niedrig Bedrohung Verfügbarkeit: niedrig Bedrohung Vertraulichkeit: hoch Die Kombination aus niedriger Ausnutzbarkeit und hoher Bedrohung ergibt eine Bewertung der Schwachstelle als betriebsbehindernd. {M32} Die HSMs sollen die Arbeitsschlüssel selbst erzeugen, und nur in ver- schlüsselter Form zur Übertragung auf andere HSMs herausgeben (Key- Wrapping). Alle HSM-Schlüssel sollten nur innerhalb speziell gesicherter Hardware (HSM, Chipkarte) gespeichert werden. Version: 1.0 Stand: 18.06.2018 Seite 87",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p87-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 88,
"content": "Technische Analyse und Konzeptprüfung des beA 5.6 Auflistung der C-Schwachstellen Es wurden zwei Schwachstellen mit der Risikobewertung C gefunden. Tabelle 15: Konzept C-Schwachstellen Kurzbeschreibung Bedrohung Ausnutzbarkeit Verfügbarkeit Vertraulichkeit Schwachstelle Integrität behoben Legende: h=hoch; m=mittel; n=niedrig; J=Ja Berechtigungs-MACs können nicht sicher widerrufen werden, n m m n - sondern nur durch Entfernung aus der Berechtigungsdaten- bank deaktiviert werden. Ein Wiedereinspielen bleibt möglich, was ehemals berechtigten Lesern eines Postfachs wieder unberechtigt Zugriff auf dieses Postfach verschaffen könnte. Die Postfach-ID wird bei der Beantragung einer Berechtigung n m m n - nicht mitsigniert. Der Antrag kann daher für andere Postfächer, die der Antragsteller administrieren darf, missbraucht werden und dadurch Berechtigungen schaffen, die nicht beabsichtigt sind. Version: 1.0 Stand: 18.06.2018 Seite 88",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p88-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 89,
"content": "Technische Analyse und Konzeptprüfung des beA 5.7 Anmerkungen zu Betriebs- und Sicherheitskonzepten Das beA-System ist seinem Wesen nach eine IT-Sicherheitslösung. Für den siche- ren Betrieb einer solchen Lösung bedarf es eines verbindlichen Sicherheitsregel- werkes mit mindestens folgenden für die IT-Sicherheit wesentlichen Konzepten: ■ Sicherheitskonzept o Systemmodellierung o Schutzbedarfsanalyse o Bedrohungsanalyse o Risikoanalyse o Beschreibung der Sicherheitsmaßnahmen o Vollständigkeitsprüfung und Restrisikoanalyse ■ Kryptokonzept o Welche Algorithmen und Betriebsmodi werden wo verwendet? o Welche Schlüsselparameter werden verwendet? o etc. ■ Schlüsselmanagementkonzept (ggf. als Bestandteil des Kryptokonzepts) o Wie werden Schlüssel erzeugt? o Wie werden Schlüssel verwahrt und verwaltet? o Wie werden Schlüssel sicher ausgetauscht? o Wie werden Schlüssel gelöscht? o etc. ■ Incident- und Security-Managementkonzept Für das Gutachten wurden Konzepte seitens des Betreibers bereitgestellt, ange- passt bzw. neu erstellt. Dieser Prozess ist jedoch zum Zeitpunkt der Erstellung des vorliegenden Berichts noch nicht abgeschlossen, so dass hier noch Handlungsbe- darf besteht. Im Folgenden wird daher der aktuelle Stand dargestellt, so wie er für die konzeptionelle Analyse zur Verfügung stand. In Bezug auf die notwendigen Bestandteile eines Sicherheitskonzeptes liegt eine nachvollziehbare und vollständige Schutzbedarfsanalyse vor. Grundsätzlich erfolgt der Betrieb des beA in einer ISO-27001-zertifizierten Infrastruktur, so dass grundle- gende Elemente des sicheren Betriebs vorhanden sind. Des Weiteren werden in Version: 1.0 Stand: 18.06.2018 Seite 89",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p89-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 90,
"content": "Technische Analyse und Konzeptprüfung des beA verschiedenen Dokumenten umfangreiche und für das beA spezifische physikalisch- organisatorische Schutzmaßnahmen beschrieben. Die IT-Komponenten der beA- Umgebungen befinden sich in zwei baulich getrennten Rechenzentren, die unab- hängig voneinander betrieben werden. Es sind detaillierte Angaben zur physika- lisch-organisatorischen Sicherheit der Rechenzentren beschrieben. Sicherheitsmaßnahmen für Rechenzentren gemäß einer vorgegebenen Policy sind einzuhalten. Der Auftraggeber hat das Recht, nach Anmeldung die Rechenzentren und IT-Komponenten zu prüfen und Auditberichte einzusehen. Es fehlt allerdings eine dokumentierte Analyse der möglichen Bedrohungen der schutzbedürftigen Assets, eine Risikobewertung sowie eine geschlossene Darstel- lung der den Risiken entgegenwirkenden Sicherheitsmaßnahmen. Damit liegt noch kein Vollständigkeitsnachweis darüber vor, dass jedem nicht tragbaren Risiko aus- reichend mit Sicherheitsmaßnahmen begegnet wird. Die grundsätzlichen kryptographischen Schritte im Umgang mit Nachrichten konnten anhand der vorgelegten Feinkonzepte und des Kryptokonzeptes nachvollzogen werden. Angaben über die verwendeten Algorithmen und ihre Parametrisierung wurden zum Teil nur summarisch gemacht. Vermisst wurde eine genaue Darstel- lung der kryptographischen Operationen auf die verschiedenen Datenelemente mit Kryptoschutzbedarf. Daher war es nicht immer möglich, die vom beA ausgeführten kryptographischen Operationen im Detail nachzuvollziehen und sich von der Ge- schlossenheit und kryptographischen Robustheit des Schutzes der Nachrichten zu überzeugen. Angaben zum Schlüsselmanagement (Erzeugung, Verwendung, Wechsel, Vernich- tung) verteilten sich auf eine Vielzahl von Dokumenten, ohne dabei in der Summe vollständig zu sein. Zum Incident- und Securitymanagement wurde ein Dokument vorgelegt, das allge- mein Verantwortlichkeiten und Rollen, aber keine spezifischen Sicherheitsvorfälle für die beA-Anwendung aufzählt und die Reaktionsweise für das Auftreten festlegt. Es wird der Einsatz eines Tools des Betreibers zur Auswertung von Logmeldungen durch ein Call-Center angeführt, aber nicht beschrieben, um welche Art von Log- meldungen der beA-Anwendung es sich handelt. Damit ist nicht einschätzbar, wel- che Bedeutung das Tool im Rahmen des Incident-Managements für die beA- Anwendung hat. Weiterhin wird auf ein Tool zur Untersuchung der IT-Landschaft des beA- Zentralsystems durch externes und internes Scannen auf bekannte Schwachstellen hingewiesen, das sich in der Einführung befindet. Diese Anwendung ist eine zu be- grüßende Sicherheitsmaßnahme. Zwischen dem Auftraggeber und dem Betreiber ist kein spezifisches Information Security Management vereinbart. Augenscheinlich werden Sicherheitsvorfälle im Rahmen eines allgemeinen, dem Auftraggeber und dem Betreiber zugänglichen Ti- cketsystems bearbeitet, dessen eigentlicher Zweck die Identifizierung und Beseiti- gung von Betriebsstörungen des beA ist. Sicherheitsvorfälle haben aber einen Version: 1.0 Stand: 18.06.2018 Seite 90",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p90-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 91,
"content": "Technische Analyse und Konzeptprüfung des beA anderen Charakter, so dass die Gefahr besteht, dass sie im Rahmen der allgemei- nen Incident-Behandlung zu niedrig priorisiert werden. Es erwies sich als zu schwierig, aus den vorgelegten Dokumenten das Rollenkon- zept zu ermitteln, das z.B. sicherstellt, dass an sicherheitskritischen Komponenten nur im 4-Augen-Prinzip gearbeitet werden kann. Im Rahmen der Neuorganisation der Sicherheitsdokumentation mit Erstellung eines bündelnden Sicherheitskonzep- tes muss darauf geachtet werden, dass für die in der Schutzbedarfsanalyse identifi- zierten oder daraus abgeleitet hoch schutzbedürftigen IT-System-Komponenten die angewendeten organisatorisch-physikalischen Sicherheitsmaßnahmen leicht zu fin- den sind. Grundsätzlich offenbaren die vorliegenden Dokumente einen geregelten IT-Betrieb, der auch den Aspekt IT-Sicherheit behandelt. Die Dokumentation erlaubt aber keine Prüfung, ob allen nicht tragbaren Risiken auch mit hinreichenden Sicherheitsmaß- nahmen begegnet wurde. Es wird empfohlen, ein Sicherheitskonzept nach dem üb- lichen Muster zu erstellen, das die aufgezählten Elemente und für jedes Sicherheitsrisiko einen klaren Verweis auf beschriebene Sicherheitsmaßnahmen in anderen Dokumenten enthält. In einer dabei zu erstellenden Restrisikoanalyse kön- nen sich ggf. Schutzlücken ergeben, die dann zu bewerten und zu schließen wären. Wichtig erscheint auch, dass auf der Basis einer nachvollziehbaren Sicherheitskon- zeption ein unabhängiger Auditor sich regelmäßig vom sicheren Betrieb des beA überzeugt. Dieses Audit kann sich dort, wo anwendbar, auf das regelmäßige ISO- 27001-Audit stützen und auch dessen Rhythmus folgen. Außerdem ist ein nachhaltiger Patchmanagement-Prozess zu betreiben, der ver- wendete Bibliotheken nach Bekanntwerden von Schwachstellen baldmöglichst ak- tualisiert. Version: 1.0 Stand: 18.06.2018 Seite 91",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p91-{size}.png"
},
{
"document": "https://fragdenstaat.de/api/v1/document/7551/",
"number": 92,
"content": "Technische Analyse und Konzeptprüfung des beA _______________________________________________________________________________ secunet Security Networks AG Kurfürstenstraße 58 45138 Essen, Deutschland _______________________________________________________________________________ Version: 1.0 Stand: 18.06.2018 Seite 92",
"width": 2481,
"height": 3508,
"image": "https://media.frag-den-staat.de/files/docs/97/41/c3/9741c36021614f71ab5e3e5a1ee8c237/page-p92-{size}.png"
}
]
}
