Уязвимость CVE-2021-20090 позволяет получить доступ к любому скрипту веб-интерфейса без прохождения аутентификации. Суть уязвимости заключается в том, что в веб-интерфейсе некоторые каталоги, через которые отправляются изображения, файлы CSS и сценарии JavaScript, доступны без аутентификации. В этом случае проверка каталогов, к которым разрешен доступ без аутентификации, выполняется с использованием начальной маски. Указание символов «../» в путях к родительскому каталогу блокируется прошивкой, но использование комбинации «../» игнорируется. Таким образом, можно открывать защищенные страницы при отправке таких запросов, как «http://192.168.1.1/images/../index.htm». В этой статье рассмотрим как осуществляется обход аутентификации на маршрутизаторах с помощью CVE-2021–20090.

Корневые оболочки на UART

Довольно часто  маршрутизаторы, предлагают оболочку через последовательное соединение, известное как универсальный асинхронный приемник / передатчик (UART) на печатной плате. Производители часто оставляют контрольные точки или незанятые площадки на печатной плате для доступа к UART. Они часто используются для отладки или тестирования устройства во время производства. В данном случае нам очень повезло, что после некоторой плохой пайки и тестирования WSR-2533DHPL2 предложил оболочку BusyBox в качестве root вместо UART.

Если это для кого-то ново, давайте быстро рассмотрим этот процесс (в Интернете есть много статей с более подробным описанием взлома оборудования и оболочек UART).

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

Интерфейс UART на WSR-2533DHP3

Мы видим заголовок J4, который может быть тем, что мы ищем. Следующим шагом является проверка контактов с помощью мультиметра, чтобы определить мощность (СCV), землю (GND) и наши потенциальные контакты передачи / приема (TX / RX). После того, как мы их определили, мы можем припаять некоторые контакты и подключить их к такому инструменту, как JTAGulator, чтобы определить, по каким контактам мы будем связываться и с какой скоростью передачи.

Мы могли бы определить это другими способами, но JTAGulator значительно упрощает это. После установки напряжения, которое мы используем (3,3 В, найденного ранее с помощью мультиметра), мы можем запустить сканирование UART, которое попытается отправить возврат каретки (или некоторые другие указанные байты) и получить на каждом контакте с разными битами, что помогает  определить, какая их комбинация позволит нам общаться с устройством.

Запуск сканирования UART на JTAGulator

Сканирование UART показывает, что отправка возврата каретки через контакт 0 в качестве TX, с контактом 2 в качестве RX и скоростью передачи 57600 дает вывод BusyBox v1, который выглядит так, как будто у нас есть наша оболочка.

Httpd и аутентификация через веб-интерфейс

Доступ к двоичному файлу httpd значительно упрощает поиск уязвимостей в веб-интерфейсе, поскольку мы можем добавить его в Ghidra и идентифицировать любые интересные фрагменты кода. Одна из первых вещей, на которую я обычно обращаю внимание при анализе любого веб-приложения или интерфейса, — это то, как оно обрабатывает аутентификацию.

Изучая веб-интерфейс, я заметил, что даже после входа в систему файлы cookie сеанса не устанавливаются и токены не хранятся в локальном / сеансовом хранилище, так как же отслеживалось, кто прошел проверку подлинности? Открывая httpd в Ghidra, мы находим функцию с именем Assessment_access (), которая приводит нас к следующему фрагменту:

Фрагмент из FUN_0041fdd4 (), вызываемый оценкой_access ()

FUN_0041f9d0 () на скриншоте выше проверяет, совпадает ли IP-адрес хоста, выполняющего текущий запрос, с IP-адресом из предыдущего действительного входа в систему.

Теперь, когда мы знаем, что делает eval_access (), давайте посмотрим, сможем ли мы это обойти. Поискав, где на него ссылаются в Ghidra, мы видим, что он вызывается только из другой функции process_request (), которая обрабатывает любые входящие HTTP-запросы.

process_request () решает, должен ли он разрешать пользователю доступ к странице

Что сразу бросается в глаза, так это логическое ИЛИ в более крупном операторе if (строки 45–48 на скриншоте выше) и тот факт, что он проверяет значение uVar1 (установленное в строке 43) перед проверкой вывода Assessment_access (). Это означает, что если вывод bypass_check (__ dest) (где __dest — это запрашиваемый URL) возвращает что-либо, кроме 0, мы фактически пропустим необходимость аутентификации, и запрос будет передан в process_get () или process_post () .

Давайте рассмотрим bypass_check ().

Обход проверок с помощью bypass_check ()

bypass_list проверяется в bypass_check ()

Взглянув на bypass_check () на скриншоте выше, мы видим, что он перебирает bypass_list и сравнивает первые n байтов _dest со строкой из bypass_list, где n — длина строки, полученной из bypass_list. Если совпадений не найдено, мы возвращаем 0, и нам потребуется пройти проверки в Assessment_access (). Однако, если строки совпадают, то нас не волнует результат метода Assessment_access (), и сервер обработает наш запрос, как и ожидалось.

Взглянув на список обхода, мы видим login.html, loginerror.html и некоторые другие пути / страницы, что имеет смысл, поскольку даже неаутентифицированные пользователи должны иметь доступ к этим URL-адресам.

• Мы можем обойти аутентификацию и получить доступ к страницам, которые должны быть ограничены аутентифицированными пользователями.
• Эти страницы включают доступ к токенам, которые позволяют нам делать запросы GET / POST для получения более конфиденциальной информации и предоставлять возможность вносить изменения в конфигурацию.
• Мы знаем, что нам также нужно правильно установить заголовок Referer, чтобы httokens были приняты.

Как получит правильные токены httokens

Хотя мы знаем, что httokens захватываются в какой-то момент на страницах, к которым мы обращаемся, мы не знаем, откуда они берутся и как они генерируются. Это будет важно понять, если мы хотим продолжить эту эксплуатацию, поскольку они должны делать или получать доступ к чему-либо важному на устройстве. Отслеживание того, как веб-интерфейс производит эти токены, было похоже на событие Capture-the-Flag.

Страница info.html, к которой мы получили доступ с обходом пути, заполняла свою информационную таблицу данными из файлов .js в каталоге / cgi / и передавала два параметра. Один — это отметка даты и времени (_t), а другой — httoken, который мы пытаемся вычислить.

Мы видим, что ссылки, используемые для получения информации из / cgi /, генерируются с помощью функции URLToken (), которая устанавливает httoken (в данном случае параметр _tn) с помощью функции get_token (), но не похоже что get_token () может быть определенным где угодно в любом из скриптов, используемых на странице.

Глядя прямо выше, где определен URLToken (), мы видим, что определена эта странная строка.

Глядя на то, где он используется, мы находим следующий фрагмент. 

1.  // decode way

2.   var head = document.getElementsByTagName("head")[0] || document.documentElement;

3.   var script = document.createElement("script");

4.   script.type="text/javascript";

5.   teks="";teksasli="";

6.   enkripsi=ArcBase.decode(enkripsi);

7.   var panjang;panjang=enkripsi.length;for (i=0;i<panjang;i++){         teks+=String.fromCharCode(enkripsi.charCodeAt(i)^3) }teksasli=unescape(teks);

8.   script.text=teksasli;

9.   head.insertBefore(script,head.firstChild );

10.   head.removeChild(script);

• httokens, которые необходимы для выполнения запросов GET и POST к различным частям веб-интерфейса, генерируются на стороне сервера.
• Они хранятся в кодировке в тегах img внизу любой страницы при ее загрузке.
• Затем они декодируются в JavaScript на стороне клиента.

Мы можем использовать токены для любых запросов, которые нам нужны, если токен и Referer, используемые в запросе, совпадают. Мы можем делать запросы к конфиденциальным страницам, используя токен, полученный из login.html, но нам по-прежнему нужен обход аутентификации для доступа к некоторым действиям (например, внесению изменений в конфигурацию).

Примечательно, что на маршрутизаторе WSR-2533DHPL2 простое использование этих токенов означает, что мы можем получить доступ к паролю администратора для устройства, уязвимость, которая, по-видимому, уже исправлена ​​на WSR-2533DHP3 (несмотря на то, что обе версии прошивки были выпущены примерно в одно и то же время).

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

Все и сразу

• Получите правильные httokens из тегов img на странице.
• Используйте эти httokens в сочетании с обходом пути, чтобы сделать действительный запрос на apply_abstract.cgi
• В этом действительном запросе на apply_abstract.cgi вставьте параметр конфигурации ARC_SYS_TelnetdEnable = 1
• Отправьте еще один действительный запрос на перезагрузку устройства.