Anwaltspostfach beA: Miserable Sicherheitsvorkehrungen auf bea.brak.de

Am Montag hat die Bundesrechtsanwaltskammer (BRAK) das besondere elektronische Anwaltspostfach wieder in Betrieb genommen. Die URL zur begleitenden Informationsseite des beA lautet: https://bea.brak.de/

Die Webseite basiert auf WordPress – das ist erstmal nicht weiter schlimm. Allerdings sollte man gewisse Sicherheitsvorkehrungen treffen, bevor man eine WordPress-Seite in Betrieb nimmt. Gerade für eine zum beA begleitenden Webseite wäre das jedenfalls höchst empfehlenswert.

Wie sich herausstellt wurde da leider wenig getan. So lässt sich bspw. die Anmeldeseite für das WordPress-Backend direkt erreichen: https://bea.brak.de/wp-login.php

Normalerweise zieht man vor die Anmeldeseite zumindest ein Basic Auth. Da es sich beim Webserver um einen Apache/2.4.6 handelt, würde folgendes Code-Snippet schon ausreichen:

# Ab Apache 2.4
# Auth protect wp-login.php
<Files wp-login.php>
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user
</Files>
# Deny access to important files
<FilesMatch "(\.htaccess|\.htpasswd)">
   Require all denied
</FilesMatch>

Das ist aber nicht alles – auch der Rest der WordPress-Installation ist in keiner Weise irgendwie »gehärtet«. So lässt sich bspw. auch die XMLRPC-Schnittstelle (xmlrpc.php) direkt aufrufen. Ein gefundenes Fressen für Angreifer, um mittels Bruteforce bis zu 500 Passwörter pro Anfrage auszuprobieren – den Benutzernamen verrate ich jetzt nicht, den kann jeder selbst schnell herausfinden.

Auch hier wäre das Problem über ein entsprechendes Apache-Code-Snippet schnell aus der Welt geräumt:

# Ab Apache 2.4
# Disallow access to important files
<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme)\.*)">
   Require all denied
</FilesMatch>

Irgendein Sicherheitsplugin (Jetpack Security) ist aber immerhin aktiv – blöd nur, dass diese selbst meist Sicherheitslücken im Code aufweisen und damit die Angriffsfläche unnötig erhöhen:

Deine IP (176.10.99.200) wurde wegen möglicher Sicherheitsverstöße als unsicher eingestuft. Mehr Infos …

Die Absicherung bzw. Härtung einer WordPress-Installation ist im Grunde genommen kein Hexenwerk – allerdings muss man es eben auch tun. Dazu habe ich bereits zwei Artikelserien verfasst:

Offenbar haben die Verantwortlichen noch immer nicht begriffen, welche Verantwortung sie mit der Bereitstellung und Betrieb vom beA innehaben.

Hinweis

Bei den hier veröffentlichten Informationen handelt es sich um keine Sicherheitslücken – allerdings wird ein Angriff, aufgrund nicht vorhandener Sicherheitsmaßnahmen, deutlich vereinfacht. Während der kurzen Analyse habe ich allerdings auch Schwachstellen ausfindig machen können und diese entsprechend gemeldet. Weiterhin habe ich die Verantwortlichen dazu angeregt, entsprechende WordPress-Härtungsmaßnahmen zu evaluieren – ich habe nämlich lediglich etwas an der Oberfläche gekratzt…
Hilf mit die Spendenziele zu erreichen! Mitmachen ➡