Более 850 000 устройств Cisco уязвимы перед эксплоитом BENINGCERTAIN

Более 850 000 устройств Cisco уязвимы перед эксплоитом BENINGCERTAIN

Более 850 000 устройств Cisco уязвимы перед эксплоитом BENINGCERTAIN

В августе 2016 года хакеры из ранее неизвестной группы The Shadow Brokers опубликовали в открытом доступе набор инструментов и экплоитов, похищенных у хакерской группы Equation Group. Многие эксперты и исследователи связывают деятельность Equation Group с американским правительством и АНБ.

Например, «Лаборатория Касперского» еще в 2015 году сообщала, что данная группа ведет свою деятельность на протяжении почти двадцати лет (с 1996 года), и ее действия затронули тысячи, а возможно и десятки тысяч пользователей в более чем 30 странах мира.

После изучения дампа, опубликованного хакерами, специалисты Cisco пришли к выводу, что некоторые эксплоиты представляют угрозу для продуктов компании. Причем впоследствии выяснилось, что проблему недооценили. Так, изначально эксперты решили, что эксплоит BENIGNCERTAIN предназначен для атак на брандмауэры PIX, поддержка для которых была прекращена еще в 2009 году, пишет xakep.ru.

Представители Cisco писали, что эксплоит неопасен для PIX версии 7.0 и выше, и не обнаружили в продуктах компании никаких уязвимостей, связанных с данным инструментом. Затем стало ясно, что BENIGNCERTAIN эксплуатирует уязвимость CVE-2016-6415 и также опасен для IOS (4.3.x, 5.0.x, 5.1.x и 5.2.x; версии 5.3.0 и выше вне опасности), IOS XE (все версии) и IOS XR (все версии). При этом представители компании сообщили, что уже были зафиксированы попытки использования BENIGNCERTAIN в деле, то есть хакеры уже взяли инструмент на вооружение.

Чтобы определить масштаб проблемы, специалисты Shadowserver Foundation и инженеры Cisco провели сканирование, призванное выявить все уязвимые устройства Cisco. Специалисты пишут, что проверяли маршрутизируемые адреса IPv4, отправляя на них специальные пакеты ISAKMP, размером 64 байта. Сканирование выявило, что по состоянию на 25 сентября 2016 года в онлайне находились 850 803 уязвимых устройства. Более 257 000 из них расположены в США, а почти 44 000 на территории России.

 

Данные на 26 сентября 2016 года

Проблема осложняется тем, что патча для CVE-2016-6415 пока нет. Кроме того, временных способов защиты от проблемы тоже не существует. Разработчики Cisco пообещали представить исправление как можно скорее.

Создатель Диспетчера задач объяснил, почему загрузка CPU в Windows врёт

Бывший инженер Microsoft Дэйв Пламмер, приложивший руку к таким знаковым вещам, как поддержка ZIP в Windows и меню «Пуск» в Windows NT, рассказал, как на самом деле Диспетчер задач считает загрузку процессора. И заодно объяснил, почему цифры в этом инструменте иногда кажутся немного странными, особенно если сравнивать их с тем, как компьютер ощущается в реальной работе.

По словам Пламмера, идея просто показать, насколько занят процессор на деле куда сложнее, чем кажется.

Вопросов тут сразу слишком много: занят чем именно, на одном ядре или на всех, прямо сейчас или в среднем за последние секунды, в пользовательском режиме или на уровне ядра? Как только начинаешь во всём этом разбираться, простая шкала загрузки уже перестаёт выглядеть такой уж простой.

Сам Диспетчер задач, как объяснил Пламмер, работает не в режиме мгновенного измерения. Он обновляет данные через определённые интервалы, то есть показывает скорее интерпретацию того, что происходило между обновлениями, а не живую картину в каждый конкретный момент. Поэтому цифры на экране — это всегда усреднённый результат, а не моментальный снимок состояния процессора.

Самым очевидным решением мог бы быть простой расчёт по времени между обновлениями интерфейса. Но Пламмер от такого подхода отказался: он посчитал, что полагаться на точность GUI-таймера — идея так себе. Он даже сравнил это с попыткой доверить точный ритм метронома, который едет в кузове пикапа по разбитой дороге.

Вместо этого он заложил в Диспетчер задач другой принцип. Утилита запрашивает, сколько процессорного времени каждый процесс суммарно использовал с момента запуска (отдельно в пользовательском и системном режимах).

Затем из нового значения вычитается предыдущее, полученное во время прошлого обновления. Так определяется, сколько CPU-времени процесс съел за конкретный промежуток. А дальше это сравнивается с общим объёмом процессорного времени, которое было израсходовано всеми процессами за тот же период.

Звучит не очень просто, но именно такой метод, по словам Пламмера, даёт более точный результат, чем грубый расчёт по таймеру. Проблема в другом: современные процессоры стали намного сложнее, чем во времена, когда создавался классический Диспетчер задач.

Сегодня на работу CPU влияют динамическое изменение частоты, турбобуст, тепловые ограничения, глубокие режимы простоя и другие механизмы. Из-за этого один и тот же процент загрузки уже не всегда означает один и тот же объём реально выполненной работы. Пламмер привёл образное сравнение: современная загрузка CPU больше похожа не на пройденное расстояние, а на загруженность шоссе. Полупустая трасса с быстрыми спорткарами может перевезти больше, чем полностью забитая дорога со старыми грузовиками.

Именно поэтому Диспетчер задач иногда может показывать вроде бы нестрашные цифры, хотя компьютер при этом ощутимо тормозит (или наоборот). Дело не обязательно в ошибке инструмента. Просто сам показатель загрузки процессора уже давно перестал быть идеальным универсальным маркером производительности.

RSS: Новости на портале Anti-Malware.ru