Автор Тема: Hahor challenge part ii  (Прочетена 117947 пъти)

ANTIADMIN

  • Напреднали
  • *****
  • Публикации: 660
  • Distribution: Windows XP Pro latest updates
  • ANTIADMIN
    • Профил
Hahor challenge part ii
« Отговор #30 -: Jul 30, 2008, 13:56 »
myecho не беше пуснато в началото, даже и nmap. Имаше portmap и atd, което ме заблуди. После пусна myecho, което се виждаше ясно през nmap, който също беше пуснат в последствие. Поне според моите наблюдения, което е донякъде нелогично '<img'>
gdb /bin/myecho
run
disas main
Беше моят вял опит да намеря големината на буфера и след това случайни, преписани команди на perl, но дотам '<img'> То не става само с ядене и пиьене, трябва и акъл '<img'>
Активен

VladSun

  • Moderator
  • Напреднали
  • *****
  • Публикации: 2166
    • Профил
Hahor challenge part ii
« Отговор #31 -: Jul 30, 2008, 14:11 »
Големината на буфера и само с ръчни проби можеш да установиш '<img'>

А намери ли

 jmp    *%esp

инструкция?

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



Активен

KISS Principle ( Keep-It-Short-and-Simple )
http://openfmi.net/projects/flattc/
Има 10 вида хора на този свят - разбиращи двоичния код и тези, които не го разбират :P

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Hahor challenge part ii
« Отговор #32 -: 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 #### '<img'>

Цитат
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 байта. Това в десетична бройна система прави....хм, не знам '<img'> В тези 0х32 байта се съхранява параметъра на функцията gets()
2) Извиква се gets()


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

"Knowledge is power" - France is Bacon

VladSun

  • Moderator
  • Напреднали
  • *****
  • Публикации: 2166
    • Профил
Hahor challenge part ii
« Отговор #33 -: Jul 30, 2008, 16:29 »
Цитат (gat3way @ Юли 30 2008,14:27)
####()

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

KISS Principle ( Keep-It-Short-and-Simple )
http://openfmi.net/projects/flattc/
Има 10 вида хора на този свят - разбиращи двоичния код и тези, които не го разбират :P

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Hahor challenge part ii
« Отговор #34 -: Jul 30, 2008, 16:33 »
'<img'>
Активен

"Knowledge is power" - France is Bacon

zeridon

  • Killmode enabled
  • Administrator
  • Напреднали
  • *****
  • Публикации: 1398
  • Distribution: Debian/Ubuntu
  • Window Manager: console/Gnome
  • BOfH
    • Профил
    • WWW
Hahor challenge part ii
« Отговор #35 -: Jul 30, 2008, 16:46 »
но пък за сметка на това става по интересно :П
Активен

Внмимавай имам клещи за кабел
http://www.netsecad.com/
http://theregister.co.uk/odds/bofh/

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Hahor challenge part ii
« Отговор #36 -: Jul 30, 2008, 17:27 »
Оф, видяло се е че ще се разказва '<img'>

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

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

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

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), значи имаме и шел с такива привилегии.

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


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



Активен

"Knowledge is power" - France is Bacon

ANTIADMIN

  • Напреднали
  • *****
  • Публикации: 660
  • Distribution: Windows XP Pro latest updates
  • ANTIADMIN
    • Профил
Hahor challenge part ii
« Отговор #37 -: Jul 30, 2008, 21:14 »
Стека не вади ли обратно нещата писани в него, по-точно временно вкарани и затова расте към ниските стойности и намалява към високите? А това с регистрите може да се научи само с асамблер, не че аз знам, но това е много общо казано/горната лекция/ и който не разбира/някой като мен/ и без това няма да му свърши работа ':p' Все пак поощрително ДА, за труда. Не се сещам как беше точно лафа от мюзик айдъл.
Иначе на асемблера си имаше точно в кой регистър кви дани се пущаха, ма то с тея пайтъни, рубита, луа луа и други такива извращения, не останаха сериозни хора, за да ни обяснят '<img'> Кой учи асамблер в днешни дни?
Активен

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Hahor challenge part ii
« Отговор #38 -: Jul 30, 2008, 21:58 »
Стекът вади наобратно нещата, затова е LIFO структура '<img'> Обаче никой не е казал, че трябва да расте наобратно, всъщност това е решение, взето за масово използваните архитектури, въпреки което при някои не расте наобратно '<img'> Това са неща, мислени дълго преди въобще да имам идея за какво иде реч, така че нямам право да протестирам '<img'>

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

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

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

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



Активен

"Knowledge is power" - France is Bacon

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Hahor challenge part ii
« Отговор #39 -: Jul 30, 2008, 22:21 »
Както и да е - за да стане по-интересно ще ви кажа, че примерно много популярния vmsplice експлойт като идея има доста общо с тази задача. Там разбира се нещата са доста различни и доста по-сложни, но идеята изначално е сходна - системното извикване  vmsplice() подобно на функцията gets() е глупаво и не проверява големината на това, което му се подава. Като резултат, злият хахор презаписва някаква памет с нещо, което е под негов контрол. Там пак има shellcode, но същият е малко по-различен с оглед на това, че се изпълнява от самото ядро '<img'> И разбира се веригата на случките е по-дълга и по-забавна от нашият случай където прескачаме на адрес с jmp esp и оттам на нашия шелкод, но като цяло, идеята е до немалка степен сходна '<img'>
Активен

"Knowledge is power" - France is Bacon

VladSun

  • Moderator
  • Напреднали
  • *****
  • Публикации: 2166
    • Профил
Hahor challenge part ii
« Отговор #40 -: Aug 02, 2008, 00:02 »
Ех ...
Очаквах някои хора от форума да се запалят по играта ...
Визирам отявлени дейци като  zeridon, Hapkoc, tarator, task_struct и др. (поне за тези, които знам, че имат опит със C)
Активен

KISS Principle ( Keep-It-Short-and-Simple )
http://openfmi.net/projects/flattc/
Има 10 вида хора на този свят - разбиращи двоичния код и тези, които не го разбират :P

task_struct

  • Напреднали
  • *****
  • Публикации: 576
  • Distribution: Kubuntu 14.04
  • Window Manager: KDE 4.13
    • Профил
Hahor challenge part ii
« Отговор #41 -: Aug 02, 2008, 01:12 »
Аз сега виждам, че има втори кръг  '<img'> Голяма съм блейка  ':p'
Попринцип ми е интересно, но нямам време '<img'> , а и не си падам по хакването  '<img'>

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


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

"Minds are like parachutes. They only function when they are open." - James Dewar

irc.freenode.net  / #linux-bg

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Hahor challenge part ii
« Отговор #42 -: Aug 02, 2008, 10:48 »
Да, и аз съм разочарован малко. Особено от това, че lkr май се отказа, а се справяше добре '<img'>
Активен

"Knowledge is power" - France is Bacon

lkr

  • Напреднали
  • *****
  • Публикации: 81
    • Профил
Hahor challenge part ii
« Отговор #43 -: Aug 02, 2008, 12:14 »
Второто ниво не ме заинтригува чак толкова, колкото първото, а ми и писна да ровя '<img'>
Активен

nov_chovek

  • Напреднали
  • *****
  • Публикации: 536
  • Distribution: Ubuntu 8.10 по принуда
  • Window Manager: Gnome
    • Профил
    • WWW
Hahor challenge part ii
« Отговор #44 -: Aug 02, 2008, 12:42 »
Явно стимула липсва - обяви някаква награда '<img'> Естествено VladSun автоматично се изключва от нея , защото вече е минал играта '<img'>
Активен


Подобни теми
Заглавие Започната от Отговора Прегледи Последна публикация
Linux vs Window$ part 2
Идеи и мнения
Buda 21 10961 Последна публикация Feb 20, 2004, 18:06
от nix
Linux vs Windows Part 3
Идеи и мнения
Buda 22 13993 Последна публикация Feb 23, 2004, 22:50
от Agent_SMITH
Hahor challenge web-part
Конкурс bash-майсторът
VladSun 20 55575 Последна публикация Sep 19, 2008, 20:32
от gat3way
Hahor challenge :)
Конкурс bash-майсторът
gat3way 66 140293 Последна публикация Jul 27, 2008, 18:59
от VladSun
Hah0r challenge....again :)
Системна Сигурност
gat3way 9 10233 Последна публикация Feb 03, 2009, 16:43
от gat3way