CC BY
36i-methods
ИНФОРМАТИКА, ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА И УПРАВЛЕНИЕ
том 12. № 3. 2020 http://intech-spb.com/i-methods/
Проблема обезвреживания руткитов уровня ядра в системах специального назначения
Кирилова Ксения Сергеевна
студент магистратуры Санкт-Петербургского государственного университета телекоммуникаций им. проф. М. А. Бонч-Бруевича, г. Санкт-Петербург, Россия, ksen98@hotmail.com
Цветков Александр Юрьевич
старший преподаватель Санкт-Петербургского государственного университета телекоммуникаций им. проф. М. А. Бонч-Бруевича, г. Санкт-Петербург, Россия, alexander.tsvetkov89@gmail.com
Волкогонов Владимир Никитич
к.т.н., доцент Санкт-Петербургского государственного университета телекоммуникаций им. проф. М. А. Бонч-Бруевича, г. Санкт-Петербург, Россия, vladimir.volkogonov@gmail.com
АННОТАЦИЯ_________________________________________________________
С развитием и распространением информационных технологий нельзя не заметить, что вместе с ними стремительно развиваются и сопутствующие им угрозы. К примеру, с вредоносными программами часто сталкиваются и пользователи, и администраторы компьютерных систем, и чем более защищёнными становятся системы, тем искуснее становятся разработчики вредоносного программного обеспечения и методология атак. Вредоносные программы типа руткит уровня ядра для систем специального назначения Российской Федерации, часто реализованные в виде загружаемого модуля ядра операционной системы, являются актуальной на сей день угрозой, позволяющей атакующему закрепить свой доступ ко взломанной системе. Руткиты, работающие на уровне ядра, по сравнению с прикладными программами имеют некоторые особенности и ключевые различия, на которые обращено внимание: почему такие руткиты намного сложнее обнаружить непосредственно на атакованной машине, как они закрепляются в системе, в какой момент становятся активны. Рассматривается, как построено взаимодействие пользовательских приложений с операционной системой и каким образом она обрабатывает их запросы. На основе этого объяснено преимущество (для атакующего) в использовании механизма модулей ядра для создания руткитов перед руткитами пользовательского пространства. Приведены примеры некоторых аспектов работы двух известных руткитов уровня ядра операционной системы последнего десятилетия. Сформулирована проблема обнаружения системного файла, при помощи которого вредоносный модуль закрепляется в системе, решение которой позволяет предотвратить обнаружить руткит и обезвредить его на атакованной машине. Приведены варианты решений этой проблемы, а также указано направление дальнейших возможных исследований по теме.
КЛЮЧЕВЫЕ СЛОВА: linux; загружаемые модули ядра; вредоносные программы; руткиты; эскалация привилегий.
Введение
Руткит (англ. Rootkit) — разновидность вредоносных программ, позволяющих злоумышленнику незаметно возвращаться во взломанную систему. Это понятие появилось в мире UNIX, где оно означает набор утилит или специальный модуль ядра, которые атакующий устанавливает на взломанной им компьютерной системе сразу после получения прав суперпользователя (корневого пользователя).
Главное отличие руткита от прочих вредоносных программ — акцент на незаметное для пользователя и администратора присутствие в системе. Для этого руткиты могут хранить свои файлы в системных папках, где и без того много файлов, и их будет сложно обнаружить. Более изощрённые руткиты способны скрывать процессы, активные сетевые соединения, файлы в файловой системе и фальсифицировать их содержимое [1].
Традиционно по уровню привилегий в компьютерной системе разделяют два вида рут-китов: уровня пользователя и уровня ядра. Первые появились в конце 80-х годов. Они на настоящий момент уже хорошо изучены, и разработано множество утилит для их нахождения и удаления их из системы (среди них, например, chrootkit, rkhunter) [2, 3].
В связи с этим больший интерес для изучения представляют руткиты, работающие в режиме ядра, как более серьёзная угроза. В операционных системах (ОС) они, как правило, реализуются в виде драйверов модулей ядра. Для понимания специфики их работы необходимо рассмотреть особенности работы кода ядра, не свойственные пользовательским приложениям.
Особенности и привилегии режима ядра
Операционные системы обычно имеют свою иерархическую структуру, логические уровни управления. Эта иерархия восходит к архитектуре процессоров [4, с. 381]. На практике часто используются только два уровня: нулевой и третий, привилегированный режим и режим пользователя соответственно (рис. 1).
Рис. 1. Уровни (кольца) привилегий
Программы более высокого логического уровня активно используют программы нижележащих уровней, поскольку сами не обладают достаточными правами для совершения некоторых операций. Например, пользовательские приложения не имеют привилегий даже для простого чтения файла или записи в него. Им доступно лишь подмножество всех команд процессора, тогда как код, выполняющийся в нулевом кольце защиты, может использовать все имеющиеся в машине инструкции.
Операционная система, как любая программа режима ядра, обладает максимальными привилегиями и выполняется в кольце 0. Пользовательские приложения, работающие в кольце 3, получают доступ к функциям ОС только посредством системных вызовов (англ. зуБваН). Они, в свою очередь, вызывают функции-обработчики на уровне ядра, которые непосредственно отвечают за работу с оборудованием (рис. 2) [5].
Рис. 2. Цепочка вызовов при чтении файла из пользовательского приложения
Контроль и разграничение доступа пользователей к имеющимся ресурсам машины осуществляется операционной системой при выполнении системных вызовов. Таким образом, когда пользователь А пытается прочесть файл, доступный только пользователю Б, ОС выполнит необходимые проверки и сообщит о недопустимости действия приложению пользователя ошибкой вида «Отказано в доступе». Многие из ограничений доступа не распространяются на суперпользователя; но программ, выполняющихся на уровне ядра, они не касаются совсем. Для программ уровня ядра нет подобных механизмов разграничения прав доступа.
В Linux-системах, на основе которых построены некоторые ОС специального назначения, ядро ОС считается монолитным, но его функционал можно расширять с помощью загружаемых модулей ядра (LKM, Loadable Kernel Module) [6]. Код таких модулей при загрузке встраивается в память ядра и работает как его часть. Механизм LKM являются привлекатель-
ным средством для создания руткитов, поскольку, как сказано ранее, предоставляет все доступные в машине низкоуровневые функции, с помощью чего можно эффективно скрываться в атакованной системе с обходом всех системных механизмов контроля доступа. Кроме того, такие руткиты не выполняются в отдельном процессе, потому как являются частью большого сложно структурированного ядра, что затрудняет их обнаружение. Как следствие, противодействовать руткитам уровня ядра следует с помощью другой программы, работающей также в режиме ядра [7].
Заражение системы и закрепление вредоносных модулей
Для того, чтобы руткит уровня ядра, реализованный в виде вредоносного загружаемого модуля, оказался хотя бы запущен, необходимы права суперпользователя. Злоумышленник может получить их с помощью уязвимости в одной из программ, работающих с его правами [8]. Вопрос эскалации привилегий через уязвимости в данной статье не рассматривается, так как об этом уже есть много разнообразных материалов1.
Запустившись, руткит должен закрепиться в системе, чтобы после перезагрузки остаться активным. Для этого он модифицирует один из файлов или скриптов автозагрузки. В зависимости от ОС и от самого руткита это может быть файл, содержащий команды к выполнению при старте операционной системы, файл со списком загружаемых модулей, которые необходимо запустить для дальнейшей корректной работы ОС, и другие файлы с информацией о программах, модулях и командах, которые должны быть исполнены в процессе загрузки системы.
При этом факт изменения этих файлов руткиты, как и положено им, тщательно скрывают. Известные LKM-руткиты (под известностью понимается то, что они оказались за пределами машин, на которых были написаны, и ныне опубликованы в сети Интернет. Среди них Adore, Knark, Snakso, Reptile) для этого перехватывают (англ. hooking) системную функцию чтения файлов и изменяют её поведение так, что результат чтения «инфицированного» файла автозагрузки будет говорить, что файл не содержит данных, отвечающих за загрузку вредоносного модуля, хотя на самом деле это не так [7].
Когда руткит уровня ядра перехватывает системный вызов, то фиктивный результат прочтения файла получают лишь программы, выполняющиеся в пользовательском режиме, потому что функции ядра остаются не тронутыми и работают в штатном режиме. То есть, в таком случае файл может быть достоверно прочитан средствами ядра. Однако руткит, выполняющийся в ядре, обладает достаточным правами и для перехвата внутренних функций ядра, недоступных пользовательским приложениям — тех самых функций, которые отвечают за обработку системных вызовов на более низком уровне. Эти функции, помимо прочего, используются и самим ядром. Это означает, что не только приложения пользователя, но и ядро в итоге будет получать неверные данные о содержимом файла.
Все действия по маскировке истинного содержимого происходят на уровне операционной системы. Как только вредоносный модуль загружается вместе со стартом системы, маскировка данных начинает работать, и не только для процессов пользователя. Теперь, если ядро обратится любому из модифицированных руткитом файлов, то оно, как и любая другая программа в системе, получит результат, необходимый руткиту: файл якобы чист.
'Например, этому посвящена целая книга «Хакинг. Искусство эксплойта» авторства Дж. Эриксона
Проблема нахождения файлов, содержащих данные, скрытые руткитом
Из сказанного ранее следует, что за запуск вредоносного модуля отвечает один из системных файлов, управляющих загрузкой операционной системы. Знание того, какой именно файл подвергся модификации, может помочь предотвратить очередной запуск руткита после рестарта системы, таким образом обезвредив её.
Для того, чтобы вредоносный модуль не был загружен, необходимо восстановить состояние модифицированного файла до закрепления руткита в системе. Один из способов это сделать — хранить в безопасном месте его запасную копию, чтобы в случае необходимости поместить её вместо «заражённого» файла.
Однако самая главная проблема при этом — понять, какой именно файл был использован руткитом для закрепления в системе. Это знание может позволить не только вылечить заражённую систему, но и понять, что за руткит её поразил, и возможно, как он в систему попал и получил к ней доступ, что крайне полезно при расследовании инцидентов безопасности.
Очевидно, что в худшем случае необходим перебор всех файлов, задействованных при старте ОС, которые так или иначе могут отвечать за загрузку дополнительных программ и модулей: файл автозагрузки модулей, драйверов, файлы команд для выполнения на различных этапах загрузки ОС, загрузочные сценарии. Также нахождение файла, модифицированного руткитом, затруднено из-за осуществляемой руткитом маскировки его истинного содержимого.
В случае, если руткит перехватывает и фальсифицирует результат выполнения только системных вызовов, то можно использовать программу, которая работала бы в режиме ядра, для получения действительного содержимого подозрительного файла, и дальнейшего сравнения этого содержимого с тем, что видно на уровне пользователя. Это будет работать, ведь системные вызовы ещё находятся в пространстве пользователя. Использование системных вызовов внутри ядра пресекается, потому что они должны служить исключительно интерфейсом между приложениями и ядром [5, 9]. Таким образом, функции внутри ядра будут возвращать достоверный результат, отличный от результата системного вызова.
Если же руткит перехватывает функции самого ядра, то обнаружить недостоверность сведений, работая непосредственно на заражённой машине, становится намного сложнее: нет ни одного механизма ОС, на который можно полагаться безоговорочно [10]. Тем не менее, даже для такой ситуации в результате исследования были обнаружены несколько вариантов поиска.
Первый заключается в поиске модифицированного файла на этапе загрузки ОС, где модули ядра ещё не работают. Всего этапов можно выделить 3:
• работает загрузчик ОС. Операционная система ещё не находится в памяти;
• начальная загрузка—загрузка минимального базового функционала ОС, необходимого для выполнения третьего этапа;
• загрузка модулей ОС, необходимых для полноценной работы пользователя.
На последнем этапе выполняется загрузка модулей ядра, то есть вредоносный модуль становится активен именно на этом шаге. Значит, что осуществлять поиск следов руткита нужно до этого.
На первом этапе это можно сделать из командного режима загрузчика ОС. Такой способ не очень удобен, так как не представляет привычный интерфейс пользователя и ограничен
в возможностях. Выполнение поиска на втором этапе загрузки ОС более удобно. В ОС, как правило, есть модуль начальной загрузки ОС, имеющий необходимый базовый функционал, более богатый, чем на первом шаге загрузки.
Второй — поиск файла со сторонней машины. Он подразумевает изучение содержимого дискового накопителя, на котором хранятся файлы заражённой ОС, на другом не атакованном компьютере.
Третий способ подразумевает контроль целостности файлов, задействованных при загрузке ОС. Он отличается от предыдущих тем, что некоторые действия должны быть осуществлены ещё до заражения системы. Для данного метода можно было бы использовать механизм контрольных сумм на основе однонаправленных хеш-функций2, потому что любое изменение файла должно привести к её изменению. Руткит, тем не менее, после модификации файла может пересчитать и подменить предыдущую контрольную сумму, и при этом нет возможности убедиться в том, была ли совершена подмена. Чтобы этого избежать, можно воспользоваться электронной цифровой подписью (ЭЦП) файлов3, однако недостаток этого способа заключается в усложнении системы. Кроме того, необходимо проработать протокол проверки целостности файла. Программы пользователя рассчитывают контрольную сумму на основе тех данных, которые они получают от ОС. Когда руткит применяет маскировку действительного содержимого файлов, информация, которую получит пользователь о модифицированном файле, ничем не будет отличаться от таковой до заражения руткитом. Иными словами, на уровне пользователя файл останется прежним, и его контрольная сумма — тоже. То же верно и для ЭЦП. То есть, при использовании данного способа необходима как минимум программа уровня ядра. Также необходимо помнить о возможности криптографических атак и подделки контрольных сумм и ЭЦП [11].
Заключение
Руткиты уровня ядра, появившиеся в конце 90х — начале 2000-х, являются по сей день актуальной угрозой для систем специального назначения, построенных на базе операционных систем семейства Linux, которой нельзя избежать в силу особенностей дизайна самой этой ОС. Загружаемые модули ядра являются неотъемлемой частью этих систем. Хотя использования модулей и можно избежать, они широко используются, поскольку предоставляют большую гибкость в поддержке различных устройств и экономию памяти, чем при непосредственном включении в исполняемый файл ядра.
В ходе исследования было выделено несколько вариантов обнаружения заражения рут-китами уровня ядра. Все они сводятся к поиску файла, модифицированного руткитом для закрепления в системе.
Поиск на уровне загрузчика ОС и на уровне начальной загрузки ОС позволяют осуществить поиск в системе, где вредоносный модуль ещё не загружен в память, и любые применяемые им способы маскировки содержимого файлов не будут работать.
2Алгоритмы и способы реализации данного механизма можно найти в книге Брюса Шнайера «Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си».
3Подробнее об ЭЦП можно прочесть в статье на сайте ныне электронного журнала Хакер «Гайд по криптографии: что такое электронная цифровая подпись и как она работает», URL: https://xakep.ru/2016/12/15/crypto-part5/
На третьем этапе загрузки, когда ОС загрузилась целиком, обнаружение затруднено в силу того, что руткит также находится в памяти и осуществляет необходимые операции для скрытия своих следов в системе.
Последний вариант поиска — поиск руткита со сторонней не инфицированной системы. Он не всегда приемлем, так как при этом необходимо вынимать дисковый накопитель и подключать его к другой машине, но, тем не менее, эффективен.
Литература
1. r00tkit Analysis: What Is A Rootkit? // VnutZ Domain. 2005. URL: http://www.vnutz.com/ articles/r00tkit_Analysis_What_Is_A_Rootkit (дата обращения 13.09.2019).
2. Siles R. Linux kernel rootkits: protecting the system's "Ring-Zero" // GIAC Unix Security Administrator. SANS Institute, 2004. 168 p. URL: https://www.giac.org/paper/gcux/243/linux-kernel-rootkits-protecting-systems-ring-zero/105411 (дата обращения 15.09.2019).
3. Miller T. Analysis of the t0rn rootkit // Symantec corp. 2000. URL: https://www.symantec. com/connect/articles/analysis-t0rn-rootkit (дата обращения 17.09.2019).
4. Таненбаум Э., Остин Т. Архитектура компьютера: пер. с англ. 6-е изд. СПб.: Питер, 2019. 816 с.
5. Цилюрик О. Разработка модулей ядра Linux. Часть 4. Ядро и модуль // IBM Developers Россия. Технические материалы. 2012. URL: https://www.ibm.com/developerworks/ru/ library/l-linux_kernel_04/ (дата обращения 17.09.2019).
6. Таненбаум Э., Бос Х. Современные операционные системы. 4-е изд. СПб.: Питер, 2015. 1120 с.
7. Руткиты новой волны // Хакер. 2002. URL: https://xakep.ru/2002/05/20/15281/ (дата обращения 17.09.2019)
8. Расширение локальных привилегий в Linux при помощи эксплоита для ядра // SecurityLab, Positive Technologies. 2018. URL: https://www.securitylab.ru/analytics/496756.php (дата обращения 17.09.2019)
9. Цилюрик О. Практикум: модули ядра Linux. Конспект с примерами и упражнения с задачами. URL: https://losst.ru/wp-content/uploads/2016/08/B00K_PRACTIS_245.pdf (дата обращения 17.09.2019)
10. Love R. Linux Kernel Development. 3rd ed. Novell Press by Pearson Education, Inc., 2010. 496 p.
11. Sanjar Satsura. Легкий способ подделки контрольной суммы и ЭЦП с помощью коллизий // Хакер. 2012. URL: https://xakep.ru/2012/11/22/light-fake-checksum/ (дата обращения 19.09.2019)
THE PROBLEM OF KERNEL-MODE ROOTKITS DISPOSAL ON SPECIAL PURPOSE SYSTEMS
KSENIA S. KIRILOVA
master student of the St. Petersburg State University of Telecommunications, St-Petersburg, Russia, ksen98@hotmail.com
ALEXANDER Y. TSVETKOV,
Senior Lecturer of the St. Petersburg State University of Telecommunications, St-Petersburg, Russia, alexander.tsvetkov89@gmail.com
VLADIMIR N. VOLKOGONOV,
PhD, Доцент of the St. Petersburg State University of Telecommunications, St-Petersburg, Russia, vladimir.volkogonov@gmail.com
ABSTRACT
With information technologies spreading and evolving it is hard not to notice the evolution of related threats. For example, both administrators and users of computer systems often face malicious software. More secure those systems become, more skilled become so-called virus writers and attacks methodology. Malicious programs such as kernel-mode rootkits for Linux operating systems, often implemented as a loadable kernel module, stay a threat relevant to this day, allowing an intruder to ensure his further access to the compromised system. Compared to user-mode rootkits, kernel-mode ones have their peculiarities and key differences that also are to be considered: why these rootkits are much harder to detect directly on an attacked machine, how they get reboot persistence, at what moment they become active. There is shown how the interaction of user applications and operating system is designed and how the latter processes their requests. Based on this, the advantage of using loadable kernel modules to build kernel-mode rootkits in comparison to userland ones is explained. The examples of some aspects of execution of known last-decade Linux kernel-mode rootkits are given. The problem of finding the system file that rootkits use to gain boot persistence is worded. The solution of this problem lets one to prevent rootkit from launching thus curing the hacked machine. Possible solution of this problem are listed, as well as possible directions of future researches.
Keywords: linux; loadable kernel modules; malware; rootkits; privilege escalation.
REFERENCES
1. Berheev M. M., Zalyaev I.A., Kozhevnikov Yu.V. Osnovysistem avtomatizirovannogoproektirovaniya [Bases of systems of the automated design]. Kazan: Kazan university Publ., 1988. 253 p. (In Rus)
2. Gracianova T.Yu., Mal'kovskij M.G., Polyakova I.N. Prikladnoe programmnoe obespechenie: sistemy avtomaticheskoj obrabotki tekstov [Applied software: systems of automatic processing of texts]. URL: https://www.lux.e-reading.bz/ book.php?book=17901 (date of access 10.09.2019). (In Rus)
3. Greenberg I., Garber L. Searching for new search technologies. IEEE Computer. 1999. Vol. 32. Pp. 4-11.
4. Potapova R.K. Lingvisticheskie znaniya i novye tehnologii (k resheniyu nekotoryh prakticheskih zadach special'nogo naz-nacheniya) [Linguistic knowledge and new technologies (regarding some practical tasks of special purpose)]. 2002. URL: http://www.dialog-21.ru/digest/2002/articles/potapova (date of access 10.09.2019) (In Rus)
5. Potapova R.K. Vvedenie vlingvokibernetiku [Vvedenie v lingvokibernetiku]. Moscow: MGLU Publ., 1990. 140 p. (In Rus)
6. Titorenko G.A. (Ed.) Avtomatizirovannye informacionnye tehnologii v 'ekonomike [The automated information technologies in economy]. Moscow: UNITI Publ., 2003. 399 p.
7. Vorojskij F.S. Informatika. 'Enciklopedicheskij sistematizirovannyj slovar'-spravochnik: vvedenie v sovremennye informacionnye i telekommunikacionnye tehnologii v terminah i faktah [Informatics. The encyclopedic systematized dictionary reference: introduction in modern information and telecommunication technologies in terms and the facts]. 2008. URL: http://elib.ict.nsc.ru/jspui/bitstream/ICT/1066/3/voro.pdf (date of access 10.09.2019) (In Rus)
8. Softcatalog. URL: http://softcatalog.info/ru/obzor/programmy-dlya-raspoznavaniya-teksta (date of access 10.09.2019) (In Rus)
9. Infokommunikacii. Vvedenie [Infokommunikatsy. Introduction]. Yazykiprogrammirovaniya [Programming languages]. URL: https://life-prog.ru/1_32049_infokommunikatsii-vvedenie.html (date of access 10.09.2019) (In Rus)
