Ezen a héten a biztonságban: Git Deep Dive, Mailchimp és SPF

Ezen a héten a biztonságban: Git Deep Dive, Mailchimp és SPF

Időbélyeg: 20. január 2023. 10:00
Forrás csomópont: 1910203

Először is, a git auditálásra került. Ezt az Open Source Technology Improvement Fund (OSTIF) nevű nonprofit szervezet támogatta, amely a nyílt forráskódú projektek biztonságának javításán dolgozik. Magát az auditot az X41 és a GitLab kutatói végezték, ill két kritikus biztonsági rést találtak, mindkettőt ugyanaz a rossz kódolási szokás okozza – egy int pufferhosszak megtartására.

A modern rendszereken a size_t mindig előjel nélküli, és ugyanolyan bithosszúságú, mint az architektúra bitszélessége. Ez a megfelelő adattípus a karakterlánc- és pufferhosszúságokhoz, mivel garantáltan nem csordul túl a rendszer maximális címezhető memóriájáig terjedő hosszúságok kezelésekor. Másrészt egy int általában négy bájt hosszú és előjeles, maximális értéke 2^31-1 vagy 2147483647 – körülbelül 2 GB. Nagy puffer, de nem hallatlan mennyiségű adat. Dobj valami nagyot a git-re, és váratlan módon eltörik.

Az első példánk a CVE-2022-23521, egy határon túli írás, amelyet egy int túlcsorduló negatív. A .gitattributes fájl véglegesíthető egy lerakatban egy módosított git klienssel, majd ennek a tárolónak az ellenőrzése a num_attrs változó a túlcsorduláshoz. Tolja a túlcsordulást egészen egy kis negatív számig, és a git ekkor jelentősen alulfoglalja az attribútumpuffert, és az összes adatot a lefoglalt puffer végére írja.

A CVE-2022-41903 egy másik előjeles egész túlcsordulás, ezúttal akkor, amikor egy csinos nyomtatási formátumot visszaélnek valami váratlan művelethez. Vessen egy pillantást erre a kódblokkra:

 int sb_len = sb->len, offset = 0; if (c->flush_type == flush_left) offset = padding - len; else if (c->flush_type == flush_both) offset = (padding - len) / 2; /* * we calculate padding in columns, now * convert it back to chars */ padding = padding - len + local_sb.len; strbuf_addchars(sb, ' ', padding); memcpy(sb->buf + sb_len + offset, local_sb.buf, local_sb.len);

Az exploit formátum valahogy így nézne ki %>(2147483647)%a%>(2147483646)%x41, ahol a fenti kód minden kitöltési példánynál lefut (A %>(#) blokkok) található a formátumban. A kód első alkalommal (2^31)-1 szóközt ad a kimeneti karakterlánc elejéhez. Ez a szám véletlenül egy négy bájtos előjelű egész szám maximális értéke. De a fenti kódblokk máskor is lefut, és egyszer újabb szöveg kerül a pufferbe, és a hossza meghaladja a maximális egész értéket. A blokk első sora implicit leadást végez size_t nak nek int, beállítás sb_len negatív értékre.

Aztán a memcpy() hívás, sb->buf a puffer elejére mutató mutató, az sb_len a túlcsordult nagy negatív számunk, az offset pedig egy felhasználó által szabályozott érték. Ez a címzett cél helyét jelenti memcpy() akaratlanul is alacsonyabb memóriahelyre állítható, mint a tervezett puffer kezdete. Támadó irányított ír. Hozzáadtam néhány hibakereső printf() utasítást ehhez a szövegblokkhoz, és lefuttattam egy tesztesetet:

$ ./bin-wrappers/git log -1 --pretty="format:%>(2147483647)%a%>(2147483635)%s" >/dev/null
Padding: 2147483647
sb_len: 0
offset: 2147483647
Memcpy: Padding: 2147483635
sb_len: -2147483647
offset: 2147483591
Memcpy: CI: upgrade to macos-12, and pin OSX version
=================================================================
==844038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd8989f97c8 at pc 0x7fdb15e49d21 bp 0x7ffe8fa5c100 sp 0x7ffe8fa5b8b0
WRITE of size 44 at 0x7fd8989f97c8 thread T0
0x7fd8989f97c8 is located 56 bytes to the left of 4831838268-byte region [0x7fd8989f9800,0x7fd9b89f983c)

A kimenetek első kvartettje a setup, a naplósor alapozása párnázással, hogy max int hosszú legyen. A második kvartett a puffertúllépés, ahol sb_len negatívra van állítva, majd hozzáadjuk az eltoláshoz, hogy a puffer kezdetétől balra 56 bájttal kapjunk helyet. Ebben az esetben az adott helyre nyomtatott tartalom az %s, amelyet a véglegesítés tárgysora vált fel – 44 bájt hosszú. A szerzők azt sugallják, hogy ez felfegyverkezhető egy „git kovácsolással”, AKA GitHubbal és GitLabbal, mivel ezek a szoftvercsomagok a git archiválás parancsot futtatják, amely egy felhasználó által vezérelt szép karakterláncot hívhat meg.

A javításokat még december 8-án betolták a git forráskódba, de csak most érhetők el az ezeket a javításokat tartalmazó új kiadások. A nyersanyagnak körülbelül 2200 példánya van int probléma, és ezek eltakarítása eltart egy ideig, még néhány szórakoztató hack mellett is cast_size_t_to_int(), egy soron belüli függvény, amely csak megöli a programot, ha egy 2 GB+ size_t kezelik. Szóval frissíts!

Mailchimp – Újra

Úgy tűnik, a Mailchimp munkatársai nem tudnak pihenni belső adminisztrációs eszközeikhez ismét hozzáfértek a támadók, ami 133 ügyfélfiók, köztük a WooCommerce megjelenéséhez vezetett. Ez a harmadik alkalom, hogy a Mailchimp egy social engineering vagy adathalász támadásba esik az elmúlt évben, és minden alkalommal adathalász e-maileket küldtek a végfelhasználóknak. Tehát ha a Mailchimp levelezőlistáján szerepel, tartsa szem előtt ezt a szabálysértést, amikor legközelebb kapcsolódó e-mail érkezik. (A szerkesztő megjegyzése: Hackaday két hírlevele a Mailchimpet használja, és nem kaptunk értesítést, ezért úgy gondoljuk, hogy jók vagyunk.)

Royal Mail Ransomware

Egy olyan történetben, amelynek nagy következményei lehetnek, a A brit Royal Mail zsarolóvírus-támadást szenvedett el nemzetközi levelek kezelésére szolgáló rendszerükön. A támadás Lockbit ransomware-t használ, egy olyan csoportot, amelyről feltételezik, hogy egy oroszul beszélő ransomware banda. Ez jelentős lehet, mivel egy tényleges kormányhivatal elleni támadás sokkal súlyosabb, mint egy vállalkozás elleni támadás. Mivel a Lockbit ransomware-ként-szolgáltatásként fut, nagyon nehéz lesz pontosan meghatározni, hogy valójában ki hajtotta végre a támadást. Egyelőre az ajánlás egyszerű: ne küldjön nemzetközi leveleket. Hoppá.

SPF rekordok szkennelése

[Sebastian Sallának] van egy furcsa hobbija, mégpedig a formájában az SPF rekordok szkennelése furcsa hibás konfigurációkért. Legutóbbi kalandjában ez a vizsgálat volt a 3 millió leglátogatottabb domain között. És hibás konfigurációt találtak.

De várjunk csak, mi az az SPF, és miért érdekel minket? A Sender Policy Framework egy txt rekord, amely a tartomány DNS-rekordjainak része. És megadja, hogy valójában mely IP-címek jogosultak e-mailek küldésére az adott domainhez. Tehát ha egy bejövő e-mail azt állítja, hogy érvényes SPF-rekorddal rendelkező tartományról származik, és a küldő IP-cím nem szerepel ebben a rekordban, akkor nyilvánvalóan nem az igényelt domainről származik.

Ha pedig SPF-probléma miatt elutasítják a domain e-mailjeit, az az egyik legbiztosabb módja annak, hogy elkapd a hibásodást. Szóval csábító, hogy az SPF rekordot egy kicsit… *liberálisabbá* tegyük, mint amilyennek lennie kellene. Ennek pedig a legszélsőségesebb iterációja, hogy csak pofont a +all az SPF-rekordon, és végezzen vele. Természetesen elmondja a világnak, hogy minden spammer bárhol, amely az Ön domainjét használja, valójában valódi e-maileket küld, de legalább újra működik a főnök kimenő e-mailjei. Több mint ezer SPF-re állított domainnel +all, úgy tűnik, ez a vártnál gyakoribb hiba.

Az igazán érdekes dolog az, hogy ki kicsoda ezek közül a rosszul konfigurált tartományok közül, például több amerikai kormányzati ügynökség, más kormányzati tartományok szerte a világon és több egyetem. A legérdekesebb az ukrán védelmi minisztérium volt, ahol az SPF rekordot a -all nak nek +all kb 4 hónapja.

Bitek és bájtok

A Tailscale egy potenciálisan súlyos problémát fedezett fel, ahol egy másik ügyfél csomópontazonosítójának ismerete lehetővé teszi a támadó számára, hogy hozzáadja a csomópontot a saját hátsó hálózatához. Ez egy támadót juttatott volna a VPN belsejébe, ami határozottan rossz forgatókönyv. Mielőtt azonban megkapta volna a pitchforks-t, a sebezhető kódot kevesebb mint négy hónapig telepítették, mielőtt kijavították. E hónap 11-én jelentették privátban, és 12-én rögzítették. A rendszerindításhoz a támadás egy naplóaláírást hagy maga után, amelyet a Tailscale meg tudott keresni, és arra a következtetésre jutott, hogy az elszigetelődött a koncepció bizonyítási tesztje során. Megerősítés céljából ellenőrizheti a saját irányítópultján, hogy nincs-e megosztva a saját hátsó hálózatán kívülről. És bár ez egy csúnya sebezhetőség, jó a Tailscale számára, hogy felfedje. Sok eladó ráült volna erre, és soha nem hozta volna nyilvánosságra.

A A Linux kernel puffertúlcsordulást szenvedett a Netfilter kódjában, ahol a puffer túlcsordulása adatszivárgást és kódvégrehajtást is eredményezhet. A távoli kiaknázáshoz nem vezet út, de a fent hivatkozott e-mail teljes PoC-t tartalmaz a helyi jogosultságok kiterjesztéséhez. És ha a kernel kihasználása a te dolgod, akkor a Google Project Zero igen új írás a témában, minden a null dereferencingről szól.

Ha pedig a Zoho ManageEngine-jét használod, akkor ma éghet a hajad, ha még nem frissített a CVE-2022-47966-ot javító kiadásra. Kutatók a A Horizon3 visszafejtette a javítást, és ráborította a babot erre az RCE-re. Ez egy probléma a SAML egyszeri bejelentkezés megvalósításában, részben a termék részeként becsomagolt rendkívül régi könyvtár miatt. Ez egy nagyon egyszerű kizsákmányolás, ezért ideje újra ellenőrizni a telepítéseket!

Időbélyeg:

Még több Hack A Day