Хочу поделится методой, которую придумал сам... если баян прошу показать где про это можно читануть, если нет то все это дело требует доработки и не дает 100% гарантии успеха. Попался под руки движок форума, обычный с виду движок... но... заметил такую штуку, в скрипте который выводит список юзеров, можно менять поле по которому идет сортировка вывода. Ну т.е. можно было выбирать сортировать по имени пользователя, по дате регистрации и т.д... я попробовал вручную изменить пост зарос и поставил сортировку по полю password.... и оно сработало. Проверил таким образом зарегал себе акк у которого хеш от пароля начинался на 0000.... и отсортировал по полю пароль, и вот мой акк стоит на первом месте. Дальше выбираем жертвой нужного юзера и так меняем себе пароли что бы их хеши начинались с нужного нам символа, например у жертвы хеш 202cb962ac59075b964b07152d234b70 (пасс 123) мы себе поставили пароль 1234 с хешем 81dc9bdb52d04dc20036dbd8313ed055, значит после сортировки наш акк будет ниже в списке, мы меняем себе пароль таким обрзом что бы хеш начинался с символа меньше 8.... и т.д. пока не дойдем до 1 при которой наш акк поднимися выше при сортировке. Таким образом получаем первый символ хеша выбраной жертвы. Потом второй, третий и т.д. Пароли с нужными хешами я искал по нужной маске в базе данных хешей, например мне был нужен пароль с хешем который начинается с 21, делаю запрос в свою базу такого вида. SELECT ......LIKE '21%' где '21%' маска нужного хеша, как результат имею несколько паролей. Сразу скажу, что с ПХПББ и Булкой такое не проходит, там сортировка списка юзеров устроена иначе. Я пробовал это на вот этом сайте www.neocrome.ru, может еще где прокатит. До этого такого подхода не встречал нигде, хотя наверное он очевиден, недаром в форумах сортировка идет не напрямую по столбикам таблицы (во всяком случае в ПХПББ), сегодня спецом порылся в коде форума....
хм интересно тока меня смущает то что последнии символы будет очень сложно подбирать мне кажется легче будет брут
Последние символы подбирать и не придется, цель вообщем не получить полный хеш. Мы допускаем что в нашей базе хешей-паролей есть нужный нам пасс (ну или мы генерим нужную базу) дальше мы просто подбираем нужный, ведь если в базе все же окажется нужный хеш-пароль, то мы в любом случае на него выйдем, ну а если нет, то про последние символы нечего говорить, врядли получится дойти и до первых 10... Однако замечу что если пароль будет в открытом виде, то его мы подберем практически гарантировано.
В том то и дело, что неизвестно через что идет запрос, взлома как такового нету. Просто в при указании сортировки в коде скорее всего явно задается поле по которому нужно сортировать. Ну допустим вот так Code: www.site.ru/memberlist.php?sort=username&f=asc т.е. сортируем по имени пользователя. Причем то по чем сортировать выбираем из выпадающего списка, так же это может идти в POST заросе, при этом в списке нету конечно же поля password, но в таблице то оно есть вот мы и указываем Code: www.site.ru/memberlist.php?sort=password&f=asc ну или тоже самое но через POST зарос. При этом сортировка успешно выполнится и база нам вернет результат отсортированый по полю ПАРОЛЬ. Как видим иньекции к обычном понимании нету, но в тоже время .... мы получаем инфу которой мы не должны получать
3 раза прочитал и понял уникальность метода, т.е мы вообще не имеем вывода никаких хэшей, а находим близкий хэш (хотя-бы 4-5-6 совпадающих символов подряд и вероятность того что пароль уже совпададёт будет велика, ну что в свою очередь конечно зависит от имеющейся базы пасс:хэш).
вообще, подобный метод очень хорош будет когда в базе пароли в своем исходном виде лежат.. но и в случае с использованием хешей может очень пригодится.. ) молодец, оригинальный подход.. теперь остается искать движки где такое проходит и писать новые сплоенты.. )
Используем метод деления пополам: Подбираем пароль, у которого первая цифра хэша 8 - смотрим где юзер жертва, если ниже то меняем пасс на новый, хэш которого начинается на С ну и тд. Потребуется от 20 до 30 сортировок и неполный хэш мы получили... UP Поправил у нас алфавит [0-9a-f] (hex) ЗЫ Если хэши хранятся в символьном виде, либо в hex, то их сортировка, будет одинаковая, если под вторым случаем иметь ввиду не строку а число...
в определенных условиях можно ускорить процесс, сделав себе несколько акков юзеров заместо одного.. особенно если для юзеров сайта, присутствуют, например, временные ограничения для необходимых нам выборок с сортировкой и общее число юзеров достаточно велико..
огромную базу хешей надо иметь. Первый угаданный символ хеша сокращает перебор в 2^4=16 раз, следующий еще в 16 и т.д., т.е. получается если угаданы N символов хеша, то перебор паролей сокращается в (16)^n раз, что очень неплохо...
Теоретически, это тяжело сделать, я имею ввиду, не каждый хеш таким образом подобрать можно, но еще надо учитывать человеческий фактор, что на практике поможет получить результат А вобще конечно оригинальный способ, но слишком много условий должно выполняться для этого, незнаю, мож я не обращал внимания на такие вещи, когда просто все знаки фильтруются (ну понятно о чем я), обычно или вобще нет никакой филитрации в order by или значения для sql запроса берутся с помощью конструкции switch...case, при первом варианте обычно есть возможность провести скуль инъекцию, при втором нет, а твой метод для промежуточных вариантов, когда кодеры сами себя обхитрили, непонятно для чего, хотя могу и ошибаться
Боян, еще старая тема, об этом не где не писалось но логически догадаться не сложно Так же в моем случаем можно было - Подбирать названия колонок - Использывать посимвольный перебор через Benchmark в на 4.1 > - Узнать AND в Как для различный иньекций... - Так же можно узнать юзера, если база запушенна под непривелегерованным юзером, если даже отколючен вывод ошибок добавляем /**/from/**/mysql.user/*и далее нам пишет доступ в users такомоту юзера запрещен. То что привел автор не имеет не какого различия, так как админские пассы редко бывают легкими. p.s. Такие баги очень часты, в различных системах статистик, а так же партнерках ведущих подробную статистику.
1. согласен с diehard - нужна большая база хэшей. 2. идею можно приспособить и для group by в инъекциях. когда есть траблы с выводом ошибок.
Хорошие отзывы, я рад . Хотел бы добавить, что методика не отработана, нужно подумать что она еще может дать. Хорошее замечание сделал +toxa+, если есть соль, то все это дело не прокатит. Вообще суть сводится к тому что в условиях хорошей фильтрации в запросе вида SELECT ...... FROM users ORDER BY $order мы можем поставить в переменной $order поле пароля. т.е. при условии что на $order стоит фильтр который не дает провести полноценный иньект, мы все равно можем получить нужную инфу. 2 [ cash ] согласен с тем что логически догадаться не сложно, просто я нигде не видел описания....., по поводу админ пассов тоже верно, но эта же проблема не снимается когда мы получили полный хеш при стандартной скуле, и в моем случае не было возможности или я просто не сумел это дело найти.
