The truth is that hacking OT devices wasn\u2019t challenging enough. Today, like five years ago, the security in the area is running 10\/15 years behind the traditional IT sector. In a few words:<\/p>\n
- \n
- Almost no data encryption at all\u2026<\/li>\n
- Weak authorization mechanisms\u2026<\/li>\n
- Service misconfigurations everywhere.<\/li>\n<\/ul>\n
I can\u2019t remember a single project in which I was unable to achieve remote code execution, without considering the rest: a whole boat of all kinds of bugs and vulnerabilities. I saw literally no evolution of my skills\/career if I were to continue on that professional path.<\/p>\n
I must admit it! Meanwhile some people have made their fortunes by selling ICS\/IoT vulnerabilities to 0day programs and if I had today to give an advice, I would certainly suggest aspiring and novice bug bounty hunters to focus on this area. However, I continue to prefer targets more difficult to hack. This is a personal choice of course, not a universal truth. Somebody else can very well have fun with OT security. <\/p>\n
RCE everywhere<\/strong><\/h2>\n
RCE everywhere, I said. One of the many devices I tested, fallen into the so-called category of \u201cdata concentrator\u201d. Imagine the place where you live. Probably the electricity you consume is measured by a smart meter installed at your home. The same is for your neighbours. But how does the company sending the bill each month knows how much their customer must pay? Well, your smart meter communicates current consumption and other information to a data concentrator, normally via powerline communication (PLC) or some wireless system. As opposed to smart meters, a data concentrator is located outside of the user domain, usually into a cabin down the street where you live or under a bridge. This device collects the data received and transmits it (via GPRS or more modern units) to a central system in the operator\u2019s data center, where other steps, for example, traffic monitoring or billing, take place.<\/p>\n
As data concentrators are a bit more sophisticated than smart meters, these devices come with the necessary hardware to run a complete operating system (quite often Linux). It means some kind of configuration web interface is of course exposed, along with other network services.<\/p>\n
One day, me and a colleague were engaged to test one of these devices. We found that an undocumented guest<\/kbd> user with default guest<\/kbd> password could authenticate to the web admin interface (port 80) with read-only access rights. The presence of this undocumented user (of which there was no trace neither in the official documentation, nor somewhere else) proved to be enough to totally compromise the device itself.<\/p>\n
It was a classic old-school RCE. In the \u2018change password\u2019 page we just targeted a parameter (password_text<\/kbd>) and placed our shell command after a single quote and a semicolon character (see screenshot below).<\/p>\n
![](\"https:\/\/www.redtimmy.com\/wp-content\/uploads\/2021\/06\/afbeelding.png\")
<\/figure>\nSpecifically we changed the password of the admin<\/kbd> user because it was allowed to ssh into the device. While we analyzed more in depth the web interface of this data concentrator, it was noticed that the issue was systemic. To put it simply, every field where the attacker could insert their own input (regardless if GET or POST parameter) seemed injectable. So we decided to dig more in order to establish the root cause for this bug, which brought us to determine that the flaw was tied to an underlying sanitization function<\/em> that failed to properly filter the user-supplied input<\/p>\n
Basically, in whatever place the application took user input, a function (partially-masked snippet below) inside a CGI script, was called first to process that input:<\/p>\n
![](\"https:\/\/www.redtimmy.com\/wp-content\/uploads\/2021\/06\/afbeelding-1.png\")
<\/figure>\nThe function tried to delimitate the user input between two single quotes. If the URL-encoded representation of one or more single quote characters was present in the user input, the function tried to escape them. But as you know an attacker can bypass the browser and force the submission of single quote characters that are not URL-encoded. This allowed us to break the input string (along with the possibility to use a semicolon \u201c;\u201d) and inject characters interpreted as operating system commands. But there was another level of craziness in the function itself. The eval()<\/kbd> instruction was invoked before the validation of the HTTP parameter\u2019s content occurred, which meant an attacker could remotely execute shell commands by providing whatever name as HTTP parameter \ud83d\ude00<\/p>\n
Exploiting command injections like these is not only something seen with IoT devices. Any web application can be vulnerable to this. We\u2019ll teach you how to find (and exploit) these bugs in modern web applications in our BlackHat course<\/a>.<\/p>\n
It was at that point we realized there was not even the need to authenticate as guest user to exploit this vulnerability. Just an EPIC FAIL of the vendor!<\/p>\n
An embarassing file disclosure bug<\/strong><\/h2>\n
Arbitrary file download is another class of vulnerabilities that web interfaces of data concentrators are commonly affected by. I remember a different device in which the web technology adopted was PHP. It was quite a weird and funny case. There was a function named SanitizeCmdLine()<\/kbd> intended to remove evil characters from a user-supplied string before being executed. For example the pipe \u201c|\u201d <\/kbd>character and the dot-dot \u201c..\u201d<\/kbd> sequence were stripped out of the user input, if present, but a single dot \u201c.\u201d<\/kbd> was not.<\/p>\n
In simple terms, inserting a pipe char in the middle of two dots (like this \u201c.|.\u201d<\/kbd>) would have had the effect to produce, after sanitization, the sequence dot-dot \u201c..\u201d<\/kbd><\/p>\n
But the function SanitizeCmdLine()<\/kbd> was not recursive! So, there was not a second round of sanitization on the resulting dot-dot sequence. Therefore a string like this:<\/p>\n
.|.\/.|.\/.|.\/.|.\/.|.\/some\/file<\/kbd><\/p>\n
would have been transformed like this, after being \u201csanitized<\/em>\u201d:<\/p>\n
..\/..\/..\/..\/..\/some\/file<\/kbd><\/p>\n
For example, the effect of submitting the request below\u2026<\/p>\n
![](\"https:\/\/www.redtimmy.com\/wp-content\/uploads\/2021\/06\/afbeelding-2.png\")
<\/figure>\n\u2026produced a server\u2019s reply that contained the full content of \/etc\/passwd<\/kbd>:<\/p>\n
![](\"https:\/\/www.redtimmy.com\/wp-content\/uploads\/2021\/06\/afbeelding-3.png\")
<\/figure>\nAbsolutely one of the most inventive and original ways to sanitize malicious input I have ever seen!<\/p>\n
The \u201cunhackable\u201d device<\/strong><\/h2>\n
After a series of successes in hacking IoT\/ICS devices, my boss came to me and said the next assignment would have been a tough one: the device to test (another data concentrator) was never hacked in the previous security checks the other companies had performed, and the vendor was of course very happy about that. Their products had the fame to be very secure in the market.<\/p>\n
The first bug I spotted was a simple arbitrary file delete vulnerability. Nothing exceptional yes, but it immediately gave me the feeling that the fame of this device was undeserved.<\/p>\n
![](\"https:\/\/www.redtimmy.com\/wp-content\/uploads\/2021\/06\/afbeelding-4.png\")
<\/figure>\nSoon I discovered the action=delete<\/kbd> string in the screenshot above could be turned to action=download<\/kbd>, which gave me a vanilla arbitrary file download primitive.<\/p>\n
The web console of the data concentrator implemented a feature that allowed a user to get a copy of log files for analysis and troubleshooting purposes, compressed in a zip archive. The archive itself replicated the same internal structure of the data concentrator\u2019s filesystem, which revealed the exact location where sensible resources were stored, like encryption keys, system logs, confidential database files containing electricity consumes with other user details, etc\u2026<\/p>\n
I could grab all these files with my vanilla arbitrary file download bug. Most importantly, inside a system log file, I spotted something like this:<\/p>\n
[\u2026]<\/p>\n
201x-0x-2x_15:59:22.42275 Installed and marked for start: reference:file:\/usr\/lib\/_scape\/jars\/BorderRouter.jar<\/strong> (id#23)<\/p>\n
201x-0x-2x_15:59:22.42526 #2: check reference:file:\/usr\/lib\/_scape\/jars\/CellularModemControl.jar<\/strong><\/p>\n
[\u2026]<\/p>\n
Now that I knew the location of the JAR files that implemented the web application logic, the consequential step was to get all of them (power of the file download bug found) and perform a quick internal code review. By previously walking over the web panel, I had noticed a function through which to configure a PPP tunnel with a remote destination. I decided to investigate the JAR related to that functionality.<\/p>\n
Basically, when a certain web form was filled up, the StartPppd()<\/kbd> method of the class PppConnection()<\/kbd> was invoked with some arbitrary input taken from the form itself, mainly a username and a password. The StartPppd()<\/kbd> method was responsible to build the command string for the system binary pppd<\/kbd>, something like this:<\/p>\n
pppd \/dev\/ttyS0 connect<\/em> \u201cchat -v -s -E -f \/etc\/ppp\/chat-isp\u201d debug logfile \/tmp\/pppd.log [\u2026] user someuser<\/strong> password somepassword<\/strong><\/p>\n
The command string was subsequently executed to prepare and establish the PPP connection. You can see how the issue is evident here. As an attacker we are totally in control of \u201cuser\u201d and \u201cpassword\u201d parameters. We also know quotation marks are allowed in the user-supplied input.<\/p>\n
Additionally, there is a little trick. The option \u201cconnect\u201d can execute shell commands specified between quotation marks. If that option is repeated twice on \u201cpppd\u201d command line, the shell command the binary executes is the one related to the last instance found of the \u201cconnect\u201d option. So, in the specific case, it was enough to submit in the web form:<\/p>\n
- \n
- as \u201cuser<\/kbd>\u201d parameter the string: whatever<\/em><\/li>\n
- as \u201cpassword<\/kbd>\u201d parameter the string: s connect \u201csudo \/bin\/touch \/tmp\/byebye\u201d<\/em><\/li>\n<\/ul>\n
After the form submission, the following \u201cpppd<\/em>\u201d command was constructed:<\/p>\n
pppd \/dev\/ttyS0 connect<\/em> \u201cchat -v -s -E -f \/etc\/ppp\/chat-isp\u201d debug logfile \/tmp\/pppd.log [\u2026] user whatever<\/strong> password s connect \u201csudo \/bin\/touch \/tmp\/byebye\u201d<\/strong><\/p>\n
When the string is finally passed to the shell interpreter, the command sudo \/bin\/touch \/tmp\/byebye<\/kbd> is executed!<\/p>\n
$ ls -al \/tmp<\/strong><\/p>\n
[\u2026]<\/p>\n
-rw-r\u2014\u2013 byebye root root <\/strong>0 Jun 17 14:12<\/p>\n
[\u2026]<\/p>\n
Well, it was the first RCE I spotted by doing code review of the collected JAR files. Potentially there were many more bugs of the same class, but the time I was assigned to for the investigation (1 week) was too short to bring up to the surface other issues. In any case, this assessment marked the end of the \u201cunbeatability<\/em>\u201d of a device considered unhackable, until that moment.<\/p>\n
Conclusion<\/strong><\/h2>\n
There is nothing more left for today, although we have many other stories related to hacking of IoT\/ICS devices that we would like to tell. So probably this will be just one of a series of blog posts about it, and we will see more from Red Timmy in the near future. In the meantime, don\u2019t forget to check out our BlackHat course<\/a> coming up, we\u2019ve got still some spots left!<\/p>\n
- as \u201cpassword<\/kbd>\u201d parameter the string: s connect \u201csudo \/bin\/touch \/tmp\/byebye\u201d<\/em><\/li>\n<\/ul>\n
- as \u201cuser<\/kbd>\u201d parameter the string: whatever<\/em><\/li>\n