Many Mobile Stock Trading Application Vulnerabilities Discovered

The majority of stock trading has been conducted online for years now through the use of online applications. Customers have been able to transfer funds between banking accounts, track personal buying power, and produce orders to be sold by utilizes the online features. With these convenient online feature, as usual with any feature utilizing the Internet, comes with their associated vulnerabilities. Computer system vulnerabilities are normally a big deal, since those vulnerabilities could be exploited by an attacker to gather sensitive information. Depending on the severity of the vulnerability, sensitive information such as: usernames, passwords, credit card information, and banking information could be revealed to an attacker. In a recent analysis posted on September 26 by IOActive researcher, Alejandro Hernández, found vulnerabilities that would reveal the previously mentioned sensitive information in around 20 of the most popular mobile stock trading applications.

Analysis Background

Picture taken from

According to Hernández, “the latest version of 21 of the most used and well-known mobile trading apps available on the Apple Store and Google Play” were tested for vulnerabilities. He conducted an analysis of these mobile stock trading applications utilizing a stock iPhone 6 version 10.3.3 and an emulated Android version 7.1.1 running as root. He also did not disclose the names of these mobile applications or the names of the companies that own them, since only a few of the associated companies have responded to his email regarding the vulnerabilities and are potentially still vulnerable to being exploited. However, there are 21 online stock trading companies such as: Ally Invest by Ally Financial, Capital One Investing Mobile, Charles Schwab Corporation, DriveWealth, E-Trade, Fidelity Investments, Firstrade Securities, Interactive Brokers, Lightspeed Financial, Merrill Edge by Bank of America, PNC Bank, Robinhood Markets, Scottrade, Suntrust Banks, TD Ameritrade, TradeStation, US Bank, USAA, The Vanguard Group, WellsTrade by Wells Fargo, and Zions Direct.

Discovered Vulnerabilities

Upon concluding his analysis of the mobile stock trading vulnerabilities, Hernández discovered that some applications had credentials stored in plaintext, established an insecure connection, had poor authentication and session management, privacy, data validation, root detection, and hardcoded secrets in their source code.

Plaintext Credentials

Four of the applications stored the username and password to the stock trading account in plaintext. This was within an unencrypted XML file or the log history console. An attacker would need physical access to the victim’s smartphone in order to view this information, so it could be a big problem if someone lost their phone and had auto lock disabled. If an attacker were to gain the login credentials, they could sell stocks, transfer money to a newly added bank account, or delete the bank account after a transfer is complete.

Insecure Communication

Two applications used unencrypted network channels (HTTP) to transmit and receive data sent and received, and around 10 of 20 applications that actually used an encrypted channel (HTTPS) did not verify the Certification Authority (CA) of a Secure Sockets Layer (SSL) certificate via SSL pinning. An attacker could take advantage of this by conducting a Man in the Middle (MitM) attack where they intercept and modify bidding or selling prices of an item or sending false information. These applications had SSL disabled by default, which a customer would not know to turn on for security.

Authentication and Session Management

Hernández also discovered that five applications did not implement the biometric fingerprint-reading authentication. This feature would make a customer’s online stock trading more secure, since their particular fingerprint would be required to authorize any sensitive feature. He also discovered that the applications had a maximum password length of 12 characters. The analysis did not mention if the password length required any special characters or not, but it is a general rule of thumb to be required to create a 16 character password containing at least 1 uppercase, 1 lowercase, 1 special character, and 1 number to be considered a secure password. This is especially relevant for these applications, since it processes transactions directly from the customer’s bank account. The applications also only required a single-factor authentication in order to logon to their account, as opposed to having a secure two-factor authentication method like a text message value and password.

Privacy Mode

One of the 21 applications supported privacy mode, which would prevent a person from shoulder-surfing to gather a victims sensitive information. The remaining 20 applications had information, such as a credit card number appear in plaintext on their screen display. Another privacy flaw Hernández discovered was that an attacker only needs to know the victim’s email address linked to their stock trading account to retrieve a snapshot of their account containing their finances.

Client-side Data Validation

Around ten applications had their web view configured to accept and execute JavaScript code. This could allow an attacker to conduct a Cross-site Scripting (XSS) attack to generate fake login pages to gather victim usernames and passwords to steal money.

Root Detection

Again, Hernández found that the same application that had privacy mode enabled also had root detection enabled. Usually, Android devices normally run as a general user, instead of root. If a user is running an application with administrative privileges (root), then they will be able to authorize any incoming or outgoing request.

Hardcoded Secrets in Code and App Obfuscation

Six Android application installers were also discovered to be easily reverse engineered to view code that a human can read. Hernández found cryptographic keys and passwords to third-party partner by doing so. He also found that ten of the applications had internal hostnames and IP address of development and testing environments where application was created.


IOActive Alejandro Hernández Analysis:

Online Brokerage List:

Stock Trading Application Vulnerability Articles: