Cybersecurity News & Commentary - May 2017

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

May 1, 2017


Active Cyber Defense Certainty Act, or "Hack Back" Law, Under Consideration 

Rep. Tom Graves (R-Ga.) organized a gathering of information security business and academic leaders in Atlanta on May 1 to collect opinions about discussion draft legislation that would allow victims of cyberattacks to “hack back” into networks not their own. The legislation -- the Active Cyber Defense Certainty Act (or AC-DC) -- aims to give individuals more power to identify and stop cyberattackers, his office says. A "victim" would be defined as one who has been hit with a "persistent unauthorized intrusion." Although it would allow victims to disrupt suspected cyberattacks, the draft prohibits information destruction, physical injury, or creating threats to public health or safety during the course of a "hack back."

IISP Analyst Yacin Nadji: Hacking back" is not a new concept, but this draft has helped revive the discussion around the issue. When I was a Ph.D. student, I worked briefly with some companies to identify ways to respond to distributed denial of service (DDoS) attackers. In this case, the companies knew of a DDoS that was headed their way within minutes and they wanted to eliminate or mitigate the damage actively, rather than just wait and react defensively.

This proposal is different, however, in that it only considers victims to be those who have machines that are persistently compromised. This covers most of what one would consider to be a compromise, but does not include transient attacks like DDoS. While I like using "hacking back" to determine if criminal activity is taking place (and the AC-DC acronym), the problems of potential misattribution and collateral damage -- or lack of established actors to perform the "hack back" correctly -- make the existing draft problematic.

First, the attribution problem here is a catch-22: To know which machines to hack back, attribution must be performed, but to perform the hack back, attribution must be already done to comply with the proposed law. What happens when the hack back reveals the "attacker's machine" is not actually owned by the attacker? Furthermore, what constitutes proof of ownership? It is well known that attackers use "stepping stones," or compromised machines for C&C servers, routing points, or dropsites, while continuing to allow their benign activity. Who owns these machines in the eyes of this draft? Disrupting the unauthorized activity must be done carefully if it is not to simultaneously cause a legitimate business financial damages—say lost revenue—just because they happened to have been compromised, or co-located with unsavory Internet miscreants. Without reliable attribution and controls for limiting collateral damage, the current form may cause more harm than good.

Second, the bill currently allows any victim to "hack back," but ignores the potential consequences of them doing it wrong. Let's return to the compromised host example where a naive attacker leaves the very vulnerability they used to gain access unpatched. An industrious employee of the victim organization realizes this and hacks back; now what? First, does the employee know what information is relevant to law enforcement officers (LEO) looking to prosecute cyber criminals? Second, what if the intrusion alerts the attacker that something is amiss, giving them time to clean up their tracks and make subsequent LEO action more difficult or impossible? Leaving the question of "who hacks the hackers?" unanswered may simply make LEO investigations even harder. The draft makes it clear that active measures can be taken "by, or at the direction of, a victim" but it isn't clear that just because one is a victim that they are prepared or equipped to perform — or lead — an active cyber retaliation effort. Furthermore, a great deal of information that can assist in legal action can be provided by the company without hacking back, such as financial damages, lost intellectual property, and logs from the compromised hosts within their network. Often, this information is enough for LEO to obtain warrants to seize the machines that would be hacked back as a response.

There are reasons to perform more active measures, but we cannot open this Pandora's box without the proper safeguards in place. My concrete recommendations to improve the bill are:

  • provide more clear definitions for "the computer of an attacker;"
  • require the establishment of a consortium of experts that will coordinate with LEO to assess if a "hack back" will yield useful and admissible evidence to pursue legal action as well as perform the active investigation, and
  • develop a more thorough list actions that cannot be performed, e.g., undue financial damage to co-located organizations and businesses.

Personally, I think a more prudent course is to improve the ability for LEO to do their job well. This includes research in automated attribution, estimating financial damages incurred from compromises, and speeding up the process of seizing machines when they are implicated in cyber crime. As it stands, open-ended laws permitting "hack backs" may only complicate matters in the long run.”


Agency Identified for Regulatory Oversight of IoT Security

The Electronic Privacy Information Center (EPIC) urged Congress to reauthorize and expand the National Telecommunications & Information Administration (NTIA) to include oversight of Internet of Things (IoT) devices in connected households. In an open letter, EPIC put forward a case that the soon-to-be ubiquitous, always-on nature of internet connectivity in the household makes regulatory oversight a necessity. The NTIA met in late April to review its own assessment of existing IoT security standards. NTIA reports in its findings that "Consumers of these new types of devices and capabilities need to be protected from vulnerabilities and security related exposures" and documents an inventory of current best practices. The desired outcome is that Congress will authorize NTIA to have a central role in ensuring that security and privacy are built into IoT devices -- replacing what is currently haphazard or absent management by other agencies in this area.

IISP Analyst Stone Tillotson: "If the NTIA becomes armed with a congressional mandate to oversee IoT security, we can step a little more gingerly into a world where smart devices are driving our appliances and locking our doors. The almost breakneck speed of adoption has come with little emphasis on security, and it hasn't gone unnoticed by cybercriminals and cyberspies. Regulating security and penalizing non-compliance won't end the problem of corrupt (and corruptible) devices, but cutting off, hampering, and delaying the spread of malware can have much the same effect in the cyber world as it does with real-world infections: slower growth and time to understand the problem. After all, if there is no Patient Zero, there is no pandemic.”


Echo Look Adds New Creepiness Factor to IoT Insecurity

A new IoT device by Amazon combines the digital assistance smarts of Alexa with a camera. Amazon's "Echo Look" proposes to offer the convenience of a smart shopper that can photograph you in your home and recommend outfits for your physique by recording audio, images and your shopping preferences. Consumers will trade privacy for convenience, as they already do with so many other apps and devices. “A lot of consumers see the convenience and don’t think about the long-term records that are being kept,” says Peter Swire, who specializes in privacy law at the Georgia Tech Scheller College of Business, in Wired.

IISP Analyst Joel Odom: "Echo Look is a camera that lives in your bedroom for the purpose of sending photos and videos of you over the internet to a company whose business model involves learning your personal habits for marketing purposes.  What could possibly go wrong?  Amazon’s own promotional video for Echo Look says it best: “Alexa is built from the cloud, and always getting smarter, and so will Echo Look.”





A new, purported, hacking tool by the National Security Agency -- named DOUBLEPULSAR -- has exploded onto the hacking scene. It emerged from the latest dump of tools from a hacking group named The Shadow Brokers -- a group suspected to be affiliated with Russian intelligence. According to an analysis performed by Countercept, the exploit uses a previously unknown technique to load arbitrary kernel code. Essentially, it acts as a gateway for whatever malicious payload the operator wants to run. With its public release by The Shadow Brokers, a whole range of militarized exploits have been put into the hands of nation states, hacking teams, and script kiddies worldwide. The security firm Below0Day has been tracking the multiplication of the exploit in the wild. Out of 5.5 million hosts found to be vulnerable, more than one in 100 were infected, up from one in 200 within a week. The slow trickle of vulnerabilities splashing over the dam turned into a torrential rush.

IISP Analyst Stone Tillotson: DOUBLEPULSAR is only the latest in a series of leaked hacking tools, following on the heels of the CIA's Vault7 leak. With the cyber world aflutter with militarized exploits, not to mention the threat of everyday cybercriminals, what's an ordinary computer user to do? First, don't panic. Bad actors might be able to wreak havoc on your online profiles, but this analyst finds it preferable to real mugging. Second, standard best practices will serve to prevent the most prevalent avenues of attack: use anti-virus software, avoid easily guessed passwords, connect through a firewall, don't click on links in unsolicited email, and back-up important data. Most ordinary users are targets of convenience, so simply being a little more difficult than average tends to work. And in any case, if (supposedly) the NSA and CIA can be breached, losing your Beatles mp3s to ransomware shouldn't seem so bad."


New Malware Preys on Linux-based IoT Devices with Default Passwords

BrickerBot is a new malware that preys on Linux-based networked assets with factory-default passwords, granting it remote administrator access and conducting “permanent denial-of-service” (PDoS) attacks. Based on malware used in the Mirai botnet, a botnet made up of Internet of Things (IoT) devices designed to conduct massive DDoS attacks, it’s not clear what the motivation is behind BrickerBot exactly, other than wreaking havoc. A month after the initial discovery and disappearance of BrickerBot.1 and BrickerBot.2, version 3 suddenly appeared, with an increased success rate speed (roughly 1300 attacks in under 15 hours according to Radware analysis) and a modified attack script. Once a host is compromised, the malware attempts to corrupt their internal storage, and render the device useless, or “bricked.”

IISP Analyst Holly Dragoo: “PDoS attacks are becoming alarmingly more commonplace. With the rise of BrickerBot and the Hajime botnet (similar modus operandi), more gadgets, cameras and non-computing consumer goods are being compromised and lost – permanently. As Bruce Schneier pointed out in October 2016, this surprisingly isn’t enough incentive to make manufacturers build security into their devices; it’s an economic issue. Sellers of IoT devices don’t have the same deep pockets that the computer industry giants do for testing and evaluation, and buyers don’t care or know enough to demand baked-in security to their purchases. This kind of market failure opens the door to government regulation. It’s only a matter of time trusted.”


Hacked Emergency Infrastructure in Dallas a Lesson Before It's Too Late

City officials in Dallas have pointed the finger at a hacker for causing all 156 emergency sirens to turn on at the same time.  The sirens were activated at 11:42 p.m., Friday April 7, and continued to wail for over 90 minutes before city workers pulled the plug on the emergency notification system.  The simultaneous blaring of sirens caused a chain reaction of consequences including the flooding of the 911 emergency phone lines and causing delays in responses to actual emergencies.  Researcher have concluded that the hacker was able to attack the system using a wireless transmission, meaning they could have conducted the attack from nearly anywhere in the Dallas area.

IISP Analyst Chris M. Roberts: "Researchers’ opinions vary on the difficulty of this hack, and while I tend to agree with those who say it was simple to carry out, the difficulty of the hack is not the important part of the story. The impact of the attack is where the focus needs to be. The sirens were offline for a number of hours and likely not trusted as much going forward, the 911 system was flooded with calls, and emergency responders were delayed. Additionally, the city has already responded by spending $100,000 to upgrade the system, in what is believed to be only the first round of funding for these technical upgrades. 

This attack is an excellent example of why all infrastructure and internet-of-things (IoT) type systems need to be protected -- not just from computer attacks, but from all attack surfaces that leave the systems exposed. Systems, both old and new, connected to the internet or not, need to be evaluated and protected. The city of Dallas should be thankful that this wasn’t executed by someone with malicious intent because the outcome could have been much worse."


Certification Authority Authorization is Coming, And It’s a Good Idea

A consortium of major web browser vendors and internet certification authorities known as the CA/Browser Forum recently voted to mandate Certification Authority Authorization (CAA) as part of its certificate issuance requirements. (Web browsers use security certificates to authenticate domains during the establishment of secure browsing sessions. Every domain security certificate is digitally signed by a trusted certification authority (CA), which allows the browser to check the authenticity of the certificate.) The CAA requirement, which becomes effective in September, allows web browsers to use the domain name system (DNS) to check which CAs are allowed to sign certificates for a given domain.  If a domain presents a browser with a certificate signed by a CA that is not authorized to sign for that domain, the browser will reject the certificate even if the signing CA is otherwise trusted.

IISP Analyst Joel Odom: The secure internet uses digital certificates, digitally signed by trusted certification authorities, to establish the identity of websites when a browser establishes secure connections. One problem with this system lies in the need for a browser to trust numerous certification authorities. I checked my Chromebook’s certificate store and found that there are 85 certification authorities trusted by my browser. This means that any one of those 85 CAs could issue a certificate for any domain, and my browser would trust that certificate. With that many trusted CAs, there is a lot of room for certificate misissuance. This is where CAA comes into play. CAA means that my browser can use the DNS system to check that the CA which signed a certificate for a given domain is actually authorized to sign for that domain. This check mitigates the misissuance problem by giving my browser a way to double check the validity of a certificate. The new CAA system isn’t perfect: an attacker with strong of control of my internet connection could falsify CAA records, but it significantly raises the bar."