Прошлый летом я заинтересовался вопросами информационной безопасности и взлома. Последний год я много играл в wargames, «захват флага», тестирование на проникновение, постоянно совершенствуя навыки взлома и изучая новые способы заставить компьютеры отклоняться от ожидаемого поведения.
Короче говоря, мой опыт ограничивался имитируемой средой, и, считая себя официальным хакером, я никогда не совал нос в бизнес других людей.
Это будет подробная история о том, как я взломал сервер, на котором размещалось 40 (это точное число) веб-сайтов, и о моих находках.
Примечание. Некоторые предварительные знания CS необходимы для понимания технической составляющей статьи.
Друг сообщил мне, что его веб-сайт XSS уязвим, и попросил меня взглянуть. Я попросил у него официальное разрешение на полное тестирование его веб-приложения на его сервере. Ответ был положительным.
В статье я буду ссылаться на сайт моего друга – http://example.com
Первый шаг – найти как можно больше информации о своем враге, пытаясь как можно меньше его тревожить.
На этом этапе мы запускаем наш таймер и начинаем сканирование.
$ nmap --top-ports 1000 -T4 -sC http://example.com
Nmap scan report for example.com {redacted}
Host is up (0.077s latency).
rDNS record for {redacted}: {redacted}
Not shown: 972 filtered ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
| ssh-hostkey:
| {redacted}
80/tcp open http
| http-methods:
|_ Potentially risky methods: TRACE
|_http-title: Victim Site
139/tcp open netbios-ssn
443/tcp open https
| http-methods:
|_ Potentially risky methods: TRACE
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_{redacted}
445/tcp open microsoft-ds
5901/tcp open vnc-1
| vnc-info:
| Protocol version: 3.8
| Security types:
|_ VNC Authentication (2)
8080/tcp open http-proxy
|_http-title: 400 Bad Request
8081/tcp open blackice-icecap
Сканирование завершается по истечении 2 минут.
Множество открытых портов! Судя по тому, что порты FTP (порт 21) и SMB (порты 139/445) открыты, можно предположить, что сервер используется для размещения и совместного использования файлов, а также является веб-сервером (порты 80/443 и прокси на 8080/8081).
При сканировании UDP-порта будет рассмотрено более 1000 портов, если вышеизложенной информации недостаточно. Единственным портом, с которым разрешено взаимодействовать (без учетных данных), является порт 80/443.
Не теряя времени, я запускаю gobuster
, чтобы найти какие-нибудь интересные файлы на веб-сервере, пока я буду копать информацию вручную.
$ gobuster -u http://example.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 100
/admin
/login
Оказывается, путь /admin был «административным инструментом», который позволял аутентифицированным пользователям изменять материал на веб-сервере. Он требует параметры доступа, которых у нас нет (спойлер: gobuster не нашел ничего ценного).
Прошло около 3 минут. Ничего полезного.
Веб-сайт просит нас войти. Нет проблем. Создаем учетную запись с фиктивной электронной почтой, щелкаем по электронной почте подтверждения и входим в систему через несколько секунд.
Веб-сайт приветствует нас, предлагает перейти к профилю и обновить фотографию. Как мило.
Похоже, сайт сделан на заказ. Я собираюсь протестировать уязвимость с неограниченной загрузкой файлов. На моем терминале я выполняю:
echo "<?php system($_GET['cmd']); ?>" > exploit.php
Я пытаюсь загрузить «картинку» и – бинго! Загрузчик позволяет загрузить файл exploit.php. Конечно, у него нет эскизов, но это значит, что мой файл где-то загружен.
Ожидается, что загрузчик выполнит какую-либо обработку загруженного файла, проверит его расширение и заменит принятое расширение, например .jpeg, .jpg, чтобы избежать удаленного выполнения кода злоумышленником, загружающим вредоносный код.
В конце концов, люди заботятся о безопасности.
`Copy image address` results in the following url being copied to our clipboard:
http://www.example.com/admin/ftp/objects/XXXXXXXXXXXX.php
Похоже, что webshell готов и работает:
Видим, что веб-сервер запускает perl-скрипты (реально? perl?). Мы берём обратную оболочку perl из нашего любимого cheatsheet, устанавливаем IP/Port и получаем в качестве награды low-privileged оболочку – извините, нет скришота.
~ 5 минут в оценке, и у нас уже есть оболочка с низким уровнем привилегий.
К моему огромному удивлению, на сервере размещался не 1 сайт, а сразу 40 разных. К сожалению, я не сохранил скриншоты каждой детали, но выход был вдоль линий:
$ ls /var/www
access.log site1/ site2/ site3/ {... the list goes on}
Удивительно, но у меня был доступ на чтение ко всем размещенным веб-сайтам, а это означало, что я мог читать весь бэкенд-код сайтов. Я ограничился кодом example.com.
Примечательно, что внутри каталога cgi-admin/pages
все скрипты perl соединялись с базой данных mysql как root. Учетные данные для базы данных были в открытом виде. Пусть они будут root:pwned42.
Разумеется, на сервере была запущена MariaDB, и мне пришлось решить эту проблему, прежде чем получить доступ к базе данных. После этого мы выполняем:
mysql -u root -p -h localhost victimdbname
Password: pwned42
И мы находимся в базе данных с привилегиями root.
Через 7 минут у нас есть полный доступ для чтения / записи к содержимому 35 (!) баз данных.
Морально я обязан здесь остановиться и поделиться выводами. Потенциальный ущерб уже огромен.
Что может сделать злоумышленник
- Дамп содержимого всех баз данных, как описано здесь, в результате чего произойдёт утечка данных всех 35 компаний.
- Удалить все базы данных 35 компаний.
- Оставить бэкдор для постоянного доступа как apache с cronjob, как описано здесь ( если злоумышленник хочет вернуться.
Процесс mysql запускался под root, поэтому я решил, что попробовал выполнить ! whoami
в надежде получить корни. К сожалению, я все еще был apache.
Время отдохнуть. Остановите таймер.
Что может пойти не так?
Я поделился своими выводами и получил разрешение копать глубже.
Прежде чем искать способы повысить свои привилегии до root и иметь возможность причинить огромный потенциальный ущерб, я посмотрел, какие другие интересные файлы мог бы читать, будучи ограниченным пользователем.
Я вспомнил об открытых портах SMB. Это означало, что где-то в папке должна быть другая папка, которая используется в системе среди пользователей. После небольшого поиска в каталоге /home/samba/secure
появляется следующее:
Внутри всех этих каталогов были файлы каждого пользователя хостинговой компании. Это включало все виды конфиденциальных данных, среди прочего:
- .psd / .ai (дизайнеры знают, как важно сохранять эти данные);
- файлы cookie sqlite;
- счета-фактуры;
- пиратские электронные книги (усмехнулся, когда я увидел);
- учетные данные для SSID-сетей WiFi.
Что может сделать злоумышленник
- Лагерь за пределами офиса компании: войти в свою интрасеть и выполнить всевозможные забавные атаки, которые можно делать в локальных сетях.
- Сделать дамп всех конфиденциальных данных, перечисленные выше, и выложить его для всех.
Потребовалось некоторое время, чтобы пройти через папки и понять, насколько серьезна эта проблема.
Еще один перерыв.
Последний удар
Осмотревшись еще немного как apache, я решил, что пришло время пойти на большую рыбу – получить доступ root. Используя шпаргалки, начинаю перебирать систему.
В процессе исследования на уязвимости я уже перебрал большинство методов и, похоже, не смог найти ничего, что увеличило бы мою точку опоры.
В задачах Capture the Flag, которые я использую для игры, операционная система обычно пропатчена. Это некоторая намеренно неверно настроенная служба, которая в конечном итоге дает вам привилегии root. Однако в реальном мире люди не латают дыры.
Я имею в виду вот что: посмотрите на Equifax (не мог удержаться).
Какой Linux работает на сервере?
$ cat /etc/issue
CentOS Linux release 7.2.1511 (Core)
Какая версия ядра?
Это похоже на старую версию ядра.
Это напоминает вам что-то? Если нет, прочитайте здесь (подсказка: это ОЧЕНЬ серьезно).
Я нашел этот пост в блоге, который указал мне проверить, было ли ядро уязвимым для найденного здесь скрипта.
Временные метки и восстановленные сайты Firefox отредактированы
С последующим:
Игра закончена
Я мгновенно написал электронное письмо, полностью раскрывающее детали и потенциальное влияние каждого шага, как описано выше. Уф.
Что может сделать злоумышленник
- Чтение/изменение ВСЕХ файлов на сервере.
- Оставить постоянный бэкдор (как сделали с apache).
- Устанавливать и потенциально распространять вредоносное ПО в интрасети сервера.
- Установить ransomware.
- Использовать сервер как криптовалютный майнер.
- Использовать сервер как прокси-сервер.
- Использовать сервер как сервер C2C.
- Использовать сервер как часть ботнета.
*… (использовать ваше воображение). - rm -rf / (без шуток).
На следующий день со мной связался друг (он связался с работающей на сервере компанией) и рассказал, что ошибка в загрузке файлов была исправлена.
tl;dr
Подводя итоги, мы обнаружили следующее:
- Веб-приложение с уязвимостью для неограниченной загрузки файлов, которая привела к использованию оболочки с ограниченными правами.
- Учетные данные для базы данных mysql, которые привели к доступу на чтение/запись к 35 базам данных.
- Множество читаемых конфиденциальных файлов.
Наконец, мы злоупотребили непропатченным ядром для получения доступа root.
Решения проблем
Начнем с аплоудера, который дал основной плацдарм. Поскольку бэкенд всего веб-приложения был написан в perl, я не могу предложить решения.
Решение, которое я бы предложил, было бы таким: не использовать perl в 2017 году, но это только мое мнение.
Что касается файловой системы, я рекомендую проявлять большую осторожность при назначении правильных прав доступа к файлам для пользователей в соответствии с принципом наименьших привилегий. Таким образом, даже если низкоприоритетный пользователь, такой как apache, получает доступ, он не может читать конфиденциальные файлы.
Запуск всех веб-сайтов на одном сервере – плохая идея, я не уверен, позволит ли докеризированный подход решить проблему.
Наличие одинаковых учетных данных для всех баз данных – безусловно, плохая идея.
Нежелательно иметь одиночные точки отказа.
Наконец, пропачьте все. Это всего лишь одна команда: su -c 'yum update'
(специфичная для CentOS).
Оригинал: How I Hacked 40 Websites in 7 minutes.
Автор: olemskoi