Если сегодня к вечеру соберусь с силами, то сделаю стрим про хранение API ключей в нативном коде и покажу как это все оттуда достать без особых проблем. Разбор будет по мотивам статьи, которая недавно появилась в чате и, к моему удивлению, вызвала какие-то обсуждения даже.

https://www.youtube.com/watch?v=LpOvHhpcVG4

Весь код, который показывал на стриме можно взять тут: https://github.com/Android-Guards/storing-api-keys

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

https://youtu.be/Xn6CSqJpf6I

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

Первая библиотека называется argon2kt и распространяется под лицензией MIT, вторая называется еще более незамысловато - Argon2 и выложена под лицензией GPL-3.0. Если не смотреть на лицензии, то нужно выбирать вторую, т.к. ее написали ребята из Signal (защищенный мессенджер, если кто не в курсе). Уж они то знают толк! Не то, что какой-то ноу-нейм! При более трезвом рассмотрении вопроса, мы узнаем, что лицензия MIT не накладывает никаких ограничений на использование, в т.ч. может применятся в проприетарном ПО без раскрытия исходного кода или его кусков. GPL-3.0, в свою очередь требует раскрытия исходников (см. секцию Conditions тут), что не очень то подходит для проприетарного ПО, которые вы чаще всего пишите.

При этом ответ на вопрос "А за мной точно придут?" звучит как "хз". Может да, может нет. Но если да, то будет очень плохо =) Поэтому взвешивайте риски и будьте умницами.

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

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

А с чем интересным сталкивались вы? Делитесь в комментариях.

Многие из вас используют JADX и наверняка видели там функцию экспорта декомпилированных исходников в виде Gradle проекта. Мне эта функция всегда не нравилась, потому что она экспортировала проект в старом формате и проще был ей не пользоваться чем постоянно исправлять результат этого экспорта. В какой-то момент я нашел в себе силы и решил "все пофиксить". И пофиксил =) А еще закинул PR в основной репозиторий и его уже приняли. Так что если кому-то этой штуки не хватало, то теперь она у вас есть.

https://github.com/skylot/jadx/pull/1097

Давно хотел сделать этот формат и похоже звезды сошлись. В этот четверг 04.02.2021 в 19:00 по MSK, запишем подкаст с Павлом Васильевым - android-разработчиком с большим интересом к информационной безопасности.

Я люблю ковыряться со всякими необычными интерфейсами, работал в андроиде с NFC, Bluetooth, USB. Работал с разными бесконтактными карточками, кассовыми аппаратами на android, работал с аппаратными модулями безопасности.

Павел пишет статьи и выкладывает свои наработки на GitHub. Все ссылки будут в шоуноутах.

До встречи в эфире!

https://youtu.be/a4ewiusM1f8

UPD: Перезалил подкаст в аудиоформате. Видео в этот раз не получилось. Будет в следущий. Чуть позже раскатаю еще на всякие площадки чтобы можно было слушать в плеере.

Вышла статья от Паши Васильева, с которым мы общались недавно в подкасте.

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

Как говорил ранее - рекомендую прочитать ее всем, независимо от вашего уровня. Она реально крутая.

https://habr.com/ru/post/541190/

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

Google Podcasts - https://podcasts.google.com/feed/aHR0cHM6Ly9hbmNob3IuZm0vcy80YjMyODkxYy9wb2RjYXN0L3Jzcw==

Apple Podcasts - https://podcasts.apple.com/us/podcast/android-guards-community-podcast/id1552280775

Или поищите в своем плеере подкастов, возможно есть уже и там.

Google продолжает радовать неплохими документами. На этот раз они собрали хороший чеклист, по основным требованиям к качеству Android-приложений. Это не какое-то божественное откровение, просто хороший чеклист. Нас, как обычно, интересует "шо там по безопасности". Рекомендации (или требования) опять же довольно стандартные, но удобно, что собраны в одном месте и без воды (в отличие от этого сообщения).

Коротко, что имеем:

- Запрашивать как можно меньше разрешений
- Без крайней нужды не запрашивать разрешения на возможности, которые тратят деньги пользователя (SMS и звонки)
- Запрашивать разрешения в контексте функциональности, а не "на всякий случай" при старте приложения
- Объяснять пользователю зачем запрашиваете разрешения
- Вся конфиденциальная информация должна храниться только во внутреннем хранилище (internal storage)
- ПД и прочая конфиденциальная инфа не должна попадать в логи
- Не использовать хардварные идентификаторы, такие как IMEI для идентификационных целей
- Предоставлять подcказки для autofill фреймворка
- Интегрировать One Tap Sign-up/Sign-in
- Интегрировать биометрическую аутентификацию
- Экспортировать только те компоненты, которые должны делиться данными с другими приложениями
- Все интенты и бродкасты должны следовать лучшим практикам безопасности (почитайте по ссылке, там много)
- Все контент провайдеры, которые шарят данные между вашими приложениями должны использовать protectionLevel=signature
- Весь сетевой трафик отправляется только по SSL
- Должен быть настроен пиннинг через network security configuration
- Если приложение использует сервисы Google Play, то security provider нужно инициализировать при старте приложения
- Все библиотеки должны иметь актуальные версии
- В приложении не должно быть отладочных библиотек
- Не использовать setAllowUniversalAccessFromFileURL() в WebView для доступа к локальному контенту. Вместо него нужно использовать WebViewAssetLoader. На Android 6.0 и выше, вместо этого нужно использовать HTML message channels.
- Приложение не должно динамически загружать код (dex файлы) из внешних источников. Нужно использовать App Bundles.
- Приложение должно использовать лучшие криптографические алгоритмы и генераторы случайных чисел из доступных на платформе, а не реализовывать свои алгоритмы шифрования.

https://developer.android.com/docs/quality-guidelines/core-app-quality#sc

Я часто говорю про аутентификацию по pin-коду, но еще чаще я слышу вопросы на эту тему. При кажущейся простоте, тема весьма глубокая и неоднозначная. В четверг (18.02.2021) поговорим на эту тему максимально подробно и разберемся, какие есть проблемы у локальной аутентификации по короткому коду. Кроме очевидной теории, конечно же пощупаем это на практике! Взломаем pin-код реального приложения в прямом эфире и поговорим как улучшить текущую реализацию локально и с применением сервера.

https://youtu.be/Tpsau_jQK1U

⚡️ Вышла Developer Preview новой версии Android. По безопасности пока не густо, надеюсь еще что-нибудь подвезут к релизу. Пока имеем:

- Всем не системным приложениям запретят получение MAC адреса
- В некоторых случаях, система будет блокировать тач ивенты при перекрытиях одних приложений другими
- Приложениям запретят закрывать системные диалоги

Все подробности тут: https://developer.android.com/about/versions/12/behavior-changes-all#privacy

Еще одно важное изменение, которое ждет нас в Android 12 - явное указание экспорта для компонентов приложения. Проблема довольно известная - указанный <intent-filter> приводит к неявному экспорту компонента. Теперь Google призывает принимать решение в каждом таком случае отдельно. Станет чуть больше кода, но в остальном - явное всегда лучше неявного. А еще они обещают валить приложение с ошибкой при установке, если экспорты не будут прописаны явно 🤞 Прямо как Apple какой-то...

https://medium.com/androiddevelopers/lets-be-explicit-about-our-intent-filters-c5dbe2dbdce0

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

https://youtu.be/2DLP2te7gYQ

Записали подкаст с Сергеем Тошиным. По его словам, а также по версии Google Play Security Rewards — Сергей является хакером #1 😎. В выпуске обсуждаем путь на вершины bug bounty, часто встречающиеся баги и авторский проект для поиска таких багов — Oversecured сканер.

Послушать выпуск можно в Google/Apple подкастах и на Youtube:
🎥 YouTube: https://youtu.be/wvSnM8YFcVM
🎙 Google Podcasts: http://bit.ly/2PVXGh5
🍏 Apple Podcasts: http://apple.co/3eDKkAB

Мы с вами обычно собираемся поговорить по какой-то конкретной теме. И обычно это +- обстоятельные встречи в виде стрима на YouTube или подкаста. Хочется попробовать наладить более неформальное взаимодействие и собраться потрындеть в свободной форме. В итоге все равно наверное скатимся в обсуждение того, как захекать очередное приложение или чем ProGuard лучше DexProtector-а. Но наверное это тоже неплохо. Если готовы прийти пообщаться, то вот вам ссылки:
🎙 Для спикеров: https://news.1rj.ru/str/android_guards?voicechat=17fbc64e067f6e0986
🎧 Для слушателей: https://news.1rj.ru/str/android_guards?voicechat

Собираемся в эту субботу (20.03.2021) в 20:00 по MSK.

Приближается Google I/O, где нам расскажут много нового и интересного про безопасность в Android (или нет). На текущий момент есть предварительный анонс нового раздела в Google Play — Safety section. Эта штука позволит пользователям лучше понимать какие данные приложение собирает и какие механизмы безопасности для защиты этих данных задействует.

Если кто-то подумал, что это будет какая-то добрая магия и вам ничего не нужно будет делать, то у меня для вас плохие новости: все вносится руками. Google просто добавит соответсвующие поля в настройки приложения. Сейчас известно про такие настройки:

- Используемые практики по обеспечению безопасности, например шифрование
- Следует ли приложение Families policy (если вы пишите приложения для детей)
- Описание данных, которые приложение собирает и зачем оно их куда-то передает
- Проходило ли приложение внешний аудит
- Есть ли в приложении возможность запросить полное удаление данных при деинсталляции

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

Обязать разработчиков заполнять эти данные обещают со второго квартала 2022 года.

https://android-developers.googleblog.com/2021/05/new-safety-section-in-google-play-will.html

Ребята с дружественного канала @mobile_appsec_world будут проводить вебинар по динамическому анализу мобильных и web приложений. При этом обещают не утомивший всех “разнотык” и прочие “кавычки”, а прямо автоматизацию этого процесса.

Сей дивный праздник состоится 25го мая с 15:00 до 17:00 по МСК. Но в Москве, как известно, тяжело жить без регистрации, поэтому вот вам ссылка где эту регистрацию можно получить 😎

Давненько ничего не выкладывал на YouTube и на то были причины. Но о них как-нибудь потом. По ссылке найдете лекцию по основам информационной безопасности, которую я читал в рамках "Робопрактики", которую компания red_mad_robot каждый год проводит для мобильных разработчиков. В лекции можно найти:

- Основные понятия из мира ИБ
- Моделирование злоумышленников и угроз
- Основы криптографии (симметричная, асимметричная, цифовые подписи, сертификаты, хэш-функции, KDF-функции)
- HTTP vs HTTPS, MITM и SSL Pinning
- Основные угрозы мобильных приложений

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

https://youtu.be/oZEFUA-unDo

Давно не создавал ключи подписи для приложений, а когда попытался, то напоролся на интересную ошибку про невозможность создания ключа с разными паролями на хранилище и на сам ключ. Покопавшись в интернетах быстро выяснил, что это известная проблема с Android Studio 4.2 и в качестве эльфийского костыля предлагается... сделать пароль на хранилище и на ключ одинаковыми. "Отличный совет", который полностью противоречит официальной документации. Более глубокие раскопки показали, что студия версии 4.2 работает на JDK 11, в которой для keystore по умолчанию используется формат PKCS12. Соответственно keytool и пытается создать именно его. Если попробовать сделать это из терминала, то можно увидеть вот такое сообщение: Warning: Different store and key passwords not supported for PKCS12 KeyStores. Ignoring user-specified -keypass value.

Ок, но как же так... Оказалось, что "проблема" известна аж с 2013го года и все работает как ожидается. Потому что (цитирую): Файл pkcs12 с различными паролями на хранилище и на ключ является (почти) бесполезным, потому что другие тулы (MSIE, Firefox и т.д.) принимают такие файлы только с одинаковыми паролями на ключ и хранилище. Поэтому keytool работает таким образом.

Собственно почему мы на это все попали только сейчас? Все просто. Google продолжает держать уверенный курс по направлению "подальше от Oracle" и всячески выпиливает всякие проприетарные штуки из Android окружения. А формат JKS как раз является проприетарным.

Сконвертировать свои старые JKS ключи в модный, молодежный PKCS12 можно так:
keytool -importkeystore \
-srckeystore keystore.jks \
-destkeystore keystore.p12 \
-srcstoretype JKS \
-deststoretype PKCS12 \
-deststorepass password \
-srcalias alias \
-destalias alias

Произошло целых два события: отгремела Google I/O 2021 и у меня нашлось время собрать всякую интересную инфу по privacy & security фишкам, которые там показали. Обзор получился довольно объемный, поэтому в описании вас традиционно ждут таймкоды и куча тематических ссылок. Смотрите, комментируйте, задавайте вопросы. Там есть что обсудить!
https://youtu.be/2Mtdo84dI4M