Bypassing Canary & PIE
Якщо ви маєте справу з бінарним файлом, захищеним канарейкою та PIE (Position Independent Executable), вам, ймовірно, потрібно знайти спосіб їх обійти.
Зверніть увагу, що checksec
може не виявити, що бінарний файл захищений канарейкою, якщо він був статично скомпільований і не може ідентифікувати функцію.
Однак ви можете вручну помітити це, якщо ви виявите, що значення зберігається в стеку на початку виклику функції і це значення перевіряється перед виходом.
Brute force Canary
Найкращий спосіб обійти просту канарейку - це якщо бінарний файл є програмою, яка розгалужує дочірні процеси кожного разу, коли ви встановлюєте нове з'єднання з ним (мережевий сервіс), оскільки кожного разу, коли ви підключаєтеся до нього, використовуватиметься та сама канарейка.
Тоді найкращий спосіб обійти канарейку - це просто перебрати її посимвольно, і ви можете визначити, чи був вірний вгаданий байт канарейки, перевіривши, чи програма впала, чи продовжує свій звичайний хід. У цьому прикладі функція перебирає 8 байтів канарейки (x64) і розрізняє між правильно вгаданим байтом та невірним байтом, просто перевіряючи, чи відправлена відповідь сервером (інший спосіб у іншій ситуації може бути використання try/except):
Приклад 1
Цей приклад реалізований для 64-бітної системи, але може бути легко реалізований для 32-бітної системи.
Приклад 2
Це реалізовано для 32-бітної системи, але це можна легко змінити на 64 біти. Також зверніть увагу, що для цього прикладу програма спочатку очікує байт, щоб вказати розмір введення та полезне навантаження.
Друк Канарейки
Ще один спосіб обійти канарейку - це роздрукувати її. Уявіть ситуацію, де програма вразлива на переповнення стеку може виконати функцію puts, яка вказує на частину переповненого стеку. Атакуючий знає, що перший байт канарейки є нульовим байтом (\x00
), а решта канарейки - випадкові байти. Потім атакуючий може створити переповнення, яке перезапише стек до першого байту канарейки.
Потім атакуючий викликає функціональність puts посередині політря, яка роздрукує всю канарейку (крім першого нульового байту).
З цією інформацією атакуючий може створити та відправити нову атаку, знаючи канарейку (у тій самій сесії програми)
Очевидно, що ця тактика дуже обмежена, оскільки атакуючому потрібно мати можливість роздрукувати вміст свого політря для екстракції канарейки, а потім мати можливість створити нове політря (у тій самій сесії програми) та відправити справжнє переповнення буфера. Приклад CTF: https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html
PIE
Для обходу PIE вам потрібно витікати деяку адресу. І якщо у бінарному файлі не витікає жодна адреса, то найкраще зробити це - перебором RBP та RIP, збережених у стеці у вразливій функції. Наприклад, якщо бінарний файл захищений як канарейкою, так і PIE, ви можете почати перебирати канарейку, потім наступні 8 байтів (x64) будуть збереженим RBP, а наступні 8 байтів будуть збереженим RIP.
Щоб перебрати RBP та RIP з бінарного файлу, ви можете зрозуміти, що правильний вгаданий байт є правильним, якщо програма виводить щось або просто не крашиться. Та сама функція, яка надана для перебору канарейки, може бути використана для перебору RBP та RIP:
Отримання базової адреси
Останнє, що вам потрібно зробити, щоб перемогти PIE, це розрахувати корисні адреси з витікших адрес: RBP та RIP.
З RBP ви можете розрахувати де ви пишете свій shell в стеку. Це може бути дуже корисно, щоб знати, де ви збираєтеся записати рядок "/bin/sh\x00" всередині стеку. Щоб розрахувати відстань між витікшим RBP та вашим shellcode, ви можете просто встановити точку зупинки після витоку RBP та перевірити де знаходиться ваш shellcode, після цього ви можете розрахувати відстань між shellcode та RBP:
З RIP ви можете обчислити базову адресу PIE-бінарного файлу, яка вам знадобиться для створення дійсного ланцюжка ROP.
Щоб обчислити базову адресу, просто виконайте objdump -d vunbinary
та перевірте розібрані останні адреси:
У цьому прикладі ви можете побачити, що для виявлення всього коду потрібно лише 1 байт та пів. Тоді базова адреса в цій ситуації буде витікати з RIP, але закінчуватися на "000". Наприклад, якщо витік 0x562002970ecf, базова адреса буде 0x562002970000.
Last updated