Прощай, тётя Ася!

asu4ka

В статье описываются проблемы безопасности связанные с использованием программ мгновенного обмена сообщениями в корпоративной сети и предлагается несколько вариантов запрета использования подобных программ.

Различные системы мгновенного обмена сообщениями пользуются огромной популярностью со стороны пользователей и не меньшей ненавистью со стороны руководителей и администраторов. Лидерство несомненно принадлежит программе ICQ во всех разнообразных её вариантах. В расхожей фразе ICQ называют «Зеленым цветком на могиле рабочего времени».

Чем же так досаждает «тетя Ася» руководителям всех рангов, и как следствие взмыленным администраторам? Причин, как водится – множество.

Первая, конечно, это то количество рабочего времени, которые пользователи убивают «Обсуждая с клиентом детали операции», а как правило обмениваясь свежими и не очень анекдотами или флиртуя в сети посредством этой милой программки. Как показывает практика, для деловой переписки все же больше подходит email, а для оперативного обсуждения – телефон. Наиболее деловой фразой, передаваемой по ICQ, обычно являются вариации на тему «Пойдем покурим, потрещать надо!…» и соответствующие ответы.

Следующей угрозой является то, что ICQ является неконтролируем каналом утечки информации из внутренней сети. В отличии от Web и email на настоящий момент не существует приемлемых систем фильтрации содержимого для промышленной эксплуатации, ориентированных на ICQ. Поэтому, у многих страдающих паранойей руководителей, ICQ вызывает негативные эмоции.

Наиболее актуальной для администраторов является угроза целостности сети, которая возникает при использовании систем мгновенного обмена сообщениями. Написанные третьими производителями, созданные с целью предоставить максимальный комфорт и функциональность пользователю данные системы обладают огромным количеством довольно серьезных уязвимостей, зачастую не закрываемых годами. Естественно, уязвимости существуют во всех программах, но дело усугубляется тем, что программы типа ICQ не включаются в корпоративный план управления обновлениями, устанавливаются и поддерживаются самими пользователями. Производители редко обращают внимание на найденные и обнародованные уязвимости, ограничиваясь закрытием их в новой версии, естественно, пользователи работают на старых версиях программы. Ну кто из пользователей читает bugtraq?

Соответственно, программы подобные ICQ, являются прекрасным вектором для распространения сетевых червей, даже без использования присутсвующих в них уязвимостей. Только радует, что уязвимость «object-data» в Internet Explorer пока не была использована подобным червяком. Представьте себе следующий сценарий:

• к вам приходит сообщение от человека из вашего списка контактов, содержащее ссылку на Web страницу с припиской а-ля «He-he-he!».
• открыв эту страницу в IE вы получаете себе на машину червяка, который превращает вашу машину в Web сервер, содержащий вредоносный код, а затем отправляет ссылку на него далее по списку контактов.

Для повышения вероятности заражения можно использовать несколько ссылок, на тот случай, если машины разделены межсетевым экраном, запрещающим прохождение HTTP трафика. Скорость распространения подобного червя будет огромна. У червя не возникает необходимости сканирования, поиска уязвимых машин, их список предоставляются самим ICQ клиентом.

Встроенные в некоторые клиенты функции автоматического обновления настолько далеки от совершенства, что я удивляюсь, почему злоумышленники до сих пор не обратили на них внимания.

Однако запретить использование ICQ в корпоративной сети весьма непросто. Производители позаботились о максимальном комфорте пользователя и максимальной головной боли администратора. ICQ может взаимодействовать с сервером по любому открытому TCP, поддерживает посредники сеансового уровня socks 4 и socks 5, посредники HTTP и HTTPS (метод connect). Соответственно, разрешая на межсетевом экране любую службу вы отрываете пользователю путь к вожделенному коннекту. Для самых ленивых в ICQ встроена даже функция «авто настройки», суть сканирования, для определения того, по какому номеру порта доступен сервер AIM.

Запрет на межсетевых экранах IP адресов серверов ICQ подвигает наиболее продвинутых пользователей на использование анонимных серверов – посредников для подключения к серверам. Что же делать?

Во первых, у меня существует глубокое убеждение, что для нормальной работы пользователю достаточно доступа к ресурсам внешней сети через посредник уровня приложений по HTTP.

Затем мы запрещаем на межсетевом экране соединение с серверами AOL (64.12.1.1 - 64.12.255.255) или просто *.icq.com.

При соединении через HTTP туннель ICQ сервер в http запросе рапортует, что данные он вернул в формате MIME aim/http (заголовок HTTP Content-type: AIM/HTTP). Для запрета данного типа MIME на ISA создается новое правило Site and Content Rule запрещающее всем пользователям обращаться ко всем серверам если запрос или ответ попадает в Content Group aim/http (естественно, перед этим её необходимо создать).

Если используется сервер SQID, то для запрета можно воспользоваться следующим правилом:

 
acl aim_http reply_mime_type -i ^aim/http$ 
http_reply_access deny aim_http

Что бы дополнительно усложнить жизнь любителям ICQ на сервере ISA можно потребовать, что пользователь проходил аутентификацию, используя метод Integrated (NTLM), что сразу отсечет большую часть чатлан, поскольку клиент ICQ данного типа аутентификации не поддерживает.

Однако в довершение всех непотребств, клиент ICQ может взаимодействовать с внешней сетью через HTTPS, используя метод Connect. Если пользователи освоят и этот метод настройки соединения, то перечисленные ранее способы запрета ICQ (за исключением аутентификации Integrated на ISA) окажутся бессильными.

В этом случае нам могут помочь сетевые системы обнаружения атак. За пятнадцать минут исследования протокола обмена клиента ICQ с сервером по HTTPS туннелю я обнаружил, что большая часть трафика передается в открытом виде и обнаружил некоторые закономерности, которые были использованы при написании следующих правил для NIDS Snort.

# icq.rules 
# snort rules for ICQ http/https tunnels 
# (c)ded by asu4ka 2003. 
# v 0.0.0.1 

var PR_IP x.x.x.x 
var PR_TCP 8080 

alert tcp any any -> $PR_IP $PR_TCP (msg: "ICQ HTTPS/HTTP _basic_, mf!";\ 
flow: to_server, established; content: "ICQBasic";) 

alert tcp any any -> $PR_IP $PR_TCP (msg: "ICQ HTTPS _key_, mf!";\ 
flow: to_server, established; content: "<key>"; content: "</key>"; nocase;) 

alert tcp $PR_IP $PR_TCP -> any any (msg: "ICQ HTTP _aim/http_, mf!";\ 
flow: from_server,established; content: "AIM/HTTP"; nocase;)

Первое из них отрабатывает в том случае, если клиент после установки соединения с сервером посылает ему запрос, содержащий строку «ICQBasic». Это происходит при соединении ICQ с сервером.

Второе правило срабатывает в том случае, когда в запросе клиента обнаруживается строка содержащая теги . Они используются ICQ для загрузки различной дополнительной информации (например баннеров).

И последнее правило проверяет наличие строки AIM/HTTP в ответах сервера и принципе дублирует запрет Content-type: AIM/HTTP на серверах-посредниках. Использовать его я не рекомендую в связи с большой вероятностью ложных срабатываний.

Если вы хотите, что бы попытки соединения по ICQ не только отслеживались, но и разрывались сервером, вам необходимо собрать snort с поддержкой flexible-response (для чего необходимо наличие библиотеки libnet и в качестве ответа в правилах указать тип ответа resp: rst_all. Весьма внимательно относитесь к использованию flexible-response, пару раз я умудрялся «зациклить» snort и убивать tcp направо и налево.

Использование IDS поможет и в том случае, если пользователи попытаются использовать установленные на их компьютерах посредники поддерживающие NTLM аутентификацию.

«А как же Real Secure!!!» воскликнут разведенные на кучу бабок админы, глядя на консоль Site Protector. «Мы тоже хотим убивать тётю Асю!». Не беспокойтесь. Просто зайдите в свойства сетевого сенсора и укажите TRONS файл с правилами snort. Дополнительно могу посоветовать «убивая» ICQ дать людям удобоваримую альтернативу. В одной компании я просто развернул на машинах Microsoft IM client таким образом, что бы он ходил через корпоративный Exchange. После пары дней ворчания, даже бухгалтерия просила «поучить их работать со снеговиком». Тем более он прекрасно развертывается и настраивается через групповые политики, а так же поддерживается Microsoft и производителями антивирусов.

Теперь немного о правовых аспектах. Перехватывая сообщения и ICQ и Email, не имея при этом согласия отправителя, вы нарушаете законы Российской федерации. На моей памяти проскальзывало несколько прецедентов, когда пользователи подавали в суд и выигрывали иски за незаконную перлюстрации их корреспонденции. При чем «политики безопасности» и т.д. созданные, как правило, задним числом не принимались в качестве ощутимого доказательства невиновности шпионов.

Таким образом, если у вас действительно существует необходимость хранения и анализа сообщений пользователя, необходимо получить от каждого из них письменное согласие на подобные действия. Иначе «посодют».

PS. Любители ICQ, не расстраивайтесь! Все описанные здесь препоны можно обойти, если приложить голову и руки. Но я бы посоветовал отключить ICQ на пару дней и попробовать поработать. Глядишь, понравится. Но сильно привыкать к работе я тоже не советую.

PPS. В статье умышленно не рассматривается использование персональных межсетевых экранов как метода запрета использования несанкционированного сетевого ПО. Хотя вещь несомненно полезная.

PPPS. Администраторы компании, в которой я работаю на настоящий момент. Если в один прекрасный день я приду на работу и ICQ будет тоскливо взирать на меня печальным красным взглядом, я за себя не ручаюсь. Так что… Ну это так, на тот случай, если вы читаете SecurityLab.