BIMI ja DMARC ei pruugi päästa: Tähelepanuta jäänud DKIM haavatavus

Zone spetsialistid märkasid DKIM standardis olevate hoiatuste ignoreerimisest tulenenud haavatavust, mis mõjutab kogu e-posti ökosüsteemi ja paneb ohtu miljardeid kasutajad.

Tegu ei ole otseselt ühe spetsiifilise tarkvaratoote veaga vaid haavatavusega, mis tuleneb DomainKeys Identified Mail (DKIM) standardi erinevatest tõlgendustest ökosüsteemi kuuluvate tarkvarajuppide ja teenusepakkujate poolt.

Antud nõrkust saab kasutada selliste võltsingute loomiseks, mis läbivad DKIM-i krüptograafilised kontrollid ja mida saab seejärel lihtsalt valitud ohvritele uuesti edasi saata. Taolised võltsingud läbivad DKIM-i tõttu ka tõenäoliselt selle sama domeeni DMARC (Domain-based Message Authentication Reporting and Conformance) poliisi määratud nõudmisi. Samas on paljudel saatjatel tekkinud eeldus, et DMARC hoiab ära sellisel kujul nende nimel saadetavad õngitsus- ja muud rünnakud.

Probleem on muutunud tõsisemaks seoses BIMI (Brand Indicators for Message Identification) kasutuselevõtuga. BIMI puhul sõltutakse sellest, et enne seda klapib kõik DMARC poliisiga. Kui tingimused on täidetud kuvavad mõned meiliteenused, nagu näiteks Apple Mail ja Google Gmail kuid ka Zone enda Webmail kirja juures vastavat kaubamärki. Kui aga kasutajaliides peaks kuvama, et kuidagi pahatahtlikud muudetud kirjad on nüüd eriti usaldusväärsed, on tegu tõsise probleemiga.

BIMI Gmail-is ja Apple Mail-is:

Oma testidega suutsime tuvastada, et antud nõrkust sai mitmete teenusepakkujate juures praktikas vabalt kasutada. Testide aluseks sai võtetud mitmete suurfirmade saadetud haavatavad kirjad ning need jõudsid ilusasti “ohvri” sisendkasti. Tänaseks on haavatavust mitmel pool paigatud kuid arvestades e-posti ökosüsteemi suurust siis antud viga ilmselt kummitab veel pikalt.

Samas ei tohiks eeldada, et nõrkus mõjutab ainult neid saatjaid või vastuvõtjaid, kes on BIMI kasutusele võtnud. Tegu on siiski probleemiga DKIM-i kasutamise juures ning võltsingud läbivad nii DKIM kui ka DMARC kontrolle. Kui riske ei maandata ja kurjategijad selle enda arsenali lisavad, muutuvad õngitsusrünnakud suuremaks probleemiks. Kirja saatja autentimine ja nende meetodite tugevdamine on juba iseseivalt kriitilise tähtsusega.

Google’i kommentaar antud probleemi osas on järgnev (tõlgitult):

Antud uurimise käigus tuvastatud riskid näitavad otseselt miks Gmail ei toeta saates probleemset “l”-parameetrit. Arvestades kui üksteisega seotud on e-posti ökosüsteem soovitame kõigil meiliteenuse pakkujatel välja pakutud lahendusi järgida. Täname uurimist teostanuid sellele olulisele probleemile tähelepanu juhtimise eest.

Tehniline kokkuvõte

DKIM-standard (RFC 6376) määrab parameetri e-kirja sisu pikkuse (“l=”) määratlemiseks; see parameeter annab kirja valideerijale teada mitmest oktetist e-kirja keha koosneb.

Sisu pikkuse piirangu (“l=” parameetri) kasutamise riskid on teada olnud juba DKIM-i standardi avaldamisest alates (vt https://datatracker.ietf.org/doc/html/rfc6376#section-8.2), kuid juurde pandud hoiatused turvariskide osas ei ole täielikud. Standardis vaadatakse antud parameetrit üksi, ilma laiema pildita. Meie kirjeldatav lähenemisviis on võtta e-kiri, millel on antud parameeter DKIM allkirja juures kasutusel ja seejärel muuta kas olemasolevat sisu tüüpi määravat (Content-Type) päist või lisada täitsa uus, et sedaviisi asendada kogu kuvatav sisu soovituga.

Testide käigus ilmnes, et paljud saatjad kes niiviisi osaliselt kirju allkirjastavad, ei allkirjasta sisu tüüpi määravat päist. See teeb ründajale hästi lihtsaks selle asendamise talle soovitava väärtusega, ilma selle juures kirja allkirja rikkumata. Kuid tuleb tõdeda, et isegi kui päis oleks allkirjastatud siis ei ole see tavaliselt allkirjastatud topelt. See tähendab seda, et osaliselt kaitstud kirjale saab siiski lisada täiendava Content-Type päise, mis on nüüd üksi allkirjastamata kuid kiri üldiselt (ja teine Content-Type päis) on jätkuvalt kehtiva allkirjaga. Klientrakendused samas sellist lisatud päist ei ignoreeri, ega tohikski. Mitme Content-Type päise tõlgendamine ühes meilisõnumis pole üheselt määratletud ning seetõttu on klientrakenduste käitumine ja sellest tulenevad ohud natuke erinevad.

Meie meetod selle nõrkuse ärakasutamiseks on täpsemalt Content-Type päises seatud MIME-piir selliselt ära muuta, et kirja (allkirjastamata) lõppu lisatud uus struktuur taaskasutaks osaliselt vana. Originaalne sisu muutub nähtamatuks kommentaariks ja sunnib meiliklienti kuvama ainult lisatud sisu. Nii muudetud kirja tõlgendatakse valdavalt sarnasemalt ning läbi viidav rünnak on universaalsem ja sellest tulenevalt suurema mõjuga kui varasemalt kirjeldatu.

Lihtsustatud illustratsioon kirjeldatud rünnakust:

Algne meili sisu (koos kommentaaridega):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=naide.ee; l=1234; s=test;
  h=date:from:to:message-id:subject:mime-version; <-- Content-Type ei ole allkirjastatud
  bh=kDDbMi...; b=K8S4Yk2XjoIvBh...
Content-Type: multipart/mixed; boundary="abc"

<<<Multipart kommentaari algus
See on multi-part sõnum
>>>Multipart kommentaari lõpp

--abc
Sõnumi MIME-struktuur
--abc--[1234 byte cutoff]Code language: JavaScript (javascript)

Muudetud meili sisu (koos kommentaaridega):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=naide.ee; l=1234; s=test;
  h=date:from:to:message-id:subject:mime-version;
  bh=kDDbMi...; b=K8S4Yk2XjoIvBh...
Content-Type: multipart/mixed; boundary="abc--" <-- modified boundary

<<<Multipart kommentaari algus
See on multi-part sõnum

--abc
Sõnumi MIME-struktuur
>>>Multipart kommentaari lõpp
--abc--[1234 byte cutoff]

Võlts MIME struktuur

--abc----Code language: JavaScript (javascript)

Siinkohal tuleb tähele panna, et võltsimise käigus lisatud struktuuri esimene rida on endiselt allkirjastatud. Nii pääseb mööda lihtsamatest (ja varem kirjeldatud) kaitsemeetoditest “ebausaldusväärse” sisu mittekuvamise suhtes. Selline kiri läbib DKIM allkirjakontrolli ja klientrakendus kuvab lisatud sisu, ignoreerides originaali.

Kui sisu tüüpi määrav Content-Type päis on aga osa DKIM-i allkirjast, saab valdavalt siiski lisada täiendava päise ning haavatavust ära kasutada.

Muudetud meili sisu:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=naide.ee; l=1234; s=test;
  h=date:from:to:message-id:subject:mime-version:content-type;
  bh=kDDbMi...; b=K8S4Yk2XjoIvBh...
Content-Type: multipart/mixed; boundary="def" <-- lisatud (võlts) päis
Content-Type: multipart/mixed; boundary="abc"Code language: JavaScript (javascript)

Allkirjakontroll on edukas, kuna allkiri hõlmab ainult alumise päise poolt viidatud sisu. Kuna mõni meiliklient kasutab MIME-struktuuri määramise juures ülalt esimest väärtust, on võltsimine siiski edukas.

Selle leevendamiseks peaks Content-Type päis olema allkirjas kaitstud topelt (see tuleb kaks korda päiste loetellu “h=” lisada):

  h=date:from:to:message-id:subject:mime-version:content-type:content-type;Code language: JavaScript (javascript)

Sel juhul muudaks sõnumile lisatud mis tahes Content-Type päis DKIM-i allkirja kehtetuks. Samas see muudab allkirja natuke õrnemaks (transpordi käigus tehtavad pahaaimamatud muudatused võivad allkirja rikkuda), kuid kui kasutada “l=” parameetrit on see kordades parem kui alternatiivid.

Seotud probleemid

See ei ole esimene kord, kui keegi on sellistele probleemidele tähelepanu juhib, kuid tänaseks tõsidus oluliselt muutunud. Näiteks on sarnaseid rünnakuid on varem kirjeldanud Stephen Ullrich (https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html#spoofed_body_dhl) ja Valimaili meeskond (https://www.valimail.com/blog/breaking-dkim-or-simply-misunderstanding-how-it-works-in-practice/). Antud haavatavust saab suure tõenäosusega kombineerida ka muud laadi “reskin” rünnakutega, nagu näiteks Koboldi kirjad (https://lutrasecurity.com/en/articles/kobold-letters/), tehes sellise “voolitavuse” veel ohtlikumaks.

Kahjuks ei lõpe DKIM allkirjadega seotud probleemid sellega. Praktikas on ka saatjaid, kes allkirjastavad ainult kirja esimest oktetti “l=1” (nagu näiteks Maropost) ning see on juba niisamagi ohtlik. Loodetavasti tõstab motivatsiooni DKIM-i valideerijatel “l” parameetrit kasutavaid allkirju ignoreerida.

Vanim kiri mille me leidsime, mida saaksime rünnakuks ära kasutada (mille puhul on vastav avalik võti endiselt DNS-ist kättesaadav), pärineb lausa 2014. aastast. See Microsofti saadetud kiri ei kasuta mitte ainult “l=” parameetrit vaid ka SHA1 räsialgoritmi. Sellise võtmepaarid, mida on korra kasutatud RSA-SHA1 allkirjade andmise jaoks, oleks pidanud juba ammu maha kandma ja DNS-ist eemaldama. Keskendudes “l” parameetrile ei tohiks samas minetada seda, et nii pikalt kasutuses olev võtmematerjal on veaohtlik.

Väga vana võtmematerjali kasutamine on viinud ka selleni, et mittetühine osa saatjatest kasutab endiselt halvasti genereeritud või nõrku (512-bitiseid) RSA-võtmeid. Hanno Böck-i analüüsi (https://16years.secvuln.info/) järgi 0,24% Tranco Top 1 Million domeenidest jagavad jätkuvalt maailmaga “nõrku Debiani võtmeid”, mis on kergelt murtavad (ja väärkasutatavad).

Praktiline näide ja mõju

Analüüsides meile saabuvat meililiiklust leidsime palju silmatorkavaid domeene, nagu tesla.com, trendmicro.com, bloomberg.net, dell.com, cisco.com, ups.com, dhl.com, ebay.com, panasonic.com, whirlpool.com, hilton.com, norton.com, avast.com ja radissonhotels.com. Millest kõik on saatnud haavatavusega kirju. Päris selgelt on tegu väärtuslike sihtmärkidega.

Praeguseks hetkeks oleme näinud haavatavaid DKIM allkirju juba 3040 erinevast domeenist, millest 32 läbivad BIMI kontrolle ja millel on kehtiv VMC. Seetõttu peame päris ekslikuks Valimaili väidet, parafraseerides “tänapäeval ei kasuta peaaegu ükski saatja seda parameetrit.”

Muudetud kiri DHL-ilt:

Kaitse

Selle haavatavuse vältimiseks ja rünnakute kahjutustamise juures on juba DKIM-i standardis olemas sektsioon “Security Considerations” mis kirjeldab võimalikke lähenemisi: 8.2. Misuse of Body Length Limits (“l=” Tag).

Parafraseerides: “Selle rünnaku vältimiseks peaksid allkirjastajad olema selle parameetri kasutamisega äärmiselt ettevaatlikud ja kontrollijad võivad tahta ignoreerida allkirju selle parameetriga.” Seda ettepanekut tuleks aga praktikas tõlgendada palju rangemalt, kui “võivad tahta.” Kui mitte üldiselt siis vähemalt kontekstides kus on BIMI kasutusel. Ideaalis peaks seda siiski täielikult ignoreerima.

Allkirjade kontrollijad peaksid samas juba praegu hakkama tagasi lükkama väga vanade DKIM-allkirjadega kirju, et niiviisi leevendada vanade allkirjade väärkasutust. Kui mitte antud rünnaku kontekstis siis mõne muu sarnase tõttu. Kuid seda ei tohiks võtta kui lahendust, lahendus oleks “l” parameetrit kasutavate või muud moodi nõrku (SHA1-RSA algoritmi või ≤1024-bitite võtmetega antud) allkirju saab täielikult ignoreerida.

Saatjad, eriti sellised kes on kasutanud pikkust määravat parameetrit oma allkirjades, peaksid oma DKIM-võtmeid perioodiliselt välja vahetama. Kui seda ei tehta saab vanu e-kirju jätkuvalt uute võltsingute loomiseks kasutada. DKIM-võtmete välja vahetamiseks on nagu varem mainitud, palju rohkem põhjuseid.

Ajajoon

• 2024-01-26 Teavitasime Apple-it ja Google-it probleemist
• 2024-01-31 Teavitasime CERT-EE-d probleemist
• 2024-02-02 Teavitasime Microsofti probleemist
• 2024-02-08 Google kinnitas probleemi olemasolu
• 2024-03-05 Apple kinnitas, et kavatseb probleemiga tegeleda
• 2024-03-07 Google kinnitas, et probleem lahendatakse
• 2024-03-21 Microsoft ütles, et ei pea seda probleemiks
• 2024-04-05 Google rakendas mõned kaitsemeetmed
• 2024-05-07 Google tegi ettepaneku avalikustada haavatavuse kohta käiva info 17. mail

Autorid ja kontaktid

Seda probleemi märkasid Zone e-posti eksperdid Silver Asu (silver@zone.eu) ja Andris Reinman (andris@zone.eu). Taavi Eomäe (taavi@zone.eu) koordineeris osapoolte vahelist avalikustamist koos CERT-EEga (cert@cert.ee). Täname kõiki, sealhulgas Apple’it ja Google’it, kes meiega probleemi leevendamise juures koostööd tegid.