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:
- WordPress absichern (7 Teile, Jahr 2013)
- WordPress Sicherheit (3 Teile, Jahr 2016)
Offenbar haben die Verantwortlichen noch immer nicht begriffen, welche Verantwortung sie mit der Bereitstellung und Betrieb vom beA innehaben.