The following summarizes an HTTP persistence cookie vulnerability that I identified in A10 ACOS ADC software. This was disclosed to A10 Networks in June 2016 and has now been resolved.
As noted in a previous post, ACOS uses insecure HTTP/HTTPS persistence cookies which can allow a malicious user to craft a cookie determining the server and port to which a persistent session should be sent. In addition, for vports using the default “port-based” HTTP cookie persistence, it was discovered that when using the default persistence cookie type, ACOS does not perform a check to ensure that the server/port defined in the cookie is within the configured service-group for that VIP.
The only sanity check appears to be to ensure that the server IP read from the cookie has been configured on the A10 within the same partition. If that constraint is met, packets will be forwarded by ACOS to the real server based solely on the value contained in the cookie. This is extremely serious as it allows a malicious user to connect, for example, through a public VIP and access back end servers used by other VIPs, including those only accessible via internal IPs.
SUMMARY OF VULNERABILITY
When using a vport configured for default (port-based) HTTP cookie-based persistence, a cookie submitted to that vport with the correct name is trusted without any validation of the information contained within.
This would not be an issue if the cookies were secure and thus invulnerable to tampering; however, given that the cookies used weakly obfuscated values, it is trivial to generate arbitrary encoded IP/Port cookie values and by doing so cause the A10 to blindly redirect HTTP sessions to any accessible internal HTTP server.
The implications of this are wide ranging. Enumerating the available servers on an internal network is a simple scripting exercise and once completed, custom cookie creation can be used to direct an IP connection to any valid back end server. For example, if there is an ACL applied to a VIP which limits access to specific IP addresses, it is likely possible to access that restricted service by accessing a public VIP on the same A10 ADC which uses cookie persistence, and using a custom cookie to redirect the incoming session to a back end server for the restricted service. Depending on the implemented architecture of the A10 ADC, the ability to redirect sessions to any available server could potentially expose internal HTTP servers to the Internet through apparently unrelated public VIPs.
SOFTWARE VERSIONS TESTED:
This vulnerability was discovered and validated initially in ACOS 2.7.2-P4-SP2 and reconfirmed most recently in ACOS 4.1.1-P3.
This behavior has been core to persistence cookies until now, so it can be reasonably stated that this vulnerability exists in:
- ACOS 2.7.2 initial release and up to 2.7.2-P10 inclusive
- ACOS 4.0 initial release up to 4.1.1-P5 inclusive
One mitigation is to configure all cookie persistence templates with the service-group option; however, enabling this will in turn mean disclosing the service-group name in the cookies. That disclosure may be a lesser risk than continued exposure to this vulnerability, so should be assessed for use as a temporary workaround if a software upgrade is not possible.
A10 Networks has issued updated software which include a fix for this vulnerability :
- ACOS 2.7.2-P11 (June 2017)
- ACOS 4.1.1-P6 (November 2017)
A10 Networks tracked this vulnerability under ID 368800.
AUTHOR / DISCOVERER
John Herbert (http://movingpackets.net)
HTTP persistence cookies generated by A10 ACOS (Advanced Core Operating System) can take one of four forms depending on the match-type defined within the persistence cookie template:
|Match-Type||Cookie Will Contain|
|(none)||(default) Real server IP and port|
|server||Real server IP|
|service-group||Service-group + real server IP and port|
|server service-group||Service-group + real server IP|
The service-group configuration option implies that the ADC will ensure that the returning client will go to the same service-group as it did previously, checking the IP (and optionally, port) defined in the cookie sent by the client for membership in the selected service-group.
Without the service-group option in place, the cookie is only examined (or created, if missing) the first time a client connects to a vport, after which the cookie is trusted when presented by the client. Assuming that a connection can be made to the destination, the session will be directed to the IP and port specified in the cookie.
The weak obfuscation used by ACOS to hide the IP and port information in HTTP persistence cookies mean that it is possible for a malicious client to send a cookie value that the A10 ADC will implicitly trust. In turn the ADC will faithfully create a proxied HTTP connection to the IP and port specified in the cookie so long as the specified destination server is defined somewhere in the partition’s configuration. If routing and source-nat allow the A10 ADC to make a connection to the requested IP/port on behalf of the client, it will be made.
One limitation to this technique is that if the vport being accessed by the malicious user is configured with a server-ssl template to encrypt traffic between the ADC and the real server, any malicious redirected connection attempts will also be made using SSL; which restricts the connectivity to those server ports running SSL. The client-side protocol is irrelevant (HTTP or HTTPS) as a cookie can be supplied by the client over either protocol.
The implications should be obvious. Making an initial HTTP/HTTPS connection to a vport will generate a valid cookie from which the cookie name and the real server and port can easily be extracted. It is then simple to create an automated tool that can create new (false) values for the named cookie and thus scan for available HTTP servers, checking common ports, perhaps starting on the IP subnet extracted from the original persistence cookie.
The cookie sent to the client on first connection to a vport configured using the default cookie persistence type will look like this:
The [vport] field is usually a 5-digit integer, but for the purposes of a cookie attack the only relevance to a would-be attacker is to note down the entire cookie name so it can be reused when sending a bogus value to the ADC. Creating false values is made simple courtesy of weak encryption in the cookie.
Users of A10 Networks ACOS 2.7.2 and 4.x using cookie-based persistence should upgrade immediately to the fixed-in versions outlined above, or higher. If not possible, consideration should be given to avoiding using the default port-based HTTP persistence cookies.