Вся информация предоставлена исключительно в ознакомительных целях. Я не несу ответственности за любой возможный вред, причиненный материалами этой статьи.
Брутфорсинг здесь работать не будет, так как у нас всего 3 попытки ввести номер телефона. Пытался выполнять все возможные get и post запросы, но все время происходил редирект на https://vk.com/login.php?act=security_check.
Можно было бы выполнить 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, на мое удивление, эта ссылка открылась:
Попытался запостить себе ссылку на стенку и получил сообщение.
Поздравляем! Ссылка появится на Вашей странице.
Сначала не поверил, подумал, что security_check заблокировал всё, но зашел на стенку и увидел, что ссылка успешно запостилась )
На стену можно расшаривать не только ссылки, а и обычный пост, для этого нужно оставить параметр url пустым https://vk.com/share.php?url=.
Также, если мы владелец или администратор сообщества, мы можем запостить на стену сообщества запись в обход ввода номера телефона.
Друзьям мы не можем отправить сообщение, так как 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 года!
Ещё один репорт, который висит уже 1 год:
Эта статья создана только для того, чтобы привлечь внимание разработчиков Вконтакте, надеюсь, они исправят данную уязвимость, увеличат штат безопасников и начнут оперативно устранять уязвимости.
Выводы: Цель фишеров — спамить, она остается выполнимой, аутентификацию можно забайпасить.
P.S: В процессе обхода аутентификации обнаружил уязвимость, которая позволяет подписаться на любую групу vk, не зная номера телефона жертвы, и ещё одну, с помощью которой можно полностью обойти ввод номера, но пока об этом не написал репорт.
P.P.S: Об импакте уязвимости:
1. Эта уязвимость может использоваться при массовых фишинговых атаках на пользователей (сейчас набирает популярность создание фейков ВК и распространение их через личные сообщения, а также соц инженерия, применимая на друзьях взломанных аккаунтов), часто фишеры при получении логов сталкиваются с проблемой входа в аккаунт и дальнейшего распространения url фишингового сайта (получают только email;password), с этой уязвимостью они могут получать намного больше логов за счет того, что делятся своей ссылкой на стене и в группе жертвы.
2. Чтобы заблокировать или заморозить страницу пользователя — нужно поделится запрещенной ссылкой у себя на стене и аккаунт сразу заблокируют.
Группа VK и мой твиттер внизу. Буду очень рад подписке :)
Рекомендую прочитать мою предыдущую статью «Iframe injection и self xss на более чем 20 000 сайтах alexarank UA/RU».
Комментарии (12)
foxyrus
27.01.2017 14:44Чтобы заблокировать или заморозить страницу пользователя — нужно поделится запрещенной ссылкой у себя на стене и аккаунт сразу заблокируют
Могут еще двушечку дать :(pudovMaxim
27.01.2017 19:37Чтобы заблокировать или заморозить
страницупользователя — нужно....
Интересно, а как доказать что ты не верблюд.
iwonz
27.01.2017 17:15+1Эх, бро! Я сталкивался с этим!
https://tjournal.ru/28415-novaya-uyazvimost-vkontakte-snova-pozvolyaet-deanonimizirovat-administratorov-soobshestv
Vogr
27.01.2017 19:20Вся информация предоставлена исключительно в ознакомительных целях. Я не несу ответственности за любой возможный вред, причиненный материалами этой статьи.
Через мобильную версию сайта можут получиться баги намного серьезнее( в смысле подобный баг может дать больше простора, ибо м.версия очень отстают от десктопа).
srbgd
27.01.2017 20:15+1Чем объясняется желание админов оставлять уязвимости открытыми? Однажды на одном популярном сайте нашёл уязвимость, которая позволяла обходить капчу. Написал про неё админу. Не хотел просто так отдавать, но админ предложил только «фантики» этого сайта. Тогда я решил сделать спам-бота. Никак не получалось спамить во много потоков т.к. сайт был под cloudflare. Спустя неделю после моего письма админу эту уязвимость нашли и прикрыли. Я уже забыл про этот случай, но недавно копался в доках к api и нашёл старую капчу, которая удивительно легко поддавалась брутфорсу. Всего 6 вариантов ответа перебирались меньше секунды. Посчитал это уязвимостью, отчитался админу и взял «фантиков» на 300 рублей. Прошло чуть больше недели. Уязвимость не прикрыта.
worldxaker
27.01.2017 20:17+1зато косяк с интерфейсом они попровили на следующий же день после обращения
Deus0x58
27.01.2017 22:19+1И ведь подобная история далеко не первая, у кого-то еще остается желание участвовать в их bugbounty-программе?
alexeyknyshev
29.01.2017 10:44+1Не касательно багов, а в целом про отношение поддержки и их реакции на репорты пользователей. Например, к моему товарищу постоянно кидают инвайты распространители наркоты (фамилия и имя на А, поэтому есть подозрение, что он первый в списке перебора ботами или что-то вроде того). Паттерн поведения у них очень простой, страница взломанного аккаунта изобилует прочей рекламой, а на аватарке написан id канала в телеграме, куда обращаться за искомым товаром. Поддержка говорит: «Ничего не можем с этим поделать, помечайте такие записи как спам». Походу простой статистический и fraud анализ у них отсутствует как класс, не говорю уже про всякие NN и Deep Learning.
sotnikdv
29.01.2017 12:31+1Похожая ситуация была с LinkedIn, после того, как я сообщил о проблеме (возможность угона аккаунта, более того, несколько раз видел проявления на аккаунтах знакомых) и получил ответ «это не баг, это такая фича».
Хватило одного вопроса «Ну тогда я публикую пошаговый мануал для воспроизведения со ссылкой на Вас и цитатой официального ответа? Ну т.е. я вам отрепортил, вы одобрили, что это не баг, а стандартный функционал.» После этого запрос был эскалирован до главы подразделения и бага была закрыта за несколько дней.
Я к чему, ИМХО имеет смысл следовать следующим правилам:
1. Всегда репортим уязвимость, независимо от того есть вознаграждение или нет.
2. Если саппорт, сказал, что это не баг, ласково спрашиваем, «ну я тогда публикую полную инструкцию со ссылкой на вас, т.е. вы проревьюили и решили, что это не уязвимость». И если не передумали — публикуем.
3. Если саппорт сказал, что это баг, немедленно публикуем статью о проблеме и как ее избежать, но без деталей для эксплуатации.
4. Если за 6 месяцев нет движения или сразу после фикса — публикуем полные детали. Я бы еще после фикса уточнял, можно ли публиковать или у них есть что-то недофикшенное и когда планируют закончить (так и сделал)
P.S. Bug Bounty у LinkedIn нет, да я и не ради вознаграждения тратил свое время. Несколько покоробил факт, что после этого (а может совпало) мне начали сыпаться предложения оплатить премиум.
Labunsky
Они, судя по всему, не особо волнуются по поводу некоторых уязвимостей.
Один мой реквест пролежал у них на h1 год с лишком. Я уже и сам забыл о нем. Как-то наткнулся потом, написал. После напоминаний даже ответили, чем-то вроде: «Вот это мы не считаем уязвимостью, а вот об этом мы и без вас знаем, как-нибудь может пофиксим». Пометили «Informative» и закрыли. Сейчас проверил — так и не пофиксили :(
w9w
Понимаю, не уязвимость, а фича, но пофиксить её необходимо. О ней известно уже 2 года.