themalwareguardian/cve-2017-14980Стековое переполнение буфера в Sync Breeze Enterprise 10.0.28, доступное через обработчик /login, демонстрирующее, как непроверенная длина входных данных может повредить стековую память.
Переполнение стекового буфера в Sync Breeze Enterprise 10.0.28, доступное через обработчик /login, демонстрирующее, как непроверенная длина входных данных может повредить стековую память.
Этот репозиторий является частью материалов, которые я использую при обучении эксплуатации повреждения памяти (в дополнение к основной работе я также преподаю на различных курсах по кибербезопасности, где помогаю обучать следующее поколение специалистов по реверс-инжинирингу).
CVE-2017-14980 — это случай, который я использую, когда хочу, чтобы студенты столкнулись с обычным перезаписыванием EIP через HTTP, а не через необработанный протокол TCP. На первый взгляд это выглядит просто: форма входа, длинный пароль, сбой, но контекст HTTP вводит набор нежелательных символов, которые не очевидны сразу и заставляют студентов задуматься о том, как данные обрабатываются перед тем, как попасть в уязвимый буфер. Понимание того, почему %, &, + и = являются здесь плохими символами, требует понимания URL-кодирования, что само по себе является полезным уроком.
Sync Breeze Enterprise — это приложение для синхронизации файлов в Windows, которое предоставляет веб-интерфейс управления. Уязвимость находится в обработчике входа, который копирует поле пароля в стековый буфер фиксированного размера без проверки длины. Что делает этот случай полезным для обучения:
Sync Breeze Enterprise — это инструмент синхронизации файлов для Windows, который включает встроенный веб-сервер для удалённого управления. Веб-интерфейс прослушивает TCP-порт 80 (если включён) и предоставляет форму входа по адресу /login. Уязвимость находится в обработчике POST, который обрабатывает поле пароля.
Ключевые технические детали:
Sync Breeze обрабатывает форму входа, считывая тело POST и извлекая поле пароля. Значение копируется в стековый буфер фиксированного размера без проверки его длины. Упрощённая версия уязвимой логики выглядит так:
char password_buffer[256];
strcpy(password_buffer, password_field);
Тело POST декодируется из URL перед копированием, что означает, что такие символы, как %25, декодируются в % перед тем, как попасть в буфер. Это также объясняет, почему некоторые символы, специальные для URL, действуют как плохие символы: они интерпретируются слоем HTTP до того, как данные попадут в уязвимую операцию копирования. Отправка достаточно длинного значения пароля приводит к тому, что копия выходит за пределы буфера, перезаписывая сохранённый обратный адрес. Когда функция возвращается, процессор загружает управляемое злоумышленником значение из стека в EIP и переходит к нему.
Сбой можно воспроизвести, отправив слишком длинный пароль в POST-запросе к /login. Аутентификация не требуется. Пример с использованием Python:
import socket
HOST = '127.0.0.1'
PORT = 80
payload = b"A" * 600
body = b"username=admin&password=" + payload
request = (
b"POST /login HTTP/1.1\r\n"
b"Host: 127.0.0.1\r\n"
b"Content-Type: application/x-www-form-urlencoded\r\n"
b"Content-Length: " + str(len(body)).encode() + b"\r\n"
b"Connection: close\r\n"
b"\r\n" +
body
)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
s.send(request)
s.close()
При выполнении под отладчиком сбой показывает EIP, перезаписанный управляемыми пользователем данными:
EIP = 41414141
подтверждая, что сохранённый обратный адрес был повреждён переполнением.
Цель этого репозитория — не только продемонстрировать сбой, но и провести пошаговый процесс полной эксплуатации, от фаззинга до рабочего обратного шелла.
Чтобы не загромождать основной README, подробные заметки по эксплуатации, скрипты и шаги отладчика размещены в папке Vulnerability 📂 этого репозитория.
Там вы найдёте полный рабочий процесс, используемый для эксплуатации данной CVE, включая: