Bufferoverflows über ein Netzwerk

Hackse

Hackse

0
Hallo,
ich habe in meiner Vergangenheit lokal Bufferoverflows entwickelt, konnte somit auf meiner eigenen Linux-Maschine Root-Rechte erlangen (insofern das SUID-Bit gesetzt war) und bekam somit eine Root-Shell.

Die Funktionsweise ist klar, ein schwaches Programm bekommt über einen String den Shellcode ?injiziert? und der Shellcode hat somit die Rechte des ?infizierten? Programms.

Der nächste Schritt wäre es so etwas über ein Netzwerk zu versuchen, nur wie?

O.k., ich schreibe einen kleinen Root-Daemon, der über einen Port über TCP Daten annimmt und bewusst keinen Range-Check ausführt und somit exploitable ist. Ich connecte mich nun von einem anderen Rechner zu diesem Daemon via TCP und sende ihm nun das Payload. Gut, nun ist der schwache Daemon zwar exploitet und führt bei sich lokal die Root-Shell aus, doch wie komme ich denn da über das Netzwerk ran? Das Ausnutzen von Sicherheitslücken meines Daemons über das Netzwerk ist nicht das Problem, ich kann über das Netzwerk einmalig beliebigen Code injizieren und ausführen, doch irgendwie bringt mich das methodisch nicht weiter. Sobald die injizierte Root-Shell ausgeführt wird, würde die TCP-Verbindung abbrechen und mein Payload war umsonst, denn ich bin ja nicht lokal am Rechner, sondern auf der anderen Seite des Netzwerks. Ich habe nun einen kleinen Dropper geschrieben, der über ein Netzwerk Befehle über einem bestimmten Port annimmt und diese Befehle lokal ausführt.

Was mir als Letztes fehlt ist jene Fähigkeit, die viele Trojaner und Würmer haben:
Ich müsste es schaffen über die bereits ausgenutzte Sicherheitslücke meinen Dropper auf dem Fremdrechner über das Netzwerk zu platzieren und dort auszuführen. Ich habe keine Ahnung wie meine Payload aussehen muss, damit sie meinen Dropper hinter sich herzieht, auf den exploited Host als Datei packt und dort lokal ausführt.

Was ist die gängige Methode von Exploits den Dropper auf dem exploited Host zu übertragen und auszuführen? ssh-Verbindung im Payload zum ?Angreifer? ausführen, Dropper nachladen via scp, ..., was am sinnvollsten tun?


Greetz
Hackse
 
Die gängige Methode von Exploits ist das Binden einer Shell an einen Port. Der Unterschied besteht also lediglich im verwendeten Shellcode, der dann eben nicht nur eine Shell/Eingabeaufforderung aufruft, sondern diese auch noch an einen freien Port bindet. Weitere Aufgabe lassen sich natürlich auch im Shellcode unterbringen wie z.B. das Runterladen eines Trojaners u.ä. Eine Suche bei Google nach 'portbinding shellcode' wird dir daher sicherlich genug Lösungsansätze bieten. Alternativ spielst du selbst einfach mal mit Shellcodes rum und bastelst dir eigene, die das machen, was du willst.
 
Hallo bitmuncher,
vielen Dank für Dein Posting. Modifikation des Payloads ist ein geringer Aufwand, das freut mich. Genau dieses Stichwort des "portbinding shellcode" habe ich gesucht. Vielen Dank. =)


Greetz
Hackse
 
Alternativ könntest du auch Parameter auf den stack laden, die auf einen auszuführenden String zeigen , und via return-to-libc dann exec[v[le]] auf diesen ausführen lassen.
Bzgl. der Payloads könntest du auch metasploit verwenden, die haben da einige fertige Shellcodes, allerdings ist da fast immer leider der Sourcecode nicht dabei und wenn man Geschichten wie einen NOP-Sled dazupackt, kann es schon mal passieren, dass die interne Adressierung des Shellcodes in sich kaputt geht.
 
@manace
z.B.Xp pro sp2 besitzt einen Protected Stack. wenn es eingeschaltet ist.
Da in der Vergangenheit zuviele Stackexploits aufgetreten sind geht man wieder dazu ueber den Stack zu schuetzen, u.a. auch mit einer not Execute flag im coditionCode.
Was ab neueren Prozessoren von Intel und Amd standard sein duerfte und von den Kommenden Generationen von OS unterstuetzt wird.
Wie dem auch sei.
Es were viel sicherer einen Heap-Exploit zu machen.dann hastdu weitreichendere Moeglichkeiten.
mfg

sw33t
 
Das weiß ich schon, aber zum einen hat hackse ja nicht bzgl. Windows gefragt und weiterhin arbeitet sie sich sowieso noch ein. Und ausserdem .. dann laden wir das halt in die Environment-Informationen :) und auch die Stackprotection kann man bis zu einem gewissen Grad umgehen. Es wird zwar um einiges schwieriger,aber momentan ist meines Wissens kein prinzipieller Schutz in Sicht. (Ich würde ja für SchadowStacks votieren, aber dafür müsste man die Prozessorleute in die Pflicht nehmen)
 
Das mit dem umgehen habe ich gar nicht gewusst, aber so wie sich das bei heisse anhoert ist das nicht leicht, naja, was ist das schon, aber das mit den Enviroment-Informationenen musst du mir mal erklaeren.
Willst du einen Exploit als Geraeteinformation tarnen oder sogar einen Port auf dem du anklopfst als externes Geraet deklarieren?
mfg

sw33t

p.s.:btw:
ein shadowstack das dauert noch, wer gibt schon von Neuman auf.
Abgesehen davon kann ich mir vorstellen das man auch da was dran fingern kann,
vor allem wenn es soetwas wie Embeded Formulare gibt, wie im Internet, wo man erst nach dem aufruf etwas laden muss damit man das Dokument anschauen kann, und wenn ich mich nicht irre muessten dann die Informationen doch auch ueber den Datastack in den Shadowstack geladen werden oder nicht?
 
Das mit dem umgehen habe ich gar nicht gewusst, aber so wie sich das bei heisse anhoert ist das nicht leicht,
Zum Vergrößern anklicken....
rein theoretisch (zumindest für Windows):

RET_to_libcaladresse, param1,param2,param3
braucht nicht ausgeführt zu werden - es wird zu einem Libcall(bzw API-Adresse) returnt, dieser kann die Parameter einlesen und macht das Gewünschte. Die Umsetzung und die Parameterplatzierung hängen natürlich von der Situation ab.

Zumidenst bei Windows produzieren Linker häufig sogenannte JMP-Tabellen:
JMP DWORD PTD [fester_Adressverweis_auf_IAT]
damit braucht man nicht mal die API-Adressen auf dem Zielsystem zu kennen/zu raten, falls im Programm selbst die nötigen API-Calls vorhanden sind, kann man sie nach diesem Muster nutzen.
RET_to_JMP_ADRESSE, param1,... ParamX
 
Mit ShadowStack meine ich, dass der Prozessor einen Stack vorhält, wo bloss Prolog/Epilog-Informationen wie EIP und EBP stehen.
Und bei jeder Manipulation dieser Stackadressen wird halt der richtige Stack mit seinem Schattenpendant in einer atomaren Funktion verglichen (am besten in ret selbst gleich). Dafür müsste man nicht das vonNeumannPrinzip ändern, nur den Prozessor "pimpen", was sie wegen Pipelining und Superskalarität und blafoo sowieso schon die ganze Zeit tun.

Mit "ins Environment laden" meine ich nur, dass man den Payload statt auf den stack ja auch dorthin laden kann" und die adresse davon nimmt, und das ausführen lässt.
 
^^thx
man lernt nie aus.
indie data strucktur zu schreiben habe ich noch gar nicht in betracht gezogen.^^
@manace....
ist die ansicht nicht ein bischen ....keine ahnung....trivial??
;)bitte nicht angepisst fuehlen nicht so boese gemeint wie es sich anhoert.
Denn wenn ich etwas auf den Stack schieben kann und er springt sowiso dahin bzw ich schreibe code auf den Stack der dann in den Heap schreibt, wo das Prog sowiso hinspringt dann muss ich die dinger ja gar nicht veraendern, und wenn das Programm den Shadowstack auch aendern kann dann kann man das von aussen doch auch erzwingen oder sehe ich da was falsch?
mfg

sw33t
 
der Punkt ist, dass keine echten Daten wie Puffer oder lokale Variablen auf den "Schattenstack" geschrieben werden, und somit kein Overflow möglich wäre. Aber der Test, ob der EIP (oder auch EBP) im Schattenstack und im normalen Stack gleich sind, müsste eben in einer atomaren Testfunktion geschehen (sowas wie ein testundsetlock für semaphore), die bei Erfolg zb ret ausführt und bei nicht erfolgt eine exception wirft.

Und genau deswegen wären hier die Prozessorhersteller gefragt. Weil die atomare Testfunktion müsste als Mikrocode/Befehl im InstructionSet des Prozessors auftauchen
 
Das ist mir schon klar, also das mit den Registerwerten im shadowStack und das das alles in Hardware gegossen werden muss, ich dachte dabei auch vielmehr an:
set normalebp = newebp
set shadowebp = normalebp

und das ganze dann fuer jeden der paar Werte im Shadowstack, aber egal, ist momentan sowiso nur ein Luftschloss^^.
thx

sw33t
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben