Так как у меня получилось решить "задачку - Канарейка", то я решил взять что-то более сложное и оценить свои силы, но в pwn категории сложных задач не было, только легкие и средние. Потыкав на несколько задач, я обнаружил, что в задачке "Цепи" решили всего 9 человек, когда как в других задач преобладает 10 решений, а то и больше. Меня заинтересовала эта задачка именно этим, и я хотел посмотреть насколько она сложная. Как таковых знаний в хакинге у меня нет. Знаю только о переполнении буфера. Остальное приходится доходить своим умом и на это уходит бывает несколько дней. Но я также знаю как работает программа, и для программиста вроде меня полезно знать уязвимости, чтобы их не совершать. В каждой такой задачке дан какой-то способ решения задач, и скорее всего один верный. Итак, я взял очередную задачу. Поизучав код, я обнаружил переполнение буфера в функции 0x004014ea.



Как видно, для стека выделяется всего 16 байт памяти. А функция read принимает 256 байт памяти. Здесь возможно переполнение стека. Но что делать дальше? Можно прыгнуть на адрес
0x00401600
И завершить работу с выигрышным сообщением, но вряд ли этого хотели создатели задачки. Здесь нужно было сделать что-то другое. В задаче сказано, что информация находится в файле
flag.txt
, значит нужен
shellcode
. Получается, я думаю, что есть возможность отправить в стекshellcodeи выполнить его. Но, это старая уязвимость, о которой я вспомнил недавно, да и точно не помню, можно было ли в стеке выполнять код или нет. Тем более, что адреса стека меняются постоянно из-за защиты.

Так как я себя чувствовал неважно, я решил распечатать нашу задачку на бумагу и читать в любом месте где только захочется.



Я посмотрел и убедился, что адреса стека меняются, значит shellcodeбудет проблематично записать в стек, потому что я не знаю адрес возврата. Или тут есть какая-то хитрость, типа как мы можем сделать прыжок на адрес0x4015be. Нет, здесь наверное какой-то другой способ должен быть и нужно понять лазейку, если есть переполнение буфера.

Читая лежа распечатанный стек, я заметил канарейку.



Регистры были таковыми.

Код:


Если прибавить к rsp 256 байт, то мы получим 0x7FFE3152A540, значит нам нельзя передавать полные 256 байт в память. Почему я думаю, что это канарейка? Во-первых, в этом адресе каждый раз меняется значение, а во вторых вот правило для канареек, это код из ядра Linux.

C:


Для 64-битной будет в начале первый байт всегда ноль. Анализатор radare не давал мне заглянуть, что ссылается на канарейку, так что пришлось отложить этот вариант, хотя для проверки можно отправить 256 байт и убедиться, что будет stack-smashing. Отправив данные 256 байт, я словил bus error. Передавая данные поменьше я тоже получал bus-error. Нужно было точно понимать что нужно делать, и я стал думать.
Чуть позже до меня дошло, что стековая память в функции main берёт всего 16 байт. И в функции чтения имени 16 байт. Всего 32 байта. Задачка называется цепи. Может нужно правильно оформить стек не знаю. ))
Тогда я решил посмотреть, правильно ли я понимаю, что стек от (Там где вводить логин) будет также доступен и другим функциям в неизменном виде. Может в имя надо пару байт вписать. Потому что если мы переполним функцию ret, то в rbp занесется наше значение (буфер). Получается, если мы впишем много 'A', то после функции leave мы с помощью pop rbp занесём в rbp '0x414141414141414141'. Получается опасный случай, значит нам нужно делать что-то другое.
Помню я как то раньше мог вызывать функции, которые на указаны в программе. Но этот метод тоже не подходит, так как стоит какой-нибудь библиотеке, которую программа использует, измениться (из-за обновлений), то сместятся все позиции функций.
Чтобы было понятно о чем я пишу, я приведу пример. В x86-64 архитектуре, в Linux, если компилировать с помощью gcc, мы можем увидеть следующее: в регистре r8 или r9 (не помню уже), хранится адрес от которого мы можем вычитать или прибавлять смещения и запускать скрытые функции. Сначала, с помощью dlsym мы получаем адреса функций, вычитаем их вместе в r9 регистром, и запоминаем смещения. Потом убираем линковку с -ldl, и можем вызывать эти же функции просто прибавив или вычтя смещения. Этот хитрый способ тоже вроде не подходил. У нас слишком мало возможностей что-либо делать. Поэтому, я решил посмотреть какой будет стек в этих функциях. И вот что вышло.
Итак, главная функция имеет всего 16 байт стека.
В функции 0x40114ea ввода имени мы вычитаем ещё 16 байт.
В функции 0x401223 стек не вычитается.
В функции 0x40128c вычитается 16 байт.
Первый этап. Смотрим адреса rsp и rbp - 0x40114ea

Код:


Второй этап. Смотрим также в 0x401223.

Код:


В этой функции мы хоть и не выделяем для стека память, но записываем в 0x44c данные.



Смотрим как изменился стек.

Код:


Ага, 0xfc7f стирается, значит имя пользователя здесь вообще не имеет значения )), хотя это и так понятно. Идём дальше.
Функция 0x40128c. Здесь регистры опять указывают на то место, где было имя пользователя.

Код:


После ввода символа мы получаем такой стек.

Код:


Именно символ 0x44 был записан как первый, но там ещё записываются данные из других областей памяти и весь логин вообще стирается.

Код:


Ещё одна функция 0x00401223, и вот какой стек.

Код:


В итоге мы имеем то, что в цикле программа считывает нажатие клавиш и стирает всё то, что было в имени игрока. Здесь получается ничего нельзя сделать, так как в каждой функции мы не читаем из стека в начале, первым делом заносим новое значение в стек, значит старые значения стека не канают и записанные данные никак не влияют на работу стека. Единственное к чему я опять возвращаюсь, это переполнить стек и попытаться что-то сделать. Переписать адрес возврата, но куда? Да, я могу просто прыгнуть в то место, чтобы мне написали, что вы решили лабиринт, но это слишком просто для задачи среднего уровня сложности. Что именно делать, я не понимал, и мне пришлось пойти на прогулку и обдумать что делать.
Решил получше исследовать стек. Понятно было, что шансов узнать адрес стека не было. Я залез в ядро Linux и начал смотреть производимые операции со стеком. Я обнаружил, что для стека даже может быть магическое число установлено, чтобы определить, было ли переполнение или нет.

C:


Но пока это мало что давало, да и это магическое число мне не удалось найти с помощью radare.
Думая, думая, я стал просматривать как завершается программа и тут меня осенило, а вдруг нам нужно манипулировать именно теми функциями, которые нам доступны в данный момент и адреса которых нам точно известно. Я не знал, что из этого выйдет, так как не было таких функций как execve и так далее. Но нужно было проверить эту гипотезу и я стал записывать какие регистры меняются и на что меняются, когда используются.

Первым делом я выписал две функции srand и time, и оставил в записях только те регистры, которые менялись после выполнения функции.

Код:


Функция time указывала регистрами на стековую память как я понял, я посмотрел каждый указатель на память, везде были какие-то данные, и что самое главное, это мне не хотелось вдаваться в подробности, почему такие адреса становятся после выполнения этих функций. В итоге я решил пока попробовать с тремя функциями и вот что вышло в отчете.

Код:


Получалась какая-то фигня. После srand в rdi попадал 0x08 число, но в rsi попадало 0xffffffff. Такое нельзя было подавать в read. Но я попробую. ))
Нет, ничего не вышло толкового. Значит либо алгоритм неправильный, либо я не в том направлении двигался. Придется забросить задачку и порешать другие. Что ж, бывает.