Перейти к содержанию

Уязвимость в Java подвергает пользователей серьезному риску

Евгений Малинин

Автор Евгений Малинин
в Новости и события со всего мира

 Поделиться

Рекомендуемые сообщения

Евгений Малинин

Евгений Малинин

Опубликовано
Опубликовано

Исследователь Тэвис Орманди сообщил об уязвимости в Java Web Start, позволяющей хакеру удаленно выполнить вредоносный код в системе под управлением всех недавних версий ОС Windows, а его соратник Рубен Сантамарта из фирмы Wintercore заявил, что аналогичная брешь затрагивает и Linux.

 

Оба эксперта указывают на шокирующую легкость использования бага, эксплуатацию которого можно осуществить с помощью веб-сайта, тайно рассылающего вредоносные команды различным компонентам Java, служащим для запуска приложений в браузерах Internet Explorer, Firefox и прочих.

 

Орманди рассказал также, что разработчики Java из недавно приобретенного Oracle соответствующего подразделения Sun были проинформированы о наличии проблемы, однако не сочли ее заслуживающей того, чтобы нарушить плановый ежеквартальный график выхода патчей. Оба исследователя с этим категорически не согласны.

 

Так, Сантамарта пишет, что метод, с помощью которого поддержка Java Web Start была добавлена в JRE – это ничто иное, как сознательно установленный бэкдор или вопиющий случай поразительной безответственности. По словам эксперта, самое невероятное заключается в том, что в Sun не смогли правильно оценить уровень риска от этой утечки после того, как Орманди предоставил им информацию о ней.

 

В числе уязвимых компонентов Windows, обнаруженных Орманди, значатся элемент управления ActiveX, известный как Java Deployment Toolkit и плагин для Firefox под названием NPAPI, служащий для того, чтобы облегчить разработчикам Java распространение приложений среди конечных пользователей.

 

Все эти компоненты без надлежащей проверки принимают и обрабатывают команды, встроенные в URL и веб-страницы, а затем передают их другим компонентам на исполнение. По словам Сантамарты, добавление скрытого параметра командной строки позволяет использовать данный баг и на Linux. В настоящее время эксперт изучает возможность эксплуатации этой бреши для удаленного выполнения кода.

 

Орманди предупреждает, что без патча защитить себя от этой уязвимости будет не так-то просто, поскольку одного отключения ActiveX или плагина для Firefox будет недостаточно. Данный инструментарий ставится отдельно от Java и это значит, что единственными возможными временными решениями являются установка специфичных для каждого браузера стоп-битов или внедрение дополнительных функций в списки контроля доступа. Более подробно об этом написано здесь.

 

Впрочем, существует и более радикальный способ решения проблемы, который в последнее время все чаще кажется заслуживающим внимания. Так, эксперт по компьютерной безопасности Алекс Сотиров написал на Twitter о том, что он удалил Java более года назад и до сих пор не имел ни единой проблемы ни с одним из сайтов. Поэтому исследователю кажется непонятным, для чего люди до сих используют Java в своих браузерах.

 

© http://www.xakep.ru/post/51748/default.asp

Fasawe

Fasawe

Опубликовано
Опубликовано

Скорее всего Java внесла брешь специально и для своего личного пользования...

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
 Поделиться
Перейти к списку тем

  • Похожий контент

    • KL FC Bot
      Что не так с SSO в облачных сервисах и как снизить риски
      Автор KL FC Bot
      Утечки учетных данных остаются одним из самых популярных у злоумышленников способов проникновения в организацию. Только за 9 месяцев 2023 года по данным Kaspersky Digital Footprint Intelligence в даркнете было опубликовано 315 миллионов записей учетных данных, среди которых множество реквизитов доступа к корпоративным ресурсам, в том числе и к ресурсам компаний из списка Fortune 500.  Чтобы эффективнее управлять связанными с этим рисками, минимизировать число уязвимых аккаунтов, быстрее замечать и пресекать несанкционированный доступ, компании внедряют системы управления identity, о которых мы подробно писали ранее. Но эффективный процесс управления identity невозможен, пока большинство корпоративных систем не поддерживают процедуру унифицированной аутентификации. Для внутренних систем компании она обычно завязана на централизованный каталог, например Active Directory, а во внешних SaaS-системах взаимодействие с корпоративным каталогом identity ведется через платформу Single Sign-on (SSO) —либо внешнюю, либо развернутую в инфраструктуре компании, такую как ADFS.
      Для сотрудников это предельно удобно — логинясь во внешние системы, такие как SalesForce или Concur, сотрудник проходит единый для корпоративной сети процесс аутентификации, включая ввод пароля и предъявление второго фактора (кода OTP, USB-токена и так далее, согласно корпоративной политике), ему не нужны никакие дополнительные логины и пароли. Более того, однократно войдя утром в одну из систем, в остальные можно входить автоматически. Помимо удобства этот процесс в теории безопасен, поскольку службы IT и ИБ имеют полный централизованный контроль над учетными записями, парольными политиками, методами МФА и логами.
      Но на практике уровень безопасности внешних систем, поддерживающих SSO, зачастую оказывается не таким уж высоким.
       
      Подводные камни Single Sign-On
      Пока пользователь входит в SaaS-систему, сервер этой системы, клиентское устройство пользователя и платформа SSO проходят несколько этапов взаимодействия, в которых платформа SSO проверяет пользователя и выдает SaaS-системе и клиентскому устройству токены аутентификации, которые подтверждают права пользователя. При этом платформа может снабжать токен целым рядом параметров, напрямую влияющих на безопасность. Они могут включать:
      указание периода действия токена (и сессии), по истечении которого потребуется повторная аутентификация; привязка токена к конкретному браузеру или мобильному устройству; привязка токена к конкретным IP-адресам или IP-диапазонам, что позволяет реализовать в том числе географические ограничения; дополнительные условия окончания сессии, например закрытие браузера или выход пользователя из самой SSO-платформы. Ключевая проблема заключается в том, что некоторые облачные провайдеры неверно интерпретируют или вовсе игнорируют эти ограничения, нарушая таким образом модель безопасности, которую выстроила команда ИБ. Более того, в ряде случаев SaaS-платформы недостаточно контролируют корректность самих токенов, открывая простор для их подделки.
       
      Посмотреть статью полностью
    • KL FC Bot
      Устранение бизнес-рисков, связанных с домашними прокси
      Автор KL FC Bot
      Каждый день миллионы обычных частных пользователей Интернета вольно или невольно предоставляют свой компьютер, смартфон или домашний роутер посторонним. Они устанавливают на свои устройства proxyware — прокси-сервер, принимающий интернет-запросы этих посторонних и транслирующий их дальше в Интернет, к целевому серверу. Доступ к proxyware обычно предоставляют специализированные поставщики, которых мы дальше в статье будем называть ПДП (провайдеры домашних прокси). Иногда услугами таких ПДП компании пользуются вполне сознательно, но чаще появление их на рабочих компьютерах связано с нелегальной активностью.
      ПДП конкурируют между собой, хвастаясь разнообразием и количеством доступных для клиентов IP-адресов, счет которых идет на миллионы. Этот рынок фрагментирован, непрозрачен и создает для организаций и их ИБ-команд специфический набор рисков.
      Зачем применяются домашние прокси
      Времена, когда Интернет был один для всех, давно прошли: крупные онлайн-сервисы адаптируют контент к региону, из которого пришел конкретный запрос, многие сайты фильтруют контент, отсекая целые страны и континенты, функции одного сервиса для разных стран могут отличаться, и так далее. Изучить, настроить или обойти такие фильтры как раз позволяют домашние прокси. ПДП часто приводят в своей рекламе такие варианты применения сервиса: исследование рынка (отслеживание цен конкурентов и тому подобное), верификация показа рекламы, сбор открытой информации (web scraping), в том числе для тренировки ИИ, анализ поисковой выдачи, и так далее.
      Конечно, что все это выполнимо при помощи коммерческих VPN и прокси на базе дата-центров. Но многие сервисы умеют детектировать VPN по известным IP-диапазонам дата-центров или эвристически, а вот домашний прокси определить гораздо сложнее. Ведь он, в конце концов, работает на настоящем домашнем компьютере.
      О чем не пишут на сайтах ПДП, так это о сомнительных и откровенно вредоносных активностях, в которых систематически применяются домашние прокси. Среди них:
      проведение атак с перебором паролей, в том числе password spraying, как в недавнем взломе Microsoft; проникновение в организацию при помощи легитимных учетных данных — домашний прокси из нужного региона предотвращает срабатывание эвристических правил подозрительного входа; заметание следов кибератаки — сложнее отследить и атрибутировать источник вредоносной активности; мошеннические схемы с кредитными и подарочными картами. Применение домашних прокси позволяет обойти систему борьбы с мошенническими оплатами (antifraud); проведение DDoS-атак. Например, большая серия DDoS-атак в Венгрии была отслежена до ПДП White Proxies; автоматизация спекуляций, таких как массовая скоростная скупка дефицитных билетов на мероприятия или коллекционных товаров (sneaker bots); мошенничество в маркетинге — накрутки рекламы, реакций в соцсетях, и так далее; рассылка спама, массовая регистрация аккаунтов; сервисы по обходу CAPTCHA.  
      Посмотреть статью полностью
    • SS78RUS
      Атаковали через уязвимость NAS
      Автор SS78RUS
      Добрый вечер. 
      С нами случилась ситуация 1в1 с вышеописанной. NAS Zyxel 326 со всеми патчами, отключены все выходы во внешнюю сеть, работал только как локальное хранилище, всё равно атаковали через уязвимость самого NAS -создали облачного пользователя, которого даже удалить не могу.
      Подскажите, какой вариант с починкой файлов? Заранее спасибо.
       
      Сообщение от модератора Mark D. Pearlstone Перемещено из темы.
    • KL FC Bot
      CVE-2024-6387 aka regreSSHion — причины, риски, устранение
      Автор KL FC Bot
      В OpenSSH, популярном наборе инструментов для дистанционного управления *nix-системами, была найдена уязвимость, при помощи которой неаутентифицированный злоумышленник может выполнить произвольный код и получить root-привилегии. Уязвимость получила номер CVE-2024-6387 и собственное имя regreSSHion. Учитывая, что sshd, сервер OpenSSH, внедрен в большинство популярных ОС, многие устройства интернета вещей и другие девайсы вроде межсетевых экранов, описание уязвимости звучит как начало новой эпидемии уровня WannaCry и Log4Shell. На практике ситуация несколько сложнее, и массовой эксплуатации уязвимости, вероятно, не будет. Несмотря на это, все администраторы серверов с OpenSSH должны срочно позаботиться об устранении уязвимости.
      Где применяется OpenSSH
      Набор утилит OpenSSH встречается почти повсеместно. Это популярная реализация протокола SSH (secure shell), внедренная в подавляющее большинство дистрибутивов Linux, OpenBSD и FreeBSD, macOS, а также в специализированные устройства, например на базе Junos OS. Поскольку многие телевизоры, «умные» дверные глазки и видеоняни, сетевые медиаплееры и даже роботы-пылесосы работают на базе Linux-систем, в них тоже часто применяется OpenSSH. Начиная с Windows 10, OpenSSH есть и в ОС от Microsoft, правда, здесь это опциональный компонент, не устанавливаемый по умолчанию. Не будет преувеличением сказать, что sshd работает на десятках миллионов устройств.
       
      Посмотреть статью полностью
    • Rezored
      Закрытие уязвимостей в изолированной сети
      Автор Rezored
      Здравствуйте. Сделал по инструкции изолированный сервер https://support.kaspersky.com/KSC/14.2/ru-ru/230777.htm , но список уязвимостей формирует .bin файлы 0 длины, подскажите как можно это исправить или где посмотреть логи ошибок?
×
×
  • Создать...