В начале немного о радмине (для исследования применялся метод тыка )... - Сервер хранит хэш пароля в реестре: HKEY_LOCAL_MACHINE\SYSTEM\RAdmin\v2.0\Server\Parameters "Parameter"=hex:02,ba,5e,18,7e,25,89,be,6f,80,da,00,46,aa,7e,3c // Пароль 12345678 Пароль шифруется алгоритмом MD5, причём сначала пароль дополняется нулевыми символами до 100 символов, тока потом шифруется Проверил... работает!! - В справке по радмину говорится: "Radmin работает в режиме шифрования...все данные передаваемые между компьютерами...шифруются случайно генерируемым ключем. Используется 128 битный Twofish алгоритм..." Думаю мона поверить разработчикам... Или нет!? Запускаем сниффер, допустим Ириску... Содержимое пакетов (данные в hex) при авторизации по паролю: 1) Клиент: 01 00 00 00 01 00 00 00 1B 1B - 10 байт 2) Сервер: 01 00 00 00 21 A8 99 B4 A7 1B 2A 5F 62 5E 69 EA 5E 82 8C 1D 41 63 1E F7 B7 10 B7 9D 7D D2 0F 92 97 E8 C1 59 82 2E ED B1 56 51 - 42 байта 3) Клиент: 01 00 00 00 21 89 2D 73 BC 09 5D 00 4E F9 3A CF 71 13 EA B4 D0 B0 F0 A8 F8 F7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 42 байта 4) Сервер: 01 00 00 00 01 00 00 00 0A 0A - 10 байт Предположение: 1) Похоже на обычную команду с кодом $1B1B, предложение на авторизацию 2) скорее всего ключ для шифрования пакетов 3) Введённый пароль!!! А точнее его хэш (по логике MD5 хэш, как и в реестре у сервера), т.к. размер ответа ВСЕГДА 26 байт (не считая 16 нулей). 4) Результат авторизации, $0A0A - всё в порядке, $0B0B - неудача Написал на делфи переборщик для "ключа" (2) и "зашифрованового пароля" (3)... использовал компонент TDCP_twofish. При расшифровки (3) ключом (2) ожидалось найти MD5 хэш пароля 12345678: 02 ba 5e 18 7e 25 89 be 6f 80 da 00 46 aa 7e 3c Ничё не получилось ... Почему? - Может передаётся по сети не MD5 хэш пароля, а какой-нить другой, но точно хэш - Может трафик шифруется не 128 битным Twofish Если ты знаешь больше или я где-то ошибся, напиши плииииииииииииз!!!!
Так, интересно... Заметь, 01 00 00 00 подозрительно повторяеться. Возможно сам ключ лежит в байтах ПОСЛЕ повтора, или ещё дальше.
Регился на 8 форумах, там народ ваще вялый, похоже antichat рулит Так что давайте мозговать!!! Попробуйте тоже поснифать трафик, разобратся в кодировках.... Кста пробовал запускать клиента радмина из отладчика (Olly debuger), ставил брики на вызовы функций, но ОЛЯ что-то глючила . Предпологаю, что авторизация в радмине проходит так: Клиент считывает символьный пароль, получает из него хэш (например MD5 длиной 16 байт), затем получает от сервера случайный ключ, шифрует хэш пароля (например TwoFish-ем), и отсылает серверу... Сервер получает шифр, зная ключ, восстанавливает хэш пароля и сравнивает его с хэшем из реестра. Получатеся, что настоящий пароль в чистом виде никогда нигде не храниться, разумно так-то Если разберёмся с шифрование сетевого трафика, я смогу написать прогу, чтобы мона было авторизоватся по хэшу пароля.... ЖДу ваших наработок и предложений!!
хай, а может не хеш отправляетса, а сам пароль ??? если на CPAN есть модуль для Twofish то вечерком проверю
Именно хэш!!! потому что длина пакета постоянна. ОТкрой в радмине "обмен файлами"...поснифать трафик именно этот трафик....при расшифровке пакетов стремись получить имена папок, в которые заходил радмином!
Незнай....найдёшь кинь линку.... я скачал компоненты для делфи DCPCrypt2, там есть реализация TwoFish-а! В пакетах есть маленькая закономерность, не угледел сразу вот две пары пакетов с ключом и хэшем пароля...я разбил их на логические блоки: Сервер: 01 00 00 00 | 21 | 2F 19 31 2F | 1B | 09 86 BE C7 5C 68 00 E9 16 9B 0B DD 18 87 BB 81 85 94 E4 EA C5 A8 D0 DF DD 04 1F C0 71 C6 D4 7D Клиент: 01 00 00 00 | 21 | FA E2 1E 80 | 09 | C3 B8 19 A2 BA D5 B1 FE CF 45 A2 A1 D0 0D 8D 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Сервер: 01 00 00 00 | 21 | EE E1 B0 2D | 1B | 07 F3 66 3D E1 53 24 45 BD 9E 78 61 FC 2B 88 A2 EC EE A3 00 30 76 A2 3D BD D6 65 57 33 94 B6 F9 Клиент: 01 00 00 00 | 21 | 09 14 45 1F | 09 | 0E 68 FE 09 FF 6B B0 BB 9E 3F DB 4C 99 00 7F 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 И всё таки шифрование смахивает на связку TwoFish + MD5... в пакете от сервера есть 32 случайных байта (если захешировать ключ, то получим новый ключ размером 16 байт = 128 бит), а у клиента 16 байт (нули не считаем ) - размер хэша MD5, MD4 и т.д. Не могу понять зачем в каждом пакете есть 4-байтовое случайное число (2F 19 31 2F, FA E2 1E 80.... )???????????????????????????? GluckX задумался..........
Прошла ещё одна бессонная ночь.... До меня дошло зачем эти числа , немного математики... Рассмотрим два ответа клиента: 01 00 00 00 21 | Fa E2 1e 80 | 09 | C3 B8 19 A2 Ba D5 B1 Fe Cf 45 A2 A1 D0 0d 8d 36 <нули> 01 00 00 00 21 | 09 14 45 1f | 09 | 0e 68 Fe 09 Ff 6b B0 Bb 9e 3f Db 4c 99 00 7f 06 <нули> Предположим, что первые 10 байт - это заголовок, а остальные байты - это данные... и так, если просуммировать все 4-хбайтовые слова данных, учесть переполнение, поменять местами 1 и 3 байты слева местами, получим: 1) C3b819a2 + Bad5b1fe + Cf45a2a1 + D00d8d36 = 31de0fb77 -> 3 | 1d E0 Fb 77 -> 1d E0 Fb 7A -> Fb E0 1d 7A = Fa E2 1e 80 2) 0e68fe09 + Ff6bb0bb + 9e3fdb4c + 99007f06 = 245150916 -> 2 | 45 15 09 16 -> 45 15 09 18 -> 09 15 45 18 = 09 14 45 1f Числа Fbe01d7A и Fae21e80, 09154518 и 0914451f похожи ... Получается, что эти числа контрольные суммы, точный алгоритм вычисления я не искал за ненадобностью, но он нам нужен будет, когда начнём менять данные в пакете Есть ключ 09 86 Be C7 5c 68 00 E9 16 9b 0b Dd 18 87 Bb 81 85 94 E4 Ea C5 A8 D0 Df Dd 04 1f C0 71 C6 D4 7d и зашифрованные данные C3 B8 19 A2 Ba D5 B1 Fe Cf 45 A2 A1 D0 0d 8d 36.... перебераем варианты алгоритмов шифрования %)
GluckX, я понимаю, что разобрав протокол по косточкам, можно сделать что угодно. Однако, возможно это не удасться реализовать. Потому, может быть будет достаточно самого снифинга начала авторизации, чтобы затем просто аналогично авторизоваться, используя отнифанный траф. Таким образом, задача сводиться к написанию программы, которая снифает траф(желательно АРП-пойзонингом), запоминает и дублирует его. Возможно, потребуеться спарить её со стандартным клиентом радмина(лучше 3-й версии) для более удобного юзания. Мы лишаемся возможности рашифровки трафа, но сохраняем способность заюзать отснифанный аккаунт, пуст он и в хеше. Там ведь привязка ключа по пасу, а не по айпи? Как думаешь? Это проще и вполне достижимо(но я не потяну, слабо)
Может быть, но надежда умирает последней !) Если бы ... не всё так просто: При установлении соединения сервер посылает СЛУЧАЙНЫЙ ключ для шифрования всех данных передаваемых по сети, получается для каждого нового соединения трафик буит УНИКАЛЬНЫЙ .... не факт, что ключ остаётся постоянным с течение времени... Что касается спуфинга, я написал реализацию MITM-атаки на WinPcap, чужой трафик снифать не проблема... Подменять трафик планирую на уровне сокетов, ставя хуки на вызовы функций (да поможет мне Рихтер )... Трафик... Трафик... Трафик... как же он зашифрован?!?! Не теряем надежду, нас много, а алгоритм ОДИН!!!!!!!!!!!
Автор я бы тебе помог если бы ты не использовал делфи... Может я что непонял, ты про какой спуфинг? Уж не айпи ли ты решил подставлять спуфеные?
KEZ можешь писать и на Си.... разберусь Принцип MITM (Man In The Middle - человек по середине) : Посылаем жертвам с айпи и маками (IP1, MAC1) и (IP2,MAC2) ложные арп-ответы, первой - (IP2,MAC), а второй - (IP1,MAC), где MAC - твой мак... Пакеты от жерт буду приходить на твой комп, меняешь маки в эвернет заголовке... и всё (минус разные тонкости ) Но речь не об этом!!!! Пока модераторы бы не переименовали тему, до меня бы не дошло, что у радмина свой ПРОТОКОЛ, похожий на стандартые IP,UDP,TCP и т.д. Вот как на данный момент я разбиваю данные пакета: 01 | 00 00 | 00 21 | FA E2 1E 80 | 09 | C3 B8 19 A2 BA D5 B1 FE CF 45 A2 A1 D0 0D 8D 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 - хз...всегда 01 00 00 - аналогично 00 21 - $0021 = 33 размер данных в RAdmin-заголовке FA E2 1E 80 - контрольная сумма 09 - код команды или ответа (получается, что входит в блок данных и учитывается при подсчёте контрольной суммы) C3 B8 19 A2 BA D5 B1 FE CF 45 A2 A1 D0 0D 8D 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - зашифрованная информация Забудим навремя о шифровании...займёмся математикой!!!!! Это полегче и интереснее.... Нужно найти алгоритм вычисления контрольной суммы, вот пару пакетов для тех кому лень снифать трафик 1) 01 | 00 00 | 00 01 | 00 00 00 1B | 1B | - 10 байт 2) 01 | 00 00 | 00 05 | 00 00 00 1E | 1A | 00 00 00 04 - 14 байт 3) 01 | 00 00 | 00 25 | 08 00 01 10 | 08 | 01 00 08 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 46 байт 4) 01 | 00 00 | 00 21 | 89 2D 73 BC | 09 | 5D 00 4E F9 3A CF 71 13 EA B4 D0 B0 F0 A8 F8 F7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 42 байта 5) 01 | 00 00 | 00 21 | B8 92 71 7E | 09 | D8 DF 7B D1 C6 B7 42 0F 00 F5 F3 16 D2 05 06 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 42 байта Включаем мозги, интуицую и вперёд.. жду результатов
Ты знаешь, я в курсе что такое Mitm, я непойму - ты пытаешься сделать радмин клиент, или проснифать передачу данных? Если второе - зачем?
Ох уж эти праздники... голова гудит...кста поздравляю всех девушек с прошедшим праздником %) Я не собираюсь писать радмин-клиент, я хочу разработать механизм взлома радмина в локальной сети, меня не устраивают такие варианты: - Сломав удалённую тачку, отмыть пароль кейлогером... и другие развраты с кейлогером - Сломав удалённую тачку, менять хэш пароля в реестре, чтобы логинется клиентом радмина по своему паролю... Ситуация такая: Есть две зафайрволенные тачки, на одной из них стоит сервер радмина, а с другой переодически запускается клиент радмина (допустим админ решил положить денжку на инет ) .... мы не обращаем на другие уязвимые программы типа фтп и т.д... Нас интересует только радмин!!!!!!!!!!!! Метод взлома: - Mitm атака -> cнифаем чужой трафик в момент соединения клинта с сервером радмина.... - Расшифровываем трафик, узнаём хэш пароля - Кто хочет может дальше брутить, но мы пишем программу, которая будет поменять данные отсылаемые клинтом радмина - Запускаем клиент радмина вводим левый пароль типа 123.... при передачи данных наша прогрммка подменит хэш пароля 123 на истинный хэш - Лазаем по удалённой тачке.... глумимся одним словом. P.S. Было упушено много тонкостей Ну и ещё одна причина - самоудовлетворение, радмин же ещё не сломали Приступаем к делу... помни "Возможно всё, что возможно вообразить!"
Все понял, ты просто хочешь сниффер. Я бы, скорее всего попробовал подизассемблировать сам клиент... Незнаю зачем тебе это нужно, если бы я работал сисадмином я бы не допустил возможности снифния, поставив бы роутеры и новые свичи и отгорадив от возможности рассылки пакетов куда ненужно (за счет денег главы конечно) и ещё утилиту с antinat.com ))
Да-да...правильно мыслишь..следующий шаг - это дизассемблеры и отладчики (всё времени нет поставить SoftIce, а в олике у мня не получается работать), но сейчас наша задача научится вычислять контрольную сумму!!!!!!!!!!!!!
Запылилась темка, почему не работаем?! Опять к шифрованию.... мы имели 32 байтный "ключ", и 16 байт зашифрованного хэша пароля...В справке говорится, что используется 128 битный TwoFish, т.е. размер ключа 16 байт, а у нас есть 32, какие байты брать под ключ!!!!????? Причём эти 32 байта случайные , вот бы сервер послал бы что нить похожее на 00 00 00 00.... поможем ему в этом Не вдаваясь в технические подробности, при передачи данных подменяем ключ сервера на нули и подсовываем клиенту. Вот что получилось: S: 01|0000|0021|0000001B|1B|0000000000000000000000000000000000000000000000000000000000000000 K: 01|0000|0021|95DA02C7|09|DBD7A441D5825F870CF80E884587826E00000000000000000000000000000000 И так количество итераций в переборе резко понижается, так как мы имеем всего 2 варианта ключа: буффер из нулей размером 16 байт иили 32 байта... Мы не знаем в каком виде искать расшифрованный хэш пароля (врят ли это MD5 хэш ), поэтому привожу ещё пару пакетов с "единичным" ключом: S: 01|0000|0021|08080823|1B|0101010101010101010101010101010101010101010101010101010101010101 K: 01|0000|0021|0717DE9F|09|E618767F641ED2BDBC583415D7878A4500000000000000000000000000000000 Ну что ж, можно начинать писать брутеры, меняя алгоритмы шифрования, результат считается успешным, если совпадут расшифрованные данные в 1-м и 2-м случаях (алгоритм шифрования же один!!!!) Жду хоть какой-то активности P.S. DBD7A441D5825F870CF80E884587826E и E618767F641ED2BDBC58 3415D7878A45 - это зашифрованные хэши пароля 12345678
13 09 5a 01 57 5c 69 5b d1 18 a7 ed 23 1d b0 4e Вот в реестре parameters пароль в таком виде, как-то можно его расшифровать и получить нормальный пароль?
