SSD Advisory – Vigor ACS Unsafe Flex AMF Java Object Deserialization

Want to get paid for a vulnerability similar to this one?
Contact us at: sxsxdx@xbxexyxoxnxdxsxexcxuxrxixtxy.xcom
See our full scope at:

Vulnerability Summary
A vulnerability in Vigor ACS allows unauthenticated users to cause the product to execute arbitrary code.

VigorACS 2 “is a powerful centralized management software for Vigor Routers and VigorAPs, it is an integrated solution for configuring, monitoring, and maintenance of multiple Vigor devices from a single portal. VigorACS 2 is based on TR-069 standard, which is an application layer protocol that provides the secure communication between the server and CPEs, and allows Network Administrator to manage all the Vigor devices (CPEs) from anywhere on the Internet. VigorACS 2 Central Management is suitable for the enterprise customers with a large scale of DrayTek routers and APs, or the System Integrator who need to provide a real-time service for their customer’s DrayTek devices.”

An independent security researcher, Pedro Ribeiro, has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.

Vendor Response
“We’ll release the new version 2.2.2 to resolve this problem and inform the user about the CVE ID and reporter.
The release note will be updated on Wednesday (Apr 4, 2018).
Kindly let me know if you have further question, thank you!”

Vulnerability Details
VigorACS is a Java application that runs on both Windows and Linux. It exposes a number of servlets / endpoints under /ACSServer, which are used for various functions of VigorACS, such as the management of routers and firewalls using the TR-069 protocol [2].

One of the endpoints exposed by VigorACS, at /ACSServer/messabroker/amf, is an Adobe/Apache Flex service that is reachable by the managed routers and firewalls. This advisory shows that VigorACS uses a Flex version is vulnerable to CVE-2017-5641 [3], a vulnerability related to unsafe Java deserialization for Flex AMF

Technical Details
By sending an HTTP POST request with random data to /ACSServer/messagebroker/amf, the server will respond with a 200 OK and binary data that includes:

While in the server logs, a stack trace will be produced that includes the following:

A quick Internet search revealed CVE-2017-5641 [3], which clearly states in its description:
“Previous versions of Apache Flex BlazeDS (4.7.2 and earlier) did not restrict which types were allowed for AMF(X) object deserialization by default. During the deserialization process code is executed that for several known types has undesired side-effects. Other, unknown types may also exhibit such behaviors. One vector in the Java standard library exists that allows an attacker to trigger possibly further exploitable Java deserialization of untrusted data. Other known vectors in third party libraries can be used to trigger remote code execution.”

Further reading in [4], [5] and [6] led to a proof of concept (Appendix A) that showed both on the server logs and in the HTTP responses that the deserialization could be exploited to achieve code execution.
A fully working exploit has been released with this advisory that works in the following way:
a) sends an AMF binary payload to /ACSServer/messagebroker/amf as described in [5] to trigger a Java Remote Method Protocol (JRMP) call back to the attacker
b) receives the JRMP connection with ysoserial’s JRMP listener [7]c) configures ysoserial to respond with a CommonsCollections5 or CommonsCollections6 payload, as a vulnerable version of Apache Commons 3.1 is in the Java classpath of the server
d) executes code as root / SYSTEM

The exploit has been tested against the Linux and Windows Vigor ACS 2.2.1, although it requires a ysoserial jar patched for multi argument handling (a separate branch in [7], or alternative a ysoserial patched with CommonsCollections5Chained or CommonsCollections6Chained – see [8]).

Appendix A contains the Java code used to generate the AMF payload that will be sent in step a). This code is very similar to the one in [5], and it is highly recommended to read that advisory by Markus Wulftange of Code White for a better understanding of this vulnerability.

Appendix A



*** This is a Security Bloggers Network syndicated blog from SecuriTeam Blogs authored by SSD / Noam Rathaus. Read the original post at: