Почувствуй себя багоискателем

Докучаев Дмитрий aka Forb

Xakep, номер #065, стр. 065-060-2

Пока ты посылал сообщение, то, наверное, заметил, что для этой цели вызывается скрипт wtboard.cgi. Его и будем ковырять в первую очередь. Чтобы успешно найти брешь, нам важно понять принцип работы форума. Хотя читать чужой код, а особенно написанный небрежно, удовольствие сомнительное. Просмотрев по диагонали текст сценария, я понял, что первоначально вызывается скрипт wtbext.cgi, который содержит служебные процедуры, парсинг потока, анализ переменных и т.п.

Первая бага, на которую мне захотелось проверить проект - ошибка в функции open(). Если перед названием файла поставить конвейер |, то произойдет выполнение команды. Например, после выполнения open("|dir >1.txt"), в файл 1.txt запишется структура каталогов. Запусти поиск по функции open. Ты увидишь, что практически все переменные, находящиеся во втором параметре, создаются внутри скрипта и никак не передаются интерактивно. Это очень плохо для нас, т.к. выполнить команду при таком раскладе невозможно. Затем мне вспомнилась ошибка в open, при которой внешней программе (например, sendmail) можно передать дополнительные параметры в этой же функции. При этом, если переменная не проверяется на спецсимволы, вполне возможно сделать что-то плохое. Но опять же, вызова внешних программ в этих проектах не наблюдалось, как, впрочем, и функций system(), в которых также часто содержатся ошибки.

Изменяем параметры

Итак, изучение сорцов не привело к обнаружению баги. Так всегда, поскольку наверняка найти уязвимость после однократного просмотра кода невозможно. Что ж, попробуем найти ее методом научного тыка. Заходим на главную страницу форума и перейдем на наше первое тестовое сообщение (напиши что-нибудь, если поленился сделать это раньше). Теперь жми "Написать ответ". Мы видим первую ошибку программиста - использование компрометирующего метода GET. При появлении каких-либо параметров в адресной строке браузера невольно хочется их поменять :). Тебе никто не запрещает это сделать - сервер твой, поэтому особой опасности в подстановке нет. В строке видна переменная numans. Судя по логике и ее значению (1), это номер сообщения, на которое ты отвечаешь. Смени значение на 2 и обнови страницу - все поля окажутся пустыми. Еще бы, данного номера пока не существует. А что если... правильно: подставить путь к нижележащему каталогу? Ведь файл сообщения имеет вид цифра.html, поэтому вполне возможно, что сценарий открывает $numans.html. Проверим на значении ../1. Получим пустые поля. Однозначно реакцию определить нельзя: либо скрипт проверяет спецсимвол и открыто игнорирует запрос (пошел на фиг, злобный хакер!), либо просто не находит файла ../1.html (что ты ко мне докопался? Нет у меня такого сообщения!). Тут, конечно, можно было просто посмотреть исходники и все сразу понять. Но делать это было решительно в лом, поэтому я просто перенес 1.html из папки форума на каталог выше. После обновления страницы - о, чудо! - я увидел заполненные поля сообщения, а также полный путь к документу в теме мессаги, что свидетельствовало о наличии уязвимости.