Problem Impacting the Security of Many Banking Institutions Today:

Computers have become faster over time.  Numerous vulnerabilities have been discovered that can allow for an attacker on your local network to compromise the loading of webpage code such that harmful code can be injected into your browser unbeknown by you.  This additional code can cause the content you receive to be altered maliciously, such that some of the data you receive might be susceptible to interception.  Recently posted exploits allegedly from the CIA and other U.S. government intelligence agencies are now incorporated into automated hacking tools such as Metasploit.  A would-be attacker has an arsenal of tools that can allow for flooding a target and pushing them back to using more hackable encryption suites, such as 3DES.  Financial institutions have historically relied upon DES and later 3DES to secure financial transactions.  Some of the top banks have recognized the problem that exists today with 3DES Encryption suite which is no longer necessary for anyone running Windows 8 or later, or even a recent version of Mac OSX or other smart phone.  At the expense of preventing my grandfather who may be using his Pentium 1 computer running Windows XP from accessing his online banking account, disallowing 3DES makes smart financial sense for U.S. Banks and financial institutions.  An attacker that wants to siphon funds off a bank, need only use showdan.io to identify financial institutions that still allow 3DES, now breakable by consumer grade PCs under certain circumstances I will describe later in more detail.

Other problems I observed have included some financial institutions mixing remote calls to other domains to load social media content and other graphics.  This is undesirable because it introduces the real possibility of code injection and compromising of the secure channel between the client and the server.

Further concerns about the widespread usage of the weak 3DES encryption algorithm include an interesting correlation of a large number of apparently less secure public facing servers accepting the weak 3DES algorithm cipher suite that happen to be located near important U.S. Cities having presumed nuclear launch and defense capabilities.  Specifically, SSH servers using 3DES are of concern, since SSH, also known as secure shell, can allow for a bad guy in North Korea to login to remote server as root, if the cryptographic keys are cracked.  Scary stuff in my opinion, but for this article, I will try to keep the focus on financial institutions.

Some of the Solution:

• Disable 3DES and other Weak Encryption Protocols.
• Hire an outside INFOSEC security auditor to double check your own IT security from the outside in.
• Disable JavaScript on Banking Websites
• Have all website content, including graphics and documents load from the main site, not separate domains
• Do not feed in user generated content from facebook.com or other social media sites which may introduce further cross injection vulnerabilities
• Disallow cross site scripting
• Implement Certification Authority Authorization (CAA) to restrict which Certificate Authorities can issue certificates for a particular domain name

There are many other recommendations I have, but I will save those for another time.

The Problem in more Technical Detail:

What is DES?

DES, known as The Data Encryption Standard, has long been a steadfast technology used to secure payment transactions.   DES uses a 56 bit key size with an additional 8 parity bits to help authenticate the 56 bit key, which totals out to the 64 bit key size.  As computers became more powerful and able to generate lookup tables for keys with only a 56 bit key length, DES was abandoned in favor of 3DES, known as Triple DES.

What is Triple DES?

Triple DES (Triple Data Encryption Algorithm) relies on a series of three DES keys and appears to offer 168 bit key length of protection, but due to the ability for attackers to generate three dimensional lookup tables that have all combinations of the first and third key available in the realm of potential 56 bit key length combinations, something known as the meet-in-the-middle vulnerability arises which reduces the mathematical complexity of cracking the keys exponentially and significantly.  3DES key strength provides only 112 bits of protection.  AES encryption provides a minimum of 128 bits of protection and is a much more secure algorithm, than using multiple 56 bit keys in combination.  AES has largely replaced DES encryption and is now recommended for adoption by the U.S. Federal Government.

3DES Key Options:

There are three Key Options (KO) for Triple DES:  ( source http://csrc.nist.gov/groups/STM/cavp/documents/des/tripledesnewval.html )

1. KO 1: Key 1 ≠ Key 2 ≠ Key 3 (Now susceptible to attack by consumer grade computers if enough data is collected)
2. KO 2: Key 1 = Key 2 = Key 3 Only 56 bit keys – long abandoned
3. KO 3: Key 1 ≠ Key 2 (Key 3 = Key 1 where Key 3 is used for decryption only and Key 1 and 2 which are different are used to encrypt) – Phased out

Key Options 1 and 2 have been expressly forbidden for FIPS compliance, yet KO 1 is still vulnerable under certain circumstances, yet is still in use largely because of the prevalence of legacy payment processing industry solutions reliance on DES or (3DES).   Smart minded financial institutions have ditched this legacy encryption suite, even at the risk of having a few consumer customers complain about not being able to access their account online from their decade plus old computer system.

The 3DES Encryption Algorithm Geek Stuff:

encryptedtext = E_K3(D_K2(E_K1(originaltext)))

Decryption is the opposite:

originaltext = D_K1(E_K2(D_K3(encryptedtext)))

Unfortunately, this encryption method leaves a target vulnerable to a meet-in-the-middle attack.  If a known originaltext pair can be determined by the attacker using various exploit tools widely available, the key pair K1 & K2 can be recovered in 2ⁿ steps [72,057,594,037,927,936 possible values ~ 72 Quadrillion] instead of 2²ⁿ steps (where n=56) expected from the algorithm [5.1922968585348276285304963292201e+33 possible values or about 5 decillion options, which is clearly uncrackable by today’s consumer computing standards].  By using hacker tools and techniques such as javascript injection, a remote attacker can intercept decrypted content and if they achieve success in capturing a pair of decrypted originaltext components, they can then more easily crack the keys using pre generated tables.  This meet-in-the-middle vulnerability effectively reduces the key size and allows to only 112 BITS, and allows cracking of the encryption keys using brute force attacks in combination with the known decrypted text pairs, thereby allowing current consumer grade computers to discover the encryption keys in a couple days time.

Triple DES using Key Option 1 is believed to be secure, UNLESS an attacker uses other known hacking tools such as javascript exploits to collect enough data from the target such that a pair of known originaltext values secured by 3DES are determined.  If that scenario takes place, which might take a few days of data collection from the target, then, 3DES encryption can be defeated.  Eliminating 3DES now at the expense of a small minority of end users not being able to access their online banking will prove to be worth it given the potential for bank losses related to cyber exploits of this vulnerability.

A review of many major financial institutions performed by me today revealed that a good number of banking login pages still are supporting the vulnerable Triple DES encryption protocol, among other more secure cipher suites / protocols.   It would be smart for many financial institutions to abandon support for 3DES, since most end users are able to use TLS AES encryption (much more secure 128 bit key length) protocols to connect to their online banking accounts.  A malicious attacker can perform a protocol downgrade attack against a target, forcing the unknowing victim to use 3DES rather than the more secure encryption protocols.  This could ultimately result in compromising of user credentials which could lead to fraudulent electronic payments and loss of funds.

Several banks that do not appear to be supporting 3DES include: (This is a good thing!)

• cboprf.com
• chase.com
• citigroup.com
• jpmorganchase.com
• PNC.com
• Regions.com
• USBank.com
• wellsfargo.com

Vulnerabilities Due to Using Weak Crypto 3DES Algorithm Largely U.S. Based

A survey of internet facing servers that continue to use 3DES (which is in my opinion completely unnecessary), shows that many web servers are potentially vulnerable to remote exploitation of this vulnerability via SSH (Secure Shell remote connection that allows for someone on the other side of the world, to log in to the server and possibly take root control of the machine).  There are more than 11 Million public facing computers in the world that are using 3DES encryption, around which of 4 million are located in the United States.

Top Cities Using Weak 3DES Crypto All Near U.S. Military Facilities

The top 10 cities in the US that are report servers using 3DES are all near important US assets and military bases, suggesting cyber attacks using compromisable devices using the weak 3DES encryption security suite may be possible by rogue nations such as North Korea:

1. Ashburn, VA 428,808 (Near Dulles International Airport and the U.S. Government Capital in the District of Columbia)
2. Boardman, OR 265,886 (Near Umatilla Army Depot)
3. Los Angeles, CA 184,154 (LAX and near by 61st Air Base Wing, Space and Missile Systems Center in El Segundo, CA)
4. Scottsdale, AZ 181077 (Near Arizona National Guard Military Base)
5. San Jose, CA 152,503 (Near US Defense Department, 63rd Regional Support Command Headquarters and NASA Ames Research Center)
6. Buffalo, NY 109,051 (Near US Defense Department, Buffalo Niagara International Airport and Navy Operational Support Center)
7. Mountain View, CA 93,807  (Near US Defense Department, 63rd Regional Support Command Headquarters and NASA Ames Research Center)
8. Dallas, TX 75,779 (Near Military Entrance Processing Station – Department of Defense Agency and Dallas National Guard Base, Grand Prarie Armed Forces Reserve Complex, Naval Air Station Joint Reserve Base in Fort Worth to the West of Dallas)
9. Clifton, NJ 74,067 (Nestled in between New York city and the Picatinny Arsenal)
10. New York, NY 72,908 (Not Good! Near many airports and presume missile launch sites.)

You can check your own bank to see if they are vulnerable to 3DES attacks by visiting https://www.ssllabs.com and typing your bank domain login URL for a complete scorecard rating of your bank’s security configuration.  If you have concerns, give me a call or drop me an email!  me AT leeneubecker dot com.

Useful Websites with Details on 3DES Vulnerability Follow:

https://www.openssl.org/blog/blog/2016/08/24/sweet32/

https://sweet32.info/

https://nvd.nist.gov/vuln/detail/CVE-2016-2183

https://www.teskalabs.com/blog/teskalabs-bulletin-160826-seacat-sweet32-issue

https://www.us-cert.gov/ncas/bulletins/SB17-058