среда, 16 декабря 2015 г.

Блог переехал на kochetkov.github.io

Давно собирался это сделать, но руки дошли только сейчас. Обновите pls свои закладки и подписки на новый адрес. Статьи неспешно перетащу по мере появления на это времени. Все новое буду публиковать только там.

суббота, 14 ноября 2015 г.

По следам вебинара "Прикладная теория Application Security"

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

На вебинаре я обещал дать ссылки на несколько статей о символическом исполнении, абстрактной интерпретации и т.п. Поступим проще. Вот здесь лежит подборка материалов на эти и смежные темы, которые мы в той или иной мере использовали при работе над Application Inspector. Будут вопросы - задавайте в комментариях.

Что касается книг для дальнейшего чтения, то конкретно по теории есть не так уж и много материалов и практически все мне известные можно собрать по крупицам из подборки выше. Стоит отдельно отметить выступление Meredith L. Patterson, Sergey Bratus на 28C3 в 2011 (видео, слайды) и работу Matt Bishop с коллегами, которую я упоминал на вебинаре.

Если говорить о практике, то мой TOP 5 книг, обязательных к прочтению на данную тему следующий (порядок произвольный):

"Writing Secure Code, 2nd Edition"
"The Tangled Web. A Guide to Securing Modern Web Applications"

"The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws, 2nd Edition"
"The Browser Hacker's Handbook"
"The Shellcoder's Handbook: Discovering and Exploiting Security Holes, 2nd Edition"

Собственно, серию "Handbooks" данного издательства стоит прочесть всю.

P.S: Коллегам по конкурирующему цеху: парни, согласитесь, что обсуждать технические вопросы реализации Application Inspector на вебинаре, связанном с ним лишь косвенно - не вполне корректно по отношению к остальным слушателям. Я всегда готов делиться той информацией, которой имею право делиться со всеми, кто попросит. Даже с конкурентами, причем даже с теми конкурентами, руководство которых находится со мной в контрах. И для этого совсем не нужно дожидаться вебинара с моим участием, как повода задать интересующие вас вопросы :) Мои контакты доступны - пишите, звоните, буду рад пообщаться. Я серьезно.

среда, 28 мая 2014 г.

Об анализе исходного кода и автоматической генерации эксплоитов

        В последнее время об анализе защищенности исходного кода не написал только ленивый. Оно и понятно, ведь тот парень из Gartner, как предложил рассматривать анализ исходного кода в качестве нового хайпа несколько лет назад, так до сих пор и не дал отмашку на то, чтобы прекратить это делать. А, учитывая текущее направление моей работы (участие в разработке PT Application Inspector, далее AI), и тот факт, что в последнее время годных статей на тему анализа исходного кода в общем-то не было, как-то даже странно, что до сегодняшнего дня в этом блоге не было ни одной грязной подробности на эту животрепещущую тему. Что ж, исправляюсь :)

вторник, 30 апреля 2013 г.

Статистика и ИБ

Начну с разсказа воистину былинной истории, которую никогда не задолбусь рассказывать, когда речь заходит о статистике. Итак...

Был у "одного сотового оператора" (с) филиал, в какой-то совсем дремучей глубинке, в котором продажи 3G-модемов шли из рук вон плохо. Всем было понятно, что модемы не пользовались популярностью у местного населения исключительно из-за весьма недешевых тарифов на мобильный интернет с одной стороны и слабого покрытия 3G в том городе, с другой. Однако с этим были в корне несогласны два топ-менеджера той же компании, члены совета директоров, утверждавшие, что грамотный маркетинг творит чудеса и что это "просто в том филиале модемы продавать не умеют". Слово за слово, и эти два директора приняли решение десантироваться в тот офис продаж и показать мастер-класс по продаже модемов, проведя один день в роли рядовых продавцов. Провели. Натурально, вышли на улицы и провели машстабную промо-акцию, в результате которой продажи филиала были удвоены. Об их ошеломительном успехе сначала написали во внутрикорпоративной рассылке, потом на интранет-сайте, потом во внутрикорпоративной газете. Заголовок на тему "двое топ-менеджеров удвоили продажи филиала всего за один день, выступив в роли рядовых продавцов" еще долго муссировался HR компании с того или иного боку. По всей компании, на каждом митинге, этих директоров ставили в пример остальным сотрудникам на тему "вот как надо работать!".

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

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

Это - односторонняя функция, легко рассчитываемый по входу выход и невозможность определить по выходу вход. И в этом, как раз и заключается опасность статистики, используемой в качестве аргументации какого-либо тезиса с целью подменить или скрыть причины для доказываемого следствия. Особенно в ИБ, где требования к достоверности информации, на основе которой принимаются решения в рамках этой предметной области, зачастую не ниже, чем к конфиденциальности, целостности и доступности. PHP-приложения чаще прочих подвержены уязвимостям не потому что язык, на котором они написаны, является говном. Язык со слабой динамической типизацией, такой стандартной библиотекой и сомнительными дизайнерскими решениями - являлся бы говном даже в том случае, если бы на выходе у его сторонников были исключительно защищенные веб-приложения. Настоящая же причина заключается в том, что в силу своей простоты и примитивности, он всего лишь позволяет быстро разрабатывать веб-приложения даже неквалифицированным разработчикам. Читай: дешевой рабсиле, позволяющей сократить издержки на разработке. Тем не менее, этот аргумент против PHP можно достаточно часто встретить во всевозможных холиварах и внутрикорпоративных обсуждениях на тему выбора языка для очередного продукта.

Или вот другой пример. В операционной системе A (или браузере, или почтовом клиенте - не суть) за последний год, по данным Secunia, было зафиксировано N уязвимостей. А в его конкуренте B - всего лишь M=N/2 за тот же период. О чем это может говорить здравомыслящему человеку? Да вообщем ни о чем. Может в B просто нет квалифицированного персонала, умеющего искать уязвимости. Или напротив, в A были привлечено какое-то количество экспертов, исключительно на эту задачу (тем же краудсорсингом, например). Или еще 100500 других вариантов того, чем могли быть обусловлены подобные цифры. Но тогда почему, с пугающей регулярностью, эта статистика приводится сторонниками продукта B, как его преимущество? Ведь, если следовать их же логике, то чем больше уязвимостей устранено в продукте, тем он защищеннее? Получается, что A за прошедший год стал защищеннее B аж в 2 раза, почти тем же путем, которым удвоились продажи 3G модемов. Единственным существенным показателем в данном случае, является количество еще _не выявленных_ в продукте уязвимостей, что как раз и скрывается подобной "статистикой". Как и тот факт, что рассчитать этот показатель не представляется возможным, т.е. что вся их статистика суть - ни о чем, ч.т.д.

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

P.S: Все события в посте - вымысел, любые их совпадения с событиями, происходившими в "одном сотовом операторе" (с) считать случайными, равно как и внезапное существование реального города "Ростов-на-Дону" с такими же плакатами, и появление в комментах представителей A и B, несогласных с высказанной точкой зрения.

понедельник, 29 апреля 2013 г.

Валидация запросов ASP.NET: от <?i[a-z!/\?]|&# до XSS Type-1 WAF


(*Запоздалый кросс-пост с Хабра)
"Возможность валидации запросов в ASP.NET спроектирована для выполнения базового контроля входных данных. Она не предназначена для принятия решений, касающихся защищенности разрабатываемых веб-приложений. Только сами разработчики могут определить, какой контент должен обрабатывать их код. Microsoft рекомендует выполнять проверку всех входных данных, получаемых из любых источников. Мы стремимся способствовать разработке защищенных приложений нашими клиентами, и функционал валидации запросов был спроектирован и внедрен для того, чтобы помочь разработчикам в этом направлении. Для получения дополнительной информации о наших рекомендациях по разработке, читайте статью MSDN: http://msdn.microsoft.com/en-us/library/ff649487.aspx#pagguidelines0001_inputdatavalidation".
Официальный статус ASP.NET Request Validation по версии Microsoft Security Response Center

Несмотря на столь внезапный ответ MSRC на недавний отчет исследовательского центра Quotium об обнаружении очередного способа обхода валидации запросов в ASP.NET, стоит заметить, что она все же предназначена именно для принятия решений, касающихся защищенности веб-приложения. В пользу этого говорит и название класса, реализующего основной набор проверок (System.Web.CrossSiteScriptingValidation) и сама его суть, заключающаяся в предотвращении некоторого подмножества атак класса XSS Type-1 (отраженное выполнение межсайтовых сценариев), и оригинальная статья от разработчиков веб-стека. Другой вопрос, насколько эффективно мог бы быть реализован этот функционал и как из имеющегося примитивного регулярного фильтра получить полноценный web application firewall, защищающий от любых векторов XSS Type-1?

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