Как обнаружить Java-агенты, JVMTI и т. Д.

Question

Как можно защитить среду Java при работе на машине, которой вы не управляете? Что мешает кому-либо создать агент java или собственный агент JVMTI и создать дамп байт-кода или переписать классы, чтобы обойти лицензирование и / или другие проверки безопасности? Есть ли способ определить, запущены ли какие-либо агенты из кода Java? От JNI? От агента JVMTI?

Answer 1

Если вы не контролируете окружающую среду, тогда извините - вы действительно застряли. Да, вы могли бы искать тривиальные агенты JVMTI с помощью какого-либо сниффинга cmdline, но это меньше всего вас беспокоит. Подумайте о том, чтобы java / lang / Classloader.defineClass () был скомпрометирован напрямую. Это легко сделать, если у вас есть коробка - просто замените файл .class в rt.jar. Фактически, до появления JVMTI это был типичный способ, которым профилировщики и инструменты мониторинга инструментировали код Java.

Возвращаясь к JVMTI - функция «Позднее присоединение» также позволяет загружать агентов JVMTI на лету. Этого не могло произойти при первом сканировании.

Итог - если кто-то может изменить байты JRE на диске, он может делать все, что захочет. Этично ли это, нет? Могут ли они попасться? Возможно, но ты никогда не выиграешь войну.

Answer 2

Похоже, что я могу пойти с комбинацией проверок внутри некоторого собственного собственного кода JNI.

1.) Cmd, сниффинг строки для поиска агентов. 2.) Убедитесь, что параметр cmd-line -XX: + DisableAttachMechanism существует. (это не позволит людям подключиться к моей работающей виртуальной машине)

Answer 3

По сути, это проигрышная битва.

Посмотрите, как работает visualvm в Sun JDK и как он может подключиться к работающему процессу и переопределить все, что пожелает. Очень трудно обнаружить это портативным способом, и если вы не можете сделать это, вы могли бы также отказаться от этого подхода.

Вопрос в том, чего вы хотите избежать?

Answer 4

Я бы посмотрел на командную строку и увидел, есть ли какие-либо "-агентные" параметры. Все профилировщики, отладчики и другие модификаторы кода используют это для самоанализа. Вы также можете проверить наличие необычных jar-файлов в пути начальной загрузки, поскольку они также могут представлять угрозу (но следует помнить, что вам также необходимо предоставить пользовательскую JVM, поскольку некоторые программы, такие как Quicktime, добавляются в путь загрузки для всех работающих Java-приложений ... (Я не мог поверить своим глазам, когда увидел это ...))

Answer 5

Если вы не можете контролировать платформу, вы не можете контролировать программное обеспечение на ней.

Даже если бы вы могли закрыть все перечисленные вами пути проверки, Java имеет открытый исходный код. Они могут просто взять исходный код и перекомпилировать его с необходимыми встроенными изменениями.

Кроме того, постарайтесь запомнить, что пока это ваш код, это его машина. Они имеют право проверять ваш код, чтобы убедиться, что запуск его на их компьютере делает то, что они ожидают, и не выполняет «лишних» действий, которые они могут найти нежелательными. Менее надежные компании в прошлом сканировали не относящиеся к делу файлы, копировали конфиденциальную информацию обратно на свои домашние серверы и т. Д.

Answer 6

Безопасность Java 2, подписывание jar-файлов и т. Д. Дает некоторый уровень контроля над тем, что загружается в ваше приложение.

Однако, в конце концов, если злоумышленник имеет доступ к машине, так что он может записывать на диск, то, по всей вероятности, у него достаточно возможностей для нанесения вреда, не прибегая к умным взломам Java.

Поверните этот раунд на любом языке, что вы можете сделать, чтобы обнаружить троянов?

Тщательный контроль доступа к машинам, о которых вы заботитесь, нетривиален, но необходим, если вы серьезно относитесь к таким проблемам. Специалисты по безопасности могут показаться параноиками, но это часто означает, что они действительно понимают риски.

Answer 7

Я помню, что однажды сделал почти беззвучный Java-агент. Я думаю, вам лучше поискать сканеры портов или что-то подобное.