Реальная уязвимость JAVA
О уязвимости (или неуязвимости) JAVA в интернете ходят разные мнения – от того, что механизмы безопасности, испольузуемые в JAVA, беспрецендентны по своей мощности и результативности, до полного скепсиса.
Но достаточно посмотреть пару ссылок:
http://www.securitylab.ru/vulnerability/462753.php
http://internetno.net/category.....mnenie/java-malware/
http://business.kaspersky.ru/u.....ut-mnozhit-sya/1280/
как становится ясно, что для скепсиса оснований более чем достаточно, и с этим придется смириться. Также придется усомнится в том, что "своеременные обновления" решают проблему.
Итак, остается вопрос: каким образом эти уязвимости могут быть вызваны и активированы?
Конкретный случай: использую мессенжер Jitsi, который базируется на JAVA.
Каким эта JAVA может быть взломана, заражена, скомпроментирована и т.д.?
Ведь взломы JAVA, если правильно понял, осуществляются только через эксплоиты?
Ну а если я нахожусь за файрволом, пропускающим только часть самых нужных для работы портов, и не использую бразуер, то получается, что в такой конфигурации взлом JAVA в принципе невозможен?
Или я ошибаюсь?
Ну, в особо тяжёлых случаях уязвимость может дёргать прикладной легитимный код на джаве при вызове с определёнными параметрами. ☺
Эксплоиту кто-то запретит пролезть через один-единственный открытый вами порт?
Запускайте Java-проги в виртуалке.
P.S. Java становится всё более популярна, потому что её облюбовали проприеатрщики из-за портируемости, тредовости и прочих полезных штук. Пишут на ней всякие мобильные приложения и т.д. Поэтому, наверно, число атак против Java'ы тоже растёт — у них всё большее поле для применимости на практике.
Есть песочницы типа Sandboxie. В Линукс аналогов не знаю (есть ли они в природе?).
Или используют программы вроде app armor, которые ограничивают права выбранных программ.
То есть например запретить программам на Java писать на диск во всех каталоги кроме своего и запретить запуск других программ.
Это уже меры противодействия, спасибо.
Но я не о мерах, а чисто о механизме взлома – как он происходит?
Вот сижу за файрволом, запускаю Jitsi, начинаю общаться.
Извне появляется какой-то злоумышленник, угроза. Через файрвол они не проникнут, и что дальше происходит, конкретно?
А про механизм эксплуатации – смотрите конкретный эксплойт, смотрите требования и как он работает.
Если пишете на сайт, значит dst порты 80 и 443 у вас разрешены. Эксплойт запустит приложение, которое установит шифрованное соединение с удалённым сервером на 443 порту, маскирующимся под веб-сервер, и передаст ему всё необходимое. Может это регулярно делать и сливать, например, снимки экрана, нажатия на клавиши и много другого интересного.
То есть, я должен браузером (или чем-то его эмулирующим) зайти на некий сайт, на котором находится зловредный эксплойт?
Хорошо, сужаем возможности взлома: исключаем из своей системы браузер и вообще всё, способное выходить в интернет и заражаться – тогда как?
Но вы написали, что пользуетесь мессенджером, значит выход в сеть есть. Чтобы соединиться с удалённым портом браузер не нужен, это может сделать тупой скрипт из нескольких строк. А подхватить эксплойт в сети, который запустит этот скрипт можно откуда угодно. Например через Jitsi-сервер, если используется, или клиент с которым общаетесь. Или любые промежуточные узлы сети, в том числе интернет-провайдер, могут вклиниться в трафик.
Но чтобы тупой скрипт с чем-то соединился, то нужно, чтобы он сначался появился в системе, не так ли?
Вот я и пытаюсь понять пути его проникновения и активизации.
Вы говорите, что эксплойт можно подцепить через Jitsi-сервер, согласен.
Но если я соединяюсь с Jitsi-сервером только через протокол XMPP, то значит, что этот скрипт/эксплойт должен быть класса "XMPP", так ведь?
Существуют ли уже такие?
Они не открыты снаружи. Запрос делает браузер и получает ответ по этому порту. Снаружи порт не доступен, если его конечно не открывали для доступа. Так бы все ПК и грохали через 80 порт.
Ну да и заварите его в железный ящик, потом киньте на дно океана. И даже там его поразит ржавчина (!). Чем не вирус для железа?
Легко через внешние носители. Тогда порты нужно выломать все и никогда ничего не подсоединять к ПК.
Давайте уж по серьезному. Пытаюсь установить возможные пути взлома связки Jitsi & JAVA, чтобы затем ликвидировать их.
Ведь кроме Jitsi все еще нет вменяемого непроприетарного телефона (творение тов. Гегеля все еще, увы, не готово).
Тут понятно, спасибо!
"недоверяемый" – в смысле со свойствами безопасности, которые нельзя проверить? т.е. которому доверять нет оснований, хотя и обратного тоже нет
Многие эксплойты подволяют выполнить произвольный код, переполняя стек операционной памяти или ещё как. Конкретно нужно смотреть в описании эксплойта или консультироваться у вирусописателей.
Вы путаете src и dst порты. "Грохают" через клиентские src порты (свыше 1024), а соединяются через те dst, что пропускает сетевой экран. Сделать регулярное выполнение можно например прописавшись в скрипты запуска популярного приложения.
XMPP это лишь протокол для транспорта прикладных данных, которые передаются коду Jitsi (или что у вас там). Обычно экплойты внедряются в прикладные данные и эксплуатируют уязвимость кода приложения. Поэтому несущественно, какой используется протокол – XMPP, HTTP и т.д. Хотя могут существовать и специфичные для протокола уязвимости.