OSWE — сертификация продвинутого уровня, идеально подходящая для пентестера и аудитора веб-систем. Это был один из самых сложных экзаменов в моей жизни: куча оставленного здоровья, из 48 часов удалось поспать часов 12, и я даже не знал, что могу так “выражаться”. Состояние было “быстрее бы сдохнуть”. Но обо всем по порядку.

Безопасность на реальных примерах всегда интересна.

Сегодня поговорим об SSRF атаке, когда можно заставить сервер делать произвольные запросы в Интернет через img тэг.



Итак, недавно занимался тестированием на проникновение одновременно на двух проектах, сразу на двух эта уязвимость и выявилась. Скриншоты взяты прямо из отчетов, потому вся лишняя информация замазана.

Описание атаки

Безопасность на реальных примерах всегда более интересна.

Как тестировщик на проникновение, люблю, когда приходят проекты, построенные на фреймворках быстрой разработки (Rapid development), подобно Ruby-on-Rails, Django, AdonisJs, Express и так далее. Они позволяют очень быстро строить систему за счет того, что бизнес модели прокидываются сразу на все уровни, включая клиентский браузер. Model (модели бизнес объектов в базе) и ViewModel (контракт взаимодействия с клиентами) такие фреймворки часто объединяют вместе, чтобы избежать лишнего перекладывания из Model во ViewModel и обратно, REST сервисы автоматом генерируются. C точки зрения разработки можно просто разработать бизнес модель на сервере, и потом использовать ее сразу на клиенте, что несомненно увеличивает скорость разработки.

Еще раз, я не утверждаю, что вышеупомянутые фреймворки плохие, или с ними что-то не то, у них есть средства и инструменты правильной защиты, просто с ними разработчики делают больше всего ошибок. Такое встречал и на одном ASP.NET MVC проекте, в котором разработчики наделали те же уязвимости, выставляя Models вместо ViewModels…

Безопасность на реальных примерах всегда более интересна.

Один раз пришел клиент с запросом на тестирование на проникновение. У него было достаточно много причин для беспокойства, среди прочих прозвучала и такая: “Несколько месяцев назад к нам пришел новый разработчик, получил доступы к исходному коду, документации, тестовому серверу, через два дня пропал и до сих пор не отвечает. Чем мне это может грозить? Доступы в лайв систему ему не давали.”

Любая система имеет свои слабые и сильные стороны. Первая часть о слабостях HTTPS вызвала неоднозначную реакцию, что «это не слабости, так было задумано». В первой части говорилось:

1. О невозможности обеспечить полную конфиденциальность и privacy пользователям (все ещё можно отслеживать и банить ресурсы, которые человек посещает)
2. О том, что сертификаты передаются по открытому каналу и содержат чаще больше информации, чем текущий ресурс (например, сертификат bing.com содержит информацию о 72 дополнительных ресурсах, включая дев, тест, бета среды)

Продолжу называть это «слабостями» дизайна. В этой статье поговорим о ещё одной слабой стороне — централизованности.

HTTPS базируется на SSL и TLS протоколах (для простоты будем называть просто SSL – хотя SSL и TLS работают на разных уровнях OSI стека). Поэтому говоря о слабости, мы будем иметь ввиду централизованность SSL протокола.

Теория

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

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

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

Иногда технически неподготовленные люди продавая IT услугу либо продукт, на вопрос «а как насчёт надёжности вашей системы?» отвечают: «У нас всё защищено по https». Если с другой стороны такой же технически неподготовленный человек, то вопрос автоматически закрывается, и все остались довольны уровнем безопасности. Сам неоднократно был свидетелем подобного разговора. Было смешно.

HTTPS активно продвигается Интернет сообществом и основная идея перевести весь Интернет к определённому году на шифрованный трафик, благо современные машины это позволяют. HTTPS — это всегда хорошо. Но нужно знать и подводные камни связанные с ним.
Задача данной статьи — показать возможность слушать HTTPS трафик пользователя (назовём его Степан), и чтобы он этого не заметил.

Мы не будет брать последние исследования и эксплоиты в области взлома HTTPS. Пойдём лучше к основам и рассмотрим давно известные и простые способы.

HTTPS — это HTTP + SSL. Http — это открытый протокол передачи данных, открытый означает, что данные передаются в открытом виде. SSL — это протокол, обеспечивающий безопасное соединение посредством шифрования. То есть, наша задача состоит именно в том, чтобы перехватить чистый трафик нашего Степана и вывести его на чистую воду, какие же ХХХ сайты он смотрит по вечерам. Но мы ведь не как наш Степан и не смотрим XXX, поэтому для примера возьмём поисковик bing, который пока ещё может работать как по https, так и по http.

Ниже на картинке пример как выглядит перехваченный трафик при помощи WireShark на один и тот же запрос в bing для HTTP и для HTTPS.

CISSP (Certified Information Security Systems Professional) относится к “золотому стандарту” в индустрии безопасности и давно входит в топы IT сертификаций.

Сложность сертификации

Изначальные требования для прохождения сертификации достаточно высоки, возможно, поэтому это многих отпугивает: минимум 5 лет подтвержденного опыта в области безопасности как минимум в 2 из 8 доменов, которые покрывает CISSP (о доменах ниже).

Экзамен действительно сложный. До этого у меня было 12 Майкрософт сертификаций, которые рядом не стояли по сложности и требованию к уровню знаний. CISSP требует достаточно широких знаний безопасности, от физической защиты активов до управления безопасностью на предприятии уровня enterprise.

Все эти сложности сказываются на качестве и ценности самой сертификации.

У нас всё ещё смотрят «сквозь пальцы» на подобные сертификаты, хотя за рубежом это часто является необходимым условием для высокой технической должности. Возможно, сервисная модель ведения бизнеса подпортила отношение к сертификации, как к постоянному росту — новые функциональные формы часто предпочтительнее нефункциональных атрибутов систем, включая безопасность.

Приветствую, хабравчане!

Некоторое время назад столкнулся с необходимостью найти достойную систему обнаружения вторжений (intrusion detection system — IDS), далее по тексту будем использовать сокращение IDS. Необходимо было мониторить сервера, на которых хостятся приложения наших клиентов. И после длительных и утомительных поисков все найденные варианты можно было разделить на два лагеря:

1. Гики для гиков: сложные для управления и понимания open source решения, которые даже не имеют вменяемого интерфейса, работать в них можно только через консоль, и без солидного опыта и знаний в сфере кибер-безопасности с ними не разберешься. Да, мы для себя могли использовать такой вариант, но отдать это клиентам (которые, в свою очередь, далеко не технические люди) мы не могли.

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

Всё это натолкнуло нас на мысль написать свою IDS, покрывающую наши нужды: простую и удобную в управлении, имеющую понятный и привлекательный интерфейс систему. Нам было необходимо отслеживать доступы к серверу, проверять наличие сторонних соединений и подозрительной активности, получать оповещения о подозрительных событиях, создавать собственные правила (группы доверенных источников, IP-адресов), и всё это для интернет-серверов. Благо, большой опыт консультирования по вопросам безопасности и свой CISSP специалист в штате позволяли это сделать.

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

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

По своей сути блокчейн схож с паттерном CQRS, в основе которого лежит event sourcing. Если максимально упростить, и там и там есть только поддержка insertов, если говорить терминами баз данных. Update и delete для сущностей не поддерживаются. И если в системах построенных по CQRS никто не мешает удалить или обновить событие из журнала, то в блокчейн это невозможно из-за целостности всего журнала.

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

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

Как давно вы проверяли надежность своего SSL? Мало просто купить SSL сертификат и его установить, нужно его и настроить.

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

Тестирование конфигурации SSL

Проблемы связанные с версиями SSL протоколов:

• SSL v2 небезопасен, устарел и не рекомендуется для использования. См. атаку DROWN по этому протоколу.
• SSL v3 небезопасен и устаревший инструмент. См. атаку POODLE.
• TLS v1.0 также является устаревшим протоколом, но на практике он все же оказывается необходим. Его основная слабость (BEAST) была смягчена в современных браузерах.
• TLS v1.1 и TLS v1.2 оба не имеют известных проблем с безопасностью, но только v1.2 предоставляет современные криптографические алгоритмы.

SSL 2.0, SSL 3.0 и TLS 1.0 настоятельно рекомендуется отключить, так как большинство стандартов безопасности их уже давно не поддерживают (например, PCI DSS 3.1).

Рекомендуемые протоколы TLS v1.1 и TLS v1.2 с актуальными алгоритмами шифрование и снятия хэшей.

Все слышали о General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679), который вступает в силу 25 мая 2018 года. Штрафы большие и придётся соответствовать. Как и любой официальный документ, он написан сухо и может трактоваться по-разному. За последние полгода провел анализ десятка различных веб-систем на соответствие GDPR, и везде встречались одни и те же проблемы. В связи с этим цель этой статьи не разъяснить, что такое GDPR (об этом уже много написано), а дать практические советы техническим людям, что необходимо сделать в вашей системе, чтобы она соответствовала GDPR.

Пару интересных моментов по регламенту:

• Если есть хоть один клиент из Европы, чьи персональные данные вы храните, вы автоматически попадаете под GDPR
• Регламент базируется на трёх основных идеях: защита персональных данных, защита прав и свобод людей в защите их данных, ограничение перемещения персональных данных в рамках Евросоюза (Art. 1 GDPR)
• UK всё ещё в EU, поэтому подпадает под действие GDPR, после Brexit-а GDPR будет заменён на Data Protection Bill, который по своей сути очень схож с GDPR (https://ico.org.uk/for-organisations/data-protection-bill/)
• Серьезно ограничивается трансфер данных в третьи страны. Европейская комиссия определяет, в какие “третьи” страны или в какие сектора или организации в этих странах разрешён трансфер персональных данных Art. 45 GDPR. Вот список разрешённых стран.