Linux за българи: Форуми

Програмиране => Конкурс bash-майсторът => Темата е започната от: gat3way в Jul 27, 2008, 19:54



Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 27, 2008, 19:54
Сега ще видим кой наистина е зъл хахор :)

Значи подготвил съм нова тестова среда (предполагам не всичко е перфектно още, но ще се стараем в движение :) ).

IP address: 78.90.217.9
Username: newuser
Password: hello
Port: 22 (ssh) 80 (web)


Каква е постановката?

Първоначално се логвате като потребител без особени права. Вашият път към лелеяният root-ски акаунт минава през 2 стъпки: първо трябва да се сдобиете с правата на малко по-привилегирован потребител. За целта е необходимо да "счупите" услуга, работеща с тях. Услугата е echo, писана е от мен с много фрапантна buffer overflow грешка. Целта е да напишете експлойт за нея, който да ви spawn-не shell. За да улесня малко процеса ще дам малко насоки:

* Най-важното е първо да разберете каква е големината на буфера, който се препълва. Услугата ще крашне ако буферът се препълни със стринг, по-голям от  buffer_size+4
* По-умният човек ще знае как да се сдобие с binary-то, което ще се счупи. Това е почти единственият начин да се справите. Атаки могат да се правят директно върху същото binary като той или core файла може да се дебъг-ват с gdb и objdump. Другият вариант е да пробвате на сляпо, но силно вярвам че нищо няма да направите
* За задачката са необходими елементарни знания по C, но малко по-задълбочени по отношение на това какво представляват buffer overflows. Добро начало са разни whitepapers на packetstorm, имаше едно много добро четиво, мисля че авторът му се нарича aleph1.
* Експлойтът трябва да препълни буфера, да презапише return адреса така че изпълнението да прескочи на някакъв негов зъл код. Този код се нарича shellcode, предполагам ще ви трябва такъв shellcode, който прави нещо от сорта на execve("/bin/sh",...). Рекламирам отново сайта milw0rm.com , там има готови такива. Важно е да пробвате дали работят на тази платформа, най лесният начин е като го присвоите на променлива, да си дефинирате една функция например така:

int (*funkcia)() = (int(*)())shellcode;

Където funkcia() е функцията, char shellcode[] е шелкода.

извикването на funkcia() съответно или ще крашне поради някаква причина, или ще направи това, което трябва. Ще ви трябва шелкод, който може да прави това, а не да крашва :)

* За да е малко по-интересно, използва се address space randomization. Аз бях писал по въпроса, но има много лесен начин това да се преодолее. Има много хубави статии по въпроса, предполагам гугъл ще ги изплюе ако търсите за defeating address space randomization, [vdso], linux-gate.so и т.н. Накратко търси се място, което съдържа ffe4 (jmp %esp) и адресът му се използва за това, с което се презаписва return адреса.


Ако се справите добре, получавате daemon-ски привилегии.

За да получите оттам нататък root-ски такива, трябва да проявите малко фантазия, да се разровите из файловите системи, да разгледате какво работи, рано или късно ще ви хрумне как да успеете :) Не мисля да казвам нищо.


А, да, пуснал съм един уеб с една проста страница. Когато успеете да хахорнете системата, отбийте се през index-а да се разпишете.


За да не каже някой, че това изглежда невъзможно, далеч не е така. Ето го и доказателството :)

http://imajr.com/Original.aspx?Id=kvm3-1147405

Ако се сетя още нещо, ще пиша :)





Титла: Hahor challenge part ii
Публикувано от: ANTIADMIN в Jul 27, 2008, 21:09
Като го пуснеш се обади :D
Примерен код
ssh: connect to host 78.90.217.9 port 22: Connection refused


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 27, 2008, 21:33
Малко последни корекции вкарвах, съжалявам :) Вече работи :)


Титла: Hahor challenge part ii
Публикувано от: nov_chovek в Jul 27, 2008, 21:44
ти си ебаси маниака, честно :) според мен в тоя сайт ще има само около 2-3 човека, който ще могат да се справят с това.


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 27, 2008, 21:45
Целта е един да се справи :) А пък аз ще съм достатъчно търпелив да изчакам надявам се :)

А, дам, експлойтите за тези неща се намират в /root. Ако някой случайно измисли как да ги изчете, може да си ги ползва, макар че ако може да го направи, надали ще му трябват :)





Титла: Hahor challenge part ii
Публикувано от: senser в Jul 27, 2008, 21:45
Цитат (por4e2 @ Юли 27 2008,21:09)
Като го пуснеш се обади :D
Примерен код
ssh: connect to host 78.90.217.9 port 22: Connection refused

според мен си работи


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 27, 2008, 21:52
А, да, въпросното binary може да си го свалите и да го мъчите локално при вас ако имате желание, мисля, че така ще е по-лесно, а и другите няма да ви се бъркат :)


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 27, 2008, 23:47
Между другото ето няколко полезни текстове по тоя въпрос:

Що е то стек: http://en.wikipedia.org/wiki/Stack_frame#Structure
Buffer overflow: http://en.wikipedia.org/wiki/Buffer_Overflow
Stack overflow:
http://en.wikipedia.org/wiki/Stack_buffer_overflow


Прословутата статия от aleph1: http://packetstormsecurity.org/docs/hack/smashstack.txt

Как да чупим randomize_va_space:
http://www.milw0rm.com/papers/94

Успех :)





Титла: Hahor challenge part ii
Публикувано от: ANTIADMIN в Jul 28, 2008, 00:41
Може и на perl да се напише, ма моя shellcode го триха :( Ама и без тва не ставаше. Стигам до 0xffffff0 за буфера и съм дотам, утре ще продължа. Ако и до утре никой не направи нещо е редно да дадеш нов джокер. Ааа аз не разбирам от нищо, затова, който чете темата да не го взима насериозно.
Подозирам, че ениак ми три шелкода :D
Лека нощ!


Титла: Hahor challenge part ii
Публикувано от: eniac111 в Jul 28, 2008, 11:08
Не е вярно! :)

91.196.226.249 //Аз





Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 28, 2008, 12:56
Апропо и с една шел команда може и тя е echo, но това надали има голямо значение :)


Титла: Hahor challenge part ii
Публикувано от: zeridon в Jul 28, 2008, 13:24
Предполагам си си написал документацията как се билдва подобна среда. Поне за мен ще е интересно. Или поне по темата наблюдение на мажещите акаунтинг и други такива.


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 28, 2008, 13:49
Мне, ужасно досадно е да се пишат такива неща :)

Иначе наблюдения имам, поне по отношение на това какво се случваше в първата среда. Най-сериозният проблем беше с форкбомбите, поради което се слага някакъв нормален hard лимит в /etc/security/limits.conf. Забраната на смяна на паролата става много лесно, просто на passwd се отрязва тази възможност от страна на непривилегирован потребител. Това става по най-лесния начин: махам setuid бита на /usr/bin/passwd и дотам със смяната на паролата. Друго, което се случва - някои хора се опитват да си играят с разни популярни локални експлойти - това 2.6.18 ядро е пачнато по отношение на vmsplice проблема и понеже има ограничен набор драйвери, няколко сходни проблеми например в 802.11 драйверите се избягват. Мисля, че съществува възможност за локален DoS срещу това ядро и при такава конфигурация, но не съм сигурен. Има един много сериозен проблем, който поради мързел не съм оправил и благодарение на който някой идиот може да съсипе временно средата, но не мисля да го споделям, а и мога относително бързо да се справя с последствията ако се наложи. Оттам нататък всичко си е спрямо конкретната задача. Гледам да не си обменям ключове между хост операционната система и тази, да не стане някаква авария :) Специално за тази игра си строших доста време, защото в първоначалната конфигурация, с ядро 2.6.25, гадовете-големи-глави са бутнали малко VA кода с което превръщат експлойтването на моята програмка в доста усложнено занимание. Същото се отнася и за inetd, ползвам този му вариант, защото другите бяха ужасно досадни гадове. Гледах да улесня нещата с експлойтването максимално и това мисля е един от най-лесните случаи, поне по отношение на това. Мисля, че човек с малко повече зор няма да му е проблем да се справи. Просто изпълнението няма много общо с разните хахорски занимания да теглиш нещо да го компилираш и да се справиш, изисква малко повече мислене (и вероятно четене). Втората задача е...забавна и изисква малко знания за това как работи тази операционна система :) За нея специално съм сътворил една гигантска дупка в сигурността, но леко замаскирана и може да се експлойтне само ако си минал първото ниво.


Титла: Hahor challenge part ii
Публикувано от: lkr в Jul 28, 2008, 14:36
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!w���j
                                                                 X�Rh//shh/bin��RS��̀
Segmentation fault


Титла: Hahor challenge part ii
Публикувано от: VladSun в Jul 28, 2008, 18:49
Вътре съм :) :)


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 28, 2008, 19:40
Сега остава задача нумеро дуо :)


Титла: Hahor challenge part ii
Публикувано от: VladSun в Jul 28, 2008, 20:26
Утре :) за днес стига толкова


Титла: Hahor challenge part ii
Публикувано от: VladSun в Jul 29, 2008, 11:13
Тралалалаа :)
http://78.90.217.9/


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 29, 2008, 11:24
pwned :>


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 29, 2008, 18:54
Няма ли някой друг да се пробва? Vladsun може да е първи, но поне да си имаме и втори, а защо не и трети?


Титла: Hahor challenge part ii
Публикувано от: bulg в Jul 29, 2008, 19:44
getaway, пусни заданието в irc. Oт там ще дойде истинското Подкрепление.   (-;


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 29, 2008, 20:52
Не е лоша идея, напоследък във форумите е пълно с идиоти, които преди царстваха из IRC сървърите, следователно е възможно пък из IRC мрежите сега да са се появили такива, които не ги мързи да помислят малко :)


Титла: Hahor challenge part ii
Публикувано от: VladSun в Jul 29, 2008, 22:20
... вече има двама, които пробват :)
и единият вече се отказа :(





Титла: Hahor challenge part ii
Публикувано от: BULFON в Jul 29, 2008, 22:29
Сърдечно благодаря и почитания за инициативата. Едно от най-смислените неща, които можеха да се случат през "лятната ваканция".


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 29, 2008, 22:32
В момента има двама. Да давам ли още джокери? :)


Титла: Hahor challenge part ii
Публикувано от: arenax в Jul 29, 2008, 22:33
Да


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 29, 2008, 22:40
Добре. Вижте конфигурацията на inetd и ще намерите въпросното binary. Днеска си початихме с VladSun след като root-на машината и се оказа че съм забравил една версия на въпросната услуга, която е още по-надупчена, демек вътре е дефинирана една статична променлива на която е присвоена стойност "\xff\xe4". Така че реално погледнато има поне 2 адреса в паметта, които може да използвате за return адрес във вашия експлойт. Друго, с което мога да помогна - големината на буфера, който се overflow-ва не е по-голяма от 100 байта, това съм го правил за да ви съкратя мъките по намиране на дължината му :)

Когато си пробвате експлойта върху услугата го правете по следния начин: (exploit_blabla;cat) | nc localhost 7. В противен случай след изпълнението на есплойта (ако е успешно), губите stdin/stdout-а и не можете да изпълнявате шел команди с привишените си привилегии.


Титла: Hahor challenge part ii
Публикувано от: VladSun в Jul 30, 2008, 09:59
Аз да помагам ... още ...
Стъпка първа:
Примерен код

id
netstat -nta
cat /etc/inetd.conf | grep -v '#'
gdb .........






Титла: Hahor challenge part ii
Публикувано от: Ivshti в Jul 30, 2008, 10:43
Myecho, хаха.


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 30, 2008, 10:50
Ммм преди заниманията с gdb би било добре да се разбере колко дълъг е буфера все пак :)

Айде пак ще дам един джокер - ето един автоматизиран начин за откриване на дължината на буфера:

Примерен код
#!/bin/sh

mkdir /tmp/.workdir
cd /tmp/.workdir
len=2
vuln="/bin/true"
rm core
ulimit -c 10000

while [ $len -lt 100 ];
do
rm /tmp/test
touch /tmp/test
ag=1
while [ $ag -lt $len ];
do
echo -en "A" >> /tmp/test
ag=`expr $ag + 1`
done
echo -en "\n" >> /tmp/test
cat /tmp/test | $vuln
if [ -f ./core ]; then
echo -e "Found buffer size = $len - 4!"
exit
fi
len=`expr $len + 1`
done


Единствено /bin/true трябва да се замести с името на въпросното binary :)


Титла: Hahor challenge part ii
Публикувано от: ANTIADMIN в Jul 30, 2008, 13:56
myecho не беше пуснато в началото, даже и nmap. Имаше portmap и atd, което ме заблуди. После пусна myecho, което се виждаше ясно през nmap, който също беше пуснат в последствие. Поне според моите наблюдения, което е донякъде нелогично :D
gdb /bin/myecho
run
disas main
Беше моят вял опит да намеря големината на буфера и след това случайни, преписани команди на perl, но дотам :D То не става само с ядене и пиьене, трябва и акъл :D


Титла: Hahor challenge part ii
Публикувано от: VladSun в Jul 30, 2008, 14:11
Големината на буфера и само с ръчни проби можеш да установиш :)

А намери ли

 jmp    *%esp

инструкция?

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





Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 30, 2008, 14:27
Принципно 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()


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


Титла: Hahor challenge part ii
Публикувано от: VladSun в Jul 30, 2008, 16:29
Цитат (gat3way @ Юли 30 2008,14:27)
####()

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


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 30, 2008, 16:33
:)


Титла: Hahor challenge part ii
Публикувано от: zeridon в Jul 30, 2008, 16:46
но пък за сметка на това става по интересно :П


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 30, 2008, 17:27
Оф, видяло се е че ще се разказва :)

Значи при 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 не е интересен регистър и ненужно много ще се усложни цялата тарапана ако трябва да го вземаме предвид:) Така че ако има забележки по отношение на това ще ги приема без възражения :)





Титла: Hahor challenge part ii
Публикувано от: ANTIADMIN в Jul 30, 2008, 21:14
Стека не вади ли обратно нещата писани в него, по-точно временно вкарани и затова расте към ниските стойности и намалява към високите? А това с регистрите може да се научи само с асамблер, не че аз знам, но това е много общо казано/горната лекция/ и който не разбира/някой като мен/ и без това няма да му свърши работа :p Все пак поощрително ДА, за труда. Не се сещам как беше точно лафа от мюзик айдъл.
Иначе на асемблера си имаше точно в кой регистър кви дани се пущаха, ма то с тея пайтъни, рубита, луа луа и други такива извращения, не останаха сериозни хора, за да ни обяснят :D Кой учи асамблер в днешни дни?


Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 30, 2008, 21:58
Стекът вади наобратно нещата, затова е LIFO структура :) Обаче никой не е казал, че трябва да расте наобратно, всъщност това е решение, взето за масово използваните архитектури, въпреки което при някои не расте наобратно :) Това са неща, мислени дълго преди въобще да имам идея за какво иде реч, така че нямам право да протестирам :)

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

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

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

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





Титла: Hahor challenge part ii
Публикувано от: gat3way в Jul 30, 2008, 22:21
Както и да е - за да стане по-интересно ще ви кажа, че примерно много популярния vmsplice експлойт като идея има доста общо с тази задача. Там разбира се нещата са доста различни и доста по-сложни, но идеята изначално е сходна - системното извикване  vmsplice() подобно на функцията gets() е глупаво и не проверява големината на това, което му се подава. Като резултат, злият хахор презаписва някаква памет с нещо, което е под негов контрол. Там пак има shellcode, но същият е малко по-различен с оглед на това, че се изпълнява от самото ядро :) И разбира се веригата на случките е по-дълга и по-забавна от нашият случай където прескачаме на адрес с jmp esp и оттам на нашия шелкод, но като цяло, идеята е до немалка степен сходна :)


Титла: Hahor challenge part ii
Публикувано от: VladSun в Aug 02, 2008, 00:02
Ех ...
Очаквах някои хора от форума да се запалят по играта ...
Визирам отявлени дейци като  zeridon, Hapkoc, tarator, task_struct и др. (поне за тези, които знам, че имат опит със C)


Титла: Hahor challenge part ii
Публикувано от: task_struct в Aug 02, 2008, 01:12
Аз сега виждам, че има втори кръг  :D Голяма съм блейка  :p
Попринцип ми е интересно, но нямам време :( , а и не си падам по хакването  :)

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


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


Титла: Hahor challenge part ii
Публикувано от: gat3way в Aug 02, 2008, 10:48
Да, и аз съм разочарован малко. Особено от това, че lkr май се отказа, а се справяше добре :(


Титла: Hahor challenge part ii
Публикувано от: lkr в Aug 02, 2008, 12:14
Второто ниво не ме заинтригува чак толкова, колкото първото, а ми и писна да ровя :)


Титла: Hahor challenge part ii
Публикувано от: nov_chovek в Aug 02, 2008, 12:42
Явно стимула липсва - обяви някаква награда :) Естествено VladSun автоматично се изключва от нея , защото вече е минал играта :)


Титла: Hahor challenge part ii
Публикувано от: VladSun в Aug 02, 2008, 13:05
Цитат (lkr @ Авг. 02 2008,12:14)
Второто ниво не ме заинтригува чак толкова, колкото първото, а ми и писна да ровя :)

Няма много за ровене ;)

Примерен код
find / -uid 1 2>/dev/null | grep -v proc


Титла: Hahor challenge part ii
Публикувано от: VladSun в Aug 02, 2008, 13:10
Цитат (nov_chovek @ Авг. 02 2008,12:42)
Явно стимула липсва - обяви някаква награда :) Естествено VladSun автоматично се изключва от нея , защото вече е минал играта :)

ти не си nov_chovek, а zal_chovek

 :D  :D  :D
 :p  :p  :p


Титла: Hahor challenge part ii
Публикувано от: VladSun в Aug 02, 2008, 13:43
Ей! lkr ... забрави да се разпишеш в index.html-a :)


Титла: Hahor challenge part ii
Публикувано от: lkr в Aug 02, 2008, 13:48
не съм ;)


Титла: Hahor challenge part ii
Публикувано от: gat3way в Aug 02, 2008, 17:31
Може наградата да е бира ама ще трябва да е преди средата на месеца...щото ставам семеен човек и вече няма да се занимавам с хахорски глупости :)


Титла: Hahor challenge part ii
Публикувано от: gat3way в Aug 02, 2008, 17:42
lkr и ти си прелоуднал лошите работи :) Само ми е интересно оттам кое binary те направи root?  Съжалявам, но не съм в София и нямам ssh достъп в момента :)


Титла: Hahor challenge part ii
Публикувано от: lkr в Aug 02, 2008, 18:15
su :)


Титла: Hahor challenge part ii
Публикувано от: gat3way в Aug 02, 2008, 18:22
Мдам, това е удобно :)

Само ще ви помоля да зачистите лошата работа да не се сети някой друг :)


Титла: Hahor challenge part ii
Публикувано от: dhelix в Aug 03, 2008, 13:23
аз най-доброто до което го докарах е шел в който като напиша whoami не ми връща нищо или при опит да отворя шел веднага след отваряне ми дава broken pipe.....
:(
Все пак беше забавно да опитам.Благодаря на gat3way за което!





Титла: Hahor challenge part ii
Публикувано от: gat3way в Aug 03, 2008, 15:13
Каква ли е вероятността да си го направил точно когато lkr е играл да счупи втората задача, предполагам това е възможно стечение на обстоятелствата, което обяснява случилото се :)

За жалост нямаше как да го измисля така че едното да не пречи на другото :) Ако искаш, пробвай сега пак :)


Титла: Hahor challenge part ii
Публикувано от: bnight в Aug 08, 2008, 10:49
на мен предизвикателстовто ми хареса макар и да иска прекалено много познания по програмиране :) Иначе е хубаво подобни инициятиви да продължът. Поздрави за идеята.