SQL Injection in WCPS v.4.4.2
3.14здец вот еще одна тысячная по счету бага.
1. ОПИСАНИЕ
Вообщем не буду привдить примеры с кодом и тд т.к уязивмого кода будет очень много, и описывать все мне просто лень. Распишу на словах.
Вообщем в этой поганой цмс у каждого юзера существует его
Ник и
Логин. Они могут быть одинаковыми могут и нет. Вообщем
Логин используется только для авторизации юзера, а соответственно его
Ник выводится везде, типа рядом с его сообщениями ну и тд.
Проблема состоит в том что в этой цмс в качестве
Ника можно использовать строку содержащую спецсимволы. Но все замечательно слешируется при попадании этого ника в БД при регестрации.
Но дело в том что инфа извлекается в массив
SESSION при авторизации
БЕЗ СЛЕШИРОВАНИЯ и используется в дальнейшем в своих запросах.
Это была проблема. А узявимость можно замутить в модуле приватных сообщений. Ну и тут можно привести немного кода. Файл
mod/privat/new.php
PHP код:
$query="INSERT INTO ".$wcpref."privat VALUES ('', '$pmunames', '$pmsubject', '$_SESSION[user_fio]', '$now', '$pmmsn','1', '0') ";
mysql_query($query);
Нормальный запрос принимает вид:
Код:
INSERT INTO wcps_privat VALUES ('', 'Кому', 'Тема', 'Ник', 'Время', 'Сообщение','1', '0')
Ну казалось бы, ну и что здесь такого? А вот что. Регистрируем нового юзера с ником "
bla'/*" (без ковычег "), в итоге наш запрос при создании становится немного неккоректным и будет выглядеть так:
Код:
INSERT INTO wcps_privat VALUES ('', 'Кому', 'Тема', 'bla'/*', 'Время', 'Сообщение','1', '0')
а превратить его в валидный достаточно просто, в теле сообщения пишем "
*/,1,([SQL запрос]),1,0)/*" (без ковычег "), и получаем запрос с выводом в самом сообщении следующего плана:
Код:
INSERT INTO wcps_privat VALUES ('', 'Кому', 'Тема', 'bla'/*', 'Время', '*/,1,([SQL запрос]),1,0)/*','1', '0')
2. ЭКСПЛУАТАЦИЯ
Все было бы за**ись конешно, но тут присутствует одно маленькое е*антство как фильтрация слов user_login и user_pass а это как вы догадались имена полей с логинами и хешами в таблице с юзерами.
а. SQL injection
Так как вывести логины с хешами у вас не выйдет то юзабельность этой баги в этом смысле спадает на нет. Но все же пару советов для эксплуатации этой баги в качестве SQL-inj. Так как вывод идет в тело отправленного сообщения то юзать в качестве Адресата какого нибудь другого юзера - крайне не разумно. Можно указать свой
Ник а идиально для этого зарегить еще один аккаунт.
b. Active XSS
Тут уже поинтереснее. Так как вывод идет в тело сообщения из БД без фильтрации то можно заюзать охуительную Active XSS "отправив" админу сообщение с нашим кодом. Плюс если заделать функциональный снифер, то получится помощнее чем простая SQL inj.
Как? Очень просто. В тело сообщения пишем(разумеется без второй строчки)
Код:
*/,1,(SELECT 0xCFF0E8E2E5F2213C7363726970743E616C65727428646F63756D656E742E636F6F6B6965293C2F7363726970743E),1,0) -- d
Привет!<script>alert(document.cookie)</script>
Ну вообщем тут можете фантазировать как хотите)
2. OUTRO
Вообще интересная бага, да и сам метод реализации.
Можно было бы засунуть весь запрос в ник, но смысла нету. Посему я выбрал разбить запрос на две части.
А и еще не забудьте потом поменять свой ник в профиле на что нить менее бросающееся в глаза)
Удачи...
Похожие темы
Древовидный вид