Новости мира информационной безопасности. Расследование и реагирование на инциденты. Кибербезопасность.

Новости информационной безопасности




Хакеры рассказали, как обойти новый сервис Amazon Key

Исследователи из Rhino Security Labs представили ряд способов, позволяющих обойти систему видеонаблюдения и ограбить дом.

В прошлом месяце Amazon представила новый сервис Amazon Key, позволяющий открывать дверь курьерам компании, когда хозяев нет дома. По словам Amazon, пользователям нечего опасаться, так как система осуществляет непрерывный мониторинг с помощью камеры для внутреннего видеонаблюдения Cloud Cam с поддержкой Alexa.

Исследователи из Rhino Security Labs не согласны с уверением компании в полной безопасности нового сервиса. Они продемонстрировали несколько техник, позволивших им обмануть Cloud Cam. Предложенные исследователями способы сравнительно простые и позволяют недобросовестным курьерам или другим злоумышленникам передвигаться по дому незамеченными.

Для обхода камеры видеонаблюдения достаточно иметь компьютер с определенным ПО, находящийся в зоне действия домашней сети Wi-Fi. В видео ниже продемонстрирован «курьер», открывающий дверь с помощью PIN. Он входит в комнату, оставляет посылку и закрывает за собой дверь, как и полагается.

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

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

Дата: 2017-11-17 06:18:02

Источник: http://www.securitylab.ru/news/489754.php



Oracle устранила опасные уязвимости в ряде своих продуктов

Проблемы позволяют неавторизованным атакующим получить полный доступ к данным.

Компания Oracle выпустила экстренное обновление безопасности, устраняющее пять уязвимостей в продуктах, использующих фирменную технологию Jolt. Проблемы, обнаруженные экспертами ERPScan, получили общее название JoltandBleed по аналогии с уязвимостью HeartBleed .

Уязвимости, две из которых оценены в 9.9 и 10 баллов по шкале CVSS, затрагивают решения Oracle PeopleSoft Campus Solutions, Human Capital Management, Financial Management, Supply Chain Management и другие продукты, использующие сервер приложений Tuxedo 2. Проблемы позволяют неавторизованным атакующим получить полный доступ к данным.

Наиболее серьезная уязвимость (CVE-2017-10269) затрагивает протокол Jolt и позволяет злоумышленники полностью скомпрометировать систему PeopleSoft. Проэксплуатировав проблему CVE-2017-10272 (9.9 баллов по шкале CVSS), атакующий может удаленно получить доступ к памяти сервера. Путем отправки специально сформированных пакетов преступник может извлечь данные сессии, логины/пароли и получить доступ к целевой системе.

CVE-2017-10267 (7.5 балла) и CVE-2017-10278 (7 баллов) представляют собой уязвимости переполнения буфера. Наконец, CVE-2017-10266 (5.3 балла) позволяет злоумышленнику с помощью брутфорса получить пароль DomainPWD. Проблемы JoltandBleed затрагивают версии Oracle Tuxedo 11.1.1, 12.1.1, 12.1.3 и 12.2.2. Производитель рекомендует установить патчи как можно скорее.

Oracle Tuxedo – сервер приложений для программ, написанных на C, C++, COBOL.

Oracle Tuxedo Jolt – предоставляет интерфейс прикладного программирования (API) для доступа к приложениям Tuxedo с отдельных клиентов или других сред Java.

Дата: 2017-11-17 05:59:14

Источник: http://www.securitylab.ru/news/489755.php



Китай оттягивает раскрытие уязвимостей с целью их эксплуатации

В промежутке между обнаружением и сообщением о проблеме ее эксплуатируют связанные с правительством APT-группы.

Утечки эксплоитов ЦРУ и АНБ США являются свидетельством того, что американские власти не сообщают производителям об уязвимостях в их продуктах с целью в дальнейшем использовать их в атаках. Без сомнения, правительства других государств поступают точно так же, однако информация об этом широкой общественности не раскрывается.

В четверг, 16 ноября, компания Recorded Future опубликовала исследование, согласно которому Китай, если и не занимается сбором, то, по крайней мере, оттягивает раскрытие критических уязвимостей. В промежутке между обнаружением и сообщением о проблеме ее эксплуатируют APT-группы, предположительно связанные с китайским правительством.

Вышеупомянутое исследование является продолжением более раннего исследования, демонстрирующего, что национальная база уязвимостей КНР (находится в ведении Министерства госбезопасности Китая) пополняется гораздо быстрее, чем ее американский эквивалент. Тем не менее, в некоторых случаях уязвимости попадают в нее позже. Как раз эти случаи и заинтересовали специалистов Recorded Future, и в ходе своего исследования они пришли к неожиданным выводам.

В частности эксперты обратили внимание на три уязвимости, попавшие в китайскую базу позже, чем в американскую. Первая из них – CVE-2017-0199, использовавшаяся в атаках WannaCry и NotPetya. В американской базе она появилась 12 апреля 2017 года, а в китайской – на 50 дней позже (7 июня). По данным компании Proofpoint, в этот промежуток времени проблема эксплуатировалась китайской хакерской группой TA459 для атак на предприятия аэрокосмической промышленности России и Республики Беларусь. Министерство госбезопасности КНР могло намеренно отложить внесение уязвимости в национальную базу, чтобы использовать ее в своих операциях или дать возможность другим организациям эксплуатировать ее в интересах китайского правительства, считают в Recorded Future.

Еще две уязвимости – CVE-2016-10136 и CVE-2016-10138, затрагивающие ПО для Android-устройств, разработанное китайской компанией Shanghai Adups Technology. Как сообщили в ноябре прошлого года исследователи Kryptowire, уязвимости были равнозначны бэкдору, похищающему и передающему на сервер в Китае текстовые сообщения, списки контактов, журналы звонков, и другие данные с некоторых моделей Android-устройств. В американскую базу они были добавлены спустя два месяца после публичного раскрытия, а в китайскую – еще через восемь.

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

Дата: 2017-11-17 05:18:21

Источник: http://www.securitylab.ru/news/489753.php



Как развернуть центр мониторинга ГосСОПКА на базе решения R-Vision

В январе 2013 года вступил в силу Указ Президента Российской Федерации «О создании государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации». Документ определил основные задачи ГосСОПКА, а также определил орган исполнительной власти, на который были возложены полномочия по созданию и обеспечению функционирования ГосСОПКА (ФСБ России).

Основные задачи ГосСОПКА согласно Указу № 31с:

а) прогнозирование ситуации в области обеспечения информационной безопасности Российской Федерации;

б) обеспечение взаимодействия владельцев информационных ресурсов Российской Федерации, операторов связи, иных субъектов, осуществляющих лицензируемую деятельность в области защиты информации, при решении задач, касающихся обнаружения, предупреждения и ликвидации последствий компьютерных атак;

в) осуществление контроля степени защищенности критической информационной инфраструктуры Российской Федерации от компьютерных атак;

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

В декабре 2014 года Президентом РФ была утверждена Концепция государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации» (утверждена Президентом РФ 12 декабря 2014 г. № К 1274), в которой уточнялось назначение, принципы создания и функционирования ГосСОПКА.

В 2015 году ФСБ России в рамках развития ГосСОПКА создает Национальный координационный центр по компьютерным инцидентам (НКЦКИ), который согласно закону РФ от 26 июля 2017 г. N 187-ФЗ «О безопасности критической информационной инфраструктуры» обеспечивает координацию деятельности субъектов критической информационной инфраструктуры по вопросам обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты.

С 2016 года НКЦКИ разрабатывает методические рекомендации по созданию ведомственных и корпоративных центров ГосСОПКА, в которых освещены общие вопросы создания центров ГосСОПКА и основные функции.

На текущий момент проект методических рекомендаций по созданию ведомственных и корпоративных центров ГосСОПКА содержит 12 функций ГосСОПКА. Отметим, что некоторые источники указывают на 11 функций. Документ также перечисляет набор технических средств, который может быть использован для выполнения этих функций.

Сюда входят:

При этом рекомендуется обеспечить их интеграцию.

Мы проанализировали указанные выше методические рекомендации с точки зрения того, в какой степени функции центра мониторинга (ЦМ) ГосСОПКА могут быть реализованы на базе решения R-Vision Incident Response Platform (R-Vision IRP) и какие технические средства необходимо использовать, чтобы полностью обеспечить реализацию каждой функции.

В документе осознанно не упоминаются конкретные производители сторонних решений, а только классы решений. Данная публикация отражает субъективную трактовку методических рекомендаций специалистами компании R-Vision.

12 функций ГосСОПКА и как они реализуются с помощью R-Vision IRP

Стоит отметить, что платформа R-Vision IRP объединяет в себе 4 средства, упомянутых в рекомендациях, являясь одновременно средством для взаимодействия персонала ЦМ, взаимодействия с главным центром ГосСОПКА, средством инвентаризации информационных систем, а также средством учета и обработки инцидентов.

В методических рекомендациях перечислены следующие функции ГосСОПКА:

  1. Инвентаризация информационных ресурсов
  2. Анализ уязвимостей информационных ресурсов
  3. Анализ угроз информационной безопасности
  4. Антивирусная защита информационных ресурсов
  5. Повышение квалификации персонала информационных ресурсов
  6. Прием сообщений об инцидентах
  7. Обнаружение компьютерных атак
  8. Анализ данных о событиях безопасности
  9. Регистрация инцидентов
  10. Реагирование на инциденты и ликвидация их последствий
  11. Установление причин инцидентов
  12. Анализ результатов устранения последствий

Проведя детальное сравнение функциональных требований к центру мониторинга ГосСОПКА и возможностей продукта R-Vision IRP, мы сделали вывод о том, что разрабатываемое нами решение в целом позволяет обеспечить выполнение почти половины (48%) всех рекомендаций.

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

Рассмотрим подробнее каждую из 12 функций центра мониторинга ГосСОПКА.

№1 Инвентаризация информационных ресурсов

Функция инвентаризации информационных ресурсов предусматривает сбор сведений об информационных ресурсах, находящихся в зоне ответственности ЦМ ГосСОПКА. Эти сведения включают в себя:

Эти данные должны уточняться не реже, чем раз в квартал или при изменении состава оборудования и ПО.

Функция инвентаризации может быть полностью реализована с помощью платформы R-Vision IRP. Программный продукт позволяет собрать все необходимые сведения по информационному ресурсу, перечисленные в методических рекомендациях, соблюдая требуемую периодичность сбора и уточнений информации.

Возможности системы R-Vision IRP, позволяющие реализовать требования:

  1. Собственный движок инвентаризации.
  2. Коннекторы к поставщикам инвентаризационной информации: CMDB-решениям, сканерам защищенности, антивирусам, базам данных и другим решениям.
  3. Обогащение информации об информационных ресурсах из разных источников.
  4. Управление жизненным циклом ИТ-активов.
  5. Автоматизация связей информационных активов и оборудования.

 №2 Анализ уязвимостей информационных ресурсов (ИР)

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

Платформа R-Vision IRP позволяет реализовать порядка 20% функции анализа уязвимостей, обеспечивая автоматизацию деятельности по управлению жизненным циклом уязвимостей. В продукте имеются следующие возможности:

  1. Наличие коннекторов ко всем распространённым сканерам защищенности.
  2. Поддержка базы угроз Vulners.
  3. Отображение информации об уязвимостях из разных источников.
  4. Отображение взаимосвязи активов и обнаруженных на них уязвимостей.

Остальная часть функции анализа уязвимостей может быть обеспечена за счет следующих организационно-технических мер: применения средств анализа защищенности (выявление уязвимостей); применения средств анализа кода и безопасной разработки ПО, применения средств анализа кода веб-приложений и их защиты, включая поддержку http/https (WAF), проведения периодических пентестов, аудитов, анализа документации ИС, контроля соответствия требованиям и устранения выявленных ранее уязвимостей и недостатков.

№3 Анализ угроз информационной безопасности

Анализ угроз информационной безопасности проводится на основе информации, полученной в результате инвентаризации и анализа уязвимостей. Цель этого этапа – выявить способ проведения компьютерной атаки и разработать меры противодействия.

Анализ угроз включает в себя определение возможных угроз, связанных с компьютерными атаками на информационный ресурс; идентификацию уязвимостей; определение способов проведения атак, их признаков, способов их обнаружения и мер реагирования на них; определение возможных путей и выработку организационно-технических мер противодействия атакам. После чего готовится набор необходимых методических документов (правил, политик, инструкций для персонала и т.д.).

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

Примерно 10% рекомендаций по анализу угроз может быть обеспечено платформой R-Vision IRPза счет следующих возможностей системы:

  1. Анализ сведений по обнаруженным уязвимостям ИР из различных источников в единой системе.
  2. Поиск потенциально нелегитимного или вредоносного ПО на объектах ИР (на основе полученной информации по угрозам).
  3. Моделирование угроз.
  4. Определение ложных срабатываний по уязвимостям.
  5. Визуализация связей ИТ-активов и уязвимостей.

№4 Антивирусная защита информационных ресурсов

Функция антивирусной защиты информационных ресурсов подразумевает применение средств антивирусной защиты (САЗ) в составе информационных ресурсов и проверку подозрительных файлов определенным набором средств.

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

В техническом плане антивирусная защита ИР может обеспечиваться за счет применения средств антивирусной защиты, средств антивирусной защиты в составе COA/COB (IPS), средств анализа сетевого трафика, средств поведенческого анализа (песочницы), Anti-APT — решений.

Платформа R-Vision IRP выполняет функцию документационного обеспечения деятельности по информационной безопасности, включая деятельность по антивирусной защите. Кроме того, при подключении к R-Vision средств антивирусной защиты платформа может применяться в качестве дополнительного источника контроля состояния работы хостовых агентов САЗ. Таким образом, с помощью продукта может быть обеспечена реализация порядка 27% рекомендаций данного раздела.

№5 Повышение квалификации персонала информационных ресурсов

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

R-Vision IRP может служить платформой повышения квалификации персонала, позволяя реализовать 50% всех установленных рекомендаций. Благодаря интеграции продукта c сервисом обучения и контроля защищенности Antiphish.ru, доступны следующие возможности:

  1. Автоматизация деятельности по управлению обучением сотрудников ИР.
  2. Наличие различных программ обучения с возможностью проверки знаний.
  3. Возможность локального размещения сервиса по обучению пользователей в организации.
  4. Имитация действий злоумышленников, выявление наименее осведомленных пользователей по вопросам кибербезопасности.
  5. Получение статистики, отчетности по обучению пользователей ИР.

№6 Прием сообщений об инцидентах

Данная функция подразумевает централизованный прием сообщений о возможных инцидентах от пользователей и персонала ЦМ с помощью какого-либо средства взаимодействия. Сообщение может быть сформулировано в произвольной форме. Далее на его основании создается карточка инцидента, куда заносятся все имеющиеся сведения об инциденте.

Блок рекомендаций по организации приема сообщений об инцидентах может быть реализован за счет использования платформы R-Vision IRP на 80%. Для этого в продукте имеются следующие возможности:

  1. Обеспечение деятельности по приему, обработке и хранению сообщений об инцидентах в ЦМ в единой системе.
  2. Прием сообщений от других сегментов ГосСОПКА.
  3. Прием сообщений об инцидентах операторами ЦМ (почта, телефон с последующим внесением данных в систему).
  4. Встроенный почтовый сервер, прием почтовых сообщений в режиме online и их обработка
  5. Прием сообщений об инцидентах от других центров мониторинга, использующих платформу , а также внешних провайдеров услуг мониторинга и реагирования (например, сервиса JSOC).

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

№7 Обнаружение компьютерных атак

Цель обнаружения компьютерных атак – своевременное реагирование на связанные с ними инциденты и ликвидация последствий. Эта функция реализуется за счет использования средств обнаружения компьютерных атак и межсетевых экранов прикладного уровня, средств анализа сетевого трафика, а также средств поведенческого анализа (песочницы, Anti-APT).

№8 Анализ данных о событиях безопасности

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

№9 Регистрация инцидентов

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

Рекомендации по регистрации инцидентов могут быть обеспечены за счет платформы R-Vision IRP практически полностью (на 90%). В продукте для этого имеются следующие возможности:

  1. Управление жизненным циклом инцидентов, накопление и обогащение информации в единой БД .
  2. Регистрация инцидентов через веб-форму Оператором ЦМ вручную.
  3. Регистрация инцидентов посредством интеграции с SIEM + 2х сторонний обмен статусами.
  4. Регистрация инцидентов по результатам обработки почтовых сообщений (парсинг почтовых сообщений по тегам или регулярным выражениям).

Оставшиеся рекомендации по регистрации инцидентов обеспечиваются организационными мерами.

 

№10 Реагирование на инциденты и ликвидация их последствий

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

R-Vision позволяет автоматизировать указанные процессы и обеспечить выполнение порядка 70% рекомендаций данного раздела. Остальная его часть выполняется организационными мерами.

Возможности платформы R-Vision IRP, позволяющие реализовать функцию реагирования на инциденты и ликвидацию их последствий:

  1. Наличие гибкого конструктора правил реагирования, позволяющего реализовать любой сценарий реагирования.
  2. Наличие порядка 40 скриптов реагирования и возможность создания собственных скриптов.
  3. Возможность создания цепочки действий в сценарии реагирования, включая действие, выполняющееся автоматически на основе анализа предыдущего действия.
  4. Автоматизация функций по назначению, уведомлению ответственных, постановки задач и сроков реагирования.
  5. Контроль и управление задачами персонала ЦМ.
  6. Автоматизация функций по сбору свидетельств и доказательств.
  7. Возможность отправления команд на сетевые СЗИ.

№11 Установление причин инцидентов

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

Рекомендации по обеспечению установления причин инцидентов платформа R-Vision IRP позволяет реализовать примерно на 25%. Для этого в продукте имеются следующие возможности:

  1. Анализ сведений по инцидентам, просмотр карточки инцидента, свидетельств, результатов выполнения скриптов реагирования.
  2. Анализ реализованных сценариев, их визуализация, анализ действий персонала ЦМ.
  3. Анализ существующих процессов, методических документов.
  4. Анализ взаимосвязей инцидентов, информационных и физических активов и их свойств, включая уязвимости.

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

№12 Анализ результатов устранения последствий

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

Такой анализ может быть реализован на базе платформы R-Vision IRP, предоставляющей следующие возможности:

  1. Оценка предотвращенного ущерба от реализации инцидентов.
  2. Анализ действий персонала ЦМ.
  3. Оценка ущерба от реализации инцидентов.
  4. Анализ сроков реагирования на инциденты.
  5. Анализ принятых мер и их корректировка.

Таким образом за счет применения платформы R-Vision IRP обеспечивается практически полная (93%) реализация установленных рекомендаций, а для обеспечения других рекомендаций данного раздела применяются организационные меры.

Выводы

Ключевые функции платформы R-Vision IRP позволяют использовать ее как платформу оркестрации в ЦМ, способную агрегировать информацию по активам и их свойствам, включая уязвимости, принимать сообщения об инцидентах и осуществлять их регистрацию, управлять командой центра мониторинга, автоматизировать деятельность по управлению реагированием на инциденты, проведением расследований, повышением осведомленности пользователей. Таким образом, платформа R-Vision IRP может выступать основой для создания ЦМ ГосСОПКА.

Наличие коннекторов к распространенным техническим средствам, которые могут быть использованы для создания ЦМ ГосСОПКА, позволяют также использовать R-Vision IRP как интеграционную платформу.

Дата: 2017-11-17 05:10:40

Источник: https://rvision.pro/blog-posts/kak-razvernut-tsentr-monitoringa-gossopka-na-baze-resheniya-r-vision/



Производитель дронов DJI по ошибке опубликовал закрытые ключи и пароли

Компания DJI, один из крупнейших производителей дронов, по недосмотру разместила на GitHub архив, в котором были оставлены закрытые ключи для HTTPS-сертификатов *.dji.com, AES-ключи для шифрования прошивок, а также пароли доступа к облачным окружениям в AWS и службе хранения Amazon S3. По данным заметивших ключи исследователей, архив находился в открытом доступе от двух до четырёх лет.

Находящейся в архиве информации было достаточно для полной компрометации инфраструктуры компании и подмены сайтов, включая security.dji.com (Security Reporting Center). В ходе экспериментов исследователю также удалось получить доступ к логам о ходе полётов и идентификационной информации.

В настоящее время ключи уже отозваны и заменены на новые. Интересно, что компания DJI выразила готовность выплатить исследователю награду в 30 тысяч долларов США, но для получения премии нужно было подписать соглашение о неразглашении, условия которого исследователь посчитал неприемлемыми и раскрыл данные об утечке, независимо от возможности получения гранта.

Дата: 2017-11-17 04:52:21

Источник: http://www.opennet.ru/opennews/art.shtml?num=47584



Расширение для Chrome похищало пользовательские данные

Специалист по IT-безопасности Лоуренс Абрамс (Lawrence Abrams) во вторник 14 ноября опубликовал подробный анализ Browse-Secure — расширения для Google Chrome. В рекламе этого приложения говорилось о необходимости «вернуть браузеру былую безопасность» (Make your browser safe again — отсылка к предвыборному слогану Дональда Трампа: Make America great again). Однако в действительности расширение похищало личные данные пользователей и переправляло их на удаленные серверы.

Абрамс разобрался в исходном коде плагина и обнаружил, что сразу после установки он отправляет запрос на сайт backend.chupashop.com/getuid4search, а затем начинает сбор информации. Основной целью было получение личных данных с сайтов Facebook и LinkedIn: имени, адреса, номера мобильного телефона и e-mail. Помимо этого, расширение переадресует все поисковые запросы пользователей на сайт разработчиков, причем эта ситуация происходит не только с Google, но и с MSN, Bing и другими популярными в США ресурсами. Таким образом, в руках у мошенников оказываются данные об IP-адресах и, в какой-то степени, история веб-серфинга.

Изначально Browse-Secure можно было скачать с Chrome Web Store. Поскольку приложение было новым, отсутствовали и отзывы, и пользовательский рейтинг. На момент написания статьи подозрительный плагин уже удалили из официального магазина приложений, поэтому нельзя сказать, много ли людей успели его установить. Однако сайт разработчиков Browse-Secure еще функционирует, на главной странице нет информации о компании или доступных продуктах. Имеется только большая кнопка, клик по которой запустит установку другого расширения, которое называется SpyShield.

В октябре 2017 года Абрамс выявил плагин для Chrome под названием Ldi, который загружал скрипт для майнинга криптовалюты и похищал адреса электронной почты пользователей. Еще чаще зловреды появляются в официальном магазине Google Play Store. В октябре компания объявила об удалении сразу восьми приложений, которые использовались мошенниками для «скликивания» рекламных баннеров и, возможно, для осуществления DDoS-атак. В ноябре стало известно, что новое приложение Update WhatsApp Messenger занималось показом рекламы и самостоятельным скачиванием дополнительных файлов из Интернета, прикрываясь названием известного мессенджера.

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

Дата: 2017-11-17 02:45:44

Источник: https://threatpost.ru/malicious-chrome-extention-stole-facebook-and-linkedin-info/23270/



Управление логами - фундамент любой SIEM, в котором часто зияют прорехи

Уже совсем скоро пройдет конференция ЦБИ "Мониторинг ИБ: проблемы построения и эксплуатации", на которой я буду вести секцию про полноту и "доступность" источников информации, которые подключаются к SIEM, а потом на их основе работает SOC и принимаются решения о наличии или отсутствии угроз. По сути именно от того, насколько выстроена работа с источниками зависит эффективность всей системы кибербезопасности.

Давайте вспомним вот эту иллюстрацию двухнедельной давности:

soc2017-2.png
В ней атомарным элементом считаются логи. Все логи сразу. Многие компании, да и производители SIEM, могут сказать, что уже они то выстроили достаточно зрелый, может быть даже на пятом уровне, процесс управления логами. И в принципе, не сильно задумываясь, мы можем с ними согласиться, так как о том, как работать с логами, как одним из источников информации ИБ, говорят уже много лет и даже десятилетий. Первые хостовые IDS, появившиеся в начале 80-х годов, как раз опирались в своей работе на данные из журналов регистрации. Можно предположить, что уж с логами-то за почти 40 лет у нас научились работать. Но история умеет преподносить сюрпризы. Вот так выглядит слайд из вчерашней презентации Антона Чувакина из Gartner, который рассказывал про технологию пользовательской поведенческой аналитики (UEBA):
Screen%2BShot%2B2017-11-16%2Bat%2B22.10.37.png

Обратите внимания на первый пункт в списке основных проблем при внедрении и использовании UEBA - сбор данных, их доступность и качество. И это спустя 40 лет после появления первых хостовых IDS и 20 лет после появления первых SIEM. А ведь SIEM, которые в принципе должны уметь работать с источниками данных, потом отдают информацию в UEBA, а также иные системы аналитики ИБ.
Screen%2BShot%2B2017-11-17%2Bat%2B01.31.24.png

Но если источники данных плохие, то и все принятые на их основе решения тоже можно поставить под сомнение. В "лучшем" случае мы просто будем пропускать атаки и инциденты, а в худшем - пойдем по неверному пути, принимая неверные решения, тратя ресурсы не на то.

Какие проблемы можно выделить при работе с источниками информации? Их немало:


Разумеется, все эти проблемы могут быть решены, но об этом все-таки лучше поинтересоваться у производителя SIEM/UEBA/NTA/IDS и других ИБ-решений. Ну а если вы пишете систему защиты/аналитики сами, то просто подумайте, как вы будете решать эти проблемы? Вот именно этим вопросам и будет посвящена секция на конференции ЦБИ, которую я модерирую. Выступать в ней будут представители:

и их ждут непростые вопросы от меня :-)

Дата: 2017-11-17 02:43:07

Источник: http://lukatsky.blogspot.com/2017/11/siem.html



DumpsterFire - Security Incidents In A Box!

DumpsterFire_1_DumpsterFireMainMenu.png

DumpsterFire Toolset - "Security Incidents In A Box!"

The DumpsterFire Toolset is a modular, menu-driven, cross-platform tool for building repeatable, time-delayed, distributed security events. Easily create custom event chains for Blue Team drills and sensor / alert mapping. Red Teams can create decoy incidents, distractions, and lures to support and scale their operations. Turn paper tabletop exercises into controlled "live fire" range events. Build event sequences ("narratives") to simulate realistic scenarios and generate corresponding network and filesystem artifacts.

The toolset is designed to be dynamically extensible, allowing you to create your own Fires (event modules) to add to the included collection of toolset Fires. Just write your own Fire module and drop it into the FireModules directory. The DumpsterFire toolset will auto-detect your custom Fires at startup and make them available for use.

Author

Joe Gervais (TryCatchHCF)

Why

Red Teams and Blue Teams are typically overextended. What's missing is a way to scale each team's capabilites, providing more effective Red Team activity, and more realistic (and helpful) Blue Team / Purple Team exercises. Automation to the rescue! The DumpsterFire Toolset is a cross-platform menu-driven solution that allows you to easily create custom security incidents by combining modular, chained events into a consistent narrative. Those collection of events (DumpsterFires) can then be executed as time-delayed, automated processes. (They can also be triggered immediately, of course.)

The result? While you're in a meeting or out enjoying life, your DumpsterFire is waiting for its date-time trigger to activate. On a Red Team engagement, while you're busy exploiting that exposed service on a forgotten B2B server, your cloned & time-sychronized DumpsterFires are busy lighting up the target organization's SIEM on a far-away subnet, distracting their response team. Blue Teamers can turn table-top paper exercises into "live fire" range events, with controlled, pre-approved DumpsterFire event chains to trigger sensors and alerts, and train your analysts using their actual operational environment. Purple Team operations can now execute methodical, repeatable event chains to consistently map out their sensor and alerting posture. You can generate novel scenarios to test and train your teams, getting ahead of the threat space to be prepared for security contingencies.

Ever wondered how your Blue Team would respond to Mirai bot activity on your internal network? Now you can find out! (Don't worry, the Mirai bot Fire module doesn't pivot, but it does use the same usernames & passwords to brute-force telnet sessions across the target network.)

Don’t have a Red Team but wish you had an easy way to run controlled, repeatable, customized drills against all of your SOC shift teams? Done!

Wish you could support a Red Team engagement against a remote team that’s 7 timezones away, without waking up at 3:00am? Hit that snooze button!

Ever wanted to simultaneously rickroll all of your opponents’ systems during your annual cyberwarfare exercise? "Never gonna let you down!"

See sample DumpsterFires below. And of course the Shenanigans section.


Tutorial
See my CactusCon 2017 slides (included in project). The slides are written to stand on their own, providing background, approaches, specific use cases, and more. They'll put everything in context, and also won't put you to sleep. Unless they do put you to sleep, in which case you probably needed some rest anyway, so really we all come out ahead here.

Accountability
DumpsterFire creates a date-time stamped event log so that Red- and Blue teams can coordinate and track events, correlating them to what was detected (or not detected) by your sensors, which alerts did or did not trigger, etc. It also allows teams to confirm which events were part of your operation / exercise, keeping everyone out of trouble. All date-time tracking is performed in UTC, so your global operations can be easily correlated without worrying about conversions between timezones and international date lines.
The auto-generated date-time stamped event logs also provide an effortless value add to your engagements. Generate a collection of DumpsterFires for your client engagements, tailored to their attack surfaces. At the end of your operations you can hand over the logs as a bonus Purple Team deliverable to your client for post-engagement analysis.

DumpsterFire_2_FireDateTimeStamps.png

Overview

The DumpsterFire toolset workflow is designed to be user-friendly and robust. Everything can be done from within the menu-driven dumpsterFireFactory.py script. Launch the script and the tool will guide you as you go. You can start by browsing the existing Fire modules and saved DumpsterFires. When you're ready to create your own DumpsterFires, the tool will lead through the workflow to get the job done. Finally it will be time to ignite your DumpsterFire. After selecting the DumpsterFire of your choice, you'll review the DumpsterFire's Fire modules and settings. If everything looks good, light it up!

When you're building a DumpsterFire, after you've chosen all of the Fire modules you wish to include, the tool will loop through the list of Fires. If a Fire has options for custom settings, the tool will call that Fire's Configure() method to present you with prompts for its settings (e.g. a target network's IP address).

Once all of the Fires have been configured, you'll then be given the option to assign individual time delays to your Fires. This allows the DumpsterFire to better mimic real operations when executing its chain of events. For example, the first Fire may visit various hacking Websites, the next Fire then downloads a few common hacking tools before launching the third Fire which starts scanning the local network. If this all happened within seconds of each other, no SOC analyst is going to believe it was a human. By adding several minutes or even hours between those events, you create a more realistic chain of events.

After all of the Fires have been configured and optional individual Fire delays assigned, you'll be asked to name your DumpsterFire. Do not use spaces or odd special characterse, just stick to letters, numbers, underscores, and hyphens.

Voila! You have now created your first DumpsterFire. Time to light one up!

When you're ready to ignite a DumpsterFire, the tool will first show you the DumpsterFire's settings. If everything looks good, you'll be asked if you want to assign a date-time delay before igniting. All date-time processing is done in UTC to ensure consistent execution regardless of your DumpsterFire's location of execution. Otherwise you can decline the date-time delay and execution will begin immediately after you give final confirmation.

As the DumpsterFire executes, you'll be given regular date-time stamped feedback on each Fire's status and critical events. This not only helps you track progress, but also provides a chronological record of your DumpsterFire's activities - critical in coordinating and deconflicting your events from the general background noise that floods every SOC. You can also hand over the chronological record to your external clients after your operations are complete, as a value-added record of your activites that they can use to review their sensor and alert settings. All with no extra effort on your part.

Shenanigans

April 1st happens! So do cyber wargames or your best friend's birthday. Some circumstances call for a little extra something. Finally infiltrate your opponent's perimeter in that net wars competition? Celebrate with Shenanigans while locking in your victory! Best friend leave their screen unlocked on game night? Sharing is caring! DumpsterFire's Shenanigans let you add some flavor to your operation.

Want to open the system's default browser and stream all of that Rick Astley awesomeness? After setting their system volume to maximum? How about opening any URL you choose? Or setting the system's shell aliases to pretend the filesystem is corrupted?

DumpsterFire_3_DumpsterFireShenanigans.png
Files & Directories
dumpsterFireFactory.py - Menu-driven tool for creating, configuring, scheduling, and executing DumpsterFires
FireModules/ - Directory that contains subdirectories of Fires, each subdirectory is a specific Category of Fires to keep your Fire modules organized. Fires are added to a DumpsterFire to create a chain of events and actions.
DumpsterFires/ - Directory containing your collection of DumpsterFires
igniteDumpsterFire.py - Headless script, invoked at command line with the filename of the DumpsterFire you wish to execute. Useful for igniting distributed DumpsterFires.
testFireModule.py - Utility script for unit testing the Class methods of your custom Fire modules, without the hassle of running through the entire DumpsterFire Factory process to debug. Also useful for running a single Fire to check your settings. testFireModule.py will prompt you for configuration settings were applicable.
__init__.py files - Required to make Python treat directories as containing Python packages, allows DumpsterFire toolset to find and load Fire modules.

Requirements
Python 2.7.x

Run DumpsterFire Factory
$ ./dumpsterFireFactory.py

Creating a DumpsterFire:
The menu-driven DumpsterFire Factory script guides you through each step, with context-appropriate help along the way.

DumpsterFire_4_DumpsterFireBuildHelp.png

Sample DumpsterFires
In our first example, we have a DumpsterFire that could be either a SOC drill or a Red Team distraction. The DumpsterFire first does a Google search for hacking tools. The next Fire opens Web sessions to various hacking Websites. Next, a following Fire downloads some common hacking tools. Then a port scan targets the subnetwork, followed by bruteforce login attempts against a single host via Telnet. The final Fire runs a series of Linux commands. Note that between each Fire, the creator of this DumpsterFire has inserted some time delays. This makes the flow of events appear more realistic.
DumpsterFire_5_DumpsterFire_Wayward_Employee.png

In the next example, Purple Teamers have created a DumpsterFire to help analyze and validate their sensor and alerting configurations. This DumpsterFire runs a choreographed series of port scans, each targeting different collections of ports & services, with varying probe rates as well. They've inserted a 5 minute delay between each scanning Fire to simplify isolating the traffic associated with each scanning Fire. When they run this DumpsterFire, they'll also see date-timestamps at the beginning of each Fire to help them deconflict the Fire's network activity vs. other network events.
DumpsterFire_6_DumpsterFire_Purple_Team.png

Customizing Your Dumpster Fires
DumpsterFire's modular design gives you flexibility to create any number of event-chain narratives. Fire modules that have configurable settings allow you to set target networks or system, etc. There are a few Fire modules, however, that give you immediate flexibility to greatly expand your DumpsterFire event sequences.
Without creating any new FireModule classes, you can use these existing "custom" Fire modules to leverage and extend your DumpsterFires:
You can add any number of these to your DumpsterFire, each with its own custom actions. For example, you could chain together a dozen 'custom_url.py' Fire modules to build a complete, tailored browsing narrative. You could then have various 'OSCommand/' Fire instances that execute system commands to further reinforce your desired narrative of events. The 'OSCommand/' Fires in particular give you incredible flexbility. Each individual Fire in your DumpsterFire event chain takes any shell commands that are appropriate for the host's OS:
Example: Linux/Unix (& OSX terminal)
find /home -name '*.bash_history' -exec cat {} ; ; echo "Never gonna give you up" > rickroll.txt ; wall rickroll.txt

Write Your Own Custom Fire Modules
DumpsterFire is ready to use out of the box, but it's real value is in how easily you can extend DumpsterFire's scenario toolchest by creating your own custom Fire modules. By creating and tailoring Fire modules to match your specific needs, you can quickly expand the types of DumpsterFire scenarios you can build and execute. Simply write your new Fire module and drop it into an existing directory under FireModules/ and the DumpsterFire toolset will automatically load it at runtime & make it available.
Want to keep your custom Fire modules completely separate in their own Category? Easy! Just create a new directory under FireModules/ and the DumpsterFire toolset will auto-detect and make it available as a new Category of Fires.
NOTE: Be sure your new directory has an empty file named __init__.py otherwise the Python package manager won't be able to find it, and DumpsterFire won't see it.

DumpsterFire_7_DumpsterFire_Custom_Categories.png

Your Fire module inherits from a class called FireModule. As a starting point, you can copy an existing Fire module. Be sure to change the filename and all classname references in the file to match your new Fire. (Update the Category path references in the class's constructor methods too, if needed.)
Required Class Methods:
Configure() - Prompts user for input, populates FireModule’s parameters
Description() - Return a string containing a description of the FireModule
GetParameters() - Returns a single string of Fire's parameters
SetParameters( string ) - Takes a single string & populates Fire's members
ActivateLogging( boolean ) - Sets flag for Fire to generate a log of its activities (great for review) NOTE: For initial release, logging to stdout is always on.
Ignite() - Executes Fire's actions

Utility Scripts
Testing Python classes can be annoying, especially when you want to unit test each of the class's methods, forcing you to slog through all the application's use cases to make sure each class method is executed in proper order. Bleh. So I've written and included a script that will properly invoke each method of your new FireModule-derived classes, enabling you to quickly churn-and-burn your way through debugging. You're welcome. :-) Also a great way to run a Fire by itself to test your settings, see what it does, etc.
At the command line, give the testFireModule.py script the relative filepath to your custom Fire module. The test script will call each of the required FireModule methods for you, in proper sequence (getting configuration prior to saving, etc.). The test script doesn't use exception handling, because Python only gives you useful errors (like pointing out that missing double-quote) when it crashes. Crash and burn your way to a successful custom Fire!

Дата: 2017-11-16 21:00:46

Источник: http://www.kitploit.com/2017/11/dumpsterfire-security-incidents-in-box.html



Схема функционирования HTTP-сообщений и возможные риски

В этой статье мы рассмотрим структуру HTTP-сообщений и проанализируем, что происходит за кадром при просмотре веб-страниц.

Автор: Ryan Brown

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

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

HTTP-запросы

Простой HTTP-запрос:

clip_image002.jpg
clip_image004.jpg
Рисунок 1: Элементарный HTTP-запрос

GET – HTTP-метод

/ - Путь к ресурсу

HTTP/1.1 – Версия протокола HTTP

HTTP-методы:

Протокол HTTP поддерживает несколько методов. В самой первой версии HTTP/1.0 было три метода: GET, POST и HEAD. В HTTP/1.1 появилось несколько новых методов (см. RFC 2616): OPTIONS, CONNECT, TRACE, PUT и DELETE. В RFC 5789, появившегося в 2010 году, добавился метод PATCH.

clip_image006.jpg
Рисунок 2: Перечень методов, поддерживаемых протоколом HTTP/1.1

GET используется для простого запроса ресурсов с веб-сервера. Параметры для этого метода передаются через URL.

POST используется для отсылки данных на веб-сервер через тело HTTP-запроса.

HEAD схож с методом GET, но выводит только заголовки HTTP-ответа, который возвращает сервер.

OPTIONS используется для получения списка методов, принимаемых веб-сервером, которые хранятся в заголовке ‘Allow’ в HTTP-ответе.

PUT предназначен для замены существующего или создания нового ресурса на веб-сервере.

TRACE используется при тестировании и отсылает полное сообщение, полученное веб-сервером, обратно клиенту, что позволяет увидеть конкретное содержимое, полученное веб-сервером.
CONNECT используется редко и совместно с прокси-сервером, который может динамически переключаться в режим туннеля.

PATCH схож с методом PUT. Отличие заключается в этом, что PATCH поддерживает частичную модификацию, в то время как метод PUT поддерживает только полную замену ресурса.

Примечание:

В большинстве приложений используются в основном GET и POST, поскольку HTML поддерживает только эти два метода. Если предполагается использование методов OPTIONS, PUT, DELETE, PATCH, TRACE или CONNECT, необходимо все тщательно продумать и оценить риски в отношении приложения или веб-сервера.

URL:

URL или Uniform Resource Locator (унифицированный указатель ресурсов) является подмножеством унифицированных идентификаторов ресурсов (Uniform Resource Identifiers; URI). Типичная структура URL выглядит так:

[Protocol]://[host]/[resource path]?[parameter1]&[parameter2]

По сути, это способ обозначения местонахождения сетевого ресурса и метод передачи данных целевому ресурсу.

clip_image008.jpg
Рисунок 3: Переменная HOST представляет собой сетевой адрес веб-сервера, куда клиент отсылает HTTP-запрос

clip_image010.jpg
Рисунок 4: Наиболее распространенные заголовки HTTP-запроса

User-Agent содержит информацию о браузере.

Accept определяет тип содержимого, который может принять клиент.

Accept-Encoding определяет тип кодировки, которую может принять клиент.

Content-Length определяет длину тела запроса в октетах. Это значение не имеет особой важности, но некоторые HTTP-методы (например, PUT) требуют этот заголовок. Если необходимо, в значение этого заголовка можно установить 0.
Referer содержит URL-источник запроса.

Cookie предназначен для отправки cookies на сервер для управления сессией.

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

Authorization содержит информацию, имеющую отношение к аутентификации на конкретной платформе. 

HTTP-ответы

Пример простого HTTP-ответа:

clip_image012.jpg
Рисунок 5: Элементарный HTTP-ответ

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

clip_image014.jpg
Рисунок 6: Перечень кодов статуса

Код ответа «100 Continue» редко когда-либо используется. Наиболее распространенный код «200 OK», который сигнализирует о том, что запрос корректен, ресурс существует, сервер обработал запрос и вернул ресурс в теле ответа. Код 201 означает, что ресурс, запрашиваемый в запросе, был успешно создан. Этот код обычно является результатом запроса с использованием метода PUT. Коды статуса 3xx возвращается приложениями со ссылкой на ресурс, куда нужно перенаправить клиента. Ссылка находится либо в тебе ответа, либо в заголовке «location». Коды статуса 4xx отсылаются в случае, если запрашиваемого ресурса на сервере не существует или пользователь не авторизован для получения содержимого или при возникновении ошибки в запросе, отправленном серверу. Коды статуса 5xx возвращаются в случае, когда сервере возникает ошибка, и нет возможности обработать запрос.

clip_image016.jpg   
Рисунок 7: Наиболее распространенные HTTP-заголовки ответов

Date содержит дату, когда получен запрос.

Server содержит информацию о веб-сервере (например, IIS/Apache).

X-Powered-By содержит информацию, касающуюся технологии, используемой в скриптах, и текущую версию (например, PHP или Asp.net).

Content-Length схож с аналогичным заголовком в запросе. Содержит длину тела ответа в октетах.

Set-Cookie содержит cookie, используемые клиентом при формировании запроса с целью управления сессией.

Expires содержит, время по истечению которого сервер не будет рассматривать ответ как корректный.

Cache-Control указывает клиенту, нужно ли кэшировать возвращаемые запросы.

Пример HTTP-запроса с использованием метода GET:

clip_image018.jpg
Рисунок 8: Пример использования метода GET

Как видно на рисунке выше, в первой строчке указан метод, путь к ресурсу с параметрами и используемая версия HTTP. Во второй строчке указан хост, которому посылается запрос. В третьей строке содержится информация о браузере клиента. В четвертной строчке указан тип данных, который может принимать клиент. В пятой строчке указан язык, используемый клиентом. В шестой – cookie, полученные с сервера для поддержания сессии. Седьмая строчка указывает, нужно ли закрывать сессию или оставить открытой. Последняя строчка нужна при использовании метода GET и является пустой.

Пример ответа на запрос с использованием метода GET:

clip_image020.jpg
Рисунок 9: Ответ на запрос с использованием метода GET

В ответе на запрос содержится несколько HTTP-заголовков, которые уже обсуждались ранее.

Пример использования метода POST:

clip_image022.jpg
Рисунок 10: Пример отправки информации методом POST

HTTP-запрос с использованием метода POST во многом схож с запросом с методом GET, который мы только что рассматривали. Основное отличие заключается в том, что параметры передаются не через URL, а через тело запроса. Этот метод более безопасен и пригоден для передачи конфиденциальной информации, поскольку передаваемые сведения нельзя получить из кэша на стороне клиента. Если планируется передавать параметры, имеющие отношение к аутентификации, следует использовать протокол HTTPS вместе с TLS с целью включения функции шифрования передаваемой информации. Заголовок Content-Length содержит длину тела запроса в октетах. И, наконец, заголовок Referer указывает серверу место возникновения запроса.

Пример HTTP-запроса с методом TRACE:

clip_image024.jpg
Рисунок 11: Запрос с использованием метода TRACE

Пример ответа на запрос с методом TRACE:

clip_image026.jpg
Рисунок 12: Ответ на запрос с методом TRACE

Как видно из рисунка выше, при использовании метода TRACE сервер возвращает в теле ответа все, что было отправлено в запросе. Эта функция может быть полезна в том случае, если клиенту нужно точно знать, что получено сервером. Метод TRACK выполняет ту же самую функцию, но используется при работе с сервером Microsoft IIS. Уязвимости, которые могут возникать при использовании метода TRACE, связаны с межсайтовой трассировкой (Cross-Site Tracing; XST). Этот класс брешей злоумышленник может использовать для кражи cookie или другой конфиденциальной информации (например, учетных записей), хранимых в заголовке Authorization при помощи межсайтового скриптинга (XSS).

Пример HTTP-запроса с методом PUT:

clip_image028.jpg
Рисунок 13: Создание простейшей страницы при помощи метода PUT

Метод PUT требует использования в запросе заголовка Content-Length. Значение этого заголовка особого значение не имеет и может быть установлено нулевым без каких-либо непредсказуемых последствий. Если директория, указанная в URL, уже существует на сервере, соответствующий ресурс будет полностью заменен. Если ресурса, указанного в URL, не существует, то будет создан новый ресурс (предполагается, что соответствующий метод реализован на сервере). Содержимое ресурса, который нужно создать, указывается в теле запроса. В примере выше создается простая html-страница.

Пример ответа на запрос с методом PUT:

clip_image030.jpg
Рисунок 14: Ответ с кодом об успешном создании страницы

В идеале от сервера должен прийти ответ с кодом статуса «201 Created», свидетельствующий о том, что ресурс создан. Кроме того, в HTTP-запрос можно было бы вставить заголовок «Expect: 100-continue», чтобы удостовериться, что сервер готов к обработке и не закроет сокет до того, как получит содержимое, которое вы указали в теле запроса. При использовании в запросе заголовка «Expect» в ответ может прийти один из двух кодов статуса: «100 Continue» или «417 Expectation Failed».

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

Пример атаки показан на рисунке ниже. В этом примере в тело HTTP-запроса вставляется код шелла, который, в случае принятия запроса сервером, позволяет злоумышленнику выполнять команды.

Пример HTTP-запроса с методом PUT и вставкой кода шелла:

clip_image032.jpg
Рисунок 15: Пример использования кода шелла в теле запроса

Пример HTTP-запроса с методом DELETE:

clip_image034.jpg
Рисунок 15: Запрос на удаление ресурса при помощи метода DELETE

Пример ответа на запрос с методом DELETE:

clip_image036.jpg
Рисунок 16: Ответ на запрос об успешном удалении ресурса

После успешного удаления ресурса, указанного в URL, сервер должен вернуть код статуса 200 OK.

Пример HTTP-запроса с методом OPTIONS:

clip_image038.jpg
Рисунок 17: Запрос методов, доступных на сервере, при помощи метода OPTIONS

Пример ответа на запрос с методом OPTIONS:

clip_image040.jpg
Рисунок 18: Ответ с перечнем методов, доступных на сервере

Цель метода OPTIONS – узнать, какие методы разрешены на сервере. При помощи этого метода нельзя нанести какой-либо ущерб, а только собрать нужную информацию. Важно отметить, что содержимое заголовка «Allow» в заголовке ответа часто содержит методы, разрешенные не на сервере, а на прокси-сервере в случае, если трафик проходит через туннель.

В данной статье была представлена информация относительно использования HTTP-сообщений и методов, реализованных в протоколе HTTP/1.1. Кроме того, затрагивалась информация о возможных сценариях атак против веб-приложений при помощи этих методов. Эти сведения могут помочь вам в разработке сценариев пентестов. Надеемся, что после ознакомления с этой заметкой, вы стали лучше понимать механизмы функционирования и потоков данных протокола HTTP.

Дата: 2017-11-16 20:31:00

Источник: http://www.securitylab.ru/analytics/489752.php



Firefox будет блокировать все ссылки вида data:URI

Mozilla внедряет функциональность блокировки загрузки data:URI из навигационной панели браузера Firefox в рамках противодействия злоупотреблению использования этого протокола фишинговыми сайтами.

Что такое data:URI?

Схема data:URI была разработана в 1998 году для возможности встраивания одних файлов в другие. Программисты с её помощью смогли загружать файл, представленный в виде ASCII-закодированного восьмеричного потока, в другой документ.

С того момента данная схема стала очень популярной среди веб-разработчиков и позволила им, прежде всего, встраивать текстовые файлы (CSS и JavaScript) и изображения (PNG и JPEG) в документы HTML без дополнительной загрузки каждого из них при помощи отдельного HTTP-запроса.

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

Использование злоумышленниками

Однако, в конце 2000-х годов исследователи установили, что data:URI часто используется злоумышленниками в целях фишинга и XSS-атак (межсайтовый скриптинг). Среди наиболее популярных и опасных случаев являются data:URI следующих типов: data:text/html;base64 и data:application/x-javascript;base64, которые предоставляют способ встраивания вредоносного кода HTML и JS в код вполне обычных и безопасных сайтов.

Разработчики Mozilla присоединились к коллегам из Google и Microsoft, которые уже реализовали блокировку неправомерного использования схемы data:URI в своих браузерах. Кристоф Кершбаумер, инженер Mozilla, работавший над новой функцией, сообщил:

Мы хотим заблокировать data:URI навигацию лишь верхнего уровня, которая, в основном, и используется в целях фишинга. Фактически, мы не видим реальных условий применения этого сорта навигации в обычных условиях, только лишь в качестве фишинговых атак.

Условия блокировки

В Firefox 59 инженеры Mozilla планируют развернуть ряд функций безопасности, которые предотвратят рендеринг опасных data:URI HTML, JS и SVG файлов в определённых условиях:

Безопасные условия использования

Ссылки data:URI, которые отображают изображения, форматы которых отличных от SVG, PDF-файлы, JSON и обычные текстовые файлы не будут затронуты, поскольку они не используются для фишинговых атак. Кроме того, HTML, JS и SVG файлы по-прежнему будут рендериться в следующих безопасных условиях:

Тестирование функциональности

Mozilla уже начала применять некоторые механизмы блокировки URI, начиная с Firefox 56, но официально они запланированы для всех пользователей лишь в Firefox 59. Полная версия функции блокировки URI уже активна в Firefox Nightly и версии для разработчиков, однако недоступна в недавно выпущенном браузере Firefox 57.

Для проверки урезанной функциональности блокировки в 56 или 57 версии браузера введите в панель адреса: about:config для доступа к скрытой панели настроек. После этого найдите security.data_uri.block_toplevel_data_uri_navigations и дважды щёлкните для включения функции.

data:URI

Если всё прошло успешно, то при попытке перехода по ссылке, указывающей на data:URI, ничего не произойдёт:

data:URI

Источник: Bleeping Computer

Вячеслав Шарунов

Дата: 2017-11-16 19:15:33

Источник: https://tproger.ru/news/firefox-blocks-data-uri/