In this blog post, we cover the main security issues found on the ioLogik, and describe the process for reverse engineering the firmware and analyzing the embedded device for potential bugs and vulnerabilities.
The MOXA ioLogik E1242 industrial Ethernet remote I/O comes with two switched Ethernet ports with Modbus/TCP slave, EtherNet/IP scanner mode and RESTful API for IIoT applications support.
Reverse Engineering the firmware
First of all, let’s check if the firmware is signed and encrypted.
Indeed, the firmware is not encrypted and definitely there are some strings of interest. The first one is eCos, which is the name of comparatively rare operating system for embedded platforms. RomFS prompting of the file system somewhere nearby.
The last few strings are also interesting and demonstrate SNMP passwords, such as “public”, “admin”, “user”, “private”. We noticed that there are lots of HTML strings as well which could be interesting for our further analysis.
Let’s have a look if binwalk could help here:
As mentioned above there is a file system which is claimed itself as RomFS. However, it is not that RomFS which is usually implemented in embedded devices. eCos is known as an open source OS. There is an interesting file in can be found there mk_romfs.c which has the magic number of the FS where 0x526f6d2e is actually string "Rom."
However there is no such strings in firmware. However, in careful investigation the reversed string can be found ".moR" and apart from it, there is no more changes in FS structure.
The unpacker from now on can be found here: https://github.com/rotenkatz/ecos_romfs_unpacker
Technical Deep Dive
The embedded file system has been unpacked and the source code looks much better now. The first file which attracts my attention is password.htm of course.
Interesting part, that there is a JS script which sets actually md5 hash of password to cookie. There is a limit on password’s length which is 8 characters.
So now, it is clear that the brute-force attack, session hijacking, password recovery are not a big deal with this device. Moreover, there is a huge file named valid.js, which is actually injected everywhere, and has all validations kinds of validation scripts inside.
From this point, we can start suspecting that there is no server side validation on the device which needs to be validated first.
In essence, the ecos is an application which starts directly when device is on. It handles all the working loop and all the communications. It has all its utilities pre-built in monolithic code. As result, we can try to decompile it and see what is it inside the server side.
From documentation it is known that MOXA is compatible with ARM instructions. Therefore we should use ARM little-endian in this case.
The assembler looks good, and readable, however there is something wrong and must be fixed. There is a problem with strings, which are actually broken. It means that the file offset is not correct in this case.
If we calculate the difference between broken strings and their ends it would be clear that the offset should be 0x20. In the result, strings looks much more better.
We can find how actually server works, and yes, it can be confirmed that it is the server. In fact just takes from the cookie MoxaPass and static ChallID and compare it with XORed MD5 hashes from its memory. So stealing cookies would be enough and it contains valid password.
For the full picture, lets have a look on the changing password script. As we know, the logic is actually on client side.
Now let’s find the code on server side:
Also, it can be found, that SNMP actually accepts not only public, and private key phrases but a little bit more (admin, user, private, public).
Of course, if you already have access to device, it is easy to get current password. Surprisingly it can be found in backup config in Clear Text!
Several issues affecting the MOXA ioLogik E1200 series were discovered, ranging from application and network configuration to information disclosure which demonstrates a lack of security development practices for this device.
All of the findings we have described in this post are detailed in Applied Risk Security Advisories at http://www.applied-risk.com/labs/advisories.
These issues were discovered by Alexandru Ariciu, ICS/SCADA security researcher at Applied Risk, and this advisory was prepared in accordance with Applied Risk disclosure policy.
May 26, 2016: Initial Contact to the vendor by Applied Risk
May 30, 2016: Vendor acknowledged receipt of vulnerabilities
June 29, 2016: Vendor released first patch, vulnerabilities not fixed
August 4, 2016: Details disclosed to ICS-CERT (Report number ICS-VU-240049)
August 16, 2016: Vendor release second patch, some vulnerabilities fixed
September 30, 2016: Vendor released third patch, all vulnerabilities fixed