All posts by Ben Finke

Superfish – Should you be worried?

Note: Not the same Superfish....
Note: Not the same Superfish….

Last week security researchers discovered a major vulnerability caused by a program that was bundled with new Lenovo computers.  The program in question, made by a company named Superfish, is designed to inject ads into web pages you are visiting, based on your web browsing activity.

“Injecting” ads into web pages is pretty ethically questionable anyway, especially one that tracks your activity on any web page you visit, but it gets worse.  Most sites, like Google, Amazon, Twitter, Facebook, and others use encryption to secure your connection, so that unsavory characters can’t just listen in and track you.  Naturally, if Superfish can’t listen in on your web traffic, they can’t track and/or inject ads into those pages.

So, Superfish devised a method to insert themselves into those secure websites too.  Usually referred to as a Man-In-The-Middle attack (because it is an attack), the idea is to create a faux connection from the customer (you, in this case) and the website you want to use (anything that uses encryption).

A man-in-the-middle attack
A man-in-the-middle attack

Of course, the magic of the encryption used to secure web pages requires you to have the public key (usually called the certificate) and the private key (kept strictly private).  As you can imagine, Google doesn’t lend their private key out to interested parties, so the solution is to create your own certificate, install it on the victim, I mean customer’s, computer, and then you can sit right in the middle of that “secure” connection, present a certificate for any site to the customer (which your browser will happily trust – it’s installed as “trusted”, after all!), and watch everything going back and forth.

You are probably asking yourself what the big deal is.  Here’ the problem: the certificate that Superfish installed on your computer, just so that they can inject ads into your web browser, can be used by other attackers too.  Remember that private key we mentioned earlier?  Turns out that the Superfish crew used the same one on ALL of the computers the software was installed on.  An attacker who found the private key would have the ability to impersonate ANY website visited by someone with this software installed.

Just like a password, it doesn't matter how complex the private key is if everyone knows it....
Just like a password, it doesn’t matter how complex the private key is if everyone knows it….

Recognizing now that perhaps this is a bad idea, Lenovo has released a removal tool, that not only removes the Superfish software, but also pulls out the certificates that were installed along with it.  Kudos to them for doing so.  You can find the removal tool here:

So, should you be worried about Superfish?  If you bought one of the following Lenovo computers between September 2014 and January 2015, then you probably have it installed right now.

G Series: G410, G510, G710, G40-70, G50-70, G40-30, G50-30, G40-45, G50-45
U Series: U330P, U430P, U330Touch, U430Touch, U530Touch
Y Series: Y430P, Y40-70, Y50-70
Z Series: Z40-75, Z50-75, Z40-70, Z50-70
S Series: S310, S410, S40-70, S415, S415Touch, S20-30, S20-30Touch
Flex Series: Flex2 14D, Flex2 15D, Flex2 14, Flex2 15, Flex2 14(BTM), Flex2 15(BTM), Flex 10
MIIX Series: MIIX2-8, MIIX2-10, MIIX2-11
YOGA Series: YOGA2Pro-13, YOGA2-13, YOGA2-11BTM, YOGA2-11HSW
E Series: E10-30]

The Thinkpad line from Lenovo was not shipped with the Superfish adware installed, according to Lenovo.

If you have a company issued laptop (especially if you are an Enterprise Integration customer), your machine was likely reloaded with a purpose-built Microsoft Windows image that does not have any of this type of software installed.  If you purchased a Lenovo for yourself or your family, you should take a few moments and try the removal tool from Lenovo.

The bigger question that remains: How many more Superfish situations exist, and how can you protect yourself from these unknowns?  We’ll address that in a follow up post.

Thanks for reading, and stay safe out there!

More information can be found here:

BSides JAX – Who Should Use PowerShell? You Should Use Powershell!

B-Sides Jax LogoI was fortunate enough to present at the recent BSides Jacksonville Information Security conference.  What an awesome event that was.  We’ll be posting more about BSides Jax in the very near future, but a few kinds souls have asked for the slidedeck to my presentation “WHo SHould Use Powershell? You Should Use Powershell!” in some consumable form, so here it is!

Thanks to everyone who came out to the conference, and to Jess Hires and the entire BSides Jacksonville team for putting on an awesome event!



Wirelurker – Malware attacking iPhones and iPads

iOS devices targeted through the Apple computers they connect to

Researchers from Palo Alto Networks recently released a study where they found a new piece of malware targeting Apple Mac computers and iOS devices.  Dubbed “Wirelurker”, this piece of malware is not terribly sophisticated, but does operate differently than previous malware.  So is this a serious threat, or the malware du jour?

Early signs are that this particular malware attack is not likely to infect your Apple Mac or iOS device, but the attack method it is using is pretty new, and definitely worth looking into.

Wirelurker targets iOS devices through the Apple computers they connect to.  Basically, the trojan is bundled into pirated versions of software (in this case, mostly in China).  When the pirated software is installed on a Mac, it sits and waits for an iPhone or iPad to be connected.

When an iOS device does connect to the infected computer, the Wirelurker software captures the device serial number, the phone number, the iTunes identifier (the email address you sign into the Apple App Store with), and other identifying information.  This information is only available when you’ve enabled the “Trust This Computer” option, which you have to in order to sync with iTunes.  The captured information is uploaded to various Command and Control (C&C) servers on the Internet.

The Wirelurker software also attempts to install malicious versions of normal looking applications on your iOS device.  If your phone is jailbroken, then the attack is much worse, as many of the protection features in a jailbroken device are either disabled or easily over-riden.  If you have a standard iOS device, the Wirelurker software will attempt to use the Enterprise Provisioning feature of iOS to install applications.

So far it appears that this information is being used to identify people installing pirated software.  Odds are that if you haven’t downloaded and installed any pirated Chinese software for your Mac, you’re OK.  The security researchers who examined this malware have noted that while not terribly complex, the attack vector is likely to be copied by more skilled attackers.

So what can you do to protect yourself?

Unless you are absolutely certain, never use the "Anywhere" option.
Unless you are absolutely certain, never use the “Anywhere” option.

First, be very careful when downloading and installing ANYTHING from the Internet.  If you are using a Mac, check to see if the application you are looking for is published in the App Store first, as Apple manages and tests applications that are available there.  That is not to say that it is impossible for malware to be in the Apple App store, but odds are better that it will be discovered and removed.   Mac OS X doesn’t allow installation of software without a valid code signing certificate, and disabling that check with significantly reduce the security of your system.   By the way, this attack could work just as easily with a Windows machine, and will no doubt begin cropping up there as well in the future.

Palo Alto Networks has developed a Wirelurker Checker for Apple Mac systems, to quickly check for the presence of Wirelurker on your system.  That software can be found here:

Those awesome themes should make up for having a phone that is easily compromised....
Those awesome themes should make up for having a phone that is easily compromised….

Don’t jailbreak your iOS device.  While it does provide an awesome array of apps and functionality not present in the stock version of iOS, your security is greatly compromised.  Virtually every strain of malware impacting iOS devices that we know of requires the device to be jailbroken in order for the attack to succeed.

Using these kinds of public USB charging stations is a very bad idea.
Using these kinds of public USB charging stations is a very bad idea.

Be extremely careful when connecting your phone to a USB port you don’t own.  It has become very common for airports and other public places to install USB ports for recharging of phones and tablets.  I can not recommend more strongly that you never use one of those ports.  The simple fact is you do not know what is sitting on the other side of that connection.  Bring your AC adaptor and plug into a good old-fashioned electrical outlet.

Here’s a link to the original Palo Alto release on Wirelurker:

A great write-up by Jonathan Zdziarski, a malware researcher with lots of excellent iOS malware experience:

Thanks for reading, and stay safe out there!

Vulnerability in Bash – CVE-2014-6271 aka “ShellShock”


Last week a vulnerability in a common system component called Bash was released.  This vulnerability, nicknamed ShellShock, enables a unauthorized actor to execute commands on any affected system.  Bash (short for the Bourne Again SHell) is a common application on Unix and Linux based systems, and provides a number of services to the operating system.

While most well known as a “shell” ( a text based environment for interacting with a system) the Bash program also provides services to other common applications, like web servers, SSH servers, and mail servers.  Since those types of services are often Internet facing, this vulnerability is especially serious.

Since receiving the initial information about ShellShock, the EI Security Operations team have been evaluating the risk to our customers and have begun a review of all systems, starting with Internet facing systems and moving to the internal networks.

At this time no action is necessary on the part of our customers.   Your EI account director will be reaching out directly to each customer this week to let you know when we have either cleared the risk or identified any vulnerable systems

We will be providing regular updates on this vulnerability, and are always available if any customer has a specific question or concern.

Additional details can be found at:

How to keep yourself (and your wallet) safe

Obligatory opening shot of credit cards...  Boom!
Obligatory opening shot of credit cards… Boom!

In case you missed it, Home Depot has been in the news lately, the latest victim of an attack aimed squarely at their point of sale (POS) systems, looking to steal the credit card data of its customers.  We don’t have much in the way of details at the moment, and it took Home Depot a little over two weeks to respond publicly (see why covering up a breach typically backfires).  To their credit though, they do provide an update (actually an easy to find one on their front page).

Home Depot surely wasn’t the only major retailer to experience these attacks this year, and they (sadly) won’t be the last either.  So what can we do to stop these thieves?


On the merchant side, the latest version of the Payment Card Industry’s Data Security Standards (PCI DSS) go into effect on January 1, 2015.  The Payment Card Industry (PCI) Security Standards Council, a joint endeavor of the major credit cards brands in the world (Visa, MasterCard, American Express, JCB, and Discover), publishes these security standards for merchants processing credit card transactions.  While some have derided the PCI DSS as not going far enough, the purpose of these requirements is to create a minimum baseline for a security program, not the ideal end-state ceiling of total defense.

In version 3.0 of the PCI DSS, a few new items go into effect that should improve the overall security at these organizations.  Previous versions of the PCI DSS only required vulnerability assessments to be conducted internally.  Now organizations will be required to perform penetration testing both internally and externally.  The difference between a vulnerability assessment and a penetration test is vast: A vulnerability assessment is the equivalent of looking at a locked door to see if it’s locked, where in a penetration test we open the door and steal your XBox One.

Dramatic re-enactment....
Dramatic re-enactment….

In addition to providing detailed feedback on the methods an attacker would use, organizations will also get the benefit of a live training exercise to see how their own security teams can identify and stop these types of attacks in action.  A good step in the right direction indeed.

Be sure to check your statements regularly!
Be sure to check your statements regularly!

Personally, the best defense you can have to protect yourself is awareness.  Always check your credit and debit card statements.  If you didn’t make a purchase, you need to let your card issuer know immediately.  If they hassle you about returning the funds, perhaps it’s time to switch banks.  For every Home Depot and Target known breach, there are no doubt plenty of unknown breaches.  Don’t wait on external notifications to start looking.

If your information is compromised and you are offered free credit monitoring, take advantage of it!  Beware any emails you may recieve, as they may be scams.  Always check by going directly to the merchants website or calling their customer service numbers to confirm what monitoring programs they have for you first.

Some new technologies on the horizon may provide some relief too.  The credit card brands themselves are requiring breached merchants to implement the “chip-and-pin” system, or assume liability for future data breaches themselves.

Credit card with an embedded chip
Credit card with an embedded chip

The “chip-and-pin” system includes an embedded chip in the card that interacts with the payment terminal to create a unique code for each transaction.  It requires the card holder to use their PIN in order to activate the function, and provides additional security beyond the data stored in the standard magnetic strip that most cards in the US use today.


Electronic wallet technology has been advancing, and received a big boost yesterday when Apple announced their new offering in that space, dubbed Apple Pay.  The Apple Pay system eschews traditional passing of credit card numbers to merchants in exchange for one-time use tokens that authorize an individual purpose.  Stealing one of these tokens won’t provide any value to a thief.


Similar approaches by Google, Square, and others may provide the relief we (and companies like Home Depot) are hoping for!

Thanks for reading, and stay safe out there!


Exposed Celebrities – Cloud Security Edition


While most of America was 3 or 4 hot dogs into an outstanding Labor Day weekend, a few other individuals were working out how to access other people’s photos stored in Apple’s iCloud.  They succeeded, and promptly begin to advertise the existence of nude photos of various celebs they were now in possession of.  Which of course made the news.

I tend to glaze over the minute I hear “celebrity news” too, but stay with me for just a minute on this one.  To me, the big news isn’t the celebrity part, it’s that we keep forgetting that the “cloud” is really just someone else’s computer.  These computers aren’t magical, just running special services that enable all kinds of cool things, like constant over the air backups of your phone.

In this case, the attackers took advantage of a misconfiguration in the iCloud service that let them try big lists of potential passwords and usernames to find some matches.   And it worked.   An account lockout after a certain number of failed attempts, or using a two factor authentication would have prevented the attackers from gaining access.


Everyone who has an iPhone is a (potential) iCloud user.  Its possible to disable it altogether, but my guess is very very few folks ever do.  It’s so easy and convenient, and ensures you’ll always have access to your phone’s backup in case you need it.  This applies to Google if you’re an Android user, and Microsoft’s OneDrive if a Microsoft user.  We’ll never have control over these services, so perhaps we need to just adopt some new guidelines on using them.

1. Don’t take pictures you wouldn’t mind the whole world seeing.

2. Don’t use a simple password for your account.*

3. Enable 2-factor authentication whenever possible.

4. Don’t take pictures you wouldn’t mind the whole world seeing.

*Apple’s guide to enabling 2-factor authentication for iCloud is available here.

I’m reminded of an old analogy about email: Treat it like a postcard.  When a postcard goes through the mail, it is readable at every point of delivery.  If you need to keep something secret, send it a different way.  The same thing can apply to cloud services.  Leverage the benefits, but beware the risks.  If you do need to store some sensitive info, make sure you think carefully about where it should go.

Thanks for reading, and stay safe out there!


Going Public with a Data Breach – The Argument for Disclosure


The Wall Street Journal published a story in the beginning of August titled “Executives Rethink Merits of Going Public with Data Breaches” (link here).  It’s a fine piece of writing, and an intriguing point of view.  Unfortunately, it’s wrong.

I encourage you to read the article for yourself and draw your own conclusions but allow me to walk through some of the points outlined in the story.  Dawn-Marie Hutchinson, one of the subjects of the story and the head of information security at Urban Outfitters, kicks off the story by arguing that all data breach announcements do is create hysteria in the public.  To be fair, I understand why Ms. Hutchinson (and some of the other executives mentioned but not named in this story) would be opposed to disclosing breach activity: it is perceived as a direct reflection of their job performance.  The article indicates that disclosing a breach would be the equivalent of ringing the dinner bell for thousands of other potential attackers indicating a vulnerable network ripe for plundering.   And that may be true.  But I doubt it.

Since data breaches can come in so many colors and flavors, let’s narrow the definition for this discussion down to those involving sensitive customer data: credit card numbers, social security numbers, and usernames/passwords.  This type of data has value to the criminal element, since it enables credit card fraud (credit card numbers), identity theft (social security numbers) and online identity theft (email addresses with passwords).  While emails and passwords are nice, clearly the easiest path to money is through access to valid credit card numbers and social security numbers.

Let’s play the hypothetical game: You’ve been put in charge of information security, and discover that unauthorized persons accessed and stole some of your sensitive customer data.  Decision time.  You have two options: do nothing or disclose the breach.

If you chose nothing, then you leave the burden of discovery on your customers.  They will be the ones to discover the unauthorized charges on their credit card or the new credit line opened in their name or the spam originated from their email account.  You’ll be in violation of disclosure laws in at least 47 states (assuming you have customers there), and likely make a stronger case against yourself in all the civil litigation that is likely to follow.  After all, if the breach is of any significance, sooner or later someone else is going to find out and tell the world.  That’s what happened to Target.  Other people noticed the huge surge in stolen credit cards on the market, and did the footwork to find the source.  Target would have likely been forced to disclose anyways.  Instead they stayed silent for almost two weeks while the news media circulated stories about the massive breach.


On the other hand, if you disclose the breach, you alert your customers to the problem and enable them to be proactive.  Customers can implement locks on their credit file.  Banks re-issue credit cards.  Passwords are changed.  And you devalue the stolen information the attackers left with.

And de-valuing the stolen data is probably the best defense you can mount these days.  Remember, the motivation of the criminal group who looks to steal this information is to sell it.  Credit card numbers only have value if they are valid and social security numbers only have value if they connect to a person with a good credit rating.

The practice of defensive information security is very difficult.  Assuming that you are sophisticated enough to determine that a breach has actually occurred (not as easy as it sounds), trying to determine exactly who executed the attack is nearly impossible.  Even if you somehow get the attribution right, your options for stopping these attackers are pretty limited.  It’s like trying to stop a burglar with a paintball gun: each time you catch them they have to start over.  But they get to start over, and keep at it until they find what they are looking for.

I’m reminded of a quote from Bruce Schneier, a luminary and pioneer in the information security world: “I am regularly asked what the average Internet user can do to ensure his security. My first answer is usually ‘Nothing, you’re screwed.'”



A common perception about data breach notifications is that once a company goes public with a security event, they face:

  • Stock price drop
  • Brand damage
  • Customer loss
  • Civil lawsuits

As very effectively put by Adam Shostack in his keynote presentation “Beyond Good and Evil: Towards Effective Security“, those perceptions are wrong.  While companies may experience a brief hit to their stock price, they generally bounce back within 2 or 3 days.  Not even a week.  Customers tend not to leave because the transparency encourages trust (always a good thing).  And the vast majority of civil lawsuits are dismissed before discovery, especially if the breach disclosure process is effectively executed, and provides those individuals effected with mitigating options like credit monitoring services.

And most importantly, effective sharing on data breaches is the only way we, as an industry, can get better.  Keeping quiet about a security event doesn’t help you, or your peers, get better at preventing these attacks.  It only helps your enemy the malicious attacker.  I think they’ve got enough of an advantage, don’t you?

Thanks for reading, and stay safe out there!

Florida Information Protection Act of 2014

Florida Governor Rick Scott Attends Bill Signing

Governor Rick Scott signed the Florida Information Protection Act of 2014 on June 20.  It goes into effect July 1, 2014.

The new law has been described by legal analysts as the broadest and most encompassing data protection law in the United States.

FIPA requires companies to take reasonable measures to protect the covered electronic data of Floridians.  It also requires notifications to individuals of any security breaches involving their information.  While those provisions as similar to data breach laws in other states, FIPA defines covered personal information differently.

In addition to the usual sensitive records (medical, social security numbers, and credit cards), FIPA includes a username and password that provides a login to an online service.

Should a breach occur, the organization has 30 days to notify effected individuals once the breach has been discovered.  Any breach involving 500 or more individuals requires notifying the Florida Department of Legal Affairs, who will require a full breach investigation report and evidence, along with copies of applicable policies and procedures.

Companies will need to be aware of the provisions within the Florida Information Protection Act of 2014 to ensure they don’t find themselves out of compliance.

More information can be found here:

Defender’s Advantage Series – An Introduction

The Defenders certainly have the advantage here.
The Defenders certainly have the advantage here.

During my (informative and rewarding) time in the Air Force, I was fortunate enough to take some military strategy courses.  One of the main tenets of military strategy (borne out over 5000 years of human combat) is the notion of “Defender’s Advantage”, which essentially states that a defender force will be able to hold off an invading force up to 3 times its size.  Which makes sense: if you are the defender, you know the terrain, have time to prepare defense fortifications, and can stock up on supplies.  But in information security, its seems like anything but a Defender’s Advantage.

It’s a curious reversal of a time honored maxim.  Time and again we see large organizations completely defeated by small groups of electronic attackers. Why does the defenders advantage disappear in the information security world?

Let me be very clear: I do not at all mean to trivialize war and physical violence by comparing that with IT security, there is a clear distinction.  OK, let’s press on!

Perhaps the nature of electronic attacks are better modeled after guerilla style warfare.  In guerilla warfare, the smaller attackers look to harass and cause specific impacts against the larger force, using their agility to their benefit.  Prized resources are targeting for destruction or theft, will the goal being disrupt the operations of the larger force.

George Washington employed guerilla tactics during the Revolutionary War to counter the advantages the British possessed.
George Washington employed guerilla tactics during the Revolutionary War to counter the advantages the British possessed.

Even so, there is plenty of work on strategies and tactics to handle this type of “asymmetric warfare”.  So the question remains, why don’t we see an inherent advantage towards the defender?

Seize the Advantage #1 – Know the Terrain

Do you know all the devices on your network and how they connect?
Do you know all the devices on your network and how they connect?

This is probably the biggest area for improvement in most organizations.  It’s important to know exactly what systems are connected to your enterprise, how they are connected, what they do, and who uses them.

  •  Conduct regular inventories of all systems connected to the network
  • Implement a vulnerability management program
  • Documentation on your network should be up-to-date and available (perhaps in an offline fashion as well)

Seize the Advantage #2 – Decide Who Gets In and Out


A standard model of preventing attacks before they happen necessitates blocking malicious traffic on its way into your network.  Of course, that method is not a reliable method for defending a network, although the majority of the attention (and budget) goes there.  In reality, we need to use a model where we prevent as much of the obviously malicious traffic as we can, and then start watching for traffic that is leaving our network.

The truly dangerous attacks usually require outbound access from the network, either to send home the stolen loot, or to check in with the mothership and ask for new instructions. Fans of the kill-chain model (myself included) will recognize this either the Command and Control or Action stages, and know that this is where the majority of malware is detected and thwarted.

Within the context of the Defender’s Advantage, we need to ensure we are completely leveraging the control that we can assert over the entry and exit points of the network.  We should be monitoring and blocking the outbound traffic just as much as the inbound traffic.

  • Firewalls should have outbound access-control entries configured too – set them up and monitor them!
  • Whenever possible, use a proxy or content filter capable device to control the traffic that does leave your network
  • Monitor outbound DNS requests

Seize the Advantage #3 – Segmentation and Depth

Lots of defenses the bad guys have to deal with... assuming no one on the inside opens the dorr for them.
Lots of defenses the bad guys have to deal with… assuming no one on the inside opens the door for them.

Getting back to our martial metaphor (and alliteration too, my English teachers would be so proud!), the guerrilla warfare tends to be waged against the isolated outposts of the larger organization.  This occurs for a number of reasons, mostly because the outposts tend to be less well defended, are closer to the attacking guerrilla force, and enable to the guerrilla force to be successful without having to overextend their time and resources attacking a deeper target.

In the case of designing our network, we need to provide ourselves with some segmentation and depth in our networks to ensure that getting to the principal resources are as costly and expensive for the opponent as possible.  That is not to say it makes the process impossible, it just means that we give ourselves a few more hops to monitor, and make the attacker work a little harder (and a little longer).

Seize the Advantage #4 – Build Your Own Robot Army


If you read our review of the Verizon DBIR we posted earlier this year, you’ll remember that attackers go from initial compromise to data exflitration in minutes or hours.  They’ve found a way to leverage automation to their advantage.  Let’s take a cue from these (highly successfully and extremely detestable) folks, and do the same thing ourselves!

So what do you need to start your own robot army? Well, first you’re going to need:

  • A log management solution (or a SIEM)
  • Detailed and complete network inventory
  • An action platform (you’re going to need a way to respond and execute commands)

When we start working on automating-for-good, its important to realize I’m not necessarily talking about automating an end-to-end action (although that would be awesome!).  Start by automating components of the security operations.  Let’s you have an alert from your IPS that opens a priority 1 ticket.  When your team goes to respond to that alert, do they have all the information they need to make a decision, or do they have to go into hunting mode?  Why not have all of that information available in the ticket?  Snag the firewall logs associated with the alert, gran the AV and system logs for the target for that time frame, and put all that together in one place?  Now instead of logging in and tracking down enough information to investigate, we skip right to the part where the human does what humans do best: make a decision.

As you automate portions of these activities, you may find that the decisions being made can also be pretty easily automated as well.  Maybe 90% of the alerts follow a pattern that indicates no issues.  Go ahead and automate that, and only alert for the outliers.  I can’t imagine a security engineer in the world who wouldn’t mind having a 90% reduction in P1 alerts.

We’re going to expand on each of these sections in the next few posts.  Time to go reclaim the advantage.

Stay safe out there.  And thanks for reading!

Securing Your Cloud Services – Watch that admin console!

New take on an old joke: If a cloud service is hacked and no one is around, does it make a sound?

We’re living in a golden age of disruptive technologies, least of which is the rise of the “cloud”.  Cloud computing is one of those terms that varies based on your perspective, so for the sake of our discussion today, we’re going to break it down to the basics:  There is no cloud, only other people’s computers.  Cloud is a nifty way to sell tiny slices of those computers resources, like storage and computing.  That’s really all it is.  But make no mistake, it’s someone else’s computer running with your data.

There are tremendous advantages to be gained from leveraging these services, without a doubt.  The flexibility to pay for what you use, to scale up or down as necessary, to avoid capital expenses related to hardware and software, the redundancy and DR capabilities, the ubiquitous Internet access, all awesome things.  We’re just going to take a look at how you can leverage these technologies safely.

Administrative Controls

Virtually every public cloud service provides you, the subscriber, with access to an administrative portal, usually a web application, where all of the administrative functions happen.  Which makes sense, because your are using someone else’s computers after all, so they need to give you control over just your stuff.

May or may not be the actual control panel for modern cloud services….

How do you prevent unauthorized actions within this portal?

Well, usually the group of people designated as “admins” are given access to the portal, usually secured with a username and password.  So technically they are the only people with access.  Unless their password is easily guessable.  Or they are victims of a phishing attack and disclose it.  Or if it’s the password they use everywhere, and one of their other accounts is compromised.  Oh, or if an attacker installs a key-logger on their system.  Or if they log in from an unprotected wireless network.

Yeah, I know, the whole password thing isn't great...
Yeah, I know, the whole password thing isn’t great…

Maybe your cloud provider has a two factor authentication solution you can utilize.  That would help.  Some private cloud service providers (including EI’s Cloud+) don’t even expose the admin console to the Internet to provide additional security.

Of course, if this system were hosted in our own data center, we would find a way to monitor that kind of login activity, both to log for patterns of brute forcing attempts, or to catch login attempts from unusual locations (someplace in Asia, let’s say).  Unfortunately, most cloud providers do not provide the ability to log this type of data, and certainly not in anything like the real-time type nature we have grown accustomed to.

What this basically means is that the detective parts of your controls go out the window, and you are left with hoping that the authentication controls are sufficient.

Consider the case of Code Spaces, a service providing hosting for teams to collaborate on software projects.  Their entire business was built using cloud services (in this case, Amazon’s Infrastructure as a service offering).  Late on a Tuesday, the Code Spaces team realized they were the target of a massive distributed Denial of Service (DDoS) attack.  The Code Spaces team was able to reach out to the attacker, who demanded a ransom to stop the attack.  How did the Code Spaces team know how to contact the attacker?  Because the attacker left their contact details inside of the admin dashboard of their Amazon account!

Realizing that the attacker had access to their control panel, they began to attempt to regain control over all of their accounts, but the attacker had created a few additional accounts, and started deleting everything inside of the Code Spaces account.  Everything.  All of the virtual machines, all of the virtual machine snapshots, all of the storage, and all of the backups.

Really easy to delete things unfortunately....
Really easy to delete things unfortunately….

Code Spaces had touted their ability to protect customer data from catastrophic events as one of their main selling points.  To be fair, they probably were pretty well set up to recover from specific hardware or site failures, but no one had taken into account recovering from an instance where all of their data was deleted from the admin console.

As a result, Code Spaces is closing their doors.  The cost of recovering their customer’s data plus the damage to their reputation was too much to overcome.

We don’t have many details on the exact nature of the attack at this point, but what little we know seems to indicate that a phishing attack targeted key individuals at Code Space, and was successful enough for the attacker to gain access to the Amazon dashboard.

So, how can you secure the admin console for your cloud services?

First, securing the admin portal should be as important to the cloud provider as it is to you.  In most cases, the admin portal should be restricted, not just to authorized users, but from the Internet in general.  While remote access is great, very rarely will you need access from absolutely anywhere on the Internet.  Incorporating a VPN (with different credentials) to access administrative functions can provide an additional buffer.  Most managed private clouds will work with you to only provide access to admin consoles through very restricted access.  Obviously you can’t request physical access to most cloud service providers, which would enable physical access controls as well as logical ones.

Physical access controls are generally not an option for you in cloud services...
Physical access controls are generally not an option for you in cloud services…

Second, there should be some logging and alerting built in.  Basic things like looking for series of incorrect passwords or connections from unusual locations is a good start.

Redundancy Outside of the cloud

Offiste (or off-service) backups are crucial
Offiste (or off-service) backups are crucial

Backups are such a critical component of DR/BC plans because you can always restore the app, but once you’ve lost the data, well that’s it.  The Code Spaces team had designed their solution to handle lots of adverse conditions, just not one in which an attacker had access to their admin console.  Had they leveraged a backup solution that kept their data outside the Amazon cloud (and away from the control of the attacker) they would have suffered an outage, but would have been able to restore to full functionality.

Cloud Security – Lots more!

The proliferation of various cloud services provides lots of additional attack surface that needs to be secured.  We’ll be discussing additional cloud security concerns in upcoming blog posts.

Thanks for reading!

More details on the Code Spaces story can be found here: