На прошлой неделе было опубликовано интересное исследование об атаках на Unix-подобные системы. В нем описано создание ханипота из Docker-контейнера (новость, исходная статья Akamai). Docker было использовать не обязательно, ведь поведение «ботоводов» из отчета ничем не отличается от атаки на любую другую доступную из сети Linux-систему с дефолтным паролем. Но при работе с Docker растет вероятность ошибки оператора — когда случайно поднимается доступный из сети контейнер с настройками по умолчанию.

Соответственно, «взлом» в данном эксперименте очень простой: образ был поднят с легко угадываемым паролем для учетной записи root, а точнее, были исследованы несколько типичных пар логин-пароль вроде root:root или oracle:oracle. Интерес представляют дальнейшие действия атакующих. Для ряда успешных логинов сценарий был одинаковый: взломанная система использовалась как прокси-сервер, причем даже не для криминальных дел — был замечен трафик с сервисов Netflix, Twitch и подобных, очевидно, для обхода региональных ограничений. Но были и успешные попытки подключения системы к ботнету.

Неделю назад, 7 апреля, специалисты «Лаборатории Касперского» опубликовали подробное исследование Android-трояна xHelper. Впервые его обнаружили в середине прошлого года, большая часть атак с использованием зловреда приходится на телефоны российских пользователей. Его самое примечательное свойство — способность пережить даже сброс настроек телефона до заводских.

В прошлом году наши эксперты, занимающиеся автотестами под Android, объединились с коллегами из других компаний и создали фреймворк для автотестирования Kaspresso. В сентябре они представили его на «Хабре» (пост, в котором они объясняют, что сделали и зачем). За полгода существования Kaspresso воспользовались тысячи людей, и у многих возникали те или иные вопросы про фреймворк и инфраструктуру в целом. Мы заметили, что часто эти вопросы повторяются, и подумали, что на них хорошо бы ответить централизовано.

В четверг 2 апреля издание The Guardian поделилось впечатляющими цифрами о платформе для веб-конференций Zoom: рост посещаемости этого сервиса составил 535%. Определенно Zoom лучше конкурентов смог воспользоваться ситуацией, получив прирост если не в деньгах, то точно в популярности и количестве пользователей. Причиной такого успеха стал скорее эффективный маркетинг (например, наличие бесплатной тарифной опции), чем какие-то технические преимущества. Все было бы хорошо, если бы не характерный заголовок той же статьи в The Guardian: «Zoom — это вредоносное ПО».

Давайте сразу уточним: Zoom — это не вредоносное ПО. Не в первый раз компании привлекают к себе внимание специалистов по информационной безопасности на волне хайпа, но обсуждение недостатков Zoom на прошлой неделе стало главным развлечением всей тусовки. Если коротко: шифрование переговоров в Zoom есть, но недостаточно сильное, и точно не может быть квалифицировано как end-to-end. Обнаружилась пара серьезных и пачка несерьезных уязвимостей в софте. Пара особенностей работы сервиса вызывают вопросы по части приватности — пропуск данных через сервер в Китае и интеграция с LinkedIn. Ничего ужасного, но снова становится понятно, что защищенность цифрового сервиса все еще не является залогом его успеха.

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

Начнем с цифрового аспекта. Сервис телеконференций Zoom, испытывающий в последнее время значительный прирост числа пользователей, стал объектом внимания и тех, кто заботится о приватности, и тех, кто любит ее нарушать. Последние ответственны за явление, названное "ZoomBombing": подключение к чатам других людей для наведения бардака и паники. Причина — отсутствие надежных инструментов для того, чтобы к встрече могли присоединиться только те, кого там ждут.

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

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

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

Компания Microsoft 10 марта выкатила очередной ежемесячный набор апдейтов, закрывающий 115 уязвимостей в ее продуктах — от Windows 10 до облачного сервиса Azure. А 11 марта пришлось выпустить внеочередной патч для критической проблемы в реализации протокола SMB в Windows 10 (новость, бюллетень Microsoft, описание патча, обсуждение на Хабре).

Исходное предупреждение об обнаружении уязвимости было распространено за день до выпуска патча, причем по довольно нестандартной причине. Статьи с описанием уязвимости были по ошибке опубликованы компаниями Cisco Talos и Fortinet, что, видимо, стало результатом взаимонепонимания между ними и Microsoft в процессе совместного исследования. Публикации были удалены, однако в качестве меры предосторожности компания Microsoft распространила рекомендации по защите SMB-серверов. Для клиентов до выпуска патча временного решения не существовало, что представляло определенную опасность, так как дыру в Windows 10 (и в двух модификациях Windows Server) можно эксплуатировать для выполнения произвольного кода.

20 февраля на Хабре появился резонансный пост с примерами объявлений в поисковой выдаче по запросам пользователей, желающих загрузить распространенный софт. Рекламные ссылки вели на сторонние ресурсы, а не на официальный сайт разработчика. Автор поста не проверял, являются ли распространяемые программы вредоносными, а в комментарии «Яндекса» указывалось, что объявления подобного рода проверяются перед публикацией. Скорее всего, в выдаче по популярным запросам рекламируются сайты, получающие от разработчиков ПО комиссию за установку программ.


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

На прошлой неделе в Сан-Франциско прошла очередная конференция по кибербезопасности RSA Conference 2020 — мероприятие, в котором бизнеса немного больше, чем технологий. Деловые особенности индустрии не менее важны, чем технические, хотя это взаимодействие и проходит под знаком некоего антагонизма: менеджеры по развитию бизнеса говорят красивые слова, а технарям скучно. Кстати, о словах: вот как эволюционировали главные темы RSA Conference, баззворды отдельно взятой конференции, за последние пять лет. В 2016 году главной темой была безопасность IoT, в 2017-м — искусственный интеллект, в 2018-м — отсутствие серебряных пуль и простых решений в киберзащите, в 2019-м — проблема репутации.

В 2020 году президент RSA поднял тему разделения на технарей и бизнесменов, неожиданно превратив торжественное открытие в обсуждение реальной проблемы, пусть и общими словами: «О наших делах будут судить по тому, какая история о них будет рассказана. И мы хотим, чтобы это была история об успешном сопротивлении киберугрозам, а не технические байки о кибер-пинг-понге». То есть: сообщество IT-безопасников — закрытое, человеку со стороны непонятное, и надо это изменить. Делиться не только проблемами, но и успешными решениями: «Переформатировать культуру из элитарной в открытую».

Сразу несколько новостей прошлой недели касались безопасности платформы Android. Наибольший интерес представляет исследование безопасности смартфона Samsung, проведенное командой Google Project Zero. В модели Samsung Galaxy A50 (возможно, и в других тоже, но это не проверялось) производитель встроил в ядро Linux собственный код, отвечающий за аутентификацию процессов. Система Process Authenticator призвана усилить безопасность смартфона: при запуске приложений и системных служб она сверяет цифровую подпись.

Проверяется относительно небольшое количество процессов. По уникальному формату подписи исследователь обнаружил всего 13 штук, среди них — сервисы для работы с Bluetooth и Wi-Fi. Эксперт из Google создал сценарий, при котором система Process Authenticator вызывается для «проверки» вредоносного приложения, а ряд уязвимостей в коде Samsung позволяет получить расширенные права. Приводится пример чтения данных из базы авторизованных на телефоне аккаунтов. Вывод из этого следующий: модифицировать ядро от поставщика (то есть от Google) — не всегда хорошая идея. И вот тут совершенно техническая статья переходит в плоскость политики и поднимает тему взаимодействия участников экосистемы Android: кто должен отвечать за безопасность софта, и не стоит ли разработчикам смартфонов ограничить модификацию кода в целях этой самой безопасности?

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


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

В февральском наборе патчей для операционной системы Android закрыта уязвимость в Bluetooth-стеке (новость, бюллетень с обзором обновлений). Уязвимость затрагивает Android версий 8 и 9 (и, возможно, более ранние): на непропатченных смартфонах можно выполнить произвольный код с правами демона Bluetooth. Для эксплуатации достаточно знать MAC-адрес устройства и находиться на достаточно близком к жертве расстоянии. В Android 10 проблема также присутствует, но там она приводит только к падению отвечающего за Bluetooth софта, без выполнения кода.

Уязвимость была найдена немецкой компанией ERNW. В блог-посте специалисты отмечают относительную легкость атаки, особенно если телефон жертвы находится в режиме обнаружения. Даже без такового вычислить MAC-адрес устройства можно, узнав идентификатор модуля Wi-Fi — в некоторых смартфонах они отличаются на одну-две цифры. Исследователи не раскрывают технические детали уязвимости: их планируется обнародовать спустя некоторое время. Впрочем, исправленный код уже доступен, так как относится к открытой части платформы Android.

Мобильное приложение для работы с «умными» дверными звонками Amazon Ring отправляет подробные данные о пользователе сразу в три компании, собирающие информацию для последующего рекламного таргетирования, а также в соцсеть Facebook. Таковы результаты исследования, проведенного Фондом электронных рубежей (новость, оригинальная статья). Результаты анализа EFF нельзя назвать шокирующим открытием: данные в рекламные сети так или иначе поставляет большинство мобильных приложений. Интерес представляет метод расшифровки данных, а также тип исследуемого приложения. В отличие от любых других сценариев, здесь речь идет о работе с персональной камерой наблюдения. Такое взаимодействие, по идее, должно происходить с максимальным уровнем приватности.


Но нет. Например, социальная сеть Facebook получает от приложения Amazon Ring уведомления об открытии приложения, о действиях пользователя, а также данные, позволяющие идентифицировать владельца. К ним относятся модель смартфона, настройки языка, разрешение экрана, идентификатор устройства. Все эти данные Facebook будет обрабатывать даже в том случае, если вы не имеете учетной записи в социальной сети. Это само по себе является интересной проблемой: если аккаунт в Фейсбуке у вас есть, то вы имеете хотя бы минимальный контроль над данными, которые напрямую ассоциированы с ним. Если нет учетной записи, то нет и контроля, но соцсеть все равно про вас что-то знает. Хотя не во всех наборах данных, отправляемых рекламодателям, присутствуют однозначные (вроде имени и фамилии) идентификаторы пользователя, это зачастую и не требуется. Комбинирование данных из разных приложений идентифицирует нас получше паспорта и сообщает рекламодателям о таких чертах характера и привычках, о которых мы, возможно, сами не подозреваем.

23 января подразделение американского департамента внутренней безопасности, ответственное за киберугрозы, опубликовало информацию о шести серьезных уязвимостях в медицинских устройствах (новость, исходный документ). Проблемы были обнаружены в больничном оборудовании компании GE, включая медицинские мониторы Carescape B450, 650 и 850. По шкале CVSSv3 пять уязвимостей получили 10 баллов — высшую оценку, обозначающую возможность удаленной эксплуатации без специальных навыков. Раскрытие данных о проблемах в специализированной технике происходит нечасто и позволяет оценить уровень защищенности таких устройств.



На фото выше — одно из устройств, упомянутых в сообщении, монитор Carescape B650. Спецификации на сайте отсутствуют, и даже в даташите не указана аппаратная платформа и используемая операционная система. Но дата в документе (2010 год) указывает на очевидную проблему такого оборудования: стоит дорого, используется долго. По сути это независимый компьютер с 15-дюймовым дисплеем, способный работать автономно и подключающийся к проводной или беспроводной сети для передачи данных.

Для этого устройства актуальны две уязвимости: CVE-2020-6962 описывает проблему с валидацией введенных данных в веб-интерфейсе, которая может привести к запуску произвольного кода. CVE-2020-6965, судя по всему, намекает на незащищенную систему обновления ПО, которая позволяет загружать на монитор произвольные файлы без авторизации.

Главной новостью прошлой недели стала уязвимость в криптобиблиотеке Windows, связанная с некорректной проверкой цифровых сертификатов. Проблема была закрыта кумулятивным патчем, вышедшим во вторник, 14 января. По данным Microsoft, реальных атак до раскрытия информации замечено не было. Уязвимость, кажется, впервые в истории обнаружило американское Агентство Национальной Безопасности. Точнее, АНБ наверняка занимается поиском уязвимостей и (возможно) их эксплуатацией на регулярной основе, а вот открытая передача информации вендору от имени АНБ происходит в первый раз.



Уязвимость затрагивает самые свежие версии Windows 10 и Windows Server 2016/2019. По шкале CVSSv3 она оценивается в 8,1 балла — достаточно серьезно, но бывали события и похуже. Для непропатченной системы она открывает возможность проведения весьма правдоподобной MiTM-атаки. То есть можно направить пользователя на поддельный веб-сайт так, что браузер даже не будет ругаться на отсутствие или некорректность сертификата. Аналогичным образом софт с поддельным сертификатом будет определен как легитимный. Это не так опасно, как ранее обнаруженные уязвимости в сервисах удаленного доступа, но достаточно плохо, чтобы произошло непривычное сотрудничество АНБ и Microsoft.

Седьмого января команда Google Project Zero, специализирующаяся на поиске уязвимостей в ПО, сообщила об изменениях в правилах раскрытия информации об обнаруженных багах (новость, пост в блоге). В 2020 году Project Zero будет раскрывать информацию об уязвимостях через 90 дней после первого уведомления «пострадавшего» вендора. Дедлайн не изменился, но до этого исследователи из Project Zero могли опубликовать отчет о проблеме быстрее, если разработчику ПО удалось выпустить патч до этого срока. Теперь Project Zero будет ждать 90 дней вне зависимости от наличия заплатки.

Новые правила представляют интерес по ряду причин. Во-первых, нет единого стандарта — сколько времени давать разработчику ПО на анализ уязвимости и ее устранение. Команда Project Zero, регулярно обнаруживающая серьезные уязвимости в ПО, принимает такие решения самостоятельно и таким образом пытается влиять на всю индустрию. Во-вторых, важно изменение приоритетов: вместо «давайте закроем этот баг побыстрее» разработчиков мотивируют устранять уязвимость надежно. Иначе регулярно выходит, что патч либо не решает проблему вовсе, либо добавляет новые баги.

Если посмотреть на нашу подборку важных новостей за 2018 год, то может возникнуть ощущение, что в уходящем 2019 году ничего не поменялось. Аппаратные уязвимости по-прежнему выглядят многообещающе (последний пример: обход защиты Software Guard Extensions в процессорах Intel) и все еще не применяются в реальных атаках. Зато применяется на практике машинное обучение, например для высокотехнологичного социального инжиниринга. Имитация голоса руководителя организации помогла украсть миллион евро, а компания Microsoft организовала конкурс на создание алгоритма, детектирующего дипфейки.


Угрозы из Интернета вещей тоже никуда не делись, причем в 2019 году было больше исследований про IoT нового поколения. Свежий пример: "голосовой фишинг" с использованием умных колонок. Все это примеры перспективных атак, которые могут (естественно, внезапно) стать актуальными в будущем. В настоящем же атакуется традиционная инфраструктура: эксперты «Лаборатории Касперского» одной из главных тем года назвали точечные атаки вымогателей-шифровальщиков. Самые громкие новости года были связаны с успешными атаками на инфраструктуру, которая одновременно является критически важной и хронически недофинансированной, — IT-системы в муниципалитетах и больницах.

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

Еще в октябре исследователи из компании SRLabs показали, как можно менять поведение умных колонок Amazon Echo и Google Home для подслушивания разговоров или даже фишинга паролей (новость, исследование). Для последнего даже существует специальный термин — vishing, он же voice phishing, то есть фишинг, в котором жертва делится секретами голосом.


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

Спустя два месяца исследователи сообщили, что проблемы исправлены не были. В ходе исследования в «магазин приложений» умных колонок были загружены «вредоносные» приложения. Результаты были переданы в Amazon и Google, после чего приложения были удалены, но в SRLabs без труда загрузили их заново, и они смогли пройти проверку. Ситуация напоминает проблему с вредоносными приложениями для обычных смартфонов в Google Play Store и Apple App Store: тактика та же, просто методы социальной инженерии немного другие. В любом случае, это интересный пример эволюции атак с учетом появления устройств, которые постоянно подслушивают и подсматривают за владельцами.

10 декабря компания Apple выпустила большой набор патчей для macOS, iOS (включая iPadOS) и watchOS. Пожалуй, наиболее опасным из закрытых багов была уязвимость в FaceTime, затрагивающая все мобильные устройства Apple начиная с iPhone 6s и iPad Air 2. Как и в случае с обнаруженной недавно уязвимостью в WhatsApp, проблема найдена в системе обработки входящих видеофайлов: вредоносный ролик может привести к выполнению произвольного кода. Уязвимость CVE-2019-8830 обнаружила исследователь команды Google Project Zero Натали Сильванович (Natalie Silvanovich): она в прошлом году подробно писала про безопасность мессенджеров, включая FaceTime (начать можно со статьи годичной давности с примерами ранее обнаруженных уязвимостей в приложении).


Еще одну уязвимость обнаружил исследователь Кишан Багария (Kishan Bagaria): он выяснил, что непрерывная отправка документов на устройства Apple, находящиеся поблизости, приводит к отказу в обслуживании. Для этого на iPad или iPhone должна быть включена возможность приема файлов через механизм AirDrop от кого угодно (а не только от пользователей в вашем списке контактов). Баг был ожидаемо назван AirDoS: суть в том, что запрос на прием файла нужно принять или отклонить, и пока этого не сделаешь, другие элементы управления на мобильном устройстве недоступны. Если отправлять запросы постоянно, планшет или смартфон оказывается по факту неработоспособным. Баг был закрыт в iOS 13.3 путем введения ограничения на количество попыток: если отклонить запрос три раза подряд, все последующие попытки отправить файл с того же устройства блокируются автоматически.

Сразу несколько новостей этой недели описывают атаки типа Man-in-the-middle, а также средства борьбы с ними. Начнем с относительно курьезной новости: уязвимость нулевого дня случайно обнаружил пользователь Твиттера SwiftOnSecurity — анонимная персона, специализирующаяся преимущественно на околобезопасном юморе.


Уязвимость затрагивает приложение Atlassian Companion App — это необязательный компонент облачного сервиса для совместной работы Confluence, который позволяет работать с файлами на компьютере: загружает копию из облака, передает в офисное ПО, а затем отправляет измененный файл обратно. Частью приложения является локальный веб-сервер, а доступ к нему реализован через публичный домен с характерным названием atlassian-domain-for-localhost-connections-only.com.

Домен резолвится на локальный IP 127.0.0.1 — такая конструкция сделана для шифрования трафика по протоколу SSL. Проблема в том, что подобная схема может быть достаточно легко использована злоумышленником, способным изменять записи DNS: сертификат у всех локальных пользователей приложения одинаковый, и ничто не мешает перенаправлять локальный трафик на сервер атакующего с последующим доступом к приватным данным. По данным издания The Register, Atlassian работает над устранением данной уязвимости.