![]() |
FlexCMS 2.5 Blind SQL-Injection
FlexCMS 2.5 Blind SQL-Injection Сайт: www.flexcms.comТребования: magic_quotes_gpc = off Тестилось на последней free версии, скаченной с офф сайта Уязвимость в файле index.php PHP код:
логин==зашифрованый_пасс Т.к переменная $CookieUsername никак не фильтруется и при наличии magic_quotes_gpc = off есть возможность провести инъекцию Example: Код:
True: FCLoginData12345=qwerty'+and+1=1/*%3D%3DqwDyM1dbqwDyM1db9iOPI |
[Exploit & Research] FlexCMS 2.5 & 3.0 Blind SQL-Injection
Данная тема продолжение этой http://forum.antichat.ru/thread96609.html
Я немного погорячился сказав что они новую верcию выпустили. Выпустить то выпустили, а вот баги не закрыли Посмотрел сайтеки в нете, бага должна быть, но она как будто отстутствует, буду разбираться в этом. Пока выкладываю, надеюсь кто нибудь скачает двиг и присоединится в копании и мб немного исправит сплоит и поймёт почему бага не пашет на реальных примерах. пишите 625470 Реализовано на more than 1 row Код:
#!/usr/bin/perl |
Spyder, как я понял, у тебя просто последовательно перебираются все символы на каждой позиции? Гораздо быстрее использовать бинарный поиск. Вместо 512 запросов будет 160 в худшем случае (это если пасс в md5 и поиск правильно реализован).
Хз правда где посмотреть на перле, на пхп можешь у меня глянуть (тоже More1row), тут, правда я не помню насколько он оптимально реализован (т.е. нет ли нескольких лишних запросов): https://forum.antichat.ru/showpost.p...6&postcount=23 В любом случае работает гораздо быстрее, и даже если написан неоптимально, то запросов будет не более 170. |
Даже если и перебирать все символы, то лучше вначале определить цифра \ буква \ символ, затем разбить на диапазоны, выяснить в каком диапазоне лежит нужный символ и далее уже брутить
|
там не мд5, какая то своя криптовка
я посчитал, на каждую букву приходится максимум 62 запроса пасс состоит из 0-9a-zA-Z намёк на бинарный поиск понял меня больше волнует неработоспособноссть баги на реальных примерах в нете |
Цитата:
В случае a-zA-Z-0-9, всего 64 варианта, т.е. в худшем случае, при бинарном поиске без проверки - 6 запросов на символ. Если ты будешь проверять в какой группе лежит символ, то это: 1) 2 запроса на определение группы (стабильно для каждого символа) 2) Ещё 5 запросов на каждый символ в худшем случае (т.е. если тебе попался диапазон более чем из 16 сиволов). Вывод - 7 запросов в худшем варианте, вместо 6 в худшем варианте. З.Ы. Худший вариант - символ ни разу не попал в середину диапазона, до последней итерации. |
| Время: 16:46 |