Как закачка JPG-файла может привести к Cross Domain Data Hijacking (атаке со стороны клиента)

Автор: Soroush Dalili

Введение

В этой статье будет рассказано о технике, которая не освящалась в других статьях об атаках, связанных с загрузкой файлов (см. статьи Unrestricted file upload и File in the hole).

Насколько безопасен загрузчик файлов?

Допустим, перед загрузкой файлов происходит проверка расширения, и допускаются к загрузке только безопасные файлы с расширением .jpg, .png, и .txt. Более того, проверяется имя файла на предмет присутствия только буквенно-цифровых символов!

На первый взгляд, кажется, что вышеупомянутый метод прост и эффективен для защиты сервера и пользователей от эксплуатации уязвимостей в файловом процессоре и атак типа file inclusion.

Какие могут быть риски?

У загрузчика отсутствует проверка содержимого файлов, что может привести к загрузке на сервер вредоносного кода с безопасным именем и расширением. Хотя если сервер сконфигурирован правильно, файл нельзя будет запустить. Более того, файл будет отослан клиенту с соответствующим content-type (text/plain или image/jpeg), и злоумышленник не сможет реализовать межсайтовый скриптинг посредством открытия загруженного файла напрямую в браузере.

Изменение content-type при помощи тега OBJECT

Если мы изменим свойство content-type у файла, то сможем реализовать межсайтовый скриптинг, однако в современных реалиях это труднореализуемо.

И тут я вспомнил, что у тега «OBJECT» есть атрибут «TYPE», но не был уверен, какие конкретно значения content-type заставляют браузер загрузить объект, вместо отображения его содержимого (тег «OBJECT» может функционировать как IFrame). Я создал тестовый файл (находящийся по адресу http://0me.me/demo/SOP/ObjectMimeType.html), в котором подгружаются теги с различными значениями mime-type. Результаты показаны ниже (Java и Silverlight установлены не были):

«application/futuresplash»: загружает файл как Flash object

«application/x-shockwave-flash»: загружает файл как Flash object

«text/x-component»: работает только в IE, загружает .htc файлы(?)

«application/pdf» и некоторые другие: загружают файл как PDF object

Результаты могут отличаться в зависимости от установленных плагинов.

Таким образом, я могу закачать вредоносный файл на сервер жертвы под видом .JPG файла, а затем загрузить его как flash-файл на моем собственном вебсайте (но это не имеет особого смысла, поскольку flash-файл с XSS-уязвимостью будет работать только в пределах моего домена).

Схема реализации атаки

Было установлено, что встроенный flash-файл может «общаться» с исходным доменом без проверки cross-domain policy, и в этом есть определенный смысл, поскольку сам файл принадлежит вебсайту жертвы.

В конечном итоге flash-файл закачанный как .JPG файл на вебсайт жертвы может загрузить важные файлы, используя cookies текущего пользователя; затем эту информацию можно отослать в JavaScript (а точнее на вебсайт злоумышленника), который встроен в .JPG файл (который на сам деле представляет собой Flash-файл).

Схему реализации схожа с CSRF-атакой (Сross Site Request Forgery, межсайтовая подделка запроса). Вам нужно отослать вредоносную ссылку пользователю, который уже залогинен на сайте жертвы (даже если пользователь не залогинен, все равно данная атака типа CSRF, но эта тема уже выходит за рамки данной статьи). Вредоносный флеш уже должен быть загружен на вебсайт жертвы. Если загрузчик сам по себе уязвим к CSRF-атакам, злоумышленник может вначале загрузить вредоносный Flash-файл и затем использовать его для кражи конфиденциальной информации, либо осуществить другие CSRF-атаки.

В результате всех этих манипуляций, злоумышленник может собрать ценную информацию (пользовательские данные, CSRF-токены и т. д.).

Далее приводится общая схема реализации атаки:

A) 0me.me = вебсайт злоумышленника

B) sdl.me = вебсайт жертвы

C) JPG файл (который на самом деле Flash-файл) уже загружен на вебсайт жертвы: http://sdl.me/PoCs/CrossDomainDataHijack.jpg

(Исходный код Flash-файла доступен по следующей ссылке: http://0me.me/demo/SOP/CrossDomainDataHijack.as.txt)

D) На сервере жертвы (sdl.me) есть секретный файл, который мы будем считывать при помощи вебсайта злоумышленника (0me.me): http://sdl.me/PoCs/secret.asp?mysecret=original

E) Обратите внимание, что на вебсайте жертвы нет файла crossdomain.xml: http://sdl.me/crossdomain.xml

F) Злоумышленник отсылает следующую вредоносную ссылку пользователю сайта sdl.me: http://0me.me/demo/SOP/CrossDomainDataHijackHelper.html

После нажатия на кнопку «Run» вебсайт 0me.me (сайт злоумышленника) может считать содержимое файла secret.asp, находящегося на вебсайте sdl.me (сайт жертвы).

Обратите внимание: если другой сайт (например, Soroush.me) будет добавлен как достоверный в файл crossdomain.xml, злоумышленник может считывать содержимое и этого сайта.

Ограничения при использовании уязвимости

Злоумышленник не может считывать cookies вебсайта жертвы.

Злоумышленник не может запускать JavaScript напрямую при помощи этой уязвимости.

Дальнейшие исследования

Помимо Flash-файлов при реализации атаки могут использовать другие технологии: PDF, Java-апплеты, и Silverlight.

Можно исследовать способы обхода Flash security sandbox, когда вебсайта использует «Content-Disposition: attachment;» После нахождения способа обхода станут уязвимы многие почтовые сервера и файловые репозитарии.

Рекомендации по защите

Рекомендуется проверять корректность заголовка и формат файла. Если возможно используйте заголовок «Content-Disposition: attachment; filename=Filename.Extension;» для тех файлов, которые не должны обрабатываться в браузере. При этом Flash запротоколирует сообщение о безопасности.

Изолирование домена загруженный файлов – также хорошее решение при условии, что файл crossdomain.xml главного вебсайта не содержит изолированный домен.

Обновление 1 (21 мая 2014 года):

Кажется, @fransrosen and @avlidienbrunn опередили меня. Они опубликовали статью, которая также касается этой проблемы: http://blog.detectify.com/post/86298380233/the-pitfalls-of-allowing-file-uploads-on-your-website

Настоятельно рекомендую читателям ознакомиться с этой статьей и, в особенности, с трюком с JSONP.

Обновление 2 (21 мая 2014 года):

Дополнительные материалы, имеющие отношение к этой проблеме:

http://50.56.33.56/blog/?p=242 (Content-Type Blues)

https://bounty.github.com/researchers/adob.html (Flash content-type sniffing)