2ShowBiz: Прокуратура Курской области (уязвимость)
В догонку к предыдущему посту речь снова пойдёт о 2showbiz, только рассказать я хочу не о дизе и юзабилити а о уязвимости на одном из самых «крутых» сайтов, сделанных этой студией: prockurskobl.ru
Глядя на скрипты, которые передают параметр в бд так и хочеться сунуть в него кавычку:
«Ну и чё?» — спросите вы. А ничё! Перед нами sql-injection.
С помощью оператора «union» подбираем количество полей используемых в запросе и ищем принтабельные (те, которые выводятся из таблицы в документ):
Ок. Пробуем вывести данные… Но вот незадача — переменные «version()», «user()», «database()» и т.д. не работают. Наверное, проблемы с кодировкой на сервере. Ну ничего страшного — заюзаем функции «aes_decrypt» и «aes_encrypt», которые зашифруют и расшифруют данные с помощью алгоритма «AES». А для удобства сделаем конкатенацию (объеденение) строк, с помощью «concat».
Итак:
5.0.16-standard-log — версия sql сервера.
[email protected] — юзер, под которым он запущен.
ProsecutoryDB — база данных.
pc-linux-gnu — ось.
Отлично! 5ая версия. Пробуем вывести информацию о таблицах базы из таблицы «information_schema.tables».
Как мы видим выводится только одна запись из таблицы. Чтобы прочитать остальные используем оператор «limit», который будет выдавать нам записи построчно. Находим таблицы с аккаунтами юзеров.
Далее нужно найти названия колонок в таблице. Но сколько я не пытался — вытащить колонки мне не удалось. Наверное админы запретили вывод из «information_schema.columns». Зато сбрутить их оказалось гораздо проще. :)
Расшифровываем и получаем админские акки.
Все мои попытки найти админку не увенчались успехом. :( Поэтому на этом смайле мы завершаем взлом.
Главное — мы смогли раскрутить уязвимость, причём очень опасную.
зы: ув. 2showbiz, отключение информации об ошибках не спасёт Вас от матёрых взломщиков. Чтобы полностью уберечься от возможности проникновения стоит тщательно фильтровать входные параметры.
ззы: это не единственная уязвимость на сайтах нашей любимой веб-студии. Подвержены уязвимости по крайней мере ещё 5 сайтов.
Глядя на скрипты, которые передают параметр в бд так и хочеться сунуть в него кавычку:
«Ну и чё?» — спросите вы. А ничё! Перед нами sql-injection.
С помощью оператора «union» подбираем количество полей используемых в запросе и ищем принтабельные (те, которые выводятся из таблицы в документ):
Ок. Пробуем вывести данные… Но вот незадача — переменные «version()», «user()», «database()» и т.д. не работают. Наверное, проблемы с кодировкой на сервере. Ну ничего страшного — заюзаем функции «aes_decrypt» и «aes_encrypt», которые зашифруют и расшифруют данные с помощью алгоритма «AES». А для удобства сделаем конкатенацию (объеденение) строк, с помощью «concat».
Итак:
5.0.16-standard-log — версия sql сервера.
[email protected] — юзер, под которым он запущен.
ProsecutoryDB — база данных.
pc-linux-gnu — ось.
Отлично! 5ая версия. Пробуем вывести информацию о таблицах базы из таблицы «information_schema.tables».
Как мы видим выводится только одна запись из таблицы. Чтобы прочитать остальные используем оператор «limit», который будет выдавать нам записи построчно. Находим таблицы с аккаунтами юзеров.
Далее нужно найти названия колонок в таблице. Но сколько я не пытался — вытащить колонки мне не удалось. Наверное админы запретили вывод из «information_schema.columns». Зато сбрутить их оказалось гораздо проще. :)
Расшифровываем и получаем админские акки.
Все мои попытки найти админку не увенчались успехом. :( Поэтому на этом смайле мы завершаем взлом.
Главное — мы смогли раскрутить уязвимость, причём очень опасную.
зы: ув. 2showbiz, отключение информации об ошибках не спасёт Вас от матёрых взломщиков. Чтобы полностью уберечься от возможности проникновения стоит тщательно фильтровать входные параметры.
ззы: это не единственная уязвимость на сайтах нашей любимой веб-студии. Подвержены уязвимости по крайней мере ещё 5 сайтов.
41 комментарий
«Все мои попытки найти админку не увенчались успехом. :( Поэтому на этом смайле мы завершаем взлом.»
Ну и нашел бы ты админку, дальше что? Все, что у тебя есть на руках — логин. Или ты думаешь вот это пароль?
На глаз скажу, что это хэш md5, свидетельство того, что прогер шубисов все же не полный лох, хотя я бы все же использовал sha1.
«Да я ща напишу на сях подборщик, к утру буду с паролем....»
Если пароли соблюдают правила безопасности (не менее 8 знаков + буквы в разном регистре + цифры + знаки препинания) твой подбор нехуево затянется на пару месяцев + счета за свет. а если там еще и соль используется символов эдак на 40, то взломаешь ты пароль к пенсии. Ситуацию с солью можно избежать подбирая пароль непосредственно через форму авторизации. Но частота обращений вызовет подозрения у тех.службы в тот же день, кроме того время подбора увеличится (время отклика по сети). Итого, не смотря на мой одобрям этого поста и демонстрацию автором знания функций MySQL, правды ради замечу, что в конце его понесло вообще не в ту сторону. Его намеки на «вытащенный пароль» — сказки братьев гримм. ему скорей нужно было бы намекать на ущерб наносимый непосредственно из адресной строки, при условии, что у текущего sql пользователя для этого ущерба есть права.
ох молчите, уже, молчите.
а хотите вынюхать пару дорог тёртого рога единорога?
Коллеги, давайте договоримся. Пароли не публикуем, хотите кому-либо, что-либо доказать — в личку.
6b3f119771e9800e84ca165109bfab5b
65713e646fbf85ed5e3f8cd384d47ac7
c9289ef4b13a8f63c8271479d2416bc4
6839499417974428352669ca59f85fee
804e7275cd44d87dc89d41cd4034eb25
пароли составленные по всем законам безопасности. попробуйте сбрутить их тем же кейном и если у Вас это получится, скажите сколько потратили на это времени. а патом посмотрите в онлайн базах, поиск в которых занимает считанные секунды. только не надо говорить что эти пассы я специально вбил в базу)
А вот публикация паролей была лишней.
вот один, остальные даже не смотрел.