Questa settimana in sicurezza: Git Deep Dive, Mailchimp e SPF

Questa settimana in sicurezza: Git Deep Dive, Mailchimp e SPF

Timestamp: 20 gennaio 2023 10:00
Nodo di origine: 1910203

Prima su, git è stato controllato. Questo è stato uno sforzo sponsorizzato dall'Open Source Technology Improvement Fund (OSTIF), un'organizzazione no-profit che lavora per migliorare la sicurezza dei progetti Open Source. L'audit stesso è stato effettuato dai ricercatori di X41 e GitLab e sono state rilevate due vulnerabilità critiche, entrambi causati dalla stessa cattiva abitudine di codifica: utilizzare un file int per contenere le lunghezze del buffer.

Sui sistemi moderni, a size_t è sempre senza segno e ha la stessa lunghezza in bit della larghezza in bit dell'architettura. Questo è il tipo di dati corretto per le lunghezze di stringhe e buffer, poiché è garantito che non si verifichi un overflow quando si gestiscono lunghezze fino alla memoria indirizzabile massima sul sistema. D'altra parte, un int è solitamente lungo quattro byte e firmato, con un valore massimo di 2^31-1 o 2147483647 — circa 2 GB. Un grande buffer, ma non una quantità di dati inaudita. Lancia qualcosa di così grande a Git e si romperà in modi inaspettati.

Il nostro primo esempio è CVE-2022-23521, una scrittura fuori limite causata da un file int traboccante in negativo. UN .gitattributes il file può essere impegnato in un repository con un client git modificato, quindi il check-out di quel repository causerà l'errore num_attrs variabile da traboccare. Spingi l'overflow fino a un piccolo numero negativo e git sottoassegnerà notevolmente il buffer degli attributi e scriverà tutti i dati oltre la fine del buffer allocato.

CVE-2022-41903 è un altro overflow di numeri interi con segno, questa volta quando un bel formato di stampa viene abusato per fare qualcosa di inaspettato. Dai un'occhiata a questo blocco di codice:

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

Il formato dell'exploit sarebbe simile a %>(2147483647)%a%>(2147483646)%x41, dove il codice precedente viene eseguito per ogni istanza di riempimento (The %>(#) blocchi) trovati nel formato. La prima volta che si utilizza questo codice aggiunge (2^31)-1 spazi all'inizio della stringa di output. Quel numero sembra essere il valore massimo di un intero con segno di quattro byte. Ma il blocco di codice sopra viene eseguito un'altra volta e ancora una volta il testo viene aggiunto al buffer, spingendone la lunghezza oltre il valore intero massimo. La prima riga di quel blocco esegue un cast implicito size_t a int, ambientazione sb_len ad un valore negativo.

Quindi nel memcpy() chiamata, sb->buf è un puntatore all'inizio del buffer, sb_len è il numero negativo grande in overflow e offset sarà un valore controllato dall'utente. Ciò significa la posizione della destinazione inviata memcpy() può essere impostato involontariamente su una posizione di memoria inferiore rispetto all'inizio del buffer previsto. Scritture controllate dall'attaccante. Ho aggiunto alcune istruzioni di debug printf() a questo blocco di testo ed ho eseguito un caso di test:

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

Il primo quartetto di output è l'impostazione, che prepara la riga di registro con il riempimento in modo che abbia una lunghezza massima di int. Il secondo quartetto è il buffer overrun, dove sb_len è impostato su negativo e quindi aggiunto all'offset per darci una posizione 56 byte a sinistra dell'inizio del buffer. In questo caso si trova il contenuto che viene stampato in quella posizione %s, che viene sostituito dalla riga dell'oggetto del commit, lunga 44 byte. Gli autori suggeriscono che questo potrebbe essere utilizzato come arma contro un "git forge", AKA GitHub e GitLab, poiché tali suite software eseguono il comando git archive, che può invocare una bella stringa controllata dall'utente.

Le correzioni sono state inviate al codice sorgente git l'8 dicembre, ma le nuove versioni contenenti tali correzioni sono disponibili solo ora. Ci sono circa 2200 istanze del file raw int problema, e ci vorrà un po' di tempo per risolverlo, anche con alcuni trucchetti divertenti come cast_size_t_to_int(), una funzione inline che uccide il programma se è disponibile un file da 2 GB+ size_t viene gestito. Quindi vai ad aggiornare!

Mailchimp – Ancora una volta

Sembra che i ragazzi di Mailchimp non riescano a prendersi una pausa gli aggressori hanno nuovamente avuto accesso ai loro strumenti di amministrazione interna, portando all'esposizione di 133 account cliente, incluso WooCommerce. Questa è la terza volta che Mailchimp subisce un attacco di ingegneria sociale o di phishing nell’ultimo anno e ogni volta ha provocato l’invio di e-mail di spear phishing agli utenti finali. Quindi, se fai parte di una qualsiasi mailing list di Mailchimp, tieni a mente questa violazione la prossima volta che arriva un’e-mail correlata. (Nota del redattore: le due newsletter di Hackaday utilizzano Mailchimp e non siamo stati avvisati, quindi riteniamo di essere bravi.)

Ransomware Royal Mail

In una storia che potrebbe avere delle grandi conseguenze, il La Royal Mail del Regno Unito ha subito un attacco ransomware sul loro sistema di gestione della posta internazionale. L'attacco utilizza il ransomware Lockbit, un gruppo sospettato di essere una banda di ransomware di lingua russa. Ciò potrebbe essere significativo, poiché un attacco a un’agenzia governativa reale è molto più grave di un attacco a un’azienda. Dato che Lockbit funziona come ransomware-as-a-service, sarà molto difficile determinare esattamente chi ha effettivamente sferrato l’attacco. Per ora, la raccomandazione è semplice: non inviare posta internazionale. Uffa.

Scansione dei record SPF

[Sebastian Salla] ha quello che può essere considerato uno strano hobby, sotto forma di scansione dei record SPF per strane configurazioni errate. Nella sua ultima avventura, ha scansionato i 3 milioni di domini più visitati. Ed è stata trovata una configurazione errata.

Ma aspetta, cos'è un SPF e perché ci interessa? Sender Policy Framework è un record txt che fa parte dei record DNS di un dominio. E specifica quali indirizzi IP sono effettivamente autorizzati a inviare e-mail per quel dominio. Pertanto, se un'e-mail in arrivo dichiara di provenire da un dominio con un record SPF valido e l'indirizzo IP di invio non è presente su quel record, è abbastanza chiaro che non proviene realmente dal dominio dichiarato.

E il fatto che le email del tuo dominio vengano rifiutate a causa di un problema SPF è uno dei modi più sicuri per catturare le critiche. Quindi c’è la tentazione di rendere il record dell’SPF un po’ più… *liberale* di quanto forse dovrebbe essere. E l'iterazione più estrema di questo è semplicemente schiaffeggiare a +all sul tuo record SPF e farla finita. Certo, dice al mondo che ogni spammer ovunque che utilizza il tuo dominio sta effettivamente inviando email vere, ma almeno fa funzionare di nuovo le email in uscita del capo. Con oltre mille domini impostati su SPF +all, a quanto pare è un difetto più comune del previsto.

La parte davvero interessante è chi è chi di quei domini configurati in modo errato, come più agenzie governative statunitensi, altri domini governativi in ​​tutto il mondo e più università. Il caso più interessante è stato quello del Ministero della Difesa ucraino, dove il record dell'SPF è stato ritagliato da un file -all a +all circa 4 mesi fa.

Bit e byte

Tailscale ha scoperto un problema potenzialmente serio, in cui conoscere l'ID del nodo di un altro client consentirebbe a un utente malintenzionato di aggiungere il nodo alla propria tailnet. Ciò avrebbe messo un utente malintenzionato all’interno della tua VPN, sicuramente uno scenario negativo. Ma prima che tu prendessi i forconi, il codice vulnerabile è stato distribuito per meno di quattro mesi prima che fosse risolto. È stato riferito in privato l'11 di questo mese e fissato il 12. E per di più, l'attacco lascia una firma di registro che Tailscale è stato in grado di scansionare e ha concluso che era isolato dal test di prova. Puoi controllare la tua dashboard per eventuali nodi condivisi dalla propria tailnet per conferma. E anche se si tratta di una brutta vulnerabilità, è positivo che Tailscale la riveli. Molti venditori si sarebbero seduti su questo e non lo avrebbero mai reso pubblico.

Il Il kernel Linux ha avuto un buffer overflow nel suo codice Netfilter, dove un overflow del buffer potrebbe causare sia la perdita di dati che l'esecuzione del codice. Non esiste un percorso per lo sfruttamento remoto, ma l'e-mail collegata sopra contiene un PoC completo per un'escalation dei privilegi locali. E se lo sfruttamento del kernel fa per te, Project Zero di Google lo fa un nuovo articolo sull'argomento, tutto sul dereferenziamento nullo.

E se utilizzi ManageEngine di Zoho, oggi i tuoi capelli potrebbero andare a fuoco, se non hai aggiornato alla versione che risolve CVE-2022-47966. I ricercatori di Horizon3 ha decodificato la patch, e abbiamo vuotato il sacco su questo RCE. È un problema nel modo in cui viene implementato il single-sign-on SAML, in parte a causa di una libreria estremamente vecchia confezionata come parte del prodotto. È un exploit piuttosto semplice da realizzare, quindi è ora di ricontrollare le installazioni!

Timestamp:

Di più da Hackera un giorno