Ta teden v Varnost: Git Deep Dive, Mailchimp in SPF

Ta teden v Varnost: Git Deep Dive, Mailchimp in SPF

Časovni žig: 20. januar 2023 10
Izvorno vozlišče: 1910203

Najprej, git je bil revidiran. To je bilo prizadevanje, ki ga je sponzoriral Sklad za izboljšanje odprtokodne tehnologije (OSTIF), neprofitna organizacija, ki si prizadeva izboljšati varnost odprtokodnih projektov. Samo revizijo so opravili raziskovalci iz X41 in GitLaba ter najdeni sta bili dve kritični ranljivosti, oboje pa je povzročila ista slaba navada kodiranja — uporaba an int za shranjevanje dolžin medpomnilnika.

Na sodobnih sistemih, a size_t je vedno brez predznaka in enake bitne dolžine kot bitna širina arhitekture. To je ustrezen podatkovni tip za dolžine nizov in vmesnega pomnilnika, saj je zagotovljeno, da se ne bodo prelili pri obdelavi dolžin do največjega naslovljivega pomnilnika v sistemu. Po drugi strani pa an int je običajno dolg štiri bajte in predpisan, z največjo vrednostjo 2^31-1 ali 2147483647 — približno 2 GB. Velik medpomnilnik, vendar ne nezaslišana količina podatkov. Vrzi nekaj tako velikega v git in zlomilo se bo na nepričakovane načine.

Naš prvi primer je CVE-2022-23521, pisanje izven meja, ki ga povzroči int prelivanje v negativno. A .gitattributes datoteko lahko objavite v repozitoriju s spremenjenim odjemalcem git, nato pa preverjanje tega repozitorija povzroči num_attrs spremenljivka za prelivanje. Potisnite prelivanje vse do majhnega negativnega števila in git bo nato močno premalo dodelil vmesni pomnilnik atributov in zapisal vse te podatke čez konec dodeljenega vmesnega pomnilnika.

CVE-2022-41903 je še en presežek celega števila s predznakom, tokrat ko je lep format tiskanja zlorabljen za nekaj nepričakovanega. Oglejte si ta blok kode:

 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);

Format izkoriščanja bi bil videti nekako takole %>(2147483647)%a%>(2147483646)%x41, kjer se zgornja koda izvaja za vsak primerek oblazinjenja (The %>(#) bloki), ki jih najdete v formatu. Prvič skozi to kodo doda (2^31)-1 presledke na začetek izhodnega niza. To število je po naključju največja vrednost štiribajtnega celega števila s predznakom. Toda zgornji kodni blok se zažene drugič in še enkrat se v medpomnilnik doda novo besedilo, ki potisne njegovo dolžino nad največjo celoštevilsko vrednost. Prva vrstica tega bloka izvede implicitno pretvorbo iz size_t do int, nastavitev sb_len na negativno vrednost.

Potem v memcpy() klic, sb->buf je kazalec na začetek medpomnilnika, sb_len je naše prekoračeno veliko negativno število, odmik pa bo vrednost, ki jo nadzira uporabnik. To pomeni lokacijo cilja, na katerega je poslano sporočilo memcpy() lahko nenamerno nastavite na nižjo pomnilniško lokacijo od začetka predvidenega medpomnilnika. Napadalec nadzoruje pisanje. V ta besedilni blok sem dodal nekaj stavkov printf() za odpravljanje napak in zagnal testni primer:

$ ./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)

Prvi kvartet izhodov tam je nastavitev, ki vrstico dnevnika napolni z oblazinjenjem, da je največja int dolga. Drugi kvartet je prekoračitev blažilnika, kjer sb_len je nastavljen na negativno in nato dodan odmiku, da dobimo lokacijo 56 bajtov levo od začetka vmesnega pomnilnika. Vsebina, ki se natisne na to lokacijo, je v tem primeru %s, ki se nadomesti z vrstico zadeve objave — dolžine 44 bajtov. Avtorji predlagajo, da bi to lahko uporabili kot orožje proti "git forge", AKA GitHub in GitLab, saj ti programski paketi izvajajo ukaz git archive, ki lahko prikliče uporabniško nadzorovan lepi niz.

Popravki so bili potisnjeni v izvorno kodo git 8. decembra, vendar so nove izdaje, ki vsebujejo te popravke, na voljo šele zdaj. Obstaja približno 2200 primerkov raw int težave, ki bodo potrebovale nekaj časa, da jih odpravite, tudi z nekaterimi zabavnimi vdori, kot je cast_size_t_to_int(), vgrajena funkcija, ki samo ubije program, če je 2 GB+ size_t se obravnava. Torej pojdite na posodobitev!

Mailchimp — Spet

Zdi se, da si ljudje pri Mailchimpu ne morejo oddahniti, saj napadalci so ponovno dostopali do njihovih notranjih administrativnih orodij, kar je povzročilo izpostavljenost 133 računov strank, vključno z WooCommerce. To je že tretjič, da je Mailchimp v zadnjem letu naletel na napad družbenega inženiringa ali lažnega predstavljanja in vsakič je končnim uporabnikom poslala e-poštna sporočila s lažnim predstavljanjem. Torej, če ste na katerem koli poštnem seznamu Mailchimp, upoštevajte to kršitev, ko naslednjič prejmete povezano e-poštno sporočilo. (Opomba urednika: dve Hackadayjevi glasili uporabljata Mailchimp in nismo bili obveščeni, zato verjamemo, da smo dobri.)

Royal Mail Ransomware

V zgodbi, ki bi lahko imela velike posledice, je Britanska pošta Royal Mail je bila izpostavljena napadu izsiljevalske programske opreme na njihov sistem za ravnanje z mednarodno pošto. Napad uporablja izsiljevalsko programsko opremo Lockbit, skupino, za katero sumijo, da je tolpa rusko govoreče izsiljevalske programske opreme. To je lahko pomembno, saj je napad na dejansko vladno agencijo veliko resnejši od napada na podjetje. Ker Lockbit deluje kot izsiljevalska programska oprema kot storitev, bo zelo težko natančno ugotoviti, kdo je dejansko izvedel napad. Za zdaj je priporočilo preprosto: ne pošiljajte mednarodne pošte. Uf.

Skeniranje SPF zapisov

[Sebastian Salla] ima nekaj, kar se lahko šteje za čuden hobi, v obliki skeniranje zapisov SPF za nenavadne napačne konfiguracije. V njegovi zadnji pustolovščini je bilo to skeniranje med 3 milijoni najbolj obiskanih domen. In najdena je bila napačna konfiguracija.

Toda počakaj, kaj je SPF in zakaj nas to zanima? Sender Policy Framework je zapis txt, ki je del zapisov DNS domene. In določa, kateri naslovi IP so dejansko pooblaščeni za pošiljanje e-pošte za to domeno. Torej, če dohodno e-poštno sporočilo trdi, da je iz domene z veljavnim zapisom SPF, naslova IP pošiljatelja pa ni v tem zapisu, očitno v resnici ni iz zahtevane domene.

Zavrnitev e-poštnih sporočil vaše domene zaradi težave z zaščitnim faktorjem je eden najzanesljivejših načinov, da ujamete nesramnost. Zato je skušnjava narediti zapis SPF nekoliko bolj … *liberalen*, kot bi morda moral biti. In najekstremnejša ponovitev tega je preprosto udariti a +all na vaš zapis SPF in končajte s tem. Seveda sporoča svetu, da vsak pošiljatelj neželene pošte kjer koli, ki uporablja vašo domeno, dejansko pošilja prava e-poštna sporočila, vendar vsaj poskrbi, da šefova odhodna e-poštna sporočila znova delujejo. Z več kot tisoč domenami, nastavljenimi na SPF +all, očitno je to pogostejša napaka, kot je bilo pričakovano.

Resnično zanimiv del je, kdo je kdo od teh napačno konfiguriranih domen, kot je več ameriških vladnih agencij, drugih vladnih domen po vsem svetu in več univerz. Najbolj zanimivo je bilo ukrajinsko ministrstvo za obrambo, kjer so zapis SPF izrezali iz a -all do +all približno 4 mesece nazaj.

Biti in bajti

Tailscale je odkril potencialno resno težavo, pri kateri bi poznavanje ID-ja vozlišča drugega odjemalca napadalcu omogočilo dodajanje vozlišča v lastno končno mrežo. To bi napadalca postavilo v notranjost vašega VPN-ja, kar je vsekakor slab scenarij. Toda preden dobite svoje vile, je bila ranljiva koda nameščena manj kot štiri mesece, preden je bila popravljena. Zasebno je bilo prijavljeno 11. tega meseca, popravljeno pa 12. In za začetek, napad pusti podpis dnevnika, ki ga je Tailscale lahko pregledal in ugotovil, da je bil izoliran za testiranje dokaza koncepta. Za potrditev lahko na svoji nadzorni plošči preverite morebitna vozlišča, ki so v skupni rabi iz lastnega zadnjega omrežja. In čeprav gre za grdo ranljivost, dobro za Tailscale, da jo razkrije. Mnogi prodajalci bi sedeli na tem in ga nikoli ne bi javno objavili.

O Jedro Linuxa je imelo prekoračitev medpomnilnika v kodi Netfilter, kjer lahko prekoračitev medpomnilnika povzroči uhajanje podatkov in izvajanje kode. Ne obstaja pot do oddaljenega izkoriščanja, vendar e-poštno sporočilo na zgornjo povezavo vsebuje celoten PoC za lokalno eskalacijo privilegijev. In če vam je všeč izkoriščanje jedra, vam je všeč Googlov Project Zero nov zapis na to temo, vse o ničelnem dereferenciranju.

In če uporabljate ManageEngine iz Zohoja, potem vam bodo danes morda goreli lasje, če niste posodobili na izdajo, ki popravlja CVE-2022-47966. Raziskovalci na Horizon3 je izvedel obratni inženiring popravka, in prelil čaco o tem RCE. Težava je v tem, kako se izvaja enotna prijava SAML, deloma zaradi izjemno stare knjižnice, ki je pakirana kot del izdelka. Izkoriščanje je precej enostavno, zato je čas, da še enkrat preverite te namestitve!

Časovni žig:

Več od Hack A Day