`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

От чего нас отвлекают, или по следам уязвимости Shellshock

Читая заметки, касающиеся последних уязвимостей, невольно чувствуешь себя наблюдателем, на глазах которого разворачиваются масштабные события. Посудите сами, за относительно короткий срок мы узнаем о HeartBleed, BadUSB, BERserk, а теперь и Shellshock. Это при том, что каждая из этих уязвимостей в отдельности может быть положена в основу блокбастера. Давайте попытаемся разобраться в том, что происходит.

И так, Сеть до сих пор лихорадит от недавно обнаруженной уязвимости в UNIX-интерпретаторе команд bash. Как оказалось, более 10 лет оболочка bash в различных NIX системах (а это немалое количество интернет-серверов, сетевого оборудования, встроенных систем и т.д.) была уязвима к инъекции кода из-за некорректной обработки переменных среды. Перечень уязвимых служб и вариантов атак продолжает расти, расследование идет. На данный момент точно известно об успешных атаках на UNIX web-сервера, использующие метод CGI, DHCP и OpenVPN. Это краткая вводная для тех, кто по каким-то причинам пропустил начало событий.

Скептик может возразить, мол, уязвимости, а тем более, критические уязвимости, находили и раньше, и видит Бог, будут находить в будущем, и по-своему будет прав. Однако я вижу все иначе и хочу поделиться своими мыслями с читателем.

Во-первых, я хотел бы обратить Ваше внимание на «калибр» HeartBleed и Shellshock. В отличие, скажем, от BadUSB, живых примеров которой в природе мы пока не встречали (демонстрация на Black Hat не в счет), первые две уже были успешно апробированы в качестве «отмычек» при целевых атаках. Опять же, следует учитывать, что нам остается оперировать данными, которые появились уже после того, как уязвимости были обнародованы. Отследить факт использования таких скрытых угроз на протяжении их жизненного цикла весьма трудно: пока не знаешь куда смотреть, не увидишь.

Во-вторых, я не случайно рассматриваю HeartBleed и Shellshock в паре. Обе уязвимости хоть и отличаются механизмами реализации, имеют нечто общее:

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

Что касается интернета вещей, то помимо большой «площади поражения», показательным является то, что уязвимости HeartBleed и Shellshock не только представляли угрозу для инфраструктуры компаний, но также могли быть использованы для компрометации различных решений ИБ. То есть, в группе риска оказались не только целевые системы, но и механизмы защиты, которые были построены с использованием уязвимых opensource-компонентов.

По поводу длительного пребывания в тени: HeartBleed по разным оценкам существовала до официального обнаружения около двух лет, Shellshock – минимум 10. Мы все знаем, что даже фрейм длительностью от 7 до 14 дней для уязвимостей такого класса – это опасно, а тут годы. И ведь никто в здравом уме сейчас не даст гарантии, что этими уязвимостями не пользовались ранее, пока о них не было известно широкой публике.

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

С последней, кстати, связан показательный случай: одержав победу на хакерском конкурсе Pwn2Own в 2012 г., представители Vupen Security отказались передать подробности уязвимости браузера Google Chrome компании Google. Vupen отказалась от приза в размере $60&nbs.тысяч потому, что решила приберечь эксплойт для продажи заказчикам по возможно выгодной, гораздо большей цене. Теперь читатель может судить о стоимости подобных эксплойтов. Напомню, что в случае с Vupen речь шла о браузере, чей ареал, как правило, ограничен в отличие от известной уже парочки HeartBleed и ShellShock.

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

Мысль #1. Почему только сейчас?

Я имею в виду, что все мы: админы, технари, эксперты и обычные пользователи Сети, могли существовать в неведении еще лет десять прежде, чем кто-то обратил бы наше внимание на уязвимости подобного рода. И это несмотря на самоотверженные старания комьюнити ИБ и opensource-экспертов различного ранга. Такие размышления формируют следующую мысль.

Мысль #2. Обнаружение таких существенных уязвимостей в фундаменте Сети – это заслуга экспертов или наоборот – чья-то недоработка?

В самом деле, как так, 10 лет к ряду никто там не искал, а тут вдруг нашли. А ведь потенциал у ShellShock`а большой, и создается впечатление, что его просто «слили». Почему? Очевидно, что частные компании типа Vupen на ряду с различными спецслужбами могли бы еще несколько лет успешно использовать эти уязвимости. Если руководствоваться древнеримским принципом «Cui bono» (Кому выгодно?), становится очевидным, что ни тем, ни другим преждевременный «слив» такого качественного материала был невыгоден. Что приводит нас к следующей мысли.

Мысль #3. Обнаружение этих уязвимостей является попыткой улучшить Сеть или изменить правила игры?

Понятное дело, что мысль о существовании некоего круга лиц, которые уподобившись Робин Гуду берут эксплойты у АНБ и передают их общественности слишком наивна и способна разве что вызвать усмешку у читателя. Может быть, предупреждение о фундаментальных уязвимостях – это благо для пользователей сети? Но только в том случае, если нас не подталкивают к чему-то заранее подготовленному. Ведь согласитесь, такими «сливами» удобно готовить почву для перехода на новые, защищенные технологии, которые контролируются теми, кто больше заплатит.

Мысль #4. От чего нас могут отвлекать?

Если моя предыдущая гипотеза показалась Вам невероятной, в духе теории заговора, попытайтесь поразмыслить над тем, кому и для чего может понадобиться такой отвлекающий маневр с серьезными уязвимостями? Неоспоримый факт – основная масса ИТ-сообщества, в том числе и кибер-преступники, узнали о том, что bash уязвим после обнародования информации в Интернете. С одной стороны, широкая огласка дает возможность сознательным технарям закрыть уязвимость в подшефном хозяйстве, с другой – дает очередной вызов ИТ-энтузиастам, которые не всегда применяют знания во благо. Сейчас, пока эти уязвимости «на слуху» многие эксперты с мировым именем сосредоточились на bash и openssl. И администраторы многих компаний волей-неволей втягиваются в этот процесс, устанавливая очередной ворох обновлений, который, кстати, не защищен от ошибок, как это произошло с первыми патчами для ShellShock. Ведь гарантий, что патч не добавляет новых проблем, разработчики не дают.

Почему бы в этот момент, пока все заняты делом, не произвести «закладку» в новую редакцию стандарта или начать атаковать совсем в другом месте?

Мысль #5. К чему готовиться?

Любой уважающий себя ИТ/ИБ специалист в первую очередь обязан «держать руку на пульсе событий». Если же он не следит за ситуацией, ценность его экспертизы падает с каждым днем. Поэтому на первых порах мы вынуждены будем только наблюдать. Да, нам всем также необходимо вычитывать сводки, ставить патчи. Но не стоит расслабляться и зацикливаться на той проблеме, которая в данный момент является «трендом». Необходимо постоянно проверять каждый элемент структуры ИТ-системы, иначе именно он может в последствии стать тем самым «слабым звеном».

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

Все вышеизложенное является моим личным мнением и не претендует на истину в последней инстанции.

P.S. Помните, неосторожное использование высоких технологий может привести к нежелательным последствиям.

BadUSB: доверять нельзя отказаться

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

На прошедшей ежегодной конференции BlackHat исследователи компании SRlabs Карстен Нол (Karsten Nohl) и Якоб Лел (Jakob Lell) представили доклад под названием BadUSB. По моему скромному мнению, изложенная в нем проблематика была осознана ИТ-сообществом не в полной мере. Мало кто обратил внимание на то, что BadUSB – это не только и не столько новый способ доставки вредоносного кода, сколько повод начать решать целый спектр проблем, о которых как пользователи, так и эксперты по безопасности раньше предпочитали не думать. Вопрос доверия к устройствам – лишь одна из граней. Но давайте обо всем по порядку.

Чем BadUSB отличается от привычного нам Conficker или нашумевшего Stuxnet, которые тоже использовали флэшки в качестве вектора атаки, и с которыми мы кое-как научились бороться? Главное отличие BadUSB в том, что вредоносный код располагается не в основной памяти USB-устройства, а в его прошивке:

BadUSB доверять нельзя отказаться

Т.е. речь идет о том, что атакующий модифицирует прошивку флэшки или USB-клавиатуры под свои цели (конкретные примеры и возможные варианты атак будут рассмотрены ниже). Опасность таких атак заключается в том, что ни ОС, ни классический антивирус, ни тем более пользователь прямого доступа к прошивке устройства не имеют, вследствие чего существующие (стандартные меры, к которым все привыкли) не могут защитить систему. Но и это еще не все – зараженный USB-гаджет не только может скомпрометировать ОС, но и модифицировать прошивку системного USB-контроллера, после чего компьютер начнет инфицировать другие подключаемые USB-устройства. Широкое распространение веб-камер, гарнитур, клавиатур и другого оборудования дает основания для весьма мрачных прогнозов: одного зараженного устройства, флэшки или смартфона, хватит, чтобы в течении короткого времени заразить небольшой офис компании.

Еще одна грань проблемы – это возможная «трансформация» устройства, которая может быть использована для эмуляции, к примеру, USB-Ethernet-интерфейса или USB-дисплея. Дело в том, что архитектура USB устроена таким образом, что устройство при инициализации должно представить себя, передав ОС идентификаторы, которые описывают класс и тип подключенного гаджета. Так, к примеру, веб-камера определяется двумя отдельными ID: видеокамера и микрофон. Имея возможность модифицировать прошивку USB-устройства, атакующему не составит труда подготовить устройство, которое будет представляться различным образом в зависимости от типа ОС или от того, на каком этапе загрузки его подключили к системе.

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

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

Демо #1: эмуляция клавиатуры, запуск скрипта

К ноутбуку под управлением Windows 7 подключается обычная, на первый взгляд, флэшка. Проходит стандартный процесс идентификации устройства и установки драйверов. Флэшку показательно форматируют, предоставляя возможность убедиться, что файловая система пуста. Но спустя несколько минут на экране мелькает запущенное окно PowerShell – атака состоялась. Подключенное устройство эмулировало USB-клавиатуру для запуска скрипта, который загружал и устанавливал в системе backdoor. На первый взгляд для защиты от данного сценария будет достаточно белых/черных списков USB-устройств, однако после анализа ситуации становится ясно, что блокирование определенного класса устройств является хоть и действующей, однако недостаточной мерой – доверенные устройства из белого списка могут быть инфицированы, и как только это произойдет, черный список окажется бесполезным.

Касательно эффективности обычной антивирусной защиты, тут все будет зависеть от конкретной «нагрузки» (payload). Если скрипт будет загружать что-то явно вредоносное, то антивирус должен это заметить и пресечь. Но если загружается не вирус, а, скажем, средства удаленного управления? У McAfee VirusScan Enterprise, к примеру, есть отдельный набор правил, позволяющий блокировать запуск скриптов и установку новых приложений. Однако, как увидим из дальнейших сценариев, заблокировать выполнение «нагрузки» – это лишь половина задачи.

Демо #2: заражение «здоровой» флэшки скомпрометированным ПК, атака на Linux

К ноутбуку с Windows 7 подключается чистый накопитель, буквально на минуту. Затем он подключается к Linux-системе. Устройство, прошивка которого была изменена зараженной системой, исполняет в Linux произвольный код. К примеру, это может быть использовано для запуска поддельной экранной заставки с целью получения пароля пользователя для последующего повышения привилегий.

Здесь важны два момента:

  1. инфицированный компьютер становится рассадником угрозы (фактически, «вирус» с Windows 7 распространился на чистый накопитель, а с него на Linux);
  2. модифицированная прошивка устройства может определить, под какой ОС она работает, и, в зависимости от типа последней, выполнять различные функции. Заблокировать исполнение произвольного кода можно, к примеру, с помощью McAfee Application Control, однако сохраняется проблема с передачей вируса от инфицированного компьютера к другим флэшкам.

Демо #3: использование подготовленного смартфона для перехвата сетевого трафика

BadUSB доверять нельзя отказаться

К ноутбуку подключается смартфон, якобы для подзарядки. Практически никто при этом не обращает внимание, что наряду с подключенным Wi-Fi в списке появляется Ethernet подключение, хотя к ноутбуку витая пара не подключена(!). Итогом стала возможность подмены URL и перехвата связки логин/пароль, введенной обманутым пользователем.

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

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

На этом фантазия исследователей не закончилась, на следующем слайде представлены некоторые новые векторы угроз, к которым уже сейчас нужно (необходимо) готовиться как пользователям, так и сотрудникам департаментов ИБ:

BadUSB доверять нельзя отказаться

Сразу оговорюсь: я не считаю, что BadUSB будет широко применяться. Он наверняка кого-то заинтересует и будет задействован для APT, но это все-таки будет штучный товар. Широкую эпидемию на текущем этапе я исключаю, т.к. пока модифицировать прошивку USB умеют лишь два сотрудника SRLabs да с десяток человек в АНБ (которое, если верить (господину) Сноудену, давно питает интерес к атакам через аппаратные составляющие компьютерных систем). Но задумайтесь вот о чем: двое исследователей, которым потребовалось пускай 3-4 месяца на реализацию, своим докладом на конференции волей-неволей подтолкнули кого-то из тех, у кого хватит компетенции повторить это. Не сразу, но через полгода/год реализации BadUSB начнут появляться в теневой зоне Интернета. И пусть они не скоро станут игрушкой script kiddie, поскольку «начинку» USB-устройства нужно формировать самостоятельно под конкретную задачу. Но суть моих предостережений заключается в том, что людям в отделах ИБ определенных компаний надо уже сейчас задумываться если не о полном отказе от USB-устройств (в рамках конкретных бизнес-процессов), то хотя бы об ограничении их «контактов» с неконтролируемыми системами, ну и, само-собой, о защите конечных точек от эксплуатации BadUSB.

Давайте посмотрим на то, как докладчики оценили текущую готовность ИБ сообщества к BadUSB. Я взял на себя смелость не только осуществить перевод слайдов, но и выделить красным те методы защиты, которые доступны уже сейчас:

BadUSB доверять нельзя отказаться

Подводя итоги, можно предложить следующие рекомендации:

  • для защиты от атак, нацеленных на заражение/модификацию BIOS и MBR уже сейчас можно использовать McAfee Deep Defender, который загружается перед стартом ОС;
  • если по каким-то причинам использование Deep Defender невозможно (устаревшая ОС/CPU, отсутствие бюджета) – хотя бы отключить в BIOS автоматическое обновление прошивки, жестко ограничить загрузку только с системного HDD и закрыть BIOS паролем;
  • это очевидно, но все же – не работать под учетной записью с привилегиями администратора;
  • если антивирус позволяет блокировать установку ПО/запуск скриптов – необходимо эти функции активировать;
  • по возможности задействовать McAfee Device Control для блокирования неизвестных устройств, однако не стоит ограничиваться только этой мерой;
  • при использовании накопителей, равно как и других USB-устройств, стараться контролировать «ареал» их обитания и не допускать подключения, скажем, флэшки к чужому, непроверенному ноутбуку;
  • если свести к минимуму контакты флэшки/смартфона с чужим оборудованием возможности нет, то как вариант можно использовать накопители IronKey, которые уже защищены от BadUSB.

Изменилось ли мое отношение к USB-гаджетам после анализа BadUSB? Безусловно, теперь я знаю о новых потенциально возможных векторах атаки (о реализации которых не подозревал ранее). Откажусь ли я сам от USB и буду ли советовать отключать данный интерфейс? Нет. Я просто стану использовать дополнительные меры предосторожности. А главное – продолжу внимательно следить за развитием «аппаратных» атак, потому как их потенциал будет только расти. Ведь может оказаться, что для конкретной задачи компрометация аппаратных ресурсов окажется более эффективной, чем атака на конкретную ОС.

А внимательному читателю предлагаю самому поставить запятую в заголовке.

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT