BIMI un DMARC jūs neglābs: nepamanītais DKIM ievainojamības izmantojums

Zone.eu analītiķi, viens no vadošajiem domēnu reģistratoriem un tīmekļa mitināšanas pakalpojumu sniedzējiem Eiropā, ir novērojuši ievainojamību, kas ietekmē globālo e-pasta ekosistēmu, izrietot no neievērotiem brīdinājumiem DomainKeys Identified Mail (DKIM) standartā, kas apdraud miljardiem lietotāju.

Šī nav konkrētas programmatūras produkta problēma, bet gan ievainojamība, kas rodas no vaļīgām standarta interpretācijām daudzās implementācijās, kas aptver plašo e-pasta ekosistēmu.

Izmantojot šo ievainojamību, uzbrucēji var izveidot viltotus e-pastus, kas joprojām iztur DKIM kriptogrāfiskās pārbaudes un kurus pēc tam var viegli atkārtoti nosūtīt, lai sasniegtu paredzēto upuri. Šie viltotie e-pasti, visticamāk, izturēs arī DMARC (Domain-based Message Authentication Reporting and Conformance) politikas. Daudz organizāciju visā pasaulē sagaida, ka DMARC novērsīs noteiktus pikšķerēšanas uzbrukumu veidus gan pret sevi, gan saviem saņēmējiem.

Šīs problēmas nopietnība ir ievērojami pieaugusi līdz ar BIMI (Brand Indicators for Message Identification) parādīšanos. BIMI paļaujas uz DMARC, lai pārbaudītu ziņojumu autentiskumu. Rezultātā, ja ziņojums iztur visas šīs pārbaudes, daži e-pasta pakalpojumi, piemēram, Apple Mail un Gmail, blakus viltotam e-pastam parādīs zīmola logotipu. Lietotājiem saskarnē tiek norādīts uzticēties ar BIMI apzīmētajiem e-pastiem, padarot šīs modificētās vēstules īpaši likumīgas un uzticamas.

BIMI Gmail un Apple Mail:

Mēs esam apstiprinājuši, ka šie uzbrukumi ir izmantojami praksē, modificējot DKIM parakstītus e-pasta ziņojumus, ko sūta vairāki Fortune 500 uzņēmumi (un citi), kuriem e-pasta integritāte ir būtiska. Viltotie e-pasti bez grūtībām nonāca upuru iesūtnēs līdz nesenam laikam. Tomēr, ņemot vērā ekosistēmas lielumu, šī vājība saglabāsies vēl kādu laiku.

Šīs problēmas nozīme ir jāatzīst pat tad, ja sūtītājs vai saņēmējs nav ieviesis BIMI. Tā ir DKIM problēma, jo šie viltojumi iztur DKIM un DMARC. Ja pikšķerēšanas kampaņas izmantos šo ievainojamību, tas var izraisīt globālu risku pieaugumu akreditācijas datu un datu zādzībām. DKIM ieviešanas nostiprināšana pret šādiem uzbrukumiem ir kritiski svarīga.

Tehniskais kopsavilkums

DKIM standarts (RFC 6376) nosaka parametru e-pasta ķermeņa garuma definēšanai (“l=”); šī atzīme informē e-pasta ziņojuma pārbaudītāju par saņemtā e-pasta ķermeņa oktetu skaitu.

Risks, kas saistīts ar ķermeņa garuma ierobežojuma (“l=” atzīme) izmantošanu, ir zināms vismaz kopš DKIM standarta publicēšanas (skat. RFC 6376 8.2. sadaļa), taču aprakstītie drošības apsvērumi ir nepilnīgi, jo tie aplūko “l=” atzīmi izolēti. Mūsu pieeja ir atrast vēstules ar parakstiem, kuros ir “l=” atzīme, un tad vai nu modificēt esošo Content-Type galveni, vai pievienot jaunu, lai aizstātu attēloto saturu.

Mūsu testos daudzi sūtītāji, kas izmanto “l=” atzīmi, neparaksta Content-Type galveni, ļaujot uzbrucējam to aizstāt ar īpaši sagatavotu vērtību, nesabojājot parakstu. Diemžēl pat ja galvene ir parakstīta, tā parasti nav parakstīta divreiz, lai aizsargātu pret papildu (neparakstītas) Content-Type galvenes pievienošanu vēstulei. Kā apstrādāt vairākas Content-Type galvenes vienā e-pasta ziņojumā nav skaidri definēts, tāpēc implementācijas un izrietošie riski atšķiras.

Mūsu pieeja šīs vājības izmantošanai ir aizstāt robežvērtību Content-Type galvenē MIME multipart e-pastos un pievienot jaunu MIME struktūru ar modificēto robežvērtību e-pasta beigās. Šāda modifikācija esošo MIME struktūru padara par neredzamu komentāru un piespiež e-pasta klientu izmantot pievienoto struktūru kā “īstā” e-pasta saturu. Tas rada lielāku ietekmi un atšķiras no iepriekš aprakstītajām pieejām.

Vienkāršots aprakstītā uzbrukuma attēlojums:

Oriģinālais e-pasta saturs (ar anotācijām):

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

<<<Multipart Comment start
This is a multi-part message
>>>Multipart Comment end

--abc
Message MIME structure
--abc--[1234 byte cutoff]Code language: JavaScript (javascript)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=domain.com; 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 Comment start]
This is a multi-part message

--abc
Message MIME structure
[Multipart Comment end]
--abc--[1234 byte cutoff]

Faked message MIME structure

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

Jāatzīmē, ka pirmā rinda šajā viltotajā MIME struktūrā joprojām ir parakstīta, kas apiet vienkāršas pārbaudes pret neparakstīta satura attēlošanu. Šāds e-pasts, protams, joprojām iztur paraksta pārbaudi, bet klients izmanto pievienoto MIME struktūru kā e-pasta saturu, pilnībā ignorējot oriģinālo saturu.

Ja Content-Type galvene ir DKIM paraksta daļa, papildu Content-Type pievienošana joprojām ļauj ievainojamību daudziem e-pasta klientiem.

Mainītais e-pasta saturs:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=domain.com; 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" <-- prepended boundary
Content-Type: multipart/mixed; boundary="abc"Code language: JavaScript (javascript)

Paraksta pārbaude iziet, jo tikai apakšējā Content-Type vērtība tiks iekļauta parakstā. Tomēr e-pasta klients, iespējams, izmantos augšējo vērtību, parsējot MIME struktūru, padarot uzbrukumu iespējamu.

Lai to novērstu, Content-Type galvene jāaizsargā parakstā (jāiekļauj divreiz “h=” atzīmē)

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

Šādā gadījumā jebkura papildu Content-Type galvene, kas pievienota ziņojumam, anulēs DKIM parakstu. Tas padara parakstu trauslāku, bet, ja tiek izmantota “l=” atzīme, tas ir labāk nekā alternatīvas.

Saistītās problēmas

Šī nav pirmā reize, kad kāds pievērš uzmanību šādām problēmām, taču situācija ir kļuvusi ievērojami nopietnāka. Līdzīgi uzbrukumi iepriekš aprakstīti Stephen Ullrich (“Breaking DKIM – on Purpose and by Chance”) un Valimail komandai (“DKIM Fallacies: Debunking Rumors of DKIM’s Vulnerabilities”). Šo problēmu, iespējams, var apvienot arī ar citiem “reskin” uzbrukumiem, piemēram, Kobold letters, padarot šādu maināmību vēl bīstamāku.

Ar DKIM parakstiem saistītās problēmas ar to nebeidzas. Esam novērojuši sūtītājus, kas paraksta tikai pirmo baitu ķermenī ar “l=1” (piemēram, Maropost), kas pats par sevi ir bīstami. Tas ir vēl viens iemesls, kāpēc DKIM vērtētājiem vajadzētu ignorēt parakstus ar “l=” atzīmi.

Vecākā maināmā vēstule, ko esam atraduši (un kurai joprojām ir publicēta atbilstošā publiskā atslēga), ir no 2014. gada un to sūtījis Microsoft; papildus “l=” atzīmei tā izmanto arī SHA1. Atslēgas, kas izmantotas RSA-SHA1 parakstiem, būtu jāiznīcina un atbilstošās publiskās atslēgas jāizņem no DNS. Tas vēl vairāk izceļ problēmas ar ļoti ilgi izmantotu atslēgu materiālu.

Diemžēl tā nav vienīgā problēma ar vecu atslēgu materiālu. Daudzi sūtītāji joprojām izmanto slikti ģenerētas vai vājas 512 bitu RSA atslēgas. Kā apraksta Hanno Böck (“16 years of CVE-2008-0166 – Debian OpenSSL Bug”), 0,24% no Tranco Top 1 Million saraksta joprojām ir publicētas vājas Debian atslēgas, kas ir ļoti bīstami.

Praktiski piemēri un ietekme

Analizējot mūsu e-pasta trafiku, esam atraduši vairākus ievērojamus piemērus, piemēram, 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, radissonhotels.com, kas visi ir sūtījuši maināmas vēstules. Mēs uzskatām, ka tie ir vērtīgi mērķi viltojumu izveidei.

Līdz šim esam novērojuši miljoniem DKIM parakstu ar garuma atzīmi, no 3040 dažādām domēniem, no kuriem 32 iztur BIMI pārbaudes un tiem ir derīgs VMC. Tas ir pretrunā ar Valimail apgalvojumu, ka “gandrīz neviens sūtītājs šodien neizmanto šo atribūtu.”

Mainītas DHL vēstules (ekrānuzņēmumi no Gmail):

Ierobežošana

Atslēga šīs ievainojamības novēršanai un uzbrukumu izvairīšanai jau ir norādīta DKIM standarta sadaļā “Drošības apsvērumi”: 8.2. Ķermeņa garuma ierobežojumu ļaunprātīga izmantošana (“l=” atzīme).

Citējam: “Lai izvairītos no šī uzbrukuma, parakstītājiem jābūt ārkārtīgi piesardzīgiem, izmantojot šo atzīmi, un vērtētājiem varētu būt vēlme ignorēt parakstus, kas izmanto šo atzīmi.” Šis ieteikums jāinterpretē stingri, noteikti stingrāk nekā pašreizējais formulējums. Sākotnēji vismaz BIMI kontekstā, bet ideālā gadījumā to vajadzētu pilnībā ignorēt.

Tajā pašā laikā vērtētājiem šobrīd vajadzētu sākt noraidīt vēstules ar veciem DKIM parakstiem, lai mazinātu vecu parakstu ļaunprātīgu izmantošanu, vai tas būtu šis uzbrukums vai līdzīgi. Tomēr tam vajadzētu būt pagaidu risinājumam, līdz garuma atzīme un vāji paraksti (SHA1-RSA vai ≤1024 bitu atslēgas) var tikt pilnībā izslēgti un ignorēti.

E-pasta sūtītājiem, īpaši tiem, kas izmantojuši “l=” atzīmi, periodiski jāmaina savas DKIM atslēgas. Ja tas netiek darīts, vecos e-pastus ar “l=” atzīmi joprojām var izmantot jaunu viltojumu izveidei. Ir vēl vairāki iemesli, kāpēc DKIM atslēgas būtu jāmaina, ne tikai šīs ievainojamības dēļ.

Laika līnija

• 2024-01-26 – Apple un Google tika informēti par problēmu
• 2024-01-31 – CERT-EE tika informēts par problēmu
• 2024-02-02 – Microsoft tika informēts par problēmu
• 2024-02-08 – Google apstiprināja problēmas esamību
• 2024-03-05 – Apple apstiprināja, ka plāno risināt šo jautājumu
• 2024-03-07 – Google apstiprināja, ka problēma tiks novērsta
• 2024-03-21 – Microsoft neuzskata to par problēmu
• 2024-04-05 – Google, šķiet, ir ieviesis risinājumus šai problēmai
• 2024-05-07 – Google ierosina publisku atklāšanu 17. maijā

Pateicības & kontakti

Šo problēmu novēroja Zone.eu analītiķi Silver Asu (silver@www.zone.lv) un Andris Reinman (andris@www.zone.lv). Taavi Eomäe (taavi@www.zone.lv) koordinēja atklāšanu starp pusēm kopā ar CERT-EE (cert@cert.ee). Pateicamies visiem, tostarp Apple un Google, kas sadarbojās ar mums šīs problēmas mazināšanā.