Меня зовут Юрий Леонычев. Я работаю в службе информационной безопасности Яндекса, где разрабатываю интересные сервисы, комбинирующие методы машинного обучения с анализом BigData. Как вы знаете, у Яндекса большое количество мобильных приложений. И если безопасностью наших веб-приложений мы занимаемся уже давно, то мобильным часто уделялось недостаточно внимания. Частично это было связано с тем, что мобильные приложения считались продолжением своих «больших» братьев, надстройками над WEB API.
Но с появлением мобильных платформ iOS и Android ситуация кардинально изменилась. Количество разрабатываемых нами приложений росло, сложность их возрастала, а некоторые из приложений стали отдельными крупными самостоятельными проектами. Кроме того, мы звпустили Яндекс.Store, где нам надо было проверять безопасность уже сторонних приложений.
Отсутствие уязвимостей как в приложениях Яндекса, так и в сторонних мы научились обеспечивать разными сопособами, в том числе и применив машинное обучение. О том, как у нас устроена работа в этом месте я и расскажу. Начну с того, как мы проверяем свои собственные приложения.
Ошибки нужно не только искать. Очень важно сделать так, чтобы они в приложениях не появлялись. Мы решили использовать уже известную методику от компании Microsoft — Secure Development Lifecycle (SDLC). Конечно, нам хотелось бы, чтобы все, что предлагает SDLC, мы внедрили и использовали сразу, но это слишком сложно. Все контроли SDLC — это скорее идеальный конечный результат.
Безопасность мобильных приложений в Яндексе имеет несколько важных особенностей. Мы активно разрабатываем множество своих мобильных приложений под разные платформы (iOS, Android, Windows Mobile). Очевидно, что проверять все приложения под все платформы силой команды продуктовой безопасности Яндекса было бы очень сложно. Поэтому мы стараемся руководствоваться принципом «Разделяй и властвуй». Для этого мы постоянно взаимодействуем с ключевыми разработчиками мобильных приложений, стараемся повышать их осведомленность о проблемах, связанных с безопасностью. Например, в прошлом году мы проводили специальные тренинги, на которых специалисты по безопасности мобильных приложений из компании IOActive показывали практические приемы взлома и анализа кода. Наши разработчики смогли на практике увидеть, как будут атаковать их приложение и как можно от многих видов атак защититься. Обычно разработчики сами обращаются к нам во всех случаях, когда новые функции или изменения в приложениях влияют на безопасность.
В большинстве мобильных приложений Яндекса используются общие компоненты и библиотеки. Эти части кода мы проверяем регулярно, так как одна исправленная ошибка в общих библиотеках повлияет на все новые версии приложений. Например, в наших приложениях находили уязвимость, связанную с открытым для всех на чтение контент-провайдером, в котором была найдена SQL-injection. Хотя сообщали о ней разные исследователи и писали они про разные приложения, но сама ошибка была на самом деле в одной общей библиотеке, поэтому исправить её было несложно.
Самые популярные мобильные приложения проходят регулярный статический анализ кода, который запускается как один из шагов сборки приложения. Мы используем статический анализатор кода от компании Coverity. Наша версия анализатора немного доработана: в неё внесены дополнительные проверки для поиска специфических для Android уязвимостей. При каждом коммите кода разработчики получают подробный отчет о найденных ошибках и степени их критичности. В данном случае статический анализ работает эффективно, так как кодовая база мобильных приложений не слишком велика и разработчики успевают исправить все найденные ошибки. При этом разработчик может сразу же увидеть свои ошибки — до того момента, когда приложение будет опубликовано. Кроме того, статический анализ кода позволяет в полуавтоматическом режиме находить ошибки, которые руками найти довольно тяжело. Для ручных проверок мы также предпочитаем использовать статический анализ, так как в нашем случае проще всего проверять исходный код приложений.
Многие наши мобильные приложения взаимодействуют с бэкендами на серверах Яндекса. Такие приложения проходят двухэтапную проверку. Мы смотрим на мобильную и серверную часть. Проверяются все API-вызовы, которые делает приложение, так как чаще всего API работают по протоколам HTTP/HTTPS, то тут возможно появление обычных уязвимостей из OWASP Top 10.
Важное отличие подхода к обеспечению безопасности наших мобильных приложений — то, что мы стараемся использовать краудфаундинг при поиске уязвимостей. Мы первыми из российских компаний запустили полноценную программу поощрения за найденные уязвимости и сразу же включили в неё мобильные приложения. За время проведения «Охоты за ошибками» около 10% сообщений были об ошибках в наших мобильных приложениях. Часть из них были очень интересными. Например, один из участников нашей «Охоты» будет рассказывать про уязвимости, найденные в Я.Браузере под iOS на конференции HITB в Амстердаме. Мы к таким найденным ошибкам относимся позитивно, так как они показывают нам потенциально слабые места в коде, на которые стоит обращать пристальное внимание. А пересматривая старый legacy код, разработчики приложений часто исправляют другие проблемы.
Все новые приложения обязательно проверяются перед запуском нашей командой продуктовой безопасности. Причем проверяется не только соответствие рекомендациям по безопасной разработке под соответствующую платформу, но и наличие скрытых алгоритмических ошибок. Мы стараемся не просто исправлять ошибки, но и объяснять разработчикам, почему они появились. Для поиска некоторых уязвимостей были написаны специальные программы, которые позволяют наглядно продемонстрировать наличие дефектов.
Безопасность сторонних мобильных приложений
Когда мы проектировали свой магазин мобильных приложений под Android, возникло опасение, связанное с тем, что нам будут загружать в магазин сторонние разработчики. Сразу же закрутить гайки мы не могли, потому что отпугнули бы всех разработчиков, а нам нужно было наполнить магазин. Просить у всех на старте документально подтвердить личность было бы не самой хорошей идеей. С другой стороны, если совсем не контролировать ситуацию, то мы получили бы огромное хранилище вредоносных программ, в котором пользователи с опаской бы искали что-то полезное. Поэтому мы решили сразу же встроить антивирусные проверки в магазин, после чего провели несколько исследований.
У нас было большое количество сэмплов вредоносных программ, которые в то время активно распространялись среди пользователей Android. Мы выбрали некоторое количество антивирусных движков и проверили их эффективность на тестовых наборах. Самые хорошие результаты тогда показал антивирус Касперского, но даже они нас не удовлетворили, поэтому пришлось придумать своё решение.
Модель безопасности для платформы Android
Операционная система Android изначально содержала в себе множество механизмов для защиты информации и ограничения доступа к ресурсам мобильного устройства. Так как Android базируется на ядре Linux, то механизмы разграничения доступа к ресурсам процессов, принадлежащих разным пользователям, были унаследованы новой операционной системой. Но из-за того, что Android был предназначен для мобильных устройств и приложения должны были исполняться в специальной виртуальной машине Dalvik, в нём появились дополнительные уровни абстракций и защиты. Устройство Android можно посмотреть на классической диаграмме.
"
Для Android характерны строго выставленные разрешения для файловой системы, запуск пользовательских приложений в отдельных процессах в своеобразных «песочницах».
Привилегии
Важно, что для доступа к большей части ресурсов нужно запросить специальное разрешение в манифесте приложения. При этом при установке приложений пользователя предупреждают, какие возможности будут у приложения, к каким пользовательским данным оно получит доступ. Например, приложение с разрешениями READ_SMS и INTERNET вполне может передавать одноразовые пароли, попадающие в смартфон пользователя, постороннему лицу. Несмотря на изменившийся для повышения информативности экран, который показывает запрошенные разрешения при установке, и другие ухищрения разработчиков Android, большая часть пользователей мало внимания обращает на то, что же они решили запустить внутри своего устройства. Первое время, когда документация по платформе была довольно скудной, многие разработчики также не понимали, какие разрешения нужны им для определенных действий. Поэтому они нарушали принцип наименьших доступных привилегий и ставили в манифесте разрешения по максимуму. Это привело к тому, что пользователи стали воспринимать огромные наборы разрешений, как норму.
Распространенные вредоносные приложения
Как и всякая стремительно захватывающая потребительский рынок операционная система, Android привлек к себе внимание различных злоумышленников. Дополнительным источником интереса стало то, что в настоящее время мобильное устройство — это не только ценный источник персональных данных, но и фактически легкодоступный кошелек.
Уже в 2010 году появились сообщения антивирусных компаний о первых заражениях мобильных устройств вредоносными приложениями, отправляющими SMS на короткие платные номера (примеры раз и два). Функциональность таких приложений была очень простой. Они уже при установке просили право на отправку SMS, что и делали при первом запуске. В тех приложениях не редки были ошибки, из-за которых SMS вовсе могли не отправляться или уходить не на те номера. За четыре года вредоносные приложения существенно эволюционировали, но большую часть из них до сих пор составляют простейшие программы, нацеленные на быстрое получение прибыли. По данным ЛК, за 2013 год 36% троянов под Android отправляли платные SMS-сообщения. Новые успешные вредоносные приложения копируются много раз, поэтому трояны для Android не слишком разнообразны.
Методы обнаружения: статические и динамические
Для успешного обнаружения вредоносных приложений комбинируются различные методики: используются сигнатуры, эвристики, эмуляция приложений. Но рост количества таких программ привел к тому, что потребовались методики для автоматизированного выполнения задач, которые зачастую приходится делать антивирусным аналитикам. Для Android некоторые методы сразу не были достаточно эффективны. Эмуляция приложений была затруднена огромной фрагментированностью платформы, не слишком стабильной работой эмулятора и простыми методами его детектирования. Многими исследователями предлагалось использовать методы машинного обучения для того, чтобы находить вредоносные программы. Мы также решили пойти по этому пути и вместе с Yandex.Store год назад был запущен классификатор загружаемых программ, использующий наши алгоритмы машинного обучения (презентация на YaC’13).
Построение классификатора
Выбор факторов классификации
Для того чтобы выбрать правильные факторы классификации, было использовано два подхода. Первый — это анализ уже существующих вредоносных мобильных приложений. Он выполнялся руками и позволил увидеть некоторые особенности. Например, вредоносные приложения (на момент проведения аналитических работ) были лидерами по использованию методов обфускации. Сейчас этот признак уже не так актуален, так как разработчики популярных приложений включают хотя бы ProGuard во время сборки. Другой важный фактор — это использование разрешений. Он не потерял свой актуальности со временем, так как простые вредоносные приложения до сих пор предпочитают просить разрешения на отправку SMS.
Второй подход при создании набора факторов был ещё более тривиальным. Было потрачено определенное время на поиск уже используемых факторов классификации в научных статьях. Больших результатов это не дало, но позволило включить фантазию и придумать множество самых безумных фактов, которые можно было посчитать, глядя на входной файл. Конечно, не совсем понятно было, какой «выхлоп» будет от такого фактора, как размер входного файла или количество URL в переменных и ресурсах, но на первом этапе хотелось использовать все возможности.
Оценка эффективности детектирования и скорости работы
После нескольких обучений классификатора Матрикснет позволил выкинуть множество неэффективных на данный момент факторов. Это не значит, что мы про них совсем забыли. Со времени запуска некоторые факторы теряли актуальность, а некоторые снова становились эффективными. Например, размер файла, который изначально не давал особого вклада в детектирование, получил со временем определенный вес, так как размер файлов для многих игр существенно увеличился. Некоторые факторы можно было использовать только после определенного времени работы анализатора. Для разработчиков был посчитан уровень доверия к ним на основе всех приложений, которые были ими загружены в наш магазин. Конечно, в момент старта Yandex.Store сделать такие расчеты было невозможно, так как у большинства разработчиков было не слишком много разных приложений, чаще всего одной версии.
Эволюция факторов и переобучение системы
Изменение процессов сборки приложений, возникновение новых видов вредоносных программ и не только это заставляют постоянно переобучать анализатор. Это в данном случае нормальный процесс, который повторяется каждый раз после начала деградации результатов детектирования. Во многих спорных случаях, когда приложение детектируется как вредоносное, но это не подтверждается другими методами, мы добавляем приложение к обучающей выборке. Сейчас переобучение системы может производиться полуавтоматически. Когда проводилось первое обучение, размеры выборок были около 250 файлов. Сейчас они уже перевалили за тысячу.
Будущее системы
Поддержка новых механизмов исполняемых файлов
Платформа Android очень динамично развивается. За прошедшие два года появился ART, изменились некоторые разрешения, поменялись сами устройства. Соответственно дорабатывать анализатор приложений нужно постоянно. Сейчас есть идеи по развитию проекта в двух направлениях: первое — повышение качества статического анализа за счет усиления проверок нативного кода; второе — внедрение динамического анализа для проверки приложений.
Изменения факторов
Улучшение статического анализа за счет проверок нативного кода необходимо, так как разработчики вредоносных приложений стали более активно использовать JNI. Сейчас уже можно писать полноценные Android-приложения на C++ без особых проблем.
Также назрела необходимость большого рефакторинга и оптимизации кода, так как нам хочется ещё больше сократить время проверки файлов и увеличить производительность анализатора. Впрочем это уже скорее задачи на недалекое будущее.
" 
