Большая дыра в маленьком форуме

Master-lame-master

Xakep, номер #066, стр. 066-048-1

Нашумевшие истории крупных взломов

Теплым весенним вечером, листая журнал Хакер, один человек наткнулся на весьма интересную статью, посвященную багам в Perl-проектах. Речь шла о найденной уязвимости, позволяющей постить сообщения без дополнительной аутентификации в одном популярном форуме. Однако, прочитав материал до конца, наш герой подумал, что с помощью описанной дырки можно выполнять и более изощренные вещи.

Баг под микроскопом

Уверенным щелчком мыши хакер запустил свой любимый браузер. В адресной строке он набрал www.sonet.to/wtb, где должен был быть установлен форум Wtboard. Действительно, совсем недавно администратор поставил борду на сайт, чем подверг себя большому риску. На форуме красовалось единственное тест-сообщение от админа. Но наш герой не собирался постить второй тест от идентичного ника (что было сделано в статье). Он в принципе не занимался подобными вещами, а совершал лишь революционные взломы :). После некоторых раздумий он скачал сорцы форума себе на винт и приступил к небольшому анализу.

Взломщик установил борду на свой локальный сервер. После этого он немного порылся в скрипте, который позволяет удаленно администрировать Wtboard. Действительно, аккаунт админа располагался в файле data/wtbadmin.txt и содержал в себе следующие данные: admin;;admin;;a, что, по-видимому, означало присвоение абсолютного доступа юзеру admin с аналогичным паролем. Быстро заюзав такой дефолтный аккаунт на сервере sonet.to, наш герой получил от ворот поворот - администратор изменил все настройки по умолчанию.

Дальнейшие действия хакера были направлены на проверку уязвимости. Поставив параметр data=/ в CGI-поток, он убедился в изъяне - сценарий отрапортовал, что не может открыть файл //wtbnames.txt. Затем взломщик обратился к скрипту wtbedit.cgi, передавая ему четыре параметра, название которых было выяснено из wtbadmin.htm. В итоге у сетевого партизана получился следующий запрос: http://localhost/cgi-bin/wtbedit.cgi?fid=0&oper=adminterface&login=root&pass=root. Сценарий заругался на неверный пароль. Взломщик даже не обратил на это внимания. Сейчас его интересовал другой вопрос. Он должен был каким-то образом связать инкапсуляцию переменных с возможностью администрирования и получить полноценный доступ к администраторскому интерфейсу. Наш герой полез в исходники wtbedit.cgi, чтобы посмотреть код процедуры, проверяющей аккаунт на валидность. Искомая функция называлась verifyadmin, вот ее сокращенный код:

Код функции, проверяющей учетную запись

sub verifyadmin

{

open NAM,"$data/$wtbadmin";$i=0;while(<NAM>){chomp;($nam[$i],$pwd[$i],$stat[$i],$s)=split(';;');++$i;}close NAM;

for $i(0..$#nam)

{if($_[0] eq $nam[$i])

{if($_[1] eq $pwd[$i]){$stat=$stat[$i];return $stat;}

else

{return -1;

}}}

return -1;

}

Видно, что в verifyadmin() открывается файл "$data/$wtbadmin", из которого происходит чтение админского логина. Если пароль и имя совпадают с введенными значениями, возвращаются права доступа к борде. Хакера насторожило, что название открываемого файла целиком состоит из переменных, которые при определенном желании можно переопределить.