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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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