Apple
Что случилось с Yahoo? Как любит писать британское издание The Register, у Yahoo! на! прошлой! неделе! украли! полмиллиарда! паролей! (новость! официальное! заявление! Yahoo!) В предыдущей серии я кратко упомянул это событие, посчитав его масштабным, но не настолько значимым, чтобы дополнительно растекаться мыслью по древу.
Ан нет. И дело не в том, что украли очень много паролей: предположительно взлом инфраструктуры Yahoo! случился! (вот, опять) в 2014 году, а сейчас базы поступили в свободную продажу в Дарквебе. На фоне других взломов количественные характеристики хака впечатляют, но все же давно в курсе, что парольная защита — устаревший и неэффективный инструмент.
Интересно то, как Yahoo и другие реагировали на данный инцидент. В процессе обсуждения взлома вскрылось много интересных деталей, исследователи обратили внимание на нынешнее состояние инфраструктуры, видимой со стороны, и признали, что там все не так хорошо, как хотелось бы (новость этой недели). В утекшей базе помимо паролей хранились номера телефонов и другая личная информация, а часть паролей была захеширована признанным ненадежным алгоритмом MD5.
Но самое интересное в этой истории — последствия киберинцидента для крупной и публичной компании. Возникли справедливые упреки в том, что в самой Yahoo могли знать об инциденте и скрывали эту информацию (последнее могло произойти и по миллиону уважительных причин). Позавчера New York Times со ссылкой на анонимных инсайдеров сообщила, что в компании банально экономили на средствах безопасности, включая системы обнаружения взлома.
Список предыдущих серий тут.
Дошло до того, что утечку паролей обсуждают в американском конгрессе, ведь в самой Yahoo предполагают, что атака была спонсирована государством. Ряд экспертов, впрочем, это предположение убедительно оспаривают — характер атаки напоминает аналогичные взломы LinkedIn и MySpace, в обсуждении которых политики было гораздо меньше.
Как бы то ни было, история Yahoo становится показательной с точки зрения методов реагирования на киберинциденты. Взломы рано или поздно случаются, и очевидно, что нужны стратегия и инструменты их обнаружения и нейтрализации. Чем быстрее, тем лучше — меньше будет издержек.
Но дело не только в этом. Некий социальный протокол раскрытия информации о взломах также не проработан, а ведь было бы неплохо. Судя по наработанному опыту, максимальная открытость по части деталей взлома (хороший пример можно посмотреть здесь) и шагов по решению проблемы воспринимается наиболее позитивно всеми причастными, включая возможных пострадавших.
И еще. Если описанная в New York Times ситуация действительно имела место, получается, что менеджмент Yahoo не только экономил на инвестициях в безопасность. Принимались решения, в которых приоритет отдавался не защите, а удобству пользователей, вопросам сохранения клиентской базы и подобному. Бюджет — это дело тонкое, денег никогда много не бывает, но стратегия «от нас все уйдут, если мы будем сбрасывать пароли при каждом подозрении на взлом», уж точно обречена на неминуемый провал. Кстати, пойду-ка я пароль поменяю.
Apple снизила стойкость бэкапов к брутфорсу в iOS 10. Никто не знает зачем
Новость. Статья в блоге Elcomsoft.
По непонятным причинам компания Apple снизила защищенность бэкапов для недавно выпущенной версии iOS 10. Речь идет о резервной копии всех данных с iPhone или iPad, которая сохраняется на компьютере пользователя через iTunes. Уже довольно давно бэкапы шифруются, и в данном случае стойкость шифрования не вызывает сомнений. Сомнения вызывает стойкость бэкапов к перебору паролей.
Диспут между Apple и ФБР в начале этого года дал понять, что взломать сам iPhone, если он защищен стандартными средствами системы, достаточно сложно. Бэкап представляет собой очевидное уязвимое звено: он хранится на компьютере, который в большинстве случаев легче взломать, чем сам телефон (даже если это Mac), и, в отличие от телефона, не самоуничтожается при попытке его разобрать противоправными методами. А данные там сохранены абсолютно все, включая пароли из системы хранения KeyChain.
Так вот, по словам специалиста компании Elcomsoft Олега Афонина, проблема заключается в привязке бэкапов iOS 10 к алгоритму хеширования паролей SHA-256 с единственной итерацией. В iOS 9 использовался более стойкий к перебору алгоритм PBKDF2 SHA-1 с 10 000 итераций.
Elcomsoft специализируется на разработке ПО для обхода защиты различных устройств и софта, и, по их данным, изменение алгоритма позволяет радикально увеличить скорость перебора паролей — со 150 тысяч до 6 млн в секунду. В результате бэкап теоретически возможно взломать за двое суток с 80–90-процентной вероятностью, и это если пароль установлен мало-мальски сложный. Если совсем простой — и того быстрее. Никакого другого объяснения такому «апгрейду», кроме ошибки, эксперты не придумали. Что, в общем, и признала сама Apple, пообещав в будущем вернуть стойкость на место.
КапитанИсследователь сообщает о макротрояне, пытающемся спрятаться от анализа
Самая популярная новость на Threatpost за неделю рассказывает о вредоносной программе, распространяющейся через зараженные документы Word, которая достаточно базовыми методами пытается скрыть свое реальное предназначение. Исследователь из компании SentinelOne (статья у них в блоге) описывает довольно стандартную ситуацию: пользователю приходит письмо с вложением, открывается офисный документ, появляется предложение включить макросы, пользователь (конечно же) говорит «Да» или, в зависимости от локали, «I do». Дальше начинается чуть более интересное.
Во-первых, запустившийся вредоносный код пытается через внешний сервис пробить IP машины, на которой запущен, а также название организации, с которой ассоциирован IP. Если название совпадает с данными из зашитого внутрь списка (в котором в основном имена производителей защитного ПО, причем «Лаборатории» там нет), то дальше ничего не происходит.
Ничего не происходит и в том случае, если быстрый поиск по системе не выдает ни одного офисного документа, — очевидно, таким образом проверяется запуск вредоносного кода на виртуальной или просто на тестовой системе. Если все проверки проходят успешно, скриптом в Powershell скачивается и запускается кейлоггер.
Это интересные детали современной малвари из булки и спичек, но, откровенно говоря, попытка каким-то образом уйти от обнаружения — это совершенно распространенная и многолетняя практика писателей вредоносного кода. Единственным значимым моментом является использование макросов в Word в комбинации с такими фокусами. Макромалварь была относительно недавно поднята из небытия писателями криптолокеров. В данном случае выкуп никто не требует, но это хоть какое-то усложнение довольно простой угрозы, которая блокируется любым приличным решением на раз — да хотя бы на этапе попытки скачать кейлоггер.
На самом деле такие приемы вряд ли смутят опытного или просто настойчивого исследователя. Более интересные примеры сокрытия истинного назначения кода можно посмотреть в истории про Lurk. Рано или поздно тайное становится явным.
Гораздо важнее выявлять и блокировать мимикрирующую малварь автоматизированными средствами. Здесь используется масса весьма оригинальных решений, которые, увы, обычно остаются непубличными (вот, например, одно исключение) — как из-за глубоко технической специфики, так и из-за нежелания делиться с киберпреступниками методами детектирования вредоносов с повышенной хитростью.
Древности
«Typo-867»
Нерезидентный опасный вирус. Стандартно поражает .COM-файлы. После окончания работы зараженного файла оставляет в памяти небольшую резидентную программу, которая подменяет некоторые знаки, вводимые с клавиатуры. На время работы зараженного файла устанавливает на себя прерывания 16h, 20h, 21h.
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 86.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Советы