GuidePoint’s Expertise Supports Your Organization’s GSA HACS Contract Needs

Imagine this: Your network is compromised with outbound connections sending data to foreign countries, and your information security team has no idea.

That’s exactly what GuidePoint Security’s analysts and incident responders discovered while actively cyber hunting for a new client in our Virtual Security Operations Center (vSOC).

Our professionals discovered open connections to more than 30 foreign countries, even though the client had no foreign interests or customers. Using Splunk’s Enterprise Security application, our team put its geolocation capabilities to work and created a map to illustrate all the foreign locations that successfully received this data.

When we alerted the client to the connections, we used the map to show the extent of the compromise. The client agreed to implement egress rules on its firewalls to limit destinations for data transfers, as well as country-blocking technologies in its perimeter security appliances to deny connections to foreign countries. By working with GuidePoint, the client narrowed the scope of who has access to its enterprise network and improved its overall security posture.

This real-world example of cyber hunting for data exfiltration is one of the many ways GuidePoint can support your organization with your General Services Administration (GSA) Highly Adaptive Cybersecurity Services (HACS) contract needs.

GSA recently awarded GuidePoint all four HACS Special Items Numbers (SINs), including, 132-45C: Cyber Hunt. The others SINs include: 132-45A: Penetration Testing; 132-45B: Incident Response; and 132-45D: Risk and Vulnerability Assessment.

With these SINs, GuidePoint’s subject matter experts can help your organization with all of your information security needs. As a federal or state/local government client, your organization will have:

  • Access to pool of technically evaluated cybersecurity vendors
  • Rapid ordering and deployment of services
  • Reduction in open market ordering and contract duplication
  • Cybersecurity/acquisition support resources from GSA

For more information about how GuidePoint has helped clients, download the full text of our SINs Use Cases.

For additional information and pricing on our IT professional and cybersecurity services, visit https://www.guidepointsecurity.com/contracts.

Update Your Cisco ASA ASAP

Introduction

On February 10, 2016, Cisco publicly acknowledged CVE-2016-1287 – a CVSS 10.0 rated vulnerability in their ASA line of products. ASA devices are often generically referred to as firewalls, but they are also often used for terminating Virtual Private Network (VPN) connections (the important part of this disclosure), and less often utilized for network anti-virus and intrusion prevention. The topic of this post highlights an issue that exists in Cisco’s implementation of the Internet Key Exchange (IKE) protocol (versions 1 and 2), which is used to negotiate the security settings of the IPSec protocol stack, and most importantly, IPSec VPN connections. While this vulnerability doesn’t exactly fit the criteria that many would consider “high profile” in the same way that the vendor agnostic Heartbleed and Shellshock disclosures were, it is still worthy of significant attention. According to this Shodan report, there are currently over 5.8 million devices on the Internet with the IKE protocol available. Granted, not all 5.8 million of those devices are ASA devices, but given Cisco’s popularity in the market, even a conservative 20%+ market share would be north of a million affected devices. Combine that with the general latency associated with patching infrastructure equipment, and odds are unfortunately in favor of the nefarious.

Overview

There are two functions within the algorithm that ASA devices use to reassemble fragmented IKE payloads that chiefly contribute to this vulnerability. One is responsible for parsing the fragment and maintaining the fragment reassembly queues, and the other monitors the reassembly queues and handles the actual reassembly of the fragments once all of the fragments have arrived. The problem begins with the function that is responsible for maintaining the fragment reassembly queues. There are three primary logical issues that make this code vulnerable:

  1. The calculation that is performed to make sure that the size of an incoming fragment is acceptable checks for a maximum value, but not a minimum value;
  2. The code assumes that the fragment is at least as large as the header (8 bytes); and
  3. The length of the header is subtracted from the length of the fragment before the queue size is updated.

With no minimum value and the assumption that all fragments are at least as large as the header, an attacker can use a tool like Scapy to craft a packet with a fragment that is smaller than 8 bytes (the size of the header). When we move to step three where the length of the header (8) is subtracted from the size of the fragment (< 8), we end up in negative memory space, causing a Denial-of-Service (DoS) condition.

David Barksdale, Jordan Gruskovnjak, and Alex Wheeler of Exodus Intelligence discovered this vulnerability and are credited with disclosing it to Cisco. In addition to this, they have also posted an excellent technical explanation of their research as well as a proof-of-concept explanation of the methodology they used to achieve remote code execution.

Impact

Ultimately, exploitation will either result in remote control of the affected system or Denial-of-Service. Depending on how authentication is handled (local versus RADIUS/TACACS, etc.), credential reuse, network segmentation, and many other potential factors, a skilled attacker could eventually leverage control over the device into control over the environment in a worst-case scenario. If cryptographic key information can be discovered, capturing and decrypting traffic flowing through these devices is also a possible risk.

Identification

According to Cisco’s advisory, ASA administrators can run the following command on their devices to test their configuration for the vulnerability:

# show running-config crypto map | include interface

Should the device be configured to terminate IKE VPN connections (i.e. vulnerable), a crypto map will be present for at least one interface.

Monitoring for and detection of attempted exploits will likely require very flexible monitoring tools or a subscription service with aggressive signature SLA’s. Packet inspection needs be configured on a device that captures inbound traffic to the ASA device and flags any inbound packets in the IKE protocol that have a value of less than eight (8) in the length field of a fragmented (type 132) packet. Detection is further complicated by the need to consider that multiple fragmented payloads could potentially be linked inside of a single IKEv2 packet and therefore also that the payload may not be the only, or even the first, payload in the packet.

Remediation

Currently, there are no workarounds for this issue. Cisco has issued a patch and an advisory with information on what versions of the ASA software are affected. Additional information and a link to the relevant patch can be found in Cisco’s advisory.

Summary Opinion

Shortly after this vulnerability was announced, HD Moore (perhaps jokingly) tweeted that he was ordering an ASA. Rest assured, despite the current lack of a publicly available exploit at the time of this writing, it is likely coming in the near future. The Internet Storm Center detected a significant spike in scanning for the IKE protocol across the Internet following the announcement. If you have ASA devices exposed to the Internet, and they are being used to facilitate VPN connections with the IKE protocol, you need to deploy this patch yesterday. VPN and firewall devices are the entryway to protected environments, and the risks associated with this vulnerability extend far beyond the device itself.

As a penetration-testing consultant, I’ve seen many different environments in a variety of sizes and configurations. I’ve seen large companies with seemingly limitless budgets continue to maintain end-of-life systems in a flat network with vulnerabilities that are nearly a decade old. Conversely, I’ve seen smaller organizations without dedicated security personnel lock down a network to the point that all systems are patched within 48 hours of release. However, one thing that is still unfortunately very common, despite the current landscape of the industry, is that many organizations still do not regularly check for and apply security patches for applications and devices, such as web platforms, virtualization tools, networking infrastructure, and storage solutions. These, and any other third-party applications in use, whether on a server or an endpoint, should be included in any vulnerability and/or patch management program that aspires to be truly effective. Furthermore, evaluating the environment for missing patches and vulnerabilities should not be an activity that only occurs when a significant vulnerability disclosure (such as this one) triggers widespread panic. Regular vulnerability scanning and metric reporting should be a minimum requirement for any organization that claims to take security seriously.

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, and with offices in Georgia, Massachusetts, Michigan, Minnesota, Missouri, Florida, Texas, and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Vulnerability Identified in Linux Kernel: Local Privilege Escalation 0-Day

Overview

A local zero-day found in the Linux kernel can escalate privileges and may impact the mobile sector on an ongoing basis. Perception Point Research Team reported Analysis and Exploitation of a Linux Kernel Vulnerability (CVE-2016-0728) to the Red Hat Kernel security team and posted a proof of concept exploit.

The 0-day takes advantage of a reference leak in the keyring library. MITRE currently marks CVE-2016-0728 as reserved.

Here is a high level explanation of the proof of concept:

The Perception Point Research Team explains, “The [reference] leak occurs when a process tries to replace its current session keyring with the very same one.” A part of the Kernel code skips the key_put function and leaks the reference increased by find_keyring_by_name. The proof of concept takes advantage of the reference leak along with the lack of bounds checking to overflow the usage field and free the keyring object. The freed keyring object’s revoked function is used to execute functions with root privileges.

The Perception Point Research Teams ends the article with, “Thanks to David Howells, Wade Mealing and the whole Red Hat Security team for that fast response and the cooperation fixing the bug.”

Impact

This vulnerability may impact as much as tens of millions Linux PCs and Servers along with 66% of all Android devices. Unfortunately, since most carriers do not push updates to Android phones, the keychain vulnerability may linger for some time on mobile devices.

The issue can be traced back to a 2012 commit 3a50597de8635cd05133bd12c95681c82fe7b878 in kernel version 3.10. It affects Android KitKat 4.4 and higher, Red Hat Enterprise Linux 7 kernel and derivatives, and Ubuntu 14.04 LTS, just to name a few. You can find a list of vulnerable Linux distributions here.

The proof of concept escalates privileges from a local user to root, takes about 30 minutes to run with a Core-i7 and was tested on kernel 3.18 64 bit.

Identification

Identification is simple. Check your kernel version with the command uname –r . If you are running anything above kernel version 3.10, it is imperative to look for a patch and upgrade when one is available.

If the proof of concept exploit is successful, no log events will be generated.

One advantage to the proof of concept exploit is that it can take thirty minutes or more to execute, so it is possible to detect the exploit running by observing key file’s excessive usage counts with the cat /proc/keys command.

Remediation

Enabling SMEP (Supervisor Mode Execution Protection) and SMAP (Supervisor Mode Access Protection) may make the exploit more difficult.

The Red Hat Security Advisory has put out a patch for the kernel vulnerability.

Ubuntu Security Notice USN-2870-2 recommends updating your 12.04 LTS system to package versions outlined below.

  • linux-image-3.13.0-76-generic
  • linux-image-3.13.0-76-generic-lpae
  • 13.0-76.120~precise1

Overall, everyone is working diligently to push out an update. GuidePoint recommends patching as soon as a patch is ready. GuidePoint Security is available to assist our customers with any remediation efforts. Please contact your Account Executive or click here for more details on how GuidePoint can help.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Cisco Patches Four Backdoors

Overview

The end of 2015 posed a busy backdoor day for Cisco engineers, as four major vulnerabilities, CVE-2015-6314, CVE-2015-6317, CVE-2015-6323 and CVE-2015-6336 were published and later patched in mid-January 2016.

In late December 2015, Cisco announced in a security blog an Update for Customers, explaining an additional code review and penetration testing to address public concern after the Juniper ScreenOS Vulnerabilities. Cisco’s efforts seemed to pay off with four vulnerabilities posted on January 13, 2016 in the Cisco Security Advisory and Responses.

Impact

The Cisco Security Advisory points out all four vulnerabilities have no possible workarounds. The Cisco Exploitation and Public Announcements states for the four vulnerabilities, “The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory.”

The four backdoors cover several Wireless Controllers, Access Points and the Identity Services Engine. Below is an outline organized by CVE and lists the devices affected.

  • CVE-2015-6314
    • Cisco 2500 Series Wireless Controllers
    • Cisco 5500 Series Wireless Controllers
    • Cisco 8500 Series Wireless Controllers
    • Cisco Flex 7500 Series Wireless Controllers
    • Cisco Virtual Wireless Controllers
  • CVE-2015-6317 & CVE-2015-6323
    • Cisco Identity Services Engine
      • Vulnerable Versions
        • 1.1 or later
        • 1.2.0 prior to patch 17
        • 1.2.1 prior to patch 8
        • 1.3 prior to patch 5
        • 1.4 prior to patch 4
    • Cisco Identity Services Engine Express
  • CVE-2015-6336
    • Cisco Aironet 1830e Series Access Point
    • Cisco Aironet 1830i Series Access Point
    • Cisco Aironet 1850e Series Access Point
    • Cisco Aironet 1850i Series Access Point

The critical Cisco Wireless LAN Controller Unauthorized Access Vulnerability CVE-2015-6314 could allow an unauthenticated remote attacker ability to modify configurations.The medium-rated Cisco Identity Services Engine Unauthorized Access Vulnerability CVE-2015-6317 applies to versions prior to 2.0 and allows a low-privileged authenticated remote attacker access to particular web resources intended only for administrative users.

The critical Cisco Identity Services Engine Unauthorized Access Vulnerability CVE-2015-6323, with access to the Admin portal, can allow an attacker administrative access to the device.

The high-rated Cisco Aironet 1800 Series Access Point Default Static Account Credentials Vulnerability CVE-2015-6336 could be accessed with non-administrative privileges using a default account that has a static password. The default account is created when the device is installed.

Remediation

With no workarounds and the levity of these backdoors, it is important patch as soon as possible.

For Cisco WLCs, the Cisco Security Advisory (id cisco-sa-20160113-wlc) recommends upgrading to an appropriate release indicated in the table below.

Cisco WLC Major Release First Fixed Release CVE-2015-6314
7.6 Contact Cisco TAC
8.0 8.0.121.0
8.1 8.1.131.0

 

Both Cisco Security Advisory (id: cisco-sa-20160113-ise2) and Cisco Security Advisory (id: cisco-sa-20160113-ise) recommends upgrading to Cisco Identity Services Engine 2.0 or above.

The Cisco Security Advisory (id cisco-sa-20160113-air) recommends upgrading to version 8.1.131.0 or later for the Aironet 1800 Series Access Points.

GuidePoint Security is available to assist our customers with any remediation efforts. Please contact your Account Executive or click here for more details on how GuidePoint can help.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

 

FortiOS SSH Undocumented Interactive Login Vulnerability

Overview

Where security research is concerned, when a vulnerability or undocumented access has been found on one device, attackers and security researchers scramble to find related vulnerabilities in similar devices. Merely weeks after vulnerabilities were found in the Juniper ScreenOS, another similar vulnerability, CVE-2016-1909, was found in Fortinet’s FortiOS. CVE-2016-1909 is a hardcoded SSH credential with the username Fortimanager_Access and a static string FGTAbc11*xy+Qqz27 hashed as the password.

Impact

FortiOS versions from 4.3.0 to 4.3.16 and 5.0.0 to 5.0.7, or builds between November 2012 and July 2014, include the hardcoded SSH credentials. FortiOS 5.2 and 5.4 are not affected. The Seclists.org Full Disclosure mailing list posted proof of concept code, and some Twitter feeds document exploits as early as January 12, 2016.

The hardcoded credentials give administrative access and may be tied to FortiManager Centralized Security Management due to the lack of event logs.

Fortinet’s blog, Behind the Firewall, posted a Brief Statement Regarding Issues Found with FortiOS, stating, “After careful analysis and investigation, we were able to verify this issue was not due to any malicious activity by any party, internal or external.” The blog identifies the following versions as not affected:

FortiOS v4.3.17 or any later version of FortiOS v4.3 (available as of July 9, 2014)
FortiOS v5.0.8 or any later version of FortiOS v5.0 (available as of July 28, 2014)
Any version of FortiOS v5.2 or v5.4

Note: there have been reports of researchers finding the hardcoded password string in version 5.2.3, suggesting the hashing algorithm to produce the final password may have been altered throughout different versions.

Identification

It is difficult to identify unauthorized access because FortiOS does not create event logs for the Fortimanager_Access user by default. It may be possible to enable logs to include the user Fortimanager_Access by configuring Local-In Policy to include central management (a FortiGate unit being managed by a FortiManager unit). See the Logging Local-In Policies section in the FortiOS Handbook Logging and Reporting for FortiOS.

It may be possible to view SSH attempts in the console. Use “diagnose debug application sshd -1” to identify input_usrauth_requests for the Fortimanager_Access user.

Remediation

FortiGuard Center Advisory post, FortiOS SSH Undocumented Interactive Login Vulnerability, recommends patching FortiOS branch 4.3 to 4.3.17 or later, and FortiOS branch 5.0 to 5.0.8 or later. There are two possible workarounds:

  1. Disable admin access via SSH on all interfaces, and use the Web GUI or console applet of the GUI for CLI access.
  2. Limit SSH access to a minimal set of IP addresses with the Local-In policies.

GuidePoint is recommending whitelisting IP addresses with SSH access to your FortiOS device and patching to the latest build.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

How New Technology Can Help Federal Agencies Comply With National Insider Threat Policies

Various motives, such as greed, blackmail and revenge, have influenced federal employees and federal contractors to commit some of the most serious security breaches in the history of the United States.

While many thousands of them are dedicated to their jobs and are loyal to their country, a select few federal employees have revealed top secrets to other countries, organizations, and to the public. (Think Edward Snowden and Bradley Manning.)

Other insiders continue to pose a major threat to national security today.

Current National Security Directives

In November 2012, the National Insider Threat Policy and Minimum Standards for Executive Branch Insider Threat Programs required that federal agencies, departments and divisions:

  • Monitor employee use of classified networks
  • Protect the civil liberties and privacy of all personnel
  • Have their own insider threat programs in place
  • Appoint a program leader (U.S. citizen with appropriate clearance)
  • Maintain quality HR records (i.e. personnel, polygraph tests, security)
  • Provide insider threat awareness training within 30 days of hiring

The 2012 regulations not only cover what security measures must be taken, they also address how they must be implemented.

In early 2015, an updated policy is expected to result in additional regulations, causing concern for some federal organizations in the race to maintain national security compliance.

Advanced Technology for Greater National Security

Fortunately for federal organizations and businesses that employ federal contractors, today’s innovative technology solutions make it possible to achieve the country’s security objectives.

Identification

In order to identify threatening activity throughout networks and systems, federal agencies must develop and implement the appropriate security strategies.

For example, statistically analyzing network flows (NetFlow), utilizing network-based security tools, and implementing next generation firewalls can help the security operation centers (SOCs) determine and counter security issues.

These methods can tell an agency what type of data is being extracted, when irregular data usage is occurring, and what typical data trends and activities are used for regular operations.

Remediation

To satisfy national rules and regulations, as well as to create an internal network security alarm system, federal organizations can use the following technologies, services, and tools:

SPAN/TAP Port Aggregation

Switch aggregators allow devices from several networks to be connected to the switch aggregator, thereby sending SPAN/TAP to a number of devices. This will assist in the management and distribution of uninterrupted data flow to a centralized switch aggregator.

SPAN/TAP Data Enrichment

The spanning or tapping of network data allows for the placement of NetFlow sensors and can assist with the NetFlow data as well as application and user identification.

Packet Capture

With full packet capture, the capabilities of an agency or business to detect and respond to potential breaches can drastically increase. Being able to identify the compromised data and the person infiltrating greatly assists cyber security and forensic officials in their investigations.

Next Generation Firewalls

Next generation firewalls provide additional information and extra layers of protection to federal organizations. They can identify IP addresses, service ports and users, as well as determine when the user is logged in to the domain.

Among the many ways next generation firewalls can be used to combat insider threats are application identification and control, file blocking and botnet detection.

Most importantly, next generation firewalls help administrators quickly access captured data logs and generate meaningful, correlated reports.

These tools are only a small sample of the technologies that can help prevent and/or minimize insider threats and satisfy the new national security mandates.

For more information about insider threats, how to mitigate them download our new, Finding the Insider Threat, white paper here: www.guidepointsecurity.com/white-papers/.

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Va., and with offices in Michigan, New Hampshire, Florida and North Carolina. GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM).

Another “Ghost” in the Machine

Introduction

A recent vulnerability disclosure from a group of Qualys researchers reaffirms that there is no rest for the weary and that the New Year will likely keep pace with the former as the first critical and highly publicized vulnerability of 2015 is unveiled. This vulnerability is being referred to as “Ghost” and technical news sources around the world are rushing to report on the impact. These reports have been consistently accompanied with ominous imagery of ghoulish figures and fear-inspiring phrases, but is this Ghost really as scary as the media has portrayed?

Overview – A “Ghost” of GNU Past

This vulnerability is a heap-based buffer overflow vulnerability that can be trigged when a malformed string is passed to the gethostbyname() or gethostbyname2() functions in the GNU C Library (glibc). These vulnerable functions have been present in the glibc library for nearly 15 years.

The origin of the vulnerability in each of these functions is a “hostname” variable. While the implicated code does perform some input validation on the string value stored in this variable, no bounds checking is performed. Due to this implementation flaw, an attacker can supply malformed input consisting of an excessive number of numerical digits and period characters to write to unintended portions of system memory. This type of memory access can potentially be leveraged to execute unauthenticated and unauthorized code on remote systems. The full technical details of this vulnerability can be found in the original disclosure thread from the OSS-Sec mailing list.

Impact – How Scary is Ghost?

The impact of this vulnerability, if exploited, is very high (as is always the case with remote code execution vulnerabilities). Additionally, many services on Linux systems leverage these vulnerable libraries, which would make them potential candidates for a variety of attack vectors.

However, the exploitability of this vulnerability requires highly specific circumstances that make actual exploitation in the wild extremely unlikely. This is due to multiple mitigating factors that were all addressed at length in the original disclosure. These mitigating factors were listed as follows:

  • A patch already exists (since May 21, 2013), and has been applied and tested since glibc-2.18, released on August 12, 2013;
  • The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead;
  • Many programs, especially locally accessible SUID binaries, use gethostbyname() if, and only if, a preliminary call to inet_aton() fails. However, a subsequent call must also succeed (the “inet-aton” requirement) in order to reach the overflow: this is impossible, and such programs are therefore safe; and
  • Most of the other programs, especially remotely accessible servers, use gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also known as full-circle reverse DNS) checks. These programs are generally safe because the hostname passed to gethostbyname() has normally been pre-validated by DNS software:
    • “A string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets,” makes it impossible to satisfy the “1 KB” requirement; and
    • While glibc’s DNS resolver can produce hostnames of up to (almost) 1025 characters (in the case of bit-string labels and special or non-printable characters), this action introduces backslash characters (“\\”) and makes it impossible to satisfy the “digits-and-dots” requirement.

Despite the Qualys analysts’ disclosure of these highly restrictive conditions, the fear-mongering media has repeatedly omitted these details. Such periodicals consistently fixate upon the theoretical impact of this vulnerability but neglect to report on the real-world implications.

In the past year, the security industry has witnessed an emerging trend of vulnerability disclosures that come packaged with clever names and graphical imagery (Heartbleed, ShellShock, POODLE, etc.). This trend simply seems to be the result of an effort to drive media exposure. Although this practice does increase the public’s attention to information security concerns, it also increases the frequency of widespread reports that lack complete and/or accurate technical details from news sources that are solely concerned with exaggerating the facts for profit.

Consequently, there has also been a consistent increase in the spread of misinformation, flawed assumptions, technical inaccuracies, and unwarranted hysteria. Such trends have resulted in serious real-world issues, like ShellShock and Heartbleed, being lumped together with pedantic and highly theoretical proof-of-concepts, like POODLE and GHOST. Rather than getting caught up in the media frenzy, it is important that industry professionals stop to consider the actual technical details and corresponding real-world impact of a vulnerability to ensure that a measured and appropriate response is provided.

The Final Verdict

No matter how obscure the circumstances must be for exploitation to be possible, the underlying code associated with these functions is still vulnerable and should be updated as a matter of best practice. The vulnerability is the consequence of sustained support for functions that have already been deprecated for some time. As such, remediation will eliminate the risks associated with Ghost (however unlikely), with little-to-no impact on existing services or applications.

Identification

Under normal circumstances, the vulnerable library would only be found on Linux systems and not Windows workstations or servers. This is because GNU libraries are native to Linux, and the glibc library specifically is standard on Linux distributions. Therefore, all Linux systems are potentially vulnerable.

The easiest way to determine if a given Linux system is vulnerable is to identify the version of glibc in use on the system. Unpatched versions of glibc, prior to glibc-2.18, are vulnerable and should be updated. In most cases, a simple terminal command can be used to identify the version that’s in use. Note: in each example below, the command is in blue, and the identified version is in red.

  • Use the following command with Ubuntu and Debian:
# ldd --version
ldd (Ubuntu EGLIBC 2.11.1-0ubuntu7.20) 2.11.1
  • Use the following command with CentOS and RedHat:
# rpm -q glibc 
glibc-2.12-1.149.el6_6.5.i686 

Determining if the library contains the vulnerable functions requires consideration of both the running version and the patch / minor-version. This is due to the fact that numerous patched versions of the glibc library prior to glibc-2.18 are no longer vulnerable. If the returned version predates the versions listed below, then the system is vulnerable and should be patched:

  • Ubuntu 12.04 LTS: 2.15-0ubuntu10.10
  • Ubuntu 10.04 LTS: 2.11.1-0ubuntu7.20
  • Debian 7 LTS: 2.13-38+deb7u7
  • CentOS 6: glibc-2.12-1.149.el6_6.5
  • CentOS 7: glibc-2.17-55.el7_0.5
  • RHEL 5: glibc-2.5-123.el5_11.1
  • RHEL 6: glibc-2.12-1.149.el6_6.5
  • RHEL 7: glibc-2.17-55.el7_0.5

Unless unique circumstances dictate otherwise, GuidePoint recommends updating to the latest stable version, regardless of the current running version.

Remediation

To update to the latest version of glibc (whether for mitigation or general hardening), a single update command should be run from the terminal, and then the system will need to be rebooted for the change to take affect.

  • Use the following command with Ubuntu and Debian:
# sudo apt-get update && sudo apt-get dist-upgrade 
# sudo reboot

Warning: Upgrading the distribution can result in significant changes, so be sure to plan according. 

  • Use the following command with CentOS and RedHat:
# sudo yum update glibc 
# sudo reboot

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Virginia, and with offices in Michigan, New Hampshire, Florida and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

POODLE May Still be off the Leash with Certain TLS Conditions

poodle 2The POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability was initially disclosed as a weakness in the Secure Sockets Layer (SSL) 3.0 protocol. This vulnerability permits data within “secure” communications between a user and an SSL-enabled website to be decrypted under certain conditions. Successful attacks could disclose sensitive information, such as the victim’s session cookies, which could in-turn be used to hijack the victim’s application session.

The Transport Layer Security (TLS) protocol supplants SSL and corrects the underlying flaw that’s present in the legacy protocol. However, several vendors’ TLS implementations do not properly implement the TLS specification and are consequently susceptible to the same attack.

Fortunately, such a scenario affects neither native Microsoft TLS implementations nor OpenSSL (which constitutes the majority of non-native Microsoft TLS implementations). Adam Langley identified and documented this issue on his ImperialViolet blog, and at this time, F5 Networks, A10 Networks, and IBM (IBM HTTP Server and other IBM servers) have issued security advisories and corresponding patches for remediation.

Other TLS implementations may also be vulnerable, but future disclosures will likely be increasingly obscure. Qualys’ SSL Server Test has been updated to test for the TLS variant of this vulnerability and can be used to perform an analysis of questionable TLS-enabled services.

The current SSL Pulse Report (December 6, 2014), which is also the first to include data pertaining to TLS POODLE checks, shows that just over 10% of the services analyzed are vulnerable. While that figure is significant, it is also unsurprising, when F5’s market share is taken into consideration. This figure will hopefully decrease quickly as awareness spreads and vendors’ patches are applied.

Qualys notes that, “A successful attack will use about 256 requests to uncover one cookie character, or only 4096 requests for a 16-character cookie. This makes the attack quite practical.” However, the referenced practicality is still dependent upon specific conditions being met in advance, namely the ability of an attacker to both inject JavaScript into the target web application and capture network communications between the victim and target application.

While that scenario isn’t unheard of, the overall exposure is significantly less than a remotely exploitable vulnerability such as Heartbleed. The greatest exposure for real-world attacks is over public, untrusted networks. Free public WiFi networks are obvious examples of locations where this attack could occur. Users can defend themselves by tunneling their traffic through a VPN in these cases.

But, attacks originating from facilities that manage Internet backbones and target communications that must traverse the Internet would be far more insidious. In these cases, users must ensure they’re using a recent browser that completely mitigates the SSLv3 attack vector and validate that the remote service is not vulnerable to the TLS-based variants of this vulnerability.

In conclusion, the state of SSL/TLS-based security remains in a precarious state as 2014 draws to a close. This year has been particularly brutal to these technologies, with critical flaws being discovered everywhere from specific vendor implementations, to common development libraries, and the protocols themselves.

The most recent SSL Pulse data was also the first to show TLS1.2 breaking the 50% adoption rate (50.1% to be exact — up from 48.1% in early November). This is an important milestone because TLS1.2 currently provides the only unbroken cryptographic configuration, as noted by Adam Langley, but it also demonstrates that there is still a very long road ahead.

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable Information Security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Virginia, and with offices in Michigan, New Hampshire, Florida and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

 

Your Golden Ticket to Domain Admin – Microsoft’s Critical Kerberos Vulnerability – MS14-068

Overview

Microsoft issued a critical security bulletin on Tuesday November 18, 2014 (MS14-068) which stated there was a privately reported vulnerability found within the Kerberos Key Distribution Center (KDC) that could allow privilege escalation. The KDC authenticates clients and users, and issues session tickets and temporary session keys to users and computers within an Active Directory environment. The vulnerability exists in implementations of the KDC in Microsoft Windows and exists due to the KDC failing to properly validate signatures, which can result in forged parameters within a Kerberos ticket.

The KDC is a network service that runs on each Domain Controller as part of Active Directory Domain Services (AD DS) and by default listens on TCP and UDP port 88. Attackers that have access to a compromised domain user account as well as access to AD DS within an Active Directory environment could leverage the KDC vulnerability remotely. It would then be possible to elevate the privileges of the compromised user account to the role of Domain Administrator by sending the KDC a forged Kerberos ticket that identifies the user as a Domain Administrator. Once an attacker gains Domain Administrator privileges within an Active Directory environment they will be able to compromise any domain-managed system in the environment.

Impact

Unlike local privilege escalation vulnerabilities, an attacker that has a valid unprivileged user account within the domain can leverage this vulnerability remotely. Microsoft additionally stated within the security bulletin they are aware of limited targeted attacks that have attempted to exploit this vulnerability. Thus, it is reasonable to assume there is code in the wild that Microsoft has seen attempting to exploit this vulnerability. GuidePoint has not yet discovered enough information to exploit the vulnerability.

Affected Operating Systems

  • Windows Server 2003 and higher
  • Windows Server 2008 and higher
  • Windows Server 2012 and higher

For a complete list of affected hosts please refer to the MS14-068 Security Bulletin. In addition, Microsoft has released patches for Windows Vista, Windows 7, and Windows 8 and 8.1 as a defense-in-depth hardening of these operating systems. However, the Windows Vista, Windows 7, and Windows 8 and 8.1 operating systems are not directly vulnerable to this vulnerability.

Identification

Pre-Update Detection

To identify if an Active Directory environment has been targeted by any known exploits before updates have been applied to the affected systems, review Windows Security Event Log for Event ID 4624. This event is logged when successful logins occur within a domain. If the ‘Security ID’ and ‘Account Name’ fields of the log do not match, even though they should, it could indicate targeted attacks leveraging this vulnerability are underway.

Joe Bialek from the Microsoft Security Research and Defense blog illustrates pre-update detection very well within his detailed write-up of the MS14-068 vulnerability titled “Additional Information About CVE-2014-6324”. For additional information and illustration of pre-update detection it is highly recommended to read this blog post.

Post-Update Detection

To identify if an Active Directory environment is being actively targeted after applying the update to Windows Server 2008R2 and above, Event ID 4769 in the Kerberos Service Ticket Operation event log can be used for detection purposes.

Joe Bialek’s also illustrates post-update detection very well within his detailed write-up of the MS14-068 vulnerability titled “Additional Information About CVE-2014-6324”. Bialek explains event 4769 is a high volume event and it is advisable to only log failures of this event for detection purposes. For additional information and illustration of pre-update detection it is highly recommended to read this blog post.

Remediation

Microsoft has released an out-of-band patch to remediate the MS14-068 vulnerability. Users should test and deploy the patch to affected systems domain wide. Please refer to the MS14-068 Security Bulletin for more information.

References

A Shock 19 Years in the Making – Microsoft’s Critical WinShock Vulnerability – MS14-066

Overview

The vulnerability defined in MS14-066 (CVE-2014-6321), or “Winshock” as the media has dubbed it, has been categorized as a critical risk due to the potential impact that includes denial-of-service, information disclosure, and unauthenticated remote code execution. Microsoft describes Winshock in KB2992611 as the “improper processing of specially crafted packets by the Secure Channel (SChannel) security package.” This package is closely linked to critical system services, and this condition creates the possibility for a remote, unauthenticated attacker to obtain SYSTEM-level access. That is, undoubtedly, the worst-case scenario which could plausibly become the precursor to worms and other widespread damage.

 Impact

At its heart, the SChannel package is responsible for securing network communications with the SSL and TLS protocols. Numerous Microsoft service implementations including (but not limited to) IIS, Active Directory, Outlook Web Access, the Remote Desktop Protocol, and Internet Explorer utilize the SChannel package. However, due to the immediate lack of detailed technical information, it is currently unclear which of these services may genuinely be affected by this vulnerability.

For a detailed explanation on how to exploit the vulnerability, refer to the in-depth technical blog post by Beyond Trust that analyzes the patch and demonstrates how specially crafted SSL communications can be leveraged to target the vulnerable code and crash the operating system. The demonstration proves that not only is remote code execution theoretically possible, but that a simple denial of service condition is easily achieved by making a minor code change to the open source OpenSSL library.

It is important to note that the default IIS configuration does not accept client certificates. Additionally, other SSL/TLS-enabled services, such as Terminal Services, do not support client certificate configurations. However, new research demonstrates that (thanks to a second “bug” in Schannel) a malicious client certificate can still be utilized to trigger the vulnerability simply by configuring the attack technique to ignore the server configuration and submit the client certificate. While the service itself would ultimately ignore the client certificate in such a scenario, it will still be analyzed by the vulnerable SChannel code. In this case, any SSL/TLS service that utilizes the SChannel package, which includes all native Windows services, is conceivably vulnerable to exploitation.

At the moment, there are no publicly accessible exploits, nor have there been any reported cases of exploitation in the wild. However, Immunity Inc. has released a proof-of-concept exploit for subscribers that have access to their CANVAS Early Updates program. While the quality and reliability of this proof-of-concept are not disclosed, its existence confirms the feasibility of exploitation.

The technique demonstrated by Beyond Trust utilized client certificates to reach the vulnerable code. It is worth noting that Winshock appeared to address multiple code flaws, so client certificates should not be considered to be the only and definitive attack vector at this time. While a client certificate-based vulnerability would lack the prevalence of other recent SSL/TLS vulnerabilities, such as Heartbleed and POODLE, defending services affected by Winshock could arguably be a higher priority.

Identification

At this time there is no definitive way to determine if systems are vulnerable to Winshock. Anexia-it released a script that tests for the presence of four (4) ciphers that will exist on a system that has been patched against Winshock. This test, however, is not a guaranteed way to determine a system’s status in regards to Winshock. Microsoft includes a list of impacted Operating Systems (“OS”) in their MS14-066 advisory. If a system in your environment runs on an OS listed in the advisory, it would be safe to assume the system is vulnerable and proceed with mitigation steps to prevent system exploitation.

Remediation

Patching for Winshock is a largely straightforward task, and public-facing servers should obviously be prioritized due to their increased exposure. However, there are significant concerns that should be considered before applying the Microsoft supplied patch. The most common concern is the potential for negatively impacted performance.

Various well-known vendors, such as Amazon, Blackberry and IBM, have reported noticeable application performance degradation, TLS session disconnections, and SQL server performance issues. Reports of performance problems extending to client applications, such as web browsers, have surfaced as well.

Microsoft has been largely silent on these issues, and the lack of guidance makes remediation all the more problematic. On the one hand, this is a critical system vulnerability that should ideally be patched post haste, but on the other, the patch may immediately harm the organization in an alternate manner.

Before installing the patch from Microsoft, GuidePoint highly recommends carefully examining your environment to determine if installing the patch is worth the potential risk of performance degradation, and to prepare a rollback strategy should problems arise after installation.

Intermediary security controls and alternate SSL/TLS configurations may provide an ideal, short-term solution for some organizations. GuidePoint recommends contacting your inline network and host-based security control vendors to determine whether signatures have been developed to block attacks prior to reaching the vulnerable service.

Additionally, Non-Windows SSL/TLS proxy servers and offloading appliances may prevent attacks from succeeding against the underlying Windows service, but these configurations should be thoroughly tested to ensure that malicious requests are properly dropped or modified and cannot be used to successfully exploit the service.