Tag Archives: security

Improve Member Confidence

Read about Extended Validation SSL here

It is our goal to ensure that your information is safe and secure, so when we see something that will improve that, we take note. When we see something that can make a positive difference in the eyes of your members, we act. For $199.00/year, we can work with you to implement the new Extended Validation SSL (EVSSL) certificate that has been proven to increase online transactions and improve customer loyalty.

What is the EVSSL?

The EVSSL will be implemented on the login page for Home Banking (A.K.A. OASIS).

“Now when shoppers visit a Website secured with an Extended Validation SSL Certificate, the latest browsers trigger the address bar to turn green and display the name of the organization listed in the certificate, as well as the certificate’s security vendor in some cases. A secure connection has been established between browser and Website, and the Website has been authenticated according to rigorous industry standards. In the example below, the browser controls the display, pulling information from the SSL Certificate and displaying it in the address and security status bar, and making it extremely difficult for phishers and counterfeiters to hijack your brand and your customers.”

 Extra, what extras?

Custom Home Banking Domain

We want to increase the transparency between credit union services and the member. The addition of a new home banking login domain will do that.

Give your members the comfort of seeing the “green” bar and your credit union name associated with all aspects of the login screen. Example below.


Let’s Increase your Member Loyalty

Let us help you increase your member loyalty and provide another tool to better manage the security between your member and the credit union.

Please note, we are not marking this solution up – you can see the price for the certificate on the webpage that we included at the top. We genuinely want to be a part of treating your member information safely and securely.

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

Request a DR Test On-line

In the effort to make processes for our Clients as easy as possible. You can now request a Disaster Recovery (DR) test from the website. Once you fill out the form, we will contact you and get started.

You will be able to test from a remote location if you wish. This is testing as if the CU had a disaster and had to move. All you need is an Internet connection.

You can test to your remote data as well. This test is ran in the event that there is a disaster at ESP.

If you would like to request a Disaster Recovery test time, please visit the form here.

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 dropbox.com 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:

  • dl.dropboxusercontent.com/*
  • dl.dropbox.com/*
  • dl-web.dropbox.com/*
  • dl-client.dropbox.com/*
  • *.dropbox.com/u/*
  • *.dropbox.com/s/*
  • *.dropbox.com/sh/*

 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