Cybersecurity News & Commentary - April 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.


April 6, 2017

 

Senate Votes to Repeal FCC Privacy Rule

The U.S. Senate and House of Representatives passed a joint resolution that will permit Internet Service Providers (ISPs) to capture and sell customer browsing habits – allowing them to potentially offer competitive, targeted ad networks akin to Google Ad Networks in the future. The resolution repeals an Obama-era law set to go into effect in December 2017, which would have required ISPs to obtain customer permission before selling or sharing their data with third-party businesses. Privacy groups opposed the reversal in contrast to support for it from telecommunication industry associations and others. The bill now goes to the White House to officially be signed into law.

IISP Analyst Holly Dragoo: “Technology used to track your browsing history and inject advertising is not new, but somehow seems more invasive when it’s coming from the only way we have to connect to the Internet. It also inherently creates security risks. The debate is complicated, as US Telecom argues – in the name of consumer rights – that the FCC rule goes against service providers’ First Amendment rights to communicate offers about their own products and services. They point out the inconsistency of treating an IP address – arguably public information – with the same amount of protection as is required for a Social Security number. Nobody seems to be discussing how this will be affected by the new EU privacy regulations, either.  I can’t comment on the constitutionality of the rule, but the practicality of this argument to me (the consumer) suggests that I’ll get yet another way for <insert annoying provider name here> to spam me with ads about service bundling… and another way to be creeped out when something I ran a search for three days prior shows up in my social media feed.”

 


Google Begins to Distrust Symantec Security Certificates, Symantec Responds

Citing “a continually increasing scope of misissuance” of security certificates by Symantec, Google has begun a process of progressive distrust of Symantec certificates.  This means that the Google Chrome browser will, over the course of upcoming releases, place less and less trust in Symantec certificates.  Websites that use Symantec certificates will have to have those certificates issued more often, and Chrome will not recognize the extended validation property of any Symantec certificate.  Symantec’s response calls Google’s claim of a pattern of misissuance “exaggerated and misleading.”

IISP Analyst Joel Odom: "Trust in computing is complicated.  When a browser establishes a communication channel with a server, the browser’s trust in the security of the channel is ultimately rooted in the trust that a certificate authority has properly ensured that a set of public keys truly belongs to the website who claims them.  The issue in this case is that Google believes that Symantec has not been diligent in this validation process, and thus it is possible that some Symantec certificates were issued to dishonest parties who do not own the domains that the certificates protect.  Regardless of whether or not actual harm occurred (it is impossible to be sure one way or the other), Google has great interest in the security of the internet.  Google has taken this step as a pragmatic matter for the certificates in question, and as a matter of precedent to pressure certificate authorities to meet promised standards of diligence."

 


LastPass Vulnerability Revealed

It happened. An exploit of the popular password manager LastPass was revealed. The bug -- released by Tavis Ormandy, of Google Project Zero fame -- relied on "consumer onboarding features" that allowed unauthenticated access to the LastPass API. Consequently, an attacker could trick users of a LastPass extension on Chrome, Firefox, or Edge to visit a malicious page that would reveal a user's password for any website. To make matters worse, if a user had installed a helper binary, which enables features like fingerprint authentication and sharing login state between browsers, the vulnerability allowed remote code execution (RCE). A band-aid was quickly applied, removing the DNS record for the offending domain, and the vulnerability since has been patched.

IISP Analyst Yacin Nadji: “The bug itself seems no more than a mistake, but it raised some interesting issues with respect to usability, and the quick fix. First, this struck me as a classic example of how pushing for usability and integrating across systems (in this case, the browser and the underlying OS) can increase the attack surface and lead to security problems down the road. Clearly the binary extension (installed by 10% of their user base) makes the software more usable, but the cost was RCE when a vulnerability was found. Ormandy himself recommended using KeePass, which doesn't come with browser plugins -- arguably making the software much less user-friendly.

Second, the quick fix was to remove the DNS record for the domain needed to resolve to launch the attack, which was under the control of LastPass. Essentially, if the attack was attempted, the DNS resolution process would return NXDOMAIN and the request necessary for the exploit would not continue. This, however, ignores situations where the domain would resolve anyway, such as under ISPs or Enterprises that do NXDOMAIN rewriting in proxies, or user's being subjected to a man-in-the-middle attack. This was disclosed in Ormandy’s bug report, but it seems that particular issue was not conveyed properly. All said, they quickly solved the issue on the server-side.

For concerned readers, don't let this dissuade you from using a password manager, but be wary of installing components that may unnecessarily increase your attack surface."

 


Critical Sensors Might Not Be as Trustworthy as We Thought

University of Michigan researchers published findings that demonstrate the ability to influence a trusted sensor used in countless electronic devices around the world.  MEMS (Micro-Electro-Mechanical Systems) accelerometer subsystems provide accurate detec\tion while measuring acceleration, tilt, shock, and vibration.  Accelerometers work by having a physical device inside the chip that moves around and those movements are translated into electrical pulses.  Researchers were able to use an audio speaker to identify the resonant frequency of the accelerometer and cause the chip to report false movements.

IISP Analyst Chris M. Roberts: “While this vulnerability has not been used as an exploit at this time, it is a very good example of attacking a trusted sensor or communication bus. These trusted inputs are rarely checked from a security perspective and are often treated as an absolute truth. Because of that, actions -- both physical and electrical -- are automatically taken based on their data. While you likely know that MEMS accelerometers are used in your cell phone and wearable device, it’s worth noting that they are also used in more critical devices including both medical and automotive applications. In fact, these accelerometers have been used to inflate automotive airbags for years. Therefore, in theory, an attacker could deploy your airbag while you drive down the interstate which would produce devastating effects. Just another reminder to developers that no input can be trusted.”

 


Insider Threats – Threat Rising or Readiness?

A fresh study out from Haystax Technology took responses from over 500 cybersecurity and information technology professionals about their perceptions of insider threat trends. They found three quarters of their respondents felt vulnerable to insider attacks, and over half (56 percent) say they have seen an increase in threat incidents in the last year. Interestingly, nearly half (42 percent) responded that they have proper controls in place to prevent incidents. A detailed infographic covers areas from costs, how to combat the threat: logs, monitoring, analytics, etc., to insider motivations, and what roles insiders are likely to have in an organization.

IISP Analyst Holly Dragoo: "I question the real meaning of 'rise in threats' in this context, as the survey is largely perception-based, and with the trendiness surrounding the topic as of late, it may simply be due to increased awareness and recognition (which is good). It’s worth questioning that '68 percent of organizations can recover [from an insider attack] within a week or less' or that 21 percent say one can be detected in a week. Wondering if that is an actual reflection of society or if it’s because the nature of professionals taking the time to answer a survey on insider threat are likely fairly prepared and have plans in place.

Regardless, this is a great write-up on insider attacks and really drives home the fact that the vast majority – by far – are due to negligence, not malice. This is so important to keep in mind when considering whether to or how to implement a response plan for an organization. Also telling is the statistic that 57 percent feel that 'insufficient data protection strategies' and 54 percent say 'increased access to sensitive data' are a part of why the threat is rising. If we can establish a new norm where users only have access to what they need, these statistics will go down."
 


EDNS(0) Privacy Revisions May Be Ahead

A working group of the Internet Engineering Task Force (IETF) recently proposed embedding a client identifier in DNS requests to enable custom, behind-the-NAT filters (think parental controls down to the device- or user-level). This is not a new idea, and is already being done to some degree by companies -- such as PowerDNS, OpenDNS, and Akamai -- by either using unique identifiers or MAC addresses stuffed into DNS requests. While intentions are benign, there may be unaddressed privacy issues. Admittedly, these data are not readily available, but could be monetized and made more prevalent. Furthermore, similar research data has been used for non-research purposes in the past raising concerns the data may be used irresponsibly in the future.

IISP Analyst Yacin Nadji: “I cannot stress enough that collecting DNS has a clear security benefit, but this must be balanced with responsible collection and use of the data, as well as restraint when pushing new standards. Luckily, the IETF draft process allows industry and academic experts to weigh in on new extensions precisely to prevent these problems from arising.

It's hard to make concrete recommendations without additional research, but there are some obvious moves one can make. Using a MAC address seems unnecessary when a unique identifier can simply be generated that does not directly represent a physical device. Researchers collecting data should consider hashing MAC addresses if they are used and examine other schemes for privacy leakage. If the data are being sold for other reasons, this identifying information should be stripped out."