Изпечатай

[ANTIADMIN]

myecho не беше пуснато в началото, даже и nmap. Имаше portmap и atd, което ме заблуди. После пусна myecho, което се виждаше ясно през nmap, който също беше пуснат в последствие. Поне според моите наблюдения, което е донякъде нелогично '>
gdb /bin/myecho
run
disas main
Беше моят вял опит да намеря големината на буфера и след това случайни, преписани команди на perl, но дотам '> То не става само с ядене и пиьене, трябва и акъл '>

[VladSun]

Големината на буфера и само с ръчни проби можеш да установиш '>

А намери ли

 jmp    *%esp

инструкция?

ПП: http://milw0rm.com/shellcode/1734
е ОК

[gat3way]

Принципно myecho се форк-ва когато някой се върже на съответния сокет на inetd. От друга страна - да, nmap го инсталирах малко по-късно, защото реших, че някой може да го ползва.

Що се отнася до твоят опит...

Цитат

(gdb) disas main Dump of assembler code for function main: 0x08048422 <main+0>:    lea    0x4(%esp),%ecx 0x08048426 <main+4>:    and    $0xfffffff0,%esp 0x08048429 <main+7>:    pushl  -0x4(%ecx) 0x0804842c <main+10>:   push   %ebp 0x0804842d <main+11>:   mov    %esp,%ebp 0x0804842f <main+13>:   push   %ecx 0x08048430 <main+14>:   sub    $0x4,%esp 0x08048433 <main+17>:   call   0x8048404 <####> 0x08048438 <main+22>:   movl   $0x0,(%esp) 0x0804843f <main+29>:   call   0x804833c <exit@plt> End of assembler dump.

Мммм очевидно единственото, което прави main() е да викне ####() и да приключи изпълнението си. Та трябвало е да пробваш disas #### '>

Цитат

Dump of assembler code for function ####: 0x08048404 <####+0>:    push   %ebp 0x08048405 <####+1>:    mov    %esp,%ebp 0x08048407 <####+3>:    sub    $0x48,%esp 0x0804840a <####+6>:    lea    -0x32(%ebp),%eax 0x0804840d <####+9>:    mov    %eax,(%esp) 0x08048410 <####+12>:   call   0x804830c <gets@plt> 0x08048415 <####+17>:   lea    -0x32(%ebp),%eax 0x08048418 <####+20>:   mov    %eax,(%esp) 0x0804841b <####+23>:   call   0x804832c <puts@plt> 0x08048420 <####+28>:   leave 0x08048421 <####+29>:   ret

Където по-интересното е:


0x0804840a <####+6>:    lea    -0x32(%ebp),%eax
0x0804840d <####+9>:    mov    %eax,(%esp)
0x08048410 <####+12>:   call   0x804830c <gets@plt>


Ако човек знае параметрите на gets() (един параметър - низ) тогава може да се замисли какво става:

1) Стека се "измества" с 0x32 байта. Това в десетична бройна система прави....хм, не знам '> В тези 0х32 байта се съхранява параметъра на функцията gets()
2) Извиква се gets()


Та очевидно не си бил много далеч. И това е един (не бих казал най-лесния де) начин да разбереш големината на буфера '>

[VladSun]

Цитат (gat3way @ Юли 30 2008,14:27)

####()

Очевидно цензурата във форума работи  

[gat3way]

'>

[zeridon]

но пък за сметка на това става по интересно :П

[gat3way]

Оф, видяло се е че ще се разказва '>

Значи при 32-битовите x86 архитектури има определен набор от инструкции и процесорни ресурси. Тези ресурси се наричат регистри, побират 32 бита данни (4 байта) и се използват за временно съхранение на данни. Такива регистри са EAX, EBX, etc etc. Същевременно, с оглед на реализирането на разни подфункции се налага по някакъв начин хардуерно да се реализират LIFO (last-in-first-out) структури. Това е защото може да имаш извикване на подфункция от подфункция, при което някъде на удобно място трябва да се пазят данни, свързани с "предишната" функция. Тази структура се нарича "стек". Съответно има инструкции PUSH/POP с които се пъхат/вадят данни в/от стека.

Сега преминаваме на това как изглежда един процес в паметта. Всеки процес си има свой "изглед" към физическата памет (РАМ+суоп). За процеса, това е непрекъснат регион от памет, който се адресира линейно (адресите са от 0х0000000 до 0xffffffff). Ядрото има грижата да мап-ва паметта на процеса върху реалната физическа такава и как става това е една много дълга и сложна работа, която не е предмет на тази лекция (а и аз не съм компетентен лектор) '>

Адресното пространство на един процес понастоящем изглежда така:

0х00000000 (начало)--------------------------------
I
I0x0804000 (програмен код, статични променливи, library функции)
I
--------------------------------
I
I   HEAP (динамично заделена памет)
I
---------------------------------
I/////////////////////////////////////
I////////(свободна памет)//
I/////////////////////////////////////
-----------------------------------
I  Стек (расте нагоре)
-----------------------------------
I [vdso] - новост от 2.6 - допълнителен код, свързан с рандомизацията на адресното пространство
I
0xffffffff---------------------------------------------------------(край)

Общо 4 гигабайта адресно пространство.


Сега за стека: използват се 2 процесорни регистъра (ESP, EBP), които пазят адреса съответно на началото на стека и на отместването (т.е адреса на последния елемент в него). Нещо много важно - при всяко извикване на функция, в стека се "пъхат" освен параметрите, които функцията връща, също и адреса на който програмата трябва да продължи изпълнението си след завършването на тази функция. Съответно, когато се срещне RET инструкция, този адрес се "вади" от стека и се прескача на този адрес. Също така понеже всяка функция може да има различни параметри и всяко такова "напъхване" в стека може да вкарва различен обем данни в него, в стека се "пъха" и последната стойност на EBP (която се въстановява след края на функцията).

Трябва да се помни, че стека расте обратно, т.е следващите елементи напъхани в него ще са с по-"нисък" адрес.

Значи как изглежда нашият стек (извиквайки функцията gets()):

<край-EBP сочи тук>***(големина на буфера)*****<"стар" EBP><return addr><начало-ESP сочи тук> ------->...край на адресното пространство

Нашата цел е да презапишем буфера с данни по начин по който да "замажем" return addr така че след изпълнението на gets() изпълнението да продължи на място където ние искаме. Това е мястото, където разполагаме шелкода (изпълняващ шела).

Как изглежда успешно "замазания" стек? Ей така:

<край-EBP сочи тук>***(ПЪЛНЕЖ)*****<"стар" EBP (ЗАМАЗАН)><return addr (ТАКА ЧЕ ДА СОЧИ КЪДЕТО ТРЯБВА)><начало-ESP сочи тук, това е адреса, който ни трябва>SHELLCODE ------->...край на адресното пространство/

Сега сигурно някой се чуди няма ли да е най-добре да дебъгнем програмата с gdb, да видим стойността на ESP и да я използваме за return адрес. Ами допреди 2.6 това беше добра идея, сега не е. И това е защото вкараха известно "рандомизиране" на адресното пространство. Т.е стойността на ESP ще бъде различна при всяко изпълнение на програмата и вместо да скочим на нашия шелкод, ще скочим някъде на майната си.

Как се оправяме с това? За щастие злите хакери са открили, че във всички binary-та изпълнени на 2.6, ELF loader-а вмъква определен код на една и съща локация на края на адресното пространство ([vdso], linux-gate.so, etc). Оказва се че в този код някъде съществува винаги една и съща стойност \xff\xe4 (на асемблер преведено - JMP ESP). И това винаги се намира на един и същ адрес. Значи какво става ако използваме този адрес за нашия хакерски return adres?

Изпълняваме програмата, тя вика gets(), препълваме както трябва буфера с нашия return address и шелкод и се случва следното:

1) gets() завършва когато въведем "лошия" низ и изпълнението се прехвърля на нашият "хакерски адрес" който се намира след началото на стека (в обратна посока).
2) На този адрес има последователност, идентична с инструкцията JMP ESP. Изпълнението на програмата се прехвърля на адреса-начало на стека.
3) Там пък се намира нашия зъл shellcode. Бух! spawn-ва се шел. Ако програмата, която чупим се е изпълнявала с по-високи привилегии (както в случая daemon), значи имаме и шел с такива привилегии.

....ииии тук някъде ми писна да се правя на лектор щото ме заболяха пръстите '>


Уф мамка му сигурно някои неща звучат малко странно, просто проблемът е че стекът расте в обратна посока на адресното пространство и логически ми е трудно да пояснявам кое и защо. И да, EBP не сочи края на стека, а последния stack frame, но не искам да пояснявам и това, просто в случая няма значение, приемаме че EBP не е интересен регистър и ненужно много ще се усложни цялата тарапана ако трябва да го вземаме предвид'> Така че ако има забележки по отношение на това ще ги приема без възражения '>

[ANTIADMIN]

Стека не вади ли обратно нещата писани в него, по-точно временно вкарани и затова расте към ниските стойности и намалява към високите? А това с регистрите може да се научи само с асамблер, не че аз знам, но това е много общо казано/горната лекция/ и който не разбира/някой като мен/ и без това няма да му свърши работа Все пак поощрително ДА, за труда. Не се сещам как беше точно лафа от мюзик айдъл.
Иначе на асемблера си имаше точно в кой регистър кви дани се пущаха, ма то с тея пайтъни, рубита, луа луа и други такива извращения, не останаха сериозни хора, за да ни обяснят '> Кой учи асамблер в днешни дни?

[gat3way]

Стекът вади наобратно нещата, затова е LIFO структура '> Обаче никой не е казал, че трябва да расте наобратно, всъщност това е решение, взето за масово използваните архитектури, въпреки което при някои не расте наобратно '> Това са неща, мислени дълго преди въобще да имам идея за какво иде реч, така че нямам право да протестирам '>

Що се отнася до регистрите и какво се "тъпче" в тях, няма нещо което изрично да казва какво "да" и какво "не". Има естествено някакви общоприети неща (ECX примерно много често се използва като брояч в цикли), има и линукско API (който се е занимавал със системно програмиране под DOS сигурно има ясна идея - само че под линукс прекъсването е int 80h, не 21h, иначе идеята е много сходна '> ).

Аз от асемблер не разбирам. В смисъл, да - имам идея за някаква част от instruction set-а, занимавал съм се много отдавна, но и не - не бих казал че разбирам. Между другото, не ти трябва да знаеш асемблер, за да минеш тази задача, определено. Ще помогне най-вероятно, но само толкова. Решението на първата задача може да бъде само една шел команда и нито ред на C, още повече пък на асемблер '>

В днешни дни кой пише на асемблер...ммм разни хардуеристи, писачи на фърмуер предполагам, не знам '> Нормално е да се ползват езици от високо ниво де '> Някога С и Паскал се водеха такива езици '>

А, да - учи се все още. Студентите в техническите ВУЗ-ове, специалност КСТ доколкото знам ги мъчат с това '>

[gat3way]

Както и да е - за да стане по-интересно ще ви кажа, че примерно много популярния vmsplice експлойт като идея има доста общо с тази задача. Там разбира се нещата са доста различни и доста по-сложни, но идеята изначално е сходна - системното извикване  vmsplice() подобно на функцията gets() е глупаво и не проверява големината на това, което му се подава. Като резултат, злият хахор презаписва някаква памет с нещо, което е под негов контрол. Там пак има shellcode, но същият е малко по-различен с оглед на това, че се изпълнява от самото ядро '> И разбира се веригата на случките е по-дълга и по-забавна от нашият случай където прескачаме на адрес с jmp esp и оттам на нашия шелкод, но като цяло, идеята е до немалка степен сходна '>

[VladSun]

Ех ...
Очаквах някои хора от форума да се запалят по играта ...
Визирам отявлени дейци като  zeridon, Hapkoc, tarator, task_struct и др. (поне за тези, които знам, че имат опит със C)

[task_struct]

Аз сега виждам, че има втори кръг  '> Голяма съм блейка  
Попринцип ми е интересно, но нямам време '> , а и не си падам по хакването  '>

Иначе темата е доста интересна  и незнам как zeridon не се е включил. Помня, че от доста време имаше идея за такава игра '>


П.С. Събирате ли се още в Кривото да мина да ви видя някоя вечер '>

[gat3way]

Да, и аз съм разочарован малко. Особено от това, че lkr май се отказа, а се справяше добре '>

[lkr]

Второто ниво не ме заинтригува чак толкова, колкото първото, а ми и писна да ровя '>

[nov_chovek]

Явно стимула липсва - обяви някаква награда '> Естествено VladSun автоматично се изключва от нея , защото вече е минал играта '>