Что такое вирус вайпер
Обновлено: 23.04.2024
В этой части рассматриваем зловредов, которые способны причинить реальный вред пользователям смартфонов и планшетов.
В прошлой серии истории о мобильной нечисти мы рассказывали про сравнительно безобидные зловреды, которые могут завестись в ваших смартфонах или планшетах. Сегодня мы поговорим о тварях более опасных — тех, что с гораздо большей вероятностью оставят вас без денег или без мобильника.
Мобильные вымогатели
Люди очень сильно зависят от своих смартфонов (мы уже рассказывали — насколько), и если доступ к телефону у них отобрать, они будут готовы на многое, лишь бы его вернуть. На это и делают ставку создатели мобильных троянов-вымогателей, которые не дают пользоваться телефоном и требуют заплатить выкуп, чтобы вновь получить доступ к функциям устройства и данным на нем.
Впрочем, для мобильных зловредов довольно характерно и шифровать, и блокировать — этим, например, промышляет одна из модификаций трояна Svpeng, который довольно часто встречался нам и в прошлом, и в этом году.
Если блокировщики для компьютеров практически исчезли — уж больно их легко обходить, то для мобильных они только набрали обороты. Например, в 2017 году 83% обнаруженных программ-вымогателей пришлось на семейство троянов Congur, которые не позволяли пользоваться устройством, пока не введешь пин-код.
Как и для десктопных блокировщиков, для их мобильных собратьев также характерно обвинять пользователя в нарушении какого-нибудь закона — обычно на тему просмотра порнографии — и требовать заплатить якобы штраф якобы в госорганы. На самом же деле деньги уйдут злоумышленникам. Ну и распространяются такие зловреды чаще всего именно через порносайты.
Мобильные вайперы
Мобильные майнеры
Если ваш смартфон вдруг начал сильно греться, страшно тормозить и быстро разряжаться, то, скорее всего, на нем завелся скрытый криптомайнер, который втихую добывает для кого-то криптовалюту за ваш счет.
Зловред можно подцепить даже в официальном магазине приложений: такие программы успешно маскируются, старательно изображая законопослушность и добросовестно выполняя все указанные в описании функции, а в фоновом режиме добывают для хозяина виртуальные деньги. С другой стороны, программы, скачиваемые из сторонних источников, очень стараются выдавать себя за какие-нибудь системные приложения. Бывает, вредонос даже прикидывается приложением для обновления собственно Google Play, как, например, HiddenMiner.
Майнеры не крадут ваших денег и не стирают файлы, но их опасность не стоит недооценивать: из-за избыточной нагрузки устройство может не только тормозить и слишком быстро разряжаться, но и перегреваться — вплоть до выхода из строя.
Как защититься?
От большинства непрошеных вторжений, какими бы неприятными они ни были, можно защититься, соблюдая несколько правил:
Есть немногочисленная, но необычная категория зловредов, преследующих одну единственную цель: уничтожить всю информацию, до которой удастся дотянуться. Их называют вайперы.
В конце 90-х Интернет еще не был носителем столь огромного количества ценных данных, кои он хранит в наши дни, и организованной преступности только предстояло разглядеть финансовую ценность в относительно легко доступной информации. Поэтому ранние образцы зловредного ПО имели в первую очередь деструктивную природу, а тогдашние хакеры занимались преимущественно дуракавалянием и хулиганством, а не кражами и шпионажем: выпускаемые тогда программы шифровали содержимое жесткого диска (аналогично современным шифровальщикам) или портили данные каким-нибудь образом, просто так. В общем, среди вирусописателей того времени главной целью были не деньги.
Первая из них, носившая название Wiper, оказалась столь эффективна, что затерла даже следы своего пребывания с тысяч предположительно инфицированных иранских компьютеров, что исключило всякую возможность как следует изучить заразу. Тем не менее эта атака оказала столь значительное влияние, что вполне могла вдохновить многие другие подобные инициативы.
Одной из них предположительно является создание и распространение Shamoon. Этот зловред поразил одну из крупнейших и богатейших компаний в мире — нефтедобывающую корпорацию Saudi Aramco. Проникший в августе 2012 года во внутреннюю сеть компании вирус умудрился уничтожить содержимое более 30 тысяч рабочих станций. Впрочем, в отличие от Wiper, это ПО не смогло избавиться от следов своего присутствия. Это позволило установить, что для атаки в зловреде были реализованы не самые изящные, но очень эффективные методы.
И, наконец, Dark Seoul — угроза, появившаяся совсем недавно, буквально в мае 2013 года. В соответствии со своим названием программа была нацелена на несколько финансовых учреждений и телерадиовещательных компаний южнокорейского Сеула. Эта атака отличалась от вышеописанных не только непричастностью Саудовской Аравии или Ирана, но и тем, что была слишком заметна. Так что, скорее всего, организаторы хотели просто привлечь к себе внимание и искупаться в лучах хоть и сомнительной, но все же славы.
В этом смысле США повезло несколько больше других. Вскоре Конгресс Соединенных Штатов проголосует по так называемому Акту защиты национальной кибербезопасности и критической инфраструктуры 2013 года. Этот билль призван наладить взаимосвязь государства и управляющих критической инфраструктурой компаний, в рамках которой стороны должны будут обмениваться касающейся тех или иных угроз информацией. Подобные инициативы, впрочем, готовятся и в других странах. И это правильно.
На данный момент специалисты не обнаружили никаких признаков того, что были атакованы другие страны помимо Украины.
Исследователи из ESET Research Labs обнаружили новое вредоносное ПО, использовавшееся в кибератаках на украинские организации, в том числе правительственные, до и после входа российских войск на территорию Украины 24 февраля.
В ходе анализа атак исследователи выявили новый уничтожитель данных (так называемый вайпер), получивший название IsaacWiper, а также червь HermeticWizard, использовавшийся для загрузки второго вайпера HermeticWiper с помощью модулей WMI и SMB. Специалисты пока не связали вредоносные программы ни с одной киберпреступной группировкой.
HermeticWiper и IsaacWiper также развертывались в отдельных компаниях. Первый из них впервые был замечен 23 февраля за несколько часов до начала наступления российских войск. Вредонос распространялся с помощью HermeticWizard по локальным сетям вместе с вымогательским ПО на Go HermeticRansom. В свою очередь, IsaacWiper использовался во второй серии атак на украинские правительственные сети 24 февраля.
На данный момент специалисты не обнаружили никаких признаков того, что были атакованы другие страны помимо Украины. Однако на прошлых выходных Агентство кибербезопасности и безопасности инфраструктуры США (CISA) и ФБР предупредили американские организации о том, что атаки на Украину с использованием вайперов могут случайно перекинуться на сети в других странах.
Специалисты Microsoft Threat Intelligence Center (MSTIC) также зафиксировали атаки на Украину, в ходе которых развертывалось вредоносное ПО HermeticWiper (FoxBlade в классификации Microsoft).
Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!
За последний год о VIPER писали все кому не лень. Эта архитектура реально вдохновляет разработчиков. Но большинство статей, на самом деле, довольно предвзяты. Они лишь показывают крутизну этого архитектурного паттерна, умалчивая о его негативных сторонах. А ведь проблем у него вовсе не меньше (а может даже и больше) чем у других. И в этой статье я постараюсь объяснить, почему VIPER вовсе не так хорош как о нем говорят, и почему он не подойдет для большинства ваших приложений.
Некоторые статьи о сравнении архитектур, как правило, утверждают что VIPER совершенно не похож на другие MVC-архитектуры. Но на самом деле, VIPER — это просто нормальный MVC, где контроллер разделен на две части: interactor и presenter. View остался на месте, а модель переименована в entity. Router заслуживает особого внимания: да, другие архитектуры не упоминают эту часть в своих аббревиатурах, но он присутствует и в них: в неявном виде (когда вы вызываете pushViewController — вы создаете простой маршрутизатор) или более очевидном (как пример — FlowCoordinators).
Поговорим о "плюшках", которые предлагает нам VIPER (я буду ссылаться на эту книгу). Посмотрим на цель номер два, в которой говорится о SRP (принцип единой ответственности). Это прозвучит грубо, но каким чудаком нужно быть, чтобы считать это преимуществом? Вам платят за решение задач, а не за соответствие модным словам. Да, вы до сих пор используете TDD, BDD, юнит-тестирование, Realm или SQLite, внедрение зависимостей и много-много других вещей, но вы используете все это не просто ради использования, а для решения проблем клиента.
Это еще один интересный аспект и очень важная задача. По хорошему, о тестировании можно было бы написать отдельную статью, ведь многие говорят об этом, но мало кто действительно тестирует свои приложения, и еще меньше людей делают это правильно.
Одна из главных причин в том, что нет хороших примеров. Вы можете найти довольно много статей на тему того как написать юнит-тест assert 2 + 2 == 4 , но реальных примеров не найдете (тем не менее Artsy держит в опен-сорсе свои приложения, и вам следует взглянуть на их проекты).
VIPER предлагает отделить всю логику во множество мелких классов с разделенными обязанностями. Это должно бы облегчить тестирование, но так не всегда. Да, написать юнит-тест для простого класса легко, но большинство из таких тестов ничего не тестируют. Давайте посмотрим, например, на большинство методов презентера: они лишь прокси между вью и другими компонентами. Вы можете написать тесты для этого прокси, это увеличит тестовое покрытие вашего кода, но эти тесты бесполезны. И у вас будет побочный эффект: вы должны обновлять эти бесполезные тесты после каждого внесения изменений в код.
Правильный подход к тестированию должен бы включать в себя тестирование интерактора и презентера сразу, ведь эти две части сильно связаны друг с другом. Кроме того, поскольку мы разделяем логику на два класса, нам нужно намного больше тестов по сравнению с одним классом. Это простая комбинаторика: у класса A есть 4 возможных состояния, а у класса B — 6, соответственно их комбинация имеет 24 возможных состояния, и вам нужно их протестировать.
Правильный подход для упрощения тестирования представляет из себя чистоту кода вместо того, чтоб просто разделить сложный код на кучу классов.
Как ни странно, тестировать вью проще чем тестировать некоторые участки бизнес-логики. Вью представляет собой лишь совокупность определенных свойств и наследует внешний вид из этих свойств. Вы можете использовать FBSnapshotTestCase для сравнения их состояния с внешним видом. Эта штука все еще не обрабатывает некоторые особые случаи, как кастомные переходы, но насколько часто вы их используете?
VIPER — то, что происходит, когда бывшие джависты врываются в мир iOS. — n0damage, комментарий на reddit
Вот честно, может кто-нибудь посмотреть на это и сказать: "да, эти дополнительные классы и протоколы действительно улучшают мое понимание того что происходит в моем приложении".
Представьте себе простую задачу: есть кнопка, которая запускает обновление с сервера и есть вью, с полученными от сервера данными. Угадайте-ка сколько классов/протоколов будут задеты таким изменением? Да, как минимум 3 класса и 4 протокола будут изменены для реализации такой простой функции. Кто-нибудь помнит как Spring начали с некоторых абстракций и закончили с AbstractSingletonProxyFactoryBean ? Я всегда мечтал об "удобном суперклассе прокси-фабрики для прокси-фабрик, которые создают только синглтоны" в моем коде.
Избыточные компоненты
(Избыточный код не так безобиден, как я привык думать. Он дает ложный сигнал о своей необходимости.)
Как я уже упоминал ранее, презентер, как правило, довольно глупый класс, который просто передает вызовы из вью в интерактор (что-то вроде этого). Да, иногда он содержит сложную логику, но в основном, это просто избыточный компонент.
(Некрасивый код легко распознать и его стоимость легко оценить. Это не так если абстракция неверна.)
Существует общая путаница с этим сокращением: VIPER реализует принципы SOLID, где DI — это "инверсия зависимостей", а не "внедрение" ("dependency inversion", а не "injection"). Внедрение зависимостей — это особый случай паттерна "инверсия управления" ("Inversion of Control"), который, конечно связан, но отличается от инверсии зависимостей.
Инверсия зависимостей — это про отделение модулей разных уровней путем ввода абстракций между ними. Для примера, модуль UI не должен напрямую зависеть от сетевого модуля. Инверсия управления — это другое. Это когда модуль (обычно из библиотеки, которую мы не можем менять) делегирует что-нибудь другому модулю, который обычно предоставлен первому модулю как зависимость. Да, когда вы реализуете data source для вашей UITableView вы используете принцип IoC. Использование схожих названий для различных высокоуровневых вещей — источник путаницы.
Вернемся к VIPER. Есть много протоколов (как минимум 5) между классами внутри одного модуля. И во всех них нет необходимости. Презентер и интерактор не являются модулями из разных слоев. Применение принципа IoC может иметь смысл, но спросите себя: как часто у вас бывает хотя бы два презентера для одного вью? Я уверен, что большинство из вас ответит "никогда". Так почему же необходимо создавать эту кучу протоколов, которые мы никогда не будем использовать?
Кроме того, из-за этих протоколов, вы не можете легко перемещаться по коду в IDE. Ведь cmd+click будет вас выбрасывать в протокол, вместо реализации.
Проблемы с производительностью
Это ключевой момент, но многие просто не переживают об этом, или просто недооценивают влияние плохих архитектурных решений.
Я не буду говорить о фреймворке Typhoon (который очень популярен для внедрения зависимостей в мире objective-c). Конечно, он имеет некоторое влияние на производительность, особенно когда используется автоматическое внедрение, но VIPER не требует его использования. Вместо этого, я бы поговорил о рантайнме и запуске приложения, и как VIPER замедляет ваше приложение буквально повсюду.
Время запуска приложения. Эта тема редко обсуждается, но она важна. Ведь если ваше приложение стартует очень медленно, то пользователи не будут им пользоваться. На последней WWDC как раз говорили об оптимизации времени запуска приложений. Время старта вашего приложения напрямую зависит от количества классов в нем. Если у вас есть 100 классов — это нормально, задержка будет незаметной. Однако, если в вашем приложении только 100 классов — вам действительно нужна эта сложная архитектура? Но если ваше приложение огромно, например, вы работаете над приложением Facebook (18К классов), то разница будет ощутима: около одной секунды. Да, "холодный старт" вашего приложения займет 1 секунду только на то, чтоб подгрузить все метаданные классов и больше ничего, вы правильно поняли.
Слабое разделение абстракций
Один из самых популярных вопросов VIPER-сообщества: "куда мне следует отнести X?" Получается, что с одной стороны есть много правил, как нужно делать все правильно, а с другой — многие решения основаны на чьем-нибудь мнении. Это могут быть сложные случаи, например обработка CoreData с помощью NSFetchedResultsController , или UIWebView . Но даже общие случаи, такие как использование UIAlertController — являются темой для обсуждения. Давайте взглянем: здесь с нашим алертом взаимодействует роутер, а здесь его показывает вью. Вы можете ответить, что этот простой алерт является частным случаем алерта без каких-либо действий, кроме закрытия.
Все верно, но зачем у нас здесь фабрика для создания таких алертов? В итоге имеем бардак даже с UIAlertController . Вы этого хотите?
Генерация кода
Как это может быть архитектурной проблемой? Это просто генерация кучи классов по шаблону вместо написания их вручную. В чем здесь проблема? Проблема в том, что большинство времени вы читаете код, а не пишете его. Таким образом вы читаете шаблонный код вперемешку со своим кодом большую часть своего времени. Хорошо ли это? Не думаю.
Я не преследую цель отговорить вас от использования VIPER вообще. Вполне могут быть приложения, которые от него только выигрывают. Однако, прежде чем начать разработку своего приложения вам следует задать себе пару вопросов:
Будет ли у этого приложения длительный жизненный цикл?
Достаточно ли стабильны требования? В противном случае вы столкнетесь с бесконечным рефакторингом даже при внесении мелких изменений.
Только если вы ответили "да" на все три вопроса, VIPER мог бы быть хорошим выбором для вашего приложения.
И, наконец, последнее: вы должны самостоятельно принимать решения. Не просто слепо доверять какому-то парню с Медиума (или Хабра), который говорит "Используйте X, X — это круто." Этот парень тоже может ошибаться.
Рекомендуем почитать:
27 июня 2017 года, спустя чуть больше месяца после атак WannaCry, мир столкнулся с новой вымогательской эпидемией, причиной который стала новая версия шифровальщика Petya, известного специалистам еще с 2016 года.
С нашим подробным обзором Petya и сложившейся вокруг него ситуации можно ознакомиться здесь. Напомню, что ранее сообщалось, что малварь шифрует не только файлы пользователя, но и MFT (Master File Table), перезаписывает MBR (Master Boot Record) и имеет кастомный загрузчик, который отображает вымогательское послание, вместо загрузки операционной системы.
Как новая версия Petya генерирует ID, показано на иллюстрациях ниже. Малварь использует для этого функцию CryptGenRandom, то есть генерирует случайную последовательность ничего не значащих символов. Такой ID не несет в себе ровным счетом никакой информации, создается лишь для отвода глаз и точно не поможет расшифровать файлы. Таким образом, платить выкуп бесполезно не только из-за того, что Posteo заблокировал почтовый ящик преступников.
В своем отчете Мэтью Сюиш сравнивает Petya с другим известным вайпером, Shamoon. Исследователь сообщает, что зашифрованные Petya диски практически невозможно восстановить. Сравнив Petya образца 2016 года с новой версией, эксперт не мог не заметить существенную разницу: новая версия намеренно уничтожает первые 25 секторов на диске. Первый сектор диска шифруется с помощью XORс 0x07, после чего сохраняется в другом секторе и заменяется кастомным загрузчиком. Но все 24 следующие за ним сектора перезаписываются намеренно и нигде не сохраняются.
Petya 2017 слева и Petya 2016 справа
Оригинальный Petya тоже производил похожие операции, однако он действительно мог обратить все сделанные изменения, тогда как новый Petya повреждает данные умышленно и гораздо серьезнее.
Читайте также: