В этом репозитории задокументировано исследование безопасности ArubaOS 8.13.2.0 LSR, проведённое в рамках программы Bug Bounty HPE Networking на Bugcrowd. Все исследования выполнялись на авторизованном лабораторном экземпляре (виртуальная машина ArubaMC-VA-US) с использованием образов прошивок и OVA, предоставленных программой по официальной ссылке на прошивку.

Было выявлено и отправлено шесть уязвимостей. Находки охватывают стек ICMP/IP, XML-интерфейс управления (порт 32000) и службу FTP (порт 21). Все тесты проводились без аутентификации — для ни одной из задокументированных здесь находок не использовались учётные данные администратора или активные сессии.

Найденные уязвимости

Поверхность атаки

Все задокументированные находки не требуют аутентификации. Поверхность атаки состоит из трёх компонентов:

Техническое резюме

Находка 1 — XXE без аутентификации → HTTP SSRF

XML-парсер на порту 32000 обрабатывает объявления внешних сущностей SYSTEM без аутентификации. Подтверждено посредством:

• Перехват пакетов на уровне провода: инициированный контроллером запрос GET /test HTTP/1.0 к инфраструктуре атакующего
• Журнал sshd самой целевой системы: Bad protocol version identification 'GET / HTTP/1.0' from 127.0.0.1 — серверное доказательство выполнения SSRF, зафиксированное самим контроллером
• Внешняя DTD была независимо запрошена 3 раза с HTTP-сервера атакующего
• Подтверждено 9 открытых внутренних портов через SSRF-ответы <dialog>success</dialog>

Ответ триажа: «теоретически / нет валидного PoC» — не рассмотрен после четырёх пунктов доказательств, включая журнал sshd. Первый RaR истёк без ответа.

Находка 2 — ICMP-отражение + усиление Smurf

Обработчик ICMP Echo не проверяет исходные IP-адреса на соответствие записям ARP-таблицы и не применяет фильтрацию обратного пути (BCP38/uRPF). Поддельные ICMP Echo Request заставляют контроллер доставлять незапрошенные ответы подменённому источнику. Широковещательные исходные адреса заставляют контроллер отвечать на ff:ff:ff:ff:ff:ff, доставляя ответ всем хостам в L2-сегменте.

Доказательства: два независимых перехвата пакетов с двух физически раздельных машин. Перехват на стороне жертвы показывает незапрошенный Echo Reply на хосте, который не отправлял ни одного ICMP-запроса.

Ответ триажа: «ожидаемая сетевая функциональность» — pcap со стороны жертвы не был рассмотрен.

Находка 3 — Ghost Leak (TTL=0 + чтение за границей IP Total Length)

Обработчик ICMP Echo доверяет полю IP_Total_Length, не сверяя его с фактическим размером принятого кадра. Отправка IP_Total_Length=46 при фактических 28 байтах IP-данных заставляет обработчик читать 18 байт за границей пакета из сетевого приёмного буфера, отражая эти байты в ответе.

Атака использует пакеты с TTL=0 (RFC 791 предписывает их отбрасывать), что делает её невидимой для маршрутизаторов, IDS, межсетевых экранов и систем журналирования. 27 из 27 сформированных пакетов с TTL=0 получили ответы — 100% частота ответов.

Тот же механизм, что и в CVE-2003-0001 (EtherLeak) и CVE-2021-3031 (Palo Alto PAN-OS); обе уязвимости были приняты соответствующими вендорами.

Ответ триажа: «только нулевые байты» — чистый характер заполнения виртуального NIC VirtualBox был истолкован как отсутствие уязвимости.

Анализ прошивки

В рамках исследования находки 5 (не опубликовано здесь) образы прошивок AP, распространяемые через службу FTP, были подвергнуты реверс-инжинирингу. Ключевые результаты статического анализа всех четырёх образов прошивок:

Формат прошивки: Aruba Image Container (.ari) — сжатие LZMA, без шифрования. Тело использует подпись кода (X.509), а не шифрование для обеспечения конфиденциальности.

Охваченные платформы AP:

Примечательные результаты анализа прошивки:

• Все четыре образа прошивок содержат незашифрованные X.509 DER-сертификаты в конце файла, подписанные Aruba Networks Code Signing CA1, с форматом Subject CN ARUBA-PROD-{SERIAL}::{MAC}, встраивающим реальные MAC-адреса серийных AP
• Одни и те же два сертификата присутствуют во всех четырёх платформах прошивок (повторное использование идентичности между платформами)
• Linux 3.12.19 (ARM32 AP) — снят с поддержки с 2014 года. Linux 4.1.45 (ARM64 AP) — снят с поддержки примерно с 2022 года
• arm64.ari содержит /dev/tpm-cert (чип TPM), аппаратный MACsec (EIP-62/EIP-217), функцию gponPassword
• Внутренние кодовые имена AP, раскрытые в строках прошивки: Glenmorangie (AP-304/305), Aberlour (AP-303H), Bunker (AP-365/367), Aultmore (AP-555), Hendricks (AP-58x)
• Раскрыты имена хостов сборочных серверов: jenkins@c96556966d48, jenkins@317fcb08bd82, jenkins@aec499ab9b0f, jenkins@352b80449f0a

Хронология

Примечание о паттерне триажа

Пять из шести заявок получили ответы N/A. Единственная заявка, дошедшая до рассмотрения вендором (d13d0e83), — это та, в которой демонстрация воздействия наиболее прямолинейна (учётные данные → загрузка файла). Остальные пять — включающие pcap-доказательства на уровне провода, журналы серверных демонов и прямые ссылки на прецеденты CVE — были закрыты на уровне триажа.

В случае находки 1 первый запрос на ответ (RaR) истёк без какого-либо ответа. В случае находок 2, 3 и 6 ответы триажа не касаются конкретных представленных доказательств. Ни в одном случае решение триажа о закрытии не было технически согласовано с приложенными доказательствами.

Специалисты по безопасности приглашаются ознакомиться с отдельными отчётами и составить собственную оценку.

Ответственное раскрытие

Все находки были отправлены в HPE Networking Product Public Program на Bugcrowd до публикации. Программа классифицировала находки 1, 2, 3, 4, 5 и 6 как не являющиеся уязвимостями.

Vesqer / JM00NJ — netacoding.com — github.com/JM00NJ