Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

6/21/2010
05:32 PM
George V. Hulme
George V. Hulme
Commentary
50%
50%

Stock Manipulation Botnet Surfaces

A Belgian federal investigation into an electronic bank account heist reveals a sophisticated attack designed to manipulate stock prices, a Belgian newspaper reported over the weekend.

A Belgian federal investigation into an electronic bank account heist reveals a sophisticated attack designed to manipulate stock prices, a Belgian newspaper reported over the weekend.This news report in the Belgian newspaper De Tijd described a highly-targeted botnet that was designed to infiltrate software trading platforms. According to the story, and I'm relying on a Google translation for this, authorities said there were 20 Belgian victims who were infected, and the cyber-thieves used those accounts to manipulate share prices and profit about 100,000 Euros.

The attacks were targeted at these investors, and the code was custom written, according to the story. The infections and the centralized control over the botnet made it possible for the botmaster to time all of the infected systems to buy or sell shares concurrently. This attack is another example of just how sophisticated cyber attacks have become, and how useless traditional anti-virus systems are in combating modern threats.

Many security experts aren't offering viable answers to these problems. In response to the attack, a Trend Micro blog in Europe suggests each banking transaction be verified to stop such attacks:

. . . from conversations with a local journalist today it seems that many Belgian banks (in fact most banks globally) are still only offering classical two-factor authentication aimed at authenticating the user rather than the transaction. While this kind of technology would certainly thwart this bot in its current form it is not impossible to defeat. As I have previously blogged banking malware has already evolved to the stage where it can overcome multiple factor user authentication.

With this in mind it is vital that any improvment (sic) in online banking security should verify individual transactions rather than simply authenticate the user. The authentication token itself must be capable of accepting direct input relating to the content or the value of the transaction. This can then be verified by both parties and cannot be modified by the malicious "man in the browser".

I'm not sure what the majority of banks in Europe are doing to authenticate users. Most online financial systems here in the U.S. still rely on single factor authentication (username/password). I am quite sure, however, most stock traders wouldn't want their trades to be vetted by some algorithm or other form of approval. It's yet another hoop to jump and additional friction between the trader and the execution of the trade.

In addition, the security mistakes made here don't appear to be the fault of the banks, rather the fault of the stock traders themselves: somehow their systems got infected with these bots and were then permitted to execute the rogue trades.

The insidious fact is, as technology stands today, these types of attacks can affect anyone. All it takes is visiting an infected blog or news Web site and it is possible for attackers to inject the malware on end user systems. It's not yet been made public how the stock traders became infected - but infected web sites frequented by traders, or highly targeted phishing e-mails with the attack software attached are reasonable assumptions.

What's the average user to do? My advice is to establish a dedicated system for banking - and don't visit any other web sites or do any other functions on that system. Period. One could also create highly secure virtual machines dedicated to banking and financial services, and revert back to a trusted safe image every day.

Not a convenient answer: but until we get control over the security of the Web and web browsers it just may be the most secure.

For my security and business observations throughout the day, consider following me on Twitter.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Cybersecurity Industry: It's Time to Stop the Victim Blame Game
Jessica Smith, Senior Vice President, The Crypsis Group,  2/25/2020
Google Adds More Security Features Via Chronicle Division
Robert Lemos, Contributing Writer,  2/25/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9431
PUBLISHED: 2020-02-27
In Wireshark 3.2.0 to 3.2.1, 3.0.0 to 3.0.8, and 2.6.0 to 2.6.14, the LTE RRC dissector could leak memory. This was addressed in epan/dissectors/packet-lte-rrc.c by adjusting certain append operations.
CVE-2020-9432
PUBLISHED: 2020-02-27
openssl_x509_check_host in lua-openssl 0.7.7-1 mishandles X.509 certificate validation because it uses lua_pushboolean for certain non-boolean return values.
CVE-2020-9433
PUBLISHED: 2020-02-27
openssl_x509_check_email in lua-openssl 0.7.7-1 mishandles X.509 certificate validation because it uses lua_pushboolean for certain non-boolean return values.
CVE-2020-9434
PUBLISHED: 2020-02-27
openssl_x509_check_ip_asc in lua-openssl 0.7.7-1 mishandles X.509 certificate validation because it uses lua_pushboolean for certain non-boolean return values.
CVE-2020-6383
PUBLISHED: 2020-02-27
Type confusion in V8 in Google Chrome prior to 80.0.3987.116 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.