Denne uge i sikkerhed: Git Deep Dive, Mailchimp og SPF

Denne uge i sikkerhed: Git Deep Dive, Mailchimp og SPF

Tidsstempel: 20. januar 2023 kl. 10
Kildeknude: 1910203

Først op, git er blevet revideret. Dette var en indsats sponsoreret af Open Source Technology Improvement Fund (OSTIF), en non-profit, der arbejder på at forbedre sikkerheden i Open Source-projekter. Selve revisionen blev foretaget af forskere fra X41 og GitLab, og to kritiske sårbarheder blev fundet, begge forårsaget af den samme dårlige kodningsvane - ved at bruge en int at holde bufferlængder.

På moderne systemer, en size_t er altid usigneret og har samme bitlængde som arkitekturens bitbredde. Dette er den korrekte datatype for streng- og bufferlængder, da den med garanti ikke løber over, når der håndteres længder op til den maksimale adresserbare hukommelse på systemet. På den anden side er en int er normalt fire bytes lang og signeret med en maksimal værdi på 2^31-1, eller 2147483647 - omkring 2 GB. En stor buffer, men ikke en uhørt mængde data. Kast noget så stort efter git, og det vil gå i stykker på uventede måder.

Vores første eksempel er CVE-2022-23521, en out of bounds-skrivning forårsaget af en int flyder over til negativ. EN .gitattributes fil kan forpligtes til et depot med en modificeret git-klient, og derefter tjekker dette lager vil num_attrs variabel til overløb. Skub overløbet hele vejen rundt til et lille negativt tal, og git vil så meget underallokere attributbufferen og skrive alle disse data forbi slutningen af ​​den allokerede buffer.

CVE-2022-41903 er endnu et signeret heltalsoverløb, denne gang, hvor et smukt printformat bliver misbrugt til at gøre noget uventet. Tag et kig på denne kodeblok:

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

Udnyttelsesformatet ville ligne noget %>(2147483647)%a%>(2147483646)%x41, hvor koden ovenfor kører for hver udfyldningsforekomst (The %>(#) blokke) fundet i formatet. Første gang gennem denne kode tilføjes (2^31)-1 mellemrum foran på outputstrengen. Det tal er tilfældigvis den maksimale værdi af et heltal med fire byte fortegn. Men kodeblokken ovenfor køres en anden gang, og endnu en gang tilføjes tekst til bufferen, hvorved dens længde skubbes over den maksimale heltalsværdi. Den første linje i den blok laver en implicit cast fra size_t til int, indstilling sb_len til en negativ værdi.

Så i memcpy() opkald, sb->buf er en pointer til starten af ​​bufferen, sb_len er vores overfyldte store negative tal, og offset vil være en brugerstyret værdi. Dette betyder placeringen af ​​den destination, der sendes til memcpy() kan utilsigtet indstilles til en lavere hukommelsesplacering end starten af ​​den tilsigtede buffer. Angriber kontrolleret skriver. Jeg har tilføjet nogle debugging printf()-sætninger til denne tekstblok og kørt en test-case:

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

Den første kvartet af output der er opsætningen, der primer loglinjen med polstring til at være max int lang. Den anden kvartet er bufferoverløbet, hvor sb_len er sat til negativ og derefter tilføjet til offset for at give os en placering 56 bytes til venstre for starten af ​​bufferen. Indholdet, der udskrives til det pågældende sted, er i dette tilfælde %s, som bliver erstattet af emnelinjen for commit - 44 bytes lang. Forfatterne foreslår, at dette kunne væbnes mod en "git forge", AKA GitHub og GitLab, da disse softwarepakker kører git archive-kommandoen, som kan påkalde en brugerstyret smuk streng.

Rettelser blev skubbet til git-kildekoden tilbage den 8. december, men nye udgivelser, der indeholder disse rettelser, er lige nu tilgængelige. Der er cirka 2200 forekomster af råmaterialet int problem, og det vil tage et stykke tid at rydde op, selv med nogle sjove hacks som cast_size_t_to_int(), en inline-funktion, der bare dræber programmet, hvis en 2 GB+ size_t er håndteret. Så opdater!

Mailchimp - Igen

Det ser ud til, at folk hos Mailchimp ikke kan tage en pause, som deres interne administrationsværktøjer blev igen tilgået af angribere, hvilket fører til eksponering af 133 kundekonti, inklusive WooCommerce. Det er tredje gang, at Mailchimp er faldet til et social engineering eller phishing-angreb i det sidste år, og hver gang har det resulteret i spear-phishing-e-mails sendt til slutbrugere. Så hvis du er på nogen Mailchimp-mailinglister, skal du huske dette brud, næste gang en relateret e-mail ankommer. (Redaktørens note: Hackadays to nyhedsbreve bruger Mailchimp, og vi fik ikke besked, så vi mener, at vi er gode.)

Royal Mail Ransomware

I en historie, der kan få nogle store konsekvenser, er den Det britiske Royal Mail har været udsat for et ransomware-angreb på deres system til håndtering af international post. Angrebet bruger Lockbit ransomware, en gruppe, der mistænkes for at være en russisktalende ransomware-bande. Dette kan være væsentligt, da et angreb på en faktisk statslig myndighed er langt mere alvorligt end et angreb på en virksomhed. Da Lockbit kører som ransomware-as-a-service, bliver det meget svært at afgøre præcis, hvem der rent faktisk gennemførte angrebet. Indtil videre er anbefalingen enkel: send ikke international post. Øv.

Scanning af SPF-poster

[Sebastian Salla] har, hvad der kan betragtes som en mærkelig hobby, i form af scanning af SPF-poster for mærkelige fejlkonfigurationer. I hans seneste eventyr var denne scanning de 3 millioner mest besøgte domæner. Og fejlkonfiguration blev fundet.

Men hold ud, hvad er en SPF, og hvorfor er vi ligeglade? Sender Policy Framework er en txt-post, der er en del af et domænes DNS-poster. Og det specificerer, hvilke IP-adresser der faktisk er godkendt til at sende e-mail for det pågældende domæne. Så hvis en indgående e-mail hævder at være fra et domæne med en gyldig SPF-record, og den afsendende IP-adresse ikke er på den registrering, er det temmelig tydeligt ikke rigtig fra det påberåbte domæne.

Og at få dit domænes e-mails afvist på grund af et SPF-problem er en af ​​de sikreste måder at fange flager på. Så det er fristende at gøre SPF-pladen lidt mere ... *liberal*, end den måske burde være. Og den mest ekstreme gentagelse af dette er bare at smække en +all på din SPF-post og vær færdig med det. Sikker på, det fortæller verden, at alle spammere overalt, der bruger dit domæne, faktisk sender rigtige e-mails, men i det mindste får det chefens udgående e-mails til at fungere igen. Med over tusinde domæner sat til SPF +all, tilsyneladende er det mere almindelig en fejl end forventet.

Det virkelig interessante er, hvem der er hvem af disse fejlkonfigurerede domæner, som flere amerikanske statslige agenturer, andre statslige domæner rundt om i verden og flere universiteter. Den mest interessante var det ukrainske forsvarsministerium, hvor SPF-rekorden blev klippet fra en -all til +all omkring 4 måneder siden.

Bits og bytes

Tailscale opdagede et potentielt alvorligt problem, hvor at kende node-id'et for en anden klient ville give en angriber mulighed for at tilføje noden til deres eget tailnet. Dette ville have sat en angriber på indersiden af ​​din VPN, bestemt et dårligt scenario. Men før du får dine pitchforks, blev den sårbare kode implementeret i mindre end fire måneder, før den blev rettet. Det blev privat rapporteret den 11. i denne måned og fastsat den 12. Og for at starte, efterlader angrebet en logsignatur, som Tailscale var i stand til at scanne efter, og konkluderede, at den var isoleret til proof-of-concept-testen. Du kan tjekke dit eget dashboard for eventuelle noder, der deles ud af deres eget tailnet, til bekræftelse. Og selvom det er en grim sårbarhed, er det godt for Tailscale at afsløre det. Mange leverandører ville have siddet på denne og aldrig offentliggjort den.

Linux-kernen havde et bufferoverløb i sin Netfilter-kode, hvor et bufferoverløb kunne resultere i både datalækage og kodeudførelse. Der er ikke en sti til fjernudnyttelse, men den e-mail, der er linket ovenfor, indeholder en fuld PoC for en lokal privilegieeskalering. Og hvis kernel udnyttelse er din ting, har Googles Project Zero et nyt indlæg om emnet, alt om nul dereferencing.

Og hvis du bruger ManageEngine fra Zoho, så kan dit hår i dag brænde, hvis du ikke har opdateret til udgivelsen, der fikser CVE-2022-47966. Forskere ved Horizon3 har reverse-engineeret patchen, og spildte bønnerne på denne RCE. Det er et problem i, hvordan SAML single-sign-on implementeres, delvist på grund af et ekstremt gammelt bibliotek pakket som en del af produktet. Det er en ret nem udnyttelse at udføre, så det er tid til at dobbelttjekke disse installationer!

Tidsstempel:

Mere fra Hack A Day