SecureState: What state are you in?

Within the last few days, a critical vulnerability has been discovered within OpenSSL, dubbed “Heartbleed,” which can enable an attacker to extract information from the vulnerable server’s memory. OpenSSL is a free implementation of SSL, primarily used on Linux systems and appliances such as VPN concentrators. This blog explains the impact of this vulnerability, recommends ways to detect if it is in your environment, and how to remediate it.



Successful exploitation of this vulnerability could potentially enable an attacker to gain access to the server’s private key, user credentials, session information, or any credit card data stored in the server’s memory. The specific memory content returned to the attacker is random, so the attacker can increase the probability of obtaining sensitive content that is stored in memory by sending multiple SSL\TLS packets to the server. It is estimated that potentially two-thirds of devices on the Internet currently contain this vulnerability.



This is still a rather new vulnerability, but some vulnerability scanners (e.g. Qualys, Nessus, etc.) claim to have released checks to detect it. However, SecureState has found that at least some of these vulnerability checks are not adequate for detecting this vulnerability within the organization’s devices. Although many of the most popular vulnerability scanners are inadequate for identifying this vulnerability, Qualys has a free scanner that they use as part of their SSL Labs project that scans web servers for this vulnerability.

SecureState has found that it is fairly accurate when it comes to the detection of this vulnerability. In this regard, an organization can take all of their sites that use SSL and send them to this scanner ( It should be noted that other protocols, such as SMTP and FTP, can also use SSL, and the SSL Labs scanner only accepts URLs that are associated with websites. A second option would be to use a publically available Python script to check for this vulnerability ( This script has a “starttls” option, which can be used for testing other protocols that use SSL (e.g. FTP, STMP, etc.).

It should also be noted that suspicious traffic which attempts to exploit this vulnerability matches a specific pattern, and IPS\IDS rules can be created to detect and\or prevent this vulnerability. The linked blog  lists some of the SNORT rules that have been created for detecting this vulnerability:

Two modules have been release for the Metasploit Framework: one for testing server-side OpenSSL implementations (auxiliary/scanner/ssl/openssl_heartbleed) and one for testing client-side implementations (auxiliary/server/openssl_heartbleed_client_memory). The module for testing server-side implementations also has support for starttls on POP3, IMAP, SMTP, and JABBER. While a lot of attention has been focused on the vulnerabilities of server-side implementations, it is important to remember that clients can be vulnerable too!



This vulnerability affects OpenSSL versions 1.0.1-1.0.1f, and 1.0.2-beta, and can be remediated by upgrading to OpenSSL 1.0.1g. Additionally, OpenSSL branches 1.0.0, and 0.9.8 do not contain this vulnerability. It should be noted that many third party products (BlueCoat, Juniper, WatchGuard, etc.) use OpenSSL for their SSL implementations. Thus, although the organization may not be running OpenSSL directly, various devices within their organization may still contain this vulnerability. It is recommended that any OpenSSL implementations using a vulnerable version of OpenSSL be upgraded as soon as possible.

Additionally, if there are any devices that utilize a vulnerable version of OpenSSL within the organization, the vendor of those devices should be contacted in order to receive specific recommendations from the third party. Once the specific devices that support the vulnerable version of OpenSSL have been secured, we recommend the following steps be performed:


  • Replace the SSL certificate on the effected systems
  • Revoke the old SSL certificate which was used by the vulnerable implementation
  • Terminate and reinitiate any sessions or connections which may have been hijacked due to the vulnerability
  • Have all users who accessed the service change their passwords. If the impacted system was a VPN concentrator, all VPN users should change their password.
  • Contact SecureState to have an Impact Assessment performed to assess what information may have been compromised and determine what next steps are required to address any security, privacy or regulatory concerns




“Information is power. Do you know what the Internet says about your company?”

Back in 2009 I gave a well-received talk called “Enterprise Open Source Intelligence Gathering” to several conferences and local security groups. More recently, I’ve been part of many discussions with my clients and others in the security community about the increase of company confidential information that is posted by employees, competitors, or even adversaries on the Internet. These conversations have prompted me to revisit this topic to see where we stand since I looked at this several years ago. The short answer is that things have changed, and in many ways quite drastically.


What is OSINT?

OSINT or Open Source Intelligence is basically a form of intelligence collection. In basic terms, it’s any information that is publically available. In modern times this means anything that is available via the Internet in the form of blogs, news, forum posts, pictures, social media, videos and much, much more. OSINT also includes publically available government data. The government and military have their own uses for OSINT as well as businesses and individuals. Basically, whenever you do a Google search on a company or individual, you’re most likely collecting some form of OSINT whether you know it or not.


How does OSINT apply to a business and why should we care?

Over the years there has been a large increase in the posting of user generated content, mainly social media. This has been a difficult transition for many companies, mainly due to the merging of personal and business lives of employees. Bring in BYOD and mobile devices to the picture and you have a “perfect storm” of information leakage, as well as a plethora of problems around company reputation and image. Moreover, many companies now have adversaries that they may not have thought much of in the past. For example, the rise of hacktivists and other groups such as Anonymous have made corporations (large and small) targets for various reasons. Some companies are targets because of the product they sell, others because of the political views of the CEO, or simply are targeted “just for the Lulz”. Not to mention that a company’s competitors are also looking for any information that might give them the leg up in very competitive market place. It’s a different world that we live in and corporations need to understand that OSINT about their company is like gold in the eyes of the competition.


How does a company deal with OSINT?

The first step is to identify the risk that specific OSINT may pose to your organization. Think about the business you’re in, what data or information do you collect, what is it that is the most damaging thing that could happen to your business? Some of these questions can be difficult, especially if the board of directors or C-level executives are targeted personally. However, without defining what we are trying to protect, collecting OSINT can be a daunting task; not to mention monitoring for new information that might be posted.

Next, you need to determine what you’re going to monitor and how. The good news is that you can set up a very simple OSINT monitoring program on the cheap. It could be as simple as Google Alerts and using open source tools to monitor Pastebin and other document repositories. It can also be more advanced, enlisting paid services to monitor for employee password breaches, security vulnerabilities and exposures of confidential information. There are many ways, depending on the type of data, to start a monitoring program. The important thing to note is that it’s very hard, if not impossible, to monitor everything. An organization must also understand that it can’t “bite off more than it can chew” in regards to information collection. Especially on the Internet.


Want to learn more?

I’ll be presenting my revised “Enterprise Open Source Intelligence Gathering” at the InfoSec World conference in Orlando on Monday, April 7 at 3:15pm. I’ll be presenting on tools, techniques and strategies to help an organization collect OSINT and how to approach a monitoring program. If you miss the presentation at InfoSec World, I’ll be giving it again during a webinar later this month. Follow me and SecureState on Twitter for more information on when this webinar is and how to sign up.



Only a few weeks remain and the April 8, 2014 deadline is looming for the more than 12-year old operating system. Microsoft has even posted a countdown timer on their website to illustrate how many days, hours, minutes and seconds remain until life support ends for the Windows XP operating system.


A current state review of an organization’s security program and risk posture at a specific point in time is known as a point-in-time assessment. Point-in-time assessments are a standard practice for many organizations. This practice leads to a two-month “fire drill” in preparation for the assessment, ensuring systems are hardened, documentation is reviewed and updated, and testing and analysis is performed in an effort to ensure compliance requirements are met.


By: Chintan Davis, Infosec Institute

Every organization has a procurement process. Some of the software products acquired by an organization are COTS (Commercial off The Shelf) Solutions. These products are not built or developed in-house by the organization. While some COTS need to be customized to fit into the client environment, the rest of them only need to be configured according to the organization’s needs. In certain cases, organizations have a team of third-party software consultants working to develop a product on their behalf.


Regulations, industry frameworks, “best practices,” and just good ol’ common sense requires businesses to conduct thorough annual risk assessments. The depth of these risk assessments should be proportional to the size, complexity, and inherent industry risk for your business.


The Department of Health and Human Services’ (HHS) Office of the Inspector General (OIG) announced its first investigation into alleged fraud of the 2013 EHR Financial Incentive Program, by the now-shuttered Shelby Regional Medical Center (SRMC), in Center, Texas. Specifically, their former CFO may have filed false attestations of meeting the program’s requirements and subsequently SRMC received $785,000.


Late in 2013, two blogs were released describing in great technical detail the vulnerability identified as CVE-2013-3881. The vulnerability is a NULL page dereference caused by “insufficient pointer validation” in win32k!xxxTrackPopupMenuEx and was patched as part of MS13-081, which affects both Windows 7 and Windows 2008.