Cybersecurity News & Commentary - July 2018

The Source Port is Georgia Tech's monthly cybersecurity newsletter, featuring commentary from its researchers about topics in the news over the past month, what wasn't written between the lines, the big (and sometimes nagging) questions driving our research, and new projects underway.

July 31, 2018
Opinion: Replace Ga.’s Risky Touchscreen Voting Machines

The Georgia State Legislature failed in Spring 2018 to authorize funding for new voting machines, but is expected to consider such a measure again when it reconvenes in January 2019. In the meantime, Secretary of State Brian Kemp created an 18-member commission called "Secure, Accessible and Fair Elections (SAFE)" to recommend Georgia’s next voting system. The Commission includes Georgia Tech Professor Wenke Lee from the School of Computer Science, serving as a cybersecurity technical expert. As the Commission gathers public comment and studies the options, many are offering  opinion about what is, isn't, should, and shouldn't be possible in a new voting system that protects voter privacy and election integrity.


Professor Richard DeMillo: "As the 2016 cyberattacks on U.S. elections continue unabated this election year, most everyone agrees that Georgia’s aging, insecure voting machines must be replaced with a new system to increase public confidence. Georgia legislators tried this spring to authorize purchase of a new system, but the flawed legislation failed. That’s a good thing. It would have made the situation worse, not better.

In the wake of this failure, Secretary of State Brian Kemp formed a blue-ribbon Commission on Secure, Accessible and Fair Elections (SAFE) to study the options for Georgia’s next voting system. In short, the Secretary set up a way for Georgia to dig itself out of its election integrity hole and leapfrog to the front of the pack nationwide. At SAFE’s first meeting, Mr. Kemp sabotaged his own commission. The laudable goal of that meeting was to describe Georgia’s current system. Briefing slides are available online. Not apparent in the published material is a disturbing pattern of giving SAFE false and misleading information. If not corrected, the Commission’s recommendations will be as flawed as other efforts to fix the current system. Here are five egregious examples of such misinformation."

Read DeMillo's complete commentary:


Did VPNFilter Knock on the Door of Critical Infrastructure?

Security Service of Ukraine (SBU) claims to have thwarted an attempted cyberattack on a chemical station that provides chlorine for water and sewage treatment plants throughout Ukraine. The station represents the only one of its kind in Ukraine, making this chlorine plant a prime target for critical infrastructure attacks. The SBU’s strongly worded press release blamed the infamous malware VPNFilter for the event and accused Russia of intentionally orchestrating the infection. The full technical details pertaining to the incident remain unknown.


IISP Analyst Caleb Purcell"With the lack of technical detail represented, the interpretation of these events is left largely to the imagination of the reader. The press release makes the case that the 'process control system and system for detecting signs of emergencies' were directly and intentionally infected by VPNFilter, implying the existence of the malware on industrial control system (ICS) – not just networking – equipment. Taken at face value, this statement signifies a drastic change in what we currently know about VPNFilter and its capabilities.

"The most recent Cisco Talos report maintains that VPNFilter has only been known to infect networking gear and utilizes a module with limited ICS-specific capability, specifically the ability to view – but not modify – Modbus network traffic. In addition to viewing Modbus traffic, the module records limited relevant data – ignoring payloads and instead logging the associated connection metadata (i.e., IPs and ports). Given what we know from this research, the most likely explanation is that VPNFilter was discovered on the chlorine plant’s network, but that the malware did not directly impact any ICS equipment. Regardless, the information gleaned from such an infection could be harnessed by attackers for future, more destructive attacks on this or other similar ICS environments. Perhaps this event is indicative of a new role VPNFilter is destined to play as part of an ever-growing threat to critical infrastructure. With that possibility in mind, we can only hope for the release of the crucial technical details necessary for taking preventative measures."


Lack of LTE Data Integrity Allows Attackers to Control Mobile Connections

Most mobile devices rely on the LTE protocol for high-speed wireless data. A group of security researchers have recently shown that, due to a lack of data integrity protection for user data transmitted over LTE, it is possible for an attacker to alter the data received by an LTE device -- redirecting internet connections from the intended endpoint to one controlled by the attacker. The attack, named "aLTEr," starts by causing the mobile device to connect to an attacker-controlled simulation of the device’s mobile network. The simulated network acts as a "man in the middle" between the mobile device and the legitimate network. Because LTE offers encryption for confidentiality, the attacker cannot directly read the victim’s traffic, but clever tricks allow the attacker to modify DNS replies, thus allowing IP traffic redirection.


IISP Analyst Joel Odom"When people think of encryption, the first thing that usually comes to mind is keeping secrets a secret. While confidentiality is important, data integrity is often more important. For example, I’ve often said that I prefer not to have my personal banking information leaked, but I really care more about the integrity of my bank account than its secrecy.
For the encryption of user data, LTE uses the AES block cipher in a mode called "counter mode" (often abbreviated as AES-CTR). What this means from a practical standpoint is that AES is used to create an unpredictable stream of pseudo-random bits that is mixed with the plaintext (the unencrypted data) using the XOR function. The problem with using AES-CTR is that a bit that is flipped in the ciphertext (the encrypted data) flips the corresponding bit in the plaintext. Computers exchange data in precisely-formatted protocols, so there are realistic cases where it’s easy for an attacker to predict which bits in the ciphertext correspond to protocol bits that the attacker can control for malicious purposes.
Thinking beyond this simple attack on DNS over LTE, consider the cases where distributed infrastructure is controlled using industrial control protocols over LTE. If the control messages rely on LTE’s encryption, an attacker could use this attack to do things like change a message that says “open this valve” to “close this valve.”
I urge protocol engineers to consult with cryptographers when protocols are designed to avoid these kinds of mistakes. Modern cryptography gives us authenticated encryption schemes that protect against attacks on integrity and confidentiality with little added computational overhead. AES-GCM is one example of an encryption scheme that could have been specified instead of AES-CTR to provide integrity protection. I should also mention that protection against replay attacks is important. We can get fancy by requiring more esoteric protections, such as forward secrecy and protection against traffic analysis, but AES-GCM with replay protection is usually good enough.
As the researchers who demonstrated the aLTEr attack point out, mobile applications that properly employ TLS will easily detect the connection problems and will, in the worst case, simply fail to connect. This demonstrates the need for layered protection. The end-to-end principle states that applications should provide their own end-to-end cryptography rather than relying on lower layers to provide link-level protection. Designers of systems that communicate over LTE or any other communication channels that the future may present would be well advised to build standard encryption schemes such as TLS into their applications."