JWT Key Confusion Hyökkäykset

JWT ja Asymmetrinen Salaus

JWT on mahdollista allekirjoittaa myös asymmetrisellä, eli julkisen avaimen salauksella. Tällöin meillä on käytössä yhden salausavaimen sijasta kaksi avainta, julkinen ja yksityinen avain.

Julkisen avaimen voi nimensä mukaisesti jakaa vapaasti maailmalle. Julkista avainta voidaan käyttää yksityisellä avaimella allekirjoitetun JWT:n tarkistamiseen.

Otetaan esimerkki. Sanotaan, että meillä on HTTP-rajapinta api.example.com johon kirjaudutaan JWT-tokenilla jonka myöntää kirjautumispalvelu auth.example.com.

Kirjautuminen ja HTTP-rajapinnan käyttö voisi toimia näin:

• Käyttäjä lähettää käyttäjätunnuksensa ja salasanansa tunnistuspalvelulle (auth.example.com). Käyttäjätunnus: "Maija", salasana: "kissa123".
• Tunnistuspalvelulla on yksityinen avain, kenelläkään muulla ei ole sitä. Tunnistuspalvelu käyttää yksityistä avaintaan, ja allekirjoitaa sillä JWT:n jossa on claimeissa käyttäjänimi "Maija".
• Maija lähettää seuraavaksi HTTP-rajapinnalle (api.example.com) viestin, jossa on JWT mukana (tyypillisesti Authorization-otsakkessa).
• HTTP-rajapinnalla on tunnistuspalvelun julkinen avain, jonka se on tyypillisesti hakenut tunnistuspalvelun /.well-known/jwks.json -polusta. HTTP-rajapinta validoi JWT-tokenin julkisella avaimella, ja jos se on allekirjoitettu oikealla yksityisellä avaimella, tarkistus onnistuu, ja tiedetään että Maija on tosiaan Maija. Ainakin jos tunnistuspalveluun on luottaminen.

Haavoittuvuus

Haavoittuvuus, joka tällaisessa tilanteessa saattaa joskus syntyä, on luonteeltaan hyvin samankaltainen edellisen moduulin none-algoritmi -hyökkäyksen kanssa.

Sanotaan, että HTTP-rajapinnassa on tämän näköinen koodi validoimasssa tokenin:

token = request.getHeader("Authorization")
public_key = hae_julkinen_avain_tunnistus_palvelusta()

token_oikein = jwtKirjasto.validoiToken(
  token=token,
  public_key=public_key
)

Mitä algoritmia validoiToken-kutsu käyttää? Sitä ei ole erikseen määritetty koodissa, joten JWT-toteutus käyttää sitä algoritmia mikä tokenissa on. Ja jos tokenissa on oikea algoritmi, kuten RS256, mitään ongelmaa ei ole, ja kaikki toimii hienosti.

• Otetaan token
• Otetaan julkinen avain
• Tarkastetaan julkista avainta käyttäen, onko tokenin RSA-allekirjoitus OK?

Mutta mitä tapahtuu, jos tokenissa sattuukin olemaan vaikka HS256, joka on symmetrinen, eli yhteen, ajettuun salaisuuteen perustuva algoritmi? Silloinhan saattaisi käydä että:

• Otetaan token
• Otetaan julkinen avain
• Tarkastetaan, onko tokeni allekirjoitettu symmetrisellä salausavaimella jonka arvo on julkinen avain?

Toisin sanoen, jos koodi on kirjoitettu tällä tavalla, hyökkääjän saattaa olla mahdollista huijata sovellus tekemään tokenin tarkastus symmetrisellä algoritmilla, käyttäen julkista salausavainta joka on hyökkääjän tiedossa.

Hyökkäys

Aloita hankkimalla JWT-token sovelluksessa ja etsimällä sopiva HTTP-pyyntö jonka voit lähettää repeateriin, jolloin pääset helposti kokeilemaan uudestaan ja uudestaan että jospas tietyllä tavalla muokattu token menisikin läpi. Sama juttu siis kuin viime moduulissa.

Seuraava vaihe on hankkia sovelluksen julkinen avain. Alla olevassa harjoituksessa tämä on tehty varsin helpoksi:

Oikeassa maailmassa julkinen avain, silloin kun se on tehty julkiseksi, löytyy yleensä JWKS JSON-rakenteen sisältä osoitteesta /.well-known/jwks.json.

Monesti julkista avainta ei ole julkaistu lainkaan. Tähänkin tilanteeseen löytyy keinot, mutta palataan siihen myöhemmässä moduulissa.

Kun sinulla on julkinen avain, ota token ja muuta se symmetriseksi, kokeile vaikka HS256 -algoritmia. Käytä julkista avainta symmetrisenä salausavaimena, rakenna token uusiksi ja koita pääsisitkö sillä läpi!

Kuten edellisessä moduulissa, voit käyttää tähän Hakatemian JWT-studiota tai vaihtoehtoisesti BurpSuiten laajennuksia.