themalwareguardian/cve-2020-13768Переполнение буфера на основе стека в MiniShare 1.4.1, достигаемое через один HTTP PUT-запрос.
Переполнение буфера на основе стека в MiniShare 1.4.1, вызываемое одним HTTP PUT-запросом.
Этот репозиторий является частью материалов, которые я использую при преподавании эксплуатации повреждения памяти (помимо основной работы, я также преподаю на различных курсах по кибербезопасности, где помогаю готовить следующее поколение реверс-инженеров).
CVE-2020-13768 — это пример, который я использую, когда хочу показать, как простые сетевые серверы могут быть подвержены классическим переполнениям буфера на основе стека через стандартные методы протокола. Уязвимая конечная точка не требует аутентификации, переполнение представляет собой прямую перезапись EIP, а путь эксплуатации чистый и четко определенный. Это идеальный пример для изучения полной методологии эксплуатации в реалистичном удаленном сценарии без аутентификации.
Что также делает этот случай интересным в качестве учебного задания, так это то, что одна и та же первопричина — непроверенные входные данные, копируемые в буфер стека фиксированного размера, — встречается в нескольких записях CVE для одного и того же бинарного файла. CVE-2018-19861, CVE-2018-19862 и CVE-2019-17601 описывают один и тот же класс уязвимости, просто о них сообщили разные исследователи через различные HTTP-методы или конечные точки. Это учит студентов смотреть на первопричины, а не просто на номера CVE.
Эта уязвимость затрагивает MiniShare 1.4.1 — легковесный HTTP-сервер для Windows, разработка которого прекращена, предназначенный для простого локального обмена файлами. Программное обеспечение было написано без учета современных методов обеспечения безопасности. Что делает этот случай особенно интересным с точки зрения обучения, так это сочетание факторов:
Эта комбинация делает CVE-2020-13768 отличным примером для обучения основам эксплуатации сетевых переполнений буфера в реалистичном сценарии без аутентификации.
MiniShare — это минималистичный HTTP-сервер для Windows, изначально предназначенный для быстрого локального обмена файлами по локальной сети. Он прослушивает TCP-порт 80 и обрабатывает небольшое подмножество HTTP-методов, включая GET и PUT. Обработчик PUT обрабатывает входящие запросы и копирует путь URI в буфер стека фиксированного размера без проверки его длины.
Ключевые технические детали:
MiniShare обрабатывает входящие HTTP-запросы и направляет их в соответствующий обработчик в зависимости от метода. Обработчик PUT извлекает путь URI из запроса и копирует его в буфер стека фиксированного размера без проверки его длины.
Упрощенная версия уязвимой логики выглядит так:
char path_buffer[256];
strcpy(path_buffer, uri_path);
Поскольку буфер назначения имеет фиксированный размер, а длина входных данных не проверяется, отправка достаточно длинного URI в PUT-запросе приводит к тому, что копирование выходит за конец буфера, в конечном итоге достигая и перезаписывая сохраненный адрес возврата (EIP) в стеке.
Когда уязвимая функция возвращается, CPU загружает управляемое атакующим значение из стека в EIP и переходит на него. Если этот адрес указывает на управляемые атакующим данные, содержащие шеллкод, достигается произвольное выполнение кода.
Сбой можно воспроизвести, отправив URI чрезмерной длины в HTTP PUT-запросе. Аутентификация не требуется. Пример на Python:
import socket
HOST = '127.0.0.1'
PORT = 80
payload = b"A" * 3000
request = (
b"PUT /" + payload + b" HTTP/1.1\r\n"
b"Host: 127.0.0.1\r\n"
b"Connection: close\r\n"
b"\r\n"
)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
s.send(request)
s.close()
При выполнении под отладчиком видно, что EIP перезаписан управляемыми пользователем данными:
EIP = 41414141
что подтверждает повреждение сохраненного адреса возврата в результате переполнения.
Цель этого репозитория — не только продемонстрировать сбой, но и пройти весь процесс эксплуатации шаг за шагом, следуя методологии, используемой при разработке реальных эксплойтов для переполнения стека.
Чтобы основной README оставался чистым, подробные заметки по эксплуатации, скрипты и шаги отладчика помещены в папку Vulnerability 📂 этого репозитория.
Там вы найдете полный рабочий процесс, использованный для эксплуатации этого CVE, включая: