Привет, Хабр! Меня зовут Марат Сафин, я эксперт по безопасности КИИ и АСУТП в К2 Кибербезопасность. Более восьми лет занимаюсь кибербезом с упором на защиту промышленных объектов и АСУТП. До этого пять лет внедрял и обеспечивал функционирование самих АСУТП.
Сегодня расскажу о любопытной дыре в защите удаленных рабочих мест, которую я, можно сказать, вывел сначала гипотетически, а потом доказал. Помните, как всех сотрудников в пандемию срочно переводили на удаленку и пытались в безопасность, начиная, конечно же, с закрытия буфера обмена? Так вот, оказывается, и закрытый буфер обмена, и другие средства защиты можно обойти одним весьма простым способом.
Суть в том, что любой файл можно передать куда угодно, просто... набрав его на клавиатуре. Звучит безумно? Давайте разберем, как это работает, докажем работоспособность концепции, и, конечно, поговорим, как от этого защититься.
Однажды мы внедряли у заказчика крупный проект со множеством различных защитных подсистем. Для защиты удаленного доступа решили использовать, помимо прочего, доверенные рабочие среды — LiveUSB-токены со своей операционкой и подключением к удаленному рабочему столу внутри инфраструктуры компании через шифрованный канал.
Безопасность тут достигается за счет того, что рабочая оболочка программно никак не соприкасается с оболочкой домашней ОС пользователя. В эту рабочую оболочку нельзя ничего загрузить и нельзя ничего скачать из нее. Помимо взаимодействия человека с данной средой, любое другое информационное воздействие отсутствует.
С тех пор этот подход к защите прочно засел в головах, как самый лучший, который уж точно защитит инфраструктуру заказчика от любых угроз, исходящих от удаленного пользователя. Но, как это часто бывает в реальной жизни, «волшебной таблетки» от всех проблем не существует, и способ обойти защиту вскоре был найден.
Гипотеза и доказательство концепции
Исходные условия
Изолированное удаленное рабочее место — работа в терминальном режиме на удаленном компьютере или в инфраструктуре VDI. Буфер обмена закрыт, как файловый, так и текстовый. Казалось бы, все защищено: пользователь не может скопировать и сохранить у себя служебный документ, или наоборот, протащить в корпоративную систему вредонос.
Задача
Необходимо переправить на удаленный компьютер произвольный файл, который потенциально может содержать «полезную нагрузку».
Забегая вперед, таким же способом может решаться и обратная задача, — скрытно извлечь произвольный файл с конфиденциальными данными из периметра предприятия.
Гипотеза
Базовый принцип, который мы будем использовать, заключается в том, что вся компьютерная информация, в т.ч. любой файл существует в двоичном виде – в виде нулей и единиц. Любой файл (в т.ч. исполняемый с «полезной нагрузкой») можно открыть текстовым редактором, где все символы будут просто интерпретацией 8-битных (или 16-битных, в зависимости от отображаемой кодировки) последовательностей тела файла. А значит, если воспроизвести ту же самую последовательность символов на целевом удаленном ресурсе, то там должна получиться точная копия файла вплоть до совпадения хэш-сумм.
Доказательство концепции
Для начала я поднял виртуалку в облаке и подключился к ней через веб-консоль. Буфер обмена, разумеется, с этой средой не дружит, соответственно ни drag-and-drop, ни Ctrl+C и Ctrl+V тут не работают.
Скачал на локальную машину EICAR, открыл его блокнотом и перебил руками посимвольно в блокнот в удаленном окне, сохранил. Сравнил хэши, — о, чудо, они совпали!
Однако, если мы имеем дело с реальным исполняемым файлом, то сразу всплывают две глобальные проблемы:
1. В теле файла будут содержаться непечатные символы, которые клавиатурой воспроизвести проблематично (и альт-коды тут тоже проблему не решат, см. следующий пункт).
2. Количество символов несоизмеримо выше, чем в тестовом EICAR’е, так что перебивать этот массив руками не вариант.
Чтобы решить первую проблему, понадобится hex-редактор, который может отображать файл не в представлении текстовых символов, а в представлении четырехбитных последовательностей (полубайтов) – шестнадцатеричных цифр от 0 до F, и, соответственно, потом сохранять эти цифры обратно на диск в виде полубайтов. Т.е. набирать нужно будет уже только вполне воспроизводимые на клавиатуре шестнадцатеричные цифры от 0 до F (будем называть их hex-символами).
Что касается второй проблемы, то очевидно здесь нужна программная эмуляция ввода. Концептуально такой инструмент мог бы принимать на вход файл, преобразовывать его в последовательность hex-символов, а затем в выбранном окне выполнять программный ввод этой последовательности с какой-то регулируемой задержкой между эмулированными нажатиями. Очевидно, что предполагаемое к выбору окно — это окно терминального клиента на удаленный ресурс, в котором открыт hex-редактор. После окончания эмуляции ввода останется только сохранить файл на диск. С имеющимися сейчас общедоступными ИИ-технологиями собрать такое не составит труда, поэтому безопасникам нужно учитывать достаточно низкий порог входа при оценке потенциала возможных нарушителей.
Вернемся к доказательству концепции. Я подготовил на своей локальной машине тестовый файл — маленькую .png картинку размером 9х9 пикселей, которая содержит те самые непечатные символы, если открыть её обычным блокнотом:
На своей машине открыл её в hex-редакторе, а на виртуалке создал в hex-редакторе новый файл и начал просто руками перебивать hex-символы из одного окна в другое. Никакой копипасты, только ручной труд: 8, 9, 5, 0, 4, E, 4, 7, 0, D, 0, A, 1, A и так далее. Когда закончил, сохранил файл, подсчитал контрольную сумму и сравнил с контрольной суммой исходной картинки — бинго, все совпало!
Вот так концепция угрозы и подтвердилась: передача файла на удаленную машину возможна без буфера обмена и вообще без использования каких-либо протоколов для передачи файлов — просто ручным (либо эмулированным) вводом hex-символов!
Усиление концепции
Однако, очевидно, что у удаленного пользователя может и не быть возможности для установки hex-редактора на целевом корпоративном ресурсе, к которому он подключился. А вот тут ему могут помочь встроенные «из коробки» инструменты в различных ОС, которые тоже способны сохранять hex-символы в полубайты на диск, например, PowerShell, debug, certutil, xxd и т.п.
Продемонстрируем сохранение полубайтов из hex-символов на примере PowerShell:
И здесь все совпало!
Классифицируем угрозу
Отдельный вопрос, как классифицировать подобную угрозу для информационных систем. Ведь по смыслу это не уязвимость конкретного продукта, которой можно было бы присвоить какой-либо рейтинг и выпустить патч. Более того, если бы это было уязвимостью конкретного программного продукта, то, находясь на светлой стороне, мы должны были бы сначала связаться с вендором продукта (какого?) и дождаться, когда он выпустит патч, прежде чем публиковать информацию.
Ответ нашелся в Банке данных УБИ ФСТЭК. Сейчас в этой базе описано 222 возможных УБИ, но по основным признакам подобную атаку можно отнести к УБИ.111 «Угроза передачи данных по скрытым каналам».
Хотя, по контексту здесь упор и сделан больше на утечку конфиденциальной информации изнутри периметра, но «передача управляющих команд» здесь также учтена. При этом, как я уже писал выше про ИИ-технологии, потенциал нарушителя в контексте описанной атаки теперь вполне можно принимать за низкий.
Однако, несмотря на то, что подобная угроза концептуально уже предопределена регулятором, причем достаточно давно, вряд ли много кто из безопасников вообще задумывается о возможности такой её реализации через клавиатурный ввод для своих информационных систем. Поэтому мы плавно переходим к теме о том, как же от неё защищаться.
А как же средства защиты?
Итак, возможность обойти любой закрытый буфер обмена мы уже доказали. Теперь взглянем, как обстоят дела с другими механизмами защиты, и начнем сначала с тех, которые перед подобной атакой будут если не бесполезны, то малоэффективны.
Потоковые антивирусы
Потоковые антивирусы на периметре сети анализируют протоколы передачи данных, в рамках которых можно передавать файлы, например SMB, FTP, SFTP, HTTP/HTTPS и т.п. Но когда тело файла передается через нажатия клавиатуры в рамках обычной терминальной сессии, то это для потокового AV не выглядит как файл и вообще не попадает под анализ антивирусного движка, что по сути — слепое пятно в защите.
Privileged Access Management (PAM)
PAM-решения осуществляют видеофиксацию всех действий пользователя, а также отслеживают ввод потенциально опасных команд вроде форматирования дисков в терминале и в среде Windows. Но вот беда — при передаче файлов через hex-символы такой контроль просто не видит угрозы, ведь вводятся не осмысленные команды, а только лишь текстовые символы от 0 до F.
Основная проблема здесь в том, что у каждого файла свой уникальный набор hex-символов, поэтому заранее создать правила отслеживания для всех возможных комбинаций символов нереально, и вероятность случайного пересечения с каким-то шаблоном будет крайне низкой. В определенной степени может помочь добавление в правила отслеживания команд ввод последовательностей hex-символов, являющихся сигнатурами для определенных типов файлов. Хотя, опять же, основное тело файла можно ввести автоматизировано, а саму сигнатуру — аккуратно вручную, порционно, с большой задержкой, со сменой/закрытием окон ввода или в рамках следующей удаленной сессии.
Представьте: удаленный сотрудник хочет иметь постоянный доступ к корпоративной инфраструктуре. Для этого он может скопировать исполняемый файл с реверс-шеллом, который обеспечит ему впоследствии уже неконтролируемый PAMом доступ. Увольняющийся сотрудник может потом продать такой доступ на черном рынке.
Или другой сценарий: обиженный привилегированный юзер, знающий о тотальном контроле через PAM-системы, решает отомстить компании и копирует вредонос с отложенным запуском. Вирус активируется, например, через год, когда сотрудник уже давно уволится, а записи его сессий либо перезатрутся, либо их просто никто не станет проверять за давностью лет.
Отдельной проблемой становится то, что в классическом случае РАМ настраивают для контроля сессий администраторов, а сессии обычных пользователей остаются без контроля.
Data Loss Prevention (DLP)
В отличие от PAM, DLP-системы защищают корпоративные данные от утечки наружу. Они постоянно мониторят каналы передачи информации: проверяют вложения в почте, контролируют загрузку файлов через веб-формы и анализируют исходящий интернет-трафик на предмет утечки чувствительных данных. Как правило, такие системы не отследят пользовательский клавиатурный ввод hex-символов, но в передовых DLP имеется функция «Поиск похожих», через которую можно выставить правила детекта на клавиатурный ввод и внести в политику детекта образцы строк с hex-символами (опять же, особо уделив внимание сигнатурам, встречающимся в распространенных типах конфиденциальных документов). Тогда DLP сможет детектировать подобную активность и засечь подозрительный клавиатурный ввод (а точнее вывод информации за периметр). Но и это можно обойти, если заменить hex-символы любыми иными символами, а затем выполнить обратное преобразование переданных данных уже за периметром. Поэтому, если у пользователя есть права на запуск произвольных программ на своем корпоративном ПК, то при желании он сможет использовать описанный принцип для скрытой передачи данных вовне в какую-нибудь веб-форму, из которой потом сохранит эти данные.
Доверенные рабочие среды
И тут пришла пора вспомнить то, с чего все начиналась — загрузочные токены с доверенной рабочей средой.
Если пользователь работает с корпоративным ресурсом через доверенную оболочку с жестко ограниченной программной средой на своем удаленном АРМ, а его сертификат для VPN-подключения неизвлекаемо вшит в токен, то, казалось бы, никакой программный эмулятор клавиатурного ввода пользователь в этой среде не запустит. Но ключевое слово тут — «программный».
А что, если к домашнему компу пользователя подключить не обычную клавиатуру, а модифицированную? Фишка в том, чтобы задействовать подключаемый вместо клавиатуры микроконтроллер, позиционирующий себя по HID, как обычную клавиатуру, но при этом, в нужный момент запускающий «полезную нагрузку», а именно эмуляцию ввода hex-символов нужного нарушителю файла, — т.е. своего рода физический эмулятор клавиатуры. По сути, это будет своеобразное BadUSB — устройство, наподобие небезызвестных хакерских флешек Rubber Ducky.
Доверенная рабочая среда на токене, конечно, может защитить от непреднамеренных угроз удаленного пользователя, но считать её серьезной преградой для мотивированного нарушителя — несколько наивно. Да, при моделировании угроз, конечно, можно принять, что удаленный пользователь не является нарушителем, но с другой стороны такой токен ведь легко потерять. Кроме того, на практике куча удаленных рабочих мест доступна через более простые технологии и вообще не привязана к аппаратным токенам.
Так как же защищаться?
Теперь главное — про эффективные способы противодействия.
Принцип защиты от утечек изнутри предприятия до банального прост: обычному пользователю нельзя давать право запускать на своем корпоративном ПК любое стороннее ПО, которое в явном виде не внесено в белый список. Более-менее функциональные средства защиты конечных точек (обычно на базе САВЗ) имеют такую функциональность и помогают провести автоматическую инвентаризацию всего ПО на ПК для формирования белого списка и затем запретить запускать то, чего в этом списке не оказалось.
Чтобы кардинально предотвратить попадание файлов внутрь периметра в обход закрытого буфера обмена и потокового антивируса, нужно жестко ограничить пользователей в запуске программ, умеющих работать с сырыми данными. Речь как раз про те инструменты «из коробки» — PowerShell/certutil/debug/etc и вообще любые программы, способные записывать на диск полубайты из hex-символов. Иными словами, сформированный белый список нужно дополнительно проанализировать и исключить из него то ПО, которое потенциально можно использовать в качестве hex-редактора.
Таким образом, нам нужно жесткое и грамотное ограничение программной среды пользователя на целевом ресурсе.
Однако, с админами такая схема может быть неприменима — им по роду деятельности постоянно нужно запускать разные сторонние инструменты для траблшутинга, отладки и управления. Но тут, как говорится, уже нужно рассматривать каждую ситуацию case-by-case и понимать, насколько мы доверяем тому или иному типу администраторов, если этих типов вообще больше одного.
Что еще может помочь от данной атаки?
Не отсечет на корню принципиальную возможность, но поможет минимизировать возможные последствия, конечно же, качественная антивирусная защита уровня узла. Под качественной имеется ввиду постоянная защита с поведенческим анализом и актуальной базой антивирусных сигнатур, а также периодические полные антивирусные проверки. При этом, антивирусы уровня узла также не являются панацеей и способы их обойти тоже существуют, хотя и не 100%-ные.
В определенной степени усилить защиту конечных точек также можно с помощью использования решений класса EDR (Endpoint Detection & Response) и песочниц.
Решения класса UEBA (User and Entity Behavior Analytics) анализируют поведение пользователей, выявляя отклонения от нормы. Решение пока довольно редкое и также требует определенных усилий по настройке паттернов, поэтому ограничение программной среды все же выглядит более простым и эффективным способом.
Выводы
Конечно, передача больших объемов данных таким способом — занятие для терпеливых, если нет жестких ограничений по времени. Но для компактного вредоноса или утечки небольшого конфиденциального документа этот метод вполне эффективен. И что самое интересное — тут не нужно искать уязвимости или писать сложный эксплойт. Все реализуется в рамках штатных возможностей информационных систем.
Корень проблемы в том, что мы привыкли воспринимать клавиатурный ввод как нечто «ручное», не представляющее угрозы, и это не нужно инспектировать или как-то ограничивать применение. Но когда он автоматизируется — будь то программно или программно-аппаратно (BadUSB) — мы получаем универсальный канал для обмена любыми цифровыми данными.
Ну а вы как думаете — это реальная угроза или паранойя? Может, кто-то уже сталкивался с атаками такого типа в реальной жизни? Предлагайте свои способы защиты и делитесь мыслями в комментариях!
