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

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




Отследить местоположение пользователя с помощью рекламы можно всего за $1 тыс.

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

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

Ученые использовали 10 Android-смартфонов модели Motorola Moto G, созданный ими рекламный баннер и целевую страницу, на которую попадал пользователь после перехода по объявлению. Затем они потратили порядка $1 тыс. на размещение заказов в автоматизированной системе покупки (Demand Side Platform, DSP) наподобие Facebook, Google AdWords и MediaMath, позволяющей заказчикам указывать определенные критерии, например, где появится их реклама, для каких уникальных идентификаторов телефонов и в каких приложениях. Исследователи не указали, какую именно DSP они использовали, заявив, что все подобные рекламные системы работают по схожему принципу.

С помощью DSP они указали географическую сетку рекламных объявлений в Сиэтле. В эксперименте было задействовано популярное приложения для бесплатного совершения звонков и обмена сообщениями Talkatone. Каждый раз, когда Talkatone открывалось на целевом телефоне в пределах указанного исследователями диапазона, приложение отображало рекламное объявление, за которое исследователи платили 2 цента. Они получали уведомление от DSP о том, где, когда и на каком телефоне был показан рекламный баннер. С помощью данного метода они смогли следить за местоположением тестовых телефонов в диапазоне около 8 метров, если пользователь оставлял приложение открытым в одном локации в течение примерно 4 минут или открывал его дважды. Исследователи зафиксировали всего лишь 6-минутную задержку в отчетах системы в режиме реального времени о местоположении устройства. Эксперимент продолжался в течение 7 дней, за это время исследователи смогли легко определить домашний и рабочий адрес пользователя.

Данный метод отслеживания имеет несколько ограничений. В частности, на телефоне человека, за которым ведется наблюдение, должно быть открыто определенное приложение. Также для отслеживания конкретного телефона рекламодатель должен знать уникальный MAID (идентификатор мобильной рекламы) устройства.

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

Дата: 2017-10-20 06:08:00

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



Google заплатит за уязвимости в приложениях других разработчиков

Техногигант запустил программу выплаты вознаграждений за сообщения об уязвимостях в популярных Android-приложениях.

Google запустила программу выплаты вознаграждений исследователям, обнаружившим уязвимости в популярных Android-приложениях из Play Store. Программа Play Security Reward Program работает через платформу HackerOne и не ограничивается лишь приложениями от Google. Компания сама намерена платить за уязвимости, обнаруженные исследователями в продуктах других разработчиков. Оплачиваться будут только сообщения об уязвимостях в популярных программах. Максимальная сумма вознаграждения – $1 тыс.

Программа была запущена на HackerOne в четверг, 19 октября. В настоящее время исследователям предлагается взломать 13 приложений от Alibaba, Dropbox, Dulingo, Headspace, Line, Mail.ru, Snapchat и Tinder. Сейчас количество разработчиков ограничено, однако позднее Google намерена расширить список.

Информация об обнаруженных уязвимостях будет передаваться разработчикам. Google также будет сканировать все приложения в Play Store на наличие аналогичной проблемы. В случае обнаружения уязвимости в других продуктах, компания сообщит о ней производителям бесплатно.

Оплачиваться будут только уязвимости, позволяющие удаленно выполнить код. Для участия в программе исследователь обязан представить PoC-эксплоит, работающий на Android 4.4 и более поздних версиях. Обход песочницы на уровне ОС не является обязательным условием. Уязвимости, эксплуатация которых предполагает согласование программ (атака app collusion), для участия в программе приниматься не будут.

Дата: 2017-10-20 05:39:37

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



Опубликован скрипт для тестирования продуктов на уязвимость к атаке KRACK

Инструмент разработан обнаружившим уязвимость исследователем Мэти Ванхофом.

Исследователь безопасности Мэти Ванхов (Mathy Vanhoef) из Левенского университета в Бельгии представил инструмент для проверки продуктов на наличие уязвимости к атаке KRACK. Linux-скрипт  опубликован в репозитории исследователя на GitHub.

Напомним, ранее на этой неделе Ванхов сообщил об уязвимостях в протоколе WPA2, ставящей под угрозу практически все существующие на данный момент сети Wi-Fi. С ее помощью злоумышленник может осуществить атаку реинсталяции ключей (Key Reinstallation Attack, KRACK) и получить доступ к конфиденциальным данным.

Представленный Ванхофом скрипт не предназначен для осуществления атак. Для того чтобы с его помощью проверить, уязвима или нет точка доступа Wi-Fi к атаке KRACK, необходимо наличие учетной записи пользователя. Перед запуском скрипта нужно сначала отключить Wi-Fi, выполнить sudo rfkill, а затем снова включить Wi-Fi. Более подробная информация опубликована на GitHub в инструкциях по использованию инструмента.

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

Дата: 2017-10-20 04:42:11

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



Уязвимости WPA2 представляют угрозу для промышленных систем

Проблема безопасности WPA2 затрагивает сетевые устройства, смартфоны и планшеты, используемые для удаленного доступа к АСУ ТП.

В начале текущей недели стало известно об опасных уязвимостях в реализациях протокола WPA2, позволяющих обойти защиту и перехватить передаваемый Wi-Fi трафик. Как полагают исследователи «Лаборатории Касперского», атака, получившая название KRACK (Key Reinstallation Attack), может также представлять угрозу для систем промышленной автоматизации. К примеру, существует ряд ПЛК (программируемый логический контроллер), применяющих технологию Wi-Fi для беспроводной настройки и управления. Но в основном проблема безопасности WPA2 затрагивает сетевые устройства, смартфоны и планшеты, используемые инженерами и операторами для удаленного доступа к АСУ ТП.

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

Wi-Fi используется на промышленных объектах, в том числе на складах (включая порты и сортировочные терминалы), в логистике и при автоматизации производства (особенно в медицинской и пищевой промышленности), в том числе для сбора данных в рамках технического и коммерческого учета. Несанкционированный доступ к такого рода информации, полученный атакующими после расшифровки Wi-Fi трафика, может привести к серьезным последствиям, вплоть до временной остановки процесса транспортировки грузов и потери продукции.

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

Ряд производителей уже выпустили патчи, устраняющие данные уязвимости. До выхода и установки исправлений безопасности при передаче данных по Wi-Fi специалисты рекомендуют использовать шифрование, не связанное с беспроводной передачей данных, например, SSL (SSH, VPN и пр.), которое обеспечит защиту информации даже в случае компрометации Wi-Fi.

 

Дата: 2017-10-20 04:12:43

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



Создание USB-песочницы на базе компьютера USB Armory

USB Armory представляет собой небольшой компьютер с процессором ARM A8 800 МГц и оперативной памятью 512 Мб на базе USB-корпуса.

Автор: Pedro Vilaca

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


Рисунок 1: Песочница для анализа USB-устройств на базе компьютера USB Armory

USB Armory представляет собой небольшой компьютер с процессором ARM A8 800 МГц и оперативной памятью 512 Мб на базе USB-корпуса. Это устройство достаточно функционально для реализации различных интересных проектов. Одна из наиболее интересных функций – безопасная загрузка, которая называется High Assurance Boot (загрузка в высоким уровнем защиты) и позволяет защитить целостность нашей USB-песочницы. Кстати, недавно появилась заметка о безопасности, касаемо этой функции (хотя во время сборки я не предполагал, что в загрузчике есть какие-либо уязвимости). Песочница имеет приемлемый уровень аппаратной целостности, поскольку мы можем добавить свои PKI-ключи в безопасный загрузчик и поменять карту microSD на ту, которая будет использоваться во время анализа. У вредоноса мало способов нарушить целостность аппаратной части и сделать устройство непригодным для использования с точки зрения аналитика (имеется ввиду, постоянный руткит, который сможет постоянно вредить нашему анализу). USB Armory можно заказать на сайте Inverse Path. Кроме того, вам потребуется хост-адаптер, без которого мы не сможем реализовать этот проект.


Рисунок 2: Хост-адаптер

Компьютер может работать в двух режимах: host и non-host. Режим non-host используется по умолчанию и позволяет подсоединить устройство к USB-порту. После подключения песочница доступна по определенному IP-адресу (эта функция работает на базе эмуляции CDC Ethernet). По сути, в этом режиме один компьютер подключен к другому компьютеру. Подобная конфигурация используется для хранения конфиденциальных данных, в качестве аппаратного модуля безопасности (HSM), секретного мессенджера, TOR-роутера, менеджера паролей, безопасного кошелька Bitcoin и везде, где важная аппаратная целостность и надежность. В этой статье приведены другие примеры применений.

Дополнительным преимуществом является небольшой размер, и вы всегда можете носить устройство с собой.

В нашем проекте будет использоваться режим host, когда USB-песочница работает как отдельный компьютер, к которому, в случае наличия Linux-драйверов, можно подключить другие устройства: клавиатуру, монитор, электронный ключ и т. д.

В качестве одного из первых проектов я делал WiFi хот-спот / фаервол, используемый в путешествиях. Идея заключалась в том, что один WiFi-интерфейс подключается к публичной сети, а другой Ethernet- или WiFi-разъем к одному из моих устройств. Таким образом, мы изолируем наше устройство, и в то же время можем использовать публичную сеть. После подключения устройства к аккумулятору получаем собственную точку доступа. Ключевое различие заключается в том, что мы полностью контролируем это точку доступа и хорошо защищены от потенциальных вредоносов и уязвимостей, которым подвержены данные виды устройств (например, ни одна точка доступа не имеет безопасного загрузчика). Кроме того, можно добавить TOR-маршрутизацию и другие полезные функции (например, DNS-туннелинг для обхода сетей в аэропортах и так далее).

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

Этот проект имеет следующие требования:

Аппаратные требования:

Программные требования:

Общая схема установки выглядит так:

Рисунок 3: Общая схема установки

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

USB Armory подключается к одному из концов хост-адаптера, а USB-хаб к другому концу. Остальные USB-устройства подключаются к USB-хабу. Адаптер USB Ethernet можно подключить к сети, куда мы хотим скопировать данные. Чтобы повысить уровень безопасности, можно установить фаервол между сетью с USB armory и сетью, к которой мы хотим получить доступ. Далее блокируем все, кроме протокола SSH (теперь потребуется особо изощренный вредонос, чтобы обойти наш фаервол).

Существует несколько установочных образов, предварительно собранных компанией Inverse Path, и другие Linux-дистрибутивы, которые по умолчанию работают в режиме non-host. Чтобы активировать режим host, ознакомьтесь с этим документом.

Я не использовал заранее собранные образы, поскольку на тот момент в Linux-ядре не поддержки адаптера USB Ethernet, который я купил (хотя драйвера от производителя были доступны). Кроме того, сборка собственного образа позволила мне добавить дополнительные программы. Недавно компания Inverse Path выложила в общий доступ Makefile для образа на базе дистрибутива Debian (теперь не нужно копировать и вставлять команды как раньше).
Я создал форк Armory Sandbox, где добавлены дополнительные пакеты, используемые при анализе, а также конфигурация Linux-ядра, которая содержит все необходимые драйвера (для адаптера USB Ethernet и некоторый файловых систем, например, HFS+). Нам нужна поддержка всех файловых систем, которые могут встретиться на анализируемых USB-устройствах. Если у вас есть особые требования, нужно сгенерировать новый конфигурационный файл ядра и обновить уже существующий. Стандартный конфигурационный файл, используемый при создании песочницы, находится в папке kernel_conf/armorysandbox_linux-4.9.config. Конфигурация ядра обновляется следующим образом:

KBUILD_BUILD_USER=usbarmory KBUILD_BUILD_HOST=usbarmory ARCH=arm CROSS_COMPILE=arm-none-eabi- make menuconfig

Сохраните конфигурацию и скопируйте поверх старой (или обновите старый файл напрямую). Если вы не сделаете так, как показано выше, конфигурационный файл будет собран для хоста (в нашем случае для архитектуры x86), а наш целевой компьютер работает на архитектуре ARM. Вы можете использовать и другие опции при создании конфигурации, если умеете работать с неграфическим режимом.
Перед сборкой образа необходимо установить некоторые программы на хосте, а конкретно – кросс-компилятор для архитектуры ARM и программы, необходимые для создания корневой файловой системы.

sudo apt-get install bc binfmt-support bzip2 gcc gcc-arm-none-eabi git gnupg make parted qemu-user-static wget xz-utils zip sudo debootstrap

Makefile проверяет сигнатуры ядра и загрузчика U-Boot, и мы должны импортировать соответствующие GPG-ключи:

gpg --keyserver hkp://keys.gnupg.net --recv-keys 38DBBDC86092693E
gpg --keyserver hkp://keys.gnupg.net --recv-keys 87F9F635D31D7652

Теперь мы можем компилировать код для архитектуры ARM.
Перед сборкой образа для песочницы клонируем репозитарий на хост-машину:

git clone https://github.com/gdbinit/armorysandbox

В Makefile в переменную SSH_KEY добавляем ssh-ключ.

Вы можете поменять зеркало для Debian, используемое по умолчанию, на то, которое работает быстрее конкретно в вашем случае. Нужно отредактировать переменную DEBIAN_MIRROR. Кроме того, вы можете отредактировать переменную IMAGE_SIZE, которая содержит стандартный размер образа (3500 Мб). Этот размер предполагает, что будет использоваться карта microSD размером 4 Гб. Если размер карты больше, мы можем изменить размер раздела позже (см. FAQ). Если вы не хотите возиться с изменением размера раздела, то можете изменить значение переменной IMAGE_SIZE.

Учетная запись, используемая по умолчанию, - usbarmory (пароль тот же).  Чтобы изменить стандартный пароль, необходимо отредактировать переменную CHANGEME в файле Makefile.

Следующий шаг – сборка образа, которая делается в четыре шага:

Если все шаги завершатся успешно, появится файл armorysandbox-debian_jessie-base_image-YYYYMMDD.raw, который нужно записать на карту microSD:
Проверка целевой системы из терминала при помощи команды dmesg (Linux):

sudo dd if=armorysandbox-debian_jessie-base_image-YYYYMMDD.raw of=/dev/sdX bs=1M conv=fsync

Проверка целевой системы из терминала при помощи команды diskutil list (Mac OS X):

sudo dd if=armorysandbox-debian_jessie-base_image-YYYYMMDD.raw of=/dev/rdiskN bs=1m

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

После того как команда dd завершит запись образа, вы можете вставить карту microSD в USB armory. Далее включите USB armory, подсоедините серийную консоль (схема пинов доступна здесь) и проверьте, что все загрузилось корректно.

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

Mac OS X:

sudo ifconfig en0 alias 10.1.0.2 255.255.255.0

Если эта сеть для вас не подходит, отредактируйте Makefile перед сборкой ядра, или подключитесь через серийную консоль и измените файл /etc/network/interfaces.
Если вы хотите включить безопасную загрузку, ознакомьтесь с документацией. Имейте ввиду, что эта функция на данный момент не настолько ценна из-за упомянутой ранее уязвимости, однако в некоторых случаях (в том числе и в нашем) может оказаться полезной. По крайней мере до тех пор, пока не будут обнародованы полные детали уязвимости. Проблема в основном касается устройств, оставленных без присмотра, и физического проникновения. Однако в отсутствии подробностей мы не можем оценить, смогут ли некоторые виде вредоносов/эксплоитов обойти защитную загрузку, скомпрометировать нашу установку и/или испортить результаты анализа. Однако главная причина отсутствия безопасной загрузки в нашем проекте в том, что эта функция предполагает постоянные и необратимые действия.

Чтобы добавить пакеты нужно отредактировать файл Makefile, а конкретно строку с командой qemu-debootstrap. У меня были некоторые проблемы с пакетами, связанными с python 2.7 minimal. Относительно этой темы есть несколько отчетов об ошибках, и окончательного решения пока нет. Если вам нужны пакеты, у которых есть проблемы и из-за которых возникают ошибки при сборке образа, вы всегда можете выполнить установку позже при помощи apt-get и dpkg(загрузить вручную или подключиться к интернету).

Когда песочница завершит загрузку, вы можете подключиться через серийную консоль или SSH, подключить любое поддерживаемое устройство, проанализировать файловую систему или сделать образ для последующего анализа на другой машине. Если вы придерживаетесь строгих правил безопасности, после завершения анализа вы можете избавиться от карты microSD (или продать на EBay). Более щадящий вариант: просто стереть всю информацию и записать новый образ. В последнем случае возникает вопрос о методах стирания: использование собственных методов стирания или подключение отдельного устройства. При втором методе нужно быть осторожным, поскольку сторонние устройства могут нанести вред карте microSD.

Этот проект не первый, где делается попытка создании изолированной системы для анализа USB-носителей. Например, ранее уже было создано устройство CIRCLean USB Sanitizer на базе системы Raspberry Pi. Проблема этого решения заключается в том, что это устройство пытается автоматически конвертировать недостоверные документы в другой формата и, что более важно для меня, не разделяет носители. То же самое «изолированное» устройство работает с плохим и хорошим USB-носителем. В такой архитектуре безопасное разделение отсутствует априори. Я предпочитаю решения, когда доступ осуществляется через сеть, поскольку мы можем добавить фаервол между изолированным подключаемым устройством. Кроме того, у меня нет желания добавлять автоматическое преобразование информации. Меня интересует только изоляция среды. Конечно, проект CIRCLean можно доработать, чтобы было соответствие вышеупомянутым требованиям. По умолчанию в Raspberry Pi отсутствует безопасная загрузка (хотя при помощи дополнений можно добавить эту функцию). И безопасная загрузка была большим плюсом USB armory по крайней мере до тех пор, пока не были найдены уязвимости (моя первоначальная сборка была сделана перед обнародованием этих брешей).

USB armory – очень интересная платформа и при наличии творческой искры можно реализовать новые и не менее полезные проекты. Рекомендую вам купить и ознакомиться с этим устройством. 

Дата: 2017-10-20 04:00:00

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



TrickBot подался в спамеры

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

После активации испытуемый образец TrickBot запустил несколько процессов svchost.exe — как оказалось, их число может варьироваться от 4 до 7. Назначение этих svchost, как удалось установить, различно: один используется для поиска и получения цифровых сертификатов, другой содержит строки с адресами 127 банковских сервисов — видимо, целей троянца, третий собирает данные из Outlook\Profiles (имя пользователя, пароль, серверы, порты), четвертый просматривает историю веб-серфинга в поисках сохраненных идентификаторов, и т. д.

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

Темы исходящих спам-сообщений были разными, как и URL, приведенные в теле этих писем. Как оказалось, все ссылки спамеров указывали на php-редиректы в разных доменах, перенаправляющие на один и тот же сайт в зоне .su — интернет-аптеку, торгующую контрафактными лекарственными средствами.

Входящий email-трафик был более внушительным; на IP-адрес UAB шел поток разных по тематике рекламных сообщений, отправляемых, судя по строке From:, из двух десятков доменов. Среди них мелькали такие известные имена, как Walmart, AOL, Facebook, Twitter и Apple. Использование прокси-серверов — давний спамерский трюк, помогающий скрывать источники рассылок от обнаружения.

Университетские исследователи также убедились, что TrickBot регистрируется на почтовых серверах с помощью краденых учетных данных. Список этих идентификаторов в незашифрованном виде, загруженный на ботнет, был выявлен с помощью анализатора Network Miner.

Новая находка UAB подтверждает выводы других исследователей банкера, появившегося год назад: этот троянец постоянно развивается, совершенствуя свой арсенал и обретая новые функции.

Дата: 2017-10-20 03:35:11

Источник: https://threatpost.ru/trickbot_podalsja_v_spamery/22881/



Сколько инцидентов ИБ должен обрабатывать SOC? #socforum

На почти любых мероприятиях по SOC, и небольших, как круглый стол, который я модерировал на InfoSecurity Russia, и крупных, как SOC Forum, всегда возникают вопросы по тем или иным количественным характеристикам SOC. Сколько людей нужно в SOC? Сколько стоит строительство SOC? Сколько событий безопасности обрабатывает SOC? Сколько инцидентов ИБ попадает в SOC? И т.п. Надо сразу сказать, что эти вопросы НЕВЕРНЫ и правильного ответа на них не существует. Точнее все ответы будут правильными, так они зависят от кучи параметров - масштаба организации, покрываемой SOC области, определения инцидента и т.п. Но так как вопросы все равно возникают и будут возникать (особенно у тех, кто только подступается к теме SOC), я попробовал найти хоть какие-нибудь численные значения, на которые можно ориентироваться.

Итак:

  • Внутренняя служба реагирования на инциденты в Cisco обрабатывает около 2000 инцидентов в квартал. При этом угроз мы видим около 2.5 миллиардов, а число событий безопасности и вовсе измеряется десятками триллионов.
  • Наш внешний SOC (хотя аутсорсинговые центры мониторинга и реагирования на инциденты вообще сложно оценивать - очень уж разное у них количество заказчиков может быть) при около 200 миллиардах поступаемых событий "ужимает" их в 7 миллионов угроз, которые транслируются в 7 тысяч кейсов для наших аналитиков. Есть только цифры по двум из заказчиков, которые отдали нам аутсорсинг свою безопасность.
Количественные показатели по заказчику-банку
Количественные показатели по заказчику из промышленности
  • Австралийский центр кибербезопасности зафиксировал с 1-го января 2015 по 30 июня 2016 года серьезных 1095 инцидентов на государственные системы, то есть примерно (если считать, что распределение равномерное) по 60 инцидентов в месяц. Австралийский же CERT за год отработали 14804 инцидентов.
  • У британского центра кибербезопасности схожие цифры - 1131 инцидент в год (из них 590 серьезных).
  • Голландский центр кибербезопасности в год фиксирует около 600 инцидентов.
  • Центр киберзащиты HPE CDC, мониторящий и сеть HPE и сеть ее заказчиков, детектирует ежедневно около 5 миллионов атак и 2,5 миллиардов событий безопасности. Число инцидентов, которые обрабатываются аналитиками CDC, я не нашел. Предвосхищая вопрос, почему порядок отслеживаемых событий у Cisco и HPE отличается на порядок, отвечу, что HPE CDC мониторит только периметр (это только первая стадия трехэтапной стратегии развития HPE CDC).
  • У Solar Security средний поток событий безопасности в первом полугодим 2017-го года составил чуть больше 6 миллиардов в сутки, а событий с подозрением на инцидент было обнаружено 172 тысячи, то есть около 955 в сутки. 
  • Отечественной компанией "Перспективный мониторинг" за первый квартал 2017-го года было зафиксировано всего 137 миллионов событий безопасности, в которых было обнаружено 98 инцидентов ИБ.
  • На российские организации по словам секретаря Совета Безопасности в прошлом году было осуществлено несколько десятков миллионов атак.

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

  1. Число инцидентов, которые обрабатывает SOC в год, измеряется несколькими сотнями в случае, если мы имеем дело с государственным центром мониторинга, и несколькими тысячами, если мы имеем дело с корпоративным SOC мультинациональной компании, офисы которой разбросаны по всему миру. При этом это число врядли превысит 7-8 тысяч. Поэтому у меня есть вопросы по данным Solar Security, которые за год около 350 тысяч инцидентов фиксирует.
  2. Государственные центры ИБ в первую очередь собирают данные об инцидентах, не занимаясь их мониторингом в реальном времени.
  3. Многие SOCи (что корпоративные, что аутсорсинговые) преимущественно ориентируются на мониторинг периметра, "забывая" или не имея возможности следить за внутренней сетью предприятия.
ЗЫ. Про особенности построения государственных центров мониторинга ИБ буду рассказывать 27 октября в рамках Kaz'Hack'Stan в Алматы.

Дата: 2017-10-20 02:16:01

Источник: http://lukatsky.blogspot.com/2017/10/soc-socforum.html



Man-In-The-Middle Attack Against Modbus TCP Illustrated with Wireshark

Though attacks on the industrial control system (ICS) and their protocols are not a new occurrence, recent years have highlighted a growing trend in such attacks. To make matters worse, cyber defenders have also dealt with a slow migration to more secure ICS protocols due to costs associated with equipment downtime. With the increase in attacks and the slow migration to more secure ICS protocols, it is crucial for cyber defenders to be able to quickly set up labs to mimic and observe how potential attacks on the ICS network function so that necessary defenses and detection mechanisms can be put in place. This paper lays out how to setup a lab with multiple virtual machines and ICS software that can observe a Master workstation controlling a PLC. First, Wireshark will be used to illustrate and compare normal Modbus TCP communications between the Master and PLC workstations. Wireshark will then be used to demonstrate and compare a MITM attack with an Ettercap filter that manipulates the Modbus TCP communications against both workstations.

Дата: 2017-10-20 00:00:00

Источник: https://www.sans.org/reading-room/whitepapers/ICS/man-in-the-middle-attack-modbus-tcp-illustrated-wireshark-38095



Новая эра технологических продуктов

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


Со времен Сноудена, робких порывов РФ к импортозамещению, шквала различных обвинений в недокументированных возможностях, сделанных "по ошибке", которой успешно пользовались госхакеры и все остальные, или умышленно, а также загадочных публикаций и событий, становится очевидным тренд, подрывающий глобализацию.
В обществе постепенно культивируется мнение о тотальной слежке, и через какие-нибудь 10 лет продать высокотехнологичное СЗИ в виде "коробки" в другое, заботящееся о национальной безопасности государство, будет крайне сложно.
Описанное явление - обычная трансформация взглядов потребителей, происходящая не первый раз в истории, вызванная, в нашем случае - изменениями модели угроз и нарушителя (что важно для ИБ-продуктов, хотя и звучит как-то академично\бумажно), конъюнктурой рынка, и пр. проявлениями культурно-цивилизационной эволюции. Изменение спроса требует изменения предложения, - подумаем что можно предложить...

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

Далеко не каждая компания может позволить себе исследования, ибо это требует инвестиций прямо сейчас, а окупаемость придет только потом, да и то с вероятностью. Более того, поскольку детектирующая атаки логика является весьма скоропортящимся товаром, исследования внутри продукта ИБ имеют ярко выраженный операционный характер с уровнем качества сервиса, напрямую влияющим на ценность этого исследования. В качестве ремарки, хочется отметить, что системные операционные исследования имеют мало общего с ad-hoc ресерчами, возможно, даже выстрелевшими в какие-либо громкие публикации, так как приоритет operations-исследований - неизменно высокое качество детекта во времении, а не "вау-эффект" от ad-hoc.
А вот написать код, продуктивизирующий исследования - радикально проще.
Учитывая, что недоверие и закладки относятся именно к конечному продукту, а не к исследованиям внутри него, логичным изменением предложения является смещение фокуса с "коробок" на технологии и запчасти. Причем продажи технологий и запчастей с сопутствующим операционным ресерчем (чтобы запчасти продолжали оставаться эффективными) при правильной организации может оказаться еще и более выгодной - как бонус к уходу от возможных претензий в недокументированных возможностях.
Идея совсем не нова. Все то же мы наблюдаем с российским автопромом, когда иномарки ввозят в страну по запчастям и, будучи собранной на территории РФ, иномарка чудесным образом превращается в отечественный автомобиль.

В целом, понятно, что надо делать, но все-таки, позволю в последнем абзаце явно написать алгоритм.

  1. Модифицировать стратегию, отдав больше внимания исследованиям, технологиям и запчастям-компонентам, которые можно удобно\дешево встраивать в другие продукты и\или разрабатывать вокруг них необходимую обвязку.
  2. Искать и входить в партнерство с локальными производителями программных продуктов (== "сборочных конвейеров"), которые смогут из компонент п.1 сделать локальную сборку и обязательно протащить ее через все возможные местные сертификации.
  3. Находить локальных производителей и строить им "производственные мощности" и "сборочные конвейеры", на которых они уже от своего имени смогут делать  продукты и сервисы, удовлетворяющие всевозможным требованиям и условиям.
  4. Не расслабляться, помните, что как любая палка имеет, как минимум, два конца, так и любое изменение ситуации можно с одинаковым успехом трансформировать как в убыток, так и в выгоду, и наша менеджерская задача здесь - искать и находить тот правильный ответ обстоятельствам, идти "в ногу" с культурно-цивилизационными изменениями, постоянно эволюционируя.

Дата: 2017-10-19 22:49:00

Источник: http://reply-to-all.blogspot.com/2017/10/blog-post_20.html



BaRMIe - Java RMI Enumeration And Attack Tool

BaRMIe is a tool for enumerating and attacking Java RMI (Remote Method Invocation) services.

RMI services often expose dangerous functionality without adequate security controls, however RMI services tend to pass under the radar during security assessments due to the lack of effective testing tools. In 2008 Adam Boulton spoke at AppSec USA (YouTube) and released some RMI attack tools which disappeared soon after, however even with those tools a successful zero-knowledge attack relies on a significant brute force attack (~64-bits/9 quintillion possibilities) being performed over the network.
The goal of BaRMIe is to enable security professionals to identify, attack, and secure insecure RMI services. Using partial RMI interfaces from existing software, BaRMIe can interact directly with those services without first brute forcing 64-bits over the network.

Disclaimer

BaRMIe was written to aid security professionals in identifying insecure RMI services on systems which the user has prior permission to attack. Unauthorised access to computer systems is illegal and BaRMIe must be used in accordance with all relevant laws. Failure to do so could lead to you being prosecuted. The developers of BaRMIe assume no liability and are not responsible for any misuse or damage caused by this program.

Usage

Use of BaRMIe is straightforward. Run BaRMIe with no parameters for usage information.

$ java -jar BaRMIe.jar
  ▄▄▄▄    ▄▄▄       ██▀███   ███▄ ▄███▓ ██▓▓█████
 ▓█████▄ ▒████▄    ▓██ ▒ ██▒▓██▒▀█▀ ██▒▓██▒▓█   ▀
 ▒██▒ ▄██▒██  ▀█▄  ▓██ ░▄█ ▒▓██    ▓██░▒██▒▒███
 ▒██░█▀  ░██▄▄▄▄██ ▒██▀▀█▄  ▒██    ▒██ ░██░▒▓█  ▄
 ░▓█  ▀█▓ ▓█   ▓██▒░██▓ ▒██▒▒██▒   ░██▒░██░░▒████▒
 ░▒▓███▀▒ ▒▒   ▓▒█░░ ▒▓ ░▒▓░░ ▒░   ░  ░░▓  ░░ ▒░ ░
 ▒░▒   ░   ▒   ▒▒ ░  ░▒ ░ ▒░░  ░      ░ ▒ ░ ░ ░  ░
  ░    ░   ░   ▒     ░░   ░ ░      ░    ▒ ░   ░
  ░            ░  ░   ░            ░    ░     ░  ░
       ░                                     v1.0
             Java RMI enumeration tool.
               Written by Nicky Bloor (@NickstaDB)

Warning: BaRMIe was written to aid security professionals in identifying the
         insecure use of RMI services on systems which the user has prior
         permission to attack. BaRMIe must be used in accordance with all
         relevant laws. Failure to do so could lead to your prosecution.
         The developers assume no liability and are not responsible for any
         misuse or damage caused by this program.

Usage:
  BaRMIe -enum [options] [host] [port]
    Enumerate RMI services on the given endpoint(s).
    Note: if -enum is not specified, this is the default mode.
  BaRMIe -attack [options] [host] [port]
    Enumerate and attack the given target(s).
Options:
  --threads  The number of threads to use for enumeration (default 10).
  --timeout  The timeout for blocking socket operations (default 5,000ms).
  --targets  A file containing targets to scan.
             The file should contain a single host or space-separated
             host and port pair per line.
             Alternatively, all nmap output formats are supported, BaRMIe will
             parse nmap output for port 1099, 'rmiregistry', or 'Java RMI'
             services to target.
             Note: [host] [port] not supported when --targets is used.
Reliability:
    A +/- system is used to indicate attack reliability as follows:
      [+  ]: Indicates an application-specific attack
      [-  ]: Indicates a JRE attack
      [ + ]: Attack insecure methods (such as 'writeFile' without auth)
      [ - ]: Attack Java deserialization (i.e. Object parameters)
      [  +]: Does not require non-default dependencies
      [  -]: Non-default dependencies are required
Enumeration mode (-enum) extracts details of objects that are exposed through an RMI registry service and lists any known attacks that affect the endpoint.
Attack mode (-attack) first enumerates the given targets, then provides a menu system for launching known attacks against RMI services.
A single target can be specified on the command line. Alternatively BaRMIe can extract targets from a simple text file or nmap output.

No Vulnerable Targets Identified?
Great! This is your opportunity to help improve BaRMIe! BaRMIe relies on some knowledge of the classes exposed over RMI so contributions will go a long way in improving BaRMIe and the security of RMI services.
If you have access to JAR files or source code for the target application then producing an attack is as simple as compiling code against the relevant JAR files. Retrieve the relevant remote object using the LocateRegistry and Registry classes and call the desired methods. Alternatively look for remote methods that accept arbitrary objects or otherwise non-primitive parameters as these can be used to deliver deserialization payloads. More documentation on attacking RMI and producing attacks for BaRMIe will be made available in the near future.
Alternatively, get in touch, and provide as much detail as possible including BaRMIe -enum output and ideally the relevant JAR files.

Attack Types
BaRMIe is capable of performing three types of attacks against RMI services. A brief description of each follows. Further technical details will be published in the near future at https://nickbloor.co.uk/. In addition to this, I presented the results of my research at 44CON 2017 and the slides can be found here: BaRMIe - Poking Java's Back Door.

1. Attacking Insecure Methods
The first and most straightforward method of attacking insecure RMI services is to simply call insecure remote methods. Often dangerous functionality is exposed over RMI which can be triggered by simply retrieving the remote object reference and calling the dangerous method. The following code is an example of this:

//Get a reference to the remote RMI registry service
Registry reg = LocateRegistry.getRegistry(targetHost, targetPort);

//Get a reference to the target RMI object
Foo bar = (Foo)reg.lookup(objectName);

//Call the remote executeCommand() method
bar.executeCommand(cmd);

2. Deserialization via Object-type Paraeters
Some RMI services do not expose dangerous functionality, or they implement security controls such as authentication and session management. If the RMI service exposes a method that accepts an arbitrary Object as a parameter then the method can be used as an entry point for deserialization attacks. Some examples of such methods can be seen below:
public void setOption(String name, Object value);
public void addAll(List values);

3. Deserialization via Illegal Method Invocation
Due to the use of serialization, and insecure handling of method parameters on the server, it is possible to use any method with non-primitive parameter types as an entry point for deserialization attacks. BaRMIe achieves this by using TCP proxies to modify method parameters at the network level, essentially triggering illegal method invocations. Some examples of vulnerable methods can be seen below:
public void setName(String name);
public Long add(Integer i1, Integer i2);
public void sum(int[] values); 
The parameters to each of these methods can be replaced with a deserialization payload as the method invocation passes through a proxy. This attack is possible because Java does not attempt to verify that remote method parameters received over the network are compatible with the actual parameter types before deserializing them.

Дата: 2017-10-19 21:02:05

Источник: http://www.kitploit.com/2017/10/barmie-java-rmi-enumeration-and-attack.html