RCE в Android-приложениях через сторонние сервисы

Совсем недавно компания MWR опубликовала интересную запись "WebView addJavascriptInterface Remote Code Execution" в своем блоге. Запись касается безопасности мобильных приложений. Не хочется полностью пересказывать исследование наших английских коллег — советуем обратиться к первоисточнику. Но если коротко, то при использовании сторонней библиотеки в своем мобильном приложении под Android можно легко поймать RCE (remote code execution) атаку. Произвольное выполнение кода в Android-приложении возможно благодаря рефлексии Java-объекта, который вставляется в WebView.

Итак, для того чтобы данный вектор работал:

1) Во-первых, код должен быть собран с помощью SDK старше 17 версии.
2) Во-вторых, в приложении должно быть разрешено выполнение JavaScript-кода. То есть должен присутствовать метод setJavaScriptEnabled() с параметром true – по умолчанию он отключен.
3) В-третьих, должна использоваться функция addJavascriptInterface().
4) В-четвертых, при получении данных с сервера должен отсутствовать или некорректно использоваться HTTPS.

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

В российских приложениях для мобильного банкинга под Android мы видели взаимодействие с большим количеством сторонних сервисов, что повышает риск компрометации приложения при неправильном использовании. Очень часто встречается взаимодействие с новостным сервером банка, и очень часто это взаимодействие идет по HTTP. Все это значительно расширяет область атаки (attack surface) на банковское приложение.

Атака:

1) Производим MitM.
2) Инъектим в трафик вредоносный JavaScript-код, который вызывает метод Java-объекта getClass(). Например:

JavaObject.getClass().forname(“java.lang.Runtime”).getMethod(“getRuntime”, , null).invoke(null,null).exec([“/system/bin/sh”,”rm”,”-rf”,”*”]) 

Можно представить вариант атаки и без MitM: например, через взлом сайта и вставку своего JavaScript-кода или через хранимую XSS на сайте. В общем, возможно и такое развитие ситуации.

А тем временем Joshua J. Drake, один из самых активных контрибьюторов Metasploit, уже написал специально под это дело модуль add_js_interface_mitm. Модуль пока не доступен и проходит бета-тестирование. На картинке – успешная атака на Fruit Ninja, использующую уязвимый MoPub.

Возможные последствия для пользователя:

1) Полная компрометация данных уязвимого приложения. Если устройство не рутовано, то наш код будет выполняться в рамках sandbox уязвимого Android-приложения, то есть делать все, что может делать это приложение.
2) Полная компрометация мобильного устройства (всех данных на телефоне). Если устройство рутовано или имеет уязвимую версию Android, то наш код может провести LPE (Local Privilege Escalation) атаку и уже работать от пользователя root. Делаем на устройстве все что хотим.

Fix:

1) Отказаться от вызова Java-объекта из JavaScript, если в этом нет необходимости.
2) Использовать SDK младше 17 версии – для этого необходимо добавить аннотацию @JavaScriptInterface, так как все методы Java-объекта, начиная с версии 17, по умолчанию недоступны.
3) Вместо addJavaScriptInterface использовать другой способ вызова Java-методов через создание своей URI-схемы и использование метода shouldOverrideUrlLoading. При этом следует применить валидацию входящих данных и кодирование исходящих данных для предотвращения инъекции.

Backdoor:

Также все это можно с успехом использовать для обхода премодерации приложений в Google Play. В общем, красиво оставлять backdoor в своем приложении =)