Posts

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

office365

Introducing the Office 365 Secure Score

Ever wonder how secure your Office 365 organization really is? Time to stop wondering – the Office 365 Secure Score is here to help. Secure Score analyzes your Office 365 organization’s security based on your regular activities and security settings and assigns a score. Think of it as a credit score for security.

How do I get to Secure Score?

Anyone who has admin permissions (global admin or a custom admin role) for an Office 365 Business Premium or Enterprise subscription can access the Secure Score at https://securescore.office.com. Users who aren’t assigned an admin role won’t be able to access Secure Score. However, admins can use the tool to share their results with other people in their organization.

How does it work?

Secure Score figures out what Office 365 services you’re using (like OneDrive, SharePoint, and Exchange) then looks at your settings and activities and compares them to a baseline established by Microsoft. You’ll get a score based on how aligned you are with best security practices.

office365 secure score

If you want to improve your score, review the action queue to see what you can do to help increase security and reduce risks.

secure score 1

Expand an action to learn about what threats it’ll help protect you from and how you’ll get the job done.

To see the impact of your actions on your organization’s security, go to the Score Analyzer page and review your history.

Click any data point to see a breakdown of your score for that day. You can scroll down to see which controls were enabled and how many points you earned that day for each control.

How will it help me?

Using Secure Score helps increase your organization’s security by encouraging you to use the built-in security features in Office 365 (many of which you already purchased but might not be aware of). Learning more about these features as you use the tool will help give you piece of mind that you’re taking the right steps to protect your organization from threats.

But don’t just take our word for it. Customers who are using Secure Score have seen their score increase 5 times more than customers who aren’t using it. (The increase in score corresponds with the security features being used in their organizations.)

Check out this Microsoft blog post to learn more.

meltdown spectre

Explained : Meltdown and Spectre CPU vulnerability

Anton Gostev from Veeam wrote a wonderful article on the Spectre and Meltdown vulnerability in his weekly Veeam forums digest. I have reposted it below as it explains the current situation very well:

 

By now, most of you have probably already heard of the biggest disaster in the history of IT – Meltdown and Spectre security vulnerabilities which affect all modern CPUs, from those in desktops and servers, to ones found in smartphones. Unfortunately, there’s much confusion about the level of threat we’re dealing with here, because some of the impacted vendors need reasons to explain the still-missing security patches. But even those who did release a patch, avoid mentioning that it only partially addresses the threat. And, there’s no good explanation of these vulnerabilities on the right level (not for developers), something that just about anyone working in IT could understand to make their own conclusion. So, I decided to give it a shot and deliver just that.

First, some essential background. Both vulnerabilities leverage the “speculative execution” feature, which is central to the modern CPU architecture. Without this, processors would idle most of the time, just waiting to receive I/O results from various peripheral devices, which are all at least 10x slower than processors. For example, RAM – kind of the fastest thing out there in our mind – runs at comparable frequencies with CPU, but all overclocking enthusiasts know that RAM I/O involves multiple stages, each taking multiple CPU cycles. And hard disks are at least a hundred times slower than RAM. So, instead of waiting for the real result of some IF clause to be calculated, the processor assumes the most probable result, and continues the execution according to the assumed result. Then, many cycles later, when the actual result of said IF is known, if it was “guessed” right – then we’re already way ahead in the program code execution path, and didn’t just waste all those cycles waiting for the I/O operation to complete. However, if it appears that the assumption was incorrect – then, the execution state of that “parallel universe” is simply discarded, and program execution is restarted back from said IF clause (as if speculative execution did not exist). But, since those prediction algorithms are pretty smart and polished, more often than not the guesses are right, which adds significant boost to execution performance for some software. Speculative execution is a feature that processors had for two decades now, which is also why any CPU that is still able to run these days is affected.

Now, while the two vulnerabilities are distinctly different, they share one thing in common – and that is, they exploit the cornerstone of computer security, and specifically the process isolation. Basically, the security of all operating systems and software is completely dependent on the native ability of CPUs to ensure complete process isolation in terms of them being able to access each other’s memory. How exactly is such isolation achieved? Instead of having direct physical RAM access, all processes operate in virtual address spaces, which are mapped to physical RAM in the way that they do not overlap. These memory allocations are performed and controlled in hardware, in the so-called Memory Management Unit (MMU) of CPU.

At this point, you already know enough to understand Meltdown. This vulnerability is basically a bug in MMU logic, and is caused by skipping address checks during the speculative execution (rumors are, there’s the source code comment saying this was done “not to break optimizations”). So, how can this vulnerability be exploited? Pretty easily, in fact. First, the malicious code should trick a processor into the speculative execution path, and from there, perform an unrestricted read of another process’ memory. Simple as that. Now, you may rightfully wonder, wouldn’t the results obtained from such a speculative execution be discarded completely, as soon as CPU finds out it “took a wrong turn”? You’re absolutely correct, they are in fact discarded… with one exception – they will remain in the CPU cache, which is a completely dumb thing that just caches everything CPU accesses. And, while no process can read the content of the CPU cache directly, there’s a technique of how you can “read” one implicitly by doing legitimate RAM reads within your process, and measuring the response times (anything stored in the CPU cache will obviously be served much faster). You may have already heard that browser vendors are currently busy releasing patches that makes JavaScript timers more “coarse” – now you know why (but more on this later).

As far as the impact goes, Meltdown is limited to Intel and ARM processors only, with AMD CPUs unaffected. But for Intel, Meltdown is extremely nasty, because it is so easy to exploit – one of our enthusiasts compiled the exploit literally over a morning coffee, and confirmed it works on every single computer he had access to (in his case, most are Linux-based). And possibilities Meltdown opens are truly terrifying, for example how about obtaining admin password as it is being typed in another process running on the same OS? Or accessing your precious bitcoin wallet? Of course, you’ll say that the exploit must first be delivered to the attacked computer and executed there – which is fair, but here’s the catch: JavaScript from some web site running in your browser will do just fine too, so the delivery part is the easiest for now. By the way, keep in mind that those 3rd party ads displayed on legitimate web sites often include JavaScript too – so it’s really a good idea to install ad blocker now, if you haven’t already! And for those using Chrome, enabling Site Isolation feature is also a good idea.

OK, so let’s switch to Spectre next. This vulnerability is known to affect all modern CPUs, albeit to a different extent. It is not based on a bug per say, but rather on a design peculiarity of the execution path prediction logic, which is implemented by so-called Branch Prediction Unit (BPU). Essentially, what BPU does is accumulating statistics to estimate the probability of IF clause results. For example, if certain IF clause that compares some variable to zero returned FALSE 100 times in a row, you can predict with high probability that the clause will return FALSE when called for the 101st time, and speculatively move along the corresponding code execution branch even without having to load the actual variable. Makes perfect sense, right? However, the problem here is that while collecting this statistics, BPU does NOT distinguish between different processes for added “learning” effectiveness – which makes sense too, because computer programs share much in common (common algorithms, constructs implementation best practices and so on). And this is exactly what the exploit is based on: this peculiarity allows the malicious code to basically “train” BPU by running a construct that is identical to one in the attacked process hundreds of times, effectively enabling it to control speculative execution of the attacked process once it hits its own respective construct, making one dump “good stuff” into the CPU cache. Pretty awesome find, right?

But here comes the major difference between Meltdown and Spectre, which significantly complicates Spectre-based exploits implementation. While Meltdown can “scan” CPU cache directly (since the sought-after value was put there from within the scope of process running the Meltdown exploit), in case of Spectre it is the victim process itself that puts this value into the CPU cache. Thus, only the victim process itself is able to perform that timing-based CPU cache “scan”. Luckily for hackers, we live in the API-first world, where every decent app has API you can call to make it do the things you need, again measuring how long the execution of each API call took. Although getting the actual value requires deep analysis of the specific application, so this approach is only worth pursuing with the open-source apps. But the “beauty” of Spectre is that apparently, there are many ways to make the victim process leak its data to the CPU cache through speculative execution in the way that allows the attacking process to “pick it up”. Google engineers found and documented a few, but unfortunately many more are expected to exist. Who will find them first?

Of course, all of that only sounds easy at a conceptual level – while implementations with the real-world apps are extremely complex, and when I say “extremely” I really mean that. For example, Google engineers created a Spectre exploit POC that, running inside a KVM guest, can read host kernel memory at a rate of over 1500 bytes/second. However, before the attack can be performed, the exploit requires initialization that takes 30 minutes! So clearly, there’s a lot of math involved there. But if Google engineers could do that, hackers will be able too – because looking at how advanced some of the ransomware we saw last year was, one might wonder if it was written by folks who Google could not offer the salary or the position they wanted. It’s also worth mentioning here that a JavaScript-based POC also exists already, making the browser a viable attack vector for Spectre.

Now, the most important part – what do we do about those vulnerabilities? Well, it would appear that Intel and Google disclosed the vulnerability to all major vendors in advance, so by now most have already released patches. By the way, we really owe a big “thank you” to all those dev and QC folks who were working hard on patches while we were celebrating – just imagine the amount of work and testing required here, when changes are made to the holy grail of the operating system. Anyway, after reading the above, I hope you agree that vulnerabilities do not get more critical than these two, so be sure to install those patches ASAP. And, aside of most obvious stuff like your operating systems and hypervisors, be sure not to overlook any storage, network and other appliances – as they all run on some OS that too needs to be patched against these vulnerabilities. And don’t forget your smartphones! By the way, here’s one good community tracker for all security bulletins (Microsoft is not listed there, but they did push the corresponding emergency update to Windows Update back on January 3rd).

Having said that, there are a couple of important things you should keep in mind about those patches. First, they do come with a performance impact. Again, some folks will want you to think that the impact is negligible, but it’s only true for applications with low I/O activity. While many enterprise apps will definitely take a big hit – at least, big enough to account for. For example, installing the patch resulted in almost 20% performance drop in the PostgreSQL benchmark. And then, there is this major cloud service that saw CPU usage double after installing the patch on one of its servers. This impact is caused due to the patch adding significant overhead to so-called syscalls, which is what computer programs must use for any interactions with the outside world.

Last but not least, do know that while those patches fully address Meltdown, they only address a few currently known attacks vector that Spectre enables. Most security specialists agree that Spectre vulnerability opens a whole slew of “opportunities” for hackers, and that the solid fix can only be delivered in CPU hardware. Which in turn probably means at least two years until first such processor appears – and then a few more years until you replace the last impacted CPU. But until that happens, it sounds like we should all be looking forward to many fun years of jumping on yet another critical patch against some newly discovered Spectre-based attack. Happy New Year! Chinese horoscope says 2018 will be the year of the Earth Dog – but my horoscope tells me it will be the year of the Air Gapped Backup.
certificates

Why you should get a handle on Certificates

Many companies (especially smaller ones) feel they do not have the work force or time to deal with properly implementing signed TLS certificates across their organization.  This can lead to potentially serious problem because of the user’s perception while browsing the company intranet sites. If something potentially is hacked and everyone is accustomed to clicking through certificate warnings, then company accounts and data can easily be compromised.

Organizations that deploy Microsoft Certificate Services or even their own Certificate Authority (CA) using the OpenSSL toolkit are in a much better position to handle attacks and organize their application infrastructure.

Think twice about clicking through Pop-ups. What is the cost of a breech? Get a recognized root CA deployed to your clients and install the associated server certificates on all of your user facing systems.