Новая утечка в Twitter: соцсети предлагают выкупить данные 400 млн юзеров

Новая утечка в Twitter: соцсети предлагают выкупить данные 400 млн юзеров

Новая утечка в Twitter: соцсети предлагают выкупить данные 400 млн юзеров

На хакерском форуме Breached появилось объявление о продаже ПДн более 400 млн твиттерян. Автор сообщения, некто Ryushi, предложил Twitter и Илону Маску выкупить базу во избежание штрафных санкций за нарушение европейского регламента по защите данных (GDPR); в противном случае лот будет распродаваться по частям.

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

В подтверждение качества товара продавец приводит четыре десятка записей с ПДн известных персон: политиков, журналистов, телеведущих. В частности, слиты данные Дональда Трампа-младшего, ИБ-исследователя и блогера Брайана Кребса, создателя блокчейн-проекта Ethereum Виталика Бутерина.

Позднее на том же форуме был опубликован более объемный дамп — данные еще 1000 Twitter-профилей, в том числе юрлиц. Записи содержат такую информацию, как имейл, имя, юзернейм, число читателей, дата создания аккаунта, иногда номер телефона. Почти все эти сведения, кроме адресов электронной почты и телефонных номеров, доступны любому твиттерянину.

 

В объявлении о продаже упоминается уязвимость, позволившая Ryushi собрать столь внушительную базу. В комментарии для BleepingComputer продавец уточнил, что это та же уязвимость в API Twitter, которую использовал его коллега по цеху для получения данных 5,4 млн твиттерян.

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

Уязвимость устранили почти год назад, в январе, однако ею успели воспользоваться разные киберпреступники, в том числе Ryushi. Подлинность данных, выложенных им в качестве образца, подтвердили в израильской ИБ-компании Hudson Rock; эксперты BleepingComputer смогли проверить только две записи и пришли к тому же выводу.

В Twitter новую утечку пока не комментируют, призывы хакера воспользоваться эксклюзивом тоже остались без ответа. Тем временем ирландская Комиссия по защите данных (Data Protection Commission, DPC) начала расследование в связи с утечкой ПДн 5,4 млн твиттерян, о которой стало известно в июле. По итогам Twitter могут обвинить в нарушении GDPR.

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

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

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

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

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

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