iPhone Spyware Trident Exploit Chain

On August 25thApple released iOS 9.3.5an update to iOS devices which addresses 3 CVEs known as the Trident Exploit Chain: 

CVE-2016-4655: Memory Corruption in Webkit – A vulnerability in the Safari WebKit that allows the attacker to compromise the device when the user clicks on a link. 

CVE-2016-4656: Information leak in Kernel – A kernel base mapping vulnerability that leaks information to the attacker allowing him to calculate the kernel’s location in memory. 

CVE-2016-4657: Kernel Memory corruption leads to Jailbreak – 32 and 64 bit iOS kernel-level vulnerabilities that allow the attacker to silently jailbreak the device and install surveillance software. 

 These vulnerabilities were used in combination in an attempt to deploy "lawful intercept" spyware onto the iPhone of a noted human rights campaigner in the UAE.  Specific details of this case can be found on Citizenlab

And a technical analysis and blog post can be found on Lookouts website.

Leviathan recommends that all iOS users update to 9.3.5 as soon as possible.  When a 0-day exploit of this kind is patched, a wide range of groups will embark on reverse engineering the patch to recreate the exploit for reuse.  The mean time from patch release to a recreated exploit is ever shortening meaning that the chance of encountering an attack in the wild becomes more and more likely as the exploit becomes more widely available.

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 (herehere 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.

Bulk ASLR Data Analysis

Bulk ASLR Data Analysis

Hello from the Lotan team at Leviathan!

We recently looked at a sample set of 80,000 crashdumps from a production environment and decided it was time to look at some data we have in aggregate. Lotan's core focus is detecting stage one attacks (shellcode) in crashed processes. To achieve this goal Lotan has to process the bulk of the data contained within a memory image. One of the most interesting components of these process images is the information about loaded modules from Windows processes.

The Cobbler’s Children and source code integrity, or why your source code repositories need better shoes.

I’m reminded of the saying ‘The Cobbler’s children have no shoes’. We consider our customer facing products more important than our internal ones.

 

Of course we do, right? Our bills are paid by our customers and we’d like more of them, so an hour or dollar spent to improve their experience is easily justified.  However, allocating resources to internal processes and systems gets a different response.  You want to spend how much to do what?  Internal processes, systems and tools have to pass greater scrutiny to be “justified”. Since it’s “all in the family”, internal tools don’t have to be as pretty, well documented, reliable or secure, right? 

Oh, and doing it “right” just takes too much time.  “Just get it done instantly, if not sooner.”

 

DevOps is one way of making the development process faster and cheaper. Unfortunately, it’s all too easy to let it devolve into anarchy. Doing DevOps  the right  way is harder. It’s so much easier to spool up an instance of $Whatever_Tool_You_Need_Right_Now to fix some issue before a release than to plan for what you need and document what you’re doing. Sure, you might be using the same tool as some other developer or team, but hey, when it’s faster and easier to just create your own instance instead of coordinating systems, faster and easier often win out. Documentation and hardening, when done by yourself, just take too much time.

 

The result is something I call the ‘Sergeant Schultz approach’ –IT worries about enterprise wide systems directly under their control and leaves the development environment alone until forced to pay attention, when it may be too late.

 

These systems may have been quickly stood up and aren’t being fully protected by your controls. You’re not watching logs, tracking users, remediating vulnerabilities to ensure stable, hardened systems.

 

A loss of availability in on these systems is annoying, but obvious.  It may slow development but it won’t permanently affect your business.  

But a loss of confidentiality and integrity can affect the enterprise as a whole. A source code leak might reveal some trade secrets to a competitor. A loss of integrity can be far worse.

 

Imagine an development server not benefiting from the full protection of your controls.  A malicious or negligent user can modify code for your mobile app, web app or device OS, creating a stability issue, back door or jackpot condition.

 

Discovering a back door or jackpot condition prior to code release is merely embarrassing. Remediating the issue post- release opens the company to loss of market share and goodwill. If the parade of horribles doesn’t have your attention, consider the possibility that the jackpot condition is a negative one. Remember the Therac-25, where a radiation therapy device sometimes overdosed patients? That was mere negligence. Imagine what a malicious party could do.

 

Ok – so I’ve stated the obvious – it’s easier to do it fast and loose than to take the time to plan things out.  However, it IS possible to reduce the risk of compromise, even in a fast moving DevOps environment.  By using the following 4 steps, you will greatly reduce the risk of a catastrophic loss of integrity, with reasonable amount of effort expended.

 

We recommend the following:

 

Inventory tracking: IT should have, as a minimum, visibility into the DevOps environment- instances, users and permissions. If you have a SIEM or log management tool, have the instances report up to it.

 

Identity management: Each user with write capability should have their own credentials. Ideally, these are referenced back to the firms LDAP/AD user store. If you can, require the use of 2FA to reduce the risk of credential compromise.

 

User tracking: Every change to source code should map back to a specific human user.

 

Pre- built images: When feasible, systems should be standardized and centralized. Consider offering pre-hardened VM images with  favorite development tools to offer developers so they don’t have to roll their own.

 

 

We don’t need to make our tools as nice as what we offer our customers, but they need to be good enough. Your kids don’t need Louboutins, but they do need good enough shoes.

 

For the curious:

https://www.psychologytoday.com/blog/credit-and-blame-work/200812/cobblers-children-syndrome-in-the-workplace

 

Guidance - Flash Vulnerability CVE-2015-5119

During the Hacking Team breach which came to light earlier this week, a large quantity of Hacking Team's internal data was posted online.  Some of this data pertained to a 0-day (a vulnerability which the vendor is not aware of) in Adobe Flash (versions 9 through to 18.0.0.194) (CVE-2015-5119) which allows an attacker to execute code on a victims computer if they browse to a website with a malicious flash file embedded. 

Guidance - OpenSSL Vulnerability CVE-2015-1793

This morning, OpenSSL released details of a vulnerability (CVE-2015-1793) affecting OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1 for client connections; listening servers are unaffected unless they validate client certificates.  Anyone can issue themselves a certificate for any domain and the OpenSSL library will not notice, allowing someone to impersonate a server and pass TLS/SSL based checks.  The vulnerability allows an attacker to use a leaf certificate as if they were a Certificate Authority and issue rogue certificates to themselves. 

The Harms of Forced Data Localization

How we store data---and how we think about keeping our memories available over the long term---has changed in the last few years. The world has become better at keeping data secure and safe by distributing it to multiple continents. However, some leaders are calling for "national Internets"---censored, walled gardens set up to appease special interest groups that range from political factions, to property cartels, to religious police. Other leaders have taken a different tack, called forced localization; rather than blocking your communications, they want to require that all your data (and all the computers that handle it) be inside a single country: theirs, for whichever country they represent. These would be major changes to the structure of the Internet---changes that would harm both businesses and the general public.