Diese Woche in Sicherheit: Git Deep Dive, Mailchimp und SPF

Diese Woche in Sicherheit: Git Deep Dive, Mailchimp und SPF

Zeitstempel: 20. Januar 2023, 10:00 Uhr
Quellknoten: 1910203

Zuerst, Git wurde geprüft. Dies war eine vom Open Source Technology Improvement Fund (OSTIF) gesponserte Initiative, einer gemeinnützigen Organisation, die sich für die Verbesserung der Sicherheit von Open Source-Projekten einsetzt. Das Audit selbst wurde von Forschern von X41 und GitLab durchgeführt Es wurden zwei kritische Schwachstellen gefunden, beide werden durch die gleiche schlechte Programmiergewohnheit verursacht – die Verwendung eines int Pufferlängen zu halten.

Auf modernen Systemen a size_t ist immer vorzeichenlos und hat die gleiche Bitlänge wie die Architektur-Bitbreite. Dies ist der richtige Datentyp für Zeichenfolgen- und Pufferlängen, da bei der Verarbeitung von Längen bis zum maximal adressierbaren Speicher im System garantiert kein Überlauf auftritt. Andererseits ein int ist normalerweise vier Bytes lang und vorzeichenbehaftet, mit einem Maximalwert von 2^31-1 oder 2147483647 – etwa 2 GB. Ein großer Puffer, aber keine unerhörte Datenmenge. Werfen Sie etwas so Großes auf den Git, und es wird auf unerwartete Weise kaputt gehen.

Unser erstes Beispiel ist CVE-2022-23521, ein Schreibvorgang außerhalb der Grenzen, der durch einen verursacht wurde int überlaufend ins Negative. A .gitattributes Die Datei kann mit einem geänderten Git-Client in ein Repository übertragen werden, und das anschließende Auschecken dieses Repositorys führt zu dem Problem num_attrs Variable zum Überlaufen. Schieben Sie den Überlauf ganz herum auf eine kleine negative Zahl, und Git wird dann den Attributpuffer deutlich unterbelegen und alle Daten über das Ende des zugewiesenen Puffers hinaus schreiben.

CVE-2022-41903 ist ein weiterer vorzeichenbehafteter Ganzzahlüberlauf, diesmal, wenn ein hübsches Druckformat missbraucht wird, um etwas Unerwartetes zu bewirken. Schauen Sie sich diesen Codeblock an:

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

Das Exploit-Format würde ungefähr so ​​aussehen %>(2147483647)%a%>(2147483646)%x41, wobei der obige Code für jede Auffüllinstanz ausgeführt wird (The %>(#) Blöcke), die im Format gefunden werden. Beim ersten Durchlaufen dieses Codes werden (2^31)-1 Leerzeichen am Anfang der Ausgabezeichenfolge hinzugefügt. Diese Zahl ist zufällig der Maximalwert einer XNUMX-Byte-Ganzzahl mit Vorzeichen. Der obige Codeblock wird jedoch ein weiteres Mal ausgeführt, und dem Puffer wird erneut Text hinzugefügt, wodurch seine Länge über den maximalen Ganzzahlwert hinausgeht. Die erste Zeile dieses Blocks führt eine implizite Umwandlung von durch size_t zu int, Einstellung sb_len auf einen negativen Wert.

Dann in der memcpy() Anruf, sb->buf ist ein Zeiger auf den Anfang des Puffers, sb_len ist unsere übergelaufene große negative Zahl und offset ist ein vom Benutzer gesteuerter Wert. Dies bedeutet den Standort des Ziels, an das gesendet wird memcpy() kann unbeabsichtigt auf einen niedrigeren Speicherort als den Anfang des vorgesehenen Puffers gesetzt werden. Vom Angreifer kontrollierte Schreibvorgänge. Ich habe diesem Textblock einige printf()-Anweisungen zum Debuggen hinzugefügt und einen Testfall ausgeführt:

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

Das erste Quartett der Ausgaben dort ist das Setup, bei dem die Protokollzeile mit Auffüllung auf eine maximale int-Länge vorbereitet wird. Das zweite Quartett ist der Pufferüberlauf, wo sb_len wird auf negativ gesetzt und dann zum Offset addiert, um eine Position 56 Byte links vom Anfang des Puffers zu erhalten. Der Inhalt, der an diesem Ort gedruckt wird, ist in diesem Fall %s, die durch die Betreffzeile des Commits ersetzt wird – 44 Byte lang. Die Autoren schlagen vor, dass dies als Waffe gegen eine „Git-Schmiede“, auch bekannt als GitHub und GitLab, eingesetzt werden könnte, da diese Software-Suiten den Befehl „git archive“ ausführen, der einen vom Benutzer gesteuerten hübschen String aufrufen kann.

Korrekturen wurden bereits am 8. Dezember in den Git-Quellcode übernommen, neue Versionen mit diesen Korrekturen sind jedoch erst jetzt verfügbar. Es gibt ungefähr 2200 Instanzen des Rohdatensatzes int Problem, und es wird eine Weile dauern, bis es bereinigt ist, selbst mit ein paar lustigen Hacks wie cast_size_t_to_int(), eine Inline-Funktion, die das Programm bei mehr als 2 GB einfach beendet size_t abgewickelt wird. Also los, Update!

Mailchimp – Schon wieder

Es scheint, dass die Leute bei Mailchimp keine Pause einlegen können Ihre internen Verwaltungstools wurden erneut von Angreifern angegriffen, was zur Offenlegung von 133 Kundenkonten führte, darunter WooCommerce. Dies ist das dritte Mal, dass Mailchimp im letzten Jahr einem Social-Engineering- oder Phishing-Angriff zum Opfer fiel, und jedes Mal wurden Spear-Phishing-E-Mails an Endbenutzer gesendet. Wenn Sie also auf einer Mailchimp-Mailingliste stehen, denken Sie an diesen Verstoß, wenn das nächste Mal eine entsprechende E-Mail eintrifft. (Anmerkung des Herausgebers: Die beiden Newsletter von Hackaday verwenden Mailchimp und wir wurden nicht benachrichtigt, daher glauben wir, dass wir gut sind.)

Royal Mail-Ransomware

In einer Geschichte, die große Konsequenzen haben könnte, ist die Die britische Royal Mail wurde Opfer eines Ransomware-Angriffs über ihr System zur Bearbeitung internationaler Post. Der Angriff nutzt Lockbit-Ransomware, eine Gruppe, bei der es sich vermutlich um eine russischsprachige Ransomware-Bande handelt. Dies könnte von Bedeutung sein, da ein Angriff auf eine tatsächliche Regierungsbehörde weitaus schwerwiegender ist als ein Angriff auf ein Unternehmen. Da Lockbit als Ransomware-as-a-Service läuft, wird es sehr schwierig sein, genau zu bestimmen, wer den Angriff tatsächlich durchgeführt hat. Die Empfehlung ist vorerst einfach: Versenden Sie keine internationale Post. Uff.

Scannen von SPF-Datensätzen

[Sebastian Salla] hat etwas, was man als seltsames Hobby bezeichnen könnte, in Form von Scannen von SPF-Einträgen auf seltsame Fehlkonfigurationen. In seinem neuesten Abenteuer war dieser Scan die Top 3 Millionen der meistbesuchten Domains. Und es wurde eine Fehlkonfiguration festgestellt.

Aber Moment mal, was ist ein Lichtschutzfaktor und warum interessiert uns das? Das Sender Policy Framework ist ein TXT-Eintrag, der Teil der DNS-Einträge einer Domäne ist. Und es gibt an, welche IP-Adressen tatsächlich zum Senden von E-Mails für diese Domain berechtigt sind. Wenn also eine eingehende E-Mail behauptet, von einer Domain mit einem gültigen SPF-Eintrag zu stammen, und die sendende IP-Adresse nicht in diesem Eintrag enthalten ist, stammt sie ganz offensichtlich nicht wirklich von der beanspruchten Domain.

Und wenn die E-Mails Ihrer Domain aufgrund eines SPF-Problems abgelehnt werden, ist dies eine der sichersten Möglichkeiten, Kritik zu erleiden. Es ist also verlockend, die SPF-Aufzeichnung etwas … *liberaler* zu gestalten, als es vielleicht sein sollte. Und die extremste Variante davon ist, einfach einen zu schlagen +all auf Ihrem SPF-Eintrag und fertig. Sicher, es zeigt der Welt, dass jeder Spammer, der Ihre Domain nutzt, tatsächlich echte E-Mails sendet, aber zumindest werden die ausgehenden E-Mails des Chefs wieder zum Laufen gebracht. Mit über tausend Domains, die auf SPF eingestellt sind +all, anscheinend ist das ein häufigerer Fehler als erwartet.

Das wirklich Interessante ist das Who-is-Who dieser falsch konfigurierten Domänen, wie z. B. mehrere US-Regierungsbehörden, andere Regierungsdomänen auf der ganzen Welt und mehrere Universitäten. Am interessantesten war das ukrainische Verteidigungsministerium, wo der SPF-Datensatz von einem abgeschnitten wurde -all zu +all Vor etwa 4 Monaten.

Bits und Bytes

Tailscale hat ein potenziell schwerwiegendes Problem entdeckt, bei dem die Kenntnis der Knoten-ID eines anderen Clients es einem Angreifer ermöglichen würde, den Knoten seinem eigenen Tailnet hinzuzufügen. Dies hätte dazu geführt, dass ein Angreifer in Ihr VPN eingedrungen wäre, was definitiv ein schlechtes Szenario ist. Doch bevor es überhaupt zur Sache geht: Der anfällige Code war weniger als vier Monate lang im Einsatz, bevor er behoben wurde. Es wurde am 11. dieses Monats privat gemeldet und am 12. behoben. Darüber hinaus hinterlässt der Angriff eine Protokollsignatur, nach der Tailscale suchen konnte, und gelangte zu dem Schluss, dass er auf den Proof-of-Concept-Test beschränkt war. Sie können Ihr eigenes Dashboard zur Bestätigung auf alle Knoten überprüfen, die von ihrem eigenen Tailnet aus geteilt werden. Und obwohl es sich um eine schlimme Schwachstelle handelt, ist es gut für Tailscale, sie offengelegt zu haben. Viele Anbieter hätten sich darauf verlassen und es nie öffentlich gemacht.

Das Der Linux-Kernel hatte einen Pufferüberlauf in seinem Netfilter-Code, wo ein Pufferüberlauf sowohl zu Datenlecks als auch zur Codeausführung führen könnte. Es gibt keinen Weg zur Remote-Ausnutzung, aber die oben verlinkte E-Mail enthält einen vollständigen PoC für eine lokale Rechteausweitung. Und wenn Kernel-Ausbeutung Ihr Ding ist, ist Googles Project Zero genau das Richtige für Sie ein neuer Artikel zu diesem Thema, alles über Null-Dereferenzierung.

Und wenn Sie ManageEngine von Zoho verwenden, kann es sein, dass Ihnen heute die Haare brennen, wenn Sie nicht auf die Version aktualisiert haben, die CVE-2022-47966 behebt. Forscher bei Horizon3 hat den Patch rückentwickelt, und verschüttete die Bohnen auf diesem RCE. Es stellt ein Problem bei der Implementierung des SAML-Single-Sign-On dar, was zum Teil auf eine extrem alte Bibliothek zurückzuführen ist, die als Teil des Produkts enthalten ist. Es ist ein ziemlich einfacher Exploit, also ist es an der Zeit, die Installationen noch einmal zu überprüfen!

Zeitstempel:

Mehr von Hacke einen Tag