id: Гость   вход   регистрация
текущее время 19:31 27/04/2024
Автор темы: Гость, тема открыта 02/01/2015 00:24 Печать
Категории: уязвимости
создать
просмотр
ссылки

Реальная уязвимость 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 в принципе невозможен?
Или я ошибаюсь?


 
На страницу: 1, 2 След.
Комментарии
— Гость (02/01/2015 05:01)   <#>

Ну, в особо тяжёлых случаях уязвимость может дёргать прикладной легитимный код на джаве при вызове с определёнными параметрами. ☺


Эксплоиту кто-то запретит пролезть через один-единственный открытый вами порт?

Запускайте Java-проги в виртуалке.

P.S. Java становится всё более популярна, потому что её облюбовали проприеатрщики из-за портируемости, тредовости и прочих полезных штук. Пишут на ней всякие мобильные приложения и т.д. Поэтому, наверно, число атак против Java'ы тоже растёт — у них всё большее поле для применимости на практике.
— Гость (02/01/2015 12:29)   <#>

Есть песочницы типа Sandboxie. В Линукс аналогов не знаю (есть ли они в природе?).
— Гость (02/01/2015 16:01)   <#>
Создают пользователя и ограничивают ему права, запускают от его имени программы.
Или используют программы вроде app armor, которые ограничивают права выбранных программ.

То есть например запретить программам на Java писать на диск во всех каталоги кроме своего и запретить запуск других программ.
— Гость (02/01/2015 18:49)   <#>

Это уже меры противодействия, спасибо.
Но я не о мерах, а чисто о механизме взлома – как он происходит?
Вот сижу за файрволом, запускаю Jitsi, начинаю общаться.
Извне появляется какой-то злоумышленник, угроза. Через файрвол они не проникнут, и что дальше происходит, конкретно?
— Гость (02/01/2015 19:48)   <#>
Это неправильный подход в корне. Java в своем нынешнем состоянии – набор неповоротливого глючного г***а, которое писалась в разном стиле в разное время, с вынужденное обратной поддержкой и в которой сам черт ногу сломит. Постоянные обнаружения уязвимостей и выкатывание заплаток продолжатся и дальше, тут никогда нельзя будет считать ее надежной для каких-либо задач, связанных с секретностью и т.п. Только отказываться, либо, как уже сказали, использовать в виртуалках\запускать без прав.

А про механизм эксплуатации – смотрите конкретный эксплойт, смотрите требования и как он работает.
— Гость (02/01/2015 21:00)   <#>
Через файрвол они не проникнут, и что дальше происходит

Если пишете на сайт, значит dst порты 80 и 443 у вас разрешены. Эксплойт запустит приложение, которое установит шифрованное соединение с удалённым сервером на 443 порту, маскирующимся под веб-сервер, и передаст ему всё необходимое. Может это регулярно делать и сливать, например, снимки экрана, нажатия на клавиши и много другого интересного.
— Гость (02/01/2015 21:56)   <#>

То есть, я должен браузером (или чем-то его эмулирующим) зайти на некий сайт, на котором находится зловредный эксплойт?
Хорошо, сужаем возможности взлома: исключаем из своей системы браузер и вообще всё, способное выходить в интернет и заражаться – тогда как?
— Гость (02/01/2015 23:49)   <#>
Если автономный компьютер, физически отключённый от сети, тогда никак.

Но вы написали, что пользуетесь мессенджером, значит выход в сеть есть. Чтобы соединиться с удалённым портом браузер не нужен, это может сделать тупой скрипт из нескольких строк. А подхватить эксплойт в сети, который запустит этот скрипт можно откуда угодно. Например через Jitsi-сервер, если используется, или клиент с которым общаетесь. Или любые промежуточные узлы сети, в том числе интернет-провайдер, могут вклиниться в трафик.
— Гость (03/01/2015 00:10)   <#>
Разумеется, компьютер включен в мировую Сеть :)
Но чтобы тупой скрипт с чем-то соединился, то нужно, чтобы он сначался появился в системе, не так ли?
Вот я и пытаюсь понять пути его проникновения и активизации.
Вы говорите, что эксплойт можно подцепить через Jitsi-сервер, согласен.
Но если я соединяюсь с Jitsi-сервером только через протокол XMPP, то значит, что этот скрипт/эксплойт должен быть класса "XMPP", так ведь?
Существуют ли уже такие?
— Гость (03/01/2015 01:10)   <#>

Они не открыты снаружи. Запрос делает браузер и получает ответ по этому порту. Снаружи порт не доступен, если его конечно не открывали для доступа. Так бы все ПК и грохали через 80 порт.

Ну да и заварите его в железный ящик, потом киньте на дно океана. И даже там его поразит ржавчина (!). Чем не вирус для железа?

Легко через внешние носители. Тогда порты нужно выломать все и никогда ничего не подсоединять к ПК.
— Гость (03/01/2015 01:12)   <#>
Блинн.. ну вы тут страстей нагнали.
— Гость (03/01/2015 02:39)   <#>
Самый простой способ — недоверяемый Jitsi-сервер, который в ответ на ваш клиентский легитимный запрос выдаст вам такое, что клиенту поплохеет, он выполнит невозможный код и передаст управление всем, чем может, в матрицу.
— Гость (03/01/2015 03:26)   <#>

Давайте уж по серьезному. Пытаюсь установить возможные пути взлома связки Jitsi & JAVA, чтобы затем ликвидировать их.
Ведь кроме Jitsi все еще нет вменяемого непроприетарного телефона (творение тов. Гегеля все еще, увы, не готово).


Тут понятно, спасибо!
"недоверяемый" – в смысле со свойствами безопасности, которые нельзя проверить? т.е. которому доверять нет оснований, хотя и обратного тоже нет
— Гость (03/01/2015 08:46)   <#>
Но чтобы тупой скрипт с чем-то соединился, то нужно, чтобы он сначался появился в системе

Многие эксплойты подволяют выполнить произвольный код, переполняя стек операционной памяти или ещё как. Конкретно нужно смотреть в описании эксплойта или консультироваться у вирусописателей.

> значит dst порты 80 и 443 у вас разрешены

Они не открыты снаружи. Запрос делает браузер и получает ответ по этому порту. Снаружи порт не доступен, если его конечно не открывали для доступа. Так бы все ПК и грохали через 80 порт.

Вы путаете src и dst порты. "Грохают" через клиентские src порты (свыше 1024), а соединяются через те dst, что пропускает сетевой экран. Сделать регулярное выполнение можно например прописавшись в скрипты запуска популярного приложения.
— Гость (03/01/2015 08:55)   <#>
скрипт/эксплойт должен быть класса "XMPP"

XMPP это лишь протокол для транспорта прикладных данных, которые передаются коду Jitsi (или что у вас там). Обычно экплойты внедряются в прикладные данные и эксплуатируют уязвимость кода приложения. Поэтому несущественно, какой используется протокол – XMPP, HTTP и т.д. Хотя могут существовать и специфичные для протокола уязвимости.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3