A Brief Survey of CWMP Security

Summary

This article attempts to provide a brief overview of the CPE WAN Management Protocol (CWMP). We also share some of our findings during a Penetration Test (with very limited scope) of a CWMP based Home Broadband infrastructure.

Finally we provide some of the possible attack vectors against a CWMP infrastructure and prospective areas of research in this topic.

Introduction

The CPE WAN Management Protocol (CWMP) is a bi-directional SOAP/HTTP based protocol which allows centralised remote management of Customer Premises Equipments such as Broadband Routers, VoIP Phones , Set-Top Boxes etc. by an Auto Configuration Server (ACS).

CWMP infrastructure allows an ACS to provision a CPE during its deployment at the customer end while monitoring and upgrading its software and configuration as and when applicable.

The Broadband Forum's Technical Report 069 (TR069) defines the specification and implementation requirements for CWMP.

Deployment & Technical Details

Fig. 1.0: CWMP Specification - TR069.pdf

The above diagram briefly describes the design and deployment of a CWMP based infrastructure involving a set of CPE devices and an ACS. The ACS can request for a session with the CPE which in turn establishes a CWMP session with the pre-configured ACS. The session allows an ACS to perform various administrative tasks on the CPE including software and configuration update. If UPNP is supported by the CPE, it optionally can allow NAT Traversal functionality by an ACS so that it can communicate with devices inside the Local Network and request for connection initiation.

Protocol of Communication

CWMP uses SOAP/HTTP based communication between the ACS and the CPE. The schema definition for CWMP SOAP Methods are available here using which an appropriate WSDL can be generated for use with conventional SOAP Clients or Libraries. Pre-generated WSDL for CWMP-1.0 and CWMP-1.1 can be found here.

The major RPC Methods used in CWMP are as follows:

• Inform method is used by a CPE to initiate a CWMP Session with its pre-configured ACS.
• GetParameterValues method is used by the ACS to obtain various configuration information from the CPE using corresponding Parameter Names.
• Parameters are grouped based on relevance and are separated using '.'
• E.g. InternetGatewayDevice.ManagementServer.URL is the parameter name for ACS URL configuration in the CPE.
• SetParameterValues method is used by the ACS to update various configuration information in the CPE using corresponding Parameter Names.
• Download method is used by the ACS to initiate a file download by the CPE. This request is usually used to upgrade software/firmware in the CPE.
• Upload method is used by the ACS to request the CPE to upload a local file from the CPE to a specific URL. Current version of CWMP allows uploading of Vendor Configuration and Log Files only.
• Reboot method is used by the ACS to initiate a CPE reboot.

The CWMP specification also supports a method called GetRPCMethods which can be used to enumerate the supported CWMP RPC Methods in a CWMP capable device (CPE or ACS).

CWMP GetRPCMethods Example using SoapUI

The above screenshot shows a GetRPCMethods call against an ACS. This method is probably ideal for use as a CWMP endpoint discovery mechanism due to the fact that many ACS or CPE will allow a request for this method even without authentication.

During our testing, we could call this method against multiple ACS implementations without authentication. However none of the CPEs (our scope was limited to only 2 models of Home Broadband ADSL Router) responded to this request even with authentication.

Session Initiation & Execution

• A CWMP Session is initiated by a CPE with its pre-configured ACS URL by sending an Inform Request to the ACS. Device specific information like Vendor, Make, Model etc. are shared as a part of Inform request parameter with the ACS. An Inform request is executed by a CPE on occurrence of various events or periodically every pre-configured duration.
• The ACS in turn responds with an Inform Response message which contains negotiated session parameters. This HTTP response may contain more than one SOAP envelops each containing a CWMP RPC Method call request from the ACS. 
• The CPE then responds with response to RPC Method Call requests from the ACS or RPC Method Call request of its own.
• The session is terminated when there are no further messages to be exchanged by both the ends or in case of an error.

Alternatively, an ACS may also request for a session by sending a GET request to a specific URL in the CPE called the Connection Request Notification (CRE). The specification suggests usage of non-static resource-location by the CPE along with HTTP Digest based authentication for CRE. This GET request act as a trigger event which should cause the CPE to initiate a CWMP session with the ACS in the usual manner described above.

Note: The CWMP specification suggests usage of a single HTTP connection (using the Keep-Alive flag) for the entire CWMP session. However cookies may be used to maintain the HTTP session for implementations that does not support Keep-Alive.

Security Note: CWMP is relatively secure by design due to the fact that CPE devices which may be exposed over the Internet DOES NOT accept CWMP RPC requests over any HTTP connection originating from any location other than the one initiated by the CPE itself. The CPE initiates an HTTP Connection with the pre-configured ACS URL and initiates a CWMP Session. The SOAP/HTTP paradigm is reversed in its implementation such that HTTP Responses from the ACS contains CWMP RPC Requests and HTTP Requests from the CPE contains corresponding CWMP RPC responses.

CWMP Attack Surface

During our research, we were not able to discover any critical issue with the design of CWMP however during a pentest we were able to exploit configuration weaknesses in the CWMP implementation of the target particularly hardcoded credentials and absence of SSL in HTTP connections. Particularly we were able to demonstrate using CWMP for backdooring CPE devices and using our malicious ACS as a Command & Control server for multiple CPE devices which was possible only due to configuration vulnerabilities in the target deployment and is not a flaw with CWMP itself.

Man in the Middle (MiTM) Attacks

As described earlier, CWMP enables an ACS to perform various administrative and management operation on a set of CPE devices including firmware upgrade and updating important configuration parameters like Gateway IP, DNS Server etc. The specification strongly encourages usage of HTTPS instead of plain HTTP. The specification also optionally requires the CPE to verify the SSL certificate fingerprint of the ACS before connection establishment. Adhering to these recommendations ensure integrity of the session.

CWMP infrastructure that does not make use of SSL sessions are susceptible to Man-in-the-Middle attacks which endagers CPE devices. In case an attacker manages to become a Man-in-the-Middle between an ACS and a CPE, it is possible to change the ACS URL configuration and hijack the corresponding CPE using his own malicious ACS.

Reflective DDoS against an Auto Configuration Server (ACS)

CWMP provides option for an ACS to request for a session with a CPE. The Connection Request Notification (described earlier) is a GET request sen't to a CPE designated URL with credentials for HTTP Digest Authentication with the CPE. This GET request acts as trigger for the CPE to initiate a new CWMP session with its pre-configured ACS after verification of provided credentials. The specification requires the CPE to randomly generate the path of the URL for Connection Request Notification. However during our testing, we found the entire set of CPE devices within the scope of testing have the following configuration:

CWMP "Connection Request Notification" Configuration in Test ADSL Router

Evidently the CWMP implementation in our tested CPE devices are not very obedient to the specification. Due to the predictable nature of the Connection Request Notification (CRE) configuration for CPE devices, it is trivial to write a script to scan an entire network for open CWMP endpoints and send a CRE HTTP request which will initiate a connection from the CPE to the ACS. If the network is sufficiently large, it can be exploited to cause a DDoS against the ACS.

Even though the specification suggests that the CPE should handle this case and must not initiate more than a given number of connection within a time window, implementations may vary and such was the case during our testing.

Miscellaneous Issues

The ACS is a conventional web application usually implemented using Java based technologies and deployed on top of JBoss or Tomcat. Hence during a Penetration Test of a CWMP deployment the ACS must be subjected to a conventional Web Application & Web Service Penetration Testing. 

We were blessed with a nice verbose SQL Injection vulnerability in one of the target ACS during our test which made life a bit easier.

Although CWMP provides a robust model for remote management of CPE in a local broadband deployment, the security threats associated with the design of CWMP and its common deployments are yet to be evaluated. The readers are requested to share possible Attack Vectors that may be possible against a CWMP infrastructure.

References

http://www.broadband-forum.org/cwmp.php
http://www.broadband-forum.org/technical/download/TR-069.pdf
http://en.wikipedia.org/wiki/TR-069
http://openacs.sourceforge.net/
http://pierky.wordpress.com/2009/05/20/acs-url-configuration-via-dhcp-vendor-specific-information/
https://github.com/dpavlin/perl-cwmp
http://my-svn.assembla.com/svn/cwmp/src/parser/wsdl/

Unpacking ASPack-2.29 using Dynamic Analysis

ASPack is a Win32 executable file compressor which also protects the executable against basic Reverse Engineering. Although there are automated tools like IDA Pro's Universal Malware Unpacker or can probably be unpacked using techniques defined in BitBlaze Renovo, we analyzed ASPack protected executables using Dynamic Analysis particularly as an exercise for our upcoming training on Reverse Engineering and Malware Analysis at Nullcon 2012 Delhi.

Following analysis is based on Free version of ASPack 2.29.

ASPack-2.29 Generated Executable Overview

ASPack compresses each section of the input executable along with adding two of its own section: .aspack and .asdata - the former containing the decoder and loader code however it is currently not clear about the purpose of the later as it seem to be empty (SizeOfRawData = 0).

Section List for Original Executable

Section List for Packed Executable

Comparing the Section Listing of the original and packed executable above, following assumptions can be made:

• ASPack keeps the original sections intact including the section RVA however it sets the section mapping permission to RWX instead of the original R_X.
• ASPack adds two news sections - .aspack and .adata among which the purpose of .adata is unknown as it is empty.
• As understandable, the original entry-point is redirected to point somewhere within .aspack section.

Analysis Approach

The approach was conventional - start with Static Analysis to have a basic idea of the decoder logic and look for possible anti-debug or anti-diassambly technique and acquire enough knowledge to proceed with Dynamic Analysis. We needed to identify important code blocks like decoder loop, section mapping, control transfer to Original Entry Point (OEP) etc before we can proceed with automated unpacking.

Static Analysis

The entry point code in .aspack section in the packed executable uses a bunch of fake long and short jump op-codes (0xe9, 0xeb) to break the disassembler (Note: IDA 6.3 can detect such obfuscation technique and disassemble correctly without manual intervention). After little manual fix-up the code can be analyzed and IDA 5.0 (free) can build the Flow Graph correctly as shown below.

Three APIs as shown below in the disassembly were found to be resolved early in the loader code. Based on this logic, we made an assumption that those APIs will be used in order to decode and map sections and hence are perfect analysis points during Dynamic Analysis.

Dynamic Analysis

Phase1

We needed to verify that the decoded code is executed from its original location (as mapped by the PE Loader). Since our test executable was a GUI application (calc.exe) which inevitably calls GetMessageW, we set a breakpoint on the API and on breakpoint hit we could verify that the original code was decoded and execute from its original location only.

Phase2

Once it is verified that ASPack decoder decodes and execute original code in-place, we wanted to discover the decoder code block. For this we set a break-on-write (ba w4 addr-range in WinDBG) at the base address of the mapping containing the packed code.

Phase3

During Phase1 we noticed that the memory mapping of the decoded .text section is changed to R_X before execution from its original RWX permission as seen in the packed executable. From this we inferred that VirtualProtect must have been used before control is transferred to OEP.

Using this logic we were able to determine the exact point where ASPack loader transfers control to the OEP in the decoded .text section as shown below:

Little trial and error proved that ASPack loader does not seem to have any random or metamorphic component and hence this particular code above is always at an offset 0x420 from the base of .aspack section. The 0x00 above is patched with the computed OEP address at runtime.

Workflow for Automatic Unpacking

• Set breakpoint on entry point
• On breakpoint hit
• Set breakpoint on OEP Caller address (push)
• On breakpoint-hit
• Dump the PE
• Update entry point in PE Optional Header
• TODO: Re-construct IAT

The Tool

The tool is written using the wonderful Metasm Framework, without it a LOT of work would have been required. The core logic is as below:

The full code is available here.

Closing Note: ASPack is not really meant for executable protection as such, it is more of a compression system similar to UPX. For serious requirement, appropriate tools like ASProtect, Themida, VMProtect etc. should be considered.

Advertising:

We will be conducting a 2-days workshop on Reverse Engineering and Malware Analysis at Nullcon 2012 Delhi which includes topic as described above along with other interesting topics like Dynamic Binary Instrumentation, Binary Patch Analysis etc. If you are new to Reverse Engineering, we will try our best to equip you with the basics of x86 ASM and Win32 platform components so that you can benefit from open information available on the internet. Do check out if you are interested.

Reference

http://www.aspack.com/
http://metasm.cr0.org/
http://bitblaze.cs.berkeley.edu/

http://windbg.info/doc/1-common-cmds.html

Keystroke Logging within the Browser

During a recent PenTest, we had to exploit a typical Cross Site Scripting vulnerability in a Rich Internet Application which was making heavy use of Javascript and Ajax to present an almost Desktop like UI. The objective was to prove the severity of XSS vulnerabilities, as the client was not satisfied with a mere /XSS/ popup - even though so many examples exist on the open web.

The result of our effort was to show the client an almost real time keystroke logging by exploiting a Cross Site Scripting vulnerability in his application's console. Although there is a fairly stable Javascript Keylogger available here, we wrote our own as our requirement was quite specific, something as below:


The log transfer code is intentionally removed however it is trivial to transfer the data to any predefined location by injecting iframe or img tag or perhaps even with Ajax and CORS.

Although it is perhaps trivial to write a JavaScript Key Logger and in most cases probably it is unnecessary to use such payload as using an XSS bug a target user's session can itself be hijacked, however it might be useful in certain unconventional cases.

• Consider the case of Rich Internet Applications where the entire UX is Javascript driven and the page is never refreshed or re-loaded. Considering various near real-time use-cases like Chat, Message Ticker, Notification Message etc in the web console, it is sometime desirable to sniff user's activities which otherwise is not recorded by the application. In such a case, it might be useful to have a JS Keylogger payload handy for use with an XSS bug.
• Major browser plugins are written in Javascript and hence one cannot rule out the possibility of infecting plugins with malicious code. Perhaps this is particularly desirable for various banking trojans as a stealth alternative.
• Conventionally a keylogger for Win32 platform is written using the SetWindowsHookEx API. A defensive application such as an AV or an HIPS can reliably detect keyloggers at runtime by inspecting SetWindowsHookEx API. However if the objective is to log keystrokes on the browser only then it might be possible to use Form Grabbing like technique to inject malicious JS code by using eval like APIs.

Nullcon Delhi 2012: RE and Malware Analysis Training

We will be conducting a 2-days Training Session on Reverse Engineering and Malware Analysis in co-operation with Nullcon Team at Nullcon Delhi 2012.

Remote DLL Loader

Sometimes it is required to somehow force a remote process to load an arbitrary DLL via LoadLibrary. The loaded DLL once executed from within the address space of the target process can then perform a wide variety of operation. This can be achieved using AppInit_DLLs registry option for applications which are linked with user32.dll.

However we want a bit more generic solution and that too without modifying anything in the system. The idea is quite simple and perhaps widely used:

• Find or execute the target process and obtain its handle
• Allocate memory in the target process using VirtualAllocEx
• Write a shellcode that performs LoadLibrary("C:\\Our.dll") using WriteProcessMemory
• Execute the shellcode using CreateRemoteThread

Thanks to the excellent Metasm library, building and testing the tool was a matter of less than an hour. The tool can be found here.

Note: The loader shellcode will look for exported function named Init in the DLL and will call it if found after LoadLibrary(..) This allows performing operations which otherwise should not be performed from the DllMain.

The usage is pretty simple: