Обзор уязвимости в Winbox от Mikrotik. Или большой фейл

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

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

Начнём

Первое, с чего стоит начать, это анализ трафика между клиентом Winbox и устройством

Winbox — приложение для ОС WIndows, которое в точности повторяет веб-интерфейс и предназначено для администрирования и конфигурирования устройства с Router OS на борту. Поддерживается 2 режима работы, по протоколу TCP и UDP

Перед началом стоит отключить шифрование трафика в Winbox. Делается это следующим образом: нужно включить галочку Tools -> Advanced Mode. После этого интерфейс изменится следующим образом:

Снимаем галочку Secure Mode. Запускаем Wireshark и пробуем авторизоваться на устройстве:

Как можно заметить ниже, после авторизации идёт запрос фала list и затем его содержимое нам полностью передаётся, может показаться, что всё хорошо, но взглянем на самое начало этой сессии:

В самом начале Winbox отправляет точно такой же пакет с запросом файла list:

Рассмотрим его структуру:

1. 37010035 — размер пакета
2. M2 — константа, обозначающая начало пакета
3. 0500ff01 — переменная 0xff0005 в значении True
4. 0600ff09 01 — переменная 0xff0006 в значении 1 (Номер передаваемого пакета)
5. 0700ff09 07 — переменная 0xff0007 в значении 7 (Открыть файл в режиме чтения)
6. 01000021 04 6с967374 — переменная 0x01000001 строка list размером 4 байта (Обычно данная переменная отвечает за название файла)
7. 0200ff88 02… 00 — массив 0xff0002 размером 2 элемента
8. 0100ff88 02… 00 — массив 0xff0001 размером 2 элемента

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

struct Array {
    uint32 type;
    uint8 count;
    uint32 item1;
    uint32 item2;
    ...
    uint8 zero;
}

struct Array {
    uint32 type;
    uint8 length;
    char text[length];
}

struct Array {
    uint32 type;
    uint8/32/64 value;
}

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

На стороне устройства, за обработку пакетов отвечает исполняемый файл /nova/bin/mproxy. Так как названия функций не были сохранены, я назвал функцию, которая обрабатывает пакет и принимает решения о том что делать с файлом file_handler(). Взглянем на саму функцию:

P.S. Код который нас будет интересовать отмечен стрелочками.

Шаг 1

При получении пакета на открытие файла для чтения, он начинает обработку с этого блока:

В самом начале из пакета, с помощью функции nv::message::get<nv::string_id>() извлекается название файла.

Далее функция tokenize() разбивает полученную строку на отдельные части, используя в качестве разделителя символ "/".

Полученный массив строк передаётся в функцию path_filter(), которая проверяет полученный массив строк на наличие "..", и в случае ошибок возвращает ошибку ERROR_NOTALLOWED (0xFE0009)

P.S. ERROR_NOTALLOWED так же будет получен в ответе, если нет прав доступа к файлу

Если же всё нормально, то к началу названия файла конкатенируется путь, к директории webfig или pckg

Шаг 2

Если всё прошло успешно, открывается файл и его дескриптор сохраняется в глобальный объект.

Если файл открыть не удалось, то в ответе мы получаем ошибку: cannot open source file.

Таким образом, чтобы получить содержимое файла, должно быть соблюдено 3 условия:

1. Путь к файлу не содержит "..";
2. Имеются права на доступ к файлу;
3. Файл существует и может быть успешно открыт.

Теперь давайте попробуем отправить несколько пакетов для проверки работоспособности этой функции:

$ ./untitled.py -t 192.168.88.1 -f /etc/passwd
Error: SYS_ERRNO => ERROR_FAILED
Error: SYS_ERRSTR => cannot open source file

$ ./untitled.py -t 192.168.88.1 -f /../../../etc/passwd
Error: SYS_ERRNO => ERROR_NOTALLOWED

$ ./untitled.py -t 192.168.88.1 -f //./././././../etc/passwd
Error: SYS_ERRNO => ERROR_FAILED
Error: SYS_ERRSTR => cannot open source file

Так! А вот это уже странно… Мы помним, что ERROR_NOTALLOWED появляется если не прошла проверка в path_filter(), иначе мы бы ещё получили сообщение об отсутствии прав доступа, но в последнем случае, получается, что поиск файла производился в директории верхнего уровня?

Попробуем такой способ:

$ ./untitled.py -t 192.168.88.1 -f //./.././.././../etc/passwd
xvM2�����	�	1Enobody:*:99:99:nobody:/tmp:/bin/sh
root::0:0:root:/home/root:/bin/sh

И это сработало. Но почему? Давайте взглянем на код функции path_filter():

По коду отлично видно, что действительно происходит поиск вхождения ".. ", в полученный массив строк. Но дальше самое интересное, я выделил красным этот фрагмент.
Суть этого кода в том, что: Если предыдущий элемент так же является "..", то проверка считается проваленной. В противном случае — считать, что всё хорошо.

Т.е. чтобы всё сработало, нужно просто чередовать "/./" и "/../" чтобы успешно перемещаться по любым каталогам и спускаться на любой уровень ФС.

Давайте посмотрим, как разработчики Mikrotik это исправили:

Сравнение псевдо-С кода

Теперь выход из цикла проверки происходит при первом же обнаружении ".. ". Правда мне не совсем понятно, зачем добавили проверку вхождения одной точки. А из-за изменения механизма активации пользователя devel, к сожалению, нет возможности посмотреть это в динамике.

Подведём итог

1. Router OS без проблем обрабатывает входящие пакеты ещё до авторизации пользователя
2. Из-за некорректного фильтра мы получаем доступ к любому файлу

Учитывая предыдущие пункты, мы без проблем можем: создавать, удалять, читать, и записывать файлы, а так же создавать произвольные директории

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

Так же данная уязвимость может стать отличной заменой для известной ранее возможности активации режима разработчика, ведь перезагружать устройство, делать backuprestore файла конфигурации теперь не нужно.

Автор: Nodir7565

Источник