Меня зовут Юрий Леоничев.
Я работаю в службе информационной безопасности Яндекса, где разрабатываю интересные сервисы, сочетающие методы машинного обучения с анализом BigData. Как вы знаете, у Яндекса большое количество мобильных приложений.
И хотя мы уже давно работаем над безопасностью наших веб-приложений, мобильным приложениям зачастую уделяется недостаточно внимания.
Частично это было связано с тем, что мобильные приложения считались продолжением своих «больших» братьев, надстройками над WEB API. 
Но с появлением мобильных платформ iOS и Android ситуация кардинально изменилась.
Количество разрабатываемых нами приложений росло, увеличивалась их сложность, а некоторые приложения стали отдельными крупными самостоятельными проектами.
Кроме того, мы запустили Яндекс.
Магазин, где нам нужно было обеспечить безопасность сторонних приложений.
Мы научились обеспечивать отсутствие уязвимостей как в приложениях Яндекса, так и в сторонних различными способами, в том числе с помощью машинного обучения.
Расскажу о том, как мы работаем в этом месте.
Начнем с того, как мы тестируем наши собственные приложения.
Не нужно просто искать ошибки.
Очень важно следить за тем, чтобы они не появлялись в приложениях.
Мы решили использовать уже известную методологию от Microsoft — Secure Development Lifecycle ( СДЛ ).
Конечно, хотелось бы сразу реализовать и использовать все, что предлагает SDL, но это слишком сложно.
Все элементы управления SDL представляют собой скорее идеальный конечный результат. Безопасность мобильных приложений в Яндексе имеет несколько важных особенностей.
Мы активно разрабатываем множество наших мобильных приложений для разных платформ (iOS, Android, Windows Phone).
Очевидно, что проверить все приложения для всех платформ с помощью команды безопасности продуктов Яндекса будет очень сложно.
Поэтому мы стараемся руководствоваться принципом «Разделяй и властвуй».
Для достижения этой цели мы постоянно взаимодействуем с ключевыми разработчиками мобильных приложений и стараемся повысить их осведомленность о вопросах безопасности.
Например, в прошлом году мы проводили специальные тренинги, на которых специалисты по безопасности мобильных приложений компании IOАктивный показали практические приемы взлома и анализа кода.
Наши разработчики смогли на практике увидеть, как их приложение будет атаковано и как они смогут защититься от многих типов атак.
Обычно сами разработчики обращаются к нам во всех случаях, когда новые функции или изменения в приложениях влияют на безопасность.
Большинство мобильных приложений Яндекса используют общие компоненты и библиотеки.
Мы регулярно проверяем эти части кода, так как одна исправленная ошибка в общих библиотеках затронет все новые версии приложений.
Например, в наших приложениях была обнаружена уязвимость, связанная с поставщиком открытого для всех контента, в котором она была найдена.
Хотя об этом сообщали разные исследователи и писали о разных приложениях, сама ошибка фактически находилась в одной общей библиотеке, поэтому исправить ее не составило труда.
Наиболее популярные мобильные приложения регулярно подвергаются статическому анализу кода, который запускается на одном из этапов сборки приложения.
Мы используем статический анализатор кода от Coverity. Наша версия анализатора была немного улучшена: в нее добавлены дополнительные проверки для поиска уязвимостей, специфичных для Android. При каждом коммите кода разработчики получают подробный отчет о найденных ошибках и их серьезности.
В этом случае статический анализ работает эффективно, поскольку кодовая база мобильных приложений не слишком велика и у разработчиков есть время исправить все найденные ошибки.
При этом разработчик может сразу увидеть свои ошибки — до момента публикации приложения.
Кроме того, статический анализ кода позволяет в полуавтоматическом режиме находить ошибки, которые довольно сложно найти вручную.
Для ручных проверок мы также предпочитаем использовать статический анализ, так как в нашем случае проще всего проверить исходный код приложений.
Многие наши мобильные приложения взаимодействуют с бэкендами на серверах Яндекса.
Такие заявки проходят двухэтапную проверку.
Мы рассматриваем мобильную и серверную часть.
Проверяются все API-вызовы, которые делает приложение, поскольку чаще всего API работают по протоколам HTTP/HTTPS, возможно, что обычные уязвимости от Топ-10 OWASP .
Важным отличием подхода к обеспечению безопасности наших мобильных приложений является то, что при поиске уязвимостей мы стараемся использовать краудфандинг.
Мы были первой российской компанией, запустившей полноценный программа стимулирования за найденные уязвимости и тут же включил в него мобильные приложения.
Во время Bug Hunt около 10% сообщений касались ошибок в наших мобильных приложениях.
Некоторые из них были очень интересными.
Например, один из участников нашей «Охоты» рассказал об уязвимостях, найденных в Y. Browser для iOS на конференции HITB в Амстердаме.
Мы положительно относимся к таким найденным ошибкам, поскольку они показывают нам потенциальные слабые места в коде, на которые стоит обратить пристальное внимание.
А пересматривая старый унаследованный код, разработчики приложений часто решают и другие проблемы.
Все новые приложения перед запуском проверяются нашей командой по безопасности продуктов.
При этом проверяется не только соблюдение рекомендаций по безопасной разработке для соответствующей платформы, но и наличие скрытых алгоритмических ошибок.
Мы стараемся не только исправлять ошибки, но и объяснять разработчикам, почему они появились.
Для поиска некоторых уязвимостей написаны специальные программы, позволяющие наглядно продемонстрировать наличие дефектов.
Безопасность сторонних мобильных приложений
Когда мы проектировали магазин мобильных приложений для Android, были опасения, что сторонние разработчики будут загружать их в магазин.Сразу закрутить гайки мы не смогли, потому что это отпугнуло бы всех разработчиков, а нам нужно было наполнить магазин.
Просить всех в начале документально подтвердить свою личность — не лучшая идея.
С другой стороны, если бы мы вообще не контролировали ситуацию, мы бы получили огромное хранилище вредоносного ПО, в котором пользователи опасались бы искать что-то полезное.
Поэтому мы решили сразу встроить в магазин антивирусную проверку, после чего провели несколько исследований.
У нас было большое количество образцов вредоносного ПО, которые в то время активно распространялись среди пользователей Android. Мы выбрали несколько антивирусных движков и проверили их эффективность на тестовых наборах.
Антивирус Касперского тогда показал лучшие результаты, но даже они нас не удовлетворили, поэтому пришлось придумать собственное решение.
Модель безопасности для платформы Android
Операционная система Android изначально содержала множество механизмов защиты информации и ограничения доступа к ресурсам мобильного устройства.Поскольку Android основан на ядре Linux, механизмы ограничения доступа к ресурсам процессов, принадлежащих разным пользователям, были унаследованы новой операционной системой.
Но из-за того, что Android был разработан для мобильных устройств и приложения приходилось запускать на специальной виртуальной машине.
Далвик , он добавил дополнительные уровни абстракции и защиты.
Android-устройство можно просмотреть на классической схеме.
"
Android отличается строго установленными разрешениями для файловой системы, запуском пользовательских приложений в отдельных процессах в своеобразной «песочнице».
Привилегия
Важно, что для доступа к большинству ресурсов необходимо запрашивать специальное разрешение в манифесте приложения.При этом при установке приложений пользователь предупреждается, какими возможностями будет обладать приложение и к каким пользовательским данным оно будет иметь доступ.
Например, приложение с разрешениями READ_SMS и INTERNET вполне может передавать постороннему лицу одноразовые пароли, которые входят в смартфон пользователя.
Несмотря на измененный в сторону большей информативности экран, на котором отображаются запрошенные разрешения при установке и прочие хитрости Android-разработчиков, большинство пользователей мало обращают внимания на то, что они решили запустить внутри своего устройства.
Поначалу, когда документация по платформе была довольно скудной, многие разработчики также не понимали, какие разрешения им нужны для тех или иных действий.
Поэтому они нарушили принцип наименьших доступных привилегий и установили в манифесте максимальные разрешения.
Это привело к тому, что пользователи приняли огромные наборы разрешений как норму.
Распространенные вредоносные приложения
Как любая операционная система, стремительно захватывающая потребительский рынок, Android привлекла внимание различных злоумышленников.Дополнительным источником интереса стало то, что сегодня мобильное устройство — это не только ценный источник личных данных, но и, по сути, легкодоступный кошелек.
Уже в 2010 году появились сообщения антивирусных компаний о первых заражениях мобильных устройств вредоносными приложениями, отправлявшими СМС на короткие платные номера (примеры один раз И два ).
Функционал таких приложений был очень простым.
При установке уже просили права на отправку СМС, что и сделали при первом запуске.
В этих приложениях часто возникали ошибки, из-за которых СМС вообще не могли быть отправлены или переходили не на те номера.
За последние четыре года вредоносные приложения значительно эволюционировали, но большинство из них по-прежнему представляют собой простые программы, нацеленные на быстрое получение прибыли.
По данным LC, в 2013 году 36% троянов для Android отправляли платные SMS-сообщения.
Новые успешные вредоносные приложения копируются многократно, поэтому Android-трояны не отличаются большим разнообразием.
Методы обнаружения: статические и динамические.
Для успешного обнаружения вредоносных приложений комбинируются различные методы: используются сигнатуры, эвристика и эмуляция приложений.
Но рост количества таких программ привел к необходимости в методах автоматического выполнения задач, которые часто приходится выполнять антивирусным аналитикам.
Для Android некоторые методы сразу оказались недостаточно эффективными.
Моделирование приложений затруднялось огромной фрагментацией платформы, не очень стабильной работой эмулятора и простыми методами его обнаружения.
Многие исследователи предлагают использовать методы машинного обучения для обнаружения вредоносных программ.
Мы тоже решили пойти по этому пути и вместе с Яндекс.
Store год назад запустили классификатор скачиваемых программ с использованием наших алгоритмов машинного обучения ( презентация на ЯЦ'13 ).
Создание классификатора
Выбор факторов классификации
Для выбора правильных классификационных факторов использовались два подхода.Первый — анализ существующих вредоносных мобильных приложений.
Это было сделано вручную и позволило нам увидеть некоторые особенности.
Например, вредоносные приложения (на момент анализа) были лидерами по использованию методов обфускации.
Сейчас эта функция уже не так актуальна, поскольку разработчики популярных приложений включают во время сборки как минимум ProGuard. Еще одним важным фактором является использование разрешений.
С течением времени она не потеряла своей актуальности, поскольку простые вредоносные приложения по-прежнему предпочитают запрашивать разрешение на отправку СМС.
Второй подход к созданию набора факторов был еще более тривиальным.
Некоторое время было потрачено на поиск уже используемых классификационных факторов в научных статьях.
Это не дало особых результатов, но позволило нам использовать воображение и придумать множество самых безумных фактов, которые можно было вычислить, просмотрев входной файл.
Конечно, было не совсем понятно, какой будет «выхлоп» от таких факторов, как размер входного файла или количество URL-адресов в переменных и ресурсах, но на первом этапе хотелось использовать все возможности.
Оценка эффективности обнаружения и скорости работы
После нескольких тренировок классификатора Matrixnet позволил исключить многие на данный момент неэффективные факторы.Это не значит, что мы о них совсем забыли.
С момента запуска некоторые факторы утратили актуальность, а другие вновь стали эффективными.
Например, размер файла, который изначально не имел большого значения для обнаружения, со временем приобрел некоторый вес, поскольку размеры файлов для многих игр значительно увеличились.
Некоторые факторы можно было использовать только после определенного времени работы анализатора.
Для разработчиков уровень доверия к ним рассчитывался на основе всех приложений, которые они загрузили в наш магазин.
Конечно, на момент запуска Яндекс.
Магазина такие расчеты провести было невозможно, так как у большинства разработчиков не было слишком много разных приложений, чаще всего одной и той же версии.
Ээволюция факторов и переобучение системы
Изменения в процессах сборки приложений, появление новых типов вредоносного ПО и многое другое заставляют анализатор постоянно переучиваться.В данном случае это нормальный процесс, который повторяется каждый раз после того, как результаты обнаружения начинают ухудшаться.
Во многих спорных случаях, когда приложение определяется как вредоносное, но это не подтверждается другими методами, мы добавляем приложение в обучающую выборку.
Теперь переобучение системы можно производить в полуавтоматическом режиме.
Когда проводилось первое обучение, размер выборки составлял около 250 файлов.
Сейчас их уже перевалило за тысячу.
Будущее системы
Поддержка новых механизмов исполняемых файлов.
Платформа Android развивается очень динамично.
За последние два года произошло ИСКУССТВО , поменялись некоторые разрешения, поменялись сами устройства.
Соответственно, анализатор приложений нуждается в постоянном усовершенствовании.
Сейчас есть идеи по развитию проекта по двум направлениям: во-первых, повышение качества статического анализа за счет усиления проверок нативного кода; второй — внедрение динамического анализа для проверки приложений.
Изменения факторов
Улучшение статического анализа за счет проверок нативного кода необходимо, поскольку разработчики вредоносных приложений начинают более активно использовать JNI. Теперь вы можете без проблем писать полноценные Android-приложения на C++.Также существует необходимость серьезного рефакторинга и оптимизации кода, так как мы хотим еще больше сократить время проверки файлов и повысить производительность анализатора.
Однако это скорее задачи ближайшего будущего.
Теги: #Машинное обучение #информационная безопасность #Android #Яндекс
-
Вредоносное По… Новая Угроза
19 Oct, 24 -
Защита Конфиденциальности Через Интернет
19 Oct, 24 -
Манул – Любимец Интернета
19 Oct, 24 -
Форматирование Кода Python
19 Oct, 24
