Злоумышленники крадут идентификационные данные, используя Cisco WebVPN

Злоумышленники крадут идентификационные данные, используя Cisco WebVPN

Специалисты компании Volexity обнаружили атаку, нацеленную на Cisco Clientless SSL VPN (WebVPN). Данный продукт позволяет клиентам Cisco ASA устанавливать удаленный доступ к корпоративной сети, через веб-портал.

С помощью Cisco WebVPN пользователи получают доступ к внутренним файлам и ресурсам в сети компании, используя VPN, что, по идее, должно защищать их от хакеров. На деле хакеры нашли способы компрометации Cisco WebVPN.

Volexity рассказали, что в зафиксированных ими случаях, под атакой оказывается страница ввода логина и пароля. Первый метод, используемый злоумышленниками – эксплуатация уязвимости CVE-2014-3393, обнаруженной еще в октябре 2014 года. Ошибка возникает вследствие бага в механизме авторизации фреймворка Scanbox. Эксплуатируя брешь, хакеры способны изменять содержимое WebVPN-портала на произвольное, более того, внесенные ими изменения «выживают» даже после перезагрузки устройства и апгрейда ASA.

Хотя компания Cisco оперативно выпустила исправление для данного бага (еще в прошлом году), исследователь, обнаруживший уязвимость, тоже не сидел сложа руки. Он не только опубликовал детали бага, но и представил соответственный модуль для Metasploit. Не удивительно, что в феврале 2015 года были зафиксированы первые атаки с использованием данной уязвимости, а Cisco пришлось выпустить подробные инструкции о том, как обнаружить и обезвредить вредоносный код, внедренный таким образом.

Теперь специалисты Volexity сообщают, что наблюдали атаку, в ходе которой злоумышленники, эксплуатируя CVE-2014-3393, внедрили вредоносный JavaScript в код страницы авторизации крупной фирмы. Он воровал учетные данные сотрудников из аутентификационной формы, притом осторожно — используя HTTPS. В ходе другой атаки, замеченной Volexity, атакующие вообще хостили малварь на взломанной сайте легитимной общественной организации, что тоже, до поры до времени, не вызывало подозрений.

Однако атакующие не всегда применяли эксплоит для компрометации Cisco WebVPN. Специалисты Volexity заметили, что в ряде случаев хакеры каким-то образом сначала получали административный доступ к системе, и уже после этого изменяли страницу ввода логина и пароля.

От рук неизвестных хакеров пострадали медицинские и некоммерческие организации, НИИ, общеобразовательные учреждения, а также различные компании-производители электроники.

Представители Cisco сообщили, что знают об отчете, опубликованном Volexity, напомнили, что патч для CVE-2014-3393был выпущен еще в прошлом году и посоветовали пользователям внимательнее конфигурировать свои системы.

Windows 11 после обновления может отрезать вас от проводного интернета

Похоже, у сисадминов снова «праздник»: в сообществе r/sysadmin на площадке Reddit обсуждают баг апгрейдов Windows 11, из-за которого рабочие станции после обновления внезапно теряют проводную 802.1X-аутентификацию и остаются без Сети.

Сценарий звучит неприятно: обновляете машину «поверх» (например, с 23H2 на 25H2; люди пишут, что это повторяется и на ежегодных переходах), перезагружаетесь — и всё, Ethernet молчит.

Причина, согласно описанию участников обсуждения, в том, что после апгрейда папка dot3svc оказывается очищенной, а вместе с ней пропадают политики / профили, которые нужны Wired AutoConfig для 802.1X.

Wired AutoConfig (dot3svc) — это тот самый компонент Windows, который держит проводной 802.1X в рабочем состоянии. А его политики лежат как раз в директории C:\Windows\dot3svc\Policies (плюс есть папки для миграции во время апгрейда). И вот когда эти файлы исчезают / не мигрируют корректно, машина не может пройти 802.1X на коммутаторе и получить доступ к корпоративной сети.

Самое злое тут — эффект «замкнутого круга». Без сети устройство не может дотянуться до контроллеров домена, чтобы подтянуть Group Policy и восстановить настройки автоматически. Поэтому в полях лечат по старинке: подключают устройство в «открытый» порт без 802.1X, делают gpupdate /force (часто именно /target:computer), и только потом возвращают на защищённый порт.

Есть и ещё один баг: в отдельных кейсах при апгрейде люди жаловались на проблемы с машинными сертификатами, что особенно больно организациям на EAP-TLS (когда 802.1X завязан на PKI).

При этом самое обидное — на официальных страницах Windows Release Health для 24H2 и 25H2 упоминаний про 802.1X/dot3svc в списке известных проблем сейчас не видно.

Что с этим делать прямо сейчас, если вы планируете массовые апгрейды: многие админы советуют хотя бы заложить «страховку» в процесс — например, заранее сохранить содержимое C:\Windows\dot3svc\Policies и вернуть его после обновления, либо обеспечить доступ к сети через временно открытый порт, чтобы успеть прогнать gpupdate.

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