Security - You’re blindfolded unless you scan for vulnerabilities
“This is a report from a customer project. Here we found several vulnerabilities when scanning a Linux-based device designed for industrial environments.”
Harri Susi, SW Testing & Cyber Security Specialist at Etteplan, is showing us a document that contains a detailed analysis of services provided by an IoT device and how hackers may be able to exploit it. A report like this is the first step towards more secure devices.
It’s obvious that Harri’s presentation is something special. Everyone is ranting about how insecure IoT is, but he goes one step further. He doesn’t want to just feed the hype, he wants to change things.
That’s no small task, because all the talk about insecure IoT is certainly not just empty words. There’s a lot of insecure devices out there, and the reason lies deep in development practices and the business models. Harri is on a mission to change that. And to do that he needs to know how hackers work and think.
Hackers would scan the target company for vulnerable devices, and then investigate them closer to find a way in. Harri found what he was looking for. “Look, there’s an open management protocol. It shouldn’t be needed after release, it was probably opened by the development team for debugging.” That’s an excellent example of an exploitable vulnerability. It’s quite common to forget to remove debugging features or services when shipping the product. And they are often protected with a bad password, if protected at all.
But Harri has good news: “That’s an easy bug to fix, just disable the service.” Yes, some vulnerabilities are hard to fix, some easy. But they all have one thing in common, you can’t fix them if you can’t find them. That’s what makes Harri’s presentation about vulnerability scanning so important. We are really talking about the fundamentals of secure development.
“In this case I used the F-Secure Radar vulnerability scanner. It’s a tool that maps the attack surface.”, Harri continues. This is actually similar to the first steps a hacker would take.
F-Secure Radar. A tool for attack surface mapping.
“Security is not a feature, it’s a mindset”.
That’s an old saying, but very relevant in this context. We are all used to security updates for our computers and phones. But a big part of the IoT-world is different. In this world a product is final when it ships, and the customer’s relation to the vendor ends when the purchase is completed. There’s no maintenance and updates, if it’s broken you throw it away and a buy a new one.
It’s clear that this isn’t a sustainable mindset and business model anymore. Hacked home devices can put personal integrity in jeopardy, and companies’ insecure devices provide an intrusion path for targeted attacks. Harri has a concrete example to demonstrate this. It become painfully obvious in a recent test performed in Etteplan’s lab: “We put a router in the 3G-network but didn’t share its address with anyone. But a hacker managed to find it and install the Tsunami backdoor anyway, in just two weeks.” So it’s no wonder that customers have started to ask for security when purchasing IoT.
Harri mentions another example. Could you imagine that for example a webcam, that usually is installed to increase security, could help hackers steal money from a bank? Yes, this is reported by Interpol. (link: https://www.interpol.int/News-and-media/News/2018/N2018-007 )
But Harri, what should be done to secure IoT? “It’s really not rocket science, all the needed processes already exist in the software industry. We just need to start managing IoT products more like software products.” He’s talking about products’ life-cycle management, especially about how they need to be maintained after release.
Many think about vulnerabilities as programming errors in your own code. You can fight them with quality assurance processes, like testing and code review, and still not find everything. But those errors are not the most important or commonly used by hackers. Most systems are assembled from available components, with only a small portion custom code. It is quite common that unnecessary modules and services are active in the shipping product, like in the previously mentioned example. Or that vulnerabilities are discovered later in a common module that was considered safe when the product shipped. So there is a constant need to re-test the product’s security throughout its lifespan. And to have a secure channel for firmware updates.
You soon realize how futile it is to imagine that you can make a product secure before release. Vulnerabilities are discovered later in a common module that was considered safe when the product shipped.
Now Harri brings the discussion back to the basics, “You are blindfolded without a good toolbox, like vulnerability scanners and fuzzing tools.” The hacker must start by locating weak spots before he can break in. Likewise, the defenders must locate the weak spots before they can be fixed. And that job is futile without the right tools and competence.
But what about resources? Many vendors develop devices with really small teams, and the coders move on to the next project when the device ships. All this talk bout security as a continuous process makes sense, but the investment in time, tools and competence may be hard to implement. Harri has an answer to this problem too, “We can help with that. Just call us at Etteplan and we can show you how to secure your product throughout its life-cycle. We have the tools and competence.”