Bezpieczeństwo w tym tygodniu: Git Deep Dive, Mailchimp i SPF

Bezpieczeństwo w tym tygodniu: Git Deep Dive, Mailchimp i SPF

Znacznik czasu: 20 stycznia 2023 10:00
Węzeł źródłowy: 1910203

Najpierw, git został poddany audytowi. Było to przedsięwzięcie sponsorowane przez Open Source Technology Improvement Fund (OSTIF), organizację non-profit działającą na rzecz poprawy bezpieczeństwa projektów Open Source. Sam audyt został przeprowadzony przez badaczy z X41 i GitLab oraz wykryto dwie krytyczne luki, oba spowodowane tym samym złym nawykiem kodowania — używaniem pliku int do przechowywania długości buforów.

W nowoczesnych systemach a size_t jest zawsze bez znaku i ma tę samą długość bitową, co szerokość bitowa architektury. Jest to właściwy typ danych dla długości ciągów i buforów, ponieważ gwarantuje się, że nie nastąpi przepełnienie podczas obsługi długości aż do maksymalnej adresowalnej pamięci w systemie. Z drugiej strony, an int ma zwykle cztery bajty długości i jest podpisany, a maksymalna wartość wynosi 2^31-1, czyli 2147483647 — około 2 GB. Duży bufor, ale nie niespotykana ilość danych. Rzuć coś tak dużego w git, a pęknie w nieoczekiwany sposób.

Naszym pierwszym przykładem jest CVE-2022-23521, zapis poza zakresem spowodowany przez: int przepełnienie do wartości ujemnej. A .gitattributes plik można zapisać w repozytorium za pomocą zmodyfikowanego klienta git, a następnie sprawdzenie tego repozytorium spowoduje num_attrs zmienna do przepełnienia. Wciśnij przepełnienie całkowicie do małej liczby ujemnej, a git wówczas znacznie niedostatecznie przydzieli bufor atrybutów i zapisze wszystkie dane poza końcem przydzielonego bufora.

CVE-2022-41903 to kolejne przepełnienie liczby całkowitej ze znakiem, tym razem spowodowane nadużywaniem ładnego formatu wydruku do zrobienia czegoś nieoczekiwanego. Spójrz na ten blok kodu:

 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 exploita wyglądałby mniej więcej tak %>(2147483647)%a%>(2147483646)%x41, gdzie powyższy kod jest uruchamiany dla każdej instancji dopełnienia (The %>(#) bloki) znalezione w formacie. Przy pierwszym użyciu tego kodu dodaje się (2^31)-1 spacje na początku ciągu wyjściowego. Tak się składa, że ​​ta liczba jest maksymalną wartością czterobajtowej liczby całkowitej ze znakiem. Ale powyższy blok kodu zostanie uruchomiony innym razem i do bufora zostanie dodany kolejny tekst, przesuwając jego długość powyżej maksymalnej wartości całkowitej. Pierwsza linia tego bloku wykonuje niejawne rzutowanie size_t do int, ustawienie sb_len do wartości ujemnej.

Następnie w memcpy() połączenie, sb->buf jest wskaźnikiem do początku bufora, sb_len jest naszą dużą przepełnioną liczbą ujemną, a offset będzie wartością kontrolowaną przez użytkownika. Oznacza to lokalizację miejsca docelowego, do którego wysyłany jest memcpy() może zostać przypadkowo ustawione na niższą lokalizację w pamięci niż początek zamierzonego bufora. Zapisy kontrolowane przez atakującego. Dodałem kilka debugujących instrukcji printf() do tego bloku tekstowego i uruchomiłem przypadek testowy:

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

Pierwszy kwartet wyników to konfiguracja polegająca na wypełnieniu linii dziennika dopełnieniem o maksymalnej długości int. Drugi kwartet to przepełnienie bufora, gdzie sb_len jest ustawiany na wartość ujemną, a następnie dodawany do przesunięcia, aby dać nam lokalizację 56 bajtów na lewo od początku bufora. W tym przypadku jest to treść drukowana w tej lokalizacji %s, który zostaje zastąpiony linią tematu zatwierdzenia o długości 44 bajtów. Autorzy sugerują, że można to wykorzystać przeciwko „git forge”, czyli GitHub i GitLab, ponieważ te pakiety oprogramowania uruchamiają polecenie git Archive, które może wywołać kontrolowany przez użytkownika ładny ciąg znaków.

Poprawki zostały wprowadzone do kodu źródłowego git 8 grudnia, ale nowe wydania zawierające te poprawki są już dostępne. Istnieje około 2200 przypadków surowca int problem, a jego usunięcie zajmie trochę czasu, nawet przy użyciu kilku zabawnych hacków, takich jak cast_size_t_to_int(), funkcja wbudowana, która po prostu zabija program, jeśli plik 2 GB+ size_t jest obsługiwane. Więc przejdź do aktualizacji!

Mailchimp – ponownie

Wygląda na to, że ludzie w Mailchimp nie mogą odpocząć, as osoby atakujące ponownie uzyskały dostęp do ich wewnętrznych narzędzi administracyjnych, co doprowadziło do ujawnienia 133 kont klientów, w tym WooCommerce. To już trzeci raz w ciągu ostatniego roku, kiedy Mailchimp pada ofiarą ataku wykorzystującego inżynierię społeczną lub phishing i za każdym razem kończy się to wysłaniem do użytkowników końcowych wiadomości e-mail typu spear-phishing. Jeśli więc znajdujesz się na dowolnej liście mailingowej Mailchimp, pamiętaj o tym naruszeniu, gdy następnym razem otrzyma odpowiednią wiadomość e-mail. (Nota redaktora: dwa biuletyny Hackaday korzystają z Mailchimp i nie zostaliśmy o tym powiadomieni, więc uważamy, że wszystko jest w porządku.)

Oprogramowanie ransomware Royal Mail

W historii, która może mieć poważne konsekwencje, Brytyjska Royal Mail padła ofiarą ataku ransomware w ich systemie obsługi poczty międzynarodowej. W ataku wykorzystano oprogramowanie ransomware Lockbit, grupę podejrzaną o bycie rosyjskojęzycznym gangiem zajmującym się oprogramowaniem ransomware. Może to mieć znaczenie, ponieważ atak na rzeczywistą agencję rządową jest znacznie poważniejszy niż atak na firmę. Ponieważ Lockbit działa jako oprogramowanie ransomware jako usługa, bardzo trudno będzie dokładnie ustalić, kto faktycznie przeprowadził atak. Na razie zalecenie jest proste: nie wysyłaj żadnej poczty międzynarodowej. Uff.

Skanowanie rekordów SPF

[Sebastian Salla] ma coś, co można uznać za dziwne hobby w postaci skanowanie rekordów SPF pod kątem dziwnych błędnych konfiguracji. W jego ostatniej przygodzie ten skan znalazł się na liście 3 milionów najczęściej odwiedzanych domen. I wykryto błędną konfigurację.

Ale poczekaj, co to jest SPF i dlaczego nas to obchodzi? Struktura zasad nadawcy to rekord txt będący częścią rekordów DNS domeny. Określa także, jakie adresy IP są faktycznie upoważnione do wysyłania wiadomości e-mail w tej domenie. Jeśli więc przychodząca wiadomość e-mail rzekomo pochodzi z domeny z prawidłowym rekordem SPF, a wysyłającego adresu IP nie ma w tym rekordzie, jest całkiem jasne, że tak naprawdę nie pochodzi z domeny, do której jest zgłaszany.

A odrzucenie e-maili w Twojej domenie z powodu problemu z SPF to jeden z najpewniejszych sposobów na złapanie ataku. Kuszące jest więc uczynienie rekordu SPF nieco bardziej… *liberalnym*, ​​niż być może powinno. Najbardziej ekstremalną wersją tego jest po prostu uderzenie +all na swoim rekordzie SPF i skończ z tym. Jasne, mówi to światu, że każdy spamer, gdziekolwiek korzysta z Twojej domeny, w rzeczywistości wysyła prawdziwe e-maile, ale przynajmniej sprawia, że ​​wychodzące e-maile szefa znów działają. Z ponad tysiącem domen ustawionych na SPF +all, najwyraźniej jest to częstsza usterka, niż oczekiwano.

Naprawdę interesujące jest to, kto jest kim w tych źle skonfigurowanych domenach, takich jak wiele amerykańskich agencji rządowych, inne domeny rządowe na całym świecie i wiele uniwersytetów. Najciekawszym było Ministerstwo Obrony Ukrainy, gdzie wycięto zapis SPF z a -all do +all około 4 miesiące temu.

Bity i bajty

Tailscale odkrył potencjalnie poważny problem, w którym znajomość identyfikatora węzła innego klienta umożliwiłaby osobie atakującej dodanie węzła do własnej sieci ogonowej. To spowodowałoby, że atakujący dostałby się do wnętrza Twojej sieci VPN, co jest zdecydowanie złym scenariuszem. Ale zanim dostaniesz widły, luka w kodzie była wdrażana przez niecałe cztery miesiące, zanim została naprawiona. Zostało to zgłoszone prywatnie 11 tego miesiąca i naprawione 12 tego miesiąca. Co więcej, atak pozostawia podpis dziennika, który Tailscale był w stanie przeskanować, i stwierdza, że ​​został on wyizolowany na potrzeby testów sprawdzających koncepcję. Możesz sprawdzić swój własny pulpit nawigacyjny pod kątem wszelkich węzłów udostępnionych z ich własnej sieci ogonowej w celu potwierdzenia. I chociaż jest to paskudna luka, dobrze, że Tailscale ją ujawnił. Wielu sprzedawców usiadłoby na tym i nigdy nie upubliczniłoby tego.

Połączenia Jądro Linuksa miało przepełnienie bufora w kodzie Netfilter, gdzie przepełnienie bufora może skutkować zarówno wyciekiem danych, jak i wykonaniem kodu. Nie ma ścieżki do zdalnego wykorzystania, ale powyższy e-mail zawiera pełny PoC umożliwiający eskalację uprawnień lokalnych. A jeśli lubisz eksploatację jądra, Google Project Zero już to zrobił nowy wpis na ten temat, wszystko na temat dereferencji zerowej.

A jeśli korzystasz z ManageEngine od Zoho, to dzisiaj Twoje włosy mogą płonąć, jeśli nie zaktualizowałeś do wersji, która naprawia CVE-2022-47966. Naukowcy z Horizon3 dokonał inżynierii wstecznej łatkii wylałem fasolę na temat tego RCE. Jest to problem związany ze sposobem implementacji pojedynczego logowania SAML, częściowo spowodowany bardzo starą biblioteką spakowaną jako część produktu. Jest to dość łatwy exploit, więc czas dokładnie sprawdzić te instalacje!

Znak czasu:

Więcej z Zhakuj dzień