Bufferoverflow erzwingen

Er hat einfach keine Ahnung dass ist das Problem.

Bassmaster schrieb:

Hallo, willst du nur DDOS oder auch Remote Code Execution?
Btw. das Problem was du gerade hast das hatte ich mal unter Windows mit einem Server.

Ich hab gerade kein Linux hier um rumzutesten, aber schau mal auf: www.trapkit.de da gibt es von Tobias Klein eine Sammlung von Code Beispielen und da gibts auch ein Beispiel zu Remote Bufferoverflows.

Ich möchte Remote Code ausführen!

Davor aber sollte ich ja die EIP überschreiben und an dem scheitert es gerade leider mit dem obigen Code

Aber danke für Link werde ich mir gleich anschauen! Ich glaube DirkB hatte recht das der Compiler "msg" nicht nutzt.

Dazu noch einige Anmerkungen:
a) Was willst du zeigen?
b) Was erwartest du denn fuer einen Fehler?

Du schreibst einfach Stackspeicher voll. der ist eben so gross, wie das Betriebssystem festlegt, das kann schon mal 1 MByte oder mehr sein. Um die Ruecksprungadresse zu ueberschreiben, solltest du dir mal den ASM-Code ansehen, vielleicht ist die Funktion automatisch inline. Hinzu kommt die default-Einstellungen deines Kompilers, vielleicht ist -O3 normal.

OK danke muss mal schauen was die default Einstellung bei mir ist.

So habe das jetzt mal mit Optimierung und ohne versucht.

Mit Optimierung:

gcc -O1 -fno-stack-protector -z execstack -o server server.c

Programm läuft weiter aber kommt Meldung

*** buffer overflow detected ***: ./server terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xb7754390]
/lib/tls/i686/cmov/libc.so.6(+0xe12ca)[0xb77532ca]
/lib/tls/i686/cmov/libc.so.6(__strcpy_chk+0x44)[0xb7752644]
./server[0x8048789]
./server[0x8048819]
./server[0x8048a41]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7688bd6]
./server[0x8048681]
======= Memory map: ========
08048000-08049000 r-xp 00000000 08:05 2762247 /root/Desktop/exploit/exploit/remote/server
08049000-0804a000 r-xp 00000000 08:05 2762247 /root/Desktop/exploit/exploit/remote/server
0804a000-0804b000 rwxp 00001000 08:05 2762247 /root/Desktop/exploit/exploit/remote/server
093b5000-093d6000 rwxp 00000000 00:00 0 [heap]
b7640000-b765d000 r-xp 00000000 08:05 4980823 /lib/libgcc_s.so.1
b765d000-b765e000 r-xp 0001c000 08:05 4980823 /lib/libgcc_s.so.1
b765e000-b765f000 rwxp 0001d000 08:05 4980823 /lib/libgcc_s.so.1
b7671000-b7672000 rwxp 00000000 00:00 0
b7672000-b77c5000 r-xp 00000000 08:05 5113153 /lib/tls/i686/cmov/libc-2.11.1.so
b77c5000-b77c6000 ---p 00153000 08:05 5113153 /lib/tls/i686/cmov/libc-2.11.1.so
b77c6000-b77c8000 r-xp 00153000 08:05 5113153 /lib/tls/i686/cmov/libc-2.11.1.so
b77c8000-b77c9000 rwxp 00155000 08:05 5113153 /lib/tls/i686/cmov/libc-2.11.1.so
b77c9000-b77cc000 rwxp 00000000 00:00 0
b77dd000-b77e0000 rwxp 00000000 00:00 0
b77e0000-b77e1000 r-xp 00000000 00:00 0 [vdso]
b77e1000-b77fc000 r-xp 00000000 08:05 4980766 /lib/ld-2.11.1.so
b77fc000-b77fd000 r-xp 0001a000 08:05 4980766 /lib/ld-2.11.1.so
b77fd000-b77fe000 rwxp 0001b000 08:05 4980766 /lib/ld-2.11.1.so
bfec3000-bfee4000 rwxp 00000000 00:00 0 [stack]

und ohne:

gcc -O0 -fno-stack-protector -z execstack -o server server.c

Programm arbeitet weiter ohne irgendeine Meldung...

knivil

Wie ueberpruefst du, dass dein Bufferoverflow erfolgreich war?

knivil schrieb:

Wie ueberpruefst du, dass dein Bufferoverflow erfolgreich war?

Mit gdb und dem erstellten Core.

Aber in diesem Fall wird keine Core Datei erstellt, also gehe ich davon aus das es kein Bufferoverflow gab bzw. keine überschrieben Return-Speicheradresse.

Bassmaster

DKlay schrieb:

Mit gdb und dem erstellten Core.
Aber in diesem Fall wird keine Core Datei erstellt, also gehe ich davon aus das es kein Bufferoverflow gab bzw. keine überschrieben Return-Speicheradresse.

Ich glaub du solltest dir nochmal ein paar Sachen durchlesen und das ganze erst mal Lokal machen ...

Versuch dich mal hierdran:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int bof(char *string) {
  char buffer[1024];
  strcpy(buffer, string);
  return 1;
}
int main(int argc, char *argv[]) {
  bof(argv[1]);
  printf("Done..\n");
  return 1;
}

Ich habe dir auch noch ein paar PDF Dateien zu dem Thema Bufferoverflow hochgeladen: http://www.pixelbanane.de/yafu/1151877281/overflows.rar

Das Code Beispiel was ich gepostet habe ist aus dem PDF 273.pdf da wird schritt für schritt alles erklärt.

Btw. hier findest du auch noch Lesematerial:

http://www.phrack.org/issues.html
http://www.exploit-db.com/
http://back2hack.cc/

Ja Lokal habe ich das auf diese Art schon gemacht und Erfolgreich.

Aber mit Sockets und Remote gehts nicht, weswegen ich nicht verstehe wieso.

Aber Danke für Upload...vielleicht kommt ja doch jemand auf die Lösung dieses Problems

knivil

Mit gdb und dem erstellten Core.

Was ist ein Core? Oder meinst du Coredump? Whatever ... hast du dir den Asm-Code angesehen?

knivil schrieb:

Mit gdb und dem erstellten Core.

Was ist ein Core? Oder meinst du Coredump? Whatever ... hast du dir den Asm-Code angesehen?

Ja klar Coredump, aber mit asm und reverse engineering habe ich mich nicht beschäftigt. (Sollte Vorraussetzung sein, ich weiss).

Aber das sollte erstmal nicht das Problem sein, eigentlich müsste dieser Code zum BOF führen...aber warum auch immer überschreibt er die EIP bzw RET adresse nicht...und das liegt wahrscheinlich an einer Compiler option evtl. in Verbinung mit Sockets ich habee keine Ahnung und dachte einer von euch könnte mir weiterhelfen.

Shellcode und der Rest sollte danach kein Problem sein.

Bassmaster

Schau dir mal den Puffer genau an.

- Was steht genau im Puffer?
- Wo im Puffer steht die Rücksprungadresse welche du überschreiben willst

Beispiel:

( 41 Hex = A )

Stack: Daten
0x10EE00 41 41 41 41
0x10EE04 41 41 41 41
0x10EE08 41 41 41 41
0x10EE0C 41 41 41 41
0x10EE10 41 41 41 41
0x10EE14 41 41 41 41
0x10EE18 41 41 41 41 <-- ESP RETURN zum Hauptprogramm
0x10EE1C

Jetzt zähl einfach wie viele Bytes du brauchst um die Rücksprung Adresse zu überschreiben, oder rechne es aus geht ja auch. ^^

Ich persönlich mag den gdb nicht Reverse Engineering mit so Konsolen Debuggern is nicht so mein Fall.

Mit einer GUI ist das meist doch leichter, schau dir mal IDA Pro. Vielleicht fliegt dir das ja über google zu ganz zufällig zu. (das Programm ist schweine teuer [aber auch gut] )

Aber ich denke mal es gibt auch kostenlose GUI Debugger für Linux. Mit gdb geht das natürlich auch alles aber da ist es nicht so übersichtlich. (Meine Meinug)

Du musst dir auf jedenfall 100% im klaren sein wie das mit den Bufferoverflows funktioniert sonst ist das echt zum verzweifeln.

(Oh jetzt geht nice, ich experimentier noch ein bisschen mit dem Puffer rum, omg jetzt gehts wieder nicht. ) Die Erfahrung musste ich machen. -.-

Ah da fällt mir gerade wieder was ein:

http://tut0r1al.back2hack.cc/bufferoverflows/bufferoverflow-workshop/

Cheese aus dem Back2Hack Forum hat mal irgendwan einen Workshop zu dem Thema gemacht lad dir das Video einfach mal runter. (Ich hab den Workshop bisher noch

nicht angeschaut also ka wie gut oder schlecht der ist ich weiss nur das die
Leute aus dem Forum zufrieden waren von daher denke ich das es passt.
[Wobei die Leute auf Amazon auch mit den Jürgen Wolf Büchern zufrieden sind ...]

Hier noch ein sehr gutes Tutorial von Vivek Ramachandran (Security Researcher).
Ich denke mal das ist schon Qualitativ sehr gut da der Typ auch Vorträge auf der DefCon gehalten hat ich denke mal der weiss wovon er redet.

http://www.vivekramachandran.com/
http://www.securitytube.net/groups?operation=view&groupId=4

So ich glaube ich bin dem Problem jetzt etwas näher gekommen. Es liegt wohl an der while() schleife.

Das Programm erreicht nie das Ende.

Danke trotzdem für die Hilfe !!!!!!!!!1111

Bassmaster

Normalerweise sollte es beim verlassen der Funktion display_msg crashen.
Irgendwie hab ich da so das Gefühl das da noch irgendein Schutz Mechanismus von Linux mitläuft. Eventuell könntest du das alles auch mal mit einer uralten Linux Version testen nur um sicher zu gehen.

int display_msg( char *s ) 
 { 
     char msg[128]; 
     strcpy(msg, s); 
     //sprintf(msg, "[RECV]: Size: %d -> %s", strlen(s), s); 
     printf("[RECV]: %s\tSize: %d\n", msg, strlen(msg)); 
     return 0; 
 }

Bassmaster schrieb:

Normalerweise sollte es beim verlassen der Funktion display_msg crashen.
Irgendwie hab ich da so das Gefühl das da noch irgendein Schutz Mechanismus von Linux mitläuft. Eventuell könntest du das alles auch mal mit einer uralten Linux Version testen nur um sicher zu gehen.
int display_msg( char *s ) 
 { 
     char msg[128]; 
     strcpy(msg, s); 
     //sprintf(msg, "[RECV]: Size: %d -> %s", strlen(s), s); 
     printf("[RECV]: %s\tSize: %d\n", msg, strlen(msg)); 
     return 0; 
 }

Du hast recht eigentlich müsste es beim Verlassen der Funktion crashen, so habe ich es mir aufjedenfall gedacht, aber mit dem Code nicht...Könnte es sein das Sockets in einem eigenständigen Thread laufen??