Mehrfaktorauthentifizierung ohne Verifizierung abschaltbar

Ein zweiter Faktor ist dazu da, in dem Moment weiterzuwirken, in dem mit dem Passwort oder der Sitzung etwas schiefgeht. Lässt sich dieser Faktor mit einem einzigen Klick abschalten, wirkt er genau dann nicht mehr. Im Folgenden lesen Sie, warum das Abschalten denselben Schutz verdient wie die Funktion selbst.

Was läuft beim Abschalten der MFA schief?

Mehrfaktorauthentifizierung wird danach beurteilt, wie gut sie die Anmeldung schützt. Regelmäßig außer Betracht bleibt dabei die Frage, wie sie sich abschalten lässt. Abschalten ohne Verifizierung bedeutet, dass ein angemeldeter Nutzer den zweiten Faktor entfernen kann, ohne erneut nachzuweisen, wer er ist.

Die Folge ist, dass der Schutz genau so stark ist wie die Sitzung. Und Sitzungen sind gerade das, was ein zweiter Faktor ausgleichen soll: Sie lassen sich über einen gemeinsam genutzten Rechner, ein gestohlenes Cookie, Cross-Site Scripting oder einen unbeaufsichtigten Arbeitsplatz kapern. In all diesen Fällen ist der zweite Faktor die verbleibende Schicht, sofern er sich nicht mit einer einzigen Anfrage aufheben lässt.

Dasselbe gilt für die Umwege ringsherum. Wiederherstellungscodes sind ein vollwertiger Ersatz für den zweiten Faktor; lassen sie sich ohne Bestätigung erneut abrufen, ist das dieselbe Tür unter anderem Namen. Damit gleicht das Schloss am Tresor einem Schloss, neben dem der Schlüssel hängt.

Wie schaltet ein Angreifer Ihre MFA ab?

Verwundbar:

// Nur eine gültige Sitzung ist erforderlich
app.post('/konto/mfa/abschalten', erfordertAnmeldung, async (req, res) => {
  await nutzerRepo.schalteMfaAb(req.nutzer.id);
  res.send('Zwei-Faktor-Authentifizierung abgeschaltet');
});

// Und die Wiederherstellungscodes lassen sich einfach erneut abrufen
app.get('/konto/mfa/wiederherstellungscodes', erfordertAnmeldung, async (req, res) => {
  res.json(await nutzerRepo.wiederherstellungscodes(req.nutzer.id));
});

Ein Angreifer, der auf irgendeine Weise eine Sitzung erlangt, muss den zweiten Faktor nicht umgehen; er schaltet ihn ab. Danach ändert er das Passwort, und das Konto gehört ihm, wobei der Schutz, den der Nutzer eigens eingeschaltet hatte, das erste Opfer ist.

Der zweite Endpunkt ist noch stiller. Der Angreifer lässt den zweiten Faktor einfach eingeschaltet, ruft die Wiederherstellungscodes ab und verwendet später einen davon. Der Nutzer bemerkt nichts: Sein Authenticator funktioniert weiterhin, es wurde nichts abgeschaltet, und es gab keine Meldung.

Sicher:

app.post('/konto/mfa/abschalten', erfordertAnmeldung, async (req, res) => {
  const nutzer = await nutzerRepo.finde(req.nutzer.id);

  // Passwort und der Faktor selbst: nachweisen, dass Sie ihn besitzen
  const passwortStimmt = await argon2.verify(nutzer.hash, req.body.passwort ?? '');
  const faktorStimmt = await pruefeMfa(nutzer, req.body.code ?? '');

  if (!passwortStimmt || !faktorStimmt) {
    await erfasseFehlversuch(nutzer.id, 'mfa-abschalten');
    return res.status(403).send('Bestätigung fehlgeschlagen');
  }

  await nutzerRepo.schalteMfaAb(nutzer.id);
  await nutzerRepo.entferneWiederherstellungscodes(nutzer.id);
  await sitzungen.entferneUebrigeFuer(nutzer.id, req.sessionID);

  await mail.sende(nutzer.email,
    'Für Ihr Konto wurde die Zwei-Faktor-Authentifizierung abgeschaltet. ' +
    'Waren Sie das nicht? Stellen Sie sie hier sofort wieder her: ...');
  await auditlog.schreibe('MFA abgeschaltet', { nutzer: nutzer.id, ip: req.ip });

  res.send('Zwei-Faktor-Authentifizierung abgeschaltet');
});

Der Vorgang verlangt nun das Passwort und den zweiten Faktor selbst. Letzteres ist der entscheidende Punkt: Der Nutzer weist nach, dass er den Faktor besitzt, nicht nur, dass er eine Sitzung hat. Zusätzlich werden die Wiederherstellungscodes ungültig gemacht, andere Sitzungen beendet, und der Nutzer erhält eine Meldung mit einem Weg zurück.

Welche Auswirkungen hat ohne Verifizierung abschaltbare MFA?

Der Schweregrad ist mittel bis hoch. Kennzeichnend ist, dass dieser Befund den Wert einer Maßnahme aufhebt, die die Organisation als geregelt betrachtet, wodurch das Risiko in der eigenen Berichterstattung unsichtbar wird.

Das Szenario ist stets dasselbe: Ein Angreifer besitzt eine Sitzung oder ein Passwort, aber nicht den zweiten Faktor. Genau für diese Lage existiert dieser Faktor. Kann er ihn aus dieser Position heraus abschalten oder die Wiederherstellungscodes abrufen, ist die Hürde verschwunden und die Übernahme vollständig.

Bei Konten mit weitreichenden Rechten wiegt das schwerer. Ein Administrator, für den ein zweiter Faktor verpflichtend ist, der ihn aber selbst ohne Bestätigung abschalten kann, bietet in der Praxis nicht mehr Schutz als ein Administrator ohne diese Pflicht. Und da das Abschalten häufig weder protokolliert noch gemeldet wird, bleibt es lange unbemerkt.

Wie spürt man ohne Verifizierung abschaltbare MFA auf?

Ein Tester schaltet einen zweiten Faktor ein und probiert danach alle Wege aus, ihn wieder loszuwerden. Lässt er sich allein mit der bestehenden Sitzung abschalten? Wird nach dem Passwort gefragt, und wenn ja, wird es serverseitig tatsächlich geprüft? Wird der Faktor selbst abgefragt?

Anschließend werden die Umwege betrachtet. Lassen sich Wiederherstellungscodes ohne Bestätigung erneut abrufen? Kann neben dem bestehenden ein neuer Faktor eingerichtet werden, ohne den alten zu bestätigen, womit der Angreifer sein eigenes Gerät hinzufügt, ohne dass etwas abgeschaltet wird? Funktioniert der Wiederherstellungsprozess bei Verlust über eine einzelne E-Mail-Bestätigung? Und stellt die API dieselben Anforderungen wie die Weboberfläche? Ebenso wird geprüft, ob der Nutzer eine Meldung erhält und ob der Vorgang in einem Auditprotokoll landet. AssistSec prüft diese Wege gesondert, denn der Schutz bestimmt sich nach dem schwächsten davon, und das ist selten der Hauptweg.

Wie verhindert man ohne Verifizierung abschaltbare MFA?

• Verlangen Sie beim Abschalten des zweiten Faktors das aktuelle Passwort und den Faktor selbst.
• Stellen Sie dieselben Anforderungen beim Hinzufügen oder Ersetzen eines Faktors, nicht nur beim Entfernen.
• Schützen Sie Wiederherstellungscodes ebenso gut: einmalig anzeigen und vor einer neuen Reihe eine erneute Authentifizierung verlangen.
• Machen Sie Wiederherstellungscodes ungültig, sobald der zweite Faktor abgeschaltet oder neu eingerichtet wird.
• Führen Sie den Wiederherstellungsprozess bei Verlust über einen verifizierten zweiten Kanal oder über Ihren Kundendienst mit Identitätsprüfung.
• Senden Sie unmittelbar eine Meldung an die bekannte Adresse, mit einer Möglichkeit einzugreifen.
• Beenden Sie andere Sitzungen, wenn sich die Authentifizierungseinstellungen ändern.
• Halten Sie jede Änderung am zweiten Faktor in einem Auditprotokoll fest.
• Stellen Sie an die API dieselben Anforderungen wie an die Weboberfläche.