Программное средство обнаружения атак на программное обеспечение низкого уровня Navis

Тип работы:
Реферат
Предмет:
ТЕХНИЧЕСКИЕ НАУКИ


Узнать стоимость

Детальная информация о работе

Выдержка из работы

I ПРОГРАММНОЕ СРЕДСТВО ОБНАРУЖЕНИЯ АТАК НА ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ НИЗКОГО УРОВНЯ NAVIS
Куренкова Полина Юрьевна, Москва, МГТУ им. Н. Э. Баумана,
E-mail: polya. polya@yahoo. com Пургин Александр Дмитриевич, Москва, МГТУ им. Н. Э. Баумана,
E-mail: theshade111@gmail. com
Проблема атак на программное обеспечение низкого уровня становится все более актуальной в последние годы. В работе представлено проектирование эффективной системы обнаружения, названной NAVIS (Network Adapter Veri cation and Integrity checking Solution). Выдвинуто предположение, что в зависимости от архитектуры адаптера и интерфейса сетевой платы, возможно построить систему, защищающую от атак подобного рода.
Ключевые слова: Микропрограмма, сетевая плата, сетевой адаптер.
THE SOFTWARE TOOL I TO DETECT ATTACKS ON I SOFTWARE PROVIDING LOW NAVIS I
Polina Kurenkova, Moscow, Bauman MSTU, E-mail: polya. polya@yahoo. com, Aleksandr Purgin, Moscow, Bauman MSTU, E-mail: theshade111@gmail. com
The problem of attacks on software low level is becoming increasingly important in recent years is shown. In this work the design of an effective detection system, called NAVIS (network adapter verification and integrity checking solution). It is suggested that, depending on the architecture and the interface adapter network card may build a system which protects from attacks of this kind.
Keywords: firmware, NIC, network adapter.
По мнению зарубежных авторов одной из важных задач является обнаружение вредоносных нарушений прошивки сетевого адаптера во время выполнения в операционной системе [1]. При этом предполагается, что операционная система является доверенной (т.е. что ее функционирование не может быть нарушено). Также считается, что прошивка не будет нарушена в начальном состоянии системы, то есть, должны быть проверена целостность микропрограммы контроллера при запуске системы. Эти два предположения являются исходными, учитывая стандартные механизмы, которыми оборудованы текущие компьютеры.
NAVIS использует три взаимодополняющих эвристических метода обнаружения для поиска искажений прошивки сетевого контроллера. Первые два направ-
лены на обеспечение соблюдения ограничения доступа к областям памяти. Третий используется для обнаружения возможных нарушений целостности потока управления и использует скрытый стек возвратов (shadow return call). Во время инициализации NAVIS записывает эталонную модель прошивки, которая служит в качестве основы для последующих проверок.
Пошаговая адресная проверка. Основанная на модели разметки памяти, NAVIS проверяет соответствие указателя инструкций на каждом этапе выполнения. Если код указателя инструкций указывает на область памяти, которая соответствует куче, стеку или блокноту, то, вероятно произошла внедряемая атака, сопровождаемая управлением перенаправления потоков.
Пошаговое сравнение. В дополнение к предыдущей поверке NAVIS также проверяет, имелось ли совпадение между инструкцией, которая должна быть запущена центральным процессором и тем, что должно быть запущено в соответствии с эталонной моделью. Несоответствие свидетельствует о внедрения кода в памяти NIC, и в этом случае NIC останавливается.
Скрытый стек. Для обнаружения вредоносного изменения потока, сохраняется упрощенная копия стека вызовов программного обеспечения на проверяющей стороне, называемой скрытым стеком. Скрытый стек вызовов используется для проверки того, что именно при вызове функции возвращается к месту вызова. Скрытый стек вызовов должен быть сохранен в защищенной памяти, так чтобы злоумышленник не смог изменить его.
Скрытый стек обновляется каждый раз, когда команды вызова (CALL) и возврата^Л выполняется на программном обеспечении следующим образом:
— на инструкции вызова, адрес возврата помещается в скрытый стек-
— на инструкции RET адрес возврата сопоставляется с той, которая была ранее сохранена на скрытый стек, разница между двумя адресами является признаком аномалии.
Еще один способ обнаружить внедренный код состоит в сканировании памяти в поисках того, чье статистическое распределение совпадает с исполняемым кодом в области памяти, который, как предполагается, содержит только данные (куча, стек и электронный блокнот). Такие места данных используются для хранения пакетов локальных сетей, и нет никаких причин, почему данные, хранящиеся там, должны соответствовать статистическому профилю двоичных инструкций.
Разработка NAVIS осуществлялось с применением сетевого адаптера Broadcom NetXtreme. Распределение памяти описано в документации на сетевой адаптер (Broadcom. Inc). Доступ к внутренней памяти достигается за счет использования окна памяти, который обеспечивает прямой доступ к прошивке, работающей на адаптере. Согласно карте памяти, известно, где именно процессор считывает и записывает данные.
Пошаговая адресная проверка. Простая, но весьма специфическая. Анализ должен был сделан заранее для каждой модели NIC и каждой версии прошивки.
Первый эвристический метод проверяет счетчик команд в пределах кода. Записанный в модель, он определяет некоторые области, где код, как ожидается, будет расположен, и выполнение кода за пределами этих районов ЦП свидетельствует об атаке. Эта проверка является более сложной в реализации, чем следующая, потому что не удается найти уникальный код зоны на этой модели конкретных карт и комбинации версии прошивки. Таким образом, разная проверка должна быть сделана, потому что есть одна главная область и несколько
Программное средство обнаружения атак…
подобластей. Неполная модель (то есть, та, которая не распространяется на целые диапазоны операций анализируемой прошивки) может привести к ложным срабатываниям и ложным негативам.
Пошаговое сравнение. Второй эвристический метод сравнивает содержание области памяти, указывающей на счетчик программы (который является адресом следующей инструкции для выполнения) и сравнивает его с записанной эталонной моделью. Несоответствие между ними показывает, что код был переписан и что нападение продолжается (так как мы предполагаем, что код не является самомодифицирующимся). В этом случае, контролирующее устройство останавливает встроенный процессор.
Реализация скрытого стека. Поддержание скрытого стека на хосте является сложным, потому что мы должны определить вызовы функций
В случае если, прошивки, которые контролируются, довольно простые, то:
— вызов функций осуществляется через инструкции JAL-
— нет указателей на функции. JAL всегда выполняются на абсолютных значениях-
— возвращение из функций осуществляются через JR 31.
В теории, размещение функций вызовов и возвратов (CALL и RET) не сложно. Тем не менее, необходимо управлять прерываниями, которые могут быть вызваны в сетевых адаптерах асинхронно. Некоторые из них могут быть предсказаны (глядя на регистры состояния процессора MIPS), но трудно предсказать точный цикл процессора, когда прерывание будет вызвано. Прерывание может привести к неожиданным изменениям в потоке управления сетевого адаптера и может отменить инструкции (из-за слота задержки MIPS). Поэтому каждый раз, когда система обнаруживает прерывание, проверяется последняя команда, которая должна была быть запущена входящим вызовом или инструкцией RET.
Для эксперимента использовался ноутбук Dell D530 использующий адаптер 5755M Broadcom NetXtremе, который работает на прошивке, уязвимой для различных видов атак, представленных в [8]. Ноутбук работает под управлением Debian Squeeze с системой обнаружения NAVIS.
В условиях первого эксперимента, целевой ПК напрямую подключен к интернету через адаптер, который контролируется. Вручную можно имитировать стандартные действия пользователя (загрузки FTP, веб-браузер и т. д.). В то же время, разрешается процессу доступ к веб-ресурсам. Во втором эксперименте непосредственно адаптер подключается к компьютеру, имитирующему отправку злоумышленником пакетов атаки, которые будут пытаться использовать уязвимости в адаптере. Три различных типа полезной нагрузки используются для экспериментов.
В первом эксперименте, ни один из пакетов, связанных с регулярным трафиком не вызвал никаких предупреждений от NAVIS. Напротив, все три различные виды атак с использованием ASF трафика были успешно обнаружены NAVIS.
Ожидалось, что система обнаружения резко снизит производительность машины, которая контролировалась. Поэтому тест проводится в двух частях, первая на стандартной установке и с запущенной NAVIS.
Когда скорость передачи пакетов поднимаются, программные прерывания от системных вызовов начинают становиться значительным. Генератор пакетов не в состоянии генерировать больше трафика, но вполне вероятно, что NAVIS может обрабатывать больше пакетов перед замедлением движения.
Производительность может быть снижена если есть прошивка, которой необходимо обрабатывать каждый из сетевых пакетов.
Литература (References)
1. Abadi, M., Budiu, M., Erlingsson, U'- ., Ligatti, J.: Control-flow integrity principles, implementations, and applications. ACM Transactions on Information and System Security 13 (November 2009)
2. Castelluccia, C., Francillon, A., Perito, D., Soriente, C.: On the difficulty of software-based attestation of embedded devices. In: Proceedings of 16th ACM Conference on Computer and Communications Security (November 2009)
3. Duflot, L., Perez, Y. -A.: Can you still trust your network card?. In: CanSecWest (2010)
4. Francillon, A.: Attacking an Protecting Constrained Embedded Systems from Control Flow Attacks. PhD thesis, Institut Polytechnique de Grenoble (2009)
5. Francillon, A., Castelluccia, C., Perito, D., Soriente, C.: Comments on refutation of on the difficulty of software based attestation of embedded devices (2010)
6. Li, Y., McCune, J.M., Perrig, A.: SBAP: Software-Based Attestation for Peripherals. In: Acquisti, A., Smith, S.W., Sadeghi, A. -R. (eds.) TRUST 2010. LNCS, vol. 6101, pp. 16−29. Springer, Heidelberg (2010)
7. Perrig, A., Van Doorn, L.: Refutation of on the difficulty of software based attestation of embedded devices (2010)
8. Petroni Jr., N.L., Fraser, T., Molina, J., Arbaugh, W.A.: Copilot — a coprocessor based kernel runtime integrity monitor. In: Proceedings of the 13th USENIX Security Symposium, pp. 179 194 (2004)
9. Rutkowska, J., Wojtczuk, R.: Preventing and detecting xen hypervisor subversions. In: BlackHat (2008)
10. Wang, J., Stavrou, A., Ghosh, A.: Hypercheck: a hardware-assisted integrity monitor. In: Jha, S., Sommer, R., Kreibich, C. (eds.) RAID 2010. LNCS, vol. 6307, pp. 158−177. Springer, Heidelberg (2010)

ПоказатьСвернуть
Заполнить форму текущей работой