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

В культовом фильме начала двухтысячных «Пароль «Рыба-меч» талантливому хакеру необходимо подобрать пароль в течение одной минуты. В этом ему помогает приятель, который заботливо держит пистолет у виска и темпераментная блондинка, прячущаяся под столом. Что делать, если таких друзей поблизости нет, а пароль подобрать необходимо? Например, в ходе тестирования на проникновение…

Небольшое, но важное предупреждение: если предлагаемым в статье подходом пользоваться не в рамках проектов по тестированию защищенности, то ваши действия легко могут подпасть под статью 272 УК РФ (Неправомерный доступ к компьютерной информации).

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

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

Когда речь заходит о хакинге, неважно, об этичном или не очень, многие из нас представляют темное помещение с мониторами и очкастым профессионалом с красными от постоянного недосыпания глазами. Действительно ли систему может взломать только гик-профессионал и действительно ли для того, чтобы протестировать защищенность своих систем необходимо привлекать только таких экспертов? А нельзя ли вооружить грамотного ИТ-специалиста хакерскими инструментами и логичной методологией и получить качественный результат? Попробуем разобраться.

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

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

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

В комментариях к первой нашей статье, читатели просили побольше практических примеров и скриншотов, поэтому в этой статье практики и графики будем много. Для демонстрации возможностей «продвинутого» поиска Google в качестве целей были выбраны личные аккаунты автора. Сделано это, чтобы никого не обидеть излишним интересом к его частной жизни. Хочу сразу предупредить, что никогда не задавался целью скрыть свое присутствие в интернете, поэтому описанные методы подойдут для сбора данных об обычных людях, и могут быть не очень эффективны для деанонимизации фэйковых аккаунтов, созданных для разовых акций. Интересующимся читателям предлагаю повторить приведенные примеры запросов в отношении своих аккаунтов и оценить насколько легко собирать информацию по ним.

А почему у тебя на визитке написано «КИСА»?
Ты вроде серьезный человек…
(из разговора с приятелем)

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

В рамках этой серии рассматриваются наиболее часто встречающиеся дефекты в программном коде, которые могут привести к серьезным уязвимостям. В этой статье мы остановимся на широком классе дефектов типа "Expression Issues" и рассмотрим их на примерах на языках PHP и Java.

В международной классификации CWE данный тип дефектов известен как CWE-569: Expression Issues. К нему относятся различные ошибки в логических выражениях в коде программы. Частным случаем дефекта такого класса является дефект «Присваивание вместо сравнения».