Team82 Blog / 4 min read
Progress is not inevitable—and within cybersecurity, it’s often well-earned.
For automation companies, medical device makers, manufacturers of connected devices, and many others, progress requires an investment of time, people, and money to ensure the safety of their products, and consequently, the reliability of services that enable our way of life.
After six of Team82’s biannual analyses of publicly disclosed vulnerabilities, we can say that things may be finally trending in the right direction, and indeed, progress is on the horizon. Today, we published the State of XIoT Security Report 2H 2022, which shows that since hitting a peak during the first six months of 2021, the number of published vulnerabilities is dropping while in parallel, the number of disclosures attributed to internal research and product security teams continue to climb.
Have researchers and vendors found all the low-hanging fruit as it relates to vulnerabilities in OT and IoT? Hardly. Our last three reports include the top three totals of published disclosures since our analyses began in 2020. But we are seeing the fruits of vendors’ and researchers’ labor in the steadily growing number of disclosures sourced to internal research and product security teams.
In fact, for the first time, the number of published disclosures attributed to vendors’ internal security teams tops those of disclosures from independent researchers and third-party companies.
All of this matters because cyber-physical systems deliver the services and things that enable our way of life. The food we eat, the water we drink, the energy that heats our homes and powers our devices, all rely on computer code somewhere. These direct links to outcomes in the physical world is putting a harsher spotlight on cybersecurity than ever before.
In this report, Team82 provides a contextual analysis of the vulnerabilities published during the second half of 2022. We’ll look at the numbers in OT, IoT, and IoMT, what they mean, and provide insights on recommended actions that you can take within your enterprise.
Let’s look at some of the top trends from our dataset.
Of the 688 published during 2H 2022, you can see here that 231 were disclosed by internal vendor research organizations, such as product security teams. That is an 82% increase over the 2H 2021 total of 127.
Third-party companies, meanwhile, accounted for 211 published disclosures during the second half of last year, while independent researchers disclosed 141 vulnerabilities.
There has been a sharp increase since 2020 in vendor self-disclosures, which could be an indication that cyber-physical systems security is being prioritized by automation companies, IoT, and medical device makers. The fact that more vendors are looking for, and finding, more vulnerabilities in their own products leads to a safer ecosystem for users in critical industries.
There is also a trickle-down of security being built in natively as new products are developed, tested, and sent out into the market. These numbers may also correlate to the drop in external researchers finding vulnerabilities; the drop in the number of published vulnerabilities attributed to independent researchers could also be an offshoot of the weakening global economy. Research isn’t necessarily a revenue-generating operation, and white-hats may prioritize other areas in a lagging economy.
While the numbers of published vulnerabilities may be dipping, the same cannot be said for their criticality and potential impact. As demonstrated below, most of the published vulnerabilities in 2H 2022 are scored either high or critical. The 110 critical vulnerabilities from the 2H 2021 is the second highest total from Team82’s six reports.
Exploitable vulnerabilities in our dataset could lead to a number of serious impacts, affecting the availability, reliability, and safety of connected cyber-physical systems. The top 3 impacts include: unauthorized code execution, denial of service, and bypasses of security mechanisms.
Published vulnerabilities involving OT software and firmware dominate the 2H 2022 dataset at 74%, dwarfing the 8% of combined IoT and IoMT vulnerabilities. IoT vulnerabilities dropped from 15% of our dataset in the 1H of 2022 to 4% of the vulnerabilities.
We see a continuing trend of a large majority of OT security issues uncovered at Level 3 of the Purdue Model for ICS, the operations management level.
At this level of the Purdue reference model we find devices that manage production workflows, including devices such as Historian servers and databases that collect and store process information and relay it to field devices at Levels 2 and 1, as well as the DMZ. Attacks at this level can also impact not only the OT network, but also the corporate network.
Most of the vulnerabilities at Level 3 are software-based, which are traditionally more within vendor product security teams and third-party researchers. As you can see in the next section, the remediation numbers for software vulnerabilities lines up with this assertion.
The good news is that the number of published OT vulnerabilities with partial or no remediation is dwarfed in the 2H 2022 by the availability of full remediations via software patches or firmware updates.
CWE-749 Exposed Dangerous Method or Function
When user authentication is not enabled the shell can execute commands with the highest privileges. Red Lion SixTRAK and VersaTRAK Series RTUs with authenticated users enabled (UDR-A) any Sixnet UDR message will meet an authentication challenge over UDP/IP. When the same message comes over TCP/IP the RTU will simply accept the message with no authentication challenge.
CVSS V3: 10
CWE-288: Authentication Bypass Using an Alternative Path or Channel
Red Lion SixTRAK and VersaTRAK Series RTUs with authenticated users enabled (UDR-A) any Sixnet UDR message will meet an authentication challenge over UDP/IP. When the same message is received over TCP/IP the RTU will simply accept the message with no authentication challenge.
CVSS V3: 10
The vulnerability is caused by the using deprecated deserialization functions and/or classes such as BinaryFormatter in the zenon internal graphic utility DLLs.
CVSS V3: 6.3
The vulnerability is caused by the default directory permissions for the Zenon Projects directory in the engineering studio default workspace. By allowing access to all the users on the system, the attacker may alter the zenon project itself to load arbitrary zenon projects in the zenon runtime.
CVSS V3: 5.9
Code Execution through overwriting service executable in utilities directory. The vulnerability is caused by the weakly configured default directory permission for the ABB Utilities directory.
CVSS V3: 7.0