Category Archives: Infosec


By now you will have no-doubt heard of the “POODLE” vulnerability, or “Padding Oracle On Downgraded Legacy Encryption”.  Major security standards have, in response to POODLE, advised the discontinuation of SSLv3 and additionally suggested a move to TLS 1.1 and 1.2 in order to prevent other potential avenues of attack.

What is SSLv3 and why is it used?

Whenever you view a “secure” website, such as your online banking application or credit card vendor, you may notice that the address begins with “HTTPS”.  HTTPS in this instance refers to “secured” HTTP – meaning that the identity, confidentiality, and integrity of the HTTP connection is protected by mathematical algorithms.

This protection is established via one of six protocols: SSLv1, v2, v3, TLSv1.0, v1.1, or v1.2.  SSLv1-3 were developed by Netscape, with version 2 released in 1995 and version 3 in 1996.  TLSv1.0 was released in 1999, 1.1 in 2006, and 1.2 in 2008.

Each successive protocol was designed to mitigate potential security concerns in the previous iteration, such that for many years now SSLv2 and earlier were considered insecure and disabled by default; SSLv3, while problematic, was thought to be “good enough” and was left enabled for the purpose of interoperability with old servers and clients.

However, due to a succession of severe vulnerabilities in the implementation of SSL and TLS, browser and server vendors have moved to more quickly support newer protocols such as TLSv1.1 and TLS1.2, making the need to support SSLv3 less important.

The final nail in the coffin for SSLv3 was POODLE, an attack released by Google security researchers in October 2014.

What is POODLE?

POODLE is an attack against SSLv3 which allows some amount of information to be leaked, violating the “confidentiality” of the secure connection, by repeatedly interrupting the connection from client to server in a specific way many hundreds of times.  It requires the attacker to have “man in the middle” access, in other words to be able to exist in between a client and a server.  This is possible for some advanced attackers on the internet, and also significantly less advanced attackers in places like coffee shops, hotels, conferences, and other such networks.

How does POODLE work?

POODLE actually is a two-step vulnerability: first it downgrades the connections from any version of TLS to SSLv3, and second it attacks SSLv3.  The downgrade occurs because browser vendors have attempted to maintain connectivity to even old, buggy servers, by attempting older protocols if newer ones result in a disconnect.  Because a man-in-the-middle attacker can cause a disconnect, they can cause a client and server to negotiate on SSLv3 even if TLSv1.0+ are supported.

The attack against SSLv3 works by exploiting the way in which “block ciphers” in SSLv3 encrypt the information being sent between the client and server.  Block ciphers are cryptographic algorithms that are designed to protect information, and the math behind them is generally solid – with the caveat that they can only protect information that has a length exactly equal to their “block size”.

On the web, this means that data on secure websites being encrypted with block ciphers is broken into “block size” chunks, however the data rarely fills all of the blocks neatly and there is some remainder.  This remainder is filled by “padding”, and in SSLv3, there is an unencrypted piece of information at the end of the transmission which specifies the amount of padding used.  POODLE uses this fact as part of an attack that lets a malicious party decrypt data bit-by-bit.  For a more thorough explanation of how this operation works, I recommend the article “CBC Padding Oracle Attacks Simplified – Key Concepts and Pitfalls“.

How can POODLE be mitigated?

Because it relies on SSLv3 being supported, the ability to downgrade from newer protocols to SSLv3, and on block ciphers being supported for SSLv3, there are essentially three possible solutions:

  1. Remove the ability for an attacker to forcibly downgrade the connection
    1. Option 1 is viable for servers which support something called TLS_FALLBACK_SCSV – this is a “phony” cipher suite which may be triggered by a downgrade attempt, and on triggering, if the server notices that it appears as if the connection is being downgraded, an exception is thrown to thwart the downgrade attempt.
  2. Remove support for SSLv3
    1. Option 2 is the preferred solution, as it gets to the problem at its root.  Disabling SSLv3, however, requires that all necessary clients support at least TLSv1.0 in order to continue communicating with the server.
  3. Remove support for block ciphers in SSLv3
    1. Because the only non-block-cipher available for SSLv3 is RC4 (which is a “stream cipher” that encrypts data on-the-fly and avoids needing padding), and RC4 is also very insecure, option 3 is out.

What has ESP done?

When it came to ESP’s attention in October 2014, we immediately moved to disable SSLv3 on our online banking platform and other core platforms.  Since then we’ve also worked to remove it from less sensitive services, and in addition we have enabled TLS_FALLBACK_SCSV where available.

Because our core platform does not use SSL/TLS to protect information transit, it was not affected.

What can you do?

You can scan websites or ranges of IP addresses for SSLv3 support by using these two tools:

  1. Scan a website for POODLE:
  2. Scan a website for detailed security analyses:
  3. Scan an IP range:

November Security Roundup

November has been a very “interesting” month as far as security as concerned. With this past patch Tuesday, a number of serious, high-impact vulnerabilities in Microsoft Windows were released, and this week another out-of-band patch was revealed. In the last year there have been serious Linux vulnerabilities (Heartbleed, Shellshock, etc), and now it seems that it is Microsoft’s turn – in fact, one such exploit has been dubbed “Winshock”.

The Vulnerabilities

Due to the sheer number of vulnerabilities that have arisen this month, this post will list those considered to have the highest impact.


  • CVE
    • ID: CVE-2014-6332, CVE-2014-6352
    • CVSS Base: 9.3
    • “This security update resolves two privately reported vulnerabilities in Microsoft Windows Object Linking and Embedding (OLE). The most severe of these vulnerabilities could allow remote code execution if a user views a specially crafted webpage using Internet Explorer.”


  • CVE
    • ID: CVE-2014-4143, 6323, 6337, 6339-6351, 6353
    • CVSS Base: various; 8-9
    • “This security update resolves seventeen privately reported vulnerabilities in Internet Explorer. The most severe of these vulnerabilities could allow remote code execution if a user views a specially crafted webpage using Internet Explorer.”

MS14-066 “WinShock”

  • CVE
    • ID: CVE-2014-6321
    • CVSS Base: 10
    • “This security update resolves a privately reported vulnerability in the Microsoft Secure Channel (Schannel) security package in Windows. The vulnerability could allow remote code execution if an attacker sends specially crafted packets to a Windows server.”



As a part of our daily security procedures, we look for emerging news on security vulnerabilities and monitor our environment for unusual network traffic, error logs, firewall actions, and other indicators of compromise.

We were able to patch the major “WinShock” vulnerability within several hours of discovering it, on the day the patch was released.  No indicators of compromise were found after correlating relevant security details.  Additionally, we use patch management software internally to schedule automatic update installation across internal devices, in this case as an on-demand patch that applied across all machines.

The Shellshock Exploit


Yesterday afternoon, an exploit called Shellshock came to light on a security message board .  CVE-2014-6271, as it is called by National Vulnerability Database, allows a remote user to execute arbitrary or malicious commands on a remote server, such as those that host websites; it has been given the highest impact rating, 10, for this reason .


This exploit presents a tremendous risk reminiscent of Heartbleed, because it potentially impacts many thousands of websites and other servers on the internet. A vulnerable system would allow any remote, unauthenticated user to run commands on the server, potentially allowing them to perform malicious activities: phishing, stealing data, installing a rootkit, etc.

Vulnerable Systems

Any system running Bash up to version 4.3 is potentially vulnerable, which includes Linux, Unix, and Mac OS X operating systems . The main avenue for remote exploitation of this bug is via websites served by CGI, which is a common mechanism for providing applications powered by PHP, Perl, Python, or many other languages.

Already there have been multiple reports of this exploit being used in the wild , so it is vital to examine your own environment for any unix-like systems that have Bash installed, and to apply vendor-provided patches where applicable.

You can use this tool to attempt to determine if your website is vulnerable, use the newly-available metasploit module , or run this command from a terminal on your Linux/Unix machines:

env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

If this command returns “vulnerable”, then you are vulnerable to CVE-2014-6271 and should patch your system immediately! If you run this:

env X='() { (a)=>\’ sh -c “echo date”; cat echo

And the date prints out, then you are vulnerable to CVE-2014-7169 and should attempt to patch, or sit tight until your vendor releases one, using other mitigation techniques in the short-term until such a patch is available. Currently, Debian, Ubuntu, RedHat, Gentoo, Slackware, and Suse have fixes or patches available.


Here at ESP, we’ve mostly been spared – as with Heartbleed – because our applications are primarily written in ASP.NET, and hosted in an environment that lacks any installation of Bash. Additionally, our auxiliary web servers run PHP via a module rather than CGI, which is required in most instances for remote exploitation of the bug; these servers were patched after our vendor provided updates to address the flaw.


There are several ways to mitigate this vulnerability in your own environment. Some of these avenues are listed below, along with a short explanation.

Patch pertinent systems

The easiest and most vital solution is to apply patches to any systems that you can determine are affected by Shellshock. On Debian systems, for example, this can be as simple as running “apt-get update; apt-get upgrade” in the terminal. The first available patches did no fully mitigate all attack strategies , so a second update may be required; the particular ID associated with the incomplete patch is CVE-2014-7169, and updates addressing that vulnerability have been released by several major vendors . There may be a possibility new variants of the attack, so keep checking over the course of the next several weeks and apply any superseding updates. Ask your vendors if any of their software is vulnerable and/or needs to be patched.

Use mod_php

For this vulnerability, because remote exploitation of websites requires that they be served via CGI, you could potentially mitigate Shellshock by serving your site with a module or a different form of CGI instead; if you use Apache, you can use mod_php as a temporary measure, for example. Whether socket-based CGI applications (e.g., php-fpm with nginx) are vulnerable is still being investigated , but mod_php should be safer, if you make sure that your code does not call Bash in any way that a user can alter.

Use alternate shells

Another temporary mitigation strategy is to uninstall Bash, and use a different shell as default, such as Dash .

Use firewall rules

Since this bug can affect web servers as well as OpenSSH servers, you should examine your firewall rules to make sure that only necessary sites/services are exposed to the internet. If a server is for internal use and has no business-case for being available externally, block access to it.

Further Reading

Dropbox: phishing from the cloud

phishing-fax-exampleFor the last few months, a number of phishing campaigns have been utilizing the free file-sharing platform, Dropbox, to distribute malware to hundreds of thousands of PCs.  Disguising itself as a fax notification or voice message, the email contains a link to a publicly-accessible Dropbox location containing an infected executable file.  The actual payload of these campaigns vary, but two prominent examples are that of Dyre and CryptoWall.

It remains to be seen whether more malware will be distributed in this manner, but the possibility is likely — you should act to protect yourself and your institution from any threat, and it would be wise not to overlook the possibility of Dropbox to act as a vector for infection like any other.


In many instances, the campaign deploys a variant of CryptoLocker, which proceeds to encrypt large numbers of files on the infected computer — these files are then mathematically protected from their owner, unless a bribe in the area of $500-$1000 is paid to regain access to them.  Once encrypted, these files can only be regained through an unaffected backup, paying the ransom, or possibly through advanced computer forensics.

On the other hand, we have the Dyre trojan: it injects code into a target’s web browser, enabling them to sniff out online banking credentials from a range of institutions, ferrying them off as potential targets for identity theft.  Dyre can operate in common browsers including Chrome, Firefox, and Internet Explorer.  Note that even if your institution is not explicitly targeted by Dyre today, that may not be true forever.  Theoretically, Dyre could be retooled to target much more information than it presently does.


The commonality between these two threats is in their hosting mechanism: Dropbox.  Disguised in a cleverly-worded email campaign, the intended target must click on a link which points to the malware, and this link itself is somewhat predictable.

The reason it works is that many enterprises allow Dropbox through their networks. If they’re looking for bad domains, they’re not looking for because everyone and their uncle uses it — Ronnie Tokazowski 

Blocking Dropbox Emails

If you know that no employee should be accessing files shared publicly from Dropbox, or have the capability to whitelist such activities where they occur, you can use your email filtering system to block messages which contain links to the following locations:

  • **
  • **
  • **

 Blacklisting Dropbox Domains

Similar to the email strategy, you can use your existing proxy or web filtering platform to limit access to those locations listed above.

Train your Users

Ultimately, this infection vector relies on the assumption that somewhere, someone will click on the link and run the infected program.  You can help to prevent this by training your users on how to spot and ignore fraudulent emails, why they should not download strange attachments, and what to do when some application requests permission to run or to elevate (UAC).  Washington State University has a short list of guidelines to help prevent infection from email.

Thinking Ahead

While both of these threats are currently propagating mainly through Dropbox, be aware that there exist many competitors and alternatives, any of which may potentially be used by a malicious party for the delivery of a Trojan or other piece of malware.  Cubby, one such alternative, has already been detected as a source of Dyre, and the list may grow in the future.

You should examine the potential risk of someone downloading content from these sites in much the same way that you examine any risk, and use the tools at your disposal to limit that risk wherever possible, whether by blacklisting the domains, enforcing firewall-level antivirus scans, blocking executable downloads, or any other appropriate means.

Further Reading

Heartbleed and You


Early in the morning of April 8th, ESP’s security team discovered news of a new vulnerability in a specific version of OpenSSL, which is used to provide encryption for websites using SSL/TLS encryption (HTTPS).  This new, serious vulnerability affects a large portion of the internet, and may be exploitable on some sites for months to come.

Potential Risks

The vulnerability allows an attacker to retrieve up to 64kb of memory in a server by sending a bogus request. As such, it could potentially allow for several avenues of exploitation:

  1. Stealing logins from the web server
  2. Stealing the website’s SSL certificate and private key
    • Using this SSL certificate and private key to create a man-in-the-middle attack, pretending to be the website in question
    • Using this SSL certificate and private key to decrypt previously captured traffic 

Member Impact

While we do not believe it is likely that any client had their credentials stolen from ESP via Heartbleed, they may have used the same credentials on other websites that were. Thus, we believe that it is prudent for members to reset their online banking login credentials to something new and unique.

Members who use Yahoo email are especially vulnerable, as Yahoo email accounts were vulnerable for much of Tuesday morning, and an attacker could use the “forgot password” feature of online banking to send a reset email to the member’s email address, or try using the Yahoo password on online banking (if they were the same).

You can find members who used Yahoo email accounts with our online banking platform by running the Member Email Report in Forza and exporting to excel from the report. You can then notify members and recommend changing email and OASIS passwords by, for example:

  1. Posting a message on your website
  2. Putting up a poster at the branch
  3. Adding a message to the Oasis sign-on page
  4. Adding a message to your phone system’s welcome message

Further Reading

More detailed technical information about the Heartbleed vulnerability can be accessed from its website, or from the National Institute of Standards and Technology.  You can check if a website is still vulnerable using this tool.