Endpoint //

Privacy

1/11/2018
08:00 AM
Connect Directly
Google+
Twitter
RSS
E-Mail
100%
0%

Vulnerable Mobile Apps: The Next ICS/SCADA Cyber Threat

Researchers find nearly 150 vulnerabilities in SCADA mobile apps downloadable from Google Play.

As if ICS/SCADA networks weren't a juicy enough target, now those networks face a new generation of threats via mobile apps.

Researchers Alexander Bolshev, a security consultant with IOActive, and Ivan Yushkevich, information security auditor for Embedi, randomly selected 34 Android mobile apps from the Google Play store from third-party developers and well-known ICS/SCADA vendors to check for security vulnerabilities: they found 147 security flaws that could be exploited to disrupt or sabotage an industrial process or network infrastructure.

The pair in 2015 had conducted a similar but more cursory study of 20 mobile apps, where they rooted out 50 security weaknesses. They decided to revisit their research this time but at a deeper level, with more rigorous testing of software and hardware, conducting back-end fuzzing and reverse-engineering, and mapping their findings to OWASP's Top 10 Mobile Security Risks.

"They tore them [the apps] apart looking for bugs, and compared the bugs to the previous" research, says Jason Larsen, principal security consultant at IOActive. "The rate of bugs had increased over the past three years. You'd think with higher quality software, the bug rate would go down, but it went up."

Some 59% of the apps had insecure authorization controls and 47% employed insecure data storage. "About one-third had problems with insecure communications, and either lacked encryption or had incorrect implementations of encryption," Bolshev says. "This is pretty scary."

Attackers could exploit the flaws in several ways, according to the researchers. First, if an attacker had physical access to the mobile device and app, he or she could extract the SD card, for example, and embed an exploit on the card and then reinsert it into the device. "They would need just one or two minutes to extract the card … and put it back. Most apps store data insecurely, and there's no data integrity or strong encryption," he says.

Second, an attacker could wage a man-in-the-middle attack between the mobile app and the back-end system. "Thirty-eight percent of the apps have insecure communications. So if an attacker could somehow [perform] man-in-the-middle between the app and backend, it could compromise the app," Bolshev says.

A rogue WiFi or VPN channel could be compromised to perform such an attack, according to the research, or an attacker could also compromise the application itself. An attacker could alter a SCADA operator's view of a pressure gauge, for example. "They could show an invalid picture of the system" status, for example, Bolshev explains. "It could [be altered] to show there's a problem when there isn't," which could result in physical or monetary damage to the plant.

Android in the Plant?

To date, most mobile ICS/SCADA apps deployed in plants are trials or with limited functions, Larsen says.

If running Android apps in a sensitive ICS/SCADA environment seems counterintuitive security-wise, consider the business side of the equation. Part of the motivation for going to mobile apps is pure economic pressure.

"Overall there is an active push by manufacturers and other industrial controls users to be more efficient and to reduce headcount costs. As such, there is a motivation by the users and the ICS vendors to build applications that allow for remote access to ICS systems/components, respond to alarms, etc.," says Ernie Hayden, founder and principal of 443 Consulting LLC. That has meant pressure to push apps to market without proper security assessment and evaluation, he notes.

"Hence, and sadly, vulnerabilities are discovered after the remote devices are installed and used in the field," Hayden says.

ICS/SCADA mobile app vendors don't have the proper policies and procedures in place for secure mobile software development given the market pressures to crank out the apps, according to IOActive's Larsen. "Most [mobile apps] are being outsourced and they don't have that rigor in it yet. In general, code is getting worse and not better."

The researchers did not disclose which apps contained which vulns, and say they alerted app vendors whose products were affected. Among the apps vendors whose software the researchers tested were BACmove, Cybrotech, IDEA-Teknik, Schneider Electric SE, ICONICS, Siemens AG, and TeslaSCADA.

Bolshev declined to reveal any specifics on what they found or not in specific vendor apps but says: "If a vendor is taking care of overall security, it also takes care of its mobile app security from what we saw."

While most of the solution lies with app developers upping their secure development game, the researchers say ICS/SCADA plants need to carefully deploy mobile apps. "I'd recommend if you want to integrate mobile into OT, pen-test it" first, Bolshev says. "Then you can make the decision to integrate it or not."

Larsen says mobile apps will become more mainstream in industrial networks in the next few years. "Everyone tried to fight WiFi on laptops, and now everyone has it now," he says, and mobile apps are also inevitable in those networks.

Related Content:

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
What We Talk About When We Talk About Risk
Jack Jones, Chairman, FAIR Institute,  7/11/2018
Ticketmaster Breach Part of Massive Payment Card Hacking Campaign
Jai Vijayan, Freelance writer,  7/10/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14084
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for MKCB, an Ethereum token. If the owner sets the value of sellPrice to a large number in setPrices() then the "amount * sellPrice" will cause an integer overflow in sell().
CVE-2018-14085
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for UserWallet 0x0a7bca9FB7AfF26c6ED8029BB6f0F5D291587c42, an Ethereum token. First, suppose that the owner adds the evil contract address to his sweepers. The evil contract looks like this: contract Exploit { uint public start; function swe...
CVE-2018-14086
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for SingaporeCoinOrigin (SCO), an Ethereum token. The contract has an integer overflow. If the owner sets the value of sellPrice to a large number in setPrices() then the "amount * sellPrice" will cause an integer overflow in sell(...
CVE-2018-14087
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for EUC (EUC), an Ethereum token. The contract has an integer overflow. If the owner sets the value of buyPrice to a large number in setPrices() then the "msg.value * buyPrice" will cause an integer overflow in the fallback functio...
CVE-2018-14088
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for STeX White List (STE(WL)), an Ethereum token. The contract has an integer overflow. If the owner sets the value of amount to a large number then the "amount * 1000000000000000" will cause an integer overflow in withdrawToFounde...