Время прочтения: 9 мин.
Вступление
Летом 2010 года в системах иранского завода по обогащению урана в Натанзе был обнаружен вирус Stuxnet. Вирус Stuxnet по размерам был очень мал и никак себя не проявлял до тех пор, пока не обнаруживал автоматизированные системы. Вирус заразил компьютер, который управлял центрифугами ядерных реакторов, перехватывая управление и меняя режим работы центрифуг. В итоге центрифуги работали в критическом режиме: то быстро разгонялись, то резко останавливались, из-за чего стали быстро выходить из строя. При этом операторы, следящие за работой реакторов, находились в полном неведении и ничего не знали о некорректном поведении центрифуг, т.к. вирус Stuxnet подменял значения показателей датчиков. Расследование не дало однозначного ответа — как вирус проник в закрытую сеть завода. Специалисты по кибербезопасности предположили, что вирус был занесен с помощью USB-носителя людьми из компаний-компаньонов. А если это так, то компьютеры этих компаний либо были заражены и заразили сеть иранского завода непреднамеренно, либо их заразил кто-то из специалистов намеренно (расследование это умалчивает). Проанализировав Stuxnet, специалисты заявили, что вирус был написан не хакером-любителем, а настоящими профессионалами. Разработчики вируса должны были располагать данными о цели, которую предстоит атаковать, и иметь ресурсы, характерные не для сетевых хулиганов, а для спецслужб. Вирус показал себя не просто как шалость теневых хулиганов, которые хотят украсть данные/фото/деньги, а настоящей «боевой программой», которая может нанести физический урон предприятию.
Эта, нашумевшая в свое время, история послужила хорошим уроком для всего мира и дала толчок на разработку серьезных мер кибербезопасности на многих предприятиях, которые смогли бы предотвратить подобные инциденты, особенно на стратегических объектах стран. Однако, есть источники взлома систем гораздо опаснее, нежели вирусы. Антивирусы или правила безопасности могут не сработать в борьбе с таким видом источника взлома, как бэкдор. Этой теме я и хочу посвятить свой пост.
2 апреля 2021 года была обнаружена атака на Российский НИИ. В ходе расследования было обнаружено, что первый взлом был осуществлён ранее: осенью в 2017 году с помощью «BackDoor.Farfli.130». После чего были внедрены «Trojan.Mirage.12» и «BackDoor.Siggen2.3268». А в апреле 2019 была заражена сеть другого Российского НИИ. В то же время на государственный сектор ряда стран центральной Азии была целенаправленная атака с использованием «DNS-бэкдор BackDoor.DNSep.1».
Примеры бэкдоров
Бэкдор, тайный вход (от англ. back door – «чёрный ход», буквально «задняя дверь») – дефект алгоритма, который намеренно встраивается в него разработчиком и позволяет получить несанкционированный доступ к данным или удалённому управлению операционной системой и компьютером в целом (Источник: Википедия).
Иными словами, бэкдоры – это скрытые механизмы, которые злоумышленники используют для доступа к системе без аутентификации. Однако поставщики ПО иногда создают бэкдоры в законных целях, например, для восстановления утерянного пароля пользователя или предоставления государственным органам доступа к зашифрованным данным. Как правило, такие бэкдоры не обнаруживаются антивирусами. Единственный способ его обнаружить – это хорошо разбираться в программном коде и отредактировать его вручную, а это очень трудозатратно. Хорошо, если код бэкдора находится в открытом виде. А если код откомпилирован в dll, exe или закодирован?
Как, например, бэкдор созданный в PHP WordPress:
WordPress – это распространенная и популярная система управления содержимым сайта. В сети существует множество сайтов, созданных на этой платформе. Но, вернемся к бэкдору.
Чтобы скрыть бэкдор, разработчики подвергли исходный код обфускации юникодом.
Обфускация (от лат. obfuscare — затенять, затемнять; и англ. obfuscate — делать неочевидным, запутанным, сбивать с толку) — это запутывание кода — приведение исходного кода или исполняемого кода программы к виду, сохраняющему её функциональность, но затрудняющему анализ, понимание алгоритмов работы и модификацию при декомпиляции.
Бэкдор внедрялся в основные файлы WordPress:
- ./wp-admin/network/network/index.php
- ./wp-includes/js/tinymce/themes/themes/index.php
- ./wp-admin/css/colors/coffee/coffee/index.php
- ./wp-admin/css/colors/blue/blue/index.php
- ./wp-admin/css/colors/ectoplasm/ectoplasm/index.php
- ./wp-includes/js/tinymce/utils/utils/index.php
- ./wp-admin/css/colors/midnight/midnight/index.php
- ./wp-admin/js/js/index.php
- ./wp-includes/blocks/gallery/gallery/index.php
- ./wp-includes/blocks/post-title/post-title/index.php
- ./wp-includes/blocks/page-list/page-list/index.php
- ./wp-includes/js/dist/dist/index.php
Также скрытый код встречался и в других файлах платформы:
- ./licenses/licenses/licenses/licenses/index.php
- ./licenses/licenses/licenses/index.php
- ./tmp/tmp/tmp/tmp/tmp/tmp/index.php
- ./tmp/tmp/tmp/tmp/index.php
- ./tmp/tmp/tmp/index.php
- ./wp-content/plugins/wordpress-seo/vendor/vendor/index.php
- ./wp-content/themes/astra/inc/builder/type/base/dynamic-css/widget/widget/index.php
Разработчики умело скрыли код. В каждом файле были созданы похожие функции, которые производили одинаковые действия. Когда код был обфусцирован, то набор символов получился в каждом файле уникальный, что усложняло поиск бэкдоров. Более того, в некоторых файлах бОльшая часть символов была закомментирована и, казалось, что это просто какой-то не удалённый мусор. Как оказалось, закомментированный код был написан умышленно, чтобы сбить с толку тех, кто пытался расшифровать, что он на самом деле делает.
Если удалить юникод и отформатировать php-код, то можно увидеть исходный код бэкдора, который удаленно выполняет команды php:
Непонятный контент функции:
После деобфускации кода, в массиве видно много подозрительных строк:
После приведения кода в исходное состояние выяснилось, что данный бэкдор может выполнить код, переданный как запрос cookie, или извлечь зашифрованный удаленный URL из параметра GET массива «ARRAY» и получить исполняемый код с удаленного сервера.
Примеры таких удаленных URL:
- hxxp://460rk.riseet[.]cfd/?lc=shell_shao_bing_yunxing_php….
- hxxp://468vu.rightry[.]онлайн/?lc=xiadan_rand_path….
- hxxp://450ws.ideaive[.]sbs/?lc=shao_bing_ruzhu
Пример результата, полученного с одного из удаленных URL:
Если расшифровать этот большой фрагмент в нижней части приведенного кода, то в итоге оказывается вредоносный код .htaccess (файл дополнительной конфигурации веб-сервера Apache, а также подобных ему серверов, который позволяет вносить настройки такие как: разрешать/запрещать доступ к определенным IP-адресам, пользователям, перенаправлять на заданные линки по входящим адресам, исполнять заданные файлы и т.д.).
Бэкдоры встречаются не только в свободно распространяемых продуктах, но и в платных. Недавно был опубликован отчет об обнаружении бэкдоров во многих моделях материнских плат от известного производителя Gigabyte.
Речь шла про программу, которая якобы была реализована с уязвимостями по недосмотру. Уязвимость была связана с сервисом Gigabyte, известным как APP Center, который «позволяет вам легко запускать все приложения GIGABYTE, установленные в вашей системе, проверять соответствующие обновления онлайн и загружать последние версии приложений, драйверов и даже прошивку BIOS». Бэкдор находился в программе под названием GigabyteUpdateService.exe. Для установки программы GigabyteUpdateService.exe из вашего BIOS прямо в каталог %SystemRoot%\System32, Gigabyte использует встроенную функцию Windows – WPBT. После установки GigabyteUpdateService.exe запускается как утилита Windows. И даже если ваш диск «C» зашифрован с помощью Bitlocker, WPBT сохраняет исполняемый файл Windows в своих образах BIOS, загружает его в память во время процесса предварительной загрузки встроенного ПО, а затем передает Windows.
По словам Microsoft, основная цель WPBT — обеспечить сохранность критически важного программного обеспечения, даже если операционная система была изменена или переустановлена в “чистой” конфигурации. Одним из вариантов использования WPBT является включение противоугонного программного обеспечения, которое должно сохраняться в случае кражи, форматирования и переустановки устройства. […] Эта функциональность является мощной и предоставляет возможность независимым поставщикам программного обеспечения (ISV) и производителям оригинального оборудования (OEM-производителям) привязывать свои решения к устройству на неопределенный срок.
Иными словами, в вашу прошивку Gigabyte встроена определенная версия GigabyteUpdateService.exe, и даже если вы переустановите Windows, система все равно будет получать эту встроенную версию службы обновления APP Center до тех пор, пока вы не обновите прошивку.
Что же такого страшного в программе GigabyteUpdateService.exe? Программа извлекает и запускает программное обеспечение с одного из трех жестко заданных URL-адресов.
Один из трех URL использует обычный старый протокол HTTP, таким образом не обеспечивая никакой защиты. Два других URL используют протокол HTTPS с шифрованием данных, но утилита обновления не проверяет сертификат HTTPS, который сервер отправляет обратно. А это означает, что в обоих вариантах возможно заменять передаваемые файлы с помощью MitM (MitM — является методом компрометации канала связи, при котором взломщик, подключившись к каналу между контрагентами, осуществляет вмешательство в протокол передачи, удаляя или искажая информацию. Из wiki) и представить сертификат, выданный на имя сервера, проверять и подписывать с помощью центров сертификации Let’s Encrypt, DigiCert или GlobalSign. Т.е. с помощью GigabyteUpdateService.exe можно будет устанавливать и запускать вредоносные программы на ваш компьютер.
Теперь вы догадываетесь, в чем заключается опасность бэкдора? Бэкдор может присутствовать в купленном ПО (например, продуктах Microsoft, базах данных), в скаченных библиотеках для различных языков программирования, в web конструкторах. И, в большинстве случаях, они не обнаруживается антивирусами. Он может присутствовать тихонечко, не давая о себе знать много лет.
Как защититься от бэкдоров?
На просторах Интернета предлагают делать проверку антивирусами и файрволами, которые умеют отслеживать деятельность бэкдора. Однако, исходя из личного опыта, таким способом можно выявить уже известные бэкдоры, те, которые ранее были опубликованы и занесены в реестры вредоносных программ. А если бэкдор использует целевые порты и протоколы и ничего криминального, с точки зрения антивируса или файрвола, не делает, то зафиксировать его сложнее.
Также к средствам защиты от бэкдора можно отнести многофакторную аутентификацию. Многофакторную аутентификацию легко обойти, к примеру, если разработчик заранее создаст технический аккаунт для аутентификации, хотя, возможно, она ограничит доступ, если бэкдор был создан непреднамеренно.
От преднамеренных бэкдоров защититься гораздо сложнее. На мой взгляд, для защиты от умышленных бэкдоров, необходимо изменить организационные подходы мер безопасности:
- При использовании стороннего ПО или библиотек необходимо покупать ПО с открытым кодом. Создать отдел специалистов, которые смогли бы не только читать/понимать код, но и обнаруживать подозрительные его части. Возможно, в будущем делать проверку с помощью обученных машин.
- При разработке своего ПО также создавать отдел специалистов, которые перед принятием релизов смогли бы проверять код на наличие бэкдоров. Сейчас разрабатываемое ПО перед прохождением ПСИ проходит проверку безопасности и слабых мест кода. Но такая проверка недостаточна. Изучение кода на бэкдоры вручную отсутствует и код доверяется проверке на иностранных площадках, таких как CheckMarx (частная американская компания) и SonarQube (частная швейцарская компания). В современных реалиях – это риск, к тому же площадки показывают не все уязвимости и, более того, нет никакой гарантии продажи некоторых уязвимостей в даркнете.
- Инициировать внесение в УК РФ статьи за разработку и использование бэкдоров в коде, которая будет отпугивать злоумышленников. Да, у нас существует уголовная ответственность за создание и распространение вредоносных компьютерных программ, но дело в том, что бэкдор – это часть вполне нормального ПО, официального и зарегистрированного.
Я рассказала о программных и организационных методах защиты от бэкдоров. Но нужно помнить, что эти методы – не 100% защита.
Самая лучшая рекомендация по снижению риска по взлому с помощью бэкдоров, как бы это пафосно не звучало, – это создавать отечественное ПО, а не покупать иностранное. Создать свои площадки для проверки кода на уязвимость и оптимальность. В текущей политической обстановке, откровенных кибервойн, и противостояний между соревнующимися странами, лучшим решением будет создавать в рамках страны свое ПО, свои библиотеки, свои вычислительные системы и оборудование. Возможно, для нашей страны — это будет на некоторое время шаг назад… Но согласитесь, что ядерный взрыв в каком-нибудь НИИ, спровоцированный извне через уязвимости ПО, нанесет еще бОльший урон нашей стране.
В данной публикации были рассмотрены уже обнаруженные бэкдоры. А как вы понимаете: самый страшный бэкдор – это не обнаруженный бэкдор!