Comments 37
причем здесь NAT? NAT не фаервол
При том, что большая часть устройств сидит за тем или NAT-ом и порты компьютера уже не торчат наружу в дикий интернет. Если раньше достаточно было просто поднять простейший сервер на нужном порту, и снаружи им управлять, то сейчас порт ты конечно откроешь, но достучаться до него не сможешь, если конечно не настроил проброс портов через все NAT-ы по дороге.
На 2025й год входящие подключения на обычный компьютер практически все.
Насколько мне известно, если отключить в роутере фаервол, то он радостно будет пересылать пакеты с адресами 192.168.xxx.yyy, приходящие со стороны аплинка, на компы во внутренней сети. Так что никакой защиты NAT сам по себе не даёт.
то он радостно будет пересылать пакеты с адресами 192.168.xxx.yyy, приходящие со стороны аплинка
Какая-то фантастика, если только между роутером и аплинком не бегает какой-нибудь OSPRF/RIP. Или речь про какую-то подделку пакетов?
Реальность, если "между роутером и аплинком" будет сидеть злоумышленник
И перебивать вручную номера пакетов, полагаю?
Достаточно угадать сеть LAN и настроить маршрут в нее через адрес на WAN интерфейсе Вашего роутера
Что-то новое в мире маршрутизации. Детали будут? Хотя-бы подскажите где вы о таком узнали.
Он, очевидно, имеет в виду, что на многих моделях хомячных роутеров раньше по-умолчанию был разрешен Forward между всем, в том числе снаружи внутрь (аналог iptables -P FORWARD ACCEPT). При такой настройке, зная белый ip торчащий в интернет, угадав внутренн. подсеть (ничего сложного), найдя активный ip перебором и активный порт на нем, гипотетически действительно можно отправить на него пакет и получить ответ. Только товарищ забыл, что белых ip мало, и 99,999% за Nat'ом за натом за натом и еще десятком натов и поэтому такое не сработает. Плюс уже давно даже самые днищенские китайские роутеры такого не делают.
При такой настройке, зная белый ip торчащий в интернет, угадав внутренн. подсеть (ничего сложного), найдя активный ip перебором и активный порт на нем, гипотетически действительно можно отправить на него пакет и получить ответ.
Вы своим постом шатаете устои маршрутизации.
Такого никогда не было, нет и не будет.
Но с радостью почитаю про источник столь удивительной ереси (чтобы отправить по адресу зондер-команду цисководов).
щас мне лень, на буднях если время найдется, соберу стенд из виртуалок и попробую. Самому интересно, на практике никогда не пробовал. Источник, разумеется не помню, где-то видел я это лет 20 назад в статье про настройки Iptables. А вот слово ересь использовать в таком контексте как-то странно, получается вы как бы религиозный фанатик, а я Коперник, Бруно и меня готовятся сжечь по несправедливому обвинению :)
Прежде чем заморачиваться со стендом - почитайте про протоколы маршрутизации, хотя бы про классику вроде RIP.
Это самое простое.
"Форвард" пакетов между подсетями, в которые подключен ваш локальный сервер к маршрутизации отношение имеет очень слабое.
Ну да, почитал иро обход НАТ, раз уж умные люди реализуют для этого вот такое, https://thehackernews.com/2020/11/new-natfirewall-bypass-attack-lets.html?m=1 очевидно, более простых методов нет. А про маршрутизацию я аж всего Танненбаума прочитал, но за ненадобностью в практике бОльшую часть благополучно забыл.
upd: В свое оправдание могу только сказать, что я изначально не имел в виду штатное поведение маршрутизации, а специально скрафченный пакет с поддельными параметрами, но видимо, такое невозможно.
Ээм не читайте таких статей на ночь )
Описанное в статье это очень редкий сценарий, который требует уж очень много всего: тут и триггер изнутри корпоративной сети и специфический набор протоколов взаимодействия и нетривиальная настройка.
Если уж дошло до запуска чего-то изнутри корпоративной сети, то сильно проще запустить банальный реверс-шелл типа описанного выше и дальше просто работать.
Возможно, мы говорим про разные сценарии, в моём злоумышленник подключается к домовому коммутатору, в который подключены wan интерфейсы роутеров жильцов
в моём злоумышленник подключается к домовому коммутатору, в который подключены wan интерфейсы роутеров жильцов
Ага и первым делом запускает перебор клиентских IP-адресов и сканер открытых портов. Как в фильме "Хакеры" )
Вообщем это безумие, но даже в этом безумном случае, даже самый отбитый сисадмин не станет пускать протоколы маршрутизации на клиентский порт.
Это у них на уровне генетики прошито.
Ну вот тут-то как раз нормальный провайдер обязан реализовать vlan на пользователя, или еще как-то изолировать трафик. Но в 2004 году нормальных провайдеров не было, и я лично закидывал смешную вирусню в доверчиво открытые шары на соседских Windows XP с логином Администратор и паролями вида 123, 123456 и т. П.
Но обход Нат для этого не нужен :)
Java ведь безопасная и таких подстав от нее не ждут, тем более сами разработчики.
приговаривал автор имея полный админский доступ, меняя jarки и подкладывая свои... какая-то шизофрения простите. к чему тут фокус на spi имея полный доступ тоже не понятно, возьми и поменяй любой другой класс который всегда вызывается, добавь в него свой метод и положи его обратно в jar томката или любой другой библиотеки, да хоть своего приложения, раз в рассматриваемом случае нет контроля над этим вектором, и не надо этих дополнительных плясок, ждать что кто-то вызовет какой-то метод косвенным образом... типа это будет не так заметно...
предположу, что в IDEA есть простая защита от прямого изменения, потому что 1) она изначально была платная и нужен какой-то механизм защиты 2) есть система загружаемых плагинов и вы как пользователь можете не знать что загружаете, а чтобы слишком хитрый плагин не менял ничего под себя - ввели такой простой запрет. А на сервере этого не надо и скорее мешать будет в некоторых случаях, там вы сами хозяин и должны понимать что добавляете и что запускаете.
физически удаляя все места из исходного кода где используется сканирование классов, SPI, JMX, RMI и подобные радости.
Зачищенный таким образом Jetty сейчас работает под нашим сайтом, регулярно огорчая своим существованием различных «кульхацкеров».
так дайте кулхацкерам ssh доступ к вашему Jetty, в чем проблема?))) В общем ерундой занимаетесь и да, у меня на большом проекте есть запрет на соединения с произвольными адресами, только по белому листу, и никто не умер несмотря на все интеграции. Это я не говорю о том, что вы всегда можете посмотреть какие сторонние библиотеки у вас в сборке, какие у них уязвимости, какая у них популярность и нужны ли они вам вообще. Ну а чтобы кто-то шел залил так это надо еще найти такую, обычно я это слышу про npn и питон, видимо там сложнее с анализом и не такие строгие правила ревью + народ активнее тащит всякую косметическую ерунду непонятного происхождения.
В общем узнал новое про SPI и когда jdk сама вызывает что-то из classpath а все остальное бредик
приговаривал автор имея полный админский доступ, меняя jarки и подкладывая свои
В Java-мире принято, что у пользователя, от которого работает Java-приложение есть доступ на запись минимум в собственный каталог. Поэтому при наличии RCE (линк в статье) всегда можно записать что-то на уязвимый сервер.
у меня на большом проекте есть запрет на соединения с произвольными адресами, только по белому листу
Вроде даже РКН перестал пытаться блокировать по IP еще 10 лет назад.
Даже интересно как выглядит ваш "whitelist": полный список ip-адресов Amazon S3, CloudFlare, зеркал Яндекса и так далее - рука не устала вбивать? А поддерживать потом как?
Ну а чтобы кто-то шел залил так это надо еще найти такую
Вбейте в поисковик: "github java rce" - удивитесь.
Если сразу не успокоитесь, то вот еще одна моя статья, пока не перенесенная на Хабр, как раз про ваш корпоративный мир.
В Java-мире принято, что у пользователя, от которого работает Java-приложение есть доступ на запись минимум в собственный каталог.
кем принято? в принципе я не вижу проблем настроить томкат так, чтобы он запускал приложение из отдельной папки и сам мог писать только в папку log и temp которые тоже находятся в отдельном месте. сейчас любят делать готовый jar, как там дело обстоит надо смотреть, но возможно в этом случаи вы в принципе не сможете модифицировать и подложить что-то в classpath.
А поддерживать потом как?
без понятия, этим не я занимаюсь. IP у крупных сервисов статические
Вбейте в поисковик: "github java rce" - удивитесь.
так а зачем мне код примеров, вы мне покажите пример где подобный код оказался транзитивной зависимостью какого-нибудь hibernate или на худой конец библиотеки у которой например 100 звезд на гитхабе. Я за лет 15 не помню такого случая.
Если сразу не успокоитесь, то вот еще одна моя статья, пока не перенесенная на Хабр, как раз про ваш корпоративный мир.
это я знаю и новости тут нет, нельзя наружу выставлять сложные протоколы которые по предназначению внутренние, сюда же стандартный механизм сериализации (сейчас правда чинят на всякий случай), xml через некоторые старые библиотеки (тут конечно разработчики xstream и т.д. лопухнулись) и например ajp. Все что должно быть открыто для web это http и json-xml. Остальное после строгого ревью на свой страх и риск.
в принципе я не вижу проблем настроить томкат так, чтобы он запускал приложение из отдельной папки и сам мог писать только в папку log и temp которые тоже находятся в отдельном месте
Не видите проблем или не пробовали? А я например вижу (потому что пробовал). И кто прав?
, но возможно в этом случаи вы в принципе не сможете модифицировать и подложить что-то в classpath.
Все‑таки стоит более внимательно читать технические статьи прежде чем комментировать — про автоматическую загрузку и выполнение кода из переменной окружения было написано. И не один раз.
Я за лет 15 не помню такого случая.
Надо почаще читать профильные новости, хотя вопрос конечно спорный - вдруг начитаетесь и сон потеряете?
Помимо упомянутого в статье эпичного фейла с log4j:
https://github.com/BobTheShoplifter/Spring4Shell-POC
https://github.com/absholi7ly/POC-CVE-2025-24813
https://github.com/akamai/CVE-2025-27636-Apache-Camel-PoC
https://gist.github.com/win3zz/308c6567e38e096c7071d3564ef164ad
https://securitylab.github.com/advisories/GHSL-2022-085_pac4j/
https://github.com/abdoghazy2015/ofbiz-CVE-2023-49070-RCE-POC/
И все это уже PoC (Proof of Concept) те готовый запускаемый эксплоит - наливай да пей запускай да используй.
Все кто занимается ИБ поседели за последние три года, смотреть страшно.
Не видите проблем или не пробовали? А я например вижу (потому что пробовал). И кто прав?
ну дело ваше, я уверен что можно настроить хотя я прямо этого не делал а сейчас мне не надо
Помимо упомянутого в статье эпичного фейла с log4j:
возвращаемся к вопросу что ваше приложение не должно само стучать в интернет, только если вы не краулер делаете
rce эти примерно на одну тему (уж позже гляну детально), десириализация (о чем я писал) или кривые руки. опять-таки это не ваш случай когда ваш класс уже в системе и его надо как-то запустить
Все кто занимается ИБ поседели за последние три года, смотреть страшно.
да ладно, разве нет активных систем мониторинга трафика, которые обрезают подозрительные запросы, акамай на сколько знаю sql injection замечает. если б я и делал проект в сфере иб то на эту тему, а не резал jetty.
возвращаемся к вопросу что ваше приложение не должно само стучать в интернет, только если вы не краулер делаете
Это идет в разрез с текущими тенденциями: проверка и скачивание обновлений, централизованная конфигурация, централизованная аутентификация, облачные хранилища данных и так далее.
Сейчас все сетевое.
О чем можно говорить, когда половина логики в современной системе — вызовы REST‑методов по сети.
Да, ДМЗ это хорошо и нужно на серьезных проектах.
Но дорого и непросто, поскольку все что делает автоматика вам придется делать вручную.
опять-таки это не ваш случай когда ваш класс уже в системе и его надо как-то запустить
Вы ошибочно считаете, что код это обязательно класс и что вызов может быть только локальным. Хотя RCE на практике нужен в первую очередь для скачивания основной логики, но вполне может использоваться и напрямую.
Код реверс-шелла в одну строку в статье есть, как это работает (вывод управляющих команд) видно на заглавной картинке.
акамай на сколько знаю sql injection замечает.
SQL Injection ныне довольно редок а попытки его резать запросто могут мешать логике работы системы. Это помимо очевидного замедления работы из-за подобного фонового сканирования, так что решение откровенно нишевое.
Это идет в разрез с текущими тенденциями: проверка и скачивание обновлений, централизованная конфигурация, централизованная аутентификация, облачные хранилища данных и так далее.
чаво? какие обновления? сейчас все релизится контейнерами которые представляют из себя полный артефакт. Если ваше приложение лезет в интернет и еще что-то докачивает для своего запуска, значит вы что-то делаете не так, значит у вас нет билда как такового и у этого билда нет версии. Централизация конфигураций у вас должна быть на уровне сети вашего кластера и в wan ей ходить точно не надо. Аутентификацию надо смотреть ну и допустим вам надо с сервера коннектится и что-то подливать на s3, в таком случае можно сделать отдельный сервис у которого будет такое право и соединить их по mq. Если архитектура на микросервисах то сделаете без проблем, в противном случаи конечно усложнение, но зато секурность сильно повышается. Еще раз: с моей точки зрения приложение не должно самовольно выходить wan и что-то качать или отправлять и делать это все без вашего прямого разрешения и понимания.
SQL Injection ныне довольно редок а попытки его резать запросто могут мешать логике работы системы. Это помимо очевидного замедления работы из-за подобного фонового сканирования, так что решение откровенно нишевое
я для примера привел, такие системы называются "Web Application Firewall" или что-то в этом роде умеют много чего, есть у акамая и cloudflare. Про замедление на миллисекунды я бы не переживал, вам же безопасность нужна. Я думаю можно придумать или найти разные средства защиты от rce нулевого дня на java, начиная с java agents которые будут следить какие классы загружаются и когда (ведь вам будут пытаться залить шелл который сразу же должен запуститься) заканчивая простой фильтрацией трафика, каждый java класс начинается с "CAFEBABE", если файлик, который вам пытаются залить начинается с этих байт, то сразу "забарона". Ну и ограничение на исходящий трафик. Две меры сильно повышающие безопасность. И то что выше писалось: наружу только http и через нормальные библиотеки десериализации данных. Возможно есть какие-то более сложные системы контроля соединений и анализа того, что передается, но я этой темой не интересовался.
с моей точки зрения приложение не должно самовольно выходить wan и что-то качать или отправлять и делать это все без вашего прямого разрешения и понимания.
Это само собой. На практике пробовали такое реализовать?
Про замедление на миллисекунды я бы не переживал, вам же безопасность нужна
А если скажу что задержку между 200 мс и 50 мс уже видно визуально? А если умножить эту задержку на каждую выполняемую операцию?
каждый java класс начинается с "CAFEBABE", если файлик, который вам пытаются залить начинается с этих байт,
Снова теория?
Это само собой. На практике пробовали такое реализовать?
я ж вам говорю, у нас такое было, может до ссо, но в остальном проблем не было. Не хотите так делать - ваше дело, только потом не удивляйтесь что реально вам нужно было открыть полный доступ на соединение вовне ради одного сервиса, а реально им пользуется какой-то шел и говорит вам за это спасибо. В принципе у меня есть идеи как бороться даже в этом случаи: когда у вас монолит и надо обращаться вовне без возможности иметь белый список, но как я понял вы не готовы заморачиваться.
А если скажу что задержку между 200 мс и 50 мс уже видно визуально? А если умножить эту задержку на каждую выполняемую операцию?
я не замерял какая она на самом деле, так или иначе вы все равно его включите, если захотите защиту от ботов, но везде пишется что она минимальная.
Снова теория?
это база. Но вы можете продолжать заниматься тем чем решили, это ваше дело и ваше видение, оно не обязательно должно совпадать с мои.
MC с оформлением как Dos Navigator?
Тут я хотел выдать очередную гусарскую шутку, но внезапно реальность меня обогнала:
dn2l — Dos Navigator Open Source Project linux port tryouts
Надо будет обязательно попробовать собрать, хотя-бы ради ностальгии )
Reverse shell на Java или кошмар сисадмина