Каковы риски и возможности или сценарии, посредством которых кто-то настраивает маскарады репозиториев maven и/или ip-потоков для предоставления маскарадных копий библиотеки оригинала, но с вредоносным или вредоносным кодом.
Каковы шаги и методы предотвращения таких рисков и возможностей?
Я предполагаю, что выделенный и находчивый злоумышленник может выполнить атаку MITM и перехватить все запросы в общедоступные хранилища Maven, тщательно вставляя вредоносный байт-код в артефакты JAR, а затем пересчитывая и передавая хэши SHA1.
Для клиента он выглядит как законный артефакт: двоичный JAR и SHA1 совпадают, и будут одинаковыми, даже если они проверяют альтернативные зеркала.
Я предполагаю, что единственным реальным решением является запрос центрального репозитория на поддержку HTTPS (и полагаем, что сам TLS не был сломан).
В качестве альтернативы практический подход может заключаться в создании прокси-сервера Maven (Artifactory или Nexus), обслуживаемого через HTTPS для внутренних клиентов. Это уменьшает поверхность атаки и означает, что вам просто нужно защитить линии связи от этого сервера до внешнего мира. Я периодически проверял, что JAR и хэши на прокси соответствуют тем, что есть в публичных зеркалах, используя полностью независимую, доверенную сеть.
Если вы действительно хотите быть в безопасности, вы не будете доверять двоичным файлам - вместо этого вы загрузите весь исходный код и просмотрите их вручную, прежде чем компилировать их самостоятельно, но это предполагает, что у вас достаточно квалифицированных ресурсов и времени проводить обзоры и доверять всей цепочке инструментов для сборки.
Ну, безопасность в слоях, как они всегда говорят.
Я могу думать о нескольких сценариях, хотя первый не является специфичным для Maven.
Отравление кэша DNS
Данные DNS, которые вы используете для доступа к стандартным репозиториям, могут быть отравлены, в результате чего Maven загружает артефакты из другого репозитория. См. статью wikipedia о отравлении кеша DNS.
Нестандартные репозитории
Любой репозиторий, который вы добавляете в конфигурацию Maven, может содержать артефакты, содержащие вредоносный код. Предотвратите это, используя только те сторонние репозитории, которым вы доверяете.
Отравление репозитория
Основываясь на Maven Руководство по загрузке артефактов в Центральный репозиторий, похоже, что центральный репозиторий Maven публикует артефакты из утвержденных хостов репозитория, поэтому безопасность артефактов зависит от хозяина. Я не знаю специфики процесса становления утвержденным хостом репозитория, но с таким количеством перечисленных в списке он, вероятно, обременителен.
Кроме того, для центрального репо требуется PGP-подписи для всех развертываний, поэтому, если злоумышленник не получает доступ к закрытому ключу для проекта, я не думаю, что это возможно.
Артефактная модификация во время передачи (человек посередине)
Maven выполняет автоматическую проверку контрольной суммы для всех артефактов, поэтому злоумышленнику придется модифицировать артефакт и сопровождающие контрольные суммы для ввода вредоносного кода. Я не знаю, можете ли вы полностью его предотвратить, но чтобы убедиться, что вы обращаете внимание на контрольные суммы, убедитесь, что политика контрольной суммы не установлена для игнорирования. См. настройки doc.
Как отмечали другие комментаторы, хороший способ предотвратить проникновение вредоносного кода в ваше производственное развертывание - использовать только внутренний репозиторий Maven для создания выпуска. Ограничивая доступ к добавлению зависимостей к этому репозиторию, вы можете убедиться, что все они проверены на любом выбранном вами уровне, например. контрольная сумма с двойной проверкой, сканирование исходного кода.
Если вы используете хорошо известные репозитории (центральный репозиторий maven, репозиторий jboss), очень низкая вероятность инъекции вредоносного кода. Компьютерный вирус, ваш интернет-провайдер или интернет-провайдер вашего интернет-провайдера должен работать с DNS-серверами или изменять пути маршрутизации для определенного набора адресатов. Я думаю, что это маловероятно - это касается не только maven repos, но и всех интернет-сервисов (электронная почта, http, voip и т.д.). Еще один риск заключается в загрузке JAR непосредственно с сайтов проекта.
В любом случае, если вы хотите иметь полный контроль, вы можете настроить свой собственный репозиторий maven (http://nexus.sonatype.org/)
Каждый файл, доступный в репозитории, должен иметь md5 или sha checksum generated - таким образом вы можете проверить, действительно ли то, что вы загрузили, именно то, что вы хотели. Но если злоумышленник (вирус) достаточно умен, чтобы перехватить вашу передачу данных и беспорядок в файлах JAR, он будет достаточно умен, чтобы перехватить контрольные суммы md5/sha. Защита от него заключается в том, чтобы предоставить подписи PGP как для контрольных сумм, так и для артефактов - выпустить артефакты, загруженные в центральный репо, вынуждены сделать это (файлы .asc)
Хорошей идеей является использование Nexus Professional - вы сможете настроить комплект поставки для проверки подписи PGP на сервере открытого ключа каждый раз при загрузке артефакта. Более подробную информацию о подписях PGP с maven можно найти здесь:
https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven