[es] - Remote non-exec stack exploiting... HELP :)

LiquidBrain

Član broj: 33502
Poruke: 28
*.041net.co.yu.

Sajt: www.sdwifi.co.sr

Profil

Remote non-exec stack exploiting... HELP :)

^{09.02.2006. u 19:44 - pre 233 meseci}

Poz ljudi,
opet ja sa nekim pitanjima

LoL

dakle evo shta me muci.... Zaobilazenje non-exec stack-a. To jest. exploitovanje buffer overflowa na sistemu koji ima non-exec stack. Da ali nije to sve... znam kako da to uradim lokalno, ali remote???
E aj sad.

xex...

mislim ona prica o

Code:

export ARGUMENT="/bin/sh"

pije vodu samo kod lokalnih exploit-a. A shta sa remote, kako dati parametar system(), ili execl() funkciji...

Jel tu moze da prodje neka fora sa format stringovima, kao ona vatrijanta za NULL bajtove.... Ono da ne duzim, jel ima neki link za to ili ako nema, jel moze neko da da neke upute...

Thanks

You don't want to learn, then stick this keyboard in your ass!

Odgovor na temu

fearless

Član broj: 74584
Poruke: 156
212.62.59.*

Sajt: www.phearless.org

Profil

Re: Remote non-exec stack exploiting... HELP :)

^{09.02.2006. u 21:10 - pre 233 meseci}

Pitao sam se istu stvar davno, ali sam vremenom odustao jer su se isprecile neke druge stvari :)
Jedino sto sam sada dobio iz desetosekundnog googlanja je malo ideja na fulldisclosure:

Citat:

As it turned out, we dont need to know exact address of function
argument to remote exploit using ret-into-libc method! But i still dont know
the method to remote finding address of function in libc. One thing that has
occured to me is remote fingerprinting and checking on box with the same
OS and architecture. And there is still unsolved issue of compiler used to
compile vulnerable program ;-) But this is not man topic of that article, it only
shows next step to remote exploiting using returning into libc function method
(ret-into-libc).

Nije mnogo, ali je bar nesto :)

P.S. Drago mi je da se pojavljuju normalne teme na ovom forumu, polako ali sigurno

_{[Ovu poruku je menjao fearless dana 09.02.2006. u 22:17 GMT+1]}

Phearless - Serbian/Croatian Security Magazine: www.phearless.org

Odgovor na temu

EArthquake

Član broj: 20684
Poruke: 884
*.icentrala.net.

+67 Profil

Re: Remote non-exec stack exploiting... HELP :)

^{10.02.2006. u 00:12 - pre 233 meseci}

prvo sto meni pada na pamet ,
ako vec hoces da koristis argument , koristi vec postojeci

tj $SHELL environment varijablu ,

opet , nalazenje njene adrese nije baS trivijalan zadatak remote
ali je moguce , isto kao i nalazenje adresa u libc

drugo sto mi pada na pamet, da koristis slicnu foru kao za frame fakeing i pisanje null bajtova
dakle printf , ali opet nisam siguran da li to moze tako ,
a verovatno mozes i argumente da stavljas u sam baffer , ali to inda umesto adrese environment varijable treba adresa tog dela na stacu , kao kod klasicnog eksploatisanja bez environment varijable

anywayz , sad je prilicno kasno a ja radim jes neke poslove trentutno pa izvini na skrtom odgovoru

interesantna tema , videcu sutra da dopunim odgovor
i meni je drago da ima nesto pametno na ovom forumu :)
fearless , nije sve izgubljeno :)

ajd pozdrav
Aca

Odgovor na temu

DownBload

Član broj: 1333
Poruke: 310
*.cmu.carnet.hr.

Profil

Re: Remote non-exec stack exploiting... HELP :)

^{10.02.2006. u 09:48 - pre 233 meseci}

Kod takvih situacija najbolje je probati napraviti neki memory leaking...npr
imas situaciju...

func (int sock, char *arg)
{
int len=256;
char buf[256];

strcpy (buf, arg);
send (sock, buf, len);
}

Umjesto da odmah krenes u overflowanje EIP-a, probaj overflowati
samo len varijablu, tak da ti funkcija send() posalje veci dio stack-a.
Ta fora je koristena u BIND TSIG exploitu od LSD-pl ekipe.

Fora broj 2...ima fora da overflowas EIP sa vrijednostima koje "vode"
do glibca....svaka pogresna vrijednost ce srusiti program i vjerojatno
neces dobiti nikakav odgovor od servera...no kad pogodis taj prvi
simbol koji exporta glibc i program se ne srusi, prema njemu (kao bazi za offset)
je lako odrediti adrese ostalih funkcija tipa system(), execl(), etc.
Imas jedan dobar paper o ovoj tehnici...al se vise ne sjecam kak se zove.

Pozdrav..

Leon Juranic

Odgovor na temu

LiquidBrain

Član broj: 33502
Poruke: 28
*.041net.co.yu.

Sajt: www.sdwifi.co.sr

Profil

Re: Remote non-exec stack exploiting... HELP :)

^{10.02.2006. u 15:27 - pre 233 meseci}

Citat:

DownBload: Kod takvih situacija najbolje je probati napraviti neki memory leaking...npr
imas situaciju...

Code:

func (int sock, char *arg)
{
int len=256;
char buf[256];

strcpy (buf, arg);
send (sock, buf, len);
}

Umjesto da odmah krenes u overflowanje EIP-a, probaj overflowati
samo len varijablu, tak da ti funkcija send() posalje veci dio stack-a.
Ta fora je koristena u BIND TSIG exploitu od LSD-pl ekipe.

eh, ovo mi izgleda zanimljivo.... Da li mislish da nakon toga mogu da izracunam adrese potrebne za pozivanje system() funkcije? Jel ima neki doc o tome?

Trenutno pokusavam da provalim na koju foru radi command padding (iliti link koji je prosledio fearless)

Citat:

EArthquake: prvo sto meni pada na pamet ,
ako vec hoces da koristis argument , koristi vec postojeci

tj $SHELL environment varijablu ,

opet , nalazenje njene adrese nije baS trivijalan zadatak remote
ali je moguce , isto kao i nalazenje adresa u libc

Ajde EArthquake, pliz daj josh neki info oko pronalazenja adresa, poshto sam skoro provalio kako radi ovaj command padding, pa josh racunanje adresa i imam savrshen exploit

))

Mozda posle sve to i sumiram u neki paper...

ae poz!

You don't want to learn, then stick this keyboard in your ass!

Odgovor na temu

EArthquake

Član broj: 20684
Poruke: 884
*.icentrala.net.

+67 Profil

Re: Remote non-exec stack exploiting... HELP :)

^{10.02.2006. u 15:29 - pre 233 meseci}

da , memory leaking ti je put do pouzdanih eksploita
slicno kao kad koristis fmt string bugove da bi dobio delove memorijje

sad sam se setio jedne stvari , nije bas nesto prepametno al je vredno pomena

fora mi je jako interesantna bila

doduse radila bi samo u slucaju da je singletreathed deamon i da mu je parent proces bash tj neki shell

to je izikova fora , objavio je na svom sajtu skorije
anywayz
poenta je da pomocu getppid dobijes PID parental procesa , u slucaju da je to bash naravno
zatim execve("/proc/<pid>/exe", ["/proc/<pid>/exe", NULL])

and there you go , ali opet problem je postavljanje staze za proc i sl
jos ako je chrooted sistem ...

naravno ,izik je napisao shellcode
http://www.tty64.org/code/shel...linux-x86-src/getppid-execve.s
http://www.tty64.org/code/shellcodes/linux-x86/getppid-execve.c

verovatne nece pomoci ova ideja ali mije bila jako interesantna pa sam hteo da je pomenem , da vidim sta ostali misle:)

ups , tek sad videh tvoj post Liquid

pa jedan od nacia jeste da radis fingerprint platforme i da
vidis lokalno za tu distribuciju adrese ...
sanse su da ce aadrese biti na istom mestu na istoj distribuciji

secam se da su mi na svim instalacijama slackware-a
adrese exit() u glibcu imale istu adresu , zapamtio zbog NULL bajta u adresi :)

pozdrav

Aca

_{[Ovu poruku je menjao EArthquake dana 10.02.2006. u 16:32 GMT+1]}

Odgovor na temu