Internet of Planes: Hacking Millionaires’ Jet Cabins
By
Daniel Martinez
The push to incorporate remote management capabilities into products has swept across a number of industries. A good example of this is the famous Internet of Things (IoT), where modern home devices from crockpots to thermostats can be managed remotely from a tablet or smartphone.
One of the biggest problems associated with this new feature is a lack of security. Unfortunately, nobody is surprised when a new, widespread vulnerability appears in the IoT world.
However, the situation becomes a bit more concerning when similar technologies appear in the aviation sector. Nowadays we can find Cabin Management and In-Flight entertainment systems that can be managed from mobile devices owned by crew members and/or passengers.
The systems I’ve analyzed in the research presented here, are deployed in business jets. The discovered vulnerabilities affect passenger and crew devices.
The Cabin Management System is based on a wireless access point installed onboard the aircraft that provides network connectivity from the mobile devices of passengers and crew members to the cabin server. The Android applications (and their iOS equivalents) for both vendors were developed by Rockwell Collins to manage the available cabin capabilities in the aircraft such as cabin temperature, light intensity and much more.
Bombardier Cabin Control Version 2.2.1 (Last version 1st April) – Arbitrary File Write in SDcard https://youtu.be/_3cqNwwiF9k
Lack of Legitimacy Checking of the Server
Rockwell Collins Venue Cabin Remote Version 2.2.2 – Legit Connectivity AP Emulation https://youtu.be/8QRAlTBOatU
Unencrypted Communications
Based on the vulnerabilities found during the research, an attacker could create the following situations:
Deploy a rogue aircraft access point and write in the devices of the connected clients. This could lead to a full compromise of the device.
Deploy a rogue aircraft access point and capture credentials or application secrets used to get access to protected areas in the application managed by the crew members in the real aircraft access point.
Connect to a real aircraft access point and interact with the cabin devices using the application. This could lead to full access to the cabin capabilities via the application if the attacker gets the password to access protected application menus and create situations of discomfort onboard an aircraft by altering the temperature to a higher or lower value or modifying light intensity, switching off or blinking.
Connect to a real aircraft access point and multicast other server configuration to force the devices that are connected to the network to get a new configuration file, this could lead to some dangerous situations like:
A full compromise of the client’s devices connected to the network.
Create situations of discomfort onboard an aircraft by altering the temperature to a higher or lower value or modifying light intensity, switching off or blinking.
The complete research, including: full systems overview and analysis, vulnerability discoveries with the Android apps, and detailed exploit scenarios, can be found on the Technical Advisory Paper.
In this post I’m going talk about a bug I found a while back in Google’s Chrome browser that allows attackers to bypass the Content Security Policy (CSP). Besides breaking the CSP, the bug also allows attackers a means to ex-filtrate information from inside an SSL/TLS connection. The bug was reported a couple of years back and we got word that the fix is in, so I decided to dust off this blog post and update it so you folks can learn about it.
The CSP is a configuration setting communicated to browsers through HTTP. It allows web servers to whitelist sources for active content to help defend against cross-site scripting. The policy is specified in response to resource fetches or any HTTP transaction in general with the host. Here’s what a common CSP looks like:
As you can see, the header lists attributes you would like to harden against unauthorized sources. It works by inspecting the browser origin that is sourcing active scripts on a document and making sure they match the ruleset published by the web server.
So that’s how CSP works. Now let’s talk about when it doesn’t work and what kind of response it got from the sec research industry. lcamptuf from Google wrote about developing attacks that do dangerous things to your DOM and your page content, despite the presence of a working CSP. Essentially trying to answer this question:
What will attacks look like should this idea actually work the way it is designed?
Among the techniques that came out of this line of questioning was the idea of “dangling content injection,” a brilliant concept that abuses the aggressively best-effort behavior of browsers. In a dangling content injection attack, you inject a broken HTML tag and rely on the browser to complete this tag by interpreting the content around the broken tag as part of the tag. Essentially injecting by forcing the browser to consume page content as part of an HTML tag, image tag, text area, etc.
Initially, this might seem like a mundane and rather harmless way to break a web page’s functionality, but as it turns out, it could result in security problems. It’s easier to grasp this with an example. Below is a page that fell victim to an HTML injection attack:
An image tag is being injected, and the payload looks like this:
Because this <img> tag is broken, Chrome will try to fix it for us by consuming adjacent page content as part of the URL and domain name for the <img> tag. Which, as you guessed, means that Chrome will try to use it to resolve a domain name. The only thing spoiling our fun is the CSP; we need a link here that actually allows the DNS resolution to take place using the page content.
The bug I found involves the behavior of the <link> tag. Specifically, what happens in Chrome when a <link rel=’preload’ href=’[URL]’ /> is encountered. These tags are part of the “sub-resource linking mechanisms” in HTML and allow you to link documents together so they can share common sub-resources such as JavaScript, CSS, fonts etc. You can also have the browser preemptively resolve domain names before a page is loaded, which is what the <preload> links are for!
What does this look like in practice? In the following screenshot you can see the DNS traffic generated by a broken preload link tag I injected into an HTTPS secured page; you might notice some HTML keywords in the DNS names:
There you have it, details that were once safely encrypted behind a TLS stream are flying through the air in unencrypted DNS requests! Probably not how you want your browser to work.
Anyway, that’s it for this one folks. Happy hacking!
Extracting Bluetooth Metadata in an Object’s Memory Using Frida
By
Keith Makan
Here’s a script I wrote to extract information from the Bluetooth metadata in an object’s memory. The script makes use of the Frida instrumentation framework, and I’ll take a little time to explain a simple scripting methodology/thought framework for solving problems with Frida.
Target Android phone (preferably with root permissions)
Getting Started: Your first Script
Frida forwards APIs that wrap Java objects and introduce means to inspect them, modify them, or replace them. This API is implemented in JavaScript, so you have the advantage of anonymous functions and plenty of hook/callback-style API design.
The first useful call you need is Java.perform(function(){}). Here’s an example usage: hello-world.js:
This is essentially a “hello world” Frida Script. We’re passing the setTimeout method in JavaScript for another function, Java.perform, which itself takes a function as an argument. We’re calling the console objects log method and passing it a string; we need to use the setTimeout method because it enables our actions in the JavaScript runtime. We need the Java.perform call because it enables our actions in the Frida Java runtime which inherits and mirrors from the actual runtime we’re targeting on the Android device.
To get it up and running, just grab the Frida server for your device, pop it on the disk and fire off the script from a non-mobile computer (this is essentially the Frida client, since the server runs on the mobile phone):
You should see your terminal spit out a “hello world” string.
Now we can make use of other Java features from within the function to which we pass the Java class in the Frida runtime. We can do stuff like search through loaded classes and pull out an instantiated version of those classes, replace loaded instances with others, and more.
Here’s a quick example showing all of the loaded classes in the current application:
When you run it, it should produce the following output:
In this example, we’re running Frida against the Android media service.
Another cool thing you can do is inspect Bluetooth specific classes. This is where BlueCrawl comes in: it basically searches through all the loaded classes and pulls out those with interesting Bluetooth information. Check out this example, showing all the devices dumped from a Bluetooth scanner app’s memory:
I’ve redacted the MAC addresses since some of these devices might not belong to me. 🙂
BlueCrawl also dumps information about Bluetooth sockets, and can actually show you the type of device and MAC address connected to it:
The current version’s features also include the ability to see:
loaded Bluetoothclasses
loaded BluetoothSocket and BluetoothServerSocket objects
loaded Bluetooth Device objects in memory, as stated above
I kept the features tight and as properly implemented as I could for the first iteration, so while it’s not a swiss army knife just yet, you should try this script for checks to determine whether:
Your Bluetooth spoofing tech is working properly
Apps are secretly scanning for Bluetooth devices
Apps are stealing Bluetooth information
More features are on the way once I get to know Frida a little more and finish some further testing.
Breaking Extreme Networks WingOS: How to Own Millions of Devices Running on Aircrafts, Government, Smart Cities and More
By
Josep Pi Rodriguez
On Sunday, August 12th at 11am PT, I will give a talk at DEF CON 26 explaining how several critical vulnerabilities were found in the embedded operating system WingOS. The talk is entitled, “BreakingExtreme Networks WingOS: How to Own Millions of Devices Running on Aircrafts,Government, Smart Cities and More.” The Wing operating system was originally created by Motorola and nowadays Extreme Networks maintains it. WingOS is running in Motorola, Zebra and Extreme Networks access points and controllers. It is mainly used for WLAN networks.
This research started focusing in one access point widely used by many airlines around the world, which provides Wi-Fi and Internet access to their aircraft’s passengers. After starting to reverse engineer the firmware, I realized that this access point uses the WingOS and this OS is not only used in the aircraft industry, but also in many other industries.
Based on public information, we can see how it is actively used not only by many airlines but also in public places such as the New York City subway, hospitals, hotels, casinos, resorts, mines, smart cities, sea ports, and more. I will share some real-world examples of places where these devices are being used during my talk.
During my talk, besides the introduction of this OS, scenarios and attack surfaces, I will show some examples of critical vulnerabilities that attackers could exploit to completely compromise these devices. Some of these vulnerabilities do not require any kind of authentication, meaning that an attacker — just through the Ethernet connection or Wi-Fi connection — could exploit these issues. Once the devices are compromised, obviously the attacker can compromise the communications from the clients connected to this access point or controller and also launch more effective attacks against those clients. Basically, it is the same idea when an attacker has full control of a router where dozens or hundreds of clients are connected, which can be really dangerous and the possibilities of successful attacks to the clients connected and their communications are really high.
In the case of a controller, we had the same impact but it was even greater. Controllers can control dozens or even hundreds of access points. Some of the vulnerabilities affects the controllers as well, so the attacker could get remote code execution at one controller and then compromise all the access points connected to this controller.
Another interesting and obvious fact from the attacker’s perspective is the following example:
Let’s put us in the New York City subway or in the aircraft scenario. We know that normally these vulnerable devices running WingOS are connected to other assets of the internal network that are not normally reachable from the Internet. Let’s say that an attacker is able to exploit one of the vulnerabilities through the Wi-Fi or Ethernet network. Since the attacker now has code execution at the WingOS device, now the attacker can pivot and try to attack these other assets inside the internal network of the New York City subway or at the aircraft scenario. Obviously, we don’t know for sure what is beyond that, but what is clearly obvious is that this is technically possible and clearly this is also a really juicy entry point for attackers that might want to attack other assets in the internal network of that particular scenario.
During the talk, I will show one exploit that chains several vulnerabilities to get code execution using the Wi-Fi connection that a vulnerable access point provides. After that, we will discuss some conclusions about this research. Hopefully, after this, there will be some lessons learned about security of the WingOS so that it security can improve in the future and millions of devices installed out there will be less exposed to attackers that could do some serious damage to several industries/companies.
Are You Trading Stocks Securely? Exposing Security Flaws in Trading Technologies
By
Alejandro Hernandez
This blog post contains a small portion of the entire analysis. Please refer to the white paper for full details to the research.
Disclaimer
Most of the testing was performed using paper money (demo accounts) provided online by the brokerage houses. Only a few accounts were funded with real money for testing purposes. In the case of commercial platforms, the free trials provided by the brokers were used. Only end-user applications and their direct servers were analyzed. Other backend protocols and related technologies used in exchanges and financial institutions were not tested.
This research is not about High Frequency Trading (HFT), blockchain, or how to get rich overnight.
Introduction
The days of open outcry on trading floors of the NYSE, NASDAQ, and other stock exchanges around the globe are gone. With the advent of electronic trading platforms and networks, the exchange of financial securities now is easier and faster than ever; but this comes with inherent risks.
The valuable information as well as the attack surface and vectors in trading environments are slightly different than those in banking systems.
Brokerage houses offer trading platforms to operate in the market. These applications allow you to do things including, but not limited to:
Fund your account via bank transfers or credit card
Keep track of your available equity and buying power (cash and margin balances)
Monitor your positions (securities you own) and their performance (profit)
Monitor instruments or indexes
Send buy/sell orders
Create alerts or triggers to be executed when certain thresholds are reached
Receive real-time news or video broadcasts
Stay in touch with the trading community through social media and chats
Needless to say, every single item on the previous list must be kept secret and only known by and shown to its owner.
Scope
My analysis started mid-2017 and concluded in July 2018. It encompassed the following platforms; many of them are some of the most used and well-known trading platforms, and some allow cryptocurrency trading:
16 Desktop applications
34 Mobile apps
30 Websites
These platforms are part of the trading solutions provided by the following brokers, which are used by tens of millions of traders. Some brokers offer the three types of platforms, however, in some cases only one or two were reviewed due to certain limitations:
Ally Financial
AvaTrade
Binance
Bitfinex
Bitso
Bittrex
Bloomberg
Capital One
Charles Schwab
Coinbase
easyMarkets
eSignal
ETNA
eToro
E-TRADE
ETX Capital
ExpertOption
Fidelity
Firstrade
FxPro
GBMhomebroker
Grupo BMV
IC Markets
Interactive Brokers
IQ Option
Kraken
com
Merrill Edge
MetaTrader
Net
NinjaTrader
OANDA
Personal Capital
Plus500
Poloniex
Robinhood
Scottrade
TD Ameritrade
TradeStation
Yahoo! Finance
Devices used:
Windows 7 (64-bit)
Windows 10 Home Single (64-bit)
iOS 10.3.3 (iPhone 6) [not jailbroken]
iOS 10.4 (iPhone 6) [not jailbroken]
Android 7.1.1 (Emulator) [rooted]
Basic security controls/features were reviewed that represent just the tip of the iceberg when compared to more exhaustive lists of security checks per platform.
Results
Unfortunately, the results proved to be much worse compared with applications in retail banking. For example, mobile apps for trading are less secure than the personal banking apps reviewed in 2013 and 2015.
Apparently, cybersecurity has not been on the radar of the Financial Services Tech space in charge of developing trading apps. Security researchers have disregarded these technologies as well, probably because of a lack of understanding of money markets.
While testing I noted a basic correlation: the biggest brokers are the ones that invest more in fintech cybersecurity. Their products are more mature in terms of functionality, usability, and security.
Based on my testing results and opinion, the following trading platforms are the most secure:
Broker
Platforms
TD Ameritrade
Web and mobile
Charles Schwab
Web and mobile
Merrill Edge
Web and mobile
MetaTrader 4/5
Desktop and mobile
Yahoo! Finance
Web and mobile
Robinhood
Web and mobile
Bloomberg
Mobile
TradeStation
Mobile
Capital One
Mobile
FxPro cTrader
Desktop
IC Markets cTrader
Desktop
Ally Financial
Web
Personal Capital
Web
Bitfinex
Web and mobile
Coinbase
Web and mobile
Bitso
Web and mobile
The medium- to high-risk vulnerabilities found on the different platforms include full or partial problems with encryption, Denial of Service, authentication, and/or session management problems. Despite the fact that these platforms implement good security features, they also have areas that should be addressed to improve their security.
Following the platforms I consider must improve in terms of security:
Broker
Platforms
Interactive Brokers
Desktop, web and mobile
IQ Option
Desktop, web and mobile
AvaTrade
Desktop and mobile
E-TRADE
Web and mobile
eSignal
Desktop
TD Ameritrade’s Thinkorwim
Desktop
Charles Schwab
Desktop
TradeStation
Desktop
NinjaTrader
Desktop
Fidelity
Web
Firstrade
Web
Plus500
Web
Markets.com
Mobile
Unencrypted Communications
In 9 desktop applications (64%) and in 2 mobile apps (6%), transmitted data unencrypted was observed. Most applications transmit most of the sensitive data in an encrypted way, however, there were some cases where cleartext data could be seen in unencrypted requests.
Among the data seen unencrypted are passwords, balances, portfolio, personal information and other trading-related data. In most cases of unencrypted transmissions, HTTP in plaintext was seen, and in others, old proprietary protocols or other financial protocols such as FIX were used.
Under certain circumstances, an attacker with access to some part of the network, such as the router in a public WiFi, could see and modify information transmitted to and from the trading application. In the trading context, a malicious actor could intercept and alter values, such as the bid or ask prices of an instrument, and cause a user to buy or sell securities based on misleading information.
For example, the follow application uses unencrypted HTTP. In the screenshot, a buy order:
Another interesting example was found in eSignal’s Data Manager. eSignal is a known signal provider and integrates with a wide variety of trading platforms. It acts as a source of market data. During the testing, it was noted that Data Manager authenticates over an unencrypted protocol on the TCP port 2189, apparently developed in 1999.
As can be seen, the copyright states it was developed in 1999 by Data Broadcasting Corporation. Doing a quick search, we found a document from the SEC that states the company changed its name to Interactive Data Corporation, the owners of eSignal. In other words, it looks like it is an in-house development created almost 20 years ago. We could not corroborate this information, though.
The main eSignal login screen also authenticates through a cleartext channel:
FIX is a protocol initiated in 1992 and is one of the industry standard protocols for messaging and trade execution. Currently, it is used by a majority of exchanges and traders. There are guidelines on how to implement it through a secure channel, however, the binary version in cleartext was mostly seen. Tests against the protocol itself were not performed in this analysis.
A broker that supports FIX:
There are some cases where the application encrypts the communication channel, except in certain features. For instance, Interactive Brokers desktop and mobile applications encrypt all the communication, but not that used by iBot, the robot assistant that receives text or voice commands, which sends the instructions to the server embedded in a FIX protocol message in cleartext:
News related to the positions were also observed in plaintext:
Another instance of an application that uses encryption but not for certain channels is this one, Interactive Brokers for Android, where a diagnostics log with sensitive data is sent to the server in a scheduled basis through unencrypted HTTP:
A similar platform that sends everything over HTTPS is IQ Option, but for some reason, it sends duplicate unencrypted HTTP requests to the server disclosing the session cookie.
Others appear to implement their own binary protocols, such as Charles Schwab, however, symbols in watchlists or quoted symbols could be seen in cleartext:
Interactive Brokers supports encryption but by default uses an insecure channel; an inexperienced user who does not know the meaning of “SSL” (Secure Socket Layer) won’t enable it on the login screen and some sensitive data will be sent and received without encryption:
Passwords Stored Unencrypted
In 7 mobile apps (21%) and in 3 desktop applications (21%), the user’s password was stored unencrypted in a configuration file or sent to log files. Local access to the computer or mobile device is required to extract them, though. This access could be either physical or through malware.
In a hypothetical attack scenario, a malicious user could extract a password from the file system or the logging functionality without any in-depth know-how (it’s relatively easily), log in through the web-based trading platform from the brokerage firm, and perform unauthorized actions. They could sell stocks, transfer the money to a newly added bank account, and delete this bank account after the transfer is complete. During testing, I noticed that most web platforms (+75%) support two-factor authentication (2FA), however, it’s not enabled by default, the user must go to the configuration and enable it to receive authorization codes by text messages or email. Hence, if 2FA is not enabled in the account, it’s possible for an attacker, that knows the password already, to link a new bank account and withdraw the money from sold securities.
The following are some instances where passwords are stored locally unencrypted or sent to logs in cleartext:
Base64 is not encryption:
In some cases, the password was sent to the server as a GET parameter, which is also insecure:
One PIN for login and unlocking the app was also seen:
In IQ Option, the password was stored completely unencrypted:
However, in a newer version, the password is encrypted in a configuration file, but is still stored in cleartext in a different file:
Trading and Account Information Stored Unencrypted
In the trading context, operational or strategic data must not be stored unencrypted nor sent to the any log file in cleartext. This sensitive data encompasses values such as personal data, general balances, cash balance, margin balance, net worth, net liquidity, the number of positions, recently quoted symbols, watchlists, buy/sell orders, alerts, equity, buying power, and deposits. Additionally, sensitive technical values such as username, password, session ID, URLs, and cryptographic tokens should not be exposed either.
8 desktop applications (57%) and 15 mobile apps (44%) sent sensitive data in cleartext to log files or stored it unencrypted. Local access to the computer or mobile device is required to extract this data, though. This access could be either physical or through malware.
If these values are somehow leaked, a malicious user could gain insight into users’ net worth and investing strategy by knowing which instruments users have been looking for recently, as well as their balances, positions, watchlists, buying power, etc.
The following screenshots show applications that store sensitive data unencrypted:
Balances:
Investment portfolio:
Buy/sell orders:
Watchlists:
Recently quoted symbols:
Other data:
Trading Programming Languages with DLL Import Capabilities
This is not a bug, it’s a feature. Some trading platforms allow their customers to create their own automated trading robots (a.k.a. expert advisors), indicators, and other plugins. This is achieved through their own programming languages, which in turn are based on other languages, such as C++, C#, or Pascal.
The following are a few of the trading platforms with their own trading language:
MetaTrader: MetaQuotes Language (Based on C++ – Supports DLL imports)
NinjaTrader: NinjaScript (Based on C# – Supports DLL imports)
TradeStation: EasyLanguage (Based on Pascal – Supports DLL imports)
AvaTraceAct: ActFX (Based on Pascal – Does not support OS commands nor DLL imports)
(FxPro/IC Markets) cTrader: Based on C# (OS command and DLL support is unknown)
Nevertheless, some platforms such as MetaTrader warn their customers about the dangers related to DLL imports and advise them to only execute plugins from trusted sources. However, there are Internet tutorials claiming, “to make you rich overnight” with certain trading robots they provide. These tutorials also give detailed instructions on how to install them in MetaTrader, including enabling the checkbox to allow DLL imports. Innocent non-tech savvy traders are likely to enable such controls, since not everyone knows what a DLL file is or what is being imported from it. Dangerous.
Following a malicious Ichimoku indicator that, when loaded into any chart, downloads and executes a backdoor for remote access:
Another basic example is NinjaTrader, which simply allows OS commands through C#’s System.Diagnostics.Process.Start(). In the following screenshot, calc.exe executed from the chart initialization routine:
Denial of Service
Many desktop platforms integrate with other trading software through common TCP/IP sockets. Nevertheless, some common weaknesses are present in the connections handling of such services.
A common error is not implementing a limit of the number of concurrent connections. If there is no limit of concurrent connections on a TCP daemon, applications are susceptible to denial-of-service (DoS) or other type of attacks depending on the nature of the applications.
For example, TD Ameritrade’s Thinkorswim TCP-Orders Server listens on the TCP port 2000 in the localhost interface, and there is no limit for connections nor a waiting time between orders. This leads to the following problems:
Memory leakage since, apparently, the resources assigned to every connection are not freed upon termination.
Continuous order pop-ups (one pop-up per order received through the TCP server) render the application useless.
A NULL pointer dereference is triggered and an error report (.zip file) is created.
Regardless, it listens on the local interface only. There are different ways to reach this port, such as XMLHttpRequest() in JavaScript through a web browser.
Memory leakage could be easily triggered by creating as many connections as possible:
A similar DoS vulnerability due to memory exhaustion was found in eSignal’s Data Manager. eSignal is a known signal provider and integrates with a wide variety of trading platforms. It acts as a source of market data; therefore, availability is the most important asset:
It’s recommended to implement a configuration item to allow the user to control the behavior of the TCP order server, such as controlling the maximum number of orders sent per minute as well as the number of seconds to wait between orders to avoid bottlenecks.
The following capture from Interactive Brokers shows when this countermeasure is implemented properly. No more than 51 users can be connected simultaneously:
Session Still Valid After Logout
Normally, when the logout button is pressed in an app, the session is finished on both sides: server and client. Usually the server deletes the session token from its valid session list and sends a new empty or random value back to the client to clear or overwrite the session token, so the client needs to reauthenticate next time.
In some web platforms such as E-TRADE, Charles Schwab, Fidelity and Yahoo! Finance (Fixed), the session was still valid one hour after clicking the logout button:
Authentication
While most web-based trading platforms support 2FA (+75%), most desktop applications do not implement it to authenticate their users, even when the web-based platform from the same broker supports it.
Nowadays, most modern smartphones support fingerprint-reading, and most trading apps use it to authenticate their customers. Only 8 apps (24%) do not implement this feature.
Unfortunately, using the fingerprint database in the phone has a downside:
Weak Password Policies
Some institutions let the users choose easily guessable passwords. For example:
The lack of a secure password policy increases the chances that a brute-force attack will succeed in compromising user accounts.
In some cases, such as in IQ Option and Markets.com, the password policy validation is implemented on the client-side only, hence, it is possible to intercept a request and send a weak password to the server:
Automatic Logout/Lockout for Idle Sessions
Most web-based platforms logout/lockout the user automatically, but this is not the case for desktop (43%) and mobile apps (25%). This is a security control that forces the user to authenticate again after a period of idle time.
Privacy Mode
This mode protects the customers’ private information from being displayed on the screen in public areas where shoulder-surfing attacks are feasible. Most of the mobile apps, desktop applications, and web platforms do not implement this useful and important feature.
The following images show before and after enabling privacy mode in Thinkorswim for mobile:
Hardcoded Secrets in Code and App Obfuscation
16 Android .apk installers (47%) were easily reverse engineered to human-readable code since they lack of obfuscation. Most Java and .NET-based desktop applications were also reverse-engineered easily. The rest of the applications had medium to high levels of obfuscation, such as Merrill Edge in the next screenshot.
The goal of obfuscation is to conceal the applications purpose (security through obscurity) and logic in order to deter reverse engineering and to make it more difficult.
In the non-obfuscated platforms, there are hardcoded secrets such as cryptographic keys and third-party service partner passwords. This information could allow unauthorized access to other systems that are not under the control of the brokerage houses. For example, a Morningstar.com account (investment research) hardcoded in a Java class:
Interestingly, 14 of the mobile apps (41%) and 4 of the desktop platforms (29%) have traces (hostnames and IPs) about the internal development and testing environments where they were made or tested. Some hostnames are reachable from the Internet and since they’re testing systems they could lack of proper protections.
SSL Certificate Validation
11 of the reviewed mobile apps (32%) do not check the authenticity of the remote endpoint by verifying its SSL certificate; therefore, it’s feasible to perform Man-in-the-Middle (MiTM) attacks to eavesdrop on and tamper with data. Some MiTM attacks require to trick the user into installing a malicious certificate on their phones, though.
The ones that verify the certificate normally do not transmit any data, however, only Charles Schwab allows the user to use the app with the provided certificate:
Lack of Anti-exploitation Mitigations
ASLR randomizes the virtual address space locations of dynamically loaded libraries. DEP disallows the execution of data in the data segment. Stack Canaries are used to identify if the stack has been corrupted. These security features make much more difficult for memory corruption bugs to be exploited and execute arbitrary code.
The majority of the desktop applications do not have these security features enabled in their final releases. In some cases, that these features are only enabled in some components, not the entire application. In other cases, components that handle network connections also lack these flags.
Linux applications have similar protections. IQ Option for Linux does not enforce all of them on certain binaries.
Other Weaknesses
More issues were found in the platforms. For more details, please refer to the white paper.
Statistics
Since a picture is worth a thousand words, consider the following graphs:
For more statistics, please refer to the white paper.
Responsible Disclosure
One of IOActive’s missions is to act responsibly when it comes to vulnerability disclosure. In September 2017 we sent a detailed report to 13 of the brokerage firms whose mobile trading apps presented some of the higher risks vulnerabilities discussed in this paper. More recently, between May and July 2018, we sent additional vulnerability reports to brokerage firms.
As of July 27, 2018, 19 brokers that have medium- or high-risk vulnerabilities in any of their platforms were contacted.
TD Ameritrade and Charles Schwab were the brokers that communicated more with IOActive for resolving the reported issues.
For a table with the current status of the responsible disclosure process, please refer to the white paper.
Conclusions and Recommendations
Trading platforms are less secure than the applications seen in retail banking.
There’s still a long way to go to improve the maturity level of security in trading technologies.
End users should enable all the security mechanisms their platforms offer, such as 2FA and/or biometric authentication and automatic lockout/logout. Also, it’s recommended not to trade while connected to public networks and not to use the same password for other financial services.
Brokerage firms should perform regular internal audits to continuously improve the security of their trading platforms.
Brokerage firms should also offer security guidance in their online education centers.
Developers should analyze their current applications to determine if they suffer from the vulnerabilities described in this paper, and if so, fix them.
Developers should design new, more secure financial software following secure coding practices.
Regulators should encourage brokers to implement safeguards for a better trading environment. They could also create trading-specific guidelines to be followed by the brokerage firms and FinTech companies in charge of creating trading software.
Rating organizations should include security in their reviews.
Side Note
Remember: the stock market is not a casino where you magically get rich overnight. If you lack an understanding of how stocks or other financial instruments work, there is a high risk of losing money quickly. You must understand the market and its purpose before investing.
With nothing left to say, I wish you happy and secure trading!
Discovering and Exploiting a Vulnerability in Android’s Personal Dictionary (CVE-2018-9375)
By
Daniel Kachakil
I was auditing an Android smartphone, and all installed applications were in scope. My preferred approach, when time permits, is to manually inspect as much code as I can. This is how I found a subtle vulnerability that allowed me to interact with a content provider that was supposed to be protected in recent versions of Android: the user’s personal dictionary, which stores the spelling for non-standard words that the user wants to keep.
While in theory access to the user’s personal dictionary should be only granted to privileged accounts, authorized Input Method Editors (IMEs), and spell checkers, there was a way to bypass some of these restrictions, allowing a malicious application to update, delete, or even retrieve all the dictionary’s contents without requiring any permission or user interaction.
This moderate-risk vulnerability, classified as elevation of privilege and fixed on June 2018, affects the following versions of Android: 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0, and 8.1.
User’s Personal Dictionary
Android provides a custom dictionary that can be customized manually or automatically, learning from the user’s typing. This dictionary can be usually accessed from “Settings → Language & keyboard → Personal dictionary” (sometimes under “Advanced” or slightly different options). It may contain sensitive information, such as names, addresses, phone numbers, emails, passwords, commercial brands, unusual words (may include illnesses, medicines, technical jargon, etc.), or even credit card numbers.
A user can also define a shortcut for each word or sentence, so instead of typing your full home address, you can add an entry and simply write the associated shortcut (e.g. “myhome”) for its autocompletion.
Internally, the words are stored in a SQLite database which simply contains a table named “words” (apart from the “android_metadata”). This table’s structure has six columns:
_id (INTEGER, PRIMARY KEY)
word (TEXT)
frequency (INTEGER)
locale (TEXT)
appid (INTEGER)
shortcut (TEXT)
Our main interest will be focused on the “word” column, as it contains the custom words, as its name suggests; however, all remaining columns and tables in the same database would be accessible as well.
Technical Details of the Vulnerability
In older versions of Android, read and write access to the personal dictionary was protected by the following permissions, respectively:
android.permission.READ_USER_DICTIONARY
android.permission.WRITE_USER_DICTIONARY
This is no longer true for newer versions. According to the official documentation1: “Starting on API 23, the user dictionary is only accessible through IME and spellchecker”. The previous permissions were replaced by internal checks so, theoretically, only privileged accounts (such as root and system), the enabled IMEs, and spell checkers could access the personal dictionary content provider (content://user_dictionary/words).
We can check the AOSP code repository and see how in one the changes2, a new private function named canCallerAccessUserDictionary was introduced and was invoked from all the standard query, insert, update, and delete functions in the UserDictionary content provider to prevent unauthorized calls to these functions.
While the change seems to be effective for both query and insert functions, the authorization check happens too late in update and delete, introducing a security vulnerability that allows any application to successfully invoke the affected functions via the exposed content provider, therefore bypassing the misplaced authorization check.
In the following code for the UserDictionaryProvider class3, pay attention to the highlighted fragments and see how the authorization checks are performed after the database would be already altered:
@Override
public int delete(Uri uri, String where, String[] whereArgs) {
SQLiteDatabase db = mOpenHelper.getWritableDatabase();
int count;
switch (sUriMatcher.match(uri)) {
case WORDS:
count = db.delete(USERDICT_TABLE_NAME, where, whereArgs);
break;
case WORD_ID:
String wordId = uri.getPathSegments().get(1);
count = db.delete(USERDICT_TABLE_NAME, Words._ID + "=" + wordId
+ (!TextUtils.isEmpty(where) ? " AND (" + where + ')' : ""), whereArgs);
break;
default:
throw new IllegalArgumentException("Unknown URI " + uri);
}
// Only the enabled IMEs and spell checkers can access this provider.
if (!canCallerAccessUserDictionary()) {
return 0;
}
getContext().getContentResolver().notifyChange(uri, null);
mBackupManager.dataChanged();
return count;
}
@Override
public int update(Uri uri, ContentValues values, String where, String[] whereArgs) {
SQLiteDatabase db = mOpenHelper.getWritableDatabase();
int count;
switch (sUriMatcher.match(uri)) {
case WORDS:
count = db.update(USERDICT_TABLE_NAME, values, where, whereArgs);
break;
case WORD_ID:
String wordId = uri.getPathSegments().get(1);
count = db.update(USERDICT_TABLE_NAME, values, Words._ID + "=" + wordId
+ (!TextUtils.isEmpty(where) ? " AND (" + where + ')' : ""), whereArgs);
break;
default:
throw new IllegalArgumentException("Unknown URI " + uri);
}
// Only the enabled IMEs and spell checkers can access this provider.
if (!canCallerAccessUserDictionary()) {
return 0;
}
getContext().getContentResolver().notifyChange(uri, null);
mBackupManager.dataChanged();
return count;
}
Finally, notice how the AndroidManifest.xml file does not provide any additional protection (e.g. intent filters or permissions) to the explicitly exported content provider:
It is trivial for an attacker to update the content of the user dictionary by invoking code like the following from any malicious application, without the need to ask for any permission:
Both methods (update and delete) are supposed to return the number of affected rows, but in this case (for non-legitimate invocations) they will always return zero, making it slightly more difficult for an attacker to extract or infer any information from the content provider.
At this point, it may appear that this is all we can do from an attacker perspective. While deleting or updating arbitrary entries could be a nuisance for the end user, the most interesting part is accessing personal data.
Even if the query function is not directly affected by this vulnerability, it is still possible to dump the entire contents by exploiting a time-based, side-channel attack. Since the where argument is fully controllable by the attacker, and due to the fact that a successful update of any row takes more time to execute than the same statement when it does not affect any row, the attack described below was proven to be effective.
Simple Proof of Concept
Consider the following code fragment running locally from a malicious application:
ContentValues values = new ContentValues();
values.put(UserDictionary.Words._ID, 1);
long t0 = System.nanoTime();
for (int i=0; i<200; i++) {
getContentResolver().update(UserDictionary.Words.CONTENT_URI, values,
"_id = 1 AND word LIKE 'a%'", null);
}
long t1 = System.nanoTime();
Invoking the very same statement enough times (e.g. 200 times, depending on the device), the time difference (t1-t0) between an SQL condition that evaluates to “true” and the ones that evaluate to “false” will be noticeable, allowing the attacker to extract all the information in the affected database by exploiting a classic time-based, Boolean blind SQL injection attack.
Therefore, if the first user-defined word in the dictionary starts with the letter “a”, the condition will be evaluated to “true” and the code fragment above will take more time to execute (for example, say 5 seconds), compared to the lesser time required when the guess is false (e.g. 2 seconds), since no row will actually be updated in that case. If the guess was wrong, we can then try with “b”, “c”, and so on. If the guess is correct, it means that we know the first character of the word, so we can proceed with the second character using the same technique. Then, we can move forward to the next word and so on until we dump the entire dictionary or any filterable subset of rows and fields.
To avoid altering the database contents, notice how we updated the “_id” column of the retrieved word to match its original value, so the inner idempotent statement will look like the following: UPDATE words SET _id=N WHERE _id=N AND (condition)
If the condition is true, the row with identifier “N” will be updated in a way that doesn’t actually change its identifier, since it will be set to its original value, leaving the row unmodified. This is a non-intrusive way to extract data using the execution time as a side-channel oracle.
Because we can replace the condition above with any sub-select statement, this attack can be extended to query any SQL expression supported in SQLite, such as:
Is the word ‘something’ stored in the dictionary?
Retrieve all 16-character words (e.g. credit card numbers)
Retrieve all words that have a shortcut
Retrieve all words that contain a dot
Real-world Exploitation
The process described above can be fully automated and optimized. I developed a simple Android application to prove its exploitability and test its effectiveness.
The proof-of-concept (PoC) application is based on the assumption that we can blindly update arbitrary rows in the UserDictionary database through the aforementioned content provider. If the inner UPDATE statement affects one or more rows, it will take more time to execute. This is essentially all that we will need in order to infer whether an assumption, in the form of a SQL condition, is evaluated to true or false.
However, since at this initial point we don’t have any information about the content (not even the values of the internal identifiers), instead of iterating through all possible identifier values, we’ll start with the row with the lowest identifier and smash the original value of its “frequency” field to an arbitrary number. This step could be done using different valid approaches.
Because several shared processes will be running at the same time in Android, the total elapsed time for the same invocation will vary between different executions. Also, this execution time will depend on each device’s processing capabilities and performance; however, from a statistical perspective, repeating the same invocation a significant amount of iterations should give us a differentiable measure on average. That’s why we’ll need to adjust the number of iterations per device and current configuration (e.g. while in battery saving mode).
Although I tried with a more complex approach first to determine if a response time should be interpreted as true or false, I ended up implementing a much simpler approach that led to accurate and reliable results. Just repeat the same number of requests that always evaluate to “true” (e.g. “WHERE 1=1”) and “false” (e.g. “WHERE 1=0”) and take the average time as the threshold to differentiate them. Measured times greater than the threshold will be interpreted as true; otherwise, as false. It’s not AI or big data, nor does it use blockchain or the cloud, but the K.I.S.S. principle applies and works!
Once we have a way to differentiate between correct and wrong assumptions, it becomes trivial to dump the entire database. The example described in the previous section is easy to understand, but it isn’t the most efficient way to extract information in general. In our PoC, we’ll use the binary search algorithm4 instead for any numeric query, using the following simple approach:
Determine the number of rows of the table (optional)
SELECT COUNT(*) FROM words
Determine the lowest identifier
SELECT MIN(_id) FROM words
Determine the number of characters of the word with that identifier
SELECT length(word) FROM words WHERE _id=N
Iterate through that word, extracting character by character (in ASCII/Unicode)
SELECT unicode(substr(word, i, 1)) FROM words WHERE _id=N
Determine the lowest identifier which is greater than the one we got and repeat
SELECT MIN(_id) FROM words WHERE _id > N
Remember that we can’t retrieve any numeric or string value directly, so we’ll need to translate these expressions into a set of Boolean queries that we can evaluate to true or false, based on their execution time. This is how the binary search algorithm works. Instead of querying for a number directly, we’ll query: “is it greater than X?” repeatedly, adjusting the value of X in each iteration until we find the correct value after log(n) queries. For instance, if the current value to retrieve is 97, an execution trace of the algorithm will look like the following:
Iteration
Condition
Result
Max
Min
Mid
–
–
–
255
0
127
1
Is N > 127?
No
127
0
63
2
Is N > 63?
Yes
127
63
95
3
Is N > 95?
Yes
127
95
111
4
Is N > 111?
No
111
95
103
5
Is N > 103?
No
103
95
99
6
Is N > 99?
No
99
95
97
7
Is N > 97?
No
97
95
96
8
Is N > 96?
Yes
97
96
96
The Proof-of-Concept Exploitation Tool
The process described above was implemented in a PoC tool, shown below. The source code and compiled APK for this PoC can be accessed from the following GitHub repository: https://github.com/IOActive/AOSP-ExploitUserDictionary
Let’s have a look at its minimalistic user interface and explain its singularities.
The first thing the application does is attempt to access the personal dictionary content provider directly, querying the number of entries. Under normal circumstances (not running as root, etc.), we should not have access. If for any reason we achieve direct access, it doesn’t make sense to exploit anything using a time-based, blind approach, but even in that case, you’ll be welcome to waste your CPU cycles with this PoC instead of mining cryptocurrencies.
As described before, there are only two parameters to adjust:
Initial number of iterations: How many times will the same call be repeated to get a significant time difference.
Minimum time threshold (in milliseconds): How much time will be considered the lowest acceptable value.
Although the current version of the tool will adjust them automatically for us, in the very first stage everything was manual and the tool was simply taking these parameters as they were provided, so this is one of the reasons why these controls exist.
In theory, the larger these numbers are, the better accuracy we’ll get, but the extraction will be slower. If they are smaller, it will run faster, but it’s more likely to obtain inaccurate results. This is why there is a hardcoded minimum of 10 iterations and 200 milliseconds.
If we press the “START” button, the application will start the auto-adjustment of the parameters. First, it will run some queries and discard the results, as the initial ones were usually quite high and not representative. Then, it will execute the initial number of iterations and estimate the corresponding threshold. If the obtained threshold is above the minimum we configured, then it will test the estimated accuracy by running 20 consecutive queries, alternating true and false statements. If the accuracy is not good enough (only one mistake will be allowed), then it will increase the number of iterations and repeat the process a set number of times until the parameters are properly adjusted or give up and exit if the conditions couldn’t be satisfied.
Once the process is started, some controls will be disabled, and we’ll see the current verbose output in the scrollable log window below (also via logcat) where we can see, among other messages, the current row identifier, all SQL subqueries, the total time, and the inferred trueness. The retrieved characters will appear in the upper line as soon as they’re extracted.
Finally, the “UPD” and “DEL” buttons on the right are completely unrelated to the time-based extraction controls, and they simply implement direct calls to the content provider to perform an UPDATE and DELETE, respectively. They were intentionally limited to affect the words starting with “123” only. This was done to avoid accidental deletions of any personal dictionary, so in order to test these methods, we’ll need to add this entry manually, unless we had it already.
Demo
Probably the easiest way to summarize the process is watching the tool in action in the following videos, recorded in a real device.
Additional Considerations
There is usually a gap between theory and practice, so I’d also like to share some of the issues I faced during the design and development of this PoC. First, bear in mind that the tool is simply a quick and dirty PoC. Its main goal was to prove that the exploitation was possible and straightforward to implement, and that’s why it has several limitations and doesn’t follow many of the recommended programming best practices, as it’s not meant to be maintainable, efficient, offer a good user experience, etc.
In the initial stages, I didn’t care about the UI and everything was dumped to the Android log output. When I decided to show the results in the GUI as well, I had to run all the code in a separate thread to avoid blocking the UI thread (which may cause the app to be considered unresponsive and therefore killed by the OS). The accuracy dropped considerably with this simple change, because that thread didn’t have much priority, so I set it to “-20”, which is the maximum allowed priority, and everything worked fine again.
Updating the UI from a separate thread may lead to crashes and it’s generally detected and restricted via runtime exceptions, so in order to show the log messages, I had to invoke them using calls to runOnUiThread. Bear in mind that in a real exploit, there’s no need for a UI at all.
If the personal dictionary is empty, we can’t use any row to force an update, and therefore all queries will take more or less the same time to execute. In this case there’ll be nothing to extract and the tool shouldn’t be able to adjust the parameters and will eventually stop. In some odd cases, it might be randomly calibrated even with an empty database and it will try to extract garbage or pseudo-random data.
In a regular smartphone, the OS will go to sleep mode after a while and the performance will drop considerably, causing the execution time to increase way above the expected values, so all calls would be evaluated as true. This could have been detected and reacted in a different manner, but I simply opted for a simpler solution: I kept the screen turned on and acquired a wake lock via the power manager to prevent the OS from suspending the app. I didn’t bother to release it afterwards, so you’ll have to kill the application if you’re not using it.
Rotating the screen also caused problems, so I forced it to landscape mode only to avoid auto-rotating and to take advantage of the extra width to show each message in a single line.
Once you press the “START” button, some controls will be permanently disabled. If you want to readjust the parameters or run it multiple times, you’ll need to close it and reopen it.
Some external events and executions in parallel (e.g. synchronizing the email, or receiving a push message) may interfere with the application’s behavior, potentially leading to inaccurate results. If that happens, try it again in more stable conditions, such as disabling access to the network or closing all other applications.
The UI doesn’t support internationalization, and it wasn’t designed to extract words in Unicode (although it should be trivial to adapt, it wasn’t my goal for a simple PoC).
It was intentionally limited to extract the first 5 words only, sorted by their internal identifiers.
Remediation
From a source code perspective, the fix is very simple. Just moving the call to check if the caller has permissions to the beginning of the affected functions should be enough to fix the issue. Along with the advisory, we provided Google a patch file with the suggested fix and this was the commit in which they fixed the vulnerability: https://android.googlesource.com/platform/packages/…
Since the issue has been fixed in the official repository, as end users, we’ll have to make sure that our current installed security patch level contains the patch for CVE-2018-9375. For instance, in Google Pixel/Nexus, it was released on June 2018: https://source.android.com/security/bulletin/pixel/2018-06-01
If for any reason it’s not possible to apply an update to your device, consider reviewing the contents of your personal dictionary and make sure it doesn’t contain any sensitive information in the unlikely event the issue becomes actively exploited.
Conclusions
Software development is hard. A single misplaced line may lead to undesirable results. A change that was meant to improve the security and protection of the user’s personal dictionary, making it less accessible, led to the opposite outcome, as it inadvertently allowed access without requiring any specific permission and went unnoticed for almost three years.
Identifying a vulnerability like the one described here can be as easy as reading and understanding the source code, just following the execution flow. Automated tests may help detect this kind of issue at an early stage and prevent them from happening again in further changes, but they aren’t always that easy to implement and maintain.
We also learned how to get the most from a vulnerability that, in principle, only allowed us to destroy or tamper with data blindly, increasing its final impact to an information disclosure that leaked all the data by exploiting a side-channel, time-based attack.
Always think outside the box, and remember: time is one of the most valuable resources. Every nanosecond counts!
It has been a while since I published something about a really broken router. To be honest, it has been a while since I even looked at a router, but let me fix that with this blog post. (more…)
Ransomware attacks have boomed during the last few years, becoming a preferred method for cybercriminals to get monetary profit by encrypting victim information and requiring a ransom to get the information back. The primary ransomware target has always been information. When a victim has no backup of that information, he panics, forced to pay for its return. (more…)
tl;dr: Certslayer allows testing of how an application handles SSL certificates and whether or not it is verifying relevant details on them to prevent MiTM attacks: https://github.com/n3k/CertSlayer.
During application source code reviews, we often find that developers forget to enable all the security checks done over SSL certificates before going to production. Certificate-based authentication is one of the foundations of SSL/TLS, and its purpose is to ensure that a client is communicating with a legitimate server. Thus, if the application isn’t strictly verifying all the relevant details of the certificate presented by a server, it is susceptible to eavesdropping and tampering from any attacker having a suitable position in the network.The following Java code block nullifies all the certificate verification checks:
X509TrustManager local1 = new X509TrustManager()
{
public void checkClientTrusted(X509Certificate[]
paramAnonymousArrayOfX509Certificate,
String paramAnonymousString)
throws CertificateException { }
public void checkServerTrusted(X509Certificate[]
paramAnonymousArrayOfX509Certificate,
String paramAnonymousString)
throws CertificateException { }
public X509Certificate[] getAcceptedIssuers()
{
return null;
}
}
Similarly, the following python code using urllib2 disables SSL verification:
These issues are not hard to spot while reading code, but what about a complete black box approach? Here is where Certslayer comes to the rescue.
How does it work?
Proxy Mode
Certslayer starts a proxy server and monitors for specified domains. Whenever a client makes a request to a targeted domain, the proxy redirects the request to an internal web server, presenting a special certificate as a test-case. If the internal web server receives the request, it means the client accepted the test certificate, and the connection was successful at the TLS level. On the other hand, if the internal web server doesn’t receive a request, it means the client rejected the presented certificate and aborted the connection.
For testing mobile applications, the proxy mode is very useful. All a tester needs to do is install the certificate authority (Certslayer CA) in the phone as trusted and configure the system proxy before running the tool. Simply by using the application, generates requests to its server’s backend which are trapped by the proxy monitor and redirected accordingly to the internal web server. This approach also reveals if there is any sort of certificate pinning in place, as the request will not succeed when a valid certificate signed by the CA gets presented.
A simple way to test in this mode is to configure the browser proxy and navigate to a target domain. For example, the next command will start the proxy mode on port 9090 and will monitor requests to www.ioactive.com:
The error code explains the problem: SEC_ERROR_BAD_SIGNATURE, which matches the first test-case in the list. At this point, Certslayer has already prepared the next test-case in the list. By reloading the page with F5, we get the next result.
At the end, a csv file will generate containing the results of each test-case. The following table summarizes them for this example:
Stand-alone Mode
Proxy mode is not useful when testing a web application or web service that allows fetching resources from a specified endpoint. In most instances, there won’t be a way to install a root CA at the application backend for doing these tests. However, there are applications that include this feature in their design, like, for instance, cloud applications that allow interacting with third party services.
In these scenarios, besides checking for SSRF vulnerabilities, we also need to check if the requester is actually verifying the presented certificate. We do this using Certslayer standalone mode. Standalone mode binds a web server configured with a test-certificate to all network interfaces and waits for connections.
I recently tested a cloud application that allowed installing a root CA to enable interaction with custom SOAP services served over HTTPS. Using the standalone mode, I found the library in use wasn’t correctly checking the certificate common name (CN). To run the test-suite, I registered a temporary DNS name (http://ipq.co/) to my public IP address and ran Certslayer with the following command:
+ Setting up WebServer with Test: Trusted CA Invalid Signature
>> Hit enter for setting the next TestCase
The command initialized standalone mode listening on port 4444. The test certificates then used j22d1i.ipq.co as the CN. After this, I instructed the application to perform the request to my server:
{“status”:500,”title”:”Problem accessing WSDL description”,”detail”:”We couldn’t open a connection to the service (Describe URL: https://j22d1i.ipq.co:4444/). Reason: Signature does not match. Check the availability of the service and try again”}
The connection was refused. The server error described the reason why: the CA signature didn’t match. Hitting enter in the python console made the tool prepare the next test case:
+ Killing previous server
j22d1i.ipq.co,Trusted CA Invalid Signature,Certificate Rejected,Certificate Rejected
+ Setting up WebServer with Test: Signed with CertSlayer CA
>> Hit enter for setting the next TestCase
Here, the connection succeeded because the tool presented a valid certificate signed with Certslayer CA:
Server Response:
{“status”:500,”detail”: “We couldn’t process the WSDL https://j22d1i.ipq.co:4444/. Verify the validity of the WSDL file and that it’s available in the specified location.”}
Certslayer output:
j22d1i.ipq.co,Signed with CertSlayer CA,Certificate Accepted,Certificate Accepted
When the web server is configured with a certificate with a wrong CN, the expected result is that the client will abort the connection. However, this particular application accepted the certificate anyway: + Setting up WebServer with Test: Wrong CNAME
As before, a csv file was generated containing all the test cases with the actual and expected results. For this particular engagement, the result was:
A similar tool exists called tslpretense, the main difference is that, instead of using a proxy to intercept requests to targeted domains, it requires configuring the test runner as a gateway so that all traffic the client generates goes through it. Configuring a gateway host this way is tedious, which is the primary reason Certslayer was created.
Two years ago, we assessed 20 mobile applications that worked with ICS software and hardware. At that time, mobile technologies were widespread, but Internet of Things (IoT) mania was only starting. Our research concluded the combination of SCADA systems and mobile applications had the potential to be a very dangerous and vulnerable cocktail. In the introduction of our paper, we stated “convenience often wins over security. Nowadays, you can monitor (or even control!) your ICS from a brand-new Android [device].”
Today, no one is surprised at the appearance of an IIoT. The idea of putting your logging, monitoring, and even supervisory/control functions in the cloud does not sound as crazy as it did several years ago. If you look at mobile application offerings today, many more ICS- related applications are available than two years ago. Previously, we predicted that the “rapidly growing mobile development environment” would redeem the past sins of SCADA systems. The purpose of our research is to understand how the landscape has evolved and assess the security posture of SCADA systems and mobile applications in this new IIoT era.
SCADA and Mobile Applications ICS infrastructures are heterogeneous by nature. They include several layers, each of which is dedicated to specific tasks. Figure 1 illustrates a typical ICS structure.
Figure 1: Modern ICS infrastructure including mobile apps
Mobile applications reside in several ICS segments and can be grouped into two general families: Local (control room) and Remote.
Local Applications Local applications are installed on devices that connect directly to ICS devices in the field or process layers (over Wi-Fi, Bluetooth, or serial). Remote Applications Remote applications allow engineers to connect to ICS servers using remote channels, like the Internet, VPN-over-Internet, and private cell networks. Typically, they only allow monitoring of the industrial process; however, several applications allow the user to control/supervise the process. Applications of this type include remote SCADA clients, MES clients, and remote alert applications. In comparison to local applications belonging to the control room group, which usually operate in an isolated environment, remote applications are often installed on smartphones that use Internet connections or even on personal devices in organizations that have a BYOD policy. In other words, remote applications are more exposed and face different threats.
Unauthorized physical access to the device or “virtual” access to device data
Communication channel compromise (MiTM)
Application compromise
Table 1 summarizes the threat types.
Table 1: SCADA mobile client threat list
Attack Types
Based on the threats listed above, attacks targeting mobile SCADA applications can be sorted into two groups.
Directly/indirectly influencing an industrial process or industrial network infrastructure
This type of attack could be carried out by sending data that would be carried over to the field segment devices. Various methods could be used to achieve this, including bypassing ACL/ permissions checks, accessing credentials with the required privileges, or bypassing data validation.
Compromising a SCADA operator to unwillingly perform a harmful action on the system
The core idea is for the attacker to create environmental circumstances where a SCADA system operator could make incorrect decisions and trigger alarms or otherwise bring the system into a halt state.
Testing Approach
Similar to the research we conducted two years ago, our analysis and testing approach was based on the OWASP Mobile Top 10 2016. Each application was tested using the following steps:
Perform analysis and fill out the test checklist
Perform client and backend fuzzing
If needed, perform deep analysis with reverse engineering
We did not alter the fuzzing approach since the last iteration of this research. It was discussed in depth in our previous whitepaper, so its description is omitted for brevity.
We improved our test checklist for this assessment. It includes:
Application purpose, type, category, and basic information
Permissions
Password protection
Application intents, exported providers, broadcast services, etc.
Native code
Code obfuscation
Presence of web-based components
Methods of authentication used to communicate with the backend
Correctness of operations with sessions, cookies, and tokens
SSL/TLS connection configuration
XML parser configuration
Backend APIs
Sensitive data handling
HMI project data handling
Secure storage
Other issues
Reviewed Vendors
We analyzed 34 vendors in our research, randomly selecting SCADA application samples from the Google Play Store. We did, however, favor applications for which we were granted access to the backend hardware or software, so that a wider attack surface could be tested.
Additionally, we excluded applications whose most recent update was before June 2015, since they were likely the subject of our previous work. We only retested them if there had been an update during the subsequent two years.
Findings
We identified 147 security issues in the applications and their backends. We classified each issue according to the OWASP Top Ten Mobile risks and added one additional category for backend software bugs.
Table 4 presents the distribution of findings across categories. The “Number of Issues” column reports the number of issues belonging to each category, while the “% of Apps” column reports how many applications have at least one vulnerability belonging to each category.
Table 4. Vulnerabilities statistics
In our white paper, we provide an in-depth analysis of each category, along with examples of the most significant vulnerabilities we identified. Please download the white paper for a deeper analysis of each of the OWASP category findings. Remediation And Best Practices In addition to the well-known recommendations covering the OWASP Top 10 and OWASP Mobile Top 10 2016 risks, there are several actions that could be taken by developers of mobile SCADA clients to further protect their applications and systems. In the following list, we gathered the most important items to consider when developing a mobile SCADA application:
Always keep in mind that your application is a gateway to your ICS systems. This should influence all of your design decisions, including how you handle the inputs you will accept from the application and, more generally, anything that you will accept and send to your ICS system.
Avoid all situations that could leave the SCADA operators in the dark or provide them with misleading information, from silent application crashes to full subverting of HMI projects.
Follow best practices. Consider covering the OWASP Top 10, OWASP Mobile Top 10 2016, and the 24 Deadly Sins of Software Security.
Do not forget to implement unit and functional tests for your application and the backend servers, to cover at a minimum the basic security features, such as authentication and authorization requirements.
Enforce password/PIN validation to protect against threats U1-3. In addition, avoid storing any credentials on the device using unsafe mechanisms (such as in cleartext) and leverage robust and safe storing mechanisms already provided by the Android platform.
Do not store any sensitive data on SD cards or similar partitions without ACLs at all costs Such storage mediums cannot protect your sensitive data.
Provide secrecy and integrity for all HMI project data. This can be achieved by using authenticated encryption and storing the encryption credentials in the secure Android storage, or by deriving the key securely, via a key derivation function (KDF), from the application password.
Encrypt all communication using strong protocols, such as TLS 1.2 with elliptic curves key exchange and signatures and AEAD encryption schemes. Follow best practices, and keep updating your application as best practices evolve. Attacks always get better, and so should your application.
Catch and handle exceptions carefully. If an error cannot be recovered, ensure the application notifies the user and quits gracefully. When logging exceptions, ensure no sensitive information is leaked to log files.
If you are using Web Components in the application, think about preventing client-side injections (e.g., encrypt all communications, validate user input, etc.).
Limit the permissions your application requires to the strict minimum.
Implement obfuscation and anti-tampering protections in your application.
Conclusions Two years have passed since our previous research, and things have continued to evolve. Unfortunately, they have not evolved with robust security in mind, and the landscape is less secure than ever before. In 2015 we found a total of 50 issues in the 20 applications we analyzed and in 2017 we found a staggering 147 issues in the 34 applications we selected. This represents an average increase of 1.6 vulnerabilities per application. We therefore conclude that the growth of IoT in the era of “everything is connected” has not led to improved security for mobile SCADA applications. According to our results, more than 20% of the discovered issues allow attackers to directly misinform operators and/or directly/ indirectly influence the industrial process.
In 2015, we wrote:
SCADA and ICS come to the mobile world recently, but bring old approaches and weaknesses. Hopefully, due to the rapidly developing nature of mobile software, all these problems will soon be gone.
We now concede that we were too optimistic and acknowledge that our previous statement was wrong. Over the past few years, the number of incidents in SCADA systems has increased and the systems become more interesting for attackers every year. Furthermore, widespread implementation of the IoT/IIoT connects more and more mobile devices to ICS networks. Thus, the industry should start to pay attention to the security posture of its SCADA mobile applications, before it is too late. For the complete analysis, please download our white paper here. Acknowledgments
Many thanks to Dmitriy Evdokimov, Gabriel Gonzalez, Pau Oliva, Alfredo Pironti, Ruben Santamarta, and Tao Sauvage for their help during our work on this research.
About Us
Alexander Bolshev
Alexander Bolshev is a Security Consultant for IOActive. He holds a Ph.D. in computer security and works as an assistant professor at Saint-Petersburg State Electrotechnical University. His research interests lie in distributed systems, as well as mobile, hardware, and industrial protocol security. He is the author of several white papers on topics of heuristic intrusion detection methods, Server Side Request Forgery attacks, OLAP systems, and ICS security. He is a frequent presenter at security conferences around the world, including Black Hat USA/EU/UK, ZeroNights, t2.fi, CONFIdence, and S4.
Ivan Yushkevich
Ivan is the information security auditor at Embedi (http://embedi.com). His main area of interest is source code analysis for applications ranging from simple websites to enterprise software. He has vast experience in banking systems and web application penetration testing.
IOActive
IOActive is a comprehensive, high-end information security services firm with a long and established pedigree in delivering elite security services to its customers. Our world-renowned consulting and research teams deliver a portfolio of specialist security services ranging from penetration testing and application code assessment through to semiconductor reverse engineering. Global 500 companies across every industry continue to trust IOActive with their most critical and sensitive security issues. Founded in 1998, IOActive is headquartered in Seattle, USA, with global operations through the Americas, EMEA and Asia Pac regions. Visit for more information. Read the IOActive Labs Research Blog. Follow IOActive on Twitter.
Embedi
Embedi expertise is backed up by extensive experience in security of embedded devices, with special emphasis on attack and exploit prevention. Years of research are the genesis of the software solutions created. Embedi developed a wide range of security products for various types of embedded/smart devices used in different fields of life and industry such as: wearables, smart home, retail environments, automotive, smart buildings, ICS, smart cities, and others. Embedi is headquartered in Berkeley, USA. Visit for more information and follow Embedi on Twitter.
