Хотів би розповісти про мобільні рекламні мережі, про їх систему захисту і способи її обходу. Способи обходу систем захисту застосовувалися тільки в освітніх цілях. Також зауважу, що алгоритми атак, представлені тут, справедливі для будь-яких платформ, проте в прикладі наводиться робота Android, оскільки атаки на його код найпростіші для опису.
Що таке мобільна рекламна мережа? Це клієнт-серверний додаток, в якому сервер приймає від клієнтських додатків доповіді про запуск програми, здійснення кліків з реклами та вчинення дій, а також висилає їм рекламу для відображення користувачеві. Клієнтські програми є бібліотеками, здатними взаємодіяти з сервером, які зазвичай вбудовуються в мобільні програми сторонніх розробників.
Потужність рекламної мережі вимірюється в кількості користувачів у додатків, які показують рекламу, що логічно - чим більше реклами мережа зможе показати користувачам, тим більше грошей вона заробить і тим привабливішою вона буде для інших рекламодавців.
Щоб збільшити кількість додатків, що показують рекламу, мережі намагаються залучити сторонні програми замість написання своїх. Вони надають розробникам своє рекламне SDK, здатне спілкуватися з їхніми серверами. За це вони дають таким розробникам певний% від зароблених грошей за покази кліки або дії, вчинені зі стороннього додатку. У цій чесній співпраці задоволені всі: рекламна мережа отримує новий додаток з готовою аудиторією, якою можна показувати рекламу, сторонній розробник отримує гроші з цієї реклами, а рекламодавець - велику аудиторію.
Будь-якому партнеру рекламної мережі видається пара appId - ID програми в базі рекламної мережі і secret - секретний ключ для підписування дій. Будь-кому - в ідеалі, оскільки деякі рекламні мережі видають його тільки рекламодавцям.
Що відбувається далі? При старті програми ця пара надходить в рекламне SDK і все, робота сумлінного інтегратора на цьому етапі закінчується. Якщо це рекламна програма - вона робить запит на сервер, надсилаючи всі свої параметри (різні ідентифікатори, такі як imei, openudid, udid, serial), інформацію про пристрій і платформу і свій appId. Все це вона підписує секретом, зазвичай роблячи sha1 хеш від пересиланих параметрів і додаючи його до запиту. Сервер, після перевірки справжності, видає програмі рекламу. Кожна рекламна одиниця супроводжується комплектом з двох посилань. Це посилання на поки (яке є не у всіх рекламних мереж) і посилання на клік. Коли реклама з'являється на екрані і користувач її реально бачить - дергается посилання на показ і факт показу відправляється на сервер. Якщо ж користувач зацікавиться і зробить клік - факт кліка також піде на сервер за іншим посиланням.
В результаті цих дій рекламуючий додаток, з якого були вчинені дії - отримає гроші.
Перегляди і кліки
Що буде, якщо розробник недобросовісний і хоче отримати гроші просто так? У цьому випадку він також реєструється в рекламній мережі, інтегрує в нього рекламну SDK і виводить додаток на ринок. Далі йому потрібно послати підроблений запит на отримання реальної реклами, відіслати факт показу і кліка та отримати гроші. Щоб це зробити, необхідно вивчити, які параметри необхідні для запиту та їх формат. Деякі рекламні мережі самі пишуть цю інформацію в документації, в інших відкрито вихідний код SDK. Треті постачають свої SDK, як бібліотеки з закритим вихідним кодом. Зловмисник повинен отримати бібліотеку рекламної мережі, після чого змінити механізм формування рекламного запиту таким чином, щоб ідентифікатори пристрою не збиралися, а генерувалися випадковим чином.
Злом закритої бібліотеки
Закриті SDK під Android зазвичай поширюються у вигляді jar-архіву зі скомпільованими класами. Вихідний java-код можна отримати за допомогою Java-декомпілятора, наприклад, jd gui. Тут може виникнути проблема маскування методів у вкладених класах. Java-компілятор у разі вкладеності класу в клас і виклику методу верхнього класу з нижнього змінює виклик методу на створений ідентифікатор методу $ access. У цьому випадку зловмиснику потрібно здогадуватися, який метод повинен бути викликаний за змістом і за переданими параметрами. Дана незручність не сильно ускладнить дії зловмисника, проте може ускладнити автоматизацію злому SDK.
У результаті зловмисник відсилає запит на рекламу з appId свого рекламуючого додатку і неіснуючого пристрою. Потім отримує рекламу і дергає посилання на вчинення дій. Все просто.
Захиститися від такого шахрайства на боці SDK неможливо, тому рекламні мережі відмовляються від реклами з переглядами і кліками і переходять до наступного типу реклами - реклама за установки.
Параметри і дії
Підробляти установки складніше, оскільки в них бере участь рекламований додаток. При сумлінному використанні відразу після кліка по рекламі користувач, який зацікавився, починає установку цього додатку. Коли програма встановлена, вона також використовує рекламну SDK, щоб надіслати факт встановлення на сервер. У разі реклами за дії - факту встановлення не достатньо. Користувач після встановлення повинен виконати в програмі певну дію, про яку також буде повідомлено рекламній мережі.
Зловмиснику необхідно знати секретний ключ рекламованого додатку, щоб послати підроблений факт установки або дії.
Як це зробити? Потрібно 1 раз завантажити додаток, декомпілювати і отримати секретний ключ. Для платформи Android це не викличе складності.
Пакети програм під ОС Android поставляються у вигляді архівів з розширенням apk. В архіві містяться ресурси програми, медіа-файли, інші файли та dex-файл зі скомпільованими класами програми.
Саме він і цікавить зловмисника. За допомогою програми dex2jar зловмисник може отримати jar-ахрів зі скомпільованим вихідним кодом програми і після цього приступити до декомпіляції для отримання секретного коду.
У разі, якщо розробник програми не приділяв уваги захисту програми і не обфускував код, секретні параметри програми будуть зберігатися у відкритому вигляді в коді. Достатньо лише зробити пошук за класом і функції, яка викликає рекламне SDK.
Декомпільований клас
У більшості випадків розробники додатків намагаються ускладнити злом, переносячи секрет і id програми рекламної мережі з коду, де його можна просто дістати, в ресурси і обфускуючи додаток, щоб заплутати зловмисника.
Ресурси програми знаходяться там само в apk-пакеті у файлі resources.arsc. Це спеціальний файл, що містить таблицю ресурсів програми. На малюнку вище видно, що мета зловмисника - секрет і id програми в рекламній мережі заховані у файлах з ресурсами, а код, що викликає їх, обфусційований.
Обфускований клас
Про це можна судити з того, що замість рядка виду TapjoyConnect.requestTapjoyConnect (paramContext.getApplicationContext (), «appId», «secret»); знаходиться цикл, що проходить 1 раз і отримує id програми і секрет з ресурсів. У цьому випадку зловмиснику доводиться шукати цікавий його фрагмент коду в усьому додатку і аналізувати весь заплутаний обфускатором код.
Секрет і id цієї програми були заховані у файлі ресурсів. Разом з тим, всі ідентифікатори ресурсів при компіляції програми під Android заносяться в R.class, який генерує Android SDK. Тому зловмисник може підглянути за номером id назву ресурсу, який викликається. У фрагменті коду id додатку відповідає код 2131165201, а секрету - код 2131165202.
Пошук за цими кодами в R класі показує, що використовується ресурс з назвою tapjoy_amazon_app_id і tapjoy_amazon_secret_key. Все, що тепер потрібно зловмиснику - отримати доступ до файлу ресурсів strings.xml, закодованому в resources.arsc.
Щоб це зробити, необхідно декодувати apk-пакет програми за допомогою утиліти apktool, після чого стануть доступними всі ресурси програми і зловмисник може просто відкрити його текстовим редактором і знайти ресурси за заздалегідь отриманими іменами.
Знайдені ресурси
Як тільки зловмисник отримав секретний ключ, він може відправити факт фальшивої установки з тих підроблених ідентифікаторів, які він згенував на етапі запиту реклами.
Рекомендації до рекламних мереж
Захисту рекламної SDK в даному випадку недостатньо. Навіть якщо використовувати нативну бібліотеку замість Java - вдасться лише ускладнити злом (і нажити проблеми з сумісністю), тому що вона поширюється вільно і завжди буде доступна зловмиснику. Щоб ловити підроблені факти - потрібно використовувати наступне:
У разі логічного захисту потрібно:
- не враховувати кліки, якщо перед цим не було запиту на рекламу
- не враховувати кліки, якщо перед цим не було факту перегляду
- не враховувати параметри, якщо після кліка минуло занадто мало часу (залежить від розміру програми)
- запам'ятовувати, яка реклама була віддана в запиті на рекламу і не допускати переглядів/кліків з реклами, яку користувач не отримував
- після кліка не допускати кліків по інших рекламах з тієї ж видачі
Дотримання рекомендацій для логічного захисту дозволить значно знизити темпи фальсифікації фактів зловмисником, однак якщо він теж здогадається подивитися цей спойлер, то рекламній мережі знадобиться більш складний захист.
Необхідно перевіряти реальну кількість установок для рекламуючих програм. На жаль, в даний момент магазини додатків не надають цієї інформації третім особам. Однак можна подивитися в бік Google Analytics. Якщо кількість пристроїв, на які йде реклама, перевищує кількість встановлених, то партнер є зловмисником.
Також можна стежити за всіма пристроями, які посилають факти установок/запитів на рекламу. І якщо протягом місяця з даних ідентифікаторів не було зроблено ніякої дії - вважати такий пристрій випадково згенерованим зловмисником і неіснуючим.
Якщо у рекламної мережі достатньо трафіку, то не варто відправляти одну і ту ж рекламу одному рекламуючому додатку. Це істотно знизить швидкість злому, оскільки зловмисник завжди буде отримувати секрети рекламодавців повільні, чим буде відбуватися ротація реклами.
І насамкінець - вимагайте, щоб ваші рекламодавці обфускували код в обов'язковому порядку і введіть зміну секрету раз на деякий час або на певну кількість підписувань фактів.
Подальші дії
Цей спойлер не є рекомендаціями зловмисникам. Його мета - показати мережам, що можливі не тільки штучні зломи і їм є чого боятися.
Якщо зловмисник серйозно підійде до питання злому, він цілком зможе його автоматизувати. Пошук навіть за обфусційованим кодом не є складним завданням, оскільки ім'я класу і метод виклику рекламної SDK завжди відкрито. А якщо врахувати, що досить великий відсоток розробників не обфускують код - то можна в автоматичному режимі отримати досить велику кількість секретів.
Схема, за якою можуть діяти зловмисники полягає у створенні декількох додатків, завдання яких - збір великої кількості рекламованих додатків для злому. Як тільки накопичиться досить велика кількість даних - можна запускати додаток, який використовує зібрані бази для відправки фальсифікованих даних.
