LiveJournal вновь подвергся DDoS-атаке

LiveJournal вновь подвергся DDoS-атаке

В понедельник и вторник пользователи и гости популярного блогохостинга испытывали проблемы с доступом к нему. Серверы демонстрировали низкую производительность, страницы загружались с трудом или в конечном счете вообще оказывались недоступны. Выдвигались различные версии о возможных причинах такого поведения сервиса; и вот вчера, 27 июля, администраторы официально заявили о нападении на LJ.


На статусной странице LiveJournal в настоящее время имеется запись следующего содержания:

"Теперь мы можем официально сообщить, что на протяжении последних двух дней против нас производилась крупномасштабная DDoS-атака, которая и явилась причиной тех проблем с сайтом, с которыми пришлось столкнуться большинству пользователей. Объем трафика и производимая им нагрузка были огромны, во много раз превышая наши обычные показатели; в настоящее время атака продолжается. Мы находимся в непрерывном контакте со своими провайдерами и предпринимаем с их помощью все возможные усилия по подавлению атаки. Повторно приносим извинения за перебои в работе LiveJournal; мы примем все меры для того, чтобы как можно скорее восстановить нормальную работу сервиса. Спасибо!"

Похоже, что администраторам все же удалось взять ситуацию под контроль: в настоящее время блогохостинг работает в обычном режиме без явных задержек в обслуживании. Остается открытым лишь вопрос о том, кому опять понадобилось нападать на LiveJournal и по какой причине. Возможно, дальнейшее расследование инцидента позволит дать интересующие пользователей ответы и установить, был ли целью сам "Живой журнал" или какие-либо конкретные блогеры. Российские сторонники теории заговоров уже получили пищу для размышлений: например, перебои в работе сервиса таинственным образом совпали с публикацией в блоге общественного активиста Евгения Ройзмана, в которой руководитель фонда "Город без наркотиков" представил сведения о возможной причастности студентов профильных вузов МВД РФ к нападению на поселок Сагра в Свердловской области.

LiveJournal уже переживал массированные DDoS-атаки весной этого года. Тогда сервис тоже отказывал пользователям в обслуживании в течение нескольких дней, и точно так же высказывались разнообразные предположения относительно вероятных причин. Истину в конечном счете обнаружить так и не удалось, и версии ("рука спецслужб", "ошибка администраторов", "происки конкурентов" и прочие) так и остались версиями. Посмотрим, удастся ли прояснить ситуацию на этот раз.

Письмо автору

Расширения 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