Anashkalim i administratorit SAML SSO miniOrange prek gjashtë edicione me pagesë

Dy të meta kritike të anashkalimit të autentifikimit në shtojcën miniOrange SAML 2.0 Single Sign On u lejojnë sulmuesve të paautentikuar të falsifikojnë deklarata SAML dhe të hyjnë në WordPress si çdo përdorues ekzistues, përfshirë administratorët. Hulumtimi u raportua nga ekipi i sigurisë i DigitalOcean, me analizë të shkakut rrënjësor nga DigitalOcean dhe mbulim dhe ndjekje nga shitësi në bashkëpunim me Patchstack. Të dy dobësitë kanë një rezultat serioziteti CVSS prej 9.8 dhe u zbuluan publikisht në korrik 2026. Megjithëse të dyja janë rregulluar nga shitësi, një grup i madh faqesh dhe shumë klientë ndërmarrjesh nuk kishin asnjë mënyrë për të ditur se ishin të prekur, nuk shihnin asnjë përditësim në pritje në panelin e WordPress-it dhe nuk ishin të mbuluar nga asnjë bazë të dhënash dobësish.

E meta e parë, CVE-2026-61979, është një çështje konfuzioni i algoritmit të nënshkrimit. Shtojca normalisht verifikon një përgjigje SAML duke përdorur një çelës publik RSA të besuar nga ofruesi i identitetit (IdP). Por shtojca i lejon përgjigjes SAML hyrëse të zgjedhë algoritmin e saj të nënshkrimit. Një sulmues mund të vendosë SignatureMethod në HMAC-SHA1, dhe shtojca pastaj përdor PEM-in e çelësit publik RSA si sekret HMAC. Sepse ai çelës publik është publik nga përkufizimi, sulmuesi mund ta marrë atë nga pika e fundit e metadatave të IdP-së, ta përdorë si sekret HMAC, të nënshkruajë një deklaratë të falsifikuar dhe shtojca do ta pranojë si të vërtetë. Analiza e shkakut rrënjësor, e kryer kundër edicionit Standard 16.1.9, tregon rreshtat 246-250 të Utilities.php, të cilat lexojnë algoritmin e zgjedhur nga sulmuesi dhe riciklojnë çelësin RSA, dhe rreshtat 308-314 dhe 546-548 të XMLSecurityKey.php, të cilat lënë materialin e çelësit PEM si bajt të papërpunuar dhe pastaj e kalojnë direkt në hash_hmac(). miniOrange e rregulloi këtë në edicionin Standard 17.0.5.

E meta e dytë, CVE-2026-15981, vjen nga një kontroll i lirë i rezultatit të verifikimit OpenSSL. Funksioni openssl_verify() kthen 1 për një nënshkrim të vlefshëm, 0 për një nënshkrim të pavlefshëm dhe -1 kur OpenSSL vetë ndesh një gabim të brendshëm. Shtojca e kontrolloi rezultatin si boolean, dhe në PHP vlera -1 është e vërtetë, kështu që një nënshkrim i keqformuar që shkakton një rrugë gabimi OpenSSL u pranua si i vlefshëm. Rrugët përkatëse të kodit janë rreshtat 486-494 të XMLSecurityKey.php, të cilat kthejnë rezultatin e papërpunuar tre-gjendësh, dhe rreshti 252 i Utilities.php, i cili e vlerëson atë si boolean. miniOrange e rregulloi këtë në edicionin Standard 17.0.6. Një çështje e tretë, e veçantë, u zbulua pak pas këtyre rregullimeve, por kërkon që një administrator të klikojë diçka, kështu që qëndron nën dy të parat në seriozitet praktik.

Shtojca shpërndahet nën një pseudonim të vetëm WordPress, miniorange-saml-20-single-sign-on, por ai listim i vetëm përmban në heshtje shtatë edicione produkti të versionuara veçmas. Këshillat publike mbuluan vetëm edicionin falas. Shitësi dha këtë ndarje. Falas (një faqe): versioni i parë 3.0.0, më i fundit 5.4.7, i prekshëm deri në 5.4.4, i rregulluar në 5.4.5. Premium (një faqe): versioni i parë 11.3.0, më i fundit 13.1.0, i prekshëm deri në 13.0.3, i rregulluar në 13.0.4. Standard (një faqe): versioni i parë 15.1.0, më i fundit 17.1.0, i prekshëm deri në 17.0.5, i rregulluar në 17.0.6. Premium/Enterprise/All-Inclusive (shumëfaqësh): versioni i parë 20.0.0, më i fundit 20.2.8, i prekshëm deri në 20.2.7, i rregulluar në 20.2.8. Enterprise/All-Inclusive (një faqe): versioni i parë 25.0.0, më i fundit 26.1.0, i prekshëm deri në 26.0.2, i rregulluar në 26.0.3. VIP (një faqe): versioni i parë 32.0.0, më i fundit 32.0.8, i prekshëm deri në 32.0.7, i rregulluar në 32.0.8. VIP (shumëfaqësh): versioni i parë 35.0.0, më i fundit 35.0.7, i prekshëm deri në 35.0.6, i rregulluar në 35.0.7. Për të kontrolluar faqen tuaj, gjeni edicionin tuaj dhe krahasoni versionin tuaj me kolonat e prekshme dhe të rregulluara.

Kjo skemë versionimi është arsyeja pse asnjë bazë e dhënash publike dobësish nuk i kapi këto anashkalime autentifikimi. Një regjistrim tipik dobësie supozon se të gjitha versionet nën një pseudonim ngjiten së bashku në një linjë. Këtu, ato ngjiten në shtatë breza të veçantë. I vetmi këshillë publike kishte të bënte me edicionin falas, i cili u rregullua në 5.4.5. Çdo instalim me pagesë ka një numër versioni më të lartë se ai, kështu që raportohet si i rregulluar tashmë. Zgjerimi i gamës së prekur nuk ndihmon as, sepse faqet e edicionit falas në 5.4.5 ose më vonë do të etiketoheshin gabimisht si të prekshme. Rregullimi i saktë është të regjistrohen shtatë vargje të shkëputura të prekura në të njëjtin pseudonim, gjë që regjistrimi i bazës së të dhënave tani mban. Pjesa që mungonte gjatë gjithë kohës ishte tabela e shitësit, e cila nuk ishte publikuar askund deri në këtë artikull.

Historia e rregullimit bëhet edhe më e keqe. Nëse jeni duke përdorur edicionin Standard 16.1.9, paneli juaj i administratorit WordPress nuk tregon asnjë përditësim në dispozicion, edhe pse 17.0.6 ekziston në të njëjtën linjë Standard për të cilën tashmë keni licencë. Rruga e përmirësimit nga një 16.x e prekshme në një 17.x të rregulluar është një ngarkim manual i shtojcës, sepse mekanizmi tipik i përditësimit WordPress nuk ofron një kërcim ndër-linje. DigitalOcean konfirmoi të dy gabimet në 16.1.9, një version Standard nga mesi i asaj linje, dhe rregullimi është 17.0.6. Nuk ka asnjë patch 16.x në pritje.

DigitalOcean e gjeti çështjen përmes mbrojtjes në thellësi. Nuk kishte asnjë këshillë për të lexuar, asnjë hyrje në bazën e të dhënave nuk shënonte edicionin me pagesë, dhe shtojca raportonte veten si plotësisht të përditësuar. Një përpjekje anormale për sesion administratori WordPress nga jashtë rrjetit të tyre të besuar u bllokua. Sulmuesi kishte përdorur tashmë anashkalimin për të marrë një cookie sesioni administratori WordPress, por operacionet e panelit të administratorit ishin të kufizuara pas rrjetit të besuar. Nga atje, DigitalOcean riprodhoi anashkalimin nga fillimi në fund në versionin 16.1.9, gjurmoi të dy gabimet në shkaqet e tyre rrënjësore, përcaktoi se cilat versione me pagesë ishin të prekura, shkroi hotfix-et dhe ndau analizën për përfitim publik. Aktiviteti i skanimit kundër pikave fundore SSO të miniOrange është vëzhguar nga adresat IP të mëposhtme: 207.211.214.41 (Bruksel, Belgjikë, VPN/qendër të dhënash), 79.127.224.14 (Bruksel, Belgjikë, VPN/qendër të dhënash), 102.91.71.83 (Abuja, Nigeri, operator celular), 162.243.116.148 (Secaucus, SHBA, cloud/VPS), 84.201.6.54 (Frankfurt, Gjermani, hosting/qendër të dhënash), dhe 64.225.25.188 (Clifton, SHBA, cloud/VPS). Përhapja sugjeron skanim oportunist sesa një fushatë e synuar. Sulmuesi nuk ka nevojë të dijë se cilin edicion përdorni; ju e dini.

Për të mbrojtur faqen tuaj WordPress, përditësoni shtojcën në versionin në kolonën e rregulluar për edicionin tuaj, të paktën, dhe prisni ta bëni këtë me ngarkim manual. Nëse nuk mund të përditësoni menjëherë, DigitalOcean ofron dy hotfix-e të ngushta. Për konfuzionin e algoritmit, shtoni këtë menjëherë pas rreshtit 246 në Utilities.php: if ( XMLSecurityKey::HMAC_SHA1 === $MG ) { printf( 'HMAC SAML signatures are not supported.' ); exit; }. Për çështjen tri-gjendëshe OpenSSL, zëvendësoni return në includes/lib/SAML2Core/XMLSecurityKey.php:494 me: return openssl_verify( $ql, $hl, $this->key, $MG ) === 1;. Të dy hotfix-et janë qëllimisht të ngushtë dhe kanë për qëllim të fitojnë kohë, jo të zëvendësojnë rregullimin e shitësit. Një rregullim gjithëpërfshirës ka nevojë për një listë të lejuar RSA për algoritmet e nënshkrimit, heqjen e rrugës së riciklimit të çelësit publik, një bllok të fortë për çelësat asimetrikë që hyjnë në degët HMAC, dhe forcimin e bibliotekës së sigurisë XML të përfshirë. Gjithashtu kontrolloni regjistrat tuaj për sesione administratori të autentikuara nga IP jashtë vargjeve tuaja të pritshme. Ai sinjal nuk varet nga njohja e versionit të shtojcës tuaj.

Mësimi më i gjerë është se bazat e të dhënave të dobësive janë aq të mira sa të dhënat e versioneve që shitësit publikojnë publikisht. Kur një shitës drejton shtatë edicione të numëruara në mënyrë të pavarur nën një pseudonim dhe rregullon gjashtë prej tyre pa një këshillë publike, i gjithë ekosistemi në rrjedhën e poshtme verbohet menjëherë: bazat e të dhënave, skanerët, panelet dhe administratorët e faqeve që mbështeten në të tre. Patch-i virtual ishte i ndryshëm: një rregull i murit të zjarrit që bllokon modelin e shfrytëzimit nuk kujdeset se cilin edicion përdorni, kështu që mbrojtja mund të mbulonte të shtatë edicionet në të njëjtën kohë. Alarmimi i saktë nuk mund të bënte të njëjtën gjë; ai funksionon vetëm nëse di saktësisht se çfarë keni instaluar. Në këtë rast, mbrojtja u shkallëzua mirë, por raportimi u prish. Për organizatat që mbështeten në WordPress, një shërbim hosting i menaxhuar si AEU Hosting mund të shtojë një shtresë tjetër që vëzhgon hyrjet e pazakonta të administratorit dhe bllokon modelet e njohura të shfrytëzimit, edhe kur furnizimi i përditësimeve të një shtojce ju mashtron.

Merita i takon ekipit të sigurisë DigitalOcean për të gjithë hulumtimin origjinal. Ata zbuluan dhe bllokuan aktivitetin kundër infrastrukturës së tyre, konfirmuan dhe riprodhuan anashkalimin në edicionin Standard 16.1.9, prodhuan analizën e plotë të shkakut rrënjësor për të dy CVE-të në edicionet me pagesë, identifikuan versionet e rregulluara 17.0.5 dhe 17.0.6 që shitësi dërgoi pa një hyrje publike në regjistrin e ndryshimeve ose këshillë, shkruan dhe vërtetuan hotfix-et dhe ndanë treguesit e komprometimit.