LastPass and How To Respond To Zero Day Vulnerabilities
INTRO
It’s nerve-racking to read that a product that your company relies upon has a critical zero day vulnerability. Do you scramble for a new solution, wait for a patch or just panic? Making important application decisions based on social-media rumblings isn't usually the best way to run an IT shop. In some ways, this is like driving down the road when your car starts making an unusual sound. It might not be time to consider buying a new car, but you do need to assess the situation.
Take, for example, the recently identified issues with LastPass (here, here and here). How should you react?
VULN SPECIFIC STEPS
In this instance, the vulnerability is isolated to the LastPass Firefox addon and a patch has already been issued. All versions of LastPass 4 prior to 4.1.21a are vulnerable and should be updated immediately.
If your organization uses LastPass, consider your use case:
Could any of your users have the an affected version installed?
Who is using it and what credentials do they have stored in it?
If you have logins to important business resources such as:
cloud providers (AWS, Rackspace),
organizational social media (Facebook, Twitter, Instagram) or
SaaS providers (Office 365, Salesforce),
... you need to take action.
Assuming you do have important credentials stored in LastPass and users that may be on Firefox, consider taking the following steps to reduce your risk.
First, audit logins for suspicious activity and evidence of compromise: All cloud services can give you basic information about successful logins.
You should look for logins from unusual IPs, browsers, device OSs and times.
Don't have any Swedish end-users?
A login from a Linux box when you don't support Linux?
Perhaps you should contact the user by an alternative method and investigate.
We're including links to common service providers to find recent login information:
If you find suspicious logins... have that user do a password changing party for any stored logins in their password manager. It may be reasonable to also investigate activity logs to see what a potential attacker did with the access. If you suspect more than a login occurred, it may be time to start a breach investigation process.
Another method to find compromised logins can be performed by searching your outgoing traffic for ex-filtrated logins. Check your web proxy logs for attempts to pass logins. If you can grep them, the regex to discover passwords to "example.com" being ex-filtrated using this method would look like this:
http.*\:\/\/[a-zA-Z0-9\.\-]*\/\@example.com\/.*$Monitor LastPass' website... for a patch and patch all affected systems as soon as reasonably possible. LastPass has already issued an update to address the Firefox vulnerability so ensure that your users are on the most recent version – 4.1.21a.
AND FOR THE NEXT TIME...
...there's always a next time. Vulnerabilities are discovered in commercial and open-source software on a regular basis. Although each vulnerability will require specific treatment there are some lessons which can be learned from incident response disciplines which can be applied broadly.
The first step to facing the issue the next time is knowing your environment. Understand what operating systems and applications your organization relies upon.
The second step is having a good current list of vulnerabilities on the software and systems you rely upon. Depending on your time and money budget, consider SecurityFocus' bugtraq, vendor disclosure lists for your products, Threatpost, Ubuntu Security notices or filter Twitter for the applications you rely upon.
Once an organization is made aware of (detects) an issue such as the current issue with LastPass, they can take steps to:
Assess possible impact to the organization. Using information which is to hand, such as vulnerability write-ups, an organization can determine the impact, or potential impact, that a particular issue holds for them. For example determining what kind of data is held or accessible via the compromised system. In this case it is passwords, so determining what it means to you, as an organization, if those passwords have been lost. Does the application hold all your passwords, just a subset, do affected systems use 2FA, are they internet accessible, etc?
Determine exposure. In many cases it is possible to retrospectively determine if you have fallen foul of a particular sort of attack. For example if there are any particular URLs that are an indicator if compromise, and the organization uses a proxy for internet access; searching the proxy logs is a quick way to determine the likelihood that the organization has been exposed.
Short term (temporary) steps to minimize exposure. There may be some "bandaid" fixes which can be put in place to temporarily reduce or stop an issue which is in progress until such point as some sort of permanent remediation can be put in place. In many cases this may not be a technical countermeasure but a procedural one, such as not using an affected system but using an alternative.
Long term remediation. Typically when an issue arises, sooner or later there will be a fix (hopefully!). Often this is in the form of a software patch, configuration change or other mitigation. In most cases this will be the preferred fix to any shorter term fixes deployed mid-crisis, and should be assessed for wider deployment so that short term fixes can be removed.
Cleanup. Once an issue has been contained and remediated there may be a number of cleanup actions required. Hosts may need to be rebuilt, passwords changed, cryptographic material reissued, etc. What cleanup is specifically required will depend on the nature of the incident and the potential exposure.
Lessons learned. It is always useful to hold a lessons learned session with the key stakeholders and subject matter experts after an issue has been resolved. It allows an organization to reflect on what worked well, what did not work so well, and to make positive changes to processes, procedures, staff training, and overall preparedness.
MOVING FORWARD
The best time to consider buying and implementing new or updated security controls are before you need them. The second best time is after the smoke clears. You likely have support from your users and management to implement the changes you believe you need. A final consideration is to ensure all your controls are in place, not just the 'one thing' you recently had to worry about.