MEGANews. Самые важные события в мире инфосека за сентябрь

Другие статьи в выпуске:

Xakep #234. Взломать iPhone

• Содержание выпуска
• Подписка на «Хакер»-60%

MageCart атакует

В сентябре 2018 года стало известно о серии масштабных атак на самые разные организации и компании по всему миру. За всеми этими инцидентами стоит хакерская группа MageCart.

По данным ИБ-специалистов, одноименная вредоносная кампания MageCart активна как минимум с 2015 года, и в ее рамках действует не одна хакерская группа, а сразу несколько групп, применяющих практически одинаковые тактики. Одну из них специалисты RiskIQ отслеживают под тем же именем, MageCart. Именно эта группировка, по мнению специалистов, была ответственна за ряд происшествий, о которых стало известно в этом месяце.

«Почерк» MageCart почти всегда узнаваем: злоумышленники взламывают онлайновые магазины и сайты компаний и внедряют код JavaScript на страницы оплаты, похищая таким образом вводимые пользователями финансовые данные (номера банковских карт, имена, адреса и так далее). К примеру, недавно была выявлена такая компрометация нескольких тысяч интернет-магазинов на платформе Magento.

British Airways

Первой крупной жертвой преступников стали пользователи сайта (ba.com) и мобильного приложения авиакомпании British Airways. Под угрозой оказались все пользователи, бронировавшие билеты через официальный сайт или приложение компании с 25 августа по 5 сентября 2018 года. Суммарно в руки преступников попали личные и финансовые данные 380 тысяч человек.

Эксперты RisqIQ рассказывают, что обнаружили признаки операции MageCart. Воспользовавшись своим внутренним инструментом, который периодически архивирует код различных сайтов, исследователи нашли JavaScript, загруженный на сайт British Airways. Файл, который не изменяли с 2012 года, вдруг был модифицирован 21 августа 2018-го (в 20:49 GMT), примерно за два часа до официального начала атаки, указанного в пресс-релизе авиакомпании.

Хакеры из MageCart внедрили вредоносный код в конец «чистого» до этого момента файла modernizr-2.6.2.js. Малварь следила за определенными движениями мыши и нажатиями и перехватывала данные, введенные в форму на странице оплаты. Затем эта информация передавалась на удаленный сервер baways.com (89.47.162.248), который расположен в Румынии, а принадлежит литовскому VPS-провайдеру.

Данный сервер использовал сертификат Comodo, зарегистрированный за несколько дней до атаки. По мнению исследователей, это указывает на то, что у атакующих было время для подготовки операции, а значит, на тот момент они уже имели доступ к сайту British Airways. Сейчас сертификат для baways.com уже отозван.

Кроме того, аналитикам RisqIQ удалось понять, почему компрометация затронула не только официальный сайт, но и мобильное приложение авиаперевозчика. Дело в том, что разработчики British Airways написали мобильное приложение таким образом, что внутри него подгружался тот же самый платежный интерфейс с официального сайта. И когда хакеры внедрили на эту страницу малварь, атака затронула и пользователей приложения.

Feedify

Вскоре после новости о компрометации пользователей British Airways стало известно еще об одной пострадавшей компании. Злоумышленники взломали сервис Feedify, позволяющий администраторам сайтов встраивать в свои ресурсы push-уведомления, интегрируя в код сайтов JavaScript-библиотеки Feedify.

Первым компрометацию заметил ИБ-специалист, известный в Twitter под псевдонимом Placebo. Он сообщил, что один из JavaScript-файлов компании (feedbackembad-min-1.0.js) содержит вредоносный код, похищающий платежные данные пользователей.

Вскоре находку Placebo подтвердили специалисты компании RisqIQ, а также известный эксперт Кевин Бомонт (Kevin Beaumont). Хотя на официальном сайте компании сказано, что продуктом Feedify пользуются более 4000 клиентов, поиск через PublicWWW позволяет обнаружить только 250–300 сайтов с зараженной библиотекой. Исследователи RisqIQ сумели установить, что компрометация сервиса произошла еще 17 августа 2018 года, в 16:51:01 GMT.

Placebo уведомил разработчиков Feedify о проблеме 11 сентября 2018 года, и вредоносный код практически сразу был удален из файла. Однако атакующие не сдались. Меньше чем через сутки файл оказался заражен MageCart снова, а когда представители Feedify повторно удалили малварь, преступники инициировали заражение в третий раз. При этом представители компании до сих пор хранят молчание и не отвечают на вопросы экспертов и СМИ.

Newegg

Третьей жертвой MageCart в сентябре стал крупный ретейлер Newegg. Компрометацию обнаружили эксперты компаний RiskIQ и Volexity. По данным исследователей, атака началась еще 13 августа 2018 года, когда преступники зарегистрировали домен neweggstats.com, максимально близкий к настоящему адресу newegg.com. Этому домену также принадлежал SSL-сертификат, выпущенный Comodo.

Уже на следующий день злоумышленники, как обычно, встроили на страницу оплаты настоящего Newegg малварь, похищающую данные пользователей. Чтобы не привлекать лишнего внимания и не вызывать подозрений, эта информация передавалась neweggstats.com (217.23.4.11). Как ни странно, тактика преступников сработала, компрометацию обнаружили лишь месяц спустя, 18 сентября 2018 года.

До сих пор неизвестно, сколько пользователей успели пострадать от этой атаки, но, по данным SimilarWeb, посещаемость Newegg составляет порядка 50 миллионов человек в месяц.

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

Возможная связь с MagBO

Также в этом месяце специалисты компании Flashpoint рассказали об обнаружении русскоязычной торговой площадки MagBO, на которой торгуют доступом к тысячам взломанных сайтов.

По данным исследователей, MagBO появился сравнительно недавно (в первой половине 2018 года) и должен составить конкуренцию таким площадкам, как HackForum, Exploit.in, xDedic, Nulled и Mal4All. Однако от конкурентов MagBO отличает один немаловажный нюанс — на новом форуме продают web shell’ы для уже скомпрометированных сайтов. То есть на продажу выставлен доступ к ресурсам, на которых уже размещены какие-то бэкдоры, позволяющие покупателям без труда проникнуть в систему.

В настоящее время на продажу выставлены порядка 3000 скомпрометированных ресурсов, стоимость доступа варьируется от 0,5 до 1000 долларов США. Причем цены устанавливаются динамически и зависят от таких значений, как посещаемость или параметры хостинга. Чем больше посещаемость взломанного ресурса и чем глубже доступ к его хостинг-инфраструктуре, тем выше будет цена.

Хотя пока исследователям Flashpoint не удалось найти неопровержимых доказательств, связывающих атаки группы MageCart с MagBO, они не исключают такой возможности. Так как все перечисленные атаки были «многослойными», по мнению аналитиков, изначальной компрометацией пострадавших сайтов могли заниматься совсем другие злоумышленники, у которых операторы MageCart затем покупали доступ. Эксперты не исключают, что сделки могли совершаться напрямую через MagBO.

Спорные нововведения Chrome 69

В начале сентября 2018 года в свет вышел Chrome 69 с обновленным интерфейсом и рядом новых функций. На первый взгляд, переработанный дизайн вкладок, адресной строки, стартовой страницы и других элементов браузера выглядел неплохо, однако «под капотом» новой версии обнаружилось множество нововведений, из-за которых половина ИБ-сообщества обрушилась с жесткой критикой на разработчиков Chrome.

WWW и поддомены

С новым релизом разработчики Chrome в очередной раз решили сделать его интерфейс проще и удобнее, отказавшись от «сложных и ненужных» частей URL, которые, по их мнению, лишь запутывают пользователей. К примеру, оказалось, что чтение URL-адресов усложняют отображающиеся в строке адреса мобильные поддомены, WWW и прочие элементы. Якобы людям сложно понять, какой именно части адреса нужно доверять и уделять внимание, чем, в частности, пользуются фишеры и другие преступники.

В итоге возникла весьма странная ситуация. Так, если пользователь хотел посетить www.xakep.ru, то в адресной строке отображалось просто xakep.ru. То же самое происходило с m.facebook.com, который превращался просто в facebook.com.

Подобное «упрощение» не понравилось многим само по себе, но специалисты также обнаружили множество багов, связанных с реализацией новой функциональности. Например, конструкция subdomain.www.domain.com не должна превращаться в subdomain.domain.com, а http://www.example.www.example.com не должен образовывать example.example.com, однако происходило именно это.

Исследователи приводят множество примеров подобных ошибок. Так, http://www.pool.ntp.org и http://pool.ntp.org — это два разных адреса, один из которых должен вести на страницу проекта, тогда как другой выдает рандомный адрес NTP-сервера.

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

Однако это лишь временная мера. Вскоре инженеры Google собираются доработать свои идеи, избавиться от багов, и с релизом Chrome 70 «ненужные» элементы все же исчезнут из адресной строки. Так, невзирая на критику, команда разработки продолжает настаивать на исключении WWW из строки адреса. Мобильные поддомены m пока решили оставить в покое, так как оказалось, что такие user-controlled поддомены присутствуют на большом количестве сайтов.

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

Многие специалисты отмечают, что Google, как компания, занимающая огромную долю рынка, должна была проявить большую ответственность, дождаться начала дискуссии о стандартизации (а лучше ее результатов) и лишь после принимать столь серьезные решения. Другие компании годами старались объяснить пользователям разницу в именах хостов и правила чтения URL, а теперь Google собирается попросту перечеркнуть эту работу и лишь собьет пользователей с толку.

Принудительная авторизация

Однако изъятие WWW из строки адреса оказалось едва ли не меньшей из всех проблем. Так, выяснили, что после релиза Chrome 69 пользователей принудительно авторизуют в браузере, если они вошли в свой аккаунт Google или любой другой сервис компании. Для этого браузер использует механизм Sync, позволяющий залогиниться в Chrome и опционально загрузить и синхронизировать локальные данные браузера (историю, пароли, закладки и так далее) с серверами Google.

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

Специалисты Google поспешили объяснить в Twitter, что новое использование Sync все же не означает активацию синхронизации по умолчанию (синхронизацию пользователю потребуется включить самостоятельно), и заверили, что добавление новой функциональности, напротив, связано с усилением приватности. Дело в том, что, когда одним компьютером и браузером пользуются сразу несколько человек, данные одного пользователя могут быть ошибочно связаны с Google-аккаунтом другого человека.

Тем не менее разработчиков Google все равно раскритиковали. Во-первых, из-за того, что пользователям попросту не оставили выбора: они не могут решать, когда залогиниться в браузер, а Chrome, в сущности, делает это за них. Во-вторых, Google никак не предупреждала об этом нововведении; многие пользователи могут просто не заметить разницы и очень удивятся, обнаружив, что теперь пользуются Sync.

В частности, с критикой в адрес компании выступил известный криптограф, ИБ-эксперт и профессор Университета Джона Хопкинса Мэтью Грин (Matthew Green). Он писал, что разработчики Google в целом переработали интерфейс таким образом, чтобы пользователь не понимал, залогинен ли он, активна ли синхронизация и какую кнопку нужно нажать для начала синхронизации. Эксперт считает, что текущие изменения граничат с использованием dark patterns — специфических приемов веб-дизайна, с помощью которых обманывают пользователей и побуждают их к «нужным» действиям. Так, в настоящее время пользователь может передать всю информацию о своем браузере Google одним кликом, просто по ошибке, пытаясь разобраться в настройках.

Более того, Грин убежден, что даже сам процесс аутентификации в браузере уже может давать Google возможность для сбора данных — опять же без ведома пользователя.

В ответ на критику Грина в Google пообещали описать сделанные изменения более прозрачно, внеся корректировки в Privacy Policy браузера. И хотя эти изменения могут защитить компанию от возможных юридических проблем, к сожалению, они никак не изменят сложившейся после выхода Chrome 69 ситуации, а поведение браузера вряд ли станет понятнее для рядового пользователя.

«Неудаляемые» куки

В конце месяца специалисты обратили внимание на еще одну неприятную особенность Chrome 69. Как оказалось, после команды на удаление всех файлов cookie в браузере куки для сервисов Google не удаляются, пока пользователь не разлогинится. Первым внимание к проблеме «неудаляемых» куки привлек CTO Contentpass Кристофер Тэван (Christoph Tavan).

Он пояснил, что если пользователь выполнил вход в Chrome 69 (напомню, что это теперь происходит автоматически, стоит только войти в любой сервис Google), а затем дал браузеру команду стереть все файлы cookie (открыв chrome://settings/siteData?search=cookies и нажав «Удалить все»), то куки для сервисов Google удалены не будут. Точнее, браузер удалит их, но тут же воссоздаст снова для поддержания авторизации.

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

Также исследователь отметил, что очистка данных в браузере (Clear browsing data -> Cookies and other site data) не затрагивает локальное хранилище, связанное с API localStorage. К сожалению, именно там хранят идентификаторы рекламные сети и прочие сервисы, «шпионящие» за пользователями.

Промежуточный итог

В итоге инженеры Google все же решили обратить внимание на недовольство комьюнити, после того как на компанию обрушились претензии экспертов, СМИ и рядовых пользователей. В блоге Google появилось сообщение, написанное продакт-менеджером Chrome Заком Кохом (Zach Koch). Специалист рассказывает, что с релизом Chrome 70, запланированным на середину октября 2018 года, разработчики пересмотрят некоторые изменения, внесенные в браузер.

Кох пишет, что все раскритикованные новшества были добавлены в Chrome с благими намерениями, но, получив фидбэк, разработчики решили откатить изменения и дать пользователям больше контроля. В частности, в новой версии браузера появится опция Allow Chrome sign-in («Разрешить вход в Chrome»), с помощью которой можно будет регулировать автоматический вход в браузер и его зависимость от авторизации в других сервисах Google.

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

Кроме того, Chrome 70 вновь будет удалять все файлы cookie, не делая исключений для куки сервисов самой Google.

Линус Торвальдс временно прекратит разработку ядра

Торвальдс объявил, что временно прекратит заниматься разработкой и возьмет небольшую паузу, чтобы поработать над собственным поведением. Дело в том, что Торвальдс пришел к выводу, что очень часто он ведет себя с другими разработчиками и даже посторонними людьми грубо и неприемлемо.

«Я нечуткий эмоционально человек, и вряд ли для кого-то это станет сюрпризом. Уж точно не для меня самого. Плохо, что из-за этого я неправильно понимал людей и годами даже не осознавал того, насколько неверно я оцениваю ситуацию и какой вклад вношу в создание непрофессионального климата»,

— Линус Торвальдс

Обновленный Tor Browser

Большое обновление в этом месяце получил не только Google Chrome, но и Tor Browser, наконец-то перешедший на кодовую базу Firefox Quantum и новый Photon UI.

Tor Browser всегда основывался на кодовой базе Firefox, однако отставал от своего «прародителя» на пару релизов. И если инженеры Mozilla представили Firefox 57 на базе Firefox Quantum еще в ноябре 2017 года, то до Tor обновление добралось только теперь. Равно как и Firefox, Tor Browser 8 (основанный на Firefox ESR 60) получил новый движок для рендеринга страниц, новый WebExtensions API, который для работы с дополнениями применяют Chrome, Opera, Vivaldi, Brave и другие Chromium-браузеры, а также обновленный интерфейс Photon UI.

Но если об основных изменениях, сопряженных с переходом на Firefox Quantum, хорошо известно на примере Firefox, то у Tor Browser есть и собственные специфические новшества. Так, разработчики полностью переработали и упростили стартовый экран, который пользователи видят сразу после установки и запуска браузера. Кроме того, был серьезно переработан механизм request bridge, теперь не понадобится отправлять email или переходить на сайт проекта, достаточно будет просто решить капчу в самом Tor Launcher.

Также нужно отметить, что почти одновременно с релизом Tor Browser 8 разработчики Tor Project представили и мобильную версию своего продукта: Tor Browser для Android. Приложение уже доступно в каталоге Google Play Store, хотя в настоящее время остается альфа-версией.

Tor Browser для Android должен заменить собой разрабатывавшийся до недавнего времени командой Guardian Project браузер Orfox, который теперь «отправлен в отставку». Разработчики призывают сообщество помочь в тестировании Tor Browser для Android. В настоящее время установка альфа-версии браузера также требует установки мобильного прокси-приложения Orbot, но разработчики уверяют, что для будущих релизов это уже не понадобится.

Уязвимость NoScript

Еще одним поводом для перехода на новую версию браузера может стать 0day-уязвимость, о которой в середине сентября рассказали специалисты известного «брокера уязвимостей», компании Zerodium. Данные о баге были опубликованы прямо в официальном твиттере компании, после того как браузер обновился и уязвимость стала менее критичной (а также потеряла свою ценность).

Уязвимость позволяла обойти самый безопасный режим работы дополнения NoScript, подразумевающий блокировку всего JavaScript-контента. Данное дополнение по умолчанию распространяется вместе с Tor Browser и позволяет пользователю разрешать или запрещать работу JavaScript, Flash, Java, Silverlight. Фактически предложенная специалистами атака позволяет выполнить в Tor Browser 7.x произвольный код, обманув NoScript и блокировку скриптов.

Рассказать об уязвимости публично исследователи решили именно из-за релиза Tor Browser 8.х, который проблеме уже не подвержен. Дело в том, что новая версия браузера работает с Firefox Quantum и использует новый API для дополнений, а разработчик NoScript Джорджио Маоне (Georgio Maone) еще в конце прошлого года переработал свое решение под новый формат.

После публикации твита Zerodium с Маоне связалась пресса, и выяснилось, что он впервые услышал о 0day-баге именно от журналистов. Разработчик пообещал срочно выпустить патч и уточнил, что уязвимость распространяется только на NoScript 5 Classic (уязвимость появилась в версии NoScript 5.0.4, вышедшей в мае 2017 года), но не затрагивает NoScript 10 Quantum или Tor Browser 8. В настоящее время Маоне уже сдержал свое обещание, подготовив и опубликовав патч: версия NoScript Classic 5.1.8.7 безопасна.

Глава Zerodium Чауки Бекрар (Chaouki Bekrar), в свою очередь, сообщил СМИ, что информация об этой уязвимости и эксплоит для нее были приобретены компанией много месяцев назад, в рамках тематической акции (покупка эксплоитов для Tor Browser), проведенной еще осенью 2017 года. Также Бекрар не стал скрывать, что Zerodium давно поделилась этой информацией со своими правительственными заказчиками.

Напомню, что бизнес-модель Zerodium (из-за которой компания неоднократно подвергалась жесткой критике) такова, что компания сохраняет информацию о найденных самостоятельно и купленных у третьих лиц 0day в тайне, при этом перепродавая их крупным компаниям, правительственным организациям и силовым структурам.

Больше никакой CAPTCHA

Хорошие новости поступают из стана разработчиков Cloudflare. В компании объявили о создании Cloudflare Onion Service, который будет отличать ботов и злоумышленников от легитимного Tor-трафика. Ожидается, что благодаря новому сервису пользователям Tor Browser придется намного реже сталкиваться с CAPTCHA на защищенных Cloudflare сайтах.

До недавнего времени пользователям Tor приходилось решать бесконечные Google reCAPTCHA при каждом посещении сайтов, защищенных Cloudflare. В 2016 году представители Tor Project даже обвиняли компанию в том, что та саботирует Tor-трафик, заставляя пользователей решать CAPTCHA десятки раз подряд. Тогда в Cloudflare ответили, что вынуждены идти на такие меры, так как 94% Tor-трафика составляют боты или злоумышленники.

Тем не менее спустя примерно полгода разработчики Cloudflare представили Challenge Bypass Specification и дополнение для Tor Browser, попытавшись избавить пользователей от бесконечных тестов. Однако данный проект не прижился, и ему на смену стали внедрять функциональность Opportunistic Encryption, представленную осенью 2016 года. В итоге именно Opportunistic Encryption использовали для создания Cloudflare Onion Service вместе с кастомными Proxy Protocol хедерами, HTTP/2 и рядом других инструментов.

Теперь представители компании рассказывают, что для ввода Cloudflare Onion Service в эксплуатацию от разработчиков Tor потребовалось лишь внести небольшие изменения в бинарники Tor. То есть сервис будет работать только с новыми Tor Browser 8.0 и Tor Browser для Android. Также сообщается, что Cloudflare Onion Service бесплатен для всех клиентов Cloudflare и включить его можно, найдя в настройках опцию Onion Routing.

Scan4You посадили, а Mirai нет

Еще летом 2017 года правоохранительные органы США предъявили обвинения двум гражданам Латвии: Руслану Бондарю (Ruslans Bondars) и Юрию Мартышеву (Jurijs Martisevs). Их обвиняли в тайном сговоре с целью совершения электронного мошенничества, электронном мошенничестве, подстрекательстве к преступлению, а также в причинении вреда компьютерным системам. По данным Министерства юстиции США, эти двое много лет управляли Scan4You — сервисом для киберпреступников, с помощью которого те могли проверить свою малварь и узнать, «видят» ли ее антивирусные решения.

Подобные сервисы на Западе называют no distribute сканерами. Принцип их работы аналогичен легитимному VirusTotal, с той лишь разницей, что нелегальные сканеры не делятся данными с производителями антивирусных продуктов и блокируют телеметрию. Такие ресурсы часто используют разработчики малвари, чтобы убедиться в том, что их пейлоад не вызывает срабатывания защитных решений и механизмов.

Согласно данным специалистов Trend Micro, также опубликованным в прошлом году, Бондарь создал Scan4You еще в 2009 году, и его сервис быстро стал одним из популярнейших в данной области «рынка».

Хотя операторы Scan4You запрещали своему детищу информировать антивирусные движки о сканах файлов, в 2012 году они допустили ошибку: забыли запретить доклады о сканах URL для движка Trend Micro. В итоге специалисты компании несколько лет собирали данные сканов о репутации URL от Scan4You и других подобных сервисов, что помогало обнаруживать кампании по распространению малвари еще до их запуска. В конечном счете аналитикам удалось собрать достаточно информации, чтобы передать эти наработки ФБР и другим правоохранительным органам.

Согласно обвинительному акту, составленному сотрудниками Министерства юстиции США, у ресурса было более 30 тысяч клиентов и он был одним из крупнейших в своем роде. Известно, что сканер хостился в Amazon Web Services, а оплату администраторы принимали через PayPal, зарегистрированный на Мартышева. Это обстоятельство тоже помогло связать Scan4You с его операторами.

Также из документов следует, что злоумышленники выполняли разные обязанности. Так, Бондарь возглавлял «предприятие» и занимался поддержанием инфраструктуры сканера и технической стороной дела, тогда как Мартышев отвечал за техническую поддержку клиентов через ICQ, Skype, Jabber и электронную почту. Еще в мае 2018 года суд присяжных признал Бондаря виновным. Однако приговор оператору Scan4You был вынесен лишь 21 сентября 2018 года. Бондаря приговорили к четырнадцати годам тюремного заключения.

При этом специалисты Trend Micro утверждают, что создатель Scan4You занимался и другой нелегальной деятельностью. Так, по их данным, Бондарь также входил в состав группировки Eva Pharmacy, которая в середине нулевых была одним из крупнейших игроков в сфере фармацевтического спама. Кроме того, исследователи считают, что до создания Scan4You Бондарь имел отношение к распространению известных банковских троянов SpyEye и ZeuS.

Mirai

Куда больше повезло разработчикам известной IoT-малвари Mirai. Напомню, что в декабре 2017 года на официальном сайте Министерства юстиции США была опубликована целая подборка судебных документов, согласно которым создателями оригинальной версии вредоноса Mirai были три друга: 21-летний Парас Джа (Paras Jha) из Нью-Джерси, 20-летний Джозайя Уайт (Josiah White) из Пенсильвании и 21-летний Далтон Норман (Dalton Norman) из Луизианы.

Из документов стало понятно, что, создавая Mirai, эта троица вовсе не стремилась разработать мощнейшее кибероружие, которое вызвало вполне обоснованную тревогу у властей по всему миру. Изначально Mirai и ботнет, построенный на базе данной малвари, предназначались для обычных DDoS-атак по найму, к тому же друзья интересовались бизнесом, связанным с популярной компьютерной игрой Minecraft, и хотели «прижать конкурентов».

В команде Джа отвечал за инфраструктуру и удаленный контроль малвари, Уайт разработал Telnet-сканер, вошедший в состав вредоноса, а Норман создавал новые эксплоиты. Хотя в официальном заявлении американских властей речь шла лишь о 100 тысячах скомпрометированных устройств на территории США, на деле пострадавших IoT-устройств, конечно, было гораздо больше.

Так, согласно данным ИБ-исследователей, только за первые 20 часов работы Mirai заразил более 65 тысяч девайсов, а в итоге стабильное количество ботов варьировалось между 200 тысячами и 300 тысячами. Напомню, что самыми громкими инцидентами, связанными с Mirai, стали атака на европейского провайдера OVH (мощность атаки составила 1 Тбайт/с) и атака на DNS-провайдера Dyn, из-за которой во многих странах мира с перебоями работали социальные сети, новостные сайты, популярные стриминговые сервисы и другие ресурсы.

В конце 2017 года стало известно, что разработчики нашумевшего IoT-вредоноса полностью признали свою вину (оказалось, что оригинальный Mirai-ботнет использовали не только для DDoS-атак, но и для массового кликфрода), а также сознались в том, что в 2016 году запаниковали и выложили в открытый доступ исходные коды Mirai, пытаясь сбить с толку правоохранителей. «Плоды» этого поступка весь мир пожинает до сих пор, так как львиная доля IoT-малвари базируется на этих исходных кодах и эксплуатирует идеи Mirai.

Хотя всем троим авторам Mirai грозили серьезные тюремные сроки, Министерство юстиции США обнародовало пресс-релиз, согласно которому Джа, Уайт и Норман с декабря прошлого года активно сотрудничают с правоохранительными органами, помогая ФБР в вопросах кибербезопасности. В официальном заявлении не сказано, когда именно и с какими случаями хакеры помогли разобраться спецслужбам, но довольно легко понять, что в числе прочего речь идет о DDoS-атаках Memcached, ликвидации ботнета Kelihos и ботнете VPNFilter.

Благодаря столь активному сотрудничеству с правоохранительными органами разработчиков Mirai решили «наградить»: никто из создателей IoT-малвари не сядет в тюрьму. Вместо этого Джа, Уайт и Норман получили по пять лет испытательного срока, были приговорены к 2500 часам исправительных работ, а также обязуются возместить причиненные убытки в размере 127 тысяч долларов США и добровольно отдать «значительное количество» криптовалют, найденных у них в ходе расследования. Кроме того, все трое и далее продолжат сотрудничать с ФБР и консультировать правоохранительные органы в вопросах кибербезопасности.

Незакрытая 0day в Windows

Эксперты Trend Micro Zero Day Initiative (ZDI) обнародовали информацию о неисправленной уязвимости в составе СУБД Microsoft JET Database Engine. По данным исследователей, проблема угрожает всем актуальным на сегодня версиям Windows (Windows 10, Windows 8.1, Windows 7, а также Windows Server от 2008 до 2016) и допускает исполнение произвольного кода.

Специалисты пишут, что уведомили инженеров Microsoft о проблеме еще в начале мая 2018 года и выждали даже не положенные в таких случаях 90 дней, а 120, учитывая серьезность бага. Однако патча для уязвимости по-прежнему нет, хотя в рамках сентябрьского «вторника обновлений» разработчики Microsoft устранили две другие проблемы в JET.

Уязвимость представляет собой проблему записи за пределы буфера (out-of-bounds writes), которая может возникнуть, если открыть источник данных JET через Object Linking and Embedding Database (OLEDB). Эксплуатация проблемы может привести к исполнению произвольного кода в контексте текущего пользователя. Однако, по словам исследователей, для этого атакующему придется убедить свою жертву открыть специально созданный файл, содержащий данные СУБД JET. Этот формат используется самыми разными приложениями, и специалисты предостерегают, что вредоносный код будет выполнен на уровне текущего процесса.

Proof-of-concept эксплоит уже опубликован на GitHub.

Официального патча можно ждать не раньше октябрьского «вторника обновлений». Однако об устранении проблемы позаботились сторонние специалисты — инженеры компании Acros Security. Патчи для свежей уязвимости были представлены в составе их продукта 0patch. 0patch — это платформа, предназначенная как раз для таких случаев, то есть исправления 0day и других непропатченных уязвимостей, для поддержки продуктов, которые уже не поддерживаются производителями, кастомного софта и так далее. Свежая версия 0patch содержит исправления для 32- и 64-разрядных версий Windows 10, 8.1, 7, а также Windows Server 2008–2016.

Что чаще всего загружают ботнеты

Эксперты «Лаборатории Касперского» проанализировали активность 60 тысяч ботнетов, связанных со 150 семействами вредоносов. Как показало исследование, среди киберпреступников растет интерес к универсальным вредоносным программам, которые можно модифицировать под практически неограниченное количество задач.

• В целом количество скачанных их ботами уникальных вредоносных файлов в первом полугодии 2018 года (H1 2018) снизилось на 14,5% по сравнению со вторым полугодием 2017 года (H2 2017).

• В первой половине 2018 года доля бэкдоров выросла наиболее заметно по сравнению с другими категориями малвари. Так, если во второй половине 2017 года количество подобных инструментов для удаленного доступа составляло 6,6% от общего числа циркулирующих в ботнетах вредоносов, то за первые шесть месяцев текущего года она увеличилась почти вдвое и составила 12,2%.

• В 2018 году самыми «разносторонними» ботами остались Hworm, Smoke и BetaBot (он же Neurevt). При этом ботнеты все чаще предоставляются в аренду под «нужды» заказчика, и для многих ботнетов сложно выделить конкретную «специализацию».

• Наиболее распространенным бэкдором оказался njRAT. Он стал каждым 20-м файлом, скачиваемым ботами.

• Заметно выросли доли программ-загрузчиков и майнеров. Так, процентный показатель для первых увеличился с 5% (во второй половине 2017 года) до 12%, а для вторых — с 2,7% до 5%.

• Заметно снизились доли банковских троянов (с 22,5% до 13%) и спам-ботов (с 18,9% до 7%). Хотя эксперты уверены, что говорить об уменьшении общего количества банкеров преждевременно, поскольку довольно часто они доставляются на устройства программами-загрузчиками, доля которых, напротив, значительно выросла.

Facebook снова допустила утечку данных

Казалось бы, после скандала, связанного с компанией Cambridge Analytica и злоупотреблением пользовательскими данными, Facebook стала намного серьезнее относиться к безопасности пользователей. Однако в конце сентября социальная сеть вновь сообщила о масштабной компрометации, по предварительным оценкам затронувшей более 50 миллионов пользователей.

28 сентября 2018 года представители социальной сети сообщили, что неизвестные злоумышленники похищали чужие токены доступа, используя уязвимость, связанную с функцией «Посмотреть как» (View as). Данная функция позволяет увидеть свой профиль глазами другого пользователя.

По официальным данным, баг появился в коде еще в июле 2017 года, но, судя по всему, преступники обнаружили его сравнительно недавно. Дело в том, что инженеры Facebook заметили первые странные скачки трафика и подозрительную активность (которая, как оказалось позже, была связана с массовым хищением токенов) только в середине сентября 2018 года, когда, очевидно, и началась активная эксплуатация проблемы.

Полностью разобраться в происходящем специалистам Facebook удалось только 26 сентября 2018 года, и уже на следующий день брешь, использованную преступниками, закрыли. Никаких подробностей о самих злоумышленниках пока не известно, так как расследование инцидента еще далеко от завершения и к делу лишь недавно подключились правоохранительные органы. Также представители компании пока не закончили анализ данных пострадавших пользователей и не смогли сообщить, были ли атаки направлены против пользователей конкретных регионов или стран. По предварительным данным, атаки не были целевыми.

На экстренной пресс-конференции вице-президент компании Гай Розен (Guy Rosen) рассказал о некоторых технических деталях случившегося. Так, он объяснил, что обнаруженная неизвестными хакерами уязвимость, по сути, представляла собой комбинацию трех отдельных багов.

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

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

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

Именно совокупность этих ошибок позволила злоумышленникам массово похищать токены пользователей (получив один токен, хакеры тут же переключались на друзей жертвы, затем на их друзей и так далее).

Из-за случившегося инженеры Facebook решили разлогинить около 90 миллионов пользователей социальной сети. Сообщается, что токены для 50 миллионов учетных записей были аннулированы из-за злоупотреблений злоумышленников, но в качестве превентивной меры также были «отозваны» токены еще для 40 миллионов человек, которые пользовались функцией «Посмотреть как» за последний год. Сама проблемная функциональность было отключена на время проведения аудита безопасности.

Лидер проекта OpenBSD раскритиковал инженеров Intel

Тео де Раадт раскритиковал технологию одновременной многопоточности (Simultaneous Multithreading, SMT), hyper-threading и инженеров Intel. Эксперт пишет, что после недавнего обнаружения новых уязвимостей класса Spectre, получивших название Foreshadow, разработчики приняли решение вовсе отказаться от использования SMT после релиза OpenBSD 6.4.

«SMT фундаментально сломана, так как делит ресурсы между двумя CPU-инстансами и этим инстансам не хватает дифференциаторов безопасности. Некоторые из таких атак по стороннему каналу нетривиальны, но можно ожидать, что со временем большинство из них будут работать в самых обычных условиях (например, посредством JavaScript в браузере) и сливать данные ядра или данные между виртуальными машинами.

Будет раскрыто больше аппаратных багов и артефактов. С учетом того, как SMT взаимодействует со спекулятивными вычислениями на процессорах Intel, я ожидаю, что SMT только усугубит большинство этих грядущих проблем»,

— Тео де Раадт

Уязвимость, которую не исправят

Специалисты Nightwatch Cybersecurity нашли опасную уязвимость в Android (CVE-2018-9489).

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

Исследователи обнаружили, что информация о Wi-Fi-сети и интерфейсе транслируется сразу двумя Intent: WifiManager NETWORK_STATE_CHANGED_ACTION и WifiP2pManager WIFI_P2P_THIS_DEVICE_CHANGED_ACTION. Используя эту особенность, любые приложения и их рекламные компоненты могут узнать имя Wi-Fi-сети, BSSID, локальный IP, информацию о DNS-сервере и MAC-адрес устройства. Причем перехватить эти данные возможно даже в том случае, если у приложений нет разрешения на доступ к функциям Wi-Fi. Фактически атака позволяет обойти систему разрешений Android.

Хотя на первый взгляд «утекающие» данные могут показаться не слишком важными, нужно понимать, что с помощью этой информации рекламные компоненты приложений или малварь могут идентифицировать и отслеживать пользователя. К примеру, BSSID можно поискать в публично доступных базах WiGLE и SkyHook, таким образом узнав даже физическое местоположение жертвы. В этом случае атака, по сути, позволяет обойти еще и разрешение Location Access.

По данным Nightwatch Cybersecurity, перед проблемой уязвимы все версии Android старше 6.0, включая крупные форки, вроде FireOS компании Amazon. Исследователи проинформировали Google об уязвимости еще в марте текущего года, и инженеры компании исправили ее в Android Pie (9.0). Однако патчей для других версий ОС не ожидается.

Руткит для UEFI

Эксперты компании ESET рассказали о вредоносной кампании, в ходе которой был задействован первый известный руткит для Unified Extensible Firmware Interface (UEFI). Ранее подобное обсуждалось лишь с теоретической точки зрения на ИБ-конференциях.

По данным аналитиков, руткит для UEFI использует группа российских правительственных хакеров, известная под названиями APT28, Sednit, Fancy Bear, Strontium, Sofacy и так далее. Зафиксирован как минимум один случай успешного внедрения вредоносного модуля во флеш-память SPI, что гарантирует злоумышленникам возможность сохранить присутствие в системе не только после переустановки ОС, но и после замены жесткого диска.

Для внедрения руткита злоумышленники используют малварь LoJax — «близнеца» легитимного решения LoJack компании Absolute Software, созданного для защиты устройств от утери и кражи. Этот инструмент встраивается в UEFI и позволяет, к примеру, отслеживать местонахождение устройства или удаленно стереть данные.

Появление вредоносных версий LoJack было обнаружено экспертами компании Arbor Networks еще весной текущего года. Тогда выяснилось, что преступники незначительно изменили инструмент таким образом, чтобы он связывался с их управляющими серверами, а не с инфраструктурой Absolute Software. Исследователи называли LoJax «идеальным двойным агентом», так как он может удаленно выполнить произвольный код в системе и практически не отличается от легитимной версии инструмента.

Эксперты ESET обнаружили три типа вредоносов на скомпрометированном компьютере. Два из них отвечали за сбор данных об устройстве и его прошивке, тогда как третий занимался инъекциями вредоносных модулей и компрометировал прошивку, взаимодействуя с SPI-памятью. Для взаимодействия с UEFI/BIOS злоумышленники применяли RWEverything и драйвер ядра RwDrv.sys, причем драйвер был подписан действительным сертификатом.

Если же доступа на запись не было, преступники прибегали к помощи уязвимости в UEFI четырехлетней давности (CVE-2014-8273), которая позволяет обойти запрет.

Для защиты от LoJax в частности и подобных угроз в целом исследователи рекомендуют использовать механизм Secure Boot, проверяющий все компоненты прошивки и их сертификаты. Так как руткит LoJax цифровой подписи не имеет, подобная защита попросту не позволит малвари внедриться в систему. Также специалисты советуют убедиться, что на материнской плате установлена самая свежая прошивка, ведь для успешной реализации подобной атаки требуется, чтобы защита SPI-памяти была неверно настроена или уязвима. Если эти условия не будут соблюдены, реализовать атаку тоже не получится.

BlueBorne все еще опасен

• Год назад, в сентябре 2017-го, исследователи компании Armis предупредили, что 5,3 миллиарда устройств, работающих с различными имплементациями Bluetooth в Android, iOS, Windows и Linux, уязвимы перед восемью опасными проблемами, которым было присвоено общее название BlueBorne. Теперь специалисты Armis опубликовали отчет о том, как ситуация изменилась за прошедший год.

• Множество устройств, к сожалению, по-прежнему уязвимы перед BlueBorne, либо потому, что их не обновляют сами пользователи, либо потому, что производители просто не выпускают для них патчей. К настоящему моменту обновления получили лишь 2/3 уязвимых гаджетов. Это означает, что более 2 миллиардов устройств до сих пор работают без патчей.

Собранная Armis статистика такова:

• 768 000 000 устройств на базе Linux;
• 734 000 000 устройств на базе Android 5.1 (Lollipop) и раньше;
• 261 000 000 устройств на Android 6 (Marshmallow) и раньше;
• 200 000 000 устройств под управлением Windows;
• 50 000 000 iOS-устройств, работающих с версиями 9.3.5 и ниже.

Прогноз экспертов тоже выглядит неутешительно. По их мнению, BlueBorne-уязвимости будут представлять угрозу еще многие годы.

Злой курсор

Исследователи Malwarebytes рассказали о мошеннической группе Partnerstroka, которая блокирует пользователей Google Chrome на сайтах фальшивой технической поддержки при помощи новой техники «злой курсор» (evil cursor).

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

В последнем случае пользователя вынуждают связаться с фальшивой технической поддержкой для «разрешения проблемы». Это может окончиться как установкой малвари, которая даст злоумышленникам доступ к системе (под видом антивируса), так и просто оплатой неких услуг псевдосаппорта.

Подобными мошенническими операциями и занимается группа Partnerstroka, за которой уже какое-то время наблюдают эксперты Malwarebytes.

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

Хотя в целом техники злоумышленников достаточно типичны для скама такого рода, использование методики evil cursor отличает эту кампанию от остальных. Мошенники используют баг в Chromium, который провоцируется простым HTML-кодом. В итоге пользователь кликает совсем не туда, куда установлен его курсор.

Фактически этот Base64 blurb декодируется в курсор с низким разрешением, но злоумышленники также используют прозрачный пиксель размером 128 × 128, что превращает курсор в огромную область. В итоге пользователь кликает совсем не туда, куда ему кажется, и не может покинуть мошенническую страницу.

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

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

CSS перегружает iPhone

В Сети был опубликован proof-of-concept эксплоит для проблемы в движке WebKit, в частности используемом браузером Safari. После загрузки HTML-страницы, содержащей специальный CSS-код, iOS «падает» и перезагружается.

Для эксплуатации проблемы используется CSS-эффект backdrop-filter, который применяется ко множеству DIV-элементов на странице. Backdrop-filter — сравнительно новое явление для CSS, данный эффект позволяет размыть или исказить цвета в зоне за каким-либо элементом. Подобная операция требует немалых ресурсов, и это давно беспокоило некоторых разработчиков.

Обоснованность этих тревог в минувшие выходные доказал разработчик и ИБ-специалист Сабри Аддуш (Sabri Haddouche), который и обнаружил проблему. Исследователь опубликовал в своем твиттере ссылку на PoC-эксплоит, а также выложил видеодемонстрацию атаки, приводящей к перезагрузке смартфона. В зависимости от версии ОС атака приводит к простой перезагрузке и перезапуску UI или же провоцирует kernel panic и тоже приводит к ребуту.

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

При этом Аддуш рассказывает, что баг затрагивает отнюдь не только iOS, он также может оказывать негативное влияние на macOS. По словам исследователя, в текущем виде (только HTML и CSS) атака «заморозит» Safari и замедлит macOS на добрую минуту и лишь после этого пользователь сможет закрыть проблемную вкладку.

Более серьезная атака на десктопную версию браузера потребует модификации эксплоита и добавления JavaScript. Однако публиковать этот эксплоит исследователь не рискнул, так как проблема сохраняется даже после перезагрузки устройства, Safari вновь подгружает вредоносную страницу, и цикл повторяется снова.

Стоит заметить, что в конце месяца Аддуш, который продолжает искать DoS-уязвимости в качестве хобби, обнаружил еще одну очень похожую проблему в коде браузера Firefox. Баг работает для Mac, Linux и Windows, но не для Android. Затронуты все последние версии, включая Firefox Developer и Nightly.

Как и в случае WebKit, порой проблема влияет не только на сам браузер, но и на операционную систему в целом. В случае Mac и Linux эксплуатация бага приводит к «падению» процесса браузера и появлению классического сообщения о сбое в работе. В случае Windows все обстоит несколько хуже. Эксплуатация ошибки приводит не только к проблемам с самим браузером, она может и «подвесить» операционную систему в целом, и в итоге пользователю придется делать «жесткую» перезагрузку.