Geen herauthenticatie bij gevoelige wijzigingen

Een gekaapte sessie is vervelend maar tijdelijk: hij verloopt, of de gebruiker logt uit. Tenzij de aanvaller binnen dat venster het herstelkanaal van het account op zijn eigen naam kan zetten. Dan verandert een tijdelijk probleem in een permanent verlies. Die ene extra vraag om het wachtwoord maakt het verschil.

Wat is herauthenticatie?

Herauthenticatie is het opnieuw laten aantonen van de identiteit op het moment dat een gebruiker iets gevoeligs wil doen, ook al is hij al ingelogd. In de praktijk betekent het dat om het huidige wachtwoord, en bij voorkeur ook de tweede factor, wordt gevraagd voordat de wijziging wordt doorgevoerd.

De reden ligt in het verschil tussen twee vragen. Een geldige sessie bewijst dat er ooit is ingelogd. Ze bewijst niet dat degene die nu aan het toetsenbord zit die persoon is. Dat verschil is doorgaans acceptabel: bij het bekijken van een overzicht of het opstellen van een bericht is de sessie voldoende grond. Bij het veranderen van de sleutels tot het account is dat niet zo.

Bij een bank mag u met uw pas naar binnen en kunt u aan de balie het een en ander regelen. Voor het wijzigen van uw adres of het aanvragen van een nieuwe pas wordt wel om extra legitimatie gevraagd. Niet omdat u verdacht bent, maar omdat juist die handelingen bepalen wie er in de toekomst binnenkomt.

Wat kan een aanvaller zonder herauthenticatie doen?

Kwetsbaar:

// De sessie is de enige voorwaarde
app.post('/account/email', vereistLogin, async (req, res) => {
  await gebruikers.wijzigEmail(req.gebruiker.id, req.body.nieuwEmail);
  res.send('E-mailadres bijgewerkt');
});

app.post('/account/wachtwoord', vereistLogin, async (req, res) => {
  await gebruikers.zetWachtwoord(req.gebruiker.id, req.body.nieuwWachtwoord);
  res.send('Wachtwoord bijgewerkt');
});

Een aanvaller die op enige manier een sessie in handen krijgt (via een onbeheerde werkplek, een gestolen cookie, cross-site scripting of een gedeelde computer) voert nu twee verzoeken uit. Eerst zet hij het e-mailadres op een adres dat hij beheert. Daarna wijzigt hij het wachtwoord.

Vanaf dat moment is de situatie omgekeerd. De rechtmatige eigenaar kan niet meer inloggen, want het wachtwoord is veranderd. Hij kan geen herstel aanvragen, want de herstelmail gaat naar het adres van de aanvaller. Daarnaast zijn eigen sessie verloopt vanzelf. Wat begon als tijdelijke toegang is een permanente overname geworden, en het terughalen ervan vergt tussenkomst van uw helpdesk.

Veilig:

async function bevestigIdentiteit(req) {
  // Onlangs bevestigd? Dan niet opnieuw vragen binnen dat venster
  if (req.session.bevestigdOp > Date.now() - 10 * 60 * 1000) return true;

  const gebruiker = await gebruikers.zoek(req.gebruiker.id);
  const klopt = await argon2.verify(gebruiker.hash, req.body.huidigWachtwoord ?? '');
  if (!klopt) return false;

  if (gebruiker.mfaActief && !await controleerMfa(gebruiker, req.body.mfaCode)) {
    return false;
  }
  req.session.bevestigdOp = Date.now();
  return true;
}

app.post('/account/email', vereistLogin, async (req, res) => {
  if (!await bevestigIdentiteit(req)) {
    return res.status(403).send('Bevestig eerst uw identiteit');
  }

  const oud = req.gebruiker.email;
  // Nieuw adres pas actief na bevestiging via dat adres
  await gebruikers.startEmailWijziging(req.gebruiker.id, req.body.nieuwEmail);

  // Waarschuwing naar het oude adres, met een weg terug
  await mail.stuur(oud, 'Er is een wijziging van uw e-mailadres aangevraagd. ' +
    'Was u dit niet? Gebruik deze link om de wijziging te blokkeren: ...');

  res.send('Controleer uw nieuwe e-mailadres om de wijziging te bevestigen');
});

Er zitten hier drie lagen in die elk afzonderlijk de aanval al bemoeilijken. De identiteit wordt opnieuw bevestigd, met een korte geldigheidsperiode zodat een gebruiker die meerdere instellingen aanpast niet steeds opnieuw hoeft te typen. Het nieuwe adres wordt pas actief na bevestiging via dat adres. Bovendien het oude adres krijgt een waarschuwing met een mogelijkheid om in te grijpen, precies de melding die de rechtmatige eigenaar nodig heeft om er op tijd bij te zijn.

Wat is de impact van ontbrekende herauthenticatie?

De ernst loopt van middelzwaar tot hoog. Het onderscheidende kenmerk is dat deze bevinding de gevolgen van elk ander probleem verzwaart: ze bepaalt of een tijdelijke compromittering tijdelijk blijft.

Zonder herauthenticatie is elke gekaapte sessie een potentiële permanente overname. Dat geldt voor de klassieke scenario’s (een onbeheerde werkplek, een gedeelde computer, een gestolen cookie) maar ook voor kortstondige situaties die anders zonder gevolgen zouden blijven, zoals een collega die even meekijkt op een niet-vergrendeld scherm.

Het gevolg raakt bovendien meer dan het account zelf. Wie het e-mailadres van een account beheert, kan vaak ook bij gekoppelde diensten binnenkomen die datzelfde adres als herstelkanaal gebruiken. Ook omdat de rechtmatige eigenaar is buitengesloten, verschuift het probleem naar uw helpdesk, die moet vaststellen wie de echte eigenaar is: een proces dat zelf weer een aanvalsoppervlak vormt.

Hoe spoor je ontbrekende herauthenticatie op?

Een tester loopt de accountinstellingen af en probeert bij elke gevoelige handeling of die kan worden voltooid zonder het huidige wachtwoord: het wijzigen van het e-mailadres, het telefoonnummer en het wachtwoord, het uitschakelen van tweefactorauthenticatie, het aanmaken van API-sleutels en het verwijderen van het account.

Belangrijk daarbij is de controle aan serverzijde. Applicaties vragen soms wél om het huidige wachtwoord in het formulier, maar controleren het niet werkelijk; een rechtstreeks verzoek zonder dat veld slaagt dan gewoon. Dat wordt expliciet getest. Verder wordt gekeken of de wijziging van een e-mailadres pas ingaat na bevestiging via het nieuwe adres, of het oude adres een waarschuwing ontvangt, en of bestaande sessies na een wachtwoordwijziging worden ingetrokken. Ook wordt beoordeeld of de API dezelfde eisen stelt als de webinterface, die twee lopen regelmatig uiteen. AssistSec toetst deze punten als samenhangend geheel, omdat de weerbaarheid wordt bepaald door de zwakste van de betrokken routes.

Hoe voorkom je ontbrekende herauthenticatie?

• Vraag om het huidige wachtwoord voordat u een wachtwoord, e-mailadres of telefoonnummer wijzigt.
• Vraag daarbij ook om de tweede factor wanneer die is ingeschakeld.
• Controleer die bevestiging aan serverzijde en niet alleen in het formulier.
• Laat een nieuw e-mailadres pas ingaan na bevestiging via dat adres.
• Stuur een waarschuwing naar het oude adres, met een mogelijkheid om de wijziging te blokkeren.
• Trek na een wachtwoordwijziging alle andere sessies en tokens in.
• Vraag ook opnieuw om bevestiging bij het uitschakelen van tweefactorauthenticatie en bij het aanmaken van API-sleutels.
• Houd de bevestiging kort geldig, zodat een gebruiker meerdere instellingen kan aanpassen zonder telkens opnieuw te typen.
• Stel dezelfde eisen aan de API als aan de webinterface.