BGP hijack plus fake TLS certificate hit Softaculous

Një rrëmbim BGP u përdor për të ndihmuar në sulmin ndaj një shitësi softuerësh hostimi. BGP, Protokolli i Portës Kufitare, është sistemi që u lejon rrjeteve në internet t'i tregojnë njëri-tjetrit se cilat blloqe adresash mund të arrijnë. Softaculous Ltd, kompania pas auto-instaluesit Softaculous dhe platformës Virtualizor për menaxhimin e makinave virtuale (versione softuerike të një kompjuteri që ekzekutohen në një server fizik), ka përshkruar se si një sulmues kombinoi një rrëmbim të tillë me një certifikatë TLS teknikisht të vlefshme për të dërguar një paketë të dëmshme përditësimi të Virtualizor në një numër të vogël instalimesh. Kompania i këshilloi klientët të ndjekin një sekuencë hapash për të kontrolluar nëse ishin prekur. Analiza teknike është nga Doug Madory, Shef i Analizës së Internetit në Infoblox, dhe u publikua fillimisht në blogun e Kentik.

Si i mori rrëmbimi adresat

Në orën 20:57 UTC më 28 gusht 2026 një prefiks i ri hyri në tabelën globale të rrugëtimit. Një prefiks është një bllok adresash interneti i shkruar në formë të shkurtuar; ky, 162.55.80.0/24, mbulonte adresat e përdorura nga pika e përditësimit të softuerit të Softaculous si dhe faqja e klientit dhe e faturimit. Ai u shpall përgjatë një rruge AS që lexohej ? 6204 62390 24940. Një rrugë AS është lista e rrjeteve nëpër të cilat kalon një rrugë, e shkruar si numra të quajtur Numra të Sistemit Autonom (ASN). Shpallja ishte një pjesë më specifike e bllokut më të madh 162.55.0.0/16, i cili normalisht origjinohet nga Hetzner Online (AS24940). Rruga me gjasë origjinoi nga rrjeti i parafundit në rrugë, NexonHost (AS62390), ose sepse ai rrjet u komprometua ose sepse një klient shfrytëzoi boshllëqet në sigurinë e tij.

Pse dukej legjitime

Rruga mbante gjithashtu një origjinë të falsifikuar. Duke shtuar 24940 si numrin më të djathtë, sulmuesi e bëri rrugën të dukej e vlefshme sipas RPKI. RPKI, Infrastruktura e Çelësit Publik të Burimeve, është një sistem regjistrash të nënshkruar që deklarojnë se cili rrjet lejohet të shpallë cilat adresa. Rruga kaloi për dy arsye: Autorizimi i Origjinës së Rrugës (ROA, vetë regjistri i nënshkruar) i Hetzner kërkonte AS24940 si origjinë, dhe lejonte që gjatësia e prefiksit të ishte kudo midis /24 dhe /16. Rrjetet që refuzojnë rrugët e pavlefshme sipas RPKI për këtë arsye nuk kishin arsye ta hidhnin atë. Për shkak se nuk ekzistonte asnjë rrugë tjetër për 162.55.80.0/24 për t'u konkurruar me të, shpallja u përhap aq sa lejonin politikat e filtrimit. Routerat gjithmonë preferojnë përputhjen më specifike të disponueshme, kështu që trafiku i destinuar për atë gamë adresash u tërhoq drejt rrugës së rrëmbyer në vend që të ndiqte 162.55.0.0/16 e vërtetë.

Sa zgjati

Vizualizimi BGP i Kentik, i cili tregon pjesën e pikave të vëzhgimit BGP (pika të pavarura vëzhgimi rreth internetit) që kishin 162.55.80.0/24 në tabelat e tyre të rrugëtimit me kalimin e kohës, gjurmon kronologjinë. Nga momenti kur rruga u shfaq për herë të parë në 20:57 UTC më 28 gusht, ajo pulsoi në mënyrë të ndërprerë disa herë derisa AS24940 e vërtetë filloi ta shpallë vetë prefiksin gati 12 orë më vonë, në 08:44 UTC më 29 gusht. Deri në 14:10 UTC të ditës tjetër AS24940 e kishte tërhequr përsëri. Rrëmbimi u kthye në 19:55 UTC më 29 gusht dhe pulsoi në mënyrë të përsëritur derisa AS24940 ndërhyri edhe një herë, duke shpallur 162.55.80.0/24 në 05:45 UTC më 30 gusht, në të cilën pikë rrëmbimi u tërhoq. Në momentin e shkrimit AS24940 ishte ende duke shpallur prefiksin. Grafiku tregon rrugën e rrëmbyer që përhapet pak më pak gjerësisht sesa ajo legjitime, dëshmi se disa filtra rrugësh e kufizuan atë, por përhapja ishte ende e konsiderueshme dhe krijoi potencialin për drejtim të gabuar të trafikut në shkallë të gjerë.

Pse një rrëmbim i vetëm rrugëtimi nuk mjaftonte

Sulmuesi kishte nevojë edhe për një certifikatë TLS të vlefshme. TLS është kriptimi që mbron një lidhje dhe gjithashtu vërteton identitetin e një faqeje interneti. E njëjta dobësi u shfrytëzua në sulmin e vitit 2022 ndaj KLAYswap, një shkëmbim kriptovalutash në internet në Korenë e Jugut. Në postimin e tyre për atë incident, Henry Birge-Lee dhe kolegët e tij në Princeton shkruan se KLAYswap dhe Kakao po përdornin si duhet TLS dhe se asnjë e metë në vetë protokollin TLS nuk u shfrytëzua; në vend të kësaj sulmi abuzoi me besimin e rremë që TLS vendos në infrastrukturën e rrugëtimit. Kundërshtari fillimisht e drejtoi rrëmbimin e tij drejt PKI (infrastruktura e çelësit publik, sistemi i autoriteteve certifikuese që lëshojnë certifikata) dhe kreu një sulm në mes të dy palëve ndaj procesit të shpërndarjes së certifikatave. Vetëm pasi mori një certifikatë dixhitale të vlefshme për domenin e synuar, ai u kthye drejt përdoruesve realë, duke shërbyer një skedar JavaScript të dëmshëm përmes një lidhjeje të kriptuar. Postimi i tyre u titullua "Sulmuesit shfrytëzojnë një të metë themelore në sigurinë e web-it për të vjedhur 2 milionë dollarë në kriptovaluta".

Garancia e identitetit e TLS është vetëm aq e besueshme sa sistemi i rrugëtimit që çon trafikun e vërtetimit të certifikatave në vendin e duhur. Për ta adresuar këtë, autoriteti publik i certifikatave Let's Encrypt ka përdorur Korroborimin e Lëshimit me Shumë Perspektiva (MPIC) për disa vjet. Sipas MPIC, një autoritet certifikues nuk e vërteton kontrollin e një domeni nga një pikë e vetme vëzhgimi, të cilën një rrëmbim BGP i lokalizuar mund ta mashtrojë. Ai kontrollon nga disa vende rrjeti gjeografikisht dhe topologjikisht të ndryshme në të njëjtën kohë dhe kërkon që një kuorum të bjerë dakord përpara se të lëshohet një certifikatë, kështu që një rrëmbim që arrin vetëm disa pika vëzhgimi kapet nga mospajtimi midis të tjerave. Në këtë rast, për shkak se rruga e rrëmbyer ishte një rrugë më specifike e pakundërshtuar, përhapja e saj globale krijoi një kuorum tërësisht të kontrolluar nga sulmuesi.

Çfarë treguan incidentet e mëparshme

Në vitin 2022 një rrëmbim BGP synoi gjithashtu Celer Bridge, një shërbim kriptovalutash i hostuar nga AWS. Në postimin që Madory shkroi në atë kohë, ai përmendi praktikën e atëhershme të AWS për të përdorur ROA shumë liberale, të cilat lejonin origjina të shumta dhe prefikse me madhësi nga një /10 deri në një /24, si një faktor që kufizonte aftësinë e Vërtetimit të Origjinës së Rrugës RPKI për të ndihmuar. Ai sugjeroi një alternativë: bëni atë që kanë bërë rrjete si Cloudflare dhe Comcast dhe vendosni origjinën dhe gjatësinë maksimale të prefiksit që të përputhen saktësisht me mënyrën se si rrugëtohet prefiksi. Kjo qasje kushton ngarkesën e përditësimit të një ROA sa herë që ndryshon një rrugë, por lë pak hapësirë për versione alternative të një rruge që qarkullojnë. AWS tani bën përputhje të sakta në ROA-t e tij.

Madory është i kujdesshëm të mos e mbivlerësojë Vërtetimin e Origjinës së Rrugës RPKI (ROV), praktikën e kontrollit të rrugëve kundrejt regjistrave të nënshkruar, si një mbrojtje kundër një kundërshtari të vendosur. Sulmuesit mund të falsifikojnë rrugët AS për t'i bërë rrëmbimet të vlefshme sipas RPKI. Edhe kështu, nëse Hetzner Online do të kishte përdorur ROA strikte me gjatësi maksimale të prefiksit që përputheshin me rrugët e tij, qarkullimi i rrëmbimit do të ishte zvogëluar shumë, gjë që nga ana tjetër do të kishte lejuar MPIC të parandalonte lëshimin e një certifikate TLS të vlefshme.

Zbulimi gjithashtu do të kishte qenë i mundur. Ashtu si me sulmin ndaj Celer Bridge, monitorimi BGP mund të kishte alarmuar Hetzner se një /24 i ri i hapësirës së tij të adresave po shpallej, edhe pse origjina e falsifikuar mund ta kishte bërë atë të dukej legjitime. Kur ai /24 i ri u shfaq me një furnizues të papritur, NexonHost (AS62390), një alarm duhet të kishte tërhequr vëmendjen ndaj anomalisë. Detaji që do ta kishte dalluar atë nga shfaqja e thjesht një partneri tjetër të Hetzner Online është se furnizuesi i ri u pa nga shumica dërrmuese e pikave të vëzhgimit BGP: prefiksi po transitohej ekskluzivisht nga ky ofrues hostimi relativisht i panjohur.

Çfarë duhet të nxjerrë industria

RPKI ROV ka reduktuar ndjeshëm incidentet e rrugëtimit, por nuk është projektuar për të parandaluar plotësisht një incident si ky. Ai funksionon duke reduktuar përhapjen e origjinimeve të gabuara të rrjedhura, të cilat zakonisht përfshijnë gabime të pafajshme, dhe përfitimet e tij janë parë gjithashtu në rrëmbimet e ashtuquajtura "të qëllimshme, por edhe aksidentale", si bllokimi i Telegram në Indi në qershor. ROA më strikte mund të kishin lejuar RPKI ROV të kufizonte rrugën e rrëmbyer mjaftueshëm që MPIC të bllokonte certifikatën.

Sulmet ndaj infrastrukturës si këto nxjerrin në pah probleme që nuk kufizohen vetëm te kriptovalutat ose softueri i hostimit. Kompanitë që sigurojnë infrastrukturën e tyre të ekspozuar ndaj internetit duhet të vendosin monitorim të fortë BGP dhe DNS, duke vëzhguar si sistemet e tyre ashtu edhe çdo varësi të bazuar në internet nga e cila varen. Ata duhet të refuzojnë rrugët e pavlefshme sipas RPKI dhe të krijojnë ROA strikte për hapësirën e tyre të adresave, me gjatësi maksimale të prefiksit që përputhen me gjatësitë e prefiksit që përdorin në të vërtetë rrugët e tyre. RFC 9319, Përdorimi i MaxLength në Infrastrukturën e Çelësit Publik të Burimeve, deklaron se është një praktikë aktuale më e mirë që rrjetet të shmangin plotësisht atributin maxLength në ROA, përveç në rrethana të caktuara; lënia e fushës maxLength bosh ka të njëjtin efekt si vendosja e saj për t'u përputhur me prefiksin. Këto hapa reduktojnë ndjeshëm dritaren e mundësisë për një sulmues.

Në një përditësim pas publikimit të postimit të tij, Madory vuri në dukje se Hetzner ndryshoi ROA-n për 162.55.0.0/16 për të përfshirë një maxLength prej 16, duke hequr mundësinë e një sulmi të ngjashëm me nën-prefiks në të ardhmen. Hetzner bëri të njëjtën gjë për ROA-t që mbulojnë 213.133.96.0/19 dhe 213.239.192.0/18, të cilat më parë lejonin një maxLength prej 24 dhe tani lejojnë përkatësisht 19 dhe 18. Edhe pas atyre tre rregullimeve, 50 nga ROA-t e AS24940 ende tregonin të njëjtin model: 78.46.0.0/15 rrugëtohet si një /15 por ROA e tij lejon deri në /24, një hendek prej 9, dhe shumica e blloqeve /16 në mënyrë të ngjashme lejojnë /24 kur vetëm /16 rrugëtohet. Shtrëngimi është pra i pjesshëm, dhe i njëjti problem maxLength vazhdon në pjesën më të madhe të hapësirës së adresave të rrjetit. Veçmas, Bryton Herdes nga Cloudflare vuri në dukje se Hetzner shtoi një regjistrim ASPA, një listë të nënshkruar që numëron cilat rrjete janë të autorizuara të mbajnë trafik për AS24940. Me atë regjistrim në vend, rrjetet që kontrollojnë ASPA duhet të jenë në gjendje të refuzojnë menjëherë rrugët, rruga AS e të cilave përfshin një furnizues të AS24940 që nuk është në listë, si AS62390 në këtë incident.

Për pronarët e faqeve të internetit, mësimi është se rruga që ndjek trafiku juaj dhe kërkimet e emrave nga të cilat varen stafi dhe vizitorët tuaj ia vlen t'i vëzhgoni të dyja. Askush nuk mund të zhbëjë një rrëmbim rrugëtimi nga ana e klientit, por mbajtja e zgjidhjes DNS private dhe të kriptuar, siç bën një shërbim si AEU DNS, ndalon që kërkimet e emrave të vëzhgohen ose ndryshohen në heshtje gjatë rrugës drejt zgjidhësit, që është pjesa e këtij zinxhiri që një pronar faqeje mund të kontrollojë në të vërtetë.