Automation Tools Help with Real-Time Incident Response and Protection

Free webinar: Real-world examples of how to keep your environment secure from attacks, accelerate remediation

If you’re an information security professional responsible for incident response, you may feel frustrated and overburdened by all the manual processes needed to keep your environment safe.

You’re not alone.

In a recent Enterprise Strategy Group survey, more than 60 percent of information technology professionals say their organization has taken steps to automate incident response, but 91 percent say those processes are not effective or efficient.

Did you know there are resources and tools available to help facilitate some of these key processes for your organization? GuidePoint Security’s Virtual Security Operations Center (vSOC) analysts and incident responders have real-world experience using these types of tools. One such tool, Carbon Black, helps power GuidePoint’s vSOC enabling analysts and responders to hunt for incidents in real time, visualize the complete attack kill chain, and efficiently defend environments from attacks.

Here are some examples of how they have successfully used Carbon Black to stop incidents and monitor endpoints:

PowerShell Watchlist

Recently, GuidePoint analysts used Carbon Black to create a PowerShell watchlist for an unauthorized user attempt. Once alerted, analysts tracked down a malicious remote address and shut down unauthorized privileges on the host.

Environment audits

In another instance, vSOC analysts used Carbon Black to audit an environment to limit privilege account credentials. The audit alerted analysts to a possible vulnerability that could have allowed unrestricted access to a domain.

PUA/PUP activity

vSOC analysts recently used Carbon Black to create a custom watchlist for PUA/PUP activity. They found an instance that stood out from others and located an unapproved IE toolbar, which was loaded without approval on multiple workstations. The toolbar was isolated as a threat because it had the ability to monitor web-browsing behaviors.

Would you like to know more about these real-world incident response examples and how you can move from playing incident response catch-up to proactively hunting for threats?

Join GuidePoint and Carbon Black for a free, interactive webinar, “Conquering Challenges of Incident Response: Real-Time Hunting and Response,” at 2:30 p.m. Thursday, Nov. 17. The session will last about 45 minutes, with a chance to interact with the presenters, Stephen Jones, GuidePoint’s director of managed services, and Justin Scarpaci, technical solutions lead, Carbon Black.

Register online here.

About the presenters

Stephen Jones has more than 10 years of experience in information technology and cyber security. He specializes in security operations and has extensive experience working within the Department of Defense and the Intelligence Community.

Justin Scarpaci is a technical account manager on the Partner Success team at Carbon Black. In that role, he assists IR/MSSP partners with operationalizing Carbon Black as part of their service offerings. Justin served in the Marine Corps and has worked in multiple security roles for a defense contractor. He has a master’s degree in information security and forensics.

Can’t make the webinar? No worries. Go ahead and register now and we will send you a recording after the live presentation.

About GuidePoint Security

Headquartered in Herndon, Virginia, GuidePoint Security provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. 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 is with the System for Award Management (SAM). Learn more at:

Top GuidePoint Security Consultants to Present At Sold Out 2016 BSides Boston Training Session

Two of GuidePoint Security’s consultants will be among the featured instructors and presenters at this bsidesbos_est1year’s Security BSides Boston Conference, on May 20-21, 2016. The event, which is being held at the Microsoft NERD Building, at 1 Memorial Drive, Cambridge, MA, includes key speakers, presentations and training sessions. GuidePoint will also be a participating exhibitor on Saturday, May 21.

David Bressler and Casey Dunham, both members of the GuidePoint Application Security Team, will be leading an “Advanced Web Hacking,” all-day training session on May 20 for a sold-out audience. The pair will also be heading up a presentation titled, “Advanced XSS and Injection Attacks,” slated for May 21.

The Security BSides Boston Conference includes Friday training sessions running from 10 a.m. – 5:30 p.m., while the Conference discussions and presentations will be held from 9 a.m. – 6 p.m. on Saturday, May 21, 2016.

If you are unable to attend the events with Bressler and Dunham, be sure to stop by the GuidePoint Security table on Saturday.

About the Advanced Web Hacking Session

The all-day session involves hands-on learning through an instructor-led, simulated web application assessment against a proprietary web application that was built specifically for this course. The course moves beyond the basic OWASP Top 10 Web Application Vulnerabilities by introducing advanced forms of these common vulnerabilities, built from our own penetration testing experience. Focus is also placed on creating realistic proof of concepts to show higher impact, as well as what an attacker could do if the vulnerabilities were exposed.

About the Advanced XSS and Injection Attacks Presentation

In this presentation, Bressler and Dunham will review advanced forms of Cross Site Scripting (XSS) in the AngularJS framework through improper usage of the AngularJS templating language and injection attacks through the Hibernate Query Language (HQL), as well as breaking the HQL Lexer to run arbitrary SQL commands. They will also be presenting methods of auditing applications for these issues and preventing the vulnerabilities.

About GuidePoint Security LLC

GuidePoint Security LLC provides customized, innovative and valuable cybersecurity solutions and expertise that enable organizations to successfully achieve their mission. 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:


Another “Ghost” in the Machine


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.


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 

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.


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:

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


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.


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.


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.


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.


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


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.


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.


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.


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.


POODLE: SSL 3.0 Fallback Vulnerability


The SSL version 3.0 POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability (CVE-2014-3566) was officially released on October 14, 2014 by OpenSSL. The flaw was disclosed by a team of Google researchers including Bodo Möller, Thai Duong, and Krzysztof Kotowicz. This vulnerability is a consequence of an implementation flaw associated with the use of block cipher encryption in SSLv3. Block ciphers encrypt data in fixed-length blocks. If the plain text value to be encrypted is not a multiple of the defined block size, the cipher will apply padding to the data to increase the size, so that it can be converted to cipher text. The concern is that the Message Authentication Code (MAC) does not cover the block cipher padding and when the message is decrypted, the integrity of the padding cannot be verified. This can allow an attacker to decrypt cipher text, one byte at a time.

This vulnerability only affects the SSLv3 protocol, which is rarely used by modern web browsers that prefer the usage of TLSv1 encryption. However, due to the widespread support for SSLv3 on both servers and web browsers, an attacker can still leverage this vulnerability by using it in conjunction with a downgrade attack. A downgrade attack could be accomplished by intercepting and manipulating traffic associated with the SSL/TLS cipher suite negotiation, conducted between the client and server.

In the original disclosure article, B.Möller, T. Duong, and K. Kotowicz succinctly illustrate the impact of this vulnerability, referencing a scenario in which it could be used to compromise secure session tokens within the context of a web application (p.2,

“In the web setting, this SSL 3.0 weakness can be exploited by a man-in-the-middle attacker to decrypt “secure” HTTP cookies, using techniques from the BEAST attack [BEAST]. To launch the POODLE attack (Padding Oracle On Downgraded Legacy Encryption), run a JavaScript agent on (or on to get the victim’s browser to send cookie-bearing HTTPS requests to, and intercept and modify the SSL records sent by the browser in such a way that there’s a non-negligible chance that will accept the modified record. If the modified record is accepted, the attacker can decrypt one byte of the cookies.”

An attacker could inject the JavaScript agent in a persistent or even reflected Cross-Site-Scripting (XSS) attack, or inject this code within the context of an established Man-in-the-Middle attack. This could be used to cause the victim’s browser to send the attacker cookie bearing HTTPS requests; which, in turn, can be modified and, if accepted by the server, could allow the attacker to decrypt the cookie, one byte at a time.


Due to the fact that this vulnerability must be exploited within a chosen-plaintext context, the only probable exploitation scenario with any significant impact is within a web context. For an attacker to successfully exploit this vulnerability, multiple highly specific conditions must exist. These conditions include the following:

  • The attacker must be able to intercept and manipulate traffic between the client and server (as in a Man-in-the-Middle scenario)
  • The attacker must be able to execute custom JavaScript code to initiate multiple crafted requests within the context of the victim’s browser

Despite the special circumstances and high level of skill required to exploit this vulnerability, the impact of a successful attack would be significant. Successful exploitation could result in an attacker gaining access to small pieces of highly sensitive encrypted traffic such as session tokens. Acquisition of these session tokens could be used in session hijacking attacks to completely take over a victim’s session within the context of the web application.


Server Identification

Server Testing with OpenSSL Client:

To determine if a particular service is vulnerable, use the SSL client in SSLv3 mode and supply the server name or IP address in conjunction with the port number of the service in question. If the connection succeeds then SSLv3 is enabled:

openssl s_client -connect <server>:<port> -ssl3

openssl s_client -connect -ssl3

Server Testing with Nmap:

The SSL-enum Nmap Scripting Engine (NSE) script can also be used to determine if servers are vulnerable. Nmap should be executed with the syntax provided below:

nmap <server> –script ssl-enum-ciphers -p <port>

nmap –script ssl-enum-ciphers -p 443

If the scan returns a list of support ciphers under the SSLv3 header, then SSLv3 is enabled.

|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA – strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA – strong
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA – strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA – strong
|       TLS_RSA_WITH_AES_128_CBC_SHA – strong
|       TLS_RSA_WITH_AES_256_CBC_SHA – strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA – strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA – strong
|       TLS_RSA_WITH_RC4_128_MD5 – strong
|       TLS_RSA_WITH_RC4_128_SHA – strong
|     compressors:
|       NULL

Server Testing with SSLLabs:

Qualys has made a web-based testing utility available at the URL listed below. This can be used to test public facing servers.

If the scan returns indication that there is still support for SSLv3, then the server is vulnerable.

poodle 1

Client Identification

Browser Client Testing with Poodle Test:

A web-based test has been constructed to test client browsers and determine if they are vulnerable to the POODLE attack.

If your browser is vulnerable, the site will display the following image:

poodle 2


Unfortunately, there is no patch remediation for this vulnerability. However, SSLv3 is a depreciated protocol and should be disabled on both servers and clients (browsers). Further, both Mozilla and Google have posted that they will be updating both FireFox and Google Chrome, in the coming months, to disable SSLv3 support. However, it should be noted that disabling SSLv3 could potentially break some websites or legacy web applications that support SSLv3.

Browser Remediation

Remediation on Microsoft Internet Explorer:

Click the Settings button at the top-right corner of the browser, and then select ‘Internet Options’. Then browse to the ‘Advanced’ tab. In the Settings menu, scroll to the bottom and uncheck the box labeled ‘Use SSL 3.0’. Once completed, click ‘Apply’ then ‘OK’.
poodle 3

Remediation on Mozilla FireFox:

In the URL address bar, browse to ‘about:config’. You will then be given a warning, indicating that you should only modify these settings if you know what you are doing. We do, so click the button to disregard the warning and proceed. Then, in the Search bar, type ‘security.tls.version.min’. Double-click the setting with that Preference Name and then change the integer value from 0 to 1. Once this change has been made, click ‘OK’. This will disable SSLv2 and SSLv3, and only allow the browser to support TLSv1 and later.

poodle 4

Remediation on Google Chrome:

Ironically, despite the fact that it was a Google team that identified this vulnerability, Chrome’s GUI management interface offers no option to disable support for SSLv3. A common workaround is to start Chrome from a shortcut that leverages the command line argument to disable support for SSLv3.

To do this, right-click your Google Chrome shortcut and select ‘Properties’. Then, append the command line argument ‘ –ssl-version-min=tls1’ to the end of the value in the Target field (as seen in the provided image). Click ‘Apply’ and then ‘OK’. Once this modification has been made, support for any versions prior to TLSv1 is disabled anytime the browser is started from this Shortcut.

poodle 5

Server Remediation

Remediation on Apache Server:

Modify the SSLProtocol directive in the server’s ssl.conf file to disable support for versions earlier than TLSv1 on Apache. The location of this file may vary depending on the build of the server.

For Ubuntu, the file can be modified with:

sudo nano /etc/apache2/mods-available/ssl.conf

If mod-ssl is enabled, the location will be:

sudo nano /etc/apache2/mods-enabled/ssl.conf

For CentOS, the file can be modified with:

sudo nano /etc/httpd/conf.d/ssl.conf

In the configuration file, modify the SSLProtocol directive to include the following:

SSLProtocol All -SSLv2 -SSLv3

To verify the configuration change, use the following:

apachectl configtest

Once support for SSLv2 and SSLv3 has been disabled, the Apache service will need to be restarted. This can be done with the following command:

sudo service apache2 restart

Remediation on IIS:

To disable support for SSLv3 on Microsoft IIS, a registry tweak is required. Open the registry editor (with command ‘regedit’) and then browse to the following key:


Inside the Protocols key, there should be a key called ‘SSL 3.0’ and inside that key, there should be a key called ‘Server’. If these keys do not exist, create them. Then, inside the ‘Server’ key, create a DWORD value called ‘Enabled’ and then leave its value at 0 (default). Once completed, restart the server to implement the new changes.

poodle 6

Remediation on NGINX:

Modify the ssl_protocols directive in the nginx.conf file to disable support for versions earlier than TLSv1 on Nginx. This file is located at /etc/nginx/nginx.conf and can be modified with:

sudo nano /etc/nginx/nginx.conf

Modify the ssl_protocols directive in the file to include the following:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

To verify the configuration change, use the following:

sudo nginx -t

Once support for SSLv2 and SSLv3 has been disabled, the nginx service will need to be restarted. This can be done with the following command:

sudo service nginx restart


In the event that you are not prepared to disable the use of SSLv3, downgrade attacks can be alternatively mitigated in some distinct scenarios by using a browser that supports a new cipher suite value called TLS_FALLBACK_SCSV. In the event that both the server and client browser support this option, a more secure negotiation process is used that prevents downgrading to a protocol or cipher that is less secure than the highest mutually supported option.

Unfortunately, at this time, limited support on the server-side and limited adoption by client browsers has made this an ineffective, comprehensive solution for this problem.

Presently, TLS_FALLBACK_SCSV is only supported by Google Chrome 33.0.1750 (February 2014 Build) and later. Other major web browsers will likely adopt support in the following months.


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:

Shellshock – Security Technology Vendor Information

Based on the requests of our clients, as discussed in our previous blog post “How shocking is “Shellshock?” below is a list of security technology vendors whose solutions are susceptible to the Shellshock vulnerability. This list will be regularly updated to provide you with timely information on the security technology vendors that you rely on to protect your organization.

Last Updated: Wednesday, October 1, 2014 13:47 EDT


How Shocking is ‘Shellshock’?


The Shellshock vulnerability is present in the Bourne Again Shell (Bash) versions up to and including 4.3. Bash is a popular command shell for Unix and Linux operating systems, and it is often the default shell for many platforms, including OSX.

The version of Bash can be easily be identified by using the bash –version command.

# bash --version
GNU bash, version 4.2.37(1)-release (i486-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>

This vulnerability is actually quite simple and easy to understand. Bash allows functions to be defined in environment variables and processes such functions when a session is initiated. However, the processing does not stop at the end of the function definition, like it should, but it instead continues to process subsequent commands in the string.

Consider the following environment variable. The blue text is a standard function definition, and the red text contains two additional commands. These commands will print (echo) the word “Vulnerable” to the screen, as well as print the id of the current user. Note that commands are separated by semicolons (“;”).

DEMO="() { ignored; }; echo Vulnerable; /usr/bin/id"

This environment variable can be defined using the export command.

# export DEMO="() { ignored; }; echo Vulnerable; /usr/bin/id"

This alone does not trigger the vulnerability. However, the env command can be used to list the environment variables and confirm that this new variable has indeed been defined.

# env
DEMO=() { ignored; }; echo Vulnerable; /usr/bin/id

Now, if a new Bash session is started, the word “Vulnerable” and the current user ID information are displayed, as expected.

# bash
uid=0(root) gid=0(root) groups=0(root)

The primary attack vector for remote exploitation is currently Apache web servers that are hosting CGI applications. This is due to the fact that this configuration, as denoted in the CGI specification, allows environment variables to be created from user-controlled input. Several avenues for defining custom environment variables exist, but HTTP headers are the most straightforward.

The following example is a standard HTTP GET request that contains a custom header (Demo), which includes a function definition and additional id command.

GET /cgi-bin/test.cgi HTTP/1.1
Host: localhost
Accept-Encoding: identity
Demo: () { ignored;}; /usr/bin/id
Content-type: application/x-www-form-urlencoded

Submitting this request to a CGI script hosted by Apache creates the following environment variable.

HTTP_DEMO="() { ignored;}; /usr/bin/id"

Again, simply defining the environment variable does not result in automatic code execution. The underlying CGI script must meet specific conditions as well. Consider the following CGI script. This script simply executes the ifconfig command (which would display network interface information if returned to the user). This script is not vulnerable to attack.

print "Content-type: text/html\n\n";

However, the following script effectively executes the same command, but it first initiates a new Bash session. This script is therefore vulnerable.

print "Content-type: text/html\n\n";
exec('/bin/bash -c ifconfig');


The impact of successful exploitation will vary considerably based on the target host. Configurations that are properly hardened will suffer less immediate impact than those that are not. For example, exploiting the previous CGI script on a current, default Apache installation only results in a compromise of the limited www-data user, as shown below.

$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Granted, any level of access is concerning. Even an unprivileged account may be used to obtain sensitive data or fully compromise the system through privilege escalation attacks. However, such a scenario is still far preferable over directly facilitating a full system compromise.

While the above demonstration is currently the most likely attack vector, any service that both allows users to define environment variables and initiates additional Bash sessions is vulnerable to attack. Proof-of-concept exploits are already starting to surface for other services, such as DHCP.


As one can imagine, the attack vectors for this vulnerability are numerous. Because this flaw is so tightly linked to the underlying operating system, any Unix or Linux service that runs in a Bash environment is potentially vulnerable. However, identifying vulnerable systems on your own is also trivial. In addition to basic version checks, as shown in the first command excerpt, you can simply open a shell and run the following command (Vulnerable systems will print the word “Vulnerable” to the display):

# env SHELLSHOCK="() { :;} ; echo Vulnerable" /bin/bash -c test

Detection methods, remediation procedures, and exploitation prevention signatures are all in various stages of development, with many vendors already developing and releasing patches. While opening a shell on every Unix/Linux-based network host you’re responsible for may not be feasible, the immediate priority should revolve around identifying accessible Unix/Linux services and conducting further analysis. Public-facing services should be reviewed first, given their significantly greater exposure, with a review of internal services occurring as time and resources allow.

The following two commands will provide an initial list of common Unix, Linux, and OS X/Mac services that are accessible on the specified network range(s), and the underlying host’s operating system should be reviewed for the presence of this vulnerability.

# nmap --open -oG shellshock.gnmap -sV -O <network range(s)>
# grep –i "linux\|unix\|os x\|mac" shellshock.gnmap

You can use virtually any scanner to search for this vulnerability on your network, or write your own based on version or echo checks, but vendors such as Tenable, Rapid7, and Qualys have already rolled out updates to support detection of vulnerable systems.


The most effective remediation strategy obviously consists of applying patches to affected systems. Patches already exist for most Linux distributions, such as Red Hat and Debian. As of this writing, OSX v10.9.5 and earlier are vulnerable, and Apple has not provided any information regarding when a patch will be available. However, an immediate workaround does exist, if one is willing to manually recompile Bash on OSX. If the system or device does not allow operating system patches to be applied directly, contact the vendor for such a vulnerable host in order to obtain specific remediation instructions. While Linux is commonly used across a wide range of systems and devices, limited administrative functionality may require firmware updates or other custom remediation procedures.

This vulnerability also presents an opportunity to review systems for unnecessary or unhardened services, such as FTP, Telnet, SSH, HTTP/S, and DHCP. While some services will undoubtedly be immune to this attack, obscure attack vectors will likely continue to surface for the foreseeable future, and a service shouldn’t be considered secure simply because a proof-of-concept exploitation technique doesn’t currently exist.

Unnecessary services should be disabled (or restricted via firewall access-control lists, at a minimum) in order to reduce a host’s overall attack surface. Furthermore, services that must remain accessible should be hardened as much as possible. For example, triggering this condition via SSH requires valid credentials, and implementing keys-based authentication will reduce associated risks further than traditional password-based authentication.

Prevention capabilities will evolve as additional exploits are made public or discovered in the wild. As mentioned earlier, the most likely attack vector is currently via Apache mod_cgi scripts. This is evident by the fact that several proof-of-concept CGI exploits have already surfaced on the web, and a corresponding Metasploit exploit module has also already been developed. However, the defensive side is moving just as fast, and this CGI-based attack vector can be mitigated with mod_security rules published by Red Hat, F5 LineRate (of course, there’s an F5 BIG-IP iRule as well), and Cisco has also updated their signatures to detect and block these attacks. Contact your security control vendors for further information regarding their options for attack prevention.

Finally, be advised that many embedded systems and other devices, including but not limited to printers, security cameras, environmental monitoring solutions, SOHO routers and switches, Network Attached Storage (NAS) devices, and many types of consumer electronics are likely susceptible to this vulnerability as well. Furthermore, these devices could be difficult or even impossible to patch, and as detailed above, access to network services should be disabled or restricted at the bare minimum.

Consumers should be on the lookout for firmware updates from the manufacturers of these devices, and the device and perimeter network configuration should be reviewed to determine which, if any, services are directly exposed to the Internet. Publicly-accessible services in particular should be disabled or restricted in order to avoid exploitation. These random, Internet-accessible devices may pose the largest threat, as they are easy to overlook and may remain accessible and vulnerable for extended periods of time. Research is already underway to convert proof-of-concept exploits into self-propagating worms.


For additional information on this subject and the opportunity to ask questions, please click here to register for our Webinar titled:  How Shocking is ‘Shellshock?’, occurring on Sept. 29th, 2pm (EDT).


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:

Securing People and Assets Via Mobile Security

Banner two

GuidePoint Security is adding another partner to its portfolio of technologies.  In an effort to provide its clients with best-of-breed solutions, GuidePoint Security has expanded its list of partners to include Bluebox Security™. Bluebox was chosen as a new partner for its unique ability to deliver enterprise visibility, security, and control of mobile data, while simultaneously enabling mobile productivity for employees, without compromising their privacy.

GuidePoint Security understands the importance of mobile security and how it plays a significant role for the people and businesses it protects.  By adding another mobile security vendor, GuidePoint Security has expanded it’s reach to provide the best service possible to its existing and future customers.

“Mobile Security has been redefined, and Bring Your Own Device is here to stay,” said Justin Morehouse, Founder and Principal at GuidePoint Security.  “This partnership expands our offerings to confirm us as a leader in Information Security.”

“GuidePoint Security was founded by Information Security veterans who understand the importance of a data-first security strategy, and we are thrilled to have their endorsement both as a customer, and a partner,” said Caleb Sima, CEO, Bluebox Security. “The combination of GuidePoint Security’s deep domain expertise with Bluebox’s next-generation solution, will allow companies to rethink their mobile security approach to reduce risk in today’s rapidly changing mobile landscape.”

In order to further solidify the relationship between the two companies, GuidePoint Security and Bluebox are co-hosting a live webinar: 10 Questions CISOs Should Ask About Mobile Security. The webinar will be an interactive conversation about factors CISOs should be considering when implementing a mobile security solution.

The mobile landscape is changing rapidly, creating new challenges and opportunities for CISOs tasked with balancing business enablement and risk. This webinar provides a great opportunity for people to get in-depth information about how the partnership works and how it can benefit their business.  Click here to register.

Read additional news about this partnership: GuidePoint Security Secures Mobile Data With Bluebox Security.

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. GuidePoint Security is a small business. Classification can be found with the System for Award Management (SAM).  For more information visit

About Bluebox Security

Founded in 2012 by a team of security experts, Bluebox Security offers the first mobile data security solution to safeguard corporate data across the device, application, and network. The cloud-based solution provides complete visibility and security of corporate data, while providing employees the freedom, ease of use, and privacy that ensures widespread adoption. Bluebox Security has received a total of $27.5 million in funding from Andreessen Horowitz, Tenaya Capital, Sun Microsystems co-founder, Andreas Bechtolsheim, SV Angel, and Google Board member Ram Shriram. The company is headquartered in San Francisco. For more information visit


Data Protection & Information Sharing in the Federal Government and Beyond

Today, organizations across the country are struggling to keep their data secure. As discussed in an interview with the Modern Network on April 24, Matt Keller, Vice President of Federal Services at GuidePoint Security, goes on to explain “that the single largest challenge faced by defense and intelligence agencies is protecting their data from both external and insider threats. Information security is a top priority for both agencies as well as other organizations because of a common characteristic: they are all at risk for data leakage.”

Some environments are more vulnerable to data disclosure – either from an external hacker publishing their findings on Pastebin or other forms of disclosure. On the other hand, the Trusted Insider is what threatens the Federal Government’s networks.  Since Bradley Manning released information to WikiLeaks in 2010, the Federal Government has heightened its awareness of the Insider Threat.  This was even more compelling in May 2013 when Edward Snowden released highly classified data about the United States and its Allies.  In 2011, President Obama signed Executive Order 13587, which states that the Federal Government made a commitment to “Improve the Security of Classified Networks”.  This has created strain across the Federal Government to secure the data and simultaneously allow for collaboration of information among Intel Analysts.  The lack of collaboration was the finding of the 9/11 commissions and the Federal Government is still working to tear down these stove pipes.

Creating an environment that enables the workforce to collaborate freely while also keeping data secure is important.  Approaching the security of data is critical for the US Government but also individual organizations.  This trend of the Trusted Insider releasing information to competitors and/or the public is concerning and the typical answer isn’t to secure the sensitive data and toss the keys. To prevent the throw-away-the-key mentality, it’s important to understand the problem and, thusly, how to address it.  The tricky part is granting access to the data while also monitoring the user who is accessing the data.  This allows timely access to the data while also allowing the data to stay secure across the network.  Other options to protect the data from improper disclosure include deploying a comprehensive security solution to monitor the user, accessing devices only on a host computer, and granting authentication and authorization based on a user’s role. “And it is worth noting that today’s mobile workforce extends into the intelligence and defense communities, where they require delivery of all sorts of information to the edge, including to the warfighter in the field. By employing available Suite B encryption solutions and other applications, it is possible to share secure communications to wireless and wired network endpoints,” said Matt Keller to the Modern Network.

A typical System Administrator like Edward Snowden should have never had access to the data on the servers for which he was conducting maintenance.  Unfortunately, this practice is typical across all organizations.  Most systems admins have direct access to the information.  However, a system admin should only have access to the application and operating system.  If applications were designed correctly, then the user would have access to the information while the system admin would only be able to access the operating system and application hosting the data.  Creating this ability across an enterprise is costly and usually ineffective because most applications don’t allow for Role-based Access Controls and Attribute-based Access Controls.  Most systems deploy a solution with only a few roles deployed within a RBAC or an ABAC system, thus requiring authorization and authentication of a user before he or she can access the data via different means.  Typically this is done by single sign-on or username and password.  Both of these methods are useful but don’t guarantee that a user is who they state they are, since usernames and passwords can be compromised.

In order to enable a secure data-sharing environment, the recommendation is to create an experience for the user that is seamless, while also creating a high integrity of the user’s authorization and authentication.  Utilizing PKI certificates across Government networks allows users to access the data needed while also providing a high fidelity that the data won’t be compromised by the Trusted Insider.  The ability to also deploy user identity to the network is key to keeping the data secure and available, as well as the ability to tag the data. If data is tagged correctly, then a user will be less able to gain access to the information, unless they gain access on a need-to-know basis.  This type of function provides PKI certificates to be enabled with attributes that allow the information to stay secure and possibly inaccessible to the system administrator.

For more information on Data Protection and Information Sharing, join Matt Keller, Vice President of Federal Services from GuidePoint Security on Tuesday, May 27 at 12-1pm for a Federal executive forum on WTOP.  They will discuss the priorities, challenges, and barriers of information sharing in the Federal Government along with a vision for the future of secure data sharing.

About GuidePoint Security, LLC

GuidePoint Security 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. GuidePoint Security is a small business. Classification can be found with the System for Award Management (SAM). Learn more at