Многие из вас используют 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

Мне тут коллеги с соседнего предприятия рассказали историю о том, что им пришло приложение от не самой распоследней конторы на аудит. И первым, что бросилось в глаза, было наличие релизного ключа в каталоге с проектом и заботливо прописанных креденшелов к нему в build-файле. Скажу очевидную мысль: никогда так не делайте 😄 А если узнали свое приложение, то поменяйте пароли на ключ и будьте счастливы.

А надо делать? Не в такой ситуации, а вообще. Вопрос большой и дискуссионный, но я бы посоветовал рассмотреть такие варианты:

- Назначить "хозяина ключей". Это может быть тим/техлид, который в нужное время будет спускаться с небес и подписывать ваше многострадальное приложение
- Убрать все ключи на CI чтобы все подписывалось там.

Я не хочу давать оценку ни одному из этих вариантов. Надеюсь что вы с этим справитесь самостоятельно.

Бывает смотришь на девушку и думаешь — DAST или не DAST... Впрочем о чем это я... А, подкаст новый записали. На этот раз обсуждаем все прелести DAST анализа с ребятами, которые неплохо в этом разбираются. В выпуске присутствует жесткая критика MobSF, поэтому слабонервных прошу поаккуратнее с прослушиванием 😉

Послушать выпуск можно в Google/Apple подкастах и на Youtube:

🎥 YouTube: https://youtu.be/imrlMLVOTRY
🎙 Google Podcasts: https://bit.ly/360XYIi
🍏 Apple Podcasts: https://apple.co/3vWFYte

Вам когда-нибудь было интересно как эволюционировали подходы к обеспечению безопасности в Android? Если да, то вот статья способная хоть немного удовлетворить ваш интерес. Это хороший обзор того, как Google улучшала безопасность и приватность операционной системы начиная с версии 4.4 и до наших дней. Ну и автор — не хрен с горы, а известный в нашем теплом мобильном инфобезе @Mr_R1p. Так что заваривайте свою любимую "принцессу Нури", доширак и наслаждайтесь чтением.

P.S. Статью уже репостили в чат канала, но автор репоста любезно согласился удалить сообщение, чтобы избежать дублирования 😎

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

⚠️ Осторожно, все что вы прочитаете дальше в этом сообщении — теория заговоров и так не бывает.

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