Двадцать третьего марта в рамках европейской конференции Cisco компания Microsoft проводила однодневный семинар, посвященный проблемам и решениям в области безопасности. Семинар несомненно удался. Некоторые доклады были весьма интересны, докладчики – профессионалы высокого уровня, и просто интересные люди. Если подобное мероприятие будет проводится в ближайшем будущем я обязательно попытаюсь на него попасть.
В приглашении было заявлено, что семинар будет проходить с 9 до 18 часов, однако мое пятнадцатиминутное опоздание оказалось очень кстати, поскольку начало было перенесено на 10 часов, а кофе получилось выпить только в половину десятого.
Пройдя регистрацию и получив ручку, блокнот и невнятную листовку о сертификации Windows XP по EAL1 я проследовал в забитый зал.
Количество желающих присутствовать явно превышало количество посадочных мест, однако к чести гостиницы Ренессанс эта проблема была довольно быстро решена.
Вообще мероприятие было организованно на уровне, но явно не рассчитано на такое количество участников. Уютный зал, хорошая акустика, приличный кофе, прекрасная работа переводчиков-синхронистов. Но очереди, везде очереди. Очередь на регистрацию, очередь на обед, очередь извините, в туалет. Однако это мелочи. Первый доклад, прочитанный Стивеном Адлером (Steven Adler), руководителем по разработке стратегии безопасности в Microsoft EMEA HQ, назывался «Defense in depth».
В докладе рассматривались основы концепции DiD и возможности продуктов Microsoft (особенно платформы .NET), помогающие реализовать эту концепцию.
С точки зрения Microsoft для реализации DiD информационная система разделяется на четыре уровней – уровень периметра (perimeter), уровень сети (network), уровень узла (host), уровень приложения (application) и уровень данных (data). Безопасность каждого из этих обеспечивается при помощи всех доступных защитных механизмов, исходя из предположения, что все остальные уровни не защищены. Такой подход снижает возможные последствия ошибок реализации или эксплуатации, в каком либо из уровней.
Замечательный и очень верный подход, однако, в интерпретации Microsoft, на мой взгляд, отсутствует один важный момент – уровень пользователя. Любая автоматизированная система является системой человек-машина, и люди, как правило, являются самым слабым звеном этой системы. Все громкие инциденты в области безопасности возникли именно в связи со слабой «настройкой системы безопасности» прокладки между стулом и клавиатурой. Тот же Blaster возник отнюдь не в связи с ошибками реализации. Ошибкой реализации переполнение буфера в RPC было до того момента как Microsoft выпустил патч, закрывающий эту уязвимость. После этого ошибка перешла уже в категорию ошибок эксплуатации, устранением которых должны заниматься люди, обслуживающие систему. Я уж не говорю о различных почтовых «червях», распространяющихся исключительно через «дырки в головах пользователей».
Презентацию, очень похожую на использованную в этой части доклада можно загрузить по адресу (http://www.microsoft.com/poland/seminaria/prezentacje/security/Using%20MS%20Systems%20Architecture.ppt ).
Вторая часть доклада была просвещена защитным механизмам платформы .NET. Были продемонстрированы подходы к реализации функций аутентификации, авторизации, проверки пользовательского ввода в приложениях на основе .NET. Кроме того, были продемонстрированы в работе криптографические механизмы (хеширование, шифрование). К сожалению, в код, который демонстрировал Стивен, вкралась ошибка, которая потенциально может позволить обойти используемую систему аутентификации. В LDAP запрос к AD имя пользователя, насколько я успел заметить, помещалось без проверки на содержание различных «нехороших» символов. Хотя Стивен не профессиональный программист, и подобные ляпы ему простительны.
Для тех, кто занимается разработкой и безопасность приложений на основе .NET я рекомендую обратиться к документу «Improving Web Application Security: Threats and Countermeasures» (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/threatcounter.asp) или к моему новому курсу «Безопасность Web-технологий», первое прочтение которого ожидается в июне этого года.
В целом доклад оцениваю на 7/9, мастерство докладчика 9/9.
Второй доклад, так же прочитанный Стивеном Адлером был посвящен новой технологии разграничения доступа «Right Management Server». Современные средства разграничения доступа действуют только в пределах определенной зоны безопасности (security domain). Возьмем, к примеру, файловую систему NTFS. Встроенные в неё списки контроля доступа работают только в случае, если загружена операционная система, осуществляющая проверку прав пользователей на доступ к файлу. В случае, если это файл будет, например, скопирован на другую машину или даже на другой раздел того же жесткого диска с файловой системой FAT, все права доступа будут потеряны. То же произойдет в случае, если винчестер будет подключен к другому компьютеру или на машине будет загружена другая операционная система (например, DOS с драйвером NTFSDOS или Linux с поддержкой NTFS).
Такие же проблемы возникают при использовании более продвинутой технологии, такой как EFS. В случае подмены операционной системы злоумышленник не сможет получить доступ к данным, но если человек, имеющий доступ к файлу скопирует его в другую зону безопасности – например в незашифрованную папку или просто скопирует его по сети, файл будет расшифрован и механизм разграничения доступа перестанет работать.
Система RMS призвана устранить описанные проблемы путем переноса зоны безопасности на уровень приложений. В докладе не было технических подробностей, поэтому нижеизложенная информация может быть далека от реальности.
Автор создает документ. Автор формирует набор прав и правил для документа (Publishing License). Приложение зашифровывает документ с симметричным ключом. Приложение посылает Publishing License серверу RMS на подпись. RMS подписывает Publishing License и возвращает ее приложению. Автор пересылает файл получателям документа Получатель открывает файл. Приложение посылает серверу RMS запрос на Use License. В этот запрос включаются RM Account Certificate (RAC) получателя и Publishing license документа. RMS проверяет запрос и RAC, идентифицирует получателя. При успешной проверке RMS выдает получателю лицензию на работу с документом. Приложение получает лицензию от RMS и отрабатывает правила, заложенные в ней. Получатель работает с документом. Когда к документу пытается получить доступ другой пользователь, приложение посылает запрос к серверу RMS и сервер присылает ему ключ документа, зашифрованный с использованием открытого ключ пользователя. Приложение расшифровывает документ, и контролирует действия пользователя по отношению к нему. Естественно подобная схема не защищает от злонамеренных действий пользователя, который, имея право на чтение документа, будет использовать фотоаппарат или копи экрана, что бы сохранить его на диске или «выцарапает» документ из очереди печати или временных файлов. Однако, если он внесет в этот документ и попытается сохранить его, сервер RMS воспримет его как новый документ а не как модифицированную версию исходного.
Система RMS представляется мне довольно надежным способом защиты от ошибок персонала. Например, если пользователь нечаянно укажет в качестве получателя конфиденциального почтового сообщения внешнего абонента, то получатель не сможет его прочитать, поскольку сообщение придет к нему в зашифрованном виде.
Инфраструктура RMS состоит из сервера на основе Windows Server 2003, Active Directory, сервера Microsoft SQL Server 2000 и клиентского обеспечения для клиентов. Поддержка RMS встроена в Office 2003. Несомненно, интересная технология, однако вызывает сожаление отсутствие возможности протестировать её перед внедрением – сервере RMS требуют обязательной активации в Microsoft.
Для начального ознакомления с RMS можно воспользоваться материалами конференции «Платформа 2004» (http://www.microsoft.ru/platform2004/reports/SEC-07_WRMS.ppt). Общая оценка – содержание 6/9 (слишком обзорно), мастерство докладчика 9/9.
Самым интересным с моей точки зрения выступлением был доклад менеджера программы безопасности в глобальной группе безопасности службы технической поддержки продуктов (World-wide Product Support Service (PSS) Security Team) Симона Конанта (Simon Conant) «Vulnerability Handling».
Доклад был посвящен тому, как происходит процесс обработки обнаруженных уязвимостей в Microsoft. Уязвимость проходит несколько этапов во время которых определяется степень риска, затронутые продукты, возможные cвязанные проблемы, разрабатывается патч и производится тестирование исправления как силами Microsoft, так и партнерами. Самым долгим периодом является тестирование уязвимости, в связи с большим количеством конфигураций и высокой стоимостью вероятных сбоев.
Время выпуска обновления зависит от степени риска, связанной с уязвимостью, а так же наличием «во внешнем мире» информации об уязвимости. В случае критичной уязвимости патч может быть выпущен менее чем за неделю (в качестве примера была приведена уязвимость в ASN.1, MS04-007).
Появилась полезная возможность отслеживать состояния исправления. Например, если я почитывая F-D, вдруг узнаю об очередном выполнении произвольного кода в Internet Explorer о котором было сообщено в Microsoft в тот же день, когда информация поступила в публичный ресурс, я могу обратиться в службу технической поддержки с запросом о времени выхода патча.
Кстати, о времени выхода. Сейчас обновления для продуктов Microsoft выходят раз в месяц, за исключением особых случаев. С моей точки зрения это довольно удобно, поскольку дает возможность планировать процесс развертывания. Довольно полезным начинанием является пользовательское тестирование предвыпусков патчей. Т.е. патч тестируют партнеры Microsoft в «боевых» условиях, что однозначно повышает их качество.
В мае 2004 ожидается ввод технологии Windows Installer 3.0 позволяющей унифицировать исправления для всех продуктов (Windows, Office, SQL, Exchange и т.д.) и реализующей возможность деинсталляции всех обновлений. Новая возможность Delta Patching приведет к уменьшению размера патчей («Ну хоть чему-то они научились у кракеров» (с) 3APA3A). Анонсируется новая возможность обновления загруженных в память модулей, что приведет к снижению количества перезагрузок («Microsoft посмотрел на rootkits»).
Далее последовал обзор существующих и новых продуктов, призванных облегчить процесс развертывания оперативных обновлений.
В ходе сессии вопросов и ответов были освещены следующие проблемы:
Внутренний поиск уязвимостей. Если информация о критичной уязвимости не становится публично доступной, то патч предпочитают включать в Service Pack.
В обратном случае есть возможность послать запрос в службу технической поддержки, что бы определить в какой фазе находится подготовка патча.
Довольно сложно определить привязку патча к уязвимости. MS считает, что ссылки на CVE достаточно. Это прежде всего связанно с опасениями, что информация о уязвимости может быть использована для её эксплуатации (точнее для обвинений Microsoft в помощи хакерам :-). Общая оценка – содержание 9/9, мастерство докладчика 9/9.
Доклад по теме «Wireless security» читал Стивен Адлер.
В ходе доклада были рассмотрены основные проблемы безопасности беспроводных сетей стандартов 802.11x, проведен ряд демонстраций взлома (Стивен даже загрузил Linux!!!!), а так же намечены основные методы решения этих проблем.
Основная проблема беспроводных сетей – слабая схема криптографической защиты информации в протоколе WEP (RC4 с колючем 64 или 128 бит), отсутствие механизмов управления ключевой информацией (ключ WEP – статический) и ненадежные механизмы аутентификации абонентов (MAC-адреса).
В качестве решения предлагается использовать технологию 802.1X, реализованную в продуктах Microsoft. Эта технология делает возможной аутентификацию пользователей с помощью устойчивых протоколов (EAP-TLS или MS-CHAP-V2) и генерацию сеансового ключа для протокола WEP или 802.11i. В качестве сервера аутентификации используется сервер RADIUS, реализованный в Internet Authentication Server, связанный со службой Active Directory.
Решение несомненно замечательное, однако при его внедрении встает вопрос совместимости. Предположим, я приезжаю со своим Notebook в тот же отель Реннесанс и пытаюсь подключится к беспроводной сети. У меня ничего не выходит, а администратор говорит, что поскольку моя Windows NT не поддерживает 802.1X и EAP-TLS, то никакой возможности работать в их сети, кроме как установить на неё Windows XP он не видит. Ага, конечно. Очень похожую презентацию можно найти здесь:
http://www.microsoft.com/usa/presentations/SecureWireless_at_Microsoft.ppt
Общая оценка – содержание 7/9, мастерство докладчика 9/9.
Последние два доклада читал Сэндип Модхвадиа, MCSE-Security.
Свое выступление он начал с того, что объяснил, что он де, Сандип является техническим специалистом, а не в коей мере не пресейлом или каким другим сказачником. И что де в его, Сендипа, выступления не будет никаких «продвижений», а будет голая правда как она есть. И что де всяческому нетехническому люду лучше выйти, пока он, Сандип, не стал проливать на их головы свою техническую мудрость.
После этого он вылил на наши головы две презентации, рассчитанные на пресейл. Одна из них посвящалась возможностям Windows Server 2003, а вторая рассказывала о чудесах ISA Server 2000 (а я так надеялся на информацию о 2004).
Когда докладчик коснулся замечательных механизмов защиты от переполнения буфера на примере уязвимости WEBDAV, взбеленился 3APA3A. «Неужели этот могучий ум не слышал про эксплуатацию переполнения буфера с помощью SEH?». Когда Сэндип демонстрировал ограничение на запуск программ (Software Restriction Policy) он отказался выполнить мою просьбу и изменить один байт в запрещенном для исполнения notepad. И отказался прокомментировать свой отказ. В докладе о ISA Сендип долго рассказывал зачем нам нужен firewall и с такой гордостью на кухонном уровне рассказывал о фильтрации в контексте соединения (stateful) и content filtering, как будто сам их изобрел. Он рассказал нам о фильтрации на всех восьми (!) уровнях модели OSI, чем опять вызвал возмущение 3APA3ы, которого мне пришлось успокаивать, объясняя что некоторые вендоры, например Cisco, разделяют канальный уровень на 2 подуровня – MAC и LLC. 3APA3A удивился такой моей эрудиции и пришлось объяснить, что за время преподавательской деятельности я научился отмазываться и не в таких ситуациях. После этого, обсудив личность Сэндипа, мы решили, что он был переманен из Cisco. Хотя я слабо представляю, как даже такой замечательный Firewall как ISA будет фильтровать трафик на физическом уровне...
Ссылки на презентации приводить не буду, в Internet подобных – огромное количество.
Общая оценка – содержание 4/9, мастерство докладчика 6/9.
Семинар несомненно удался. Некоторые доклады были весьма интересны, докладчики – профессионалы высокого уровня, и просто интересные люди. Организация 7 из 9 (количество приглашенных превышает возможности принимающей стороны). Если подобное мероприятие будет проводится в ближайшем будущем я обязательно попытаюсь на него попасть.
Хотелось бы поблагодарить Российское представительство Microsoft за организацию этого семинара, докладчиков за их работу.
PS. На семинаре я получил компакт-диск с beta версией ISA Server 2004 и два последующих дня посветил изучению этого продукта. ISA меня очень сильно порадовала как идеологически, так и функциональной «набивкой». Один из моих коллег, просмотрев сделанный моей материал по ISA 2004 сказал – «Ну хоть на firewall стала похожа, почти Checkpoint». В скором времени планируется включить ISA Server 2004 в один из учебных курсов.
(c)oded by offtopic
Но доступ к знаниям открыт для всех