Sicherheitsscanner schlägt Alarm: A Unix account has a guessable password. CVE-1999-0501

[HansGraefe]

Hallo,

ich habe einen Debian 12 Server, auf dem läuft ein Apache2 mit folgender Konfiguration:

Code: Alles auswählen

<VirtualHost *:80>
  ServerName example.de
  Redirect permanent / https://example.de
</VirtualHost>

<VirtualHost *:443>
    ServerName example.de

    SSLProxyEngine On
    ProxyPass / https://example.de:8443/
    ProxyPassReverse / https://example.de:8443/

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.de/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.de/privkey.pem

    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"

</VirtualHost>

Auf dem gleichen Server auf Port 8443 läuft eine Java Application "Urlaubsverwaltung". Der Server wurde von einem Sicherheitsscanner (Cyberscan.io) überprüft, welcher folgendes moniert:

"It was possible to login with the following credentials (::) https://example.de/login:FIELD:HPWORD PUB:HTTP/1.1 200 https://example.de/login:MAIL:TELESUP:HTTP/1.1 200 ...[...]... Remote host accept more than 11 logins. This could indicate some error or some "broken" web application. Scanner stops testing for default logins at this point."

Port: 443
Protokoll: tcp
Risiko: high

Für die Application sind keine Sicherheitslücken bekannt (ist aktuell), das Debian 12 hält sich per unattended-upgrades aktuell und macht auch Reboots bei Bedarf. Java wird OpenJDK von Debian verwenden:

Code: Alles auswählen

root@server:~$ java -version
openjdk version "11.0.22" 2024-01-16
OpenJDK Runtime Environment (build 11.0.22+7-post-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 11.0.22+7-post-Debian-1deb11u1, mixed mode, sharing)
root@server:~$

Wenn ich zB. die URL https://example.de/login:FIELD:HPWORD im Browser eingebe, kommt "HTTP Status 404 – Not Found" - also was zum Geier testet dieser Scanner hier? Bei Bedarf gebe ich die URL per PN auch gern weiter. Ich glaube ja das ist ein Fehlalarm, aber wie "beweise" ich das?

PS: ich hätte noch einen Screenshot aber ich scheine hier keine Bilder anhängen zu dürfen.

[TRex]

Scanner sind mehr oder weniger dumm. Antwortet deine Anwendung auf fehlerhafte Logins mit HTTP/200?

[HansGraefe]

Scanner sind mehr oder weniger dumm. Antwortet deine Anwendung auf fehlerhafte Logins mit HTTP/200?

Ich habe schon folgendes probiert (von einem unabhängigen Server aus):

Code: Alles auswählen

root@server ~ # curl -v -u FIELD:HPWORD https://example.de/
*   Trying 111.222.333.248:443...
* Connected to example.de (111.222.333.248) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=example.de
*  start date: Mar 11 07:04:53 2024 GMT
*  expire date: Jun  9 07:04:52 2024 GMT
*  subjectAltName: host "example.de" matched cert's "example.de"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* using HTTP/1.1
* Server auth using Basic with user 'FIELD'
> GET / HTTP/1.1
> Host: example.de
> Authorization: Basic RklFTEQ6SFBXT1JE
> User-Agent: curl/7.88.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 302
< Date: Fri, 15 Mar 2024 08:21:29 GMT
< Server: Apache/2.4.57 (Debian)
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< X-Frame-Options: DENY
< Location: https://example.de/login
< Content-Length: 0
< Set-Cookie: SESSION=ZmJiNDUyNmMtNTRiMS00MzAwLWE4MzYtYTM5YmM4MTA0OWZj; Path=/; Secure; HttpOnly; SameSite=Lax
<
* Connection #0 to host example.de left intact
root@server ~ #

Aber ich sehe dort kein HTTP Code 200. Und wenn ich es direkt im Browser auf der Login-Seite der Application mache kommt: "Der eingegebene Name oder das Passwort ist falsch." Wenn ich es als URL aufrufe kommt "HTTP Status 404 – Not Found".

[4A4B]

Aber ich sehe dort kein HTTP Code 200.

Dafür 302:

Code: Alles auswählen

< HTTP/1.1 302

... mit Weiterleitungsziel:

Code: Alles auswählen

< Location: https://example.de/login

Dorthin würde ich den curl Aufruf nochmal absetzen

[HansGraefe]

Das wäre dann das:

Code: Alles auswählen

root@server ~ # curl -I -v -u MGR:HPP196 https://example.de/login
*   Trying 111.222.333.248:443...
* Connected to example.de (111.222.333.248) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=example.de
*  start date: Mar 11 07:04:53 2024 GMT
*  expire date: Jun  9 07:04:52 2024 GMT
*  subjectAltName: host "example.de" matched cert's "example.de"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* using HTTP/1.1
* Server auth using Basic with user 'MGR'
> HEAD /login HTTP/1.1
> Host: example.de
> Authorization: Basic TUdSOkhQUDE5Ng==
> User-Agent: curl/7.88.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200
HTTP/1.1 200
< Date: Fri, 15 Mar 2024 09:53:24 GMT
Date: Fri, 15 Mar 2024 09:53:24 GMT
< Server: Apache/2.4.57 (Debian)
Server: Apache/2.4.57 (Debian)
< X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
Pragma: no-cache
< Expires: 0
Expires: 0
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< X-Frame-Options: DENY
X-Frame-Options: DENY
< vary: accept-encoding
vary: accept-encoding
< Content-Type: text/html;charset=UTF-8
Content-Type: text/html;charset=UTF-8
< Content-Language: de-DE
Content-Language: de-DE
< Content-Length: 5753
Content-Length: 5753
< Set-Cookie: SESSION=MzRkMzFmZDctNjhiZi00MGFlLWIxYTUtNGMzMjQ4NWJkY2Nl; Path=/; Secure; HttpOnly; SameSite=Lax
Set-Cookie: SESSION=MzRkMzFmZDctNjhiZi00MGFlLWIxYTUtNGMzMjQ4NWJkY2Nl; Path=/; Secure; HttpOnly; SameSite=Lax

<
* Connection #0 to host example.de left intact
root@server ~ #

Und da kommt dann auch ein 200 zurück. Wäre das ein Bug in der Application?

[4A4B]

Gerade mit Firefox Inspector getestet: wenn ich mich in diesem Forum mit falschen Login-Daten anmelde, gibt der Webserver auch einen HTTP-Status-Code 200 zurück. Ein 401 wird wohl auch nur beim Zugangsschutz des Webservers zurückgegeben. Und ein 403, wenn die Login-Seite erst gar nicht aufgerufen werden darf? von daher könnte ein 200 bei einem fehlgeschlagenen Login in der Webapplikation durchaus üblich sein?

Wenn du den curl Aufruf mit korrekten Zugangsdaten absetzt, wird dann am Ende zusätzlich zum Session-Cookie ein weiterer (Login-)Cookie gesetzt?