Angriff innert Sekunden: Wieso «Basic Authentication» bei uns standardmässig aktiviert ist
Wenn du bei uns eine neue Website erstellst, dann wirst du feststellen, dass Basic Authentication (Basic Auth) standardmässig aktiviert ist. Das klingt auf den ersten Blick übervorsichtig, hat aber gute Gründe. Nachfolgend erfährst du, weshalb es das braucht und weshalb Basic Auth bei uns in der Handhabung einfacher ist als anderswo.
Nehmen wir an, du möchtest ein WordPress installieren. Dazu legst du dir eine neue Subdomain an, erstellt beim Hostinganbieter deiner Wahl eine neue Website und installierst WordPress. Der WordPress-eigene Setup-Assistent navigiert dich im Browser durch die Installation und schon ist dein Content Management System installiert. In etwa so funktioniert das auch mit anderen Applikationen, wie beispielsweise Matomo, Nextcloud oder TYPO3.
Angriff innert Sekunden
Das beschriebene Vorgehen birgt jedoch Gefahren. Der Setup-Assistent ist für kurze Zeit öffentlich abrufbar. Das dürfte bekannt sein und wird häufig mit dem Argument "die Subdomain kennt doch noch niemand" bewusst in Kauf genommen. Doch das ist ein Trugschluss, wie folgendes Access Log innert Sekunden nach dem Anlegen des Hostnames zeigt:
[21/May/2024:13:14:39 +0200] "GET /.git/config HTTP/2.0" 404 "colly"
[21/May/2024:13:14:40 +0200] "GET /server HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /.vscode/sftp.json HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /about HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /debug/default/view?panel=config HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /v2/_catalog HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /server-status HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /login.action HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /_all_dbs HTTP/1.1" 404 "Mozilla/5.0"
[21/May/2024:13:14:40 +0200] "GET /.DS_Store HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /.env HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /.git/config HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /config.json HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:40 +0200] "GET /telescope/requests HTTP/1.1" 404 "Go-http-client/1.1"
[21/May/2024:13:14:41 +0200] "GET /?rest_route=/wp/v2/users/ HTTP/1.1" 200 "Go-http-client/1.1"
Timeline:
- 13:12 Uhr: Hostname erstellt
- 13:14 Uhr: Erste Bots
Angriffsszenario:
- Du erstellt eine Website und entpackst die Installationsdateien.
- Ein Bot findet innert Sekunden den öffentlichen Setup-Assistenten.
- Der Bot klickt sich durch den Assistenten (nutzt dazu ggf. eine externe DB).
- Der Bot installiert per Plug-in eine Backdoor und setzt den Assistenten zurück.
- Du merkst davon nichts und installierst ein bereits kompromittiertes WordPress.
Hierbei handelt es sich um kein ausgedachtes Szenario, wie ein Vortrag an der Sicherheitskonferenz «DEF CON» zeigt. Doch wie erfahren die Bots so schnell von der neuen, noch nicht kommunizierten Subdomain?
Certificate Transparency
Certificate Transparency (CT) ist ein Standard, welcher massgeblich von Google vorangetrieben wird. Der Standard funktioniert so: Sobald ein Zertifikat-Herausgeber ein SSL-Zertifikat ausstellt, in unserem Fall Let's Encrypt, wird diese Tatsache in den CT-Logs öffentlich gemacht. In den CT-Logs kann nun jedes öffentliche Zertifikat ausfindig gemacht werden, ein Opt-out gibt es nicht.
Das dient, wie der Name bereits sagt, der Transparenz. Bedeutet aber auch, dass die Hostnames, für welche das Zertifikat ausgestellt wurde, innert Sekunden öffentlich bekannt sind. Angreifer machen sich das zunutze und erfahren so von neuen Hostnames innert wenigen Sekunden. Um neugierige Blicke zu verhindern, sollte deshalb immer ein Passwort-Schutz davor gestellt werden.
Wie Basic Auth bei Ops One funktioniert
Wir wären nicht Ops One, wenn wir uns nicht überlegt hätten, wie Basic Auth in der Handhabung vereinfacht werden könnte. Falls du einen Managed Server verwendest, profitierst du von folgenden Vorteilen:
- Basic Auth standardmässig aktiviert
- einfache Verwaltung mittels Benutzeroberfläche
- serverübergreifende Zugangsdaten pro Mitarbeiter:in
Letzteres ist das, was die Nutzung von Basic Auth bei uns vereinfacht. Statt dass du für jede Website unterschiedliche Passwörter generierst, welche im Team geteilt werden müssen, kannst du zentral pro Mitarbeiter:in ein Passwort definieren. Das Passwort gilt dann für jede Website auf jedem Managed Server, welche Basic Auth aktiviert hat. Somit entfällt die Frage nach dem Passwort, sobald du eine neue URL mit einem Team-Gspäändli teilst.
Dazu definierst du global:
{
"website::users": {
"alice": {
"preview": "$apr1$34c5ifm6$JAVgpW9LCqYDtuHu85ney0"
},
"bob": {
"preview": "$apr1$ba3eiyhg$4ysJEF9povrHhKdPkj5f3."
}
}
}
Weitere Details dazu findest du in unserer Dokumentation. Und falls dich unsere Managed Server bereits jetzt begeistern, freuen wir uns, falls du Kontakt mit uns aufnimmst.