Как я могу проверить исполняемый файл, чтобы убедиться, что он не является вредоносным?

10

Мне было интересно, есть ли инструмент или метод для запуска исполняемого файла в изолированной среде, может быть, на виртуальной машине. Во время работы программы я хочу иметь возможность проверять приложение, т.е. видеть все, что делает исполняемый файл (доступ к файлам и сети).

Поступая так, я хочу иметь возможность проверить, является ли исполняемый файл вредоносным, т.е. выполняет операции, которые он не должен (чтение / запись в файлы, прослушивание / подключение к сетевым портам, ...).

Я не против чего-то с графическим интерфейсом.

security tools antivirus Ус
источник
2
@EliahKagan: Если я правильно понял вопрос, ОП запрашивает «a (инструмент), где я могу видеть все, что делает исполняемый файл» - представьте, можете ли вы запустить, sandbox somebinaryи воображаемая sandboxпрограмма будет записывать все файлы, somebinaryпрочитанные или записанные, все IP-адреса / порты, к которым подключены, данные переданы и т. Д. Это было бы полезно иметь, я также хотел бы знать, существует ли что-то подобное (и на самом деле, без такого инструмента наблюдать за программой, работающей на ВМ, было бы бессмысленно, поскольку не могу сказать, что он там делает в любом случае). Хороший вопрос.
Сергей
2
Соответствующий вопрос по UL.SE, который я задавал ранее: Как я могу отслеживать открытые файлы процесса в реальном времени? (не только о файлах, но и о сети) Помните, что как только вы видите, что это происходит, ущерб уже имеет место.
gertvdijk
2
Я задал вопрос по мета относительно закрытия этого вопроса: meta.askubuntu.com/questions/5871/… - Я не верю, что он должен был быть закрыт.
Сергей

Ответы:

10

это инструмент или, возможно, виртуальная машина для запуска исполняемого файла внутри него

Да, это называется виртуализация приложений .

LXC (Linux Containers) - это часто используемый инструмент для настройки этого. Это позволяет вам настроить полностью разделенную сеть для этого приложения и «помещать» ее в «виртуальную машину», почти как chroot. Это в основном в целях безопасности («тюрьма»), а не для аудита.

Я думаю, что это немного выходит за рамки вопроса, чтобы объяснить полные контейнеры LXC, а также как точно его проверить. Ниже немного о том, как начать, хотя.

Во время работы программы я хочу видеть все, что делает исполняемый файл (доступ к файлам и сети).

Это можно сделать с помощью, straceи я задал тот же вопрос по Unix и Linux:

Как там ответили , все сводится к

strace -t -e trace=open,close,read,getdents,write,connect,accept command-here

Важно: как только вы видите, что это происходит, ущерб уже произошел.

LXC контейнер приложений

Из этой статьи . Это сводится к:

  1. lxc-macvlan.conf Файл конфигурации:

    # example as found on /usr/share/doc/lxc/examples/lxc-macvlan.conf
# Container with network virtualized using the macvlan device driver
lxc.utsname = alpha
lxc.network.type = macvlan
lxc.network.flags = up
lxc.network.link = eth0 # or eth2 or any of your NICs
lxc.network.hwaddr = 4a:49:43:49:79:bd
lxc.network.ipv4 = 0.0.0.0/24

  2. Запустите это используя lxc-execute:

    sudo lxc-execute -n bash-test2 -f lxc-macvlan.conf /bin/bash

Обратите внимание, что LXC предлагает контейнеры как системного, так и прикладного типа. Вы ищете контейнеры для приложений здесь.

gertvdijk
источник
1
LXC еще не готов и в настоящее время небезопасен. Например, /sysне виртуализируется, и изменения, сделанные /sysв контейнере, вносятся /sysв хост. Делая быстрый поиск в Интернете, есть несколько статей, которые документируют, как «убежать» из контейнера. LXC будет хорошим решением проблемы, но в настоящее время это не так, и его не следует использовать в качестве инструмента безопасности.
Андреа Корбеллини
1
Между прочим, опубликованная примерная конфигурация не использует lxc.mountопции. Это означает, что файловая система всего пользователя доступна при запуске исполняемого файла.
Андреа Корбеллини
10

То, что вы ищете, это инструмент, который показывает, как программа взаимодействует с системой (точнее, с ядром). Программы взаимодействуют с системой с помощью системных вызовов. Примеры системных вызовов:

  • open - используется для открытия файла;
  • readи write- используется для чтения / записи из / в дескриптор файла;
  • connect - используется для подключения сокета к пиру;
  • много, много других (см. man syscalls).

Дело в том, что системные вызовы можно отслеживать с помощью ptrace(2). Итак, в основном, вы ищете инструменты, построенные вокруг ptrace. Одним из таких инструментов является strace(1)терминальное приложение, которое принимает команду в качестве аргумента и выдает:

  • система звонит, программа звонит;
  • аргументы, используемые для создания системных вызовов;
  • результат системных вызовов.

Выход в C-моде. Вот пример:

$ strace cat test
execve("/bin/cat", ["cat", "test"], [/* 55 vars */]) = 0
/* ... */
open("test", O_RDONLY)                 = 3
/* ... */
read(3, "hello\n", 32768)               = 6
write(1, "hello\n", 6)                  = 6
read(3, "", 32768)                      = 0
/* ... */

Там вы видите, что cat testоткрываете файл с именем test, читаете его content ( hello) и помещаете его в стандартный вывод.

straceможет выдавать много информации, поэтому обязательно прочитайте man-страницу ( man strace), особенно документацию по -eвыводу, которая позволит вам увидеть только те системные вызовы, которые вас интересуют.

К сожалению, я не знаю графических или простых в использовании альтернатив. Если вы хотите искать их, ptraceдолжно быть одно из ваших ключевых слов поиска.

Что касается изоляции, там много технологий. Chroots, контейнеры Linux (которые в настоящее время находятся в стадии разработки и не завершены), виртуализация программного обеспечения и паравиртуализация являются наиболее используемыми. Однако эта тема слишком велика для обсуждения. Я бы предложил открыть новый вопрос, если вы хотите узнать больше.

Андреа Корбеллини
источник
5

Взгляните на AppArmor . Вы можете добавить ограниченный профиль для исполняемого файла и перевести его в режим «жалоб», где действия будут разрешены, но зарегистрированы, что, я думаю, соответствует вашим требованиям.

Но учтите, что этого не достаточно. Умный злонамеренный двоичный файл может обнаружить, что он находится под наблюдением, и не выполнять злонамеренных действий, кроме случаев, когда он не наблюдается.

AppArmor идет дальше этого и позволяет приложению навсегда ограничиться только утвержденными операциями. Приложения, попадающие в Ubuntu Software Center, поставляются с профилями AppArmor.

Роби Басак
источник
5

Как вы определили, виртуальную машину лучше обеспечить изоляцией, особенно если у вас есть основания полагать, что исполняемый файл является вредоносным в первую очередь. Но даже это не идеально, поскольку уязвимости в платформе виртуализации (как аппаратные, так и программные) могут быть использованы злонамеренным кодом для их устранения. Вот пример реальной уязвимости виртуализации: http://www.kb.cert.org/vuls/id/649219

Роби Басак
источник
1

Вы можете создать оснастку .

Моментальные снимки «ограничиваются ОС и другими приложениями с помощью механизмов безопасности, но могут обмениваться контентом и функциями с другими моментальными снимками в соответствии с детальными политиками, контролируемыми пользователем и значениями по умолчанию ОС». (с http://snapcraft.io/docs/snaps/intro )

Они обеспечивают дополнительную изоляцию в дополнение к AppArmor, например, с использованием seccomp .

Кроме того, оснастка может быть автономной для легкого распространения и элементарных обновлений в вашей системе.

Роби Басак
источник
0

Спасибо, ответы были очень полезны ...

Я также нашел это: https://downloads.cuckoosandbox.org/docs/

Это очень интересный инструмент для анализа вредоносных программ, когда они находятся в виртуальной машине

Ус
источник