Рубрика «Блог компании «Digital Security»» - 6

Я — пентестер, и так получилось, что практически на всех проектах, хотя бы отдаленно связанных с анализом инфраструктуры разработчиков, мне встречаются установленные Jenkins и TeamCity (один раз я даже видел Bamboo). Немного гугла, и я выяснил, что это все — так называемые системы непрерывной интеграции. Конечно, в какой-то момент у меня в голове стали возникать вопросы вроде: «А что это вообще за системы такие?» и «Что с ними можно сделать?», естественно, с точки зрения пентестера. Ответив на поставленные вопросы, мы поймем, какую выгоду потенциальный злоумышленник может извлечь и какой вред нанести в рамках экосистемы разработчика, используя лишь имеюущуюся в ней систему непрерывной интеграции.

Agile — это модно


Как прервать непрерывную интеграцию - 1

Думаю, что большей части читателей Хабра наверняка знакомы такие ключевые слова, как Agile, Scrum или даже Sprint. Если вдруг нет, то кратко и очень приблизительно это все можно охарактеризовать так: постоянный выпуск новых законченных (т.е. обладающих каким-то конечным набором функций) релизов приложения.
Подробнее можно почитать, например, в Википедии.
Не будем останавливаться на этом подробно, т.к. потенциальному злоумышленнику, для проведения успешной атаки, эти знания особенно и не нужны. Однако стоит заметить, что с каждым днем все больше и больше разработчиков (да большинство!) обращается в Agile-веру, и, конечно, сталкивается с необходимостью как-то управлять всеми этими бесконечными промежуточными релизами. И именно для этой цели и используются системы непрерывной интеграции.

Забегая немного вперед, нужно сказать, почему же эти системы могут заинтересовать злоумышленника (или, в нашем случае, конечно, пентестера) и почему стоит беспокоиться об их безопасности.

  • Во-первых, в силу специфики своей работы, они взаимодействуют напрямую с исходными кодами (утечка которых, во многих случаях может означать значительные убытки для компании).
  • Во-вторых — зачастую, для корректной сборки исходных кодов в конечный продукт, пользователи системы создают так называемые сборочные скрипты, которые могут быть реализованы как средствами самой системы непрерывной интеграции, так и с использованием сторонних инструментов (например, скрипты могут загружаться из репозиториев). В простейшем случае, эти скрипты представляют собой batch или bash файлы, т.е. по сути они ограничены только возможностями самой ОС, на которой исполняются. Таким образом, если злоумышленник смог модифицировать сборочный скрипт, он сможет выполнять команды ОС непосредственно на сборочном сервере.

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

Читать полностью »

Безопасность прошивок на примере подсистемы Intel Management Engine - 1

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

Встречайте – подсистема Intel Management Engine, самая загадочная составляющая архитектуры современных x86-платформ.

Читать полностью »

image

SSLv2, протокол шифрования от Netscape, вышедший в 1995 году и потерявший актуальность уже в 1996, казалось бы, в 2016 году должен быть отключен во всем ПО, использующем SSL/TLS-шифрование, особенно после уязвимостей POODLE в SSLv3, позволяющей дешифровать 1 байт за 256 запросов, и FREAK, связанной с ослабленными (экспортными) версиями шифров.
И если клиентское ПО (например, браузеры) давно не поддерживает подключения по протоколу SSLv2, и, с недавнего времени, и SSLv3, то с серверным ПО не все так однозначно.

Группа исследователей из Тель-Авивского университета, Мюнстенского университета прикладных наук, Рурского университета в Бохуме, Университета Пенсильвании, Мичиганского университета, Two Sigma, Google, проекта Hashcat и OpenSSL обнаружили уязвимость под названием DROWN — Decrypting RSA using Obsolete and Weakened eNcryption, которая позволяет дешифровать TLS-трафик клиента, если на серверной стороне не отключена поддержка протокола SSLv2 во всех серверах, оперирующих одним и тем же приватным ключом.
Согласно исследованию, 25% из миллиона самых посещаемых веб-сайтов подвержены этой уязвимости, или 22% из всех просканированных серверов, использующих сертификаты, выданные публичными центрами сертификации.

Почему это возможно?

Несмотря на то, что у большинства веб-серверов протокол SSLv2 отключен по умолчанию, и его никто не будет включать намеренно, данная атака позволяет дешифровать TLS-трафик, имея доступ к любому серверу, поддерживающему SSLv2, и использующему такой же приватный ключ, что и веб-сервер. Часто можно встретить использование одного и того же сертификата для веб-сервера и почтового сервера, а также для FTPS.

Общий вариант атаки эксплуатирует уязвимость в экспортных шифрах SSLv2, использующие 40-битные ключи RSA.Читать полностью »

Безопасность прошивок на примере промышленных коммутаторов Hirschmann и Phoenix Contact - 1

Многие современные компьютерные системы (материнские платы в ПК, смартфоны, сетевое оборудование…) работают под управлением прошивки, которая, как правило, разрабатывается под конкретное железо, может использовать весь спектр доступных аппаратных ресурсов и имеет самые высокие привилегии. Защите прошивок необходимо уделять особое внимание, иначе она будет настоящей Ахиллесовой пятой в безопасности системы.
Этому вопросу будет посвящён небольшой цикл статей, мы покажем слабую и сильную модели безопасности прошивок на реальных примерах.

Кстати, в основе этой статьи – наше исследование защищённости промышленных сетевых коммутаторов, которое было представлено мной на хакерской конференции ZeroNights 2015 (доклад «Модификация прошивок промышленных свитчей», презентация лежит здесь).

Читать полностью »

Введение

Давненько мы ничего не публиковали про SAP, и сегодня мы рассмотрим уязвимость, которая затрагивает любое SAP решение от старинного R/3 до новомодной HANA. Имя этой уязвимости – межсайтовый скриптинг (XSS). Статья эта, вопреки нашему обычному повествованию про поиск и эксплуатацию уязвимости, будет по большей части посвящена защите от данной уязвимости.

Межсайтовый скриптинг — одна из самых распространенных уязвимостей вообще, и в продуктах SAP в частности. Так, за 12 лет в SAP было обнаружено 628 XSS-уязвимостей, что составляет 22% от всех уязвимостей в SAP. Только исследователи ERPScan нашли 52 XSS-уязвимости в SAP, и то потому, что больше времени уходило на написание Advisory и бюрократические моменты, чем на непосредственный поиск уязвимостей. Более подробная информация по всем уязвимостям может быть изучена в нашем исследовании "Analysis of 3000 vulnerabilities in SAP", а мы переходим к основной части.

image

Читать полностью »

image

В нашей компании мы постоянно проводим различные исследования (список), выбирая интересную для нас тему и как итог — представляя общественности pdf с результатами.

Данная статья статья как раз из разряда таких исследований. Проводя работы по анализу защищенности мы приводим обычно очень схожие (общие для всех) советы, которым мало следует, некоторые best practices, которые или просто повышают общий уровень защищенности системы (например — применение CSP), или действительно позволяют предотвратить атаку.

Введение

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

Точки соприкосновения JavaScript и Reverse Engineering - 1

Если вы посмотрите описания вакансий на позицию Reverse Engineer, то вряд ли встретите там требование знания JavaScript. А если и встретите, то только в контексте его деобфускации на разных вредоносных страницах, обычно используемых эксплойт-паками.
И возможно ли вообще сосуществование JS (который некоторые даже называют веб-ассемблером) и мира low level с Assembler во главе?

Читать полностью »

В реализации TLS в OpenSSL и Apple TLS/SSL, исследователями из INRIA, IMDEA и Microsoft была обнаружена уязвимость, которой они дали название FREAK (Factoring attack on RSA-EXPORT Keys). Уязвимость заключается в недостаточной проверке при выполнении TLS Handshake на стороне клиента, что приводит к возможности понизить шифрование во время выполнения атаки «человек посередине» до использования 512-битных ключей RSA, которые могут быть подобраны злоумышленником в течение нескольких часов.

EXPORT Ciphersuites

Примерно в середине 20 века, в США ввели закон об ограничении экспорта стойких шифров за пределы страны. Разрешалось экспортировать только специально ослабленные версии шифров, например, с ключами 40 или 56 бит для симметричного и 512 бит для асимметричного шифрования. Серьезные ограничения действовали до конца 1992 года, а к началу 2000 большинство ограничений были сняты, хотя некоторые сохраняются и по сей день.
Современные стандарты TLS все еще позволяют использовать такие нестойкие типы шифрования, и некоторые веб-серверы (26.3% всего интернета по статистике zmap) до сих пор позволяют их использовать для установки TLS-соединения.Читать полностью »

Этой записью в блог мы начинаем цикл постов о паролях в SAP-системах: о том, как различные пароли хранятся в системе, как защищаются и передаются.
На первый взгляд все просто — хранить пароли нужно в базе данных. Конечно, в случае обычных пользователей так и есть: пароли хранятся в виде хешей в БД. Однако для служебных пользователей SAP-системы не все так просто.
Ввиду сложных архитектурных особенностей ERP-системы, разработчикам из компании SAP приходится использовать различные типы хранилищ для такой критичной информации, как пароли системных пользователей.

Как устроен ABAP Secure Storage в SAP - 1

Что ж, обсудим, как надежно реализованы эти хранилища и может ли атакующий использовать их недостатки в своих целях.
Читать полностью »

Специалисты Qualys сообщили о наличии уязвимости в gethostbyname() и gethostbyname2() в GNU
C Library (glibc), которая, как минимум в одном случае, способна привести к удаленному выполнению кода. Уязвимость позволяет перезаписать до 4 байт на 32-битных системах и до 8 байт на 64-битных системах в куче числами (0…9), точкой (.) и NULL-символом (0x00).

Уязвимость появилась в версии glibc-2.2 от 10 ноября 2000 года и была закрыта в версии 21 мая 2013 года с glibc-2.18, поэтому уязвимы только LTS-дистрибутивы Linux: Debian 7, Red Hat Enterprise Linux 6 и 7, CentOS 6 и 7, Ubuntu 12.04.

Уязвимым является код, который отвечает за получение hostname. Для перезаписи кучи, имя хоста должно удовлетворять следующим условиям:

  • Содержать в себе только цифры и точку
  • Первый символ должен быть цифрой
  • Последний символ не должен быть точкой
  • Быть достаточно длинным, чтобы переполнить буфер (>1КБ)

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js