Это не столько риск безопасности, сколько широко открытая дверь, причем все помеченные для всех, чтобы взять свободно и совпадать, чтобы сжечь все это …
Когда я преподаю или читаю лекции и упоминаю безопасность, мне всегда нравится аналогия безопасности как лука. Это обычное клише Это все еще мощная аналогия для людей, которые являются новичками в концепциях. Эквивалентная аналогия, которую я бы выбрал для дистанционной отладки, — это все равно, что оставить входную дверь открытой, со всеми вашими ценностями, нагруженными легко обнаруженными и хорошо обозначенными коробками. Вызов JDWP небезопасно не имеет никакого смысла. Он не был разработан, чтобы быть безопасным, так что это не …
Java Debug Wire Protocol (AKA JDWP) был разработан для тестирования внутри. За последние несколько лет я сталкивался с несколькими людьми, которые совершили ошибку, оставив ее даже в производстве!
Это безумно!
Даже внутренне это огромный риск с 60% нарушений, происходящих изнутри организации Анкет Хорошо…
Это не просто риск безопасности, который может по сути дать каждому хакеру «ключи» на ваш сервер и полный доступ к коду вашего сервера… Это также серьезная опасность стабильности, которая может легко разбить ваши производственные серверы.
Даже для постановки это проблематичный случай. Постановки серверов иногда подвергаются воздействию Интернета, но могут служить ступенькой для внутренних серверов (например, тот же хост, чтобы они скользили под правилом брандмауэра). Хакеры могут легко «запрыгнуть» на «настоящие» серверы, как только они смогут взломать (или на самом деле войти в открытую дверь) протокол удаленной отладки.
Прежде чем продолжить, я хотел бы уточнить свою предвзятость: я работаю на Lightrun Анкет Мы внедряем инструмент, который во многих отношениях является заменой отладчика, предназначенного для безопасной работы при постановке и производстве. Тем не менее, вы должны прочитать это, даже если у вас нет намерения использовать Lightrun, поскольку факты, которые я перечисляю ниже, все еще применимы к любому, кто использует удаленную отладку.
Еще одна вещь, которую я хотел бы указать, это то, что я не эксперт по безопасности. Я прочитал несколько отличных статей на эту тему от экспертов по безопасности, таких как Асаф Мораг Анкет Я думаю, что они великолепны, если вы исследователь безопасности или DevOps. Эта статья посвящена перспективе разработчиков.
Обратите внимание, что вам не нужно быть экспертом по безопасности, чтобы понять эти концепции и неотъемлемые недостатки. В этом смысле этот пост намного проще, чем тот, который из Ассафа. Этот пост также сильно склонен к Java, так как это моя основная область знаний, но ситуация не намного лучше на других языках/платформах.
Небезопасность по дизайну
Большинство протоколов удаленной отладки, таких как JDWP, являются продуктом другой эпохи. Эра, которая дала нам Telnet и HTTP. Большинство даже не зашифровано по умолчанию. Просто оставив JDWP включенным Оправдывает CVE Анкет
JDWP эффективно разрешает удаленное выполнение кода. Позволяет вам получить доступ ко всем байт -коду сервера, который фактически почти такой же, как предоставление доступа к вашему исходному коду с полным сервером. Это позволяет злоумышленникам делать практически все, так как это не было разработано с учетом безопасности.
Я даже не буду вдаваться в сложности человека в средних атаках и т. Д. Это просто безумие.
Я думаю, что лучшее смягчение — это туннель соединения по SSH. Это не решает все проблемы, но, по крайней мере, не огромная дыра, как мы обычно имеем. Вместо того, чтобы обеспечить удаленную отладку, как обычно в прошлом, просто включите его на свои серверы Localhost как таковые:
java -agentlib:jdwp=transport=dt_socket,server=y,address=9000 ApplicationName
Чтобы подключиться к этому удаленному, вам понадобится доступ SSH к машине и выполнить следующую команду:
ssh remoteUser@remoteHost -L 9000:127.0.0.1:9000 -N
Если вам нужны учетные данные для команды, также добавьте их туда. Это откроет туннель между портом 9000 вашей местной машины и удаленным. Вы сможете отладить на Localhost, но это будет работать как стандартный удаленный отладчик. Единственное отличие в том, что это не было бы так плохо с точки зрения безопасности.
Разрушить и сжечь
К сожалению, такие обходные пути не влияют на все остальное, что разбито в протоколах отладки. Некоторые операции в отладчике требуют более одного шага с точки зрения протокола. В результате вы можете отправить запрос на отладку, потерять связь, и отладка может застрять в проблемном состоянии.
Это неотъемлемое ограничение протокола JDWP и не может быть проработано в стандартном отладке.
Проблема в том, что даже непреднамеренные действия могут снести сервер. Простая условная точка останова, которая вызывает метод как часть условия, может снести производительность сервера и сбить его.
Информация просеивание
В культовом классическом офисном помещении герои просеивают копейки от транзакций. Крупные организации блокируют много этого доступа и справедливо.
Представьте себе, если все ваши коллеги имели отладку доступа к вашему серверу … все, что вам нужно, это одна условная точка останова в коде входа в систему пользователя, и у вас есть пароль человека, которого вы можете взломать. Если вы умны, вы попробуете этот пароль на другом сайте, и никто не знает, чтобы его даже не могли проследить.
Серьезно не делай этого!
Это очень реальный риск размещения JDWP на серверах и то, что вам нужно иметь в виду.
Как мы решили эти проблемы в Lightrun
Практически все эти проблемы не существует в Lightrun. Прежде чем я вхожу в это, Lightrun не просто позволяет вам начать отладку … вам нужно аутентифицировать. Существует система доступа с корпоративным соответствием, пользовательскими ролями, которые предоставляют конкретные разрешения и т. Д.
Небезопасность по дизайну
Lightrun не использует JDWP и вместо этого использует пользовательский агент. Это означает, что нет необходимости открывать дополнительный порт в ваш сервис.
Агент подключается к серверу управления, поэтому информация всегда получается, никогда не нажимая. Кроме того, подключения используют сертификат, чтобы заблокировать человека в средних атаках.
Разрушить и сжечь
Операции на Lightrun выполняются с использованием безопасного механизма и песочницей.
Операции, отправленные агенту, являются атомными, поэтому сбой соединения не повлияет на агента.
Кроме того, условия и выражения проводятся в песочнице и проверены. Если используется слишком много процессора или обнаружена операция записи, операция отбрасывается или ограничена. Вы получите распечатку, что ограничение скорости произошло, и ваш сервер останется стабильным и эффективным.
Информация просеивание
Lightrun имеет сокращение PII и списки блоков. Это означает, что Lightrun может обнаружить проблемные шаблоны в журналах, таких как номера кредитных карт. Затем он может заблокировать эти числа от входа в журналы.
Это полностью настраивается для установки, так что вы можете настроить это для номеров социального страхования и т. Д.
Блок -списки позволяют определить классы, файлы и т. Д. которые заблокированы для отладки. Просто исключите пакеты аутентификации и авторизации после того, как вы закончите отладку первоначальной настройки, и злонамеренный разработчик не сможет разместить там снимок.
Наконец все в Lightrun проверяется. Это означает, что даже если вы забыли ограничить доступ, все это будет зарегистрировано. Любой снимок (точка останова) или журнал, добавленный пользователем, добавляется в журнал аудита. Таким образом, вредоносный разработчик покинет цифровой след, за которым мы можем следовать.
TL; DR
Не используйте удаленную отладку, если только вам не нужно, а затем убедитесь, что никто не может получить доступ к вашей системе … даже при этих обстоятельствах будет бдительным и туннелем ваших соединений через SSH.
Будьте осторожны с условными точками отдыха и другими аналогичными сложными функциями отладчика. Они являются рецептом катастрофы в таких ситуациях.
Имейте в виду, что вы эффективно даете каждому пользователю, который имеет доступ к серверу клавиши к королевству. Не только источник и DB, доступ ко всем зашифрованным данным, таким как пароли!
Я надеюсь, что вы нашли это полезным и сохраняете безопасность с вашими развертываниями. Следуй за мной на Twitter.com/debugagent для обновлений и многого другого.
Оригинал: «https://dev.to/codenameone/psathe-risks-of-remote-jdwp-debugging-dbh»