3 min read
The scenarios below are serious, and so we’ve added a series of tests to our tr69_conn_req.tcl module to cover your DUT’s TR-069 security and tests for code injection in TR-069 parameters.
In 2016, a distributed denial of service (DDoS) attack dubbed the “Mirai worm” expanded its reach by exploiting a vulnerability in an exposed Broadband Forum TR-064 service (a deprecated service which we’ve written about here). The attack used a shell injection technique in order to instruct the target to download and run malware turning the target into a DoS participant. The event has sparked a lot of questions about TR-069 security.
A shell injection attack takes advantage of exposed services that pass arguments into a unix based shell. Arguments that aren’t validated for escape characters may instead be executed as shell commands rather than passed along as they should be. For configuration protocols like TR-064 or TR-069, this means that configuration arguments (“parameters”) are being passed to another application, probably to perform the configuration operations. The escaped command is then executed by the operating system.
Since this isn’t necessarily how all TR-064 or TR-069 implementations work, this type of shell injection is not a TR-069 security problem itself, but a weakness in a particular implementation.
As an experiment, we tried this same shell injection attack on TR-069 data model parameters to demonstrate that certain TR-069 implementations may be vulnerable to the same attack. In QA Cafe’s proof of concept exploit, the value of a TR-069 data model parameter is set to a quoted shell command (in our case, “ping”) using a SetParameterValues RPC. When passed to the unix shell, this command is executed:
<cwmp:SetParameterValues>
<ParameterList SOAP-ENC:arrayType="cwmp:ParameterValueStruct[1]">
<ParameterValueStruct>
<Name>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.Name</Name>
<Value xsi:type="xsd:string">`ping -c 2 33d1ec050c320596.not.good`</Value>
</ParameterValueStruct>
</ParameterList>
<ParameterKey>cdrouter</ParameterKey>
</cwmp:SetParameterValues>
In our test, the implementation executed the ping command to domain “33d1ec050c320596.not.good” that was passed into the WANIPConnection.Name parameter of the InternetGatewayDevice:1 data model. This is extremely dangerous, since any arbitrary shell command could be executed here.
You can view a capture of the attack here on CloudShark:
https://www.cloudshark.org/captures/5e15ace66abc?filter=dns%20or%20icmp
While this type of attack must originate from a TR-069 ACS, the idea of a comprised ACS is not beyond the imagination given the sophistication of today’s networking attacks.
The most important thing a vendor or provider can do to prevent these issues is ensure that an implementation does rigorous data validation on the parameters used in any configuration protocol, be it TR-069, SNMP, UPnP or new protocols like NETCONF.
Not to worry – we at QA Cafe are on top of these important issues, and we’ve added a series of tests to our tr60_conn_req.tcl module to cover your DUT’s TR-069 Connection Request security and tests for code injection over TR-069.
