Любопытная статья и еще более любопытный документ. Названия тянут на бомбу, но по сути изложены очевидные вещи. Речь идет о безопасности протокола аутентификации владельцев карты 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 только требования и разделение ответственности.
Tuesday, December 6, 2011
Verified by Visa
Monday, November 28, 2011
Эволюция атак Drive-by Download
Выкладываю нашу презентацию на ZeroNights.
Для тех, кто не был непосредственно на конференции, хочется сказать пару слов о презе (пару слов о самой конференции скажу чуть позже, когда эмоции превратятся в мысли :-)).
Все что представлено в презентации является следствием нашего внимательного анализа событий систем обнаружения вторжений, антивируса и HTTP-прокси. Все показанные здесь события были взяты непосредственно из наших логов (которые по долгу службы мы должны смотреть), отражающих посещения Интернет наших пользователей.
Цель данной презентации ни в коем случае не оскорбить кого-либо, а привлечь внимание к проблеме и, возможно, найти более эффективные меры борьбы, чем мы тут сами пытаемся применять.
Вполне возможно, что у нас какая-то не та карма и в других сетях такие чудеса не наблюдаются, но мы вынуждены мириться, ибо мы защищаем наших пользователей каковы бы не были их интересы и какова бы не была наша карма.
Saturday, November 12, 2011
REG.ru нам не поможет :-(
Стали фиксировать некоторые изменения в развитии проблемы. Если раньше эксплоиты и зловреды хостились на индийских доменах (закрыли их весьма просто regExp-ом: "\.in$"), то сейчас - на наших отечественных. Причем здесь наблюдаются еще элементы социальной инженерии - мол, проблемы у вас с IE, давайте мы вам починим....
Что же это за домены *ie.ru??
IP-адрес: 46.4.82.48
По данным WHOIS.RIPN.NET:
| Домен: | |
| Сервер DNS: | |
| Сервер DNS: | |
| Статус: | зарегистрирован, делегирован, не проверен |
| Администратор домена: | Частное лицо "Private Person" |
| E-mail: | |
| Регистратор: | REGRU-REG-RIPN |
| Дата регистрации: | 2011.11.01 |
| Дата окончания регистрации: | 2012.11.01 |
| Источник: | TCI |
IP-адрес: 46.4.82.48
По данным WHOIS.RIPN.NET:
| Домен: | |
| Сервер DNS: | |
| Сервер DNS: | |
| Статус: | зарегистрирован, делегирован, не проверен |
| Администратор домена: | Частное лицо "Private Person" |
| E-mail: | |
| Регистратор: | REGRU-REG-RIPN |
| Дата регистрации: | 2011.11.01 |
| Дата окончания регистрации: | 2012.11.01 |
| Источник: | TCI |
IP-адрес: 46.4.82.48
По данным WHOIS.RIPN.NET:
| Домен: | |
| Сервер DNS: | |
| Сервер DNS: | |
| Статус: | зарегистрирован, делегирован, не проверен |
| Администратор домена: | Частное лицо "Private Person" |
| E-mail: | |
| Регистратор: | 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: написали в хостера. Реакции так же нет.
Wednesday, November 9, 2011
Сигнатурные антивирусы, прощайте
Продолжая потихоньку сражаться с проблемой, решил, таки посмотреть, что же там качают...
Приведу фрагмент странички, хостящей зловред:
Вот, что-то никогда не доводилось взглянуть, а как все интересно!
a - массив чудовищной длины, фактически байтов, которые там раскиданы по порядку, известному разработчику (в данном примере - обратный порядок).
Из этого "набора" потом в переменную s набирается побайтовым "выкусыванием", собственно, код, который затем выполняется в eval(s).
Какому-нибудь сканеру вредоносности кода, чтобы увидеть вредоносность надо его собрать, а чтобы его собрать надо знать алгоритм по которому он разбросан...
Тему можно дальше развивать до бесконечности:
- также набирать, скажем индекс "выкусывания",
- также набирать "опасные" команды, типа eval, substr, тп
- можно сильно усложнить алгоритм "выкусывания"
- ... человеческая фантазия безгранична ...
Полиморфизм, однако.
Можно попробовать что-то вроде песочницы, т.е. фактически выполнить код, как это сделал бы браузер. Делать это можно, если недолго (антивирус должен работать незаметно!). Но, можно же вставить искусственные задержки (sleep) , можно вставить естественные задержки, скажем, в цикле пытаться что-то поделать небыстрое, ... - пользователь замучится ждать, пока антивирус собирет - не вариант.
Печально что мой, не изощренный мозг, ограниченного горе-программиста с ходу придумывает такое количество схем обфускации, практически полностью убивающих идею обнаружения зловреда до его поражения жертвы, что же говорить о высококлассных профи :-(
Опыт показывает, что все эти сэмплы практически не детектятся никем из Virustotal, пока в соответствующие поддержки не пришлешь сэмплы и они не выпустят экстры. Что уж в этих экстрах - не разбирался, но судя по тому, что ровно такая же штука (с небольшими изменениями) срабатывает снова и снова, складывается недоброе впечатление что там чуть ли не сравнение по MD5 :-(
PS: я посмотрел в некий .class (использовал javap), там тоже белиберда и substr-ы (java/lang/String.substring). По ходу та же техника....
Sunday, November 6, 2011
Приз вместо оплаты услуг, продолжение.
Публикация вызвала любопытный спор в группе RISSPA на LinkedIn-е. Спор - это всегда хорошо, так как он позволяет приблизиться к истине (постараюсь быть самокритичным: есть у меня склонность к троллингу, но, зная за собой сей грешок, всегда стараюсь держать себя в руках) . Мне не показались убедительными доводы моих оппонентов, тогда как собственная логика вполне себе пригодной. В данном блоге я, все-таки, намерен излагать свои умозаключения, но быть объективным и привести доводы оппонентов и свои ответы на них. Пишу, главным образом, для тех, кто по каким-либо причинам не участвует в нашем RISSPA-LinkedIn-овском междусобойчике :-), но кому идея может показаться любопытной.
Итак, я пытаюсь применить такие конкурсы в качестве средства анализа защищенности (теста на проникновение) интернет-сервисов коммерческой компании. Такой подход, на мой взгляд, имеет ряд серьезных преимуществ для Заказчика (коммерческой компании):
- Выбор подрядчика происходит по факту выполненных работ, а не на основании предположения как подрядчик, наверно, это сделает. Сложившаяся практика такова: Заказчик пишет Техтребования, требования к квалификации подрядчика, вывешивает их на свой сайт с предложением слать оферты. Потенциальные Подрядчики высылают в назначенный час свои оферты с информацией о том, какие они хорошие. Заказчик рассматривает предложения, отсеивает тех, кто не проходит по каким-либо квалификационным требованиям, а из оставшихся квалифицированных выбирает по минимальной цене победителя. Т.е. на момент выбора Подрядчика Заказчик не имеет ни малейшей уверенности, что Подрядчик отработает хорошо. Критерий минимальной цены здесь играет далеко не в интересах Заказчика.
- Множество независимых результатов позволит более объективно оценить качество работ. По "устоявшейся" схеме после отработки подрядчика Заказчик получит единственный результат, собственно, результат работы Подрядчика. Для оценки качества работы Подрядчика, Заказчику, в случае пентеста, надо провести свой пентест: ОК, если Подрядчик нашел хоть что-то, но если он не нашел ничего, означает ли это, что Заказчик хорошо защищен? Или просто Подрядчик так отработал (как смог)? Множество независимых результатов эту проблему смягчают: если Подрядчик1 не нашел ничего, а Подрядчик2 - что-то, - уже есть смысл задуматься.
- Заказчик гарантированно впишется в свой бюджет. Тут все понятно: Заказчик сам объявляет приз, и не возможна ситуация, когда запланированный на пентест бюджет ниже любой присланной оферты.
- Подобные конкурсы позволят открывать новые имена. При открытом конкурсе, когда участвовать сможет каждый желающий, больше шансов для формирования действительно конкурентной среды, что, безусловно, повысит качество услуг.
Теперь перейдем к аргументам моих оппонентов.
1. Возможна низкая эффективность такого конкурса. Тут мне кажется, что все зависит от мотивации. Можно придумать неплохую стратегию проведения таких конкурсов, где продумать вопросы мотивации участников. Сейчас, банально, чем выше призовой фонд, тем бОльшая эффективность будет у конкурса. В любом случае, все работают за деньги. Можно продумать какие-либо еще варианты: какое-нибудь схемы взаимного сотрудничества, рекламы и т.п.
2. Подобные конкурсы будут работать только в разовых акциях и непригодны для постоянного процесса. Во-первых, совсем не обязательно пентестить сайт на постоянной основе, скажем, раз в год. Во-вторых, все опять же упирается в мотивацию: никто не мешает, например, оплачивать любую информацию об обнаруженной уязвимости, - при такой постановке вопроса уже мы наблюдаем процесс. Примерно это может выглядеть так: Заказчик сделал Интернет-сервис, запустил конкурс. Условиями может быть оплата каждой найденной уязвимости в пропорции к ее критичности, например (все это можно прописать в техтребованиях).
3. Подобные конкурсы приведут к тому, что Черные шляпки будут использовать найденные уязвимости в своих грязных делишках. Мое мнение, что на этот риск наличие или отсутствие конкурса никакого влияния не имеет. Позиция, что меня никто не ломает, потому что обо мне никто не знает не очень вяжется с маркетингом, поскольку если Интернет-сервис должен приносить прибыль, он должен быть известен. Ну а с тем, что ломают то, что известно и посещаемо - надо мириться и как-то бороться.
4. Публичная огласка степени "дырявости" веб-ресурса серьезно подмочет репутацию компании Заказчика. Стратегия "молчания в тряпочку" - наиболее разумная. Во-первых, все зависит от важности сайта для бизнеса Заказчика. Если сайт является, что называется, core-бизнес, то, уверен, его надо публично исследовать. Во-вторых, публикации типа этой, даже если они вышли до фактического исправления, на мой взгляд, вызывают меньший резонанс, чем информация о том, что какой-нибудь Изя Питерский тайно заломал сайт 15 месяцев назад, извелкал из него какую-либо выгоду, а когда надоело - продал конкурентам, которые глумились уже более продуманным образом (еще раз, публичность или непубличность исследований не будет хоть как-то коррелировать с работой Изи). Выход публикаций об узявимостях уже означает, что по ним рабоатют и латают. К тому же, остается надежда на этичность исследователей и подобные уязвимости пойдут в публикацию уже после исправления. Я абсолютно уверен, что стратегия "молчания в тряпочку" значительно менее эффективна, чем всестороннее исследование.
Напоследок, еще раз хочется подытожить, что то, что такие конкурсы обходятся дешевле среднестатистического пентеста - не основной мой аргумент ЗА, основное здесь - большая гарантия качества, чем при классическом конкурсном подходе в случае работ, где качество оценить самому Заказчику крайне сложно. Но есть Сообщество, которое поможет. Все-таки я склонен думать, что хороших людей больше и идея свободы информации в добрых целях жива не только в моем сознании.
Friday, November 4, 2011
Приз вместо оплаты услуг
Вот тоже интересная идея! Допустим, по вашим корпоративным стандартам положено пентестить каждый web-сервис, который должен волей бизнеса быть доступен из Интернет. Видя приз в $5000 могу с уверенностью сказать, что эта сумма значительно ниже заказного пентеста. Может, лучше такие конкурсы объявлять, чем конкурсы на выбор подрядчика?!
- Нет риска, что работа будет выполнена плохо: действительно платим только победителю, значит, он что-то найдет (можно тут ознакомиться с примерно полным перечнем опасений).
- Цена - крайне привлекательна.
Thursday, November 3, 2011
О Рекламе и Антирекламе
Мы в нашем SOC-е уже давно трейсим проблему с переменным успехом: каждый день тонны новых сайтов, хостящих эксплоиты причем в чем угодно: pdf, swf, java, exe ... Куча сэмплов засылаются в антивирусных вендоров, virustotal напрягается, вендоры тоже, наш хелпдеск устал перезаливать десктопы, мы с ИТ-шниками постоянно в тонусе: ломаем голову как бы это закрыть на периметре, чтобы более не напрягало. Пока не понятно в чью пользу. Мы склонны думать, что это работает автомат, которого постоянно подкармливают эксплоитами и пейлоадами, а также потенциальными целями (выбираются наиболее посещаемые сайты) и снимают "урожай" уже компрометированных клиентов. Возможно, последние потом просто продаются, но это вопрос отдельного изучения.
Впечатляют масштабы этого безобразия: мы анализируем только посещения наших пользователей, да у нас большая сеть, но в масштабах Интернет - капля. Достаточно много вполне себе приличных сайтов новостей, известных на всю страну организаций взломано. Причем, когда мы сообщаем в соотвествующие поддержки сайтов и проблема устраняется, практически на следующий день снова наблюдаем хостящийся эксплоит :-)
Среди таких известных и в то же время уже разломанных сайтов, с хостящимся эксплоитом - URA.RU. При заходе на сайт приятно видеть, что мой домашний Касперский не спит (думаю, любой из вас может это увидеть):
Здорово, правда? В целом, гордится не чем.
Однако, вполне себе приличная и известная Компания, специализирующаяся как раз на обеспечении информационной безопасности на своем сайте среди уважаемых клиентов с гордостью перечисляет:
Илья, если вы читаете, пожалуйста, помогите клиенту.
Размещать известных клиентов на своем сайте - общая практика. А ведь так просто этим же себе и навредить....
Я ни в коем случае не хотел бы в этом посте задеть чьи-либо интересы, нет. Я очередной раз задумался о том, что любая палка имеет как минимум два конца и, порой, преследуя одно, мы получаем совсем другое. Опыт показывает, что захачить можно практически любой сайт и совсем не значит, что его писали плохие разработчики и администрят плохие админы: слова "плохой" и "хороший" - относительны, а любая консалтинговая компания стремится обозначить своих клиентов, тем самым немного добавив в копилку мнения прохожего о качестве своих услуг.
Может, разве что, ссылки не давать со своего сайта, оставив одни логотипы :)