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.


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:

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

What Universities and Colleges Do the Best Hackers Come From? Here’s One in Particular: UCF!

University of Central Florida (UCF) won 1st Place at the National Collegiate Cyber Defense Competition (CCDC) that took place April 25-27 in San Antonio, TX.  This annual competition was started in 2005 in conjunction with the Department of Homeland Security to improve cyber security education and increase the number of highly qualified cyber security graduates in the U.S.  This Championship brings the best of the best hackers from universities all over the U.S. to fend off cyber-attacks from penetration professionals and ethical hackers.

Among those winners are GuidePoint Security interns, Carlos Beltran, the Captain of the winning UCF team; and Alex Davis, his team member.

“What sets UCFs CCDC team apart from others is that they focus on the hackers perspective. We want to know how they got in, in order to keep them out,” explained Carlos Beltran.  “There are many reasons I chose to work at GuidePoint Security, but the main reason is because I have a strong desire to learn about security and the methodologies used to perform in real-world environments. GuidePoint Security gives me the opportunity to better my trade and excel in the areas I want.”

“Competitions like this foster learning about computer security, which is something businesses need, as shown by recent breaches like Target. The people coming out of competitions like CCDC will help prevent data breaches such as the ones we have seen on the news from happening,” said Alex Davis.  “I like learning how technology works, and I discovered that the best way to learn how things work is to focus on how systems can be exploited, and how to secure them. I enjoy the field, and working at GuidePoint Security allows me to do what I enjoy.”

According to the WSJ article, “University of Central Florida wins 2014 Raytheon National Collegiate Cyber Defense Competition”, more than 180 colleges and universities and 2,000 undergraduate students participated in the competitions that lead up to this year’s national championship.  The Raytheon website listed the following 10 regional champions with UCF coming in first place:

  • University of Central Florida – Southeast Regional
  • Air Force Academy – Rocky Mountain Regional
  • Dakota State University – North Central Regional
  • University of Alaska, Fairbanks – At Large Regional
  • Southern Methodist University – Southwest Regional
  • Rochester Institute of Technology – Northeast Regional
  • Western Washington University – Pacific Rim Regional
  • University of California, Berkeley – Western Regional
  • Towson University- Mid-Atlantic Regional
  • Northern Kentucky University – Midwest Regional

“While the competition has existed since 2005, UCF only very recently started competing. Shortly after I started teaching at UCF in August 2013, two of my students approached me to ask if I would be willing to sponsor a UCF team for this competition.  I realized the tremendous opportunities this competition would provide for our students.  I eagerly agreed and this is the second year UCF has entered a team.  It is also our second appearance at the National competition.  Each year, the team enters a virtual qualification round.  Eighteen teams from our 7-state Southeast region entered the qualification round including UCF, FSU, and USF from Florida.  The top 8 teams from the qualification round are invited to compete in a regional competition.  The UCF CCDC Team finished 1st in the Southeast Collegiate Cyber Defense Competition held in Kennesaw, GA in both 2013 and 2014.  The regional winner earns the privilege to compete in the National Collegiate Cyber Defense Competition in San Antonio, TX along with the winning teams from the other 9 U.S. regions.  In 2013, the UCF CCDC Team finished 10th nationally in our very first year of competition.  This year, the UCF team has captured the national title as the top Collegiate Cyber Defense Team in the nation,” explained Dr. Thomas Nedorost, Department of Electrical Engineering & Computer Science of the University of Central Florida.

2014 UCF Champs

Photo compliments of UCF Collegiate Cyber Defense Club

The winning members of the 2014 UCF Collegiate Cyber Defense Competition Team are: Carlos Beltran, Team Captain Jason Cooper, Team Co-Captain Austin Brogle Alexander Davis Kevin DiClemente Dale Driggs Grant Hernandez Mark Ignacio Heather Lawrence Troy Micka Cody McMahon Joe Pate “The team’s strength lies in their teamwork, cross-training, and dedication to continue learning and improving,” said Dr. Nedorost.  “National CCDC brings together the top 10 cyber defense teams in the nation.  Having the ability to compete at this level is an honor in itself.  The level of competition is fierce.  Seeing UCF bring home the Alamo Cup, the 1st Place trophy, is priceless.”

“We are very proud of our two interns who worked so hard and won this challenging competition” said Michael Volk, Managing Partner at GuidePoint Security. “Congratulations to all who made it and to all who participated!”

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 successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps our 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

Heartbleed – Security Technology Vendor Information

Based on the requests of our clients, as discussed in our previous blog post “The Heartburn of Heartbleed,” below is a list of security technology vendor information pertaining to the Heartbleed bug. 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: Friday, April 18, 2014 8:19 EDT


The Heartburn of Heartbleed

The Heartbleed Bug is a dangerous vulnerability found in OpenSSL.  It potentially allows the compromise of encrypted information, that under normal conditions is secured by SSL/TLS. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM), and some virtual private networks (VPNs).

The following versions of OpenSSL are/are NOT vulnerable to the Heartbleed bug:

  • OpenSSL 1.0.1 through 1.0.1f (inclusive) ARE vulnerable;
  • OpenSSL 1.0.1g is NOT vulnerable;
  • OpenSSL 1.0.0 branch is NOT vulnerable; and
  • OpenSSL 0.9.8 branch is NOT vulnerable.

I won’t go into the technical details of this vulnerability, since that has been done en masse. If you are looking for that level of information, I recommend the following analyses:

There are several misconceptions about Heartbleed, with common ones focusing on end-servers running Microsoft IIS and not evaluating upstream technologies like reverse-proxies, load-balancers, or having users change passwords before a fix has been implemented.

What I do want to discuss is a recommended approach for organizations dealing with the “Heartburn of Heartbleed.” We’ve had numerous clients reach out to us asking for assistance in several areas; identification, remediation, and working with security technology vendors to determine when their fixes will be ready. Here is what we recommend for each of these stages:


There’s been an influx of tools and scripts made available to identify the Heartbleed vulnerability. Below are ones that meet specific use cases:



Vulnerability Management Tools


This is where the heartburn starts. Hopefully, your organization maintains a Threat Management Program and you have already addressed your high-risk assets. If not, here is a triage approach:

  1. Patch perimeter systems first, then critical internal systems, then production systems, and then test/dev systems;
  2. If a patch or configuration fix is not yet available, <insert heartburn here>. Taking a proactive approach, you can implement a reverse-proxy (Load Balancer) that is NOT vulnerable, or can be configured as such, to terminate the encrypted connections, thereby eliminating risk to your web and application servers. If you prefer a passive approach, you can implement signatures on IDS/IPS solutions, but I do NOT recommend relying on these. Snort signatures are available here. Bro Heartbleed module here;
  3. Regenerate all SSL certificates with new private keys;
  4. Replace all SSL certificates with newly generated certificates;
  5. Revoke all old SSL certificates;
  6. Force all accounts on affected systems to expire; and
  7. Communicate to account users the necessity for the password resets. CloudPassage did a good job of this; here is a link to their blog post.

Security Technology Vendors

This is where the heartburn can reach extreme levels. Some vendors have done a great job implementing fixes as soon as updates to OpenSSL were available, however, others have been less than forthcoming with their remediation approach and timelines. These are the solutions that you rely on to protect your organization and their internal failure to identify and remediate vulnerabilities in core components of their solutions in a timely manner has left you vulnerable. If this is the case, I recommend emailing your vendor representatives and letting them know you need this information ASAP. If you have formed an internal task force to deal with Heartbleed, it may be worth mentioning this to the vendor representative, and suggest that being “last” to remediate amongst your vendors is probably a bad idea.

If you utilize a Value Added Reseller (VAR), for example GuidePoint Security, I recommend reaching out to your Account Executive (AE) and asking for assistance. Provide your AE a list of all technology vendors you need assistance with, as you probably own more technologies than you have purchased through them. This is an area where VARs can show some of their “Value.”

Lessons Learned

It is my sincerest hope that organizations embrace this opportunity to take a fresh look at how they are dealing with a number of areas within their Information Security Program. Particularly, I believe Heartbleed has forced organizations to look at:

  • Threat Management
  • Vulnerability Management
  • Patch Management
  • Public Key Infrastructure (PKI)
  • Defense-in-Depth
  • SSL Decryption / Visibility Practices

GuidePoint Security can assist your organization in building and maturing these components of your Information Security program, as well as help procure, architect, implement, and optimize security technologies to support them (Hey, I have to get a shameless plug in somewhere, right?).

*** Updated on 4/10/14 @ 13:49 to include vulnerable/NOT vulnerable versions of OpenSSL, replace the python script with one that does not have false positives and clarify my statement on identifying vulnerabilities in core components of security technologies. ***

Visit GuidePoint Security at InfoSec World, Orlando

Join GuidePoint Security as we highlight and showcase two of our technology partners, Bromium and Skybox.

When:  Monday, April 7-8, 2014
Where:  InfoSec World Conference & Expo, Booth #219, at Disney’s Contemporary Resort, Orlando, FL

GuidePoint Security partners with vendors that offer unique technologies that address the security needs of our clients.  With the complexity of security threats ever increasing, GuidePoint Security offers the right solutions and technologies for our clients’ specific needs. 

These two technology partners offer the following solutions to address today’s advanced security threats.

Bromium provides protection at the endpoint with vSentry, an innovative product that protects against all advanced malware. vSentry automatically creates hardware-isolated micro-VMs that secure every user task – such as visiting a web page, downloading a document, or opening an email attachment.

Skybox delivers cutting-edge risk analytics for enterprise security management.  Their solutions give complete network visibility, help to eliminate attack vectors, and optimize security management processes. Protecting the network and the business.

GuidePoint Security uses their expertise to lead security innovation by helping clients recognize threats, understand solutions, and mitigate risks throughout their IT environment by determining which solutions fit their clients’ needs.  GuidePoint Security offers the people, processes, technologies, and oversight that deliver results to your organization.

Be sure to visit GuidePoint Security at the InfoSec World conference in Orlando, booth #219.

For additional information about the InfoSec World Conference and Expo, visit

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 successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps our 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