Intro
============
На написание этой статьи меня вдохновила статья из defaced7
"The remote system reboot" (0х06.txt).
А точнее найденные баги в алгоритме авторизации этой remote system reboot.
Сама идея - интересна, безусловно, НО, один серьезный баг, который позволит обойти
авторизацию на сервере, лежит там "на блюдечке с голубой каемочкой" ((с)
Золотой Теленок ).
В общем-то из-за того что идея мне понравилась, и из-за этого бага, я решил взяться
за реализацию своей версии этой же тулзы, но не для ребута системы, а для выполнения
любой команды на сервере которую вы пропишите в файл конфигурации. Система работает
как на windows так и на nix платформах (хотя на windows нереализована функция
таймаута). Назвал я свой сервер - Simple Secure Command Server (SSCS).
Если все идет хорошо - значит ты чего-то не заметил... =============================================================
Итак, суть этой системы почти не изменилась - есть сервер,
есть клиент. Сервер запускается на NIX/Win машине на которой требуется выполнить
команду. Небольшой ньюанс - сервер должен запускаться из под пользователя
который имеет права для выполнения требуемой команды. Есть клиент, который
соединяется с нашим сервером, авторизуется на нем и получает доступ к
выполнению
команды прописанной в конфигах сервера. Я оставил все ту же идентификацию,
по IP, MAC, только вот откинул параметр OS и Name. Как говорилось в статье
df#7, все эти параметры подделываются легко, и это правильно, а попытки
определить
ОС могут отсекаться, и скорее всего отсекаются на фаэрволе (а в современном
мире без фаэра никуда - поэтому я и откинул этот параметр в авторизации.)
А теперь про тот самый баг, который и делает возможным авторизоваться на сервере
челу с соседнего компа, или выражаясь словами статьи - "горе-хакеру".
Для того чтобы не быть голословным, я приведу один абзац из статьи, из которого
станет ясно даже неискушенному хакеру, что взлом авторизации не так уж сложен,
как нам это представляет автор.
" Если наши данные (IP+MAC+NAME+OS) найдены в accept.ini*, то шлюз
переходит ко второй части авторизации - просит ввести пароль. Введённый
КЛЮЧ шифруется с помощью MD5 на клиентской стороне** и полученный хеш
ПЕРЕДАЕТСЯ серверу. После этого он сравнивает два хэша и если они
равны - осуществляет перезагрузку компьютера. В результате в нашем
проекте мы используем вполне безопасный метод передачи данных. Ещё
один плюс в нашу копилку."
* - допустим нам удалось подделать IP,MAC,OS-NAME, что несложно (читай в df7
статье как).
** - а вот и баг - ПАРОЛЬ шифруется и ПЕРЕДАЕТСЯ (пускай и в виде хэша)
на сервер для сверки (он хоть и шифрованный, но передается по сети по незащищенному
соединению:)
Так что это скорее минус из копилки :)).
Алгоритм взлома:
==========
Мы снифаем сеть, отлавливаем хэш пароля с нужного нам IP,MAC,OS,NAME,
затем, запускаем у себя собственного клиента (смотри zloclient.pl в архиве),
подделываем атрибуты IP,MAC,OS,NAME и когда сервер запрашивает пароль - отправляем
ему соснифанный хэш.Теперь я думаю ясно, что это за "безопасный метод передачи
данных" :))). Для примера - я просто запустил север на одной машине, и снифер
на другой. Затем запустил клиента с машины на которой стоял снифер, и вот что
отловил:
рис.1 Перехваченный хэш пароля
сниферром ettercap
Как видите все не так гладко как написано в df7... Взлом
очень вероятен. Я бы даже сказал вероятность взлома такой системы приближается
к 100%. Все упирается в вопрос "А оно тебе надо?"... Но возниконовение
этого вопроса - лишь дело времени. Я написал простейший скрипт, который
ребутит систему, взаимодействуя с севером из статьи defaced. Его код
есть в аттаче к статье. Ему вы скармливаете IP сервера, порт, и md5 хэш.
Enjoy!
рис.2
Пример использования хэша пароля для авторизации.
"Второй этап - это авторизация по ключу, он весьма
надежен! Ключ большой длинны будет очень сложно подобрать даже массовым
брутфорсом." (с) defaced#7. Как видите - массовый брутфорс не требуется.
Длина вашего ключа - вообще не играет роли (а длина md5_hex всегда 32
байта:), так как при таком способе авторизации смысл в криптовке пароля
по md5 вообще отсутствует, так как хэш выступает полноправным паролем
на сервер.
Альтернативное решение.
===============
Я вам предлагаю куда более надежный и более безопасный
алгоритм (безопасный от снифферов).
Его суть - в трехступенчатом хэндшейке (1.от сервера 2.к серверу 3.от сервера
- не считая того что коннект возможен только с "правильных" IP+MAC),
без передачи по сети паролей (или их хэшей).
Аутентификация производиться при помощи ключей (только не тех про которые
написаны в статье df7, там это не ключи, а просто хэши паролей). Ключи эти
генерятся на основе рандомной строки и хэша md5 в hex пароля по алгоритму
HMAC-SHA-1. Пару слов об этом алгоритме. HMAC (Hash-based Message Authentication
Code – хешевый код идентифицирования сообщений) - это алгоритм аутентификации
с секретным ключом. Целостность данных и аутентификация их источника, обеспечиваемая
им, зависит от масштаба распространения секретного ключа. Если ключ HMAC
известен только передающей и принимающей сторонам, это обеспечит и аутентификацию
источника данных, и целостность пакетов данных, пересылаемых между двумя
сторонами. Ключи для HMAC генерируются посредством процедуры ISAKMP/Oakley.HMAC-MD4
дает большую безопасность чем MD4, а HMAC-SHA большую чем просто SHA. Если
отсортировать алгоритмы в порядке повышения их надежности, то получится следующий
список:
MD4
MD5
SHA
SHA-1
HMAC-MD4
HMAC-MD5
HMAC-SHA
HMAC-SHA-1
Как было сказано выше - наша система работает с последним алгоритмом из этого
списка. Ключом в нашем случае является хэш пароля MD5, он (как и сам пароль)
известен только серверу и клиенту, поэтому можно говорить о "безопасной
передаче данных". В нашем случае применяется SHA-1 с 32 битным ключем,
маловато - но сойдет для такой в общем-то не очень глобальной задачи, тем
более вы всегда можете модифицироавать этот параметр (рекомендуемая длина
ключа 256 бит). Не стоит применять в данном случае в качестве ключа рандомную
строку - так как она известа может быть не только серверу и клиенту, это
я думаю и так понятно.
Итак, алгоритм.
Сервер запущен, конфиги считаны, хэш пароля имеется (все как в алгоритме
от defaced, разве что хэшированный пароль я храню в конфигах, это опять же
плюс в нашу копилочку.. Потому что если вы запускаете сервер с паролем, который
задается из командной строки, да и еще прописываете это в Автозагрузку (см.
советы в конце статьи df7), то локальный взлом и пароль у вас на руках в
своей девственной чистоте - plaintext'e :)))).
Клиент подключился, сервер ищет IP и MAC в конфиге, находит и запрашивает
у клиента пароль (если не находит - отключает клиента без лишних вопросов.)
Пользователь вводит пароль и если пароль правильный - подключается к серверу...
Стоп стоп стоп!!! А где же разница между моим алгоритмом и алгоритмом из
df, спросите вы? А теперь о разнице. Пользователь не должен знать всего,
оно ему и не надо... Но для читателей я приоткрою занавес :)), этого "мудреного" алгоритма.
Итак, что происходит на самом деле? Сервер заместо того чтобы послать запрос
пароля, выдает клиенту случайную строку вида: W3Tt456GGbsOyDSGDSmnGH%gSZG@#FSjkljl632
, либо любую другую. Пользователь этого ничего не видит, он просто вводит
пароль на приглашение, как ему кажеться сервера ( на самом деле это приглашение
клиента), клиент считывает строку, затем хэширует пароль который ввел пользователь
(MD5), затем передает этот хэш вместе со случайной строкой полученной от
сервера в функцию hmac-sha1 (в коде hmac_sha1_hex), которая на основе этих
двух параметров генерит строку для аутентификации. Полученную в результате
криптовки строку клиент пересылает серверу. Сервер читает строку, затем используя
хэш пароля из конфигурационного файла и отправленную случайную строку повторяет
алгоритм hmac-хэширования, и сравнивает полученный результат с результатом
который прислал клиент. Если строки совпадают, то клиент будет допущен в
систему.
Попытка взлома.
=======================
А теперь представим хакера который проснифал наше общение с
сервером. Он снифает рандомную (случайную) строку, он снифает отправленную
криптованную строку. Далее, сам хватает клиент, запускает, коннектиться
с
серваку (подделав IP и MAC), сервер шлет ему рандомную строку, хакер, отсылает
ему соснифанную криптованную строку и сервер... посылает его куда подальше..
Рандомная строка уже другая и криптовнная строка будет другой. Вот
и вся мощь
этого алгоритма. И не нужно OS,NAME. В принципе не нужно и IP, и MAC. По
моему в статье df все это навешано - как говориться "от ведьм".
Можно было бы еще прикрутить версию IE :))... Шутка. Лучше прикрутить
для того чтобы обезопаситься от брутфорса - blacklist (в статье от
df упоминается об этом - но почему-то не реализовано), в который будут
вноситься неудачно авторизовавшиеся клиенты (например более 5 раз,
как в моем примере). Все остальное вы найдете в коде к статье. Да еще
надо сказать, что конфиги я расположил в XML файле, поэтому для конфигурирования
сервера, вам придеться немного знать синтаксис XML а лучше написать
свой конфигуратор на Perl (в качестве домашнего задания :)) Используйте
модули XML::Simple и аналогичные для этого...В общем, пользуйтесь и
дорабатывайте. Никто не безупречен, нет того что нельзя взломать, просто
есть разный уровень :)).
Заключение
=========================================
В заключение, я хотел бы заметить, что существуют законодательные
ограничения на использование тех или иных алгоритмов шифрования, которые
существенно отличаются от страны к стране. Стоит отметить, что на территории
Российской Федерации официально позволено применение лишь криптографических
средств сертифицированных ФАПСИ. Объясняется это заботой о безопасности
граждан, поскольку всегда существует вероятность существования в алгоритмах
так называемых «закладок» при помощи которых их создатели легко могут
расшифровать шифротекст без обладания секретным ключом. Насколько свободны
от «закладок» алгоритмы предлагаемые российскими спецслужбами, можно
только догадываться, опираясь на многочисленные свидетельства чистоты
их рук. Поэтому если вы внедряете тот или иной алгоритм в свое приложение,
распрастранять которое вы планируете официально, то вам немешало бы
знать законы относительно использованных вами стандартов. А вообще,
полностью доверять можно только открытым алгоритмам, и естественно
проанализированным экспертами на предмет "закладок". Либо
доверять вашим собственным алгоритмам... Но для их разработки нужно
очень много знать и трудиться, особенно в области математики. Удачи!
8.03.2005 (c) PoizOn
|
