> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/ru/useful-resources/exploit-development/linux-buffer-overflow-custom.md). # Переполнение буфера в Linux - Custom Заметки по пользовательскому переполнению буфера в Linux для создания эксплойтов, управления потоком выполнения, создания payload'ов и документирования методики порчи памяти. ## Первый пример пользовательского бинарника (Pdmenu/exim):
Скачайте машину вытащить
> Первый пример посвящён эксплуатации законного бинарника exim-4.84-7, в котором есть уязвимость, идентифицированная как CVE-2016-1531. Эта уязвимость позволяет злоумышленнику выполнять команды с привилегиями, злоупотребляя определёнными переменными среды. * В этом случае, когда мы получаем доступ к пользователю Paul, **Pdmenu** ему назначается с определёнными возможностями (список каталогов, редактирование файлов, запуск ping и т. д.):
* Чтобы выйти из этого меню, мы **редактируем файл**, например (etc/host):
* В этом случае, **vi** используется как текстовый редактор:
* Если посмотреть в **gtfobins**, если отфильтровать по vi, мы получим команды для выхода из Pdmenu и **запуска оболочки**:
* Мы фильтруем **SUID** файлы и находим один под названием exim:
* С **searchsploit** инструмент, мы ищем возможные уязвимости для этого бинарника:
* Теперь скачиваем скрипт и раздаём его с помощью **python3** чтобы его можно было загрузить после компрометации машины:
* Мы запускаем скрипт, и действительно уязвимость этого бинарника эксплуатируется, таким образом мы получаем **root-доступ**:
## Второй пример (переполнение буфера):
Скачайте уязвимую Ubuntu машину
Установите инструмент Peda
> Второй пример касается **переполнения буфера** в пользовательском [исполняемый файл](https://hack4u.io/wp-content/uploads/2023/04/custom) на 32-битной Linux-машине с активными защитами и включённым ASLR. В этом случае мы сосредоточимся на эксплуатации ret2libc в бинарнике, у которого есть разрешения SUID и который принадлежит root. С помощью переполнения буфера мы показываем, как внедрять привилегированные команды и повышать привилегии пользователя. \***переполнения буфера** включает перезапись определённых системных регистров, и поскольку бинарник создан пользователем и принадлежит группе root, **он будет запускаться от привилегированного пользователя**:
* Бинарник под названием "custom" ожидает **строковый ввод** и когда он запускается, ничего не происходит:
* Но если мы введём **очень длинную строку**, он возвращает ошибку (core dumped):
Мы отправляем **короткую строку** из AAAAAAAA, и никаких **ошибок не появляется**: * Чтобы глубоко проанализировать бинарник, мы будем использовать **gdb-peda** инструмент.
* Но если мы отправим **много символов**, мы получим следующую ошибку:
1. Первое, что нужно сделать, — это **определить общее количество символов** необходимых для перезаписи регистра (EIP). * Первый метод заключается в использовании **шаблона (pattern)** который создаёт цепочку **специально подобранную** (в этих случаях 300 символов), которую наши запуски в бинарнике:
* По отклику **EIP**, мы знаем, что **нижняя видимая цепочка** — «AA8A»:
* Эта **автоматический** режим выполнения осуществляется с помощью `смещения шаблона $eip` команды:
* Чтобы проверить это, мы используем **python3** отправляя 112 символов A, а затем 4 последних B: ```bash r $(python3 -c 'print("A"*112 + "B"*4)') ``` * По сути, теперь мы подтверждаем хвост благодаря **EIP** который обнаруживает 4 последних B:
2. Как только мы узнаем максимальное количество символов, мы **проверяем ASLR** который определит, есть ли **случайность в адресах памяти** или нет: /- С помощью следующей команды мы отфильтруем интересующие нас строки, чтобы запустить бинарник 10 раз, посмотреть, меняется ли он каждый раз, и увидеть, является ли **библиотека C** случайной или нет: Она действительно «случайная»
3. Проблема с этими **32-битными** бинарниками часто в том, что если мы запустим, например, сейчас **1000 раз** A и отфильтруем по фиксированной строке, мы увидим, что каждый раз, **она повторится как минимум один раз**:
4. Теперь цель — сначала найти **EIP** строки (**system + exit + bin/\_sh**), которые всегда будут фиксированными и необходимыми для выполнения **Bash от root** как в следующем примере, но на Python:
* Мы создаём **точку останова** чтобы поток выполнения программы останавливался в нужный момент:
* Мы внедряем **EIP** данные (system/exit/bin/\_sh):
5. Как только мы видим, что есть **случайность**, нам потребуется использовать **брутфорс** пока **base/\_libc/\_addr** не станет равным нужному значению: /- С помощью следующего мы увидим **работающие библиотеки** (в данном случае **libc.so**):
* С **readelf**, наши фильтры для библиотеки и поиск заранее внедрённых переменных, а именно (**exit and system**) по кодам:
* А чтобы найти строку **/bin/sh**, мы делаем следующее, добавляя **0x00** в начало:
Следующий скрипт Python3 будет **автоматизировать весь перебор** пока **base/\_libc/\_addr** не станет одинаковым: ```python #!/usr/bin/python3 import subprocess from struct import pack import sys offset = 112 before_eip = b"A" * 112 # Пользовательское переполнение буфера в Linux base_libc_addr = 0xb7595000 system_addr_off = 0xb7d86db0 exit_addr_off = 0xb7d7a9e0 bin_sh_addr_off = 0xb7ea7b2b system_addr = pack("
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://hacking-notes.jord4n.pro/ru/useful-resources/exploit-development/linux-buffer-overflow-custom.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.