Posts

Patch Management Practices

Patch Management Practices to Keep Your Clients Secure

Develop a Policy of Who, What, When, Why, and How for Patching Systems

The first step in your patch management strategy is to come up with a policy around the entire patching practice. Planning in advance enables you to go from reactive to proactive—anticipating problems in advance and develop policies to handle them.

The right patch management policy will answer the who, what, when, why, and how for when you receive a notification of a critical vulnerability in a client’s software.

Create a Process for Patch Management

Now that you’ve figured out the overall patch management policy, you need to create a process on how to handle each patch as they’re released.

Your patch management policy should be explicit within your security policy, and you should consider Microsoft’s® six-step process when tailoring your own. The steps include:

Notification: You’re alerted about a new patch to eliminate a vulnerability. How you receive the notification depends on which tools you use to keep systems patched and up to date.

Assessment: Based on the patch rating and configuration of your systems, you need to decide which systems need the patch and how quickly they need to be patched to prevent an exploit.

Obtainment: Like the notification, how you receive the patch will depend on the tools you use. They could either be deployed manually or automatically based on your determined policy.

Testing: Before you deploy a patch, you need to test it on a test bed network that simulates your production network. All networks and configurations are different, and Microsoft can’t test for every combination, so you need to test and make sure all your clients’ networks can properly run the patch.

Deployment: Deployment of a patch should only be done after you’ve thoroughly tested it. Even after testing, be careful and don’t apply the patch to all your systems at once. Incrementally apply patches and test the production server after each one to make sure all applications still function properly.

Validation: This final step is often overlooked. Validating that the patch was applied is necessary so you can report on the status to your client and ensure agreed service levels are met.

Be Persistent in Applying the Best Practices

For your patch management policies and processes to be effective, you need to be persistent in applying them consistently. With new vulnerabilities and patches appearing almost daily, you need to be vigilant to keep up with all the changes.

Patch management is an ongoing practice. To ensure you’re consistently applying patches, it’s best to follow a series of repeatable, automated practices. These practices include:

  • Regular rediscovery of systems that may potentially be affected
  • Scanning those systems for vulnerabilities
  • Downloading patches and patch definition databases
  • Deploying patches to systems that need them
Take Advantage of Patching Resources

Since the release of Windows 10, updates to the operating system are on a more fluid schedule. Updates and patches are now being released as needed and not on a consistent schedule. You’ll need to let your team know when an applicable update is released to ensure the patch can be tested and deployed as soon as possible.

As the number of vulnerabilities and patches rise, you’ll need to have as much information about them as you can get. There are a few available resources we recommend to augment your patch management process and keep you informed of updates that may fall outside of the scope of Microsoft updates.

Utilize Patching Tools

You don’t want your technicians spending most of their time approving and applying patches on individual machines, especially as your business grows and you take on more clients. To take the burden off your technicians, you’ll want to utilize a tool that can automate your patch management processes. This can be accomplished with a remote monitoring and management (RMM) platform, like ConnectWise Automate®. Add-ons can be purchased to manage third-party application patching to sure up all potential vulnerabilities.

Patch management is a fundamental service provided in most managed service provider (MSP) service plans. With these best practices, you’ll be able to develop a patch management strategy to best serve your clients and their specific needs.


This article was provided by our service partner : connectwise.com

Password Constraint Research

Password Constraints and Their Unintended Security Consequences

You’re probably familiar with some of the most common requirements for creating passwords. A mix of upper and lowercase letters is a simple example. These are known as password constraints. They’re rules for how you must construct a password. If your password must be at least eight characters long, contain lower case, uppercase, numbers and symbol characters, then you have one length, and four character set constraints.

Password constraints eliminate a number of both good and bad passwords. I had never heard anyone ask “how many potential passwords, good and bad, are eliminated?” And so I began searching for the answer. The results were surprising. If you want to know the precise number of possible 8-character passwords there are if all of the character sets must be used, then the equation looks something like this.

A serious limitation of this approach is that it tells you nothing about the effects of each constraint alone or relative to other constraints. (I’m also not sure if there were supposed to be four consecutive ∑s or if the mathematician was stuttering.)

We choose to use a Monte Carlo simulation to analyze the mathematical impact of the various combinations of constraints. A Monte Carlo simulation uses a statistical analysis approach that provides a close approximation of the answer, while also providing the flexibility to quickly and easily measure the impact of each constraint and combination of constraints.

A look at minimum length limits

To start, let’s look at the impact of an eight-character length constraint alone. There are 95^8 possible combinations of 8 characters. 26 uppercase letters + 26 lowercase letters + 10 numerals + 33 symbols = 95 characters. For a length of 8 characters, we have 95˄8 possible passwords.

If a password must be at least 8 characters long, then there are also about 70.6 trillion otherwise viable passwords you are not allowed to use (95+(95^2 ) +(95^3 ) +(95^4 ) +(95^5)+(95^6 )+(95^7)). That’s a good thing. It means you can’t use 95 one character passwords, 9,025 two character passwords, and so on. Almost 70 trillion of those passwords you cannot use are seven characters long. This is a great and wholly intended effect of a password length constraint.

The problem with a lack of constraints is that people will use a very small set of all possible passwords, which invariably includes passwords that are incredibly easy to guess. In the analysis of over one million leaked passwords, it was found that 30.8 percent passwords eight to 11 characters long contained only lowercase letters, and 43.9 percent contained only lowercase letters and numbers.  In fact, to perform a primitive brute force attack against an eight-character password containing only lower case letters, it’s only necessary to try about 209 billion character combinations. That does not take a computer very long to crack. And, as we know from analyzing large numbers of passwords, it’s likely to contain one of the most popular ten thousand passwords.

To beef up security, we begin to add character constraints. But, in doing so, we decrease the number of possible passwords; both good and bad.

Just by requiring both uppercase and lowercase letters, more than 15 percent of all possible 8-character combinations have been eliminated as possible passwords. This means that 1QV5#T&|cannot be a password because there are no lowercase letters. Compared to Darnrats,which meets the constraint requirements, 1QV5#T&|is a fantastic password. But you cannot use it. Superior passwords that cannot be used are acceptable collateral damage in the battle for better security. “Corndogs” is acceptable, but “fruit&veggies” is not. This clearly is not a battle for lower cholesterol.

As constraints pile up, possibilities shrink

If a password must be exactly eight characters long and contain at least one lower case letter, at least one uppercase letter and at least one symbol, we are getting close to one-in-five combinations of 8 characters that are not allowable as passwords. Still, the effect of constraints on 12 and 16 character passwords is negligible. But that is all about to change… you can count on it.

Are you required to use a password that is at least eight characters long, has lower and uppercase letters, number and symbols? Just requiring a number to be part of a password removes over 40 percent of 8-character combinations from the pool of possible passwords. Even though you can use lowercase and uppercase letters, and you can use symbols, if one of the characters in your password must be a number then there are far fewer great passwords that you can use. If a 16 character long password must have a number, then 13 times more potential passwords have become illegal as a result of that one constraint than the combined constraints of lower and uppercase letters and symbols caused. More than one-in-four combinations of 12 characters can no longer become a passwords either.

You might have noticed that there is little effect on the longer passwords. Frequently there is also very little value in imposing constraints on long passwords. This is because each additional character in a password grows the pool of passwords exponentially. There are 6.5 million times as many combinations of 16 character pass words using only lowercase letters than there are of eight character passwords using all four character sets. That means that “toodlesmypoodles” is going to be a whole lot harder to crack than “I81B@gle”

Long and simple is better than short and hard

People tend to be very predictable. There are more symbols (than there are in any other characters set. Theoretically that means that symbols are going to do the most to make a password strong, but 80 percent of the time it is going to be one of the top five most frequently used symbols, and 95 percent of the time is will be one of the top 10 most frequently used symbols.

Analysis of two million compromised passwords showed that about one in 14 passwords start with the number one, however for those that started with the number one, 75 percent of them ended with a number as well.

The use of birthdays and names, for example, make it much easier to quickly crack many passwords.

Password strength: It’s length, not complexity that matters

As covered above, all four character sets (95 characters) in an eight character password allow for about 6.634 quadrillion different password possibilities. But a 16 character password with only lowercase letters has about 43.8 sextillion possible passwords. That means that there are well over 6.5 million times more possible passwords for 16 consecutive lowercase letters than for any combination of eight characters regardless of how complex the password is.

My great password is “cats and hippos are friends!”, but I can’t use it because of constraints – and because I just told you what it is.

For years password experts have been advocating for the use of simple passphrases over complex passwords because they are stronger and simpler to remember. I’d like to throw a bit of gasoline on to the fire and tell you, those 95^8 combinations of characters are only  half that many when you tell me I have to use uppercase, lowercase, numbers, and symbols.

———————————————————————————————————————————-

 

Asset Management

Don’t Ignore Security Activity That Could Help the Most

We tend to think of security as the tools—like email scanning, malware, and antivirus protection—we have in place to secure our network. But did you know that the process of asset management helps you minimize the threat landscape too?

Management of software and hardware has historically been treated as a cost-minimizing function, where tracking assets could be the difference between driving or reducing value, from an organizational perspective. However, even the best security plan is only as strong as its weakest link. If IT administrators are unaware where assets reside, the software running on them, and who has access, they are at risk.

Understanding the device, as well as the data, is what matters here. Having an in-depth knowledge of the network of devices and their data is the first step in protecting it. Often, organizations have the tools in place to support and maintain the device, but once in place on the network, it can be easy to set it and forget it until it need repair, replacement, or up for review. Conducting asset management on a regular basis should be a fundamental function for your security plan and can strengthen the security tools you already have in place. Remember, asset management has to be continuous for it to be truly effective.

When you’re conducting continuous asset management you can always answer the following questions should an incident occur:

  • What devices are currently connected to the internet?
  • How many total systems do you have?
  • Where is your data?
  • How many vendors do you have?
  • Which vendors have what kind of your data?

Companies struggle with consistent and mature asset management because they often don’t have the time or dedicated resources to stay on top of it. However, an IT asset management program can add value by reducing costs, improving operational efficiency, determining full cost, and providing a forecast for future investments. Oversight and governance help to solidify policies and procedures already in place.

ConnectWise Automate® complements and strengthens security tools and processes by significantly improving the ability to discover, inventory, manage, and report. Additional tool sets–like antivirus and malware protection—can be added to help further protect data and reduce operational risk.

recent study of the Total Economic Impact of ConnectWise showed, “Organizations estimated that they could shorten engineers’ involvement by 60%, thus cutting the cost of hardware maintenance by $1.2 million.”


This article was provided by our service partner : Connectwise.

Unsecure RDP Connections are a Widespread Security Failure

While ransomware, last year’s dominant threat, has taken a backseat to cryptomining attacks in 2018, it has by no means disappeared. Instead, ransomware has become a more targeted business model for cybercriminals, with unsecured remote desktop protocol (RDP) connections becoming the favorite port of entry for ransomware campaigns.

RDP connections first gained popularity as attack vectors back in 2016, and early success has translated into further adoption by cybercriminals. The SamSam ransomware group has made millions of dollars by exploiting the RDP attack vector, earning the group headlines when they shut down government sectors of Atlanta and Colorado, along with the medical testing giant LabCorp this year.

Think of unsecure RDP like the thermal exhaust port on the Death Star—an unfortunate security gap that can quickly lead to catastrophe if properly exploited. Organizations are inadequately setting up remote desktop solutions, leaving their environment wide open for criminals to penetrate with brute force tools. Cybercriminals can easily find and target these organizations by scanning for open RPD connections using engines like Shodan. Even lesser-skilled criminals can simply buy RDP access to already-hacked machines on the dark web.

Once a criminal has desktop access to a corporate computer or server, it’s essentially game over from a security standpoint. An attacker with access can then easily disable endpoint protection or leverage exploits to verify their malicious payloads will execute. There are a variety of payload options available to the criminal for extracting profit from the victim as well.

Common RDP-enabled threats

Ransomware is the most obvious choice, since it’s business model is proven and allows the perpetrator to “case the joint” by browsing all data on system or shared drives to determine how valuable it is and, by extension, how large of a ransom can be requested.

Cryptominers are another payload option, emerging more recently, criminals use via the RDP attack vector. When criminals breach a system, they can see all hardware installed and, if substantial CPU and GPU hardware are available, they can use it mine cryptocurrencies such as Monero on the hardware. This often leads to instant profitability that doesn’t require any payment action from the victim, and can therefore go by undetected indefinitely.

secure password

Solving the RDP Problem

The underlying problem that opens up RDP to exploitation is poor education. If more IT professionals were aware of this attack vector (and the severity of damage it could lead to), the proper precautions could be followed to secure the gap. Beyond the tips mentioned in my tweet above, one of the best solutions we recommend is simply restricting RDP to a whitelisted IP range.

However, the reality is that too many IT departments are leaving default ports open, maintaining lax password policies, or not training their employees on how to avoid phishing attacks that could compromise their system’s credentials. Security awareness education should be paramount as employees are often the weakest link, but can also be a powerful defense in preventing your organization from compromise.


This article was provided by our service partner : webroot.com

Incident Response

6 Steps to Build an Incident Response Plan

According to the Identity Theft Research Center, 2017 saw 1,579 data breaches—a record high, and an almost 45 percent increase from the previous year. Like many IT service providers, you’re probably getting desensitized to statistics like this. But you still have to face facts: organizations will experience a security incident sooner or later. What’s important is that you are prepared so that the impact doesn’t harm your customers or disrupt their business.

Although, there’s a new element that organizations—both large and small—have to worry about: the “what.” What will happen when I get hacked? What information will be stolen or exposed? What will the consequences look like?

While definitive answers to these questions are tough to pin down, the best way to survive a data breach is to preemptively build and implement an incident response plan. An incident response plan is a detailed document that helps organizations respond to and recover from potential—and, in some cases, inevitable—security incidents. As small- and medium-sized businesses turn to managed services providers (MSPs) like you for protection and guidance, use these six steps to build a solid incident response plan to ensure your clients can handle a breach quickly, efficiently, and with minimal damage.

Step 1: Prepare

The first phase of building an incident response plan is to define, analyze, identify, and prepare. How will your client define a security incident? For example, is an attempted attack an incident, or does the attacker need to be successful to warrant response? Next, analyze the company’s IT environment and determine which system components, services, and applications are the most critical to maintaining operations in the event of the incident you’ve defined. Similarly, identify what essential data will need to be protected in the event of an incident. What data exists and where is it stored? What’s its value, both to the business and to a potential intruder? When you understand the various layers and nuances of importance to your client’s IT systems, you will be better suited to prepare a templatized response plan so that data can be quickly recovered.

Treat the preparation phase as a risk assessment. Be realistic about the potential weak points within the client’s systems; any component that has the potential for failure needs to be addressed. By performing this assessment early on, you’ll ensure these systems are maintained and protected, and be able to allocate the necessary resources for response, both staff and equipment—which brings us to our next step.

Step 2: Build a Response Team

Now it’s time to assemble a response team—a group of specialists within your and/or your clients’ business. This team comprises the key people who will work to mitigate the immediate issues concerning a data breach, protecting the elements you’ve identified in step one, and responding to any consequences that spiral out of such an incident.

As an MSP, one of your key functions will sit between the technical aspects of incident resolution and communication between other partners. In an effort to be the virtual CISO (vCISO) for your clients’ businesses, you’ll likely play the role of Incident Response Manager who will oversee and coordinate the response from a technical and procedural perspective.

Pro Tip: For a list of internal and external members needed on a client’s incident response team, check out this in-depth guide.

Step 3: Outline Response Requirements and Resolution Times

From the team you assembled in step two, each member will play a role in detecting, responding, mitigating damage, and resolving the incident within a set time frame. These response and resolution times may vary depending on the type of incident and its level of severity. Regardless, you’ll want to establish these time frames up front to ensure everyone is on the same page.

Ask your clients: “What will we need to contain a breach in the short term and long term? How long can you afford to be out of commission?” The answers to these questions will help you outline the specific requirements and time frame required to respond to and resolve a security incident.

If you want to take this a step further, you can create quick response guides that outline the team’s required actions and associated response times. Document what steps need to be taken to correct the damage and to restore your clients’ systems to full operation in a timely manner. If you choose to provide these guides, we suggest printing them out for your clients in case of a complete network or systems failure.

Step 4: Establish a Disaster Recovery Strategy

When all else fails, you need a plan for disaster recovery. This is the process of restoring and returning affected systems, devices, and data back onto your client’s business environment.

A reliable backup and disaster recovery (BDR) solution can help maximize your clients’ chances of surviving a breach by enabling frequent backups and recovery processes to mitigate data loss and future damage. Planning for disaster recovery in an incident response plan can ensure a quick and optimal recovery point, while allowing you to troubleshoot issues and prevent them from occurring again. Not every security incident will lead to a disaster recovery scenario, but it’s certainly a good idea to have a BDR solution in place if it’s needed.

Step 5: Run a Fire Drill

Once you’ve completed these first four steps of building an incident response plan, it’s vital that you test it. Put your team through a practice “fire drill.” When your drill (or incident) kicks off, your communications tree should go into effect, starting with notifying the PR, legal, executive leadership, and other teams that there is an incident in play. As it progresses, the incident response manager will make periodic reports to the entire group of stakeholders to establish how you will notify your customers, regulators, partners, and law enforcement, if necessary. Remember that, depending on the client’s industry, notifying the authorities and/or forensics activities may be a legal requirement. It’s important that the response team takes this seriously, because it will help you identify what works and which areas need improvement to optimize your plan for a real scenario.

Step 6: Plan for Debriefing

Lastly, you should come full circle with a debriefing. During a real security incident, this step should focus on dealing with the aftermath and identifying areas for continuous improvement. Take is this opportunity for your team to tackle items such as filling out an incident report, completing a gap analysis with the full team,  and keeping tabs on post-incident activity.

No company wants to go through a data breach, but it’s essential to plan for one. With these six steps, you and your clients will be well-equipped to face disaster, handle it when it happens, and learn all that you can to adapt for the future.


This article was provided by our service partner : Webroot

 

3 MSP Best Practices for Protecting Users

Cyberattacks are on the rise, with UK firms being hit, on average, by over 230,000 attacks in 2017. Managed service providers (MSPs) need to make security a priority in 2018, or they will risk souring their relationships with clients. By following 3 simple MSP best practices consisting of user education, backup and recovery, and patch management, your MSP can enhance security, mitigate overall client risk, and grow revenue.

User Education

An effective anti-virus is essential to keeping businesses safe; however, It isn’t enough anymore. Educating end users through security awareness training can reduce the cost and impact of user-generated infections and breaches, while also helping clients meet the EU’s new GDPR compliance requirements. Cybercriminals’ tactics are evolving and increasingly relying on user error to circumvent security protocols. Targeting businesses through end users via social engineering is a rising favorite among new methods of attack.

Common social engineering attacks include:

  • An email from a trusted friend, colleague or contact—whose account has been compromised—containing a compelling story with a malicious link/download is very popular. For example, a managing director’s email gets hacked and the finance department receives an email to pay an outstanding “invoice”.
  • A phishing email, comment, or text message that appears to come from a legitimate company or institution. The messages may ask you to donate to charity, ‘verify’ information, or notify you that you’re the winner in a competition you never entered.
  • A fraudster leaving a USB around a company’s premises hoping a curious employee will insert it into a computer providing access to company data.

Highly topical, relevant, and timely real-life educational content can minimize the impact of security breaches caused by user error. By training clients on social engineering and other topics including ransomware, email, passwords, and data protection, you can help foster a culture of security while adding serious value for your clients.

Backup and Disaster Recovery Plans

It’s important for your MSP to stress the importance of backups. If hit with ransomware without a secure backup, clients face the unsavory options of either paying up or losing important data. Offering clients automated, cloud-based backup makes it virtually impossible to infect backup data and provides additional benefits, like a simplified backup process, offsite data storage, and anytime/anywhere access. In the case of a disaster, there should be a recovery plan in place. Even the most secure systems can be infiltrated. Build your plan around business-critical data, a disaster recovery timeline, and protocol for disaster communications.

Things to consider for your disaster communications
  • Who declares the disaster?
  • How are employees informed?
  • How will you communicate with customers?

Once a plan is in place, it is important to monitor and test that it has been implemented effectively. A common failure with a company’s backup strategy occurs when companies fail to test their backups. Then, disaster strikes and only then do they discover they cannot restore their data. A disaster recovery plan should be tested regularly and updated as needed. Once a plan is developed, it doesn’t mean that it’s effective or set in stone.

Patch Management

Consider it an iron law; patch and update everything immediately following a release. As soon as patches/updates are released and tested, they should be applied for maximum protection. The vast majority of updates are security related and need to be kept up-to-date. Outdated technology–especially an operating system (OS)–is one of the most common weaknesses exploited in a cyberattack. Without updates, you leave browsers and other software open to ransomware and exploit kits. By staying on top of OS updates, you can prevent extremely costly cyberattacks. For example, in 2017 Windows 10 saw only 15% of total files deemed to be malware, while Windows 7 saw 63%. These figures and more can be found in Webroot’s 2018 Threat Report.

Patching Process

Patching is a never-ending cycle, and it’s good practice to audit your existing environment by creating a complete inventory of all production systems used. Remember to standardize systems to use the same operating systems and application software. This makes the patching process easier. Additionally, assess vulnerabilities against inventory/control lists by separating the vulnerabilities that affect your systems from those that don’t. This will make it easier for your business to classify and prioritize vulnerabilities, as each risk should be assessed by the likelihood of the threat occurring, the level of vulnerability, and the cost of recovery. Once it’s determined which vulnerabilities are of the highest importance, develop and test the patch. The patch should then deploy without disrupting uptime—an automated patch system can help with the process.

Follow these best practices and your MSP can go a lot further toward delivering the security that your customers increasingly need and demand. Not only you improve customer relationships, but you’ll also position your MSP as a higher-value player in the market, ultimately fueling growth. Security is truly an investment MSPs with an eye toward growth can’t afford to ignore.


This article was provided by our service partner : Webroot

Re-Thinking ‘Patch and Pray’

When WannaCry ransomware spread throughout the world last year by exploiting vulnerabilities for which there were patches, we security “pundits” stepped up the call to patch, as we always do. In a post on LinkedIn Greg Thompson, Vice President of Global Operational Risk & Governance at Scotiabank expressed his frustration with the status quo.

Greg isn’t wrong. Deploying patches in an enterprise department requires extensive testing prior to roll out. However, most of us can patch pretty quickly after an announced patch is made available. And we should do it!

There is a much larger issue here, though. A vulnerability can be known to attackers but not to the general public. Managing and controlling vulnerabilities means that we need to prevent the successful exploitation of a vulnerability from doing serious harm. We also need to prevent exploits from arriving at a victim’s machine as a layer of defense. We need a layered approach that does not include a single point of failure–patching.

A Layered Approach

First off, implementing a security awareness training program can help prevent successful phishing attacks from occurring in the first place. The 2017 Verizon Data Breach Investigations Report indicated that 66% of data breaches started with a malicious attachment in an email—i.e. phishing. Properly trained employees are far less likely to open attachments or click on links from phishing email. I like to say that the most effective antimalware product is the one used by the best educated employees.

In order to help prevent malware from getting to the users to begin with, we use reputation systems. If almost everything coming from http://www.yyy.zzz is malicious, we can block the entire domain. If much of everything coming from an IP address in a legitimate domain is bad, then we can block the IP address. URLs can be blocked based upon a number of attributes, including the actual structure of the URL. Some malware will make it past any reputation system, and past users. This is where controlling and managing vulnerabilities comes into play.

The vulnerability itself does no damage. The exploit does no damage. It is the payload that causes all of the harm. If we can contain the effects of the payload then we are rethinking how we control and manage vulnerabilities. We no longer have to allow patches (still essential) to be a single point of failure.

Outside of offering detection and blocking of malicious files, it is important to stop execution of malware at runtime by monitoring what it’s trying to do. We also log each action the malware performs. When a piece of malware does get past runtime blocking, we can roll back all of the systems changes. This is important. Simply removing malware can result in system instability. Precision rollback can be the difference between business continuity and costly downtime.

Some malware will nevertheless make it onto a system and successfully execute. It’s at this point we observe what the payload is about to do. For example, malware that tries to steal usernames and passwords is identified by the Webroot ID shield. There are behaviors that virtually all keyloggers use, and Webroot ID Shield is able to intercept the request for credentials and returns no data at all. Webroot needn’t have seen the file previously to be able to protect against it. Even when the user is tricked into entering their credentials, the trojan will not receive them.

There is one essential final step. You need to have offline data backups. The damage ransomware does is no different than the damage done by a hard drive crash. Typically, cloud storage is the easiest way to automate and maintain secure backups of your data.

Greg is right. We can no longer allow patches to be a single point of failure. But patching is still a critical part of your defensive strategy. New technology augments patching, it does not replace it and will not for the foreseeable future.


This article was provided by our service partner Webroot.

meltdown spectre

Spectre, Meltdown, & the CLIMB Exploit: A Primer on Vulnerabilities, Exploits, & Payloads

In light of the publicity, panic, and lingering despair around Spectre and Meltdown, I thought this might be a good time to clear up the differences between vulnerabilities, exploits, and malware. Neither Spectre nor Meltdown are exploits or malware. They are vulnerabilities. Vulnerabilities don’t hurt people, exploits and malware do. To understand this distinction, witness the CLIMB exploit:

The Vulnerability
Frequently, when a vulnerability is exploited, the payload is malware. But the payload can be benign, or there may be no payload delivered at all. I once discovered a windows vulnerability, exploited the vulnerability, and was then able to deliver the payload. Here’s how that story goes:

It’s kind of embarrassing to admit, but one evening my wife and I went out to dinner, and upon returning, realized we had a problem. It wasn’t food poisoning. We were locked out of our house. The solution was to find a vulnerability, exploit it, and get into the house. The vulnerability I found was an insecure window on the ground floor.

With care I was able to push the window inward and sideways to open it. From the outside, I was able to bypass the clasp that should have held the window closed. Of course, the window was vulnerable for years, but nothing bad came of it. As long as nobody used (exploited) the vulnerability to gain unauthorized access to my home, there was no harm done. The vulnerability itself was not stealing things from my home. It was just there, inert. It’s not the vulnerability itself that hurts you. It’s the payload. Granted, the vulnerability is the enabler.

The window was vulnerable for years, but nothing bad happened. Nobody attacked me, and while the potential for attack was present, an attack (exploit) is not a vulnerability. The same can be true of vulnerabilities in software. Opening the window is where the exploit comes in.

The Exploit
My actual exploit occurred in two stages. First, there was proof of concept (POC). After multiple attempts, I was able to prove that the vulnerable window could be opened, even when a security device was present. Next, I needed to execute the Covert Lift Intrusion Motivated Breach (CLIMB) exploit. Yeah, that means I climbed into the open window, a neat little exploit with no coding required. I suppose I could have broken the window, but I really didn’t want to brick my own house (another vulnerability?).

The Payload
Now we come to the payload. In this case, the payload was opening the door for my wife. You see, not all payloads are malicious. If a burglar had used the CLIMB exploit, they could have delivered a much more harmful payload. They could have washed the dishes (they wouldn’t, unless they were Sheldon Cooper), they could have stolen electronic items, or they could have planted incriminating evidence. The roof is the limit.

Not all vulnerabilities are as easy to exploit as others. All of my second-floor windows had the same vulnerability, but exploiting them would have been more difficult. I am sure happy that I found the vulnerability before a criminal did. Because I was forgetful that fateful night, I’m also happy the vulnerability was there when I found it. As I said, I really didn’t want to break my own window. By the way, I “patched” my windows vulnerability by placing a wooden dowel between the window and the wall.

There you have it. Vulnerabilities, exploits, and payloads explained through the lens of the classic CLIMB exploit.


This article was provided by our service partner : Webroot

meltdown spectre

Microsoft Releases More Patches for Meltdown & Spectre

Microsoft informed users on Tuesday that it released additional patches for the CPU vulnerabilities known as Meltdown and Spectre, and removed antivirus compatibility checks in Windows 10.

Meltdown and Spectre allow malicious applications to bypass memory isolation and access sensitive data. Meltdown attacks are possible due to CVE-2017-5754, while Spectre attacks are possible due to CVE-2017-5753 (Variant 1) and CVE-2017-5715 (Variant 2). Meltdown and Spectre Variant 1 can be resolved with software updates, but Spectre Variant 2 requires microcode patches.

In addition to software mitigations, Microsoft recently started providing microcode patches as well. It initially delivered Intel’s microcode updates to devices running Windows 10 Fall Creators Update and Windows Server 2016 (1709) with Skylake processors.

Now that Intel has developed and tested patches for many of its products, Microsoft has also expanded the list of processors covered by its Windows 10 and Windows Server 2016 updates. Devices with Skylake, Coffee Lake and Kaby Lake CPUs can now receive the microcode updates from Intel via the Microsoft Update Catalog.

Microsoft also informed customers on Tuesday that software patches for the Meltdown vulnerability are now available for x86 editions of Windows 7 and Windows 8.1.

The company has also decided to remove the antivirus compatibility checks in Windows 10. The decision to introduce these checks came after the tech giant noticed that some security products had created compatibility issues with the Meltdown patches. This resulted in users not receiving security updates unless their AV vendor made some changes.

Microsoft has determined that this is no longer an issue on Windows 10 so the checks have been removed. On other versions of the operating system, users will still not receive updates if their antivirus is incompatible.

Microsoft’s Patch Tuesday updates for March 2018 fix over 70 flaws, including more than a dozen critical bugs affecting the company’s Edge and Internet Explorer web browsers.

meltdown spectre

Meltdown & Spectre: Where Are We at Now?

Meltdown and Spectre still continue to dominate the security news and the more we delve into it, we are starting to understand the depth and breadth of what this now means for the future of the security landscape.

Turns out the three variants of side-channel attacks, Meltdown and two different for Spectre, were discovered back in June of last year [2017] by researchers using speculative execution, which is where processors execute on code and then fetch and store the speculative results in cache. It’s a technique used to optimize and improve the performance of a device. What is important to note with Spectre is that it puts users at risk for information disclosure by exposing the weakness in the architecture of most processors in the market, and the breadth is vast: Intel, AMD, ARM, IBM (Power, Mainframe Z series) and Fujitsu/Oracle SPARC implementations across PCs, physical and virtual servers, smartphones, tablets, networking equipment and possibly IoT devices.

Currently there are no reported exploits in the wild.

Of the two, Meltdown is the easier one to mitigate with operating system updates. AMD processors are not affected by Meltdown. Spectre is a bit more complex to resolve because it is a new class of attack. The two variants of Spectre both can potentially do harm like stealing logins and other user data residing on the affected device. Intel, ARM, and AMD processors are affected by Spectre. Recently, Microsoft released another emergency update to disable Intel’s microcode fix. This original update was meant to patch for variant 2 of Spectre. Unfortunately, that update had adverse effects as there were numerous reports of reboots and instability, so Microsoft issued an out of band update to disable.

Things are still evolving around Spectre and while operating system updates and browser updates are helping to patch for Spectre, it is being reported by some sources that a true fix may be an update to the hardware (processor) itself.

The following is a chart* to clarify each vulnerability:

meltdown-spectre-chart

*Chart is courtesy of SANS/Rendition Infosec. See full presentation here.

It will be important over the next few weeks to stay on top of any breaking news around Meltdown and Spectre. Mitigation efforts should be underway in your IT organization to prevent a future zero-day attack.


This article was provided by our service partner : Connectwise