Wie kriege ich mit ROP einen "/bin/sh" Pointer in rdi?

Ich versuche, rücksprungorientierte Programmierung (ROP) zu lernen.

Und zwar habe ich ein Programm mit einem Pufferüberlauf auf dem Stack, und ich möchte das Programm dazu bringen, /bin/sh zu öffnen.

Das geht mit dem execve Syscall, wenn ich die richtigen Instruktionen finden kann, um die Funktionsparameter vorzubereiten. Das ist die Signatur von execve:

int execve(const char *pathname, char *const _Nullable argv[], char *const _Nullable envp[]);

Also muss ich die folgenden Register setzen:

  • rax = 0x3b (Syscallnummer von execve)
  • rdi = "/bin/sh" Pointer
  • rsi = NULL
  • rdx = NULL

Die folgenden Instruktionen habe ich bereits gefunden:

pop rax ; ret
pop rdi ; ret
pop rsi ; ret
pop rdx ; ret
syscall

Ich kann also die Instruktionen und Registerwerte mit dem Pufferüberlauf auf den Stack schreiben und so meine Register füllen. Das Problem ist aber, dass ich einen "/bin/sh" Pointer in rdi brauche (also nicht "/bin/sh" im Register, sondern eine Speicheradresse, an der "/bin/sh" steht).

Ich kann natürlich "/bin/sh" in den Puffer auf dem Stack schreiben, aber leider ist die Speicheradresse jedes Mal anders und ich kenne sie vorher nicht.

Ich weiß, dass "/bin/sh" in libc vorkommt, aber auch dort ist die Speicheradresse jedes Mal anders und ich kenne sie vorher nicht.

Wie komme ich also an einen "/bin/sh" Pointer? Gibt es Tricks oder bestimmte Instruktionen, nach denen ich mich umsehen sollte?

hacken, Hack, Programm, programmieren, pointer, Assembler, Hacker, Hacking, Informatik, IT-Sicherheit, Shell, stack, x64, assemblersprache, Assembly, Exploit, hacken lernen, IT-Sicherheitsexperte, Register, Capture The Flag
Hintertür in xz gefunden - Kann man überhaupt noch einer Software vertrauen, die man nicht selbst geschrieben hat?

xz ist ein unter Linux weit verbreitetes Datenkompressionsformat. Ein Entwickler der Referenzimplementierung xz-utils (https://github.com/tukaani-project/xz) hat vor kurzem eine Hintertür (CVE-2024-3094) eingebaut, mit der in manchen Linux Distributionen sshd kompromittiert werden kann. Bisher wurde noch kein CVE Score zugewiesen, aber ich schätze diese Hintertür als sehr kritisch ein. Bestimmt werden in den nächsten Tagen Heise, Golem, etc. darüber berichten, und vielleicht sogar die Mainstream Medien.

Die Hintertür wurde gefunden, weil der Schadcode Performanceprobleme in sshd verursacht hat. Glücklicherweise sind die betroffenen xz Versionen noch nicht weit verbreitet, da Pakete in vielen Distributionen nur sehr langsam aktualisiert werden. In Arch Linux wurde bereits eine betroffene xz Version ausgeliefert, aber da sshd in Arch Linux kein gz verwendet, ist ein Angriff in diesem Fall nicht möglich.

Dennoch ist dieser Vorfall äußerst besorgniserregend, da die Hintertür von einem xz Entwickler eingebaut wurde, der bereits mehrere Jahre am Projekt beteiligt war und als vertrauenswürdig galt.

Grundsätzlich galt Open Source Software als weniger anfällig für Hintertüren als Closed Source Software. Man ging davon aus, dass Hintertüren in Open Source Software gefunden werden, bevor sie überhaupt veröffentlicht werden, da der Code von vielen unabhängigen Experten überprüft wird. Ein häufig genanntes Beispiel, das diese These untermauern soll, ist ein 2003 gescheiterter Versuch, eine Hintertür in den Linux Kernel einzubauen.

Der aktuelle Vorfall zeigt, dass es sehrwohl möglich ist, Schadcode unentdeckt in weit verbreitete Open Source Software einzubauen. Dies wirft die Frage auf, inwieweit man fremder Software überhaupt noch vertrauen kann.

Seid ihr selbst von dieser Hintertür betroffen? Wie schützt ihr euch? Habt ihr Zweifel an der Sicherheit von Open Source Software? Denkt ihr, dass dieser Vorfall zu einem Umdenken bei der Vertrauenswürdigkeit von Open Source Entwicklern führen wird?

Weitere Informationen
  • https://lwn.net/Articles/967180/
  • https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlxgzm@awork3.anarazel.de/
  • https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094
  • https://archlinux.org/news/the-xz-package-has-been-backdoored/
  • https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/
  • https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Computer, Software, Linux, Sicherheit, IT, Backdoor, Code, Hacker, Hackerangriff, Informatik, IT-Sicherheit, Open Source, Softwareentwicklung, ssh, Vertrauen, Vertrauensbruch, Exploit, Exploits, IT-Sicherheitsexperte, Schwachstellen, vertrauenswürdig, sshd
Bildschirm flackert?

Ich spiele gerne Roblox und da manche Spiele mit der Zeit langweilig werden habe ich mich entschieden Krnl (= ein Programm das Softwarefehler verwendet um Anwendungen von Drittanbietern in Roblox einzuschleusen) herunterzuladen und ein bisschen zu exploiten.

Ich habe einen Script gefunden der mir eine Ak-47 in allen Spielen gibt doch irgendwas ist da schiefgegangen. Nachdem ich den Script ausgeführt habe hat mein Bildschirm sozusagen angefangen zu flackern. Jedoch hat es überhalb des Cusors geflackert und unterhalb war es einfach nur Schwarz.

Als Beispiel: Ich bin in einem Roblox Spiel und habe den Cusor in der Mitte meines Bildschirms. Nun ist es so das überhalb des Cusors (also die obere hälfte) flackert und unterhalb (also die untere hälfte) einfach schwarz ist.

Das Prinzip passiert nun bei allen Waffen die den gleichen Script haben. (ich weiß nicht ob ich Script sagen kann, aber aufjedenfall meine ich sowas wie "waffen die so ähnlich sind in jegliche anderen Roblox Spielen)

Ebenso habe ich schon versucht die Grafik zurückzusetzen mit dieser Tastenkombination aber es hat nix gebracht. Vielleicht hat dieser Script ja was in den Roblox Datein verändert. Wobei ich das unglaubwürdig finden würde.

Zu letzt sollte ich noch erwähnen das ich einen Laptop habe. Ein ASUS VivoBook 17

PC, Technik, Bildschirm, System, cheaten, Gaming, Roblox, Asus-Laptop, Exploit, flackernder-bildschirm, Laptop
Wie SIM-Karte ohne PIN und/oder PUK auslesen?

Folgendes Problem. Ich besitze seit circa 7 Jahren eine Prepaid basierte SIM-Karte. Letzte Woche habe ich versehentlich meinen PIN dreimal falsch eingeben. Worauf verständlicherweise die Eingabe des PUK folgte. Genau dieser ist nicht mehr auffindbar und meiner Vermutung nach beim Umzug abhanden gekommen.

Darauf hin habe ich beim Provider angerufen, meine Situation geschildert und gehofft so meine Karte wieder freischalten zu können. Jetzt das eigentliche Problem. Ich weiß nicht mehr auf wessen Namen die Karte damals registriert wurde. Aus Datenschutzgründen bekomme ich natürlich auch keine näheren Informationen. Auf ein Ratespiel sich der Provider ja nicht einlässt. Genau da liegt jetzt der Hund begraben.

Das größte Problem das ich jetzt habe, das ich an all die Nummern die auf dieser Karte gespeichert wurden, nicht mehr zugreifen kann. Wenn die Nummer selbst pfutsch ist, ok. Wenn ich die Karte nicht weiter nutzen kann. Ärgerlich aber verkraftbar. Aber die Nummern sind für mich immens wichtig. Zahlreiche Nummern von Kunden und Geschäftspartnern aus dem In und Ausland sind darauf hinterlegt.

Wie kann ich also den PUK ohne Mitwirken des Providers umgehen? Ich habe hier diverse Devices (Handys, Smartphones und Tablets) mit Android, iOS und Windows Phone liegen. Mich jedoch mit Exploits und der Gleichen nicht sonderlich befasst habe. Wünschenswert wäre ein Kon-Boot Pendant für mobile Geräte. Wobei ja die Karte selbst durch den PUK und nicht das Device an sich geschützt ist.

Jemand irgendwelche Lösungsansätze parat?

Handy, Smartphone, Provider, SIM-Karte, PIN, PUK, Exploit

Meistgelesene Fragen zum Thema Exploit