Уязвимость ProxyToken позволяет изменить настройки сервера Exchange

Уязвимость ProxyToken позволяет изменить настройки сервера Exchange

Уязвимость ProxyToken позволяет изменить настройки сервера Exchange

Вам было мало связки уязвимостей ProxyShell? Тогда позвольте представить ProxyToken — ещё один повод обновить установки Microsoft Exchange, чтобы не стать жертвой киберпреступников, эксплуатирующих этот баг.

Как объясняют специалисты в области кибербезопасности, киберпреступники с помощью ProxyToken могут обойти аутентификацию и даже внести изменения в конфигурацию бекэнда почтового сервера Exchange.

О проблеме рассказали сотрудники вьетнамской компании VNPT ISC: ProxyToken можно использовать для незаметной установки специального правила, перенаправляющего электронные переписки пользователя злоумышленникам. Ли Сянь Туйен из VNPT ISC сообщил об уязвимости через программу Zero-Day Initiative. Причиной наличия бага стали две проблемы в коде Exchange:

  1. Проблема аутентификации запросов, содержащих cookie под именем «SecurityToken», который перенаправляется от фронтенда бэкенду.
  2. Ответ ошибки HTTP 500, раскрывающий панель управления Exchange.

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

К счастью, Microsoft устранила баг, который отслеживается под идентификатором CVE-2021-33766 ещё в июле. Поэтому всем администраторам ещё раз настоятельно рекомендуется установить вышедшие патчи.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Роботы-официанты и курьеры оказались под угрозой удалённого взлома

Исследователь под ником BobDaHacker обнаружил серьёзную брешь в API управления роботами Pudu Robotics. Ошибка была настолько простой, что даже человек с минимальными техническими знаниями мог «угнать» любого робота — от официанта BellaBot в ресторане до робота-доставщика лекарств в больнице.

Проблема заключалась в том, что API требовал токены, но при этом не проверял права пользователя и «владение» устройством.

В итоге можно было смотреть историю вызовов, менять настройки, перенаправлять задания или даже заставить роботов крутиться по кругу.

 

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

Но в больнице или офисе последствия могли быть куда серьёзнее — от срыва доставки лекарств до кражи документов с охраняемых этажей.

BobDaHacker сообщил о проблеме ещё 12 августа, но Pudu Robotics игнорировала обращения почти три недели. Лишь после того как исследователь напрямую предупредил крупных клиентов вроде японских ресторанных сетей Skylark и Zensho, компания наконец «обнаружила» уязвимость и выпустила заплатку.

Реакция производителя вызвала не меньше вопросов, чем сама дыра. У Pudu не оказалось ни выделенного контакта для безопасности, ни прозрачного процесса обработки сообщений о проблемах. Ответ пришёл в виде шаблонного письма, где даже не удалили плейсхолдер «[Your Email Address]».

История показывает: красивые слова о «приверженности безопасности» на сайте мало что значат без реальных мер. Когда роботы обслуживают рестораны, отели, школы и особенно больницы, сбои в их работе могут обернуться не только испорченным ужином, но и угрозой для здоровья и безопасности.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

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