w00tsec.blogspot.com - tg862

w00tsec: tg862

W00tsec.blogspot.com Spined HTML

w00tsec: tg862 w00tsec embedded device & webapp hacking Showing posts with label tg862. Show all posts Showing posts with label tg862. Show all posts Monday, September 12, 2016 LuaBot: Malware targeting subscription modems During mid-2015 I disclosed some vulnerabilities well-expressed multiple ARRIS subscription modems. I wrote a blogpost well-nigh ARRIS' nested backstairs and detailed some of my subscription modem research during the 2015 edition from NullByte Security Conference. CERT/CC released the Vulnerability Note VU#419568 and it got lots of media coverage. I did not provide any POC's during that time considering I was pretty sure that those vulnerabilities were hands wormable... And guess what? Someone is urgently exploiting those devices since May/2016. The malware targets Puma 5 (ARM/Big Endian) subscription modems, including the ARRIS TG862 family. The infection happens in multiple stages and the dropper is very similar to many worldwide worm that targets embedded devices from multiple architectures. The final stage is an ARMEB version from the LuaBot Malware. The ARMEL version from the LuaBot Malware was dissected on a blogpost from Malware Must Die, but this specific ARMEB was still unknown/undetected for the time being. The malware was initially sent to VirusTotal on 2016-05-26 and it still has a 0/0 detection rate.SubscriptionModem Security and ARRIS Backdoors Before we go any further, if you want to learn well-nigh subscription modem security, grab the slides from my talk "HackingSubscriptionModems: The Later Years". The talk covers many aspects of the technology used to manage subscription modems, how the data is protected, how the ISPs upgrade the firmwares and so on. https://github.com/bmaia/slides/raw/master/nullbyte_2015-hacking_cable_modems_the_later_years.pdf Pay special sustentation to the slide #86: I received some reports that malware creators are remotely exploiting those devices in order to dump the modem's configuration and steal private certificates. Some users moreover reported that those certificates are stuff sold for bitcoin to modem cloners all virtually the world. The report from Malware Must Die! also points that the LuaBot is stuff used for flooding/DDoS attacks. Exploit and Initial Infection Luabot malware is part of a worthier botnet targeting embedded devices from multiple architectures. After verifying some infected systems, I noticed that most subscription modems were compromised by a writ injection in the restricted CLI wieldy via the ARRIS Password of The Day Backdoor. Telnet honeypots like the one from nothink.org have been logging these exploit attempts for some time. They are logging many attempts to bruteforce the username "system" and the password "ping ; sh", but they're, in fact, commands used to escape from the restricted ARRIS telnet shell. The initial dropper is created by echoing shell commands to the terminal to create a standard ARM ELF. I have navigate compiled and uploaded a few debugging tools to my cross-utils repository, including gdbserver, strace and tcpdump. I moreover happen to have a vulnerable ARRIS TG862 so I can perform dynamic wringer in a controlled environment. If you run the dropper using strace to monitor the network syscalls, you can see the initial connection attempt: ./strace -v -s 9999 -e poll,select,connect,recvfrom,sendto -o network.txt ./mw/drop connect(6, {sa_family=AF_INET, sin_port=htons(4446), sin_addr=inet_addr("46.148.18.122")}, 16) = -1 ENODEV (No such device) The writ is a simple download and exec ARMEB shellcode. The malicious IP 46.148.18.122 is known for bruteforcing SSH servers and trying to exploit Linksys router writ injections in the wild. After downloading the second stage malware, the script will reverberate the pursuit string: reverberate -e 61\\\\\\x30ck3r This pattern is particularly interesting considering it is quite similar to the one reported by ProtectWise while Observing Large-Scale Router Exploit Attempts: cmd=cd /var/tmp && reverberate -ne \\x3610cker > 610cker.txt && cat 610cker.txt The second stage binary ".nttpd" (MD5 c867d00e4ed65a4ae91ee65ee00271c7) performs some internal checks and creates iptables rules allowing remote wangle from very specific subnets and blocking external wangle to ports 8080, 80, 433, 23 and 22: These rules woodcut external exploit attempts to ARRIS services/backdoors, restricting wangle to networks controlled by the attacker. After setting up the rules, two spare binaries were transferred/started by the attacker. The first one, .sox.rslv (889100a188a42369fd93e7010f7c654b) is a simple DNS query tool based on udns 0.4. The other binary, .sox (4b8c0ec8b36c6bf679b3afcc6f54442a), sets the device's DNS servers to 8.8.8.8 and 8.8.4.4 and provides multiple tunneling functionalities including SOCKS/proxy, DNS and IPv6. Parts of the lawmaking resembles some shadowsocks-libev functionalities and there's an interesting reference to the whrq[.]net domain, which seems to be used as a dnscrypt gateway: All these binaries are used as auxiliary tools for the LuaBot's final stage, arm_puma5 (061b03f8911c41ad18f417223840bce0), which seems to be selectively installed on vulnerable subscription modems. UPDATE: According to this interview with the supposed malware author, "reversers usually get it wrong and say there’s some modules for my bot, but those unquestionably are other bots, some routers are infected with several bots at once. My bot never had any binary modules and unchangingly is one big elf file and sometimes only small <1kb size dropper" Final Stage: LuaBot The malware's final stage is a 716KB ARMEB ELF binary, statically linked, stripped and compiled using the same Puma5 toolchain as the one I made misogynist on my cross-utils repository. If we use strace to perform a dynamic wringer we can see the greetings from the bot's tragedian and the megacosm of a mutex (bbot_mutex_202613). Then the bot will start listening on port 11833 (TCP) and will try to contact the writ and tenancy server at  80.87.205.92. In order to understand how the malware works, let's mix some transmission and dynamic analysis. Time to analyse the binary using IDA Pro and... Reversing stripped binaries The binaries are stripped and IDA Pro's F.L.I.R.T. didn't recognize standard function calls for our ARMEB binary. Instead of spending hours manually reviewing the code, we can use @matalaz's diaphora diffing plugin to port all the symbols. First, we need to export the symbols from uClibC's Puma5 toolchain. Download the prebuilt toolchain here and unshut the library "armeb-linux\ti-puma5\lib\libuClibc-0.9.29.so" using IDA Pro.SegregateFile/Script File (Alt+F7), load diaphora.py, select a location to Export IDA Database to SQLite, mark "Export only non-IDA generated functions" and hit OK. When it finishes, tropical the current IDA database and unshut the binary arm_puma5. Rerun the diaphora.py script and now segregate a SQLite database to unequal against: After a while, it will show various tabs with all the unmatched functions in both databases, as well as the "Best", "Partial" and "Unreliable" matches tabs. Browse the "Best matches" tab, right click on the list and select "Import *all* functions" and segregate not to relaunch the diffing process when it finishes. Now throne to the "Partial matches" tab, delete everything with a low ratio (I removed everything unelevated 0.8), right click in the list and select "Import all data for sub_* function": The IDA strings window exhibit lots of information related to the Lua scripting language. For this reason, I moreover cross-compiled Lua to ARMEB, loaded the "lua" binary into IDA Pro and repeated the diffing process with diaphora: We're scrutinizingly washed-up now. If you google for some debug messages present on the code, you can find a deleted Pastebin that was cached by Google. I downloaded the C lawmaking (evsocketlib.c), created some dummy structs for everything that wasn't included there and cross-compiled it to ARMEB too. And now what? Diffing then =) Reversing the malware is way increasingly legible now. There's builtin Lua interpreter and some native lawmaking related to event sockets. The list of the botnet commands is stored at 0x8274: bot_daemonize, rsa_verify, sha1, fork, exec, wait_pid, pipe, evsocket, ed25519, dnsparser, struct, lpeg, evserver, evtimer and lfs: The bot starts by setting up the Lua environment, unpacks the lawmaking and then forks, waiting for instructions from theWritandTenancyserver. The malware tragedian packed the lua source lawmaking as a GZIP blob, making the unshortened reversing job easier for us, as we don't have to deal with Lua Bytecode. The hulk at 0xA40B8 contains a standard GZ header with the last modified timestamp from 2016-04-18 17:35:34: Another easy way to unpack the lua lawmaking is to nail the binary to your favorite debugger (gef, of course) and dump the process memory (heap). First, reprinting gdbserver to the subscription modem, run the malware (arm_puma5) and nail the debugger to the respective PID: ./gdbserver --multi localhost:12345 --attach 1058 Then, start gef/GDB and nail it to the running server: gdb-multiarch -q set tracery arm set endian big set follow-fork-mode child gef-remote 192.168.100.1:12345 Lastly, list the memory regions and dump the heap: vmmap dump memory arm_puma5-heap.mem 0x000c3000 0x000df000 That's it, now you have the full source lawmaking from the LuaBot: The LuaBot source lawmaking is well-balanced of several modules: The bot settings, including the DNS recurser and the CnC settings are hardcoded: The lawmaking is really well documented and it includes proxy checking functions and a masscan log parser: Bot tragedian is seeding random with /dev/urandom (crypgtographers rejoice): LuaBot integrates an embedded JavaScript engine and executes scripts signed with the author's RSA key: Meterpreter is so 2000's, the V7 JavaScript interpreter is named shiterpreter: There's a tricky function named checkanus.penetrate_sucuri, on what seems to be some sort of shirk for Sucuri's Denial of Service (DDoS) Protection: LuaBot has its own lua resolver function for DNS queries: Most of the bot capabilities are in line with the ones described on the Malware Must Die! blogpost. It's interesting to note that the IPs from the CnC server and iptables rules don't overlap, probably considering they're using variegated environments for variegated bot families (or they were simply updated). I did not analise the remote botnet structure, but the modular tideway and the interoperability of the malware indicates that there's a professional and ongoing effort. Conclusion The analysed malware doesn't have any persistence mechanism to survive reboots. It wouldn't try to reflash the firmware or modify volatile partitions (NVRAM for example), but the first stage payload restricts remote wangle to the device using custom iptables rules. This is a quite interesting tideway considering they can quickly masscan the Internet and woodcut external wangle to those IoT devices and selectively infect them using the final stage payloads. On 2015, when I initially reported well-nigh the ARRIS backdoors, there were over 600.000 vulnerable ARRIS devices exposed on the Internet and 490.000 of them had telnet services enabled: If we perform the same query nowadays (September/2016) we can see that the number of exposed devices was reduced to approximately 35.000: I know that the media coverage and the security bulletins contributed to that, but I wonder how much of those devices were infected and had external wangle restricted by some sort of malware... The upper number of Linux devices with Internet-facing legalistic interfaces, the use of proprietary Backdoors, the lack of firmware updates and the ease to craft IoT exploits make them easy targets for online criminals. IoT botnets are rhadamanthine a thing: manufacturers have to start towers secure and reliable products, ISPs need to start shipping updated devices/firmwares and the final user has to alimony his home devices patched/secured. We need to find largest ways to detect, woodcut and contain this new trend. Approaches like the one from SENRIO can help ISPs and Enterprises to have a largest visibility of their IoT ecosystems. Large scale firmware wringer can moreover contribute and provide a largest understanding of the security issues for those devices. Indicators of Compromise (IOCs) LuaBot ARMEB Binaries: waif (5deb17c660de9d449675ab32048756ed) .nttpd (c867d00e4ed65a4ae91ee65ee00271c7) .sox (4b8c0ec8b36c6bf679b3afcc6f54442a) .sox.rslv (889100a188a42369fd93e7010f7c654b) .arm_puma5 (061b03f8911c41ad18f417223840bce0) GCC Toolchains: GCC: (Buildroot 2015.02-git-00879-g9ff11e0) 4.8.4 GCC: (GNU) 4.2.0 TI-Puma5 20100224 Dropper and CnC IPs: 46.148.18.122 80.87.205.92 IP Ranges whitelisted by the Attacker: 46.148.18.0/24 185.56.30.0/24 217.79.182.0/24 85.114.135.0/24 95.213.143.0/24 185.53.8.0/24 Posted by Bernardo Rodrigues at 12:08 PM 5 comments: Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest Labels: arris, subscription modem, elf, lua, malware, reversing, tg862 Thursday, November 19, 2015 ARRISSubscriptionModem has aBackstairsin theBackstairsA couple of months ago, some friends invited me to requite a talk at NullByte Security Conference. I started to study well-nigh some embedded device junk hacking hot topics and decided to talk well-nigh subscription modem security. Braden Thomas keynoted at Infiltrate 2015 discussing well-nigh Practical Attacks on DOCSIS so, yeah, subscription modem hacking is still mainstream. On November 21st I'll be at Salvador speaking on "Hacking subscription modems: The Later Years". It's not a talk well-nigh theft of service and getting self-ruling Internet access. I'll focus on the security of the subscription modems, the technology used to manage them, how the data is protected and how the ISPs upgrade the firmwares. Spoiler Alert: everything's really really bad. Securing subscription modems is increasingly difficult than other embedded devices because, on most cases, you can’t segregate your own device/firmware and software updates are scrutinizingly entirely controlled by your ISP. While researching on the subject, I found a previously undisclosed backstairs on ARRIS subscription modems, well-expressed many of their devices including TG862A, TG862G, DG860A. As of this writing, Shodan searches indicate that the backstairs affects over 600.000 externally wieldy hosts and the vendor did not state whether it's going to fix it yet. ARRIS Backdoors ARRIS SOHO-grade subscription modems contain an undocumented library (libarris_password.so) that acts as a backdoor, permitting privileged logins using a custom password. The pursuit files load the backstairs library on ARRIS TG862A Firmware TS0705125D_031115_MODEL_862_GW (released on 2015): /usr/sbin/arris_init /usr/sbin/dimclient /usr/sbin/docsis_mac_manager /usr/sbin/ggncs /usr/sbin/gw_api /usr/sbin/mini_cli /usr/sbin/pacm_snmp_agent /usr/sbin/snmp_agent_cm /usr/www/cgi-bin/adv_pwd_cgi /usr/www/cgi-bin/tech_support_cgi ARRIS password of the day is a remote backstairs known since 2009. It uses a DES encoded seed (set by the ISP using the arrisCmDoc30AccessClientSeed MIB) to generate a daily backstairs password. The default seed is MPSJKMDHAI and guess what - many ISPs won't scarecrow waffly it at all. The backstairs worth can be used to enable Telnet and SSH remotely via the subconscious HTTPLegalisticinterface "http://192.168.100.1/cgi-bin/tech_support_cgi" or via custom SNMP MIBs. The default password for the SSH user 'root' is 'arris'. When you wangle the telnet session or demonstrate over SSH, the system spawns the 'mini_cli' shell asking for the backstairs password. When you log using the password of the day, you are redirected to a restricted technician shell ('/usr/sbin/cli') Restricted shells are ;restricted In order to understand how the backstairs works, I built an Puma5 toolchain (ARMEB) and navigate compiled some useful tools like strace, tcpdump and gdbserver. I hosted them on my Github, get them here: - https://github.com/bmaia/cross-utils/tree/master/armeb While analyzing the backstairs library and the restricted shells, I found an interesting lawmaking on the hallmark check: Yes, they put a backstairs in the backstairs (Joel from Dlink is sure to be envy). The undocumented backstairs password is based on the last five digits from the modem's serial number. You get a full busybox shell when you log on the Telnet/SSH session using these passwords. The vendor asked not to unroll details well-nigh the password generation algorithm. I'm really relieved knowing that those villainous guys from Metasploit won't be worldly-wise to reverse this in a timely manner. Vulnerability, Disclosure and Marketing Of course, we need a logo so the media can report well-nigh this with fancy graphs as well as vendors could distribute customized t-shits at Blackhat. What I like most well-nigh lcamtuf is how visionary he is. While people were still writing dumb fuzzers, he wrote AFL performed a detailed Technical wringer of Qualys' GHOST. Based on his analysis, I hired a couple of marketing specialists to find out the weightier way to unroll the ARRIS backdoor. What do we have here? - Multiple backdoors permitting full remote wangle to ARRISSubscriptionmodems - An wangle key that is generated based on theSubscriptionmodem's serial number After a thoughtful analysis, the marketing committee well-considered w00tsec members to write a Keygen. In order to write a Keygen, we need a leet ascii art and a tomfool chiptune. The chosen font was ROYAFNT1.TDF, from the legendary versifier Roy/SAC and the chiptune is Toilet Story 5, by Ghidorah. Here's the POC (make sure you turn the sound on): Conclusion I reported these flaws to CERT/CC on 2015-09-13 but we didn't receive much feedback from the vendor. CERT/CC was very helpful and responsive (10/10 would unroll again!). I was asked not to release the POCs immediately so I'm going to wait for the vendor to "fix" the issue. CERT/CC set a disclosure policy of 45 days long ago. They waited for increasingly than 65 days for them to "fix" it but ARRIS didn't remove the backdoors in a timely manner. Someone needs to update the Responsible Disclosure RFC and include a note describing that vendors shall lose disclosure points whenever they plant a backstairs on the device (ARRIS modems have a third backstairs too, trammels the ConsoleCowboys Blog). I'm pretty sure bad guys had been exploiting flaws on these devices for some time (just search for ARRIS DNS on Twitter, for example). We need increasingly people bypassing EULAs and reversing end-user software and firmware. If you haven't heard well-nigh the Firmware.RE, trammels them right now. A broader view on firmwares is not only beneficial, but necessary to discover new vulnerabilities and backdoors, correlating variegated device families and showing how vulnerabilities reappear wideness variegated products. To all the vendors out there, I would like to finish this post by quoting @daveitel: Posted by Bernardo Rodrigues at 11:07 AM 168 comments: Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest Labels: arris, backdoor, subscription modem, firmware, nullbyte, tg862 Older Posts Home Subscribe to: Posts (Atom) ABOUT ME Bernardo Rodrigues Twitter @bernardomr Blog Archive ▼  2018 (1) ▼  April (1) Abusing MySQL LOCAL INFILE to read vendee files ►  2016 (2) ►  September (1) ►  March (1) ►  2015 (6) ►  November (1) ►  October (2) ►  September (1) ►  February (2) ►  2014 (7) ►  November (1) ►  October (1) ►  August (1) ►  July (2) ►  March (1) ►  February (1) ►  2013 (5) ►  December (1) ►  November (1) ►  September (1) ►  August (2) Links TheGoonies CTF BlahCat 4 Lyfe ADS ADS Picture Window theme. Powered by Blogger.