Я думаю данный движок тоже можно отнести к форумам, вопрос, где эта тварь хранит пароли, и в каком виде? В дампе базы есть нечто на них похожее. 1. a1b62ad9 - значение у всех юзеров 8ми значное, пробовал сравнить с хэшем своего пароля, ни один из вариантов не похож. 2. bd665d4fc926739ea05b000f8ebf9cf8 или 56f6e33137befe9f20aac19c600afc511ace95bd как видите значение 32 и 40 знаков, так же на мой парль не похоже, 32 знака у юзеров не бывавших на форуме, 40 у тех кто хоть раз был на форуме. 3. есть ещё одно значение, но оно есть только у тех кто был на форуме. Вопрос. А что здесь хэш пароля, он здесь вобще есть? Или это всё не то и надо искать дальше?
bd665d4fc926739ea05b000f8ebf9cf8 - пароль захешированный алгоритмом MD5 56f6e33137befe9f20aac19c600afc511ace95bd - пароль захешированный алгоритмом MySQL5 Тебе скорее всего нужны вторые пароли, тех, кто уже был...среди них будет и админский вероятно... И может RunCMS, а не RunSMC?
Ночью сидел, изучал движок...на самом деле интересно было самому поглядеть... Ну так вот...там, как оказалось, нестандартный способ хэширования данных, ох какой нестандартный...) Поясню... Когда регистрируется новый пользователь на подобном сайте его пароль хэшируется простым алгоритмом md5, но как только он заходит в свой аккаунт хэш меняется, причем кардинально... Теперь по порядку... Есть пользователь с паролем 123123, только что зарегистрировался... Его хэш - 4297f44b13955235245b2497399d7a93, salt отсутствует вовсе... Но как только он зайдет в аккаунт его пароль чудесным образом хэшируется алгоритмом sha-1 + добавляется pwdsalt...которая состоит из 4-ех аж символов... Получается, что sha-1 (HMAC), но не тут то было...не брутит он и все... А теперь примеры с кодом. Страница регистрации (register.php), ввод пароля: Code: $newuser->setVar("actkey", substr(md5(makepass()), 0, 8)); $newuser->setVar("pass", [COLOR=Red]md5[/COLOR]($passw)); Страница, где производится вход в аккаунт -->ввод пароля: Code: function login() { sleep(1); $uname = !isset($_POST['uname']) ? '' : trim($_POST['uname']); $pass = !isset($_POST['pass']) ? '' : trim($_POST['pass']); if ($uname == '' || $pass == '') { redirect_header("user.php", 1, _US_INCORRECTLOGIN); exit(); } $user = XoopsUser::login($uname, $pass); if (false != $user) { if ( 0 == $user->getVar('level') ) { redirect_header("index.php", 5, _US_NOACTTPADM); exit(); } include_once(XOOPS_ROOT_PATH.'/class/[COLOR=DarkOrange]sessions.class.php[/COLOR]'); $session = new XoopsUserSession(); $session->setUid($user->getVar('uid')); $session->setUname($user->getVar('uname')); $session->setPass($user->getVar('pass')); [COLOR=Red]$session->setSalt($user->getVar('pwdsalt'));[/COLOR] if (!$session->store()) { redirect_header("index.php", 1, _NOTUPDATED); exit(); } Как видим добавляется соль, но не видем почему меняется пасс... В файле sessions.class.php находим такие строчки: Code: ... $db->query("DELETE FROM ".RC_SESS_TBL." WHERE uid=".$this->uid); $this->hash = [COLOR=Red]rc_shatool[/COLOR]($this->pass.$this->salt); ... И видем непонятную функцию rc_shatool...лезем в functions.php Code: ... function rc_shatool($vara='', $varb='', $varc='') { if (function_exists('sha1')) { $shatool = 'sha1'; // [I]правда что-то эта надпись начинает напоминать...[/I] } else { require_once XOOPS_ROOT_PATH."/include/[COLOR=DarkOrange]rcsha.php[/COLOR]"; $shatool = 'rcsha1'; } ... Переходим в rcsha.php и читаем комментарий в начале страницы: Code: ** PHP implementation of the Secure Hash Algorithm, SHA-1, as defined ** in FIPS PUB 180-1 * ** Version 1.1 ** Copyright 2002 - 2003 Marcus Campbell ** http://www.tecknik.net/sha-1/ Из чего мы делаем вывод, что да, вот он, алгоритм sha-1! Правда соленный получается, потому как добавляется pwdsalt, то бишь выходит sha-1 (hmac), но нам от этого легче не становится... Примеры пароля 123123: 7f7e0aadf63ed2e5b527c4b23beabab3892b81e7:9c54 06b3e18deab1e5e3365853925f7559ede5838421:b39e 87e29d7e0d6fe5d46897a13e1b1b792ae6974a7c:0a3b 2bd654cf49f953b8b9a8aec27f2bf66c8bc07655:cec2 Я так и не смог докопаться до истины, но надеюсь, что небольшое повествования о том, как я искал ответ на вопрос о том, как же все-таки алгоритмом хэшируются данные в этом движке, вам поможет... P.s. Тестировал как на данной версии движка, так и на последней 1.5 RC1... P.ss. Надеюсь ничего не напутал и рассказал все правильно...
Будут ли какие-нибудь предположения что тут и как... Как например подобных хэш брутить... Я не смог до конца разобраться... У кого какие соображения по этому поводу...?
Вообщем-то поставил щас тоже на локалхост двиг этот. Особо сильно не вникал. Прояснил тока, что при регистрации пароль шифруется простым MD5. Потом при первом посещении происходит так: rc_shatool($uname.$pass); Грубо говоря из БД берётся наш НИК и наш ПАРОЛЬ. Допустим admin:12345 rc_shatool как мы уже выяснили это sha-1. Получим следующее: sha-1(admin12345) d4e8e6deaa7b1f8381e09e3e6b83e36f0b681c5c - вот эту строку я и нашёл в БД. Отсюда возникают мысли, как это расшифровывать.. Пихаем хеш в пассворд про.. Ставим SHA-1. Атаку по маске. Ник нам известен. Ставим admin?d?d?d?d?d Это в данном случае, т.к. мы знаем что пароль у нас из цифр =). Ставим минимальную и максимальную длинну пароля. И жмём на кнопачку. Все пароли найдены =)) p.s. После установки движка сразу бросилась в глаза ошибочка грамматическая. Вместо ГЛАВНАЯ написано ГЛАНАЯ. Переводчик видимо был уставшим =)) Решил посмотреть подобные сайты в сети.. И сразу наткнулся на сайт http://minimake.spb.ru/modules/news/ Там даже не попытались её исправить =))
2470c0c06dee42fd1618bb99005adca2ec9d1e19 : password алгоритм Мускл5 но это на версии 1/3a и кстати никакой соли. Koller - респект
Runcms Прочитал посты. Узнал, что один мой друг показывал эту статью разработчикам RunCMS, на что те ответили, что это все бред и пароли шифруются не так. Решил разобраться сам и узнать "в чем тут соль" =). Версия : Runcms1.5.1 build 20070306. Как говорилось в предыдущих постах, в данном движке пароли хранятся в несколько необычном виде. При регистрации в таблицу runcms_users заносятся данные о пользователе, в том числе и хэш пароля, который хранитя в поле pass. Алгоритм шифрования - простой md5. В этой таблице также присутствует поле pwdsalt с некоторым значением из четырех символов, которое, судя по всему, является солью, с помощью которой шифруется пароль. Но это не так, движок RunCMS НЕ ИСПОЛЬЗУЕТ для шифрования паролей соль. В этом мы сейчас убедимся. Далее, при первом заходе пользователя, содержимое поля pass и pwdsalt меняется. В поле pass пароль теперь шифруется алгоритмом sha1($username.$password). Соль по-прежнему не используется. При последующих аутентификациях данного пользователя пароль остается неизменным. Почему мы можем быть уверены в правильности определения алгоритмов и уверенности в том, что соль не используется? Можно залезть в код, а можно сделать по-другому. Создадим непосредственно через MySQL нового пользователя. Пускай имя у него будет test, пароль qwerty, хэш которого имеет вид: d8578edf8458ce06fbc5bb76a58c5ca4 . Запрос к базе данных будет следующим : Code: INSERT INTO runcms_users SET uname='test', pass='d8578edf8458ce06fbc5bb76a58c5ca4'; Можно было указать rank( "уровень" пользователя, определяющие его права, у админа rank 7, дефолтно присваивается ранг 0, т.е. права только на просмотр ) и соль pwdsalt с любым значением, не превышающим длину в четыре символа. Логинимся и что мы видим? А видим мы следующее: "Thank you for logging in, test". Мы зарегистрировали обычного пользователя с нулевыми правами. Посмотрим поля uname,pass,pwdsalt в таблице runcms_users. Мы видим что изменилось значение поле pass и pwdsalt. Смотрим в PasswordsPro и видим что это алгоритм sha1($username.$password). Можно убедиться, что никаких подводных камней типа взятия этого значения и соединения с солью с целью получения чего-то большего и сохранения в другой таблице нет, при осуществлении следующих действий. Создадим нового пользователя указанным выше способом, только в поле pass запишем хэш, сформированный алгоритмом sha1($username.$password) . Пускай это будет пользователь 'pilot', пароль у него будет 'zxcvbn', соль - 'tyui', хотя поле pwdsalt можно оставить пустым. Вот соответствующий запрос к базе данных : Code: INSERT INTO runcms_users SET uname='pilot', pass='faa840a3851ce61124de53a74102accca3c9cc63', pwdsalt='tyui'; Логинимся и снова видим приветливую надпись "Thank you for logging in, pilot". Таким образом, мы убедились, что соль при шифровании паролей не используется и хэш пароля зашифрован при помощи алгоритма sha1($username.$password), который может быть расшифрован при помощи PasswordsPro. При выполнении вышеописанных действий мне пригодились знания, полученные из предыдущих постов, спасибо! В код двига я не смотрел, мне кажется, что необходимую информацию мы получили и без этого. Некоторая информация по движку Runcms, возможно, кому-нибудь понадобится : -------------------------------------------------------------- Таблица пользователей: runcms_users поля в таблице runcms_users( не все, но, как мне кажется, самые значимые ) : uid | id пользователя uname | имя пользователя email | мыло pass | хэш пароля pwdsalt | соль rank | ранг пользователя(значения 0-7), обычно у админа ранг 7, user_icq | uin пользователя -------------------------------------------------------------- Примечания: -В двиге есть некоторая система безопасности, она реагирует на неразрешенные символы в запросе. При срабатывании этой системы, запрос и ваш ip записываются в файл с именем "/cache/abuse-".$ab_time.".log" . При sql-inj cистема срабатывает на функцию concat и символы начала комментарий "/*" и "--", но тем не менее sql-inj может быть проведена и без этих символов. -Как правило, данные выводятся по одному, поэтому приходится использовать limit чтобы узнать все содержимое таблицы. Спасибо за внимание )
