вторник, 27 сентября 2011 г.

Open Source Fuzzing Tools

Небольшая книга по фаззингу издательства Syngress от группы авторов, среди которых фигурирует всем известный Чарли Миллер (@0xcharlie). Книгу можно рассматривать как введение в фаззинг. Содержание книги раскрывает различные аспекты фаззинга в 10 соответствующих главах. Правда объем книги (200 страниц) не позволяет раскрыть темы достаточно подробно.
Глава 1 (Introduction to vulnerability research) достаточно традиционна для подобного рода книг и объясняет основные классы программных ошибок и вкратце описывает подходы к поиску ошибок и уязвимостей. Большинство может пропустить 10 страниц, которые занимает первая глава, так как понятия buffer overflow, black/white box testing встречаются в каждой второй книжке по ИБ. 
Глава 2 (Fuzzing - What's That?) будет интересна тем, кто до этого не сталкивался с понятием фаззинга. Приведен небольшой экскурс в историю, приводится ретроспектива развития идей, основные области применения фаззинга как инструмента. В главе упоминаются ведущие вендоры коммерческих решений в области фаззинга и их продукты.
Глава 3 (Building a Fuzzing Environment) должна раскрывать по идее вопросы построения среды для фаззинга. На деле - содержательная часть главы приводит перечень программных средств, используемых для процессов отладки, мониторинга за поведением процессов для Windows, Linux и OSX. Большей части разработчиков знакомы такие вещи как Windbg, OllyDBG, IDAPro, gdb, valgrind. Как-то совсем бедно на этом фоне выглядит упоминание XCode для OSX.
Четвертая глава (Open Source Fuzzing Tools) и пятая (Commercial Fuzzing Solutions) представляют собой перечисление бесплатных и коммерческих решений с кратким описанием, указанием области применения. Стоит отметить, что существенная часть приведенных бесплатных фаззеров не поддерживается и не развивается достаточно продолжительное время. Описание коммерческих решений более красочное за счет иллюстраций графических интерфейсов.
Шестая глава (Build Your Own Fuzzer) содержит описание основных составных частей средства фаззинга, вводит некоторое понятие базисного словаря фаззинга, вскользь упоминает о простом автомате и применимости этой модели к процессу фаззинга. В конце главы читателю предлагается создать собственный простой фаззер при помощи языка Perl.
Содержание седьмой и восьмой главы (Integration of Fuzzing in the Development Cycle и Standtartization and Certification) в большей степени направлено на людей занимающихся в софтверных компаниях вопросами QA и тестирования. В данных главах фаззинг рассматривается как элемент непрерывного и комплексного тестирования программных продуктов. Делается акцент на то, какие именно программные ошибки могут быть обнаружены средствами фаззинга. Шестая глава предлагает вариант плана по организации фаззинга, который отвечает на основные вопросы: кто, что, как, сколько будет фаззить. Приводится список наиболее часто встречаемых проблем при организации системного процесса фаззинга и пути их решения.
Глава 9 (What is a File?) рассматривает файлы как входную точку для фаззинга приложений. Приводится ряд популярных текстовых и бинарных форматов, подходы к анализу форматов файлов и их содержимого, список популярных hex-редакторов. В конце главы приводится ряд файловых фаззеров с краткими описаниями.
Глава 10 (Code coverage and fuzzing) на мой взгляд во всей книге самая содержательная, посвящена вопросам повышения эффективности методик фаззинга посредством анализа степени покрытия логики тестируемого приложения. Глава предлагает методы инструментализации программных продуктов как с доступным исходным кодом, так и закрытых решений. На достаточно простом примере показано, каким образом можно увеличить процент покрытия тестами целевого приложения.

Книга достаточно простая, без особых технических подробностей и вряд ли будет интересна техническим специалистам, занимающимися поиском уязвимостей. Содержание книги может быть передано в 2-3 статьях. Можно рекомендовать данную книгу техническим менеджерам, ответственным за сегмент QA и тестирование продуктов, желающим повысить безопасность и защищенность выпускаемого программного обеспечения. Приведенные списки утилит, средств и готовых программных сред для фаззинга могут помочь сориентироваться при выборе решения и организации плана по тестированию на уязвимости.
Вызывает вопрос и высокая стоимость книги (65$ на amazon), что в полтора раза больше чем более интересная и содержательная (даже по страницам 2,5 раза толще) Fuzzing: Brute Force Vulnerability Discovery. К тому же, вот уже как 2 года продается ее русскоязычный вариант.

суббота, 28 мая 2011 г.

Социальные сети как средство поиска информации по email.

  Представим следующую ситуацию: вы получили тем или иным способом список email и хотели бы провести адресную рассылку. При этом, вам бы хотелось увеличить вероятность отклика каждого пользователя на ваше письмо. Для достижения этой цели было бы неплохо знать имя и фамилию владельца почтового ящика или дополнительную информацию о пользователе, чтобы указать ее в теме или теле письма. И тут на помощь могут прийти социальные сети. На первый взгляд, охране информации о почтовых адресах пользователей уделяется большое внимание, но существует механизм, который допускает получение информации о соответствии адреса и учетной записи в социальной сети. Я имею ввиду механизм, позволяющий проводить поиск ваших друзей по списку почтовых контактов.
  Данная функция присутствует в таких социальных сетях как facebook и linkedin. Первая охватывает практически всех интернет-активных пользователей, вторая содержит информацию о месте работы и роде занятий пользователя (данная информация может быть также полезна для составления тела посылаемого сообщения). Ситуация упрощается тем, что обе социальные сети позволяют загружать список контактов в виде файла. Facebook требует контакты в формате экспорт-файлов Thunderbird, Microsoft Outlook Express или Apple Mail. Это не является серьезным препятствием, и проблема решается написанием небольшой утилиты. Так, например, для перегонки файла с контактами в формат Thunderbird достаточно 15 строк на python. В случае с linkedin все еще проще, так как сеть позволяет грузить файлы в txt и csv форматах.
  Наиболее удобный формат представления найденных пользователей у facebook. Результаты поиска представляют список обнаруженных пользователей и содержат как имя, так и почтовый адрес. Linkedin в этом плане более скуп на данные - показывает только список, содержащий имена пользователей. Кроме того, у linkedin есть еще одна особенность. Заключается в том, что linkedin запоминает все контакты, по которым проводился поиск и каждый новый поисковый результат содержит данные предыдущих поисков. Это опять же не слишком усложняет жизнь, так как возможно написание вспомогательной утилиты, решающей данную проблему. Алгоритм работы можно предложить следующий: каждый раз разрешать только один адрес и результаты поиска сравнивать с локально сохраненными результатами предыдущего поиска. Таким образом единственная разница в списках и будет соответствовать искомому почтовому адресу. 15 строчками на python тут конечно дело не обойдется, но много времени на разработку уйти не должно.
  Еще немного о том, как можно использовать полученные данные. Как уже говорил, можно использовать информацию о месте работе, профессии для составления пробивного содержания письма. Аналогичным способом может быть использована информация о друзьях пользователя. Так, например, можно составить сообщение от имени друга пользователя (сослаться на новый почтовый ящик) и использовать полный спектр средств социальной инженерии - упрашивать пользователя перейти по ссылке, запустить exe из аттачмента или выслать список контактов.
  Данный способ был опробован на наиболее популярных социальных сетях facebook и linkedin, но аналогичный функционал может присутствовать и в других, в том числе и региональных.

пятница, 12 ноября 2010 г.

Полнотекстовый поиск и mongodb.

Не буду вдаваться в подробности каким образом я дошел до использования не-sql базы данных, скажу лишь, что в определенный момент мой мозг отказался вталкивать предметную область  одного из проектов в чужеродную ей реляционную модель. Данные не были формализованы, формат представления грозился сильно меняться со временем, а отдельные объекты угрожали обрасти атрибутами, о которых на момент проектирования я мог и не подозревать. Атакованный со всех сторон заманчивыми лозунгами nosql, я пустился во все тяжкие и, махнув рукой на неизведанность, принялся выбирать nosql решение. Среди многообразия предлагаемых систем моим разумом удалось завладеть только MongoDB. MongoDB - документоориентированная база данных, хранящая объекты в JSON формате, предоставляющая интерфейс запросов, mapReduce, автоматические репликации, шардинг и много чего другого вкусного, от чего очень сложно устоять. Более подробно и детально о всех преимуществах и недостатках можно легко узнать из  раздела документации проекта.
За время работы над информационными системами у меня сложилось стойкое представление о том, что эффективность информационной системы в большей степени формируется качеством и скоростью работы поискового механизма. А так как все более и более превалируют объемы неструктурированной информации на первый план выходит возможность полнотектового поиска.
Являясь поклонником postgresql, с удовольствием использовал предоставляемый этой СУБД механизм создания индексов для полнотекстового поиска. PostgreSQL позволяет получить качественный полнотекстовый поиск "из коробки" сведя к минимуму необходимые затраты на модификацию приложения.
Сложно, привыкнув к теплу и комфорту, сталкиваться с проблемой отсутствия аналогичного встроенного решения в MongoDB. Очень хотелось обойтись малой кровью и не влезать в долгосрочное изучение таких монстров как Lucene и Sphinx. Возможно решение на основе данных вариантов было бы гораздо лучше, но дефицит времени не оставлял выбора.
Стоит признать, что разработчики знают о данной проблеме и в списках рассылки поднималась тема внедрения механизма полнотекстового поиска, на трекере проекта создан тикет с точкой фиксации на версии 1.7.x. Так, что вполне возможно, что через год данная статья потеряет свою актуальность.
Благодаря возможности создавать индексы для вложенных в документ массивов, в качестве частичного решения можно рассмотреть следующий вариант. Разработчику предлагается выделить в рамках документа специальный атрибут, хранящий массив слов для поиска. Этот массив индексируется средствами mongodb и используется для поиска. Формирование данного массива полностью ложится на плечи разработчика. Создание индекса на данный массив позволит получить адекватную скорость выборки. Сразу можно отметить недостатки, а именно: необходимость дополнительной разработки функционала уровня DAO, а также разнообразие словоформ и малозначащие слова, которые существенно влияют на качество поиска. Относительно первого пункта не остается ничего кроме как мириться, ибо лезть внутрь сервера mongod и прикручивать полнотекстовый поиск - явно не та задача над которой хотелось тратить свое время. Со вторым пунктом можно справиться при помощи стемминга и фильтрации стоп-слов. Инструмент для реализации задуманного долго искать не пришлось, - все необходимое оказалось в Lucene.
Рассмотрим ситуацию, когда у документа есть текстовое поле, по которому необходимо будет проводить поиск. Назовем его text:
{
    _id: "id",
    text: "content of War and Peace of Leo Tolsoy here"
}
Можно предложить разделить простое содержимое на два поля: text.content и text.tsearch, где в content непосредственно будет располагаться оригинал текста, а tsearch будет содержать массив нормализованных слов для поиска. В результате документ примет вид:
{
    _id: "id",
    text: {
        content: "content of War and Peace of Leo Tolsoy here",
        tsearch: ["content", "war", "peac", "leo", "tolstoy", "here"]
    }
}

Важно не забыть создать индекс на tsearch: db.mydocs.ensureIndex({"text.tsearch": 1}).
Остальная работа сводится к написанию вспомогательной функции, которая на вход получает строку а на выходе выдает список слов, прошедших стемминг и фильтрацию на стоп-слова. Используем классы, предоставляемые библиотекой lucene-core:

private List<String> getTSearchList(String text) {
    List<String> searchTerms = new ArrayList<String>();
    Analyzer analyzer = new SnowballAnalyzer(LUCENE_30, "English", StandardAnalyzer.STOP_WORDS_SET);
    TokenStream tokenStream = analyzer.tokenStream("contents", new StringReader(text));
    TermAttribute termAttribute = tokenStream.getAttribute(TermAttribute.class);
    try {
        while( tokenStream.incrementToken() ) {
            searchTerms.add(termAttribute.term());
        } 
    } catch (IOException ignore) {}
    return searchTerms;
}

Существует несколько алгоритмов анализа входного потока. Наиболее приемлемые результаты дает SnowballAnalyzer. В случае использования текстовых данных специфичной области можно переопределить список слов для фильтрации.
Теперь осталось строку запроса аналогичным образом перевести в массив слов, над которым проведен стемминг и фильтрация, и сформировать BSON-объект запроса к базе. Используем элементы запроса $elemMatch и $all. В общем виде запрос "War and Peace" будет выглядеть следующим образом:

{text: {$elemMatch: {tsearch: {$all: ["war", "peac"]}}}

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

P.S. Из данного поста можно сделать дополнительный вывод, что полностью избавиться от костылей не получится. Решив хронические проблемы реляционных СУБД, вы неминуемо столкнетесь с проблемами nosql.

P.P.S. Если при разработке вы пользуетесь maven2, то все необходимые зависимости Lucene подключаются следующими блоками:
<dependency>
    <groupId>org.apache.lucene</groupId>
    <artifactId>lucene-core</artifactId>
    <version>3.0.2</version>
</dependency>

<dependency>
    <groupId>org.apache.lucene</groupId>
    <artifactId>lucene-snowball</artifactId>
    <version>3.0.2</version>
</dependency>

вторник, 2 ноября 2010 г.

Безопасность Oracle глазами аудитора: нападение и защита.

В связи с отпуском и вливанием в рабочий процесс не мог уделить внимание блогу в должной степени. Исправиться хотел бы обратив ваше внимание на книгу "Безопасность Oracle глазами аудитора: нападение и защита". Я уже говорил, что отечественный книжный рынок не балует любителей информационной безопасности большим разнообразием содержательных, а главное актуальных книг в данной области. В данном случае, данная книга является достойным представителем печатных изданий посвященных вопросам ИБ. Дополнительным стимулом к чтению данной книги является то, что ее автором является достаточно известный специалист в области защиты информации, один из основателей исследовательской лаборатории Digital Security Research Group - Александр Поляков, так же известный как @sh2kerr. Поляков - один из немногих в России, кто проводит сертификацию компаний по стандарту PCI DSS.
Книга позиционируется как продолжатель традиций "Атака на интернет". Именно с этой книги началось мое знакомство с миром компьютерной безопасности, так что не смог себе отказать в удовольствии ознакомиться с данным произведением.
Содержание книги посвящено такому важному вопросу как безопасность СУБД Oracle. Такая огромная и комплексная система как СУБД Oracle просто не может не содержать целую кладезь различного рода уязвимостей и слабостей, подвергающих угрозам не только хранимые данные, но и саму операционную систему, на которой Oracle функционирует.
Основной принцип построения книги - чтобы что-то хорошо защищать надо знать от чего защищать, а главное от кого, и как этот кто-то думает. Таким образом книга на 90% состоит из детального анализа сценариев и методов проникновения в Oracle, повышения привилегий, закрепления в системе и сокрытия признаков вторжения. Лишь 40-50 страниц посвящены вопросам аудита и корректной конфигурации сервера Oracle. Так что можно сказать, что книга больше подходит для интернет-злодеев, чем для администраторов.
В книге рассматривается комплексный последовательный подход к тестированию сервера Oracle на проникновение. Прочитав данную книгу можно получить представление о проблемах безопасности Oracle TNS Listener, раскрытия вспомогательной информации о базе, преодоление парольной защиты, PL/SQL инъекции, атаки на переполнение буфера, получения доступа к ОС через СУБД и другие атаки. В отдельную главу вынесена тема руткитов для Oracle.
Таким образом, данная книга может рассматриваться как начальное руководство для получения общего представления о вопросах безопасности Oracle. Ее можно рассматривать как отличную альтернативу The Oracle Hacker's Handbook, к тому же имеется однозначное преимущество в виде языка на котором она написана.

P.S. Пытался расшифровать QR-код на обложке книги - так ничего и не получилось. Интересно, содержит ли он какую либо реальную информацию.

четверг, 12 августа 2010 г.

Сквозная аутенфикация при помощи JA-SIG CAS. Часть четвертая - реализация клиента для Spring Framework.

Продолжим цикл статей, посвященных настройке аутенфикации веб-приложений с использованием SSO JA-SIG CAS. В этой статье предлагается рассмотреть, каким образом настроить веб-приложение, в основе которого лежит Spring Framework 3-й версии.

пятница, 30 июля 2010 г.

Google Analytics. Профессиональный анализ посещаемости веб-сайтов

Брайан Клифтон - глава отдела веб-аналитики Google по Европе, Ближнему Востоку и Африке, делится в своей книге секретами оценки успешности вашего веб-сайта посредством наиболее популярного инструмента - Google Analytics. Новый пользователь сталкивается с большим количеством диаграм, цифр, настроек, терминов. Разобраться в большинстве аспектов использования Google Analytics поможет данная книга. 380 страниц покрывают широчайший спектр вопросов начиная от механизма сбора статистики до принципов оптимизации страниц.
Читатель знакомится с понятиями конверсии, отказов, целей, профилей, компаний. Прочтение данной книги может помочь в определении тех типов отчетов, которые наиболее интересны будут вам, как владельцу сайта. Отдельное внимание уделяется вопросам интерпретации поведения пользователей в денежном эквиваленте, в том числе и для некоммерческих сайтов. Рассмотрена интеграция Google Analytics с такими продуктами как Google AdWords и WebSite Optimizer. Каждая глава посвящена решению какой либо конкретной проблемы - описанию того или иного отчета, настройке определенного фильтра, определению цели. Конкретика каждой главы подкреплена примерами кода на javascript, снимками страниц Google Analytics, ситуациями из жизни реальных компаний.
Мне встречались мнения, что данная книга не содержит ничего такого, что не содержалось бы в официальной справке по Google Analytics. Наверно, можно было бы согласиться с данным утверждением, но лишь отчасти.  Действительно, технически-подкованный человек без труда найдет решения своих проблем, ознакомившись с терминологией и типами отчетов в официальной справке. Но вот чего он не сможет найти, так это рекомендации и указания, какие типы отчетов наиболее были бы полезны в том или ином случае, или вызвали бы интерес у тех или иных людей, советы по настройке фильтров и профилей сайта, подходы к интерпретации полученных данных и их анализа. Полагаю, данную информацию также можно найти в открытых источниках, но книга позволит вам сэкономить ваше время. Так что, если на работе вам внезапно свалился бонус в виде подготовки отчетов об эффективности веб-ресурса компании, то данная книга придется вам как никогда кстати.
Книгу можно было бы рекомендовать всем,  кого интересуют вопросы эффективности его сайта, неважно блог это или промо-сайт. Особенно посоветовал бы данную книгу тем, кто задумывается над открытием собственного бизнеса в интернете. Получить понимание об объеме работы, которую необходимо будет провести в области регулярной аналитики, никогда не бывает лишним. Это поможет рассчитать собственные силы или навести на мысль о целесообразности привлечения стороннего специалиста.
P.S.  С книгой идет подарочный сертификат от Google AdWords. К сожалению срок годности его закончился в 2009 году.

четверг, 22 июля 2010 г.

Сквозная аутенфикация при помощи JA-SIG CAS. Часть третья - настройка SSL в Tomcat 6.

В предыдущих частях (1, 2), посвященных системе сквозной аутенфикации, описывались начальные шаги по развертыванию системы сборки CAS-сервера и реализации обработчика аутенфикации. На данном этапе у нас должна быть сборка CAS-сервера, готовая к развертыванию на рабочем сервере. Это не представляет труда за одним небольшим нюансом. Протокол CAS требует работы через SSL. Таким образом, появляется необходимость настройки SSL для веб-контейнера. Наиболее популярным веб-контейнером является Apache Tomcat. На момент написания данной статьи, актуальной являлась версия 6.0.28. Данная статья покажет один из способов настройки поддержки SSL для Tomcat.