Серверы Amazon AWS вскоре могут стать жертвами атак вымогателей

Серверы Amazon AWS вскоре могут стать жертвами атак вымогателей

Серверы Amazon AWS вскоре могут стать жертвами атак вымогателей

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

Об этом сообщил исследователь Кевин Бомонт, отметив, что с серверами Amazon AWS S3 связаны крупнейшие утечки прошлого года — например, нарушения данных АНБ, армии США и поставщиков аналитики.

Причиной этих инцидентов стало то, что компании оставляли данные на общедоступных «ведрах» S3 («ведро» — термин, используемый для описания блока хранения S3). В большинстве случаев эти данные были обнаружены исследователями безопасности, которые помогали компаниям защищать свои системы. Однако некоторая чувствительная информация попала и в руки киберпреступников.

Как отмечают эксперты, есть нечто более опасное, чем доступные для чтения извне серверы — это доступные для записи извне «ведра», позволяющие любому пользователю, с учетной записью Amazon S3 или без нее, писать или удалять данные на AWS S3. В опубликованному в сентябре 2017 года отчете Skyhigh Networks утверждается, что 7 % всех ведер Amazon AWS S3 доступны для записи извне.

Таким образом, специалисты считают, что киберпреступники, которые в прошлом атаковали серверы MongoDB, ElasticSearch, Hadoop, CouchDB, Cassandra, MySQL, теперь могут переключиться на доступные для записи S3-ведра.

Схема таких атак всегда одна — злоумышленники обнаруживают уязвимый сервер, удаляют на нем информацию, после чего требуют выкуп за восстановление данных.

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

Кац считает, что в случае с S3 киберпреступники будут удалять данные безвозвратно, так как такой большой объем информации нельзя будет разместить у себя. Также специалисты подчеркивают, что основная проблема кроется во владельцах учетных записей, которые неправильно настраивают серверы.

Еще один эксперт, Робби Виггинс, обеспокоенный этой проблемой, нашел тысячи проблемных серверов с неправильными настройками. Виггинс уведомил владельцев, а также опубликовал в Twitter запись, в которой утверждает, что таких серверов было обнаружено 5260.

Виггинс оставил на доступных для записи «ведрах» текстовый файл, в котором содержалась следующая информация:

«Это предупреждение о том, что ваши настройки Amazon AWS S3 неверны. Любой может писать в это ведро. Исправьте это, прежде чем злоумышленник найдет эту лазейку».

Также похожее предупреждение оставил неизвестный хакер, с ним можно ознакомиться ниже:

Напомним, что в сентябре прошлого года мы сообщали о кибератаках вымогателей на MongoDB.

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

Этот механизм, пришедший на смену webRequest API, позволяет расширениям сообщать браузеру, что следует изменить или заблокировать на загружаемой странице (заголовки, реклама, трекеры).

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

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

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

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