Security Week 46: обход OAuth 2.0, низковольтный ICMP DDoS, приватность iOS и обход локскрина

в 14:47, , рубрики: firewall, icmp, iOS, klsw, lockscreen bypass, oauth 2.0, Блог компании «Лаборатория Касперского», информационная безопасность

Security Week 46: обход OAuth 2.0, низковольтный ICMP DDoS, приватность iOS и обход локскрина - 1Давно у нас не было научных работ по теме безопасности, и вот, пожалуйста. На европейской конференции BlackHat EU исследователи из университета Гонконга показали примеры некорректной реализации протокола OAuth 2.0, которые, в ряде случаев, позволяют украсть учетные записи пользователей. Так как речь действительно идет о научном исследовании, то и терминология соответствующая — без всяких этих «ААААА!1 Один миллиард учеток можно легко взломать через OAuth 2.0». Впрочем нет, oh wait, примерно так работа и называется (новость и само исследование).

Как бы то ни было, проблема, обнаруженная исследователями, заключается не в самом OAuth, а в его конкретных реализациях. Необходимость внедрять системы Single-Sign-On не только для веба, но и для мобильных приложений (принадлежащих не только владельцам сервисов идентификации типа Facebook и Google, но и третьей стороне) привела к тому, что стандарт OAuth 2.0 начали надстраивать кто во что горазд, не всегда соблюдая методы безопасности.

В результате авторизация пользователя местами происходит как попало: в исследовании описывается ситуация, когда авторизоваться от имени другого пользователя можно, зная только его логин (обычно это e-mail). Впрочем, описываемые сценарии атаки предусматривают наличие позиции man-in-the-middle, и возможны не всегда. Из обнаруженных в ходе исследования проблемных приложений большинство работает с китайским identity provider Sina, а из 99 исследованных аппов, поддерживающих OAuth через Google и Facebook атаке подвержены всего 17. Решить проблему можно на стороне провайдеров: если доверять данным только от самого сервера идентификации, и не доверять данным от приложения (которые могут быть подделаны по пути), то элегантный хак работать не будет.

Обнаружена DDoS атака, позволяющая вывести из строя межсетевые экраны относительно небольшим количеством запросов
Новость. Исследование центра управления безопасностью TDC Group.

Типичная DDoS-атака выводит из строя сайты скорее силой, чем умом: примером является недавняя атака на DNS-серверы Dyn мощностью до одного терабита в секунду. Вывести из строя сетевое оборудование атакой под малым напором сложнее, но все еще возможно. Специалисты датского телекома TDC наблюдали около сотни случаев атаки, которая способна вызывать отказ в обслуживании у ряда популярных моделей межсетевых экранов при мощности в 15-18 мегабит или 40-50 тысяч запросов в секунду.

Security Week 46: обход OAuth 2.0, низковольтный ICMP DDoS, приватность iOS и обход локскрина - 2

Атака, на всякий случай красиво поименованная (BlackNurse), использует протокол ICMP. В отличие от распространенной атаки типа ping flood, в данном случае на сервер отправляется множество пакетов Type 3 Code 3 (Destination Unreachable, Destination Port Unreachable). По каким-то причинам (в исследовании этот момент не раскрывается) обработка этих пакетов вызывает стопроцентную загрузку процессора межсетевого экрана, и, соответственно, отказ в обслуживании.

В заметке в блоге американского института SANS признается наличие проблемы, но она квалифицируется скорее как неправильная конфигурация: пакеты такого типа достаточно легко отфильтровать, либо изменить параметры их обработки. Отмечается, что Cisco даже не стала квалифицировать это как уязвимость. Предполагается, что после получения сообщений о недоступности брандмауэр пытается решить несуществующую проблему, анализируя предыдушие пакеты данных, на что уходят значительные ресурсы. Интересно, что метод атаки отчасти пришел к нам аж из 90-х, когда была актуальна так называемая проблема "смертельного пинга".

Опубликован три тысячи первый способ обхода экрана блокировки в iPhone
Новость.

Обход локскрина превратился в какой-то специальный вид спорта. Участники соревнуются в скоростном нажатии по всем доступным на заблокированном телефоне кнопкам и иконкам, победитель определяется исходя из успешности доступа к закрытым данным. Как и в прошлый раз, в обходе блокировки задействована Siri. Кроме того, последовательность действий начинается с попытки отреагировать на входящий звонок — нужно либо дождаться звонка на телефоне, либо спросить у Siri «Who am I?», после чего номер телефона жертвы будет показан на экране. Дальше следует шаманство, проще видео посмотреть.

Впрочем, самой обсуждаемой новостью вокруг Apple стала (предсказуемо) не эта. По данным российской компании ElcomSoft, iOS передает на серверы компании информацию о совершенных и принятых звонках по умолчанию. Единственное, что необходимо для передачи данных — использование iCloud, причем для того, чтобы телефон перестал отправлять на сервер историю звонков, синхронизацию с iCloud нужно полностью отключить. Данная история относится скорее к теме приватности, а не безопасности: по результатам обсуждения споров между Apple и ФБР в начале этого года стало понятно, что компетентные органы гораздо проще могут добыть информацию с серверов компании, а не с самого устройства, если оно заблокировано.

Что еще произошло:
Интересный доклад известного эксперта по безопасности и криптографии Брюса Шнайера цитируется в этой новости: он выступает за то, чтобы производителей IoT-устройств законодательно обязали соблюдать нормы безопасности. По мненю Шнайера, только экономических инструментов влияния на вендоров (= дырявые устройства не будут покупать) будет недостаточно (= все равно будут, всем наплевать).

Yahoo все-таки знала о краже пользовательских данных еще в 2014 году. Речь идет об утечке, информация о которой была обнародована только в сентябре этого года, когда базы начали сливать в открытый доступ.

Тем временем у сети FriendFinder украли 412 миллионов учеток, в основном с различных сайтов знакомств «для взрослых».

Security Week 46: обход OAuth 2.0, низковольтный ICMP DDoS, приватность iOS и обход локскрина - 3

Древности

«Petersburg-529»

Резидентный вирус, не опасен. Инфицирует .COM-файлы при загрузке их в память для выполнения, внедряется в начало файла. При выполнении инфицированной программы остается резидентным в памяти, совершая следующие действия:

— изменяет размер выделенной под основную программу памяти, резервируя дополнительную память для своих нужд;
— определяет имя основной программы и выполняет ее (т.е. происходит повторный запуск основной программы);
— по окончании работы программы вирус остается резидентным (int 21h, ah = 31h).

Вирус никак не проявляется и не имеет деструктивной функции.

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 79.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Автор: «Лаборатория Касперского»

Источник

Поделиться новостью

* - обязательные к заполнению поля