MEGANews. Основные события июня

 

Microsoft купила GitHub

В начале июля 2018 года стало известно, что компания Microsoft покупает крупнейший хостинг репозиториев GitHub за 7,5 миллиарда долларов. Многих пользователей грядущая сделка не на шутку встревожила, после чего в Сети стали появляться петиции против слияния, а операторы GitLab, BitBucket и SourceForge сообщили о значительном приросте трафика — разработчики тысячами перемещают свои проекты на другие хостинги.

Представители Microsoft поспешили выпустить официальное заявление, в котором сообщили, что осознают всю ответственность перед сообществом разработчиков, практически не собираются вмешиваться в работу GitHub и он продолжит независимое существование, по-прежнему оставаясь полностью открытым и бесплатным. Однако речь также шла об использовании GitHub для продвижения решений Microsoft, и сообщество, разумеется, интересовали подробности.

После слияния пост CEO GitHub получит Нэт Фридман (Nat Friedman), в настоящее время один из вице-президентов Microsoft. В компанию Фридман попал после создания фирмы Xamarin, занимавшейся разработкой кросс-платформенной имплементации .NET. В 2016 году Microsoft купила Xamarin. Стоит отметить, что ключевая часть стека Xamarin была опенсорсной, а еще одна компания, основанная Фридманом в девяностых, Ximian, и вовсе была создана для разработки решений, связанных с GNOME.

Текущий глава GitHub и один из сооснователей платформы, Крис Ванстрас (Chris Wanstrath), сложит с себя полномочия и станет техническим консультантом Microsoft. Вместе с Фридманом он будет работать под началом исполнительного вице-президента Скотта Гатри (Scott Guthrie), отвечающего за Microsoft Cloud и развитие технологий искусственного интеллекта.

Хотя Фридман еще не вступил в новую должность, диалог с сообществом он начал уже сейчас. Вскоре после официального объявления о грядущей сделке будущий CEO GitHub пообщался с пользователями Reddit (в рамках серии вопросов и ответов AMA). Как нетрудно догадаться, в первую очередь Фридман хотел ответить на тревожащие комьюнити вопросы о слиянии компаний.

Так как сделка еще не закрыта (это должно произойти до конца 2018 года), Фридман мог говорить не обо всем, однако общее представление о планах Microsoft из его ответов получить все же возможно. Фридман дал понять, что Microsoft, как и было заявлено ранее, не планирует серьезно менять GitHub и вмешиваться в его работу. Отвечая на вопрос о грядущих переменах, Фридман написал, что «Microsoft покупает GitHub, потому что ей нравится GitHub», а также стремится лишь к тому, чтобы «GitHub стал еще лучше как GitHub».

При этом Фридман сообщил, что можно ожидать полной интеграции с сервисами Visual Studio, но без каких-либо радикальных изменений, которые создадут неудобства пользователям. Будущий CEO заверил, что работа над Atom и Visual Studio Code будет продолжена, так как разработчики очень требовательны к своим инструментам, и пользователи Visual Studio Code определенно не будут рады, если их силой заставят перейти на Atom, и наоборот.

Конечно, Фридмана не могли не спросить о возможном появлении рекламы в публичных репозиториях (ответ прост: ее не будет) и о том, как он относится к оттоку пользователей на GitLab и другие сервисы.

«Разработчики — люди независимые в своих суждениях, люди, которые всегда имеют здоровую толику скептицизма, но признаю, я был расстроен тем, что некоторых это подтолкнуло полностью переместить свой код. Я беру на себя ответственность и серьезно постараюсь заслужить их доверие», — ответил Фридман.

Еще больше багов в процессорах

Обнаруженные в прошлом месяце новые варианты уязвимостей Meltdown и Spectre лишний раз доказали, что серьезные проблемы, связанные с side-channel-атаками, еще не скоро останутся позади.

В этом месяце исследователи рассказали сразу о нескольких новых «процессорных» уязвимостях и возможных методах борьбы с атаками на такие баги.

Lazy FP state restore

Эксплуатация проблем Meltdown и Spectre напрямую связана с тем, что все современные процессоры используют архитектуру с внеочередным (out-of-order) и одновременно упреждающим (или спекулятивным — speculative) механизмом исполнения команд. Новая проблема, получившая идентификатор CVE-2018-3665 и название Lazy FP state restore, также относится к side-channel-атакам, связанным со спекулятивным исполнением команд.

О новой бреши в безопасности сообщили сами инженеры Intel. За обнаружение бага специалисты поблагодарили сотрудников Amazon Germany, Cyberus Technology GmbH и SYSGO AG. Также они призвали исследователей и производителей пока не разглашать детальную информацию о проблеме, дав производителям и пользователям больше времени на выпуск и установку патчей.

Уже после выхода официальной публикации Intel собственные бюллетени безопасности поспешили представить и другие разработчики, в том числе RedHat, OpenBSD, DragonFlyBSD, Linux, Xen Hypervisor, Microsoft. Некоторая несогласованность действий была вызвана тем, что команды OpenBSD и DragonflyBSD рассказали о патчах для новой проблемы раньше срока: Intel планировала скоординированно раскрыть детали уязвимости в конце июня 2018 года, но в итоге была вынуждена пересмотреть планы.

CVE-2018-3665 представляет опасность для процессоров Intel Core, вне зависимости от того, какая ОС установлена на проблемной машине. Уязвимые процессоры в любом случае используют функцию Lazy FPU context switching, созданную для оптимизации производительности. Так, она позволяет операционным системам хранить и восстанавливать регистры FPU (Floating Point Unit, модуль операций с плавающей запятой или точкой) только в случае необходимости. Уязвимость позволяет сторонним процессам получить доступ к этим регистрам и всем содержащимся в них данным.

Инженеры Intel сообщили, что проблема Lazy FP state restore во многом похожа на Spectre, вариант 3а, и ее практически невозможно эксплуатировать через браузеры, в отличие от бага Meltdown. Также разработчики заверяют, что уязвимость уже была устранена во многих ОС и гипервизорах, использующихся в самых разных клиентах и решениях для дата-центров. В настоящее время производители софта работают над патчами для еще не обновленных продуктов, и исправления должны быть опубликованы в ближайшие недели.

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

TLBleed

В конце июня стали известны подробности о новой «процессорной» проблеме TLBleed. Именно из-за этой уязвимости разработчики OpenBSD решили отказаться от поддержки технологии Hyper-Threading в процессорах Intel, о чем также стало известно в этом месяце. Подробный доклад о TLBleed будет представлен в августе 2018 года на конференции Black Hat, а пока с обнаружившими проблему специалистами пообщались журналисты издания The Register.

Авторами доклада выступают исследователи из Амстердамского свободного университета. Они рассказали журналистам, что обнаружили способ обхода защиты буфера ассоциативной трансляции (Translation lookaside buffer, TLB).

Баг позволяет извлекать криптографические ключи и другие важные данные из других запущенных программ, причем коэффициент успешности атаки равняется минимум 98%. Точный результат зависит от используемого процессора: процент успешных атак при использовании Intel Skylake Core i7-6700K равен 99,8%, при использовании серверных процессоров Intel Broadwell Xeon E5-2620 v4 — 98,2%, а процессоры Coffeelake дают 98,8%.

В частности, атака позволяет извлекать из сторонних программ 256-битные криптографические ключи, используемые для подписания данных, во время выполнения операции подписи с помощью имплементации libgcrypt Curve 25519 EdDSA. На подбор одного ключа (с использованием машинного обучения и брутфорса) в среднем требуется лишь 17 секунд.

TLBleed не связана со спекулятивным исполнением команд, то есть не имеет отношения к нашумевшим уязвимостям Meltdown и Spectre. В данном случае брешь связана со слабыми местами технологии Hyper-Threading и тем, как процессоры кешируют данные.

Как нетрудно понять из названия, TLBleed атакует буфер ассоциативной трансляции (Translation lookaside buffer, TLB), то есть специализированный кеш процессора, используемый для ускорения трансляции адреса виртуальной памяти в адрес физической памяти. От ранее известных side-channel-атак на кеш TLBleed отличает то, что уже существующая защита от side-channel-атак на кеш памяти не гарантирует защиты от слежки за TLB.

Во время атаки на TLBleed происходит эксплуатация собственной имплементации Intel для идеи одновременной многопоточности (Simultaneous Multi-Threading, SMT), также известной под маркетинговым названием Hyper-Threading. После включения Hyper-Threading один физический процессор и одно физическое ядро определяются операционной системой как два отдельных процессора и два логических ядра. В итоге процессор может работать с несколькими потоками одновременно (как правило, их количество равно двум). При этом ресурсы и инфраструктура ядра остаются для потоков общими, включая и TLB.

За счет использования общих ресурсов программы, запущенные на одном ядре, могут «шпионить» за потоками друг друга. То есть открывается возможность для исполнения так называемых атак по времени (timing attack) — разновидности side-channel-атак, в ходе которой преступник пытается скомпрометировать систему с помощью анализа времени, затрачиваемого на исполнение тех или иных криптографических алгоритмов. Так, один поток может извлекать информацию из другого, следя за таймингом обращений к конкретным ресурсам и сравнивая эти данные с тем, как должно работать атакуемое приложение (основываясь на его исходных кодах). Искусственный интеллект, отслеживая изменения в TLB, помогает определить, когда целевая программа исполняет важные операции.

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

«Без паники, хотя атака очень крутая, TLBleed — это не новая Spectre», — заявил один из авторов исследования журналистам The Register.

При этом инженеры Intel сообщили, что не собираются выпускать каких-либо специальных патчей для устранения TLBleed. В компании полагают, что уже существующих контрмер, направленных против side-channel-атак, вполне достаточно для защиты от TLBleed, при условии, что разработчики будут писать код правильно. В результате проблеме даже не был присвоен собственный идентификатор CVE, и компания отказалась выплачивать исследователям вознаграждение по программе bug bounty, хотя отчет об уязвимости был направлен Intel через платформу HackerOne.

Специалисты из Амстердамского свободного университета сообщили представителям The Register, что они не согласны с такой точкой зрения. Они подчеркивают, что идеальный софт, написанный как решение, устойчивое перед любыми side-channel-атаками, встречается крайне редко и бороться с проблемой TLBleed исключительно с помощью хороших кодерских практик — это вряд ли удачная идея.

SafeSpec

Но далеко не все ИБ-специалисты заняты поиском новых уязвимостей. Сводная группа исследователей из Университета Калифорнии в Риверсайде, Колледжа Вильгельма и Марии, а также Бингемтонского университета опубликовала доклад о технике SafeSpec, которая позволит бороться с рисками, связанными со спекулятивным исполнением команд, и атаками на такие уязвимости, как Spectre и Meltdown.

Специалисты предлагают изолировать все опасные артефакты, которые возникают в ходе спекулятивного исполнения команд, чтобы те не могли быть использованы для получения доступа к привилегированным данным. SafeSpec описывается как «принцип разработки, когда спекулятивные состояния хранятся во временных структурах, недоступных посредством committed instructions».

Эти временные, или «теневые», структуры, как их называют в докладе, модифицируют иерархию памяти таким образом, чтобы спекулятивные атаки были невозможны. Специалисты уверяют, что их методика позволяет защититься от всех ныне известных side-channel-атак, эксплуатирующих различные варианты проблем Spectre и Meltdown, а также похожих проблем, к примеру упомянутой Lazy FP.

Авторы методики признают, что внедрение SafeSpec потребует от Intel и других производителей процессоров внесения глубоких изменений для отделения спекулятивных структур от перманентных. Кроме того, применение SafeSpec потребует увеличения кеша L1, однако, по словам экспертов, аппаратные изменения все же будут минимальными.

Если говорить о производительности, то авторы техники SafeSpec уверяют, что она может даже улучшить быстродействие систем, в отличие от патчей против Spectre и Meltdown, которые лишь замедляют работу компьютеров.

Представители Intel пока никак не прокомментировали идею авторов SafeSpec, так как инженеры компании впервые увидели доклад специалистов одновременно со всем остальным миром.

Криптовалютные биржи грабят

Преступления, так или иначе связанные с криптовалютами, в последнее время стали одними из наиболее распространенных и прибыльных для преступников. Однако в июне хакеры просто превзошли себя и стали причиной сразу нескольких крупных происшествий.

Ограбление Coinrail

В середине июня 2018 года администрация южнокорейской криптовалютной биржи Coinrail заявила о взломе. С серверов компании были похищено порядка 30% всего альткойн-портфеля биржи, в частности ICO-токены проектов Pundi X (NPXS), NPER (NPER) и Aston (ATX).

Coinrail можно назвать сравнительно небольшой биржей: она замыкает список топ-100 по версии ресурса CoinMarketCap.

Сразу после официального объявления об инциденте сайт биржи временно прекратил работу, а все оставшиеся 70% средств были перемещены на холодные кошельки. В настоящее время проводится расследование случившегося, и разработчики Coinrail уверяют, что тесно сотрудничают с пострадавшими ICO-проектами и другими обменниками и биржами, стремясь «заморозить» украденные токены и блокировать кошельки преступников. Сообщается, что совместными усилиями уже удалось блокировать почти две трети украденных средств.

Хотя представители Coinrail не озвучили точную сумму, оказавшуюся в руках неизвестных взломщиков, южнокорейское издание Yonhap и разработчики Pundi X пишут, что ущерб составил порядка 40 миллиардов вон, то есть около 37 миллионов долларов США.

Ограбление Bithumb

Не успело криптовалютное сообщество оправиться от известия о взломе Coinrail, как произошло еще одно не менее масштабное ограбление. Вновь взломали одну из крупнейших криптовалютных бирж в мире, Bithumb. На этот раз неизвестные злоумышленники похитили 35 миллиардов вон, то есть около 31 миллиона долларов в криптовалюте. Согласно информации, размещенной на официальном сайте Bithumb, инцидент произошел в ночь с 19 на 20 июня 2018 года.

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

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

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

Это не первое ограбление, жертвой которого стала Bithumb. В июле 2017 года биржа уже подвергалась компрометации. Тогда со счетов ресурса было похищено неизвестное количество Bitcoin и Ethereum.

Взлом разработчиков Syscoin

Еще один инцидент, имевший место в этом месяце, не был связан с криптовалютными биржами, однако имел прямое отношение к криптовалюте Syscoin и воровству.

Разработчики Syscoin предупредили пользователей о взломе своего аккаунта на GitHub и официального репозитория проекта. Команда объяснила, что атакующие каким-то образом сумели скомпрометировать одного из разработчиков Syscoin и его учетные записи.

9 июня 2018 года неизвестные подменили вредоносной версией официальный клиент для Windows (версия 3.0.4.1), опубликованный на GitHub. Подмена оставалась незамеченной вплоть до утра 13 июня 2018 года, и в итоге нечто странное заподозрили не разработчики, а пользователи. Дело в том, что установка зараженного клиента привлекла внимание Windows Defender SmartScreen и другого защитного ПО, которое уведомляло пострадавших об обнаружении вредоносной активности.

Все пользователи, загружавшие официальный клиент (файлы syscoincore-3.0.4-win32-setup.exe и syscoincore-3.0.4-win64-setup.exe) в указанный отрезок времени, оказались заражены малварью. Интересно, что опубликованные на GitHub клиенты для Mac и Linux злоумышленники не тронули.

Хакеры оснастили свою версию клиента малварью Arkei Stealer, которая обнаруживается антивирусными решениями как Trojan:Win32/Feury.B!cl. Данный вредонос специализируется на обнаружении и похищении приватных ключей от криптовалютных кошельков.

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

Разработчики Syscoin принесли сообществу свои извинения и пообещали, что теперь все сотрудники, у которых есть доступ к GitHub, будут обязаны использовать двухфакторную аутентификацию, а также всегда производить проверки сигнатур файлов перед загрузкой.

Новые проблемы MalwareTech

Проблемы с американскими властями начались у британского ИБ-специалиста Маркуса Хатчинса (Marcus Hutchins), более известного в Сети под псевдонимом MalwareTech, еще в августе прошлого года, во время визита на конференции Black Hat и DEF CON в Лас-Вегасе. Хатчинса, который весной 2017 года в одиночку остановил распространение шифровальщика WannaCry, арестовали и обвинили в создании и распространении банковского трояна Kronos в 2014–2015 годы.

Первое заседание по делу Хатчинса состоялось 14 августа 2017 года. На суде исследователь заявил о своей невиновности по всем пунктам обвинения, а адвокаты MalwareTech выразили убежденность, что после представления улик Хатчинс будет полностью оправдан. Так как, по мнению прокурора, исследователь более не представлял опасности, ему разрешили пользоваться интернетом, а также позволили перебраться в Лос-Анджелес, где расположен офис компании Kryptos Logic, в которой он работает (впрочем, работать в США он не имеет права с юридической точки зрения). Тем не менее до окончания судебных разбирательств специалист все равно не может покинуть страну и снять GPS-трекер. За прошедший год эти обстоятельства никак не изменились, и Хатчинс по-прежнему вынужден оставаться на территории США.

Как стало известно в начале июня, положение MalwareTech, к сожалению, лишь продолжает ухудшаться. Согласно новой версии обвинительного заключения, к предыдущим обвинениям добавились еще четыре. Теперь Хатчинса обвиняют в создании и продаже не только банкера Kronos, но еще и малвари UPAS Kit.

Сторона обвинения заявляет, что UPAS Kit «использовал формграббер и веб-инжекты, чтобы перехватывать и собирать данные с защищенных персональных компьютеров», а также «позволял осуществить неавторизованное извлечение данных с защищенных компьютеров». Также следствие утверждает, что в июле 2012 года MalwareTech продал эту малварь человеку, известному как Aurora123, который затем использовал вредонос для атак на американских пользователей.

Кроме того, обвинители считают, что после ареста, в августе 2017 года, Хатчинс на допросе лгал агентам ФБР. Тогда Хатчинс якобы заявил, будто вплоть до 2016 года и первого детального анализа Kronos он не знал, что ранее написанный им код является частью вредоноса (подробнее об этом аспекте мы рассказывали здесь). Как утверждают представители ФБР, позже специалист сознался, что в 2014 году он продал банкер пользователю, известному под ником VinnyK (это еще один псевдоним Aurora123), а значит, косвенно признал, что соврал во время первого допроса.

При этом адвокаты Хатчинса настаивают, что тогда их клиента допрашивали в состоянии интоксикации, не давали ему спать, держали в полном неведении, не зачитали права и не предъявляли никаких обвинений. Юристы требуют исключения этих улик из дела как неприемлемых.

Журналисты BleepingComputer обсудили новые обвинения в адрес Хатчинса с экспертом по правовым вопросам и независимым журналистом Марси Уиллер (Marcy Wheeler).

«Обвинения в даче ложных показаний — это самое лучшее, ведь в таком случае прокурора Невады тоже следует назвать сообщником Хатчинса, так как его выступление в суде летом прошлого года полностью противоречит заявлениям в новом обвинительном заключении», — говорит Уиллер.

Также эксперт указывает на тот факт, что в упомянутые годы, когда Хатчинс якобы создал и продал малварь UPAS Kit, он вообще был несовершеннолетним и срок исковой давности (пять лет) в данном случае давно истек. То есть предъявлять эти обвинения специалисту не должны были сразу по двум причинам.

Сам Маркус по-прежнему старается не терять присутствия духа и традиционно шутит о происходящем в своем Twitter. Так, исследователь пишет, что на услуги юристов уже было потрачено более 100 тысяч долларов (деньги Хатчинсу продолжают жертвовать неравнодушные пользователи и его коллеги со всего мира), а теперь из-за новых обвинений опять «нужно больше минералов». Также он называет новые обвинения «херней».

Шпионский Wavethrough

Специалист компании Google Джейк Арчибальд (Jake Archibald) обнаружил критическую уязвимость, представляющую угрозу для ряда современных браузеров. Проблема получила название Wavethrough и идентификатор CVE-2018-8235. Используя ее, вредоносные сайты могут похищать информацию с других ресурсов, на которых пользователь залогинен в том же браузере. Для выполнения атаки достаточно просто встроить в веб-страницу вредоносный видео- или аудиофайл, используя соответствующие HTML-теги.

Корень проблемы Wavethrough лежит в области использования технологии Cross-origin resource sharing (CORS, «совместное использование ресурсов между разными источниками»). CORS позволяет предоставить веб-странице доступ к ресурсам другого домена.

Арчибальд объясняет, что использование вредоносных service worker’ов позволяет подгружать мультимедийный контент, обозначенный тегами <video> и <audio>, из удаленного источника, а использование параметра range позволит загрузить лишь какую-то конкретную часть файла. Это было придумано для удобства загрузки больших медиафайлов или для случаев, когда скачивание файла остановили, а затем продолжили.

В нормальных обстоятельствах подобное поведение пресекает CORS. Браузеры давно запрещают сайтам использовать cross-origin-запросы, обращенные к другим доменам, без явного на то разрешения. Однако эти ограничения не распространяются на медиаконтент, размещенный в удаленном источнике. То есть возможно встроить на сайт аудио- или видеофайл с другого домена. В итоге при определенных условиях атакующие могут использовать no-cors-запросы, которые многие сайты (включая Facebook, Gmail и BBC) пропустят без проблем.

«Это означает, что, если вы откроете мой proof-of-concept сайт в браузере Edge, я смогу прочесть ваши письма или ленту Facebook без вашего ведома, — объясняет эксперт. — Баг появился, когда в браузерах реализовали имплементации range-запросов для медиаэлементов, на которые не распространялся стандарт. Эти range-запросы оказались по-настоящему полезны, поэтому браузеры использовали их, копируя поведение друг друга, но никто так и не интегрировал это в стандарт».

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

Перед проблемой Wavethrough уязвимы не все браузеры, только Mozilla Firefox и Microsoft Edge. Chrome и Safari вне опасности, и Арчибальд полагает, что в Chrome проблема Wavethrough была устранена еще в 2015 году, по воле случая. Тогда разработчики исправляли другую уязвимость, связанную с параметром range и мультимедийным контентом.

В настоящее время обновления выпущены для обоих уязвимых браузеров. При этом Арчибальду пришлось потрудиться, чтобы донести всю опасность проблемы до разработчиков Microsoft Edge. Подробно об этом специалист рассказал в своем блоге.

Proof-of-concept атаки можно увидеть здесь. Также исследователь создал специальный сайт, на котором пользователи уязвимых версий Mozilla Firefox и Microsoft Edge могут посмотреть на демонстрацию работы бага своими глазами.

VPNFilter стал опаснее

Вредонос VPNFilter был обнаружен в мае текущего года. Сложная малварь заразила как минимум полмиллиона роутеров Linksys, MikroTik, NETGEAR и TP-Link, а также NAS производства QNAP в 54 странах мира. Исследователи Cisco Talos, первыми рассказавшие о малвари, подчеркивали, что VPNFilter — это всего вторая известная IoT-угроза, способная «пережить» перезагрузку зараженного устройства (первой недавно стал вредонос Hide and Seek), к тому же таящая в себе деструктивную функциональность.

Эксперты Cisco Talos представили обновленный отчет о ботнете VPNFilter. Оказалось, что малварь представляет опасность для большего числа устройств, чем предполагалось изначально. К тому же исследователи выявили новые вредоносные плагины для VPNFilter.

Еще в мае аналитики Cisco Talos называли VPNFilter одной из наиболее комплексных IoT-угроз, с какими им приходилось сталкиваться. Так, заражение делится на три стадии и, по сути, состоит из трех разных ботов. Бот первой стадии прост и легковесен, но он умеет «переживать» перезагрузку устройства. Бот второй стадии несет в себе опасную функцию самоуничтожения, после активации которой зараженное устройство превращается в «кирпич», намеренно повреждаясь малварью. В свою очередь, третья фаза атаки подразумевает загрузку на зараженное устройство вредоносных плагинов.

Теперь ИБ-эксперты сообщили, что даже недооценили всю степень опасности. Если изначально считалось, что малварь представляет угрозу для устройств Linksys, MikroTik, NETGEAR, TP-Link и QNAP, то теперь выяснилось, что к этому списку нужно добавить роутеры производства ASUS, D-Link, Huawei, Ubiquiti, UPVEL и ZTE.

В итоге перечень уязвимых перед VPNFilter устройств расширился с 16 моделей до 71, причем на деле их может оказаться еще больше. По данным экспертов, операторы VPNFilter не используют для заражения устройств какие-либо 0day-уязвимости, а эксплуатируют различные известные баги.

Кроме того, в Cisco Talos сумели обнаружить еще два вредоносных плагина, использующихся во время третьей фазы заражения. Ранее исследователи уже находили плагины, задача которых заключается в сниффинге сетевого трафика и перехвате пакетов, мониторинге протоколов Modbus SCADA, а также взаимодействии с управляющим сервером посредством Tor.

Теперь список пополнился плагином ssler, предназначенным для перехвата и модификации трафика, проходящего через 80-й порт (посредством атак man-in-the-middle). Также это решение способно выполнить атаку SSLStrip и понизить соединение с HTTPS до HTTP. Еще один плагин, dstr, создан для переписи файлов прошивки зараженного устройства. В первом отчете специалисты сообщали, что VPNFilter способен уничтожить прошивку зараженной машины, а теперь они обнаружили, что для этой функциональности предназначается dstr.

Еще при первичном анализе, в мае 2018 года, было обнаружено сходство VPNFilter с вредоносом BlackEnergy. Считается, что тот был создан группой предположительно российских правительственных хакеров APT28, также известной под названиями Fancy Bear, Pawn Storm, Strontium, Sofacy, Sednit, Tsar Team, X-agent, Sednit и другими.

После того как специалисты предположили, что имеют дело с правительственными хакерами, представители ФБР забили тревогу и оперативно перехватили управление над управляющим сервером злоумышленников, применив технику синкхола (sinkhole) к домену toknowall.com. После этого ФБР и производители уязвимых устройств опубликовали подробные инструкции для владельцев уязвимых устройств, рассказав, какие шаги нужно предпринять для защиты от VPNFilter. Напомню, что простой перезагрузки устройства недостаточно, чтобы избавиться от бота первой стадии заражения. В зависимости от модели устройства может понадобиться сброс к заводским настройкам и перепрошивка гаджета.

К сожалению, эти действия не остановили операторов ботнета, как того и опасались ИБ-специалисты. Стало известно, что VPNFilter активно заражает всё новые роутеры на территории Украины и пытается «вернуться в строй».

Обновленный список всех уязвимых устройств можно найти здесь.

STARTTLS Everywhere

Некоммерческая правозащитная организация Фонд электронных рубежей (Electronic Frontier Foundation, EFF) запустила инициативу STARTTLS Everywhere — своеобразный аналог проекта Let’s Encrypt, учрежденного EFF, Mozilla и Cisco, но для обеспечения безопасности почтовых серверов.

Хотя STARTTLS никак нельзя назвать новым (по статистике Google, он используется на 89% всех почтовых серверов в интернете), специалисты EFF с сожалением констатируют, что проблемы с его конфигурацией по-прежнему встречаются очень часто.

«Хотя многие почтовые серверы работают со STARTTLS, большинство по-прежнему не осуществляет валидацию сертификатов», — пишут специалисты.

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

Инициатива STARTTLS Everywhere призвана разрешить перечисленные проблемы.

«STARTTLS Everywhere предоставляет системным администраторам специальное ПО, которое можно запустить на почтовом сервере для осуществления автоматической валидации сертификатов проекта Let’s Encrypt. Также данное ПО поможет настроить почтовый сервер таким образом, чтобы тот использовал STARTTLS и предоставлял действительные сертификаты другим почтовым серверам. Наконец, STARTTLS Everywhere включает в себя предварительно загруженный список почтовых серверов, которые обещают поддержку STARTTLS, что поможет отслеживать атаки на даунгрейд соединения. Итоговый результат для сети: более защищенные email’ы и меньше массовой слежки», — гласит официальный сайт STARTTLS Everywhere.

Все подробности о том, как правильно настроить STARTTLS, добавить свой ресурс в «предварительно загруженный список» STARTTLS Everywhere, и ответы на другие вопросы можно найти на официальном сайте новой инициативы.

Игры следят за тобой

Пользователи Reddit и Steam уличили производителей игр в массовой слежке. Возмущение комьюнити начало набирать обороты после публикации на Reddit, в которой рассказывалось о том, что игра «Holy Potatoes! We’re in Space?!» использует аналитическую программу RedShell, созданную компанией Innervate, Inc. для сбора данных о пользователях и фактически слежки за ними.

RedShell встраивается в игры в виде SDK и используется для проведения социально-маркетинговых кампаний. Так, RedShell помогает разработчикам понять, как именно пользователи выбирают и покупают игры. К примеру, если посмотреть трейлер какой-либо игры на YouTube, а затем перейти по ссылке из описания в Steam и купить ее, этого будет достаточно, чтобы за компьютером закрепился специальный ID, ассоциирующий систему с конкретным IP-адресом, разрешением экрана, установленными шрифтами и так далее. Таким образом, благодаря RedShell SDK производители получают данные об источниках покупок и установок.

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

В итоге общими усилиями комьюнити были созданы специальные списки, в которых собрана информация обо всех играх и производителях, применяющих подобные шпионские практики. Стоит заметить, что в списки попали многие хорошо известные тайтлы, например Civilization VI, Kerbal Space Program и Elder Scrolls Online.

Также выяснилось, что в некоторых случаях разработчики вообще не информировали о наличии спорного SDK в составе своих продуктов. Порой это могло быть прямым нарушением закона. К примеру, в Conan: Exile EULA вообще не упоминается сбор данных посредством RedShell.

Хотя разработчики RedShell утверждают, что вся собранная статистика анонимна, вплоть до декабря 2017 года некоторые интеграции RedShell собирали данные об IP-адресах и сопоставляли их со Steam ID, а этого более чем достаточно для деанонимизации пользователей.

Теперь, когда на происходящее обратили внимание СМИ, а пользователи засыпают гневными вопросами официальные сайты производителей, многие компании решили пойти на попятную и отказаться от использования RedShell. В частности, о таком решении уже сообщили разработчики «Total War: Warhammer 2» и «Conan: Exiles», пообещав удалить шпионский SDK и подчеркнув, что «это не спайварь».

Здесь можно найти список игр, в которых был обнаружен RedShell, а также список производителей, уже заявивших о том, что они скоро перестанут следить за игроками.

Google наращивает защиту

Сразу несколько нововведений, призванных улучшить защиту различных продуктов Google, были анонсированы в этом месяце.

Нет вредоносным расширениям

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

Так называемая inline-установка (она же встраиваемая установка) позволяет разработчикам расширений не только распространять свои продукты через официальный каталог Chrome Web Store, но и предлагать пользователям расширения на сторонних сайтах. В таком случае достаточно нажать на специальную кнопку, и расширение будет установлено без визита в Chrome Web Store.

Отказаться от этой функциональности решили из-за того, что ее давно взяли на вооружение злоумышленники. Авторы различных вредоносных расширений пользуются inline-установкой, так как в этом случае посетитель сайта не видит негативных отзывов, предупреждений от других пострадавших и низкого рейтинга вредоносного расширения в Chrome Web Store.

«Мы продолжаем получать огромное количество жалоб от пользователей, которые столкнулись с неожиданным изменением в поведении Chrome после установки нежелательного расширения. Большинство таких жалоб связаны с тем, что люди случайно или будучи намеренно введены в заблуждение использовали inline-установку на сайтах», — пишут разработчики Google.

Отказ от inline-установки будет разделен на три этапа. Первый этап уже начался: с 12 июня 2018 года встраиваемая установка для новых расширений запрещена. Для них попытка использовать chrome.webstore.install() теперь окончится открытием страницы расширения в официальном каталоге. Второй этап стартует 12 сентября 2018 года. Осенью inline-установку запретят всем существующим расширениям вообще. И наконец, третий этап: в декабре 2018 года, с релизом Chrome 71, метод inline-установки исчезнет из API окончательно.

Пароли для прошивок

Новый защитный механизм получат смартфоны Pixel 2. Нововведение обеспечит дополнительную защиту против неавторизованных попыток обновить или подменить прошивку гаджета. По сути, это защита от инсайдерских атак и случаев, когда у злоумышленника есть доступ к самому устройству.

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

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

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

Разработчики Google рекомендуют другим производителям мобильных устройств перенять их опыт и внедрить похожие защитные решения в свои продукты.

Проверка приложений в офлайне

Вскоре должен измениться и механизм проверки приложений для Android на аутентичность. В Google планируют модифицировать хедеры файлов APK таким образом, чтобы среди метаданных появилось новое поле,содержащее криптографическую подпись. Из-за этого незначительно увеличится максимально допустимый размер APK. Никаких действий и обновления приложений со стороны разработчиков не потребуется, новое поле будет заполняться Play Store автоматически.

В настоящее время установить «одобренные» Google приложения, прошедшие все надлежащие проверки, можно лишь через официальный Play Store, который в фоновом режиме перед установкой убедится в подлинности и безопасности продукта. С добавлением нового поля в хедеры APK подпись будет содержаться в самом файле, что позволит пользователям загружать приложения из Play Store, а затем распространять их по другим каналам, но не изменять в процессе.

В блоге компании Джеймс Бендер (James Bender), продакт-менеджер Google Play Store, объясняет, что данное решение продиктовано желанием улучшить комфорт и безопасность пользователей, при этом дав разработчикам возможность донести свои решения до более широкой аудитории. Так, нововведение должно прийтись по душе пользователям из развивающихся стран, где распространение приложений посредством P2P уже давно стало нормой (в силу высокой стоимости трафика или ряда других ограничений).

«В будущем мы сможем определять аутентичность приложений даже в том случае, если устройство находится в офлайне», — пишет Бендер.

Стоит отметить, что специалисты в области информационной безопасности уже выразили сомнения в рациональности данного шага. Дело в том, что это нововведение в теории может продлить «срок жизни» вредоносных приложений. Так, малвари будет достаточно попасть в Play Store хотя бы на короткое время, после чего она будет фигурировать в базах как легитимное и проверенное решение. И даже после удаления вредоноса из официального каталога пользователи, которые нечасто выходят в офлайн, могут установить себе такую малварь, взятую из каких-либо сторонних источников, но при этом система будет уверена, что приложение аутентичное и не представляет угрозы.