Tag Archives: Mitigations

Mitigating the Increasing Risk Facing Critical Infrastructure and the Internet of Things

With attackers and malware authors extending their reach to more and more areas of our everyday lives, both companies and individuals need to take steps to improve the security of their equipment/devices. It’s not just devices such as thermometers (while important) in our homes at risk; devices that impact health and safety as well as entire communities and economies are being / or will be targeted.

For example, last month a cyber-attack took place in Ukraine that while it only lasted approximately 1 hour, served to cause a power outage in an entire district of Kiev. The on-going investigation into this attack believes it to be the same attackers responsible for the December 2015 attack (that attack affected approximately 250,000 people for up to 6 hours).

In a similar manner, a smaller energy company (at an undisclosed location) was a victim of the Samsam ransomware (defined). The attackers initially compromised the web server and used a privilege escalation vulnerability (defined) to install further malware and spread throughout the network. The attackers demanded 1 Bitcoin per infected system. The firm paid the ransom and received a decryption key that didn’t work.

Fortunately, this energy company had a working backup and was back online after 2 days. The root cause of infection? Their network not being separated by a DMZ (defined) from their industrial networks. This Dark Reading article also details 2 further examples of businesses affected who use industrial systems namely a manufacturing plant and a power plant. Both were located in Brazil.

Mark Stacey of RSA’s incident response team says that while nation states have not yet employed ransomware in industrial systems, it will certainly happen. He cites the example of a dam, where the disabling of equipment may not demand a large ransom compared to the act of encrypting the data required for its normal operation.

Former US National Security Official Richard Clarke is suggesting the use of a tried and tested means of increasing the security of all deployed industrial control systems. As it is very difficult convincing those on the Board of Directors to provide budget for something that has not happened/may not happen, he suggests employing an approach similar to that of the Y2K bug. This would require introducing regulations that require all devices after a given date be in a secured state against cyber-attack. He advocates electric power, connected cars and healthcare providers follow this approach and notes that without regulation “none of this is going to happen.” Since these regulations would apply to all ICS/SCADA (defined) vendors, they would also not loose competitiveness

With security analysts predicting further compromises of ICS/SCADA equipment this year, we need to better protect this infrastructure.

For enterprises and businesses, the regulations proposed above should assist with securing IoT and ICS/SCADA devices. However, this is just the beginning. This scanner from Beyond Trust is another great start. As that article mentions the FTC is offering $100,000 to “a company that can discover an innovative way of managing and patching IoT devices.” Securing IoT devices is not an easy problem to solve.

However, progress is happening with securing critical infrastructure and Internet of Things (IoT)(defined) devices. For example, please find below resources/recommendations, tools and products that can help protect these systems and devices.

How can we better secure ICS/SCADA devices?
These devices power our critical infrastructure e.g. power, gas, communications, water filtration etc. The US ICS-CERT has a detailed list of recommendations available from the following links:

ICS CERT Recommended Practices
ICS-CERT Secure Architecture Design
ICS Defense In-Depth (PDF)

An ICS-CERT overview of the types of vulnerabilities that these systems face.

Securing IoT devices in industry
Free IoT Vulnerability Scanner Hunts Enterprise Threats (Dark Reading.com)
Defending the Grid
Network and IoT to underpin Trend Micro’s 2017 strategy

Securing IoT in the medical sector/businesses
Hospitals are under attack in 2016 (Kaspersky SecureList)
Fooling the Smart City (Kaspersky SecureList)

Recommendations for consumer IoT devices are the following
My previous recommendations on securing IoT devices
Blog Post Shout Out: New Wireless Routers Enhance Internet of Things Protection
Securing Your Smart TV
8 tips to secure those IoT devices (Network World)
Who Makes the IoT Things Under Attack? (Krebs on Security)

=======================
I hope that you find the above resources useful for securing ICS/SCADA as well as IoT devices that are very likely a target this year.

Thank you.

Microsoft Announces End of Support for EMET

====================
Update: 13th December:
Shortly after publishing this blog post, I received a response (apologies for not posting this update sooner) from the Microsoft EMET team to some questions that I had asked with regard to how to harden applications that do not incorporate security mitigations be default on Windows 10 once EMET has reached it’s end of support. These can be used with any applications, not just legacy applications.

They suggested using the Process Mitigation Options GPO which is described in the link provided by them below. This can be used to apply mitigations such as DEP, SEHOP, Mandatory/Force ASLR, and Bottom-up ASLR to a process without using EMET. They also mentioned this GPO should be receiving further usability improvements in the future.

While the above mitigations don’t provide the same level of protection that EMET offered, they offer an improvement over not using them. From their message there appears to be a possibility that further mitigations will be available in later updates to Windows 10.

I have provided the text of their message below.

====================
Thank you for your support and for providing this helpful feedback! We will consider these suggestions as we develop our documentation and continue to evolve our security and mitigation features in future releases of Windows 10.

Today, the Process Mitigation Options GPO documented below can be used to configure certain in-box Windows 10 mitigations for particular processes.

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/override-mitigation-options-for-app-related-security-policies

These mitigations include DEP, SEHOP, Mandatory/Force ASLR, and Bottom-up ASLR. Though we’re aware that this GPO presents some UX challenges, we’re actively working to improve our mitigation management experience for future releases.
====================

Once again shortly after publishing this post, I came across this blog post from the CERT/CC team of Carnegie-Mellon University. They recommend using EMET on Windows 10 after the end of support deadline in July 2018 to protect applications that do not incorporate security mitigations.

This is of course assuming that future builds/versions of Windows 10 allow EMET to continue to function. If this is not the case, the alternatives discussed above could be considered.

The CERT blog post also provides the steps to enable system-wide DEP an ASLR if EMET (or the alternatives) cannot be used. That post also provides a comparison table of Windows 7 and Windows 10 with and without EMET to better display the benefits EMET offers.

How the CERT/CC team align to the US CERT team is mentioned in this Sophos blog post.

I hope that you find this additional information useful. Thank you.

====================
Original Post:
====================
Early last week Microsoft extended the support deadline of their exploit mitigation tool, Enhanced Mitigation Experience Toolkit (EMET). The final support deadline is now the 31st of July 2018 (originally 27th January 2017).

Why Should This Announcement Be Considered Important?
At this time there are known bypasses for EMET e.g. this and this. While a competitor to EMET, SurfRight HitmanPro.Alert mitigated the WoW64 bypass, Microsoft never incorporated such changes (or at least never documented such improvements). In addition in their most recent blog post concerning EMET; Microsoft states that EMET’s effectiveness against modern exploit kits (defined) has not been proven and were not designed to be a long term solution just a “stop gap” to add extra protection to older versions of Windows without necessitating upgrading to a newer version of Windows.

In addition, Microsoft mentioned that EMET can reduce the performance of the applications that it protects. Moreover it can impact their reliability since it hooks into the operating system at a low level in order to add its protection to the applications chosen by a system administrator or individual user.


You recommend EMET a lot on this blog; is that going to change?

In the short term, no. In the long-term, yes. While EMET is still supported I will recommend its use but will note that its end of support date is approaching.

I still believe that EMET can provide value by adding mitigations to commonly used applications both for enterprise/business users and individual user applications when those applications don’t include mitigations such as DEP or ASLR etc. by default after installing them. I don’t agree with Microsoft’s decision to end support for EMET for this reason.

I believe that they were overly critical of EMET in their most recent blog post. Yes it can cause performance issues (usually disabling one or both EAF and EAF+ mitigations resolves this) and can cause compatibility issues. In general, this depended on the set up of your individual applications. E.g. if you don’t install add-ons into Microsoft Word, Excel etc. they are far more likely to work with EMET without any changes. In many business and enterprise environments I realise this isn’t an option.

In my experience, accepting the defaults of the EMET configuration and adding all but EAF and EAF+ to custom applications would almost always work. Adding EAF and/or EAF+ was appropriate if they didn’t cause performance issues. A further reference regarding EMETs mitigations and another application compatibility list is available here.

I always believed that if you were going to deploy EMET across an organisation that you had to extensively test it. This could possibly involve testing it on hardware and software that mostly (or exactly if possible) emulates each type of server and workstation in use across each team in your organisation. Using just one configuration across your organisation would not work or if it did, it would be sub-optimal since you would likely have to disable many more mitigations to make it work smoothly across all systems in use.

How secure non-best practice applications (namely that they don’t include mitigations such as DEP or ASLR) are when installed on Windows 10 is uncertain. However given the continuing work that Microsoft is doing with Windows 10 and their recent publishing of details concerning the new mitigations available in Windows 10 (the original security benefits are discussed in a previous blog post) Windows 10 in the long term is the way forward. Overall however the Windows 10 without any additions is more secure by default than Windows 7 or Windows 8.1. Just one example would be the disabling of LDR Hotpatching which mitigates the issues caused by abusing its functionality discussed here and here.


If I can’t upgrade to Windows Server 2016 or Windows 10 before the support for EMET ends, what would you recommend?

If your business applications already include security mitigations such as DEP and ASLR, you may not need EMET and can simply ignore it. EMET and indeed the competitors to EMET are only necessary if the applications you use need hardening.

For business, enterprises and individuals Alternatives to EMET are Malwarebytes Anti-Exploit (Business and Personal editions) and HitmanPro.Alert. Malwarebytes Anti-Exploit can be used to protect custom applications and thus can take that role over from EMET. I am currently testing Malwarebytes Anti-Exploit and HitmanPro.Alert and will comment on their resource usage and any drawbacks they may have. I will update this post when I have completed this testing.

Alternatively try to contact the developers of the custom business applications that you are using and request that they enable some security mitigations e.g. DEP and ASLR. Visual Studio 2015 is required for adding CFG but DEP and ASLR can be added using compilers like Mono and mingw (example 2 and example 3).

I contacted the developer of a 64 bit open source tool and he mentioned that since he still supports Windows XP migrating to a newer version of Visual Studio is not an option right now but would consider it for the future. Another small but commercial application developer (a 64 bit utility for Windows) was very enthusiastic about a new version of Visual Studio offering extra mitigations and promised to add these to the next major release of his product which is currently in beta and moving towards a release candidate.

Thank you.

VideoLAN Releases VLC Version 2.2.4

In early June the open source media player VLC created by the VideoLAN non-profit organization was updated to version 2.2.4.

This update is available for Linux, Apple Mac OS X and Windows. It addresses 2 security issues mentioned here (1x VLC issue and a 3rd party library issue detailed in this security advisory). This update is available for download for the above operating systems from this page.

One other noteworthy addition is that when VLC 3.0 is released it will feature High Entropy ASLR (Address Space Layout Randomization (defined)). I have discussed HEASLR on this blog before and it’s an excellent security measure/control/mitigation (defined). Further information on HEASLR can be found on Alex Ionescu’s blog. I will be very pleased to see it present in this upcoming version.

If you use VLC, please update as soon as possible to address the above mentioned security vulnerabilities as well as the general software bugs that were resolved.

Thank you.

Google Chrome Benefits From Windows 10 Security Mitigations

Earlier this year in February, Google added several new security mitigations (defined within this post) to Google Chrome that work in partnership with lesser known changes within the Windows 10 update (known as Build 10586 or Version 1511) made available by Microsoft in November last year.

How Do These New Techniques Work?
In total 3 new mitigations were added:

    1. Block un-trusted fonts
    On numerous occasions over the last year Microsoft have released security updates that address vulnerabilities related to Windows handling of fonts (examples here, here and here (among others)). Such vulnerabilities are of interest to attackers since when successfully exploited they provide the attacker with kernel mode privileges (defined). The concept of a kernel is defined here. A mitigation designed to make exploiting such vulnerabilities more difficult is present in the most recent version of Microsoft EMET version 5.5 and is discussed in more detail on page 11 of the EMET user guide as well as this TechNet article.

    Windows 10 features a system wide means of blocking the use of fonts to only the Windows Font directory (folder) by default located at: C:\Windows\Fonts However due to the application compatibility issues that this feature can cause it is turned off by default. While the ability to enable this security feature for running applications on a per process (defined) basis is available this is unsuitable for Chrome since it creates multiple processes with different security permissions applied. However, the November 2015 Windows 10 added the ability to enable the blocking of fonts for individual processes of which Chrome can now take advantage of.

    2. Block the creation of child processes
    This mitigation is intended to block an attacker’s exploit from creating new running processes without any restrictions of the Google Chrome sandbox (discussed below) on a Windows device if they are successful at exploiting Google Chrome. Google Chrome has always incorporated a protective sandbox (defined) that prevents malicious code from being able to make changes to the computer upon which Google Chrome is installed.

    To address a vulnerability reported by Google to Microsoft in late 2014; the Windows 10 November update provides the ability to applications (if they choose to use it) to block the ability to create child processes including console processes (disused further in the Google bug report linked to above). This new capability is now utilized by Google Chrome.

    3. Block the loading of DLLs (defined) from network drives
    While Windows provides the ability for an application to load a DLL from a network location (e.g. a mapped network drive); this can be used by an attacker to insert malicious code into a legitimate application (e.g. if they substitute a legitimate DLL in a network location with a malicious DLL of the same name).

    This ability has been disabled within Google Chrome when it’s installed on Windows 10 with the November 2015 update further hardening it against this type of attack. This capability is similar to the defences of Microsoft Edge against DLL injection.

    Conclusion
    All of the above new mitigations provide defence-in-depth (defined)(PDF) security against possible future vulnerabilities and provide further incentive for Windows users to migrate to Windows 10. Please do not misunderstand me I am not trying to advocate that users do so, I am simply pointing out the additional security features that are available if you choose to use Windows 10 (with the November update) and Google Chrome in combination.

    Thank you.

Microsoft Releases EMET 5.5

====================
Update: 14th March 2017:
Since my last update of this post EMET was updated to version 5.52 to resolve the following issues:

  • An issue with the EAF mitigation that causes some applications to hang on Windows 7 SP1.
  • A fix to the MSI installer to allow in-place upgrade behavior.
  • Removed EAF+ mitigation for Chrome from “Popular Software.xml”
  • Fixed import behavior for System Mitigations.

Thank you.

====================
Update: 17th November 2016:
====================
Please note that Microsoft EMET is in the process of being retired with the end of support scheduled for the 31st of July 2018. Further details are available in this blog post.

However Microsoft updated EMET in August 2016 to version 5.51 which incorporates the following minor changes:

  • EMET 5.5 GUI crashing on startup
  • Unexpected BitLocker warning in EMET 5.5 when changing system-wide DEP setting

Further details on EMETs mitigations as well known compatibility issues are listed in this article. A more detailed forum thread on this topic is available here.

Thank you.
====================

====================
Update: 17th November 2016:
Please note that Microsoft EMET is in the process of being retired with the end of support scheduled for the 31st of July 2018. Further details are available in this blog post.

However Microsoft updated EMET in August 2016 to version 5.51 which incorporates the following minor changes:

  • EMET 5.5 GUI crashing on startup
  • Unexpected BitLocker warning in EMET 5.5 when changing system-wide DEP setting

Further details on EMETs mitigations as well known compatibility issues are listed in this article. A more detailed forum thread on this topic is available here.

Thank you.
====================

Update 23rd February 2016:
According to this FireEye blog post EMET 5.5 also addresses a critical security vulnerability that was responsibly disclosed (defined) to Microsoft.

As mentioned below, if you use a version of EMET prior to version 5.5, please use the links provided to install version 5.5. as soon as possible. Thank you.

Update 3rd April 2016:
As discussed in a more recent blog post the Untrusted font mitigation of EMET 5.5 is now used by Google Chrome when installed on Windows 10 (with the November 2015 update). Thank you.

=======================
Original Post:
=======================
In early February Microsoft released version 5.5 of their Enhanced Mitigation Experience Toolkit (EMET).

This is an important update for users of Windows 10 since it adds full compatibility with that version of Windows in contrast to the previous 5.2 version of EMET. The full list of changes in this new version is available in this Microsoft blog post.

In addition, this version adds a noteworthy enhancement for Windows 10 users that blocks exploit that use font files stored in any directory (folder) in order to gain additional privileges when either remotely or locally (already have a presence) attacking your system. All fonts not stored in the %windir%/Fonts directory will not be loaded. If you are currently using an older version of EMET, please consider upgrading to EMET 5.5 to take advantage of the enhancements in this update. Further resources concerning installation, use and obtaining support for EMET are available on the Protecting Your PC page of this blog.

Please note that in order to migrate previous EMET settings to version 5.5 Microsoft have provided a PowerShell script to do so. Instructions for using this script to migrate the settings are available on page 33 and 36 of the EMET 5.5 users guide.

Thank you.

Possible Future Security Improvements For Adobe Flash Player In Development

Update 21st February 2016:
In late December 2015 Adobe discussed in a blog post the increasing use of extra security mitigations (defined within this post) being added to Flash Player as a result of their work with the Google Project Zero team and Microsoft’s research team.

Adobe are gradually introducing these mitigations to allow for feedback/suggestions to be used to improve the newly added and soon to be added mitigations. Moreover, by continually changing the code of Flash Player by adding these security features as Adobe points out makes it harder for attackers to obtain consistently working exploits for use within exploit kits (defined).

As discussed in a previous blog post mitigations were added to Vector objects to make exploiting use-after-free (defined) vulnerabilities more difficult. This work has been extended to ByteArrays. Adobe also extended their heap isolation (more information in this post) work in December’s Flash Player update.

In addition, in mid-2015 Adobe added Control Flow Guard (CFG) (defined) protection to protect the code generated by their Just-In-Time (JIT) compiler (defined). As I mentioned in a previous post, CFG was added to Flash Player in 2014 and a bypass was quickly found. I’m not stating that CFG protection isn’t worthwhile just that like any security technology it is not perfect but does add extra effort on the part of the attacker to bypass making it a worthy/welcome addition.

In Adobe’s conclusion of their post they mention that further improvements will be made available in 2016. I will update this post as those security improvements become available.

Thank you.

=======================
Original Post:
=======================
On the 10th of November Adobe released a security update for Flash Player to address 17 security issues (CVEs, defined). Among these issues was a use-after free (defined) issue (designated CVE-2015-7663) responsibly disclosed (defined) to Adobe by security firm Endgame.

Endgame have since detailed in a blog post 2 new techniques/defensive measures that they have developed with a view to have these included in future versions of Flash Player.

How Do These New Techniques Work?
While Adobe’s recently added security mitigations (defensive measures used to harden against attack) focus on a commonly used object (Vector. Objects) within the ActionScript language used by Flash Player. This type of object is only one class of object and as Endgame mentions attackers will simply move on to find another type of object that does not include such defenses and work to exploit it (indeed attackers have developed a bypass to the security mitigations introduced by Adobe earlier this year which has been analysed by Trend Micro).

Endgame’s approach is to apply heap (defined) isolation to as many objects as possible rather than commonly exploited objects. A use-after-free issue relies on the fact that an attacker can place an object of their choice into the space/gap in computer memory that was previously allocated for another object and direct the target program/application to access that specifically placed object. The isolation mitigation developed by Endgame seeks to only allow the attacker to re-allocate the original object rather than one of their choice which breaks the principle behind a use-after-free issue rendering it ineffective for exploitation.

Since Flash Player incorporates commonly used defences such as DEP and ASLR (references discussing DEP are provided here (see “References” at the end of the post), while ASLR is discussed here and here (see “References” at the end of the post)) attackers generally seek to bypass these mitigations using a technique known as Return Oriented Programming (ROP)(defined).

However, to do this the attackers must change the sequence of steps being carried out by the target application. For example, instead of carrying out instructions 1, 2 and 3, the attackers will have the program jump within the program (similar to jumping position to the front of a queue of people so that you are next to be served) to instructions of the attacker’s choice.

Moreover, Endgame has developed a technique to detect when this jump is carried out without the need for making extensive changes to the target program/application. When such a jump is detected, a message can be displayed allowing the person using the computer to abort what the program is doing or to continue. This technique is similar in approach to Control Flow Guard (CFG) introduced by Microsoft with Visual Studio 2015. CFG was discussed in a past blog post of mine.

Conclusion
As mentioned at the end of my previous blog post on Adobe Flash Player mitigations it is always welcome to see such improvements being made in an effort to thwart attackers since it raises the bar/standard attackers must use to successfully compromise their intended targets.

I very much hope that these mitigations are effective (if only for a short time against attackers). As before, I don’t mean this is in an offensive manner, no mitigation is perfect and these new mitigations were designed to make it harder not impossible for exploits occur (as mentioned by Trend Micro at the end of a blog post written last month).

Thank you.

Adobe and Google Strengthen Flash against Exploits

====================
Update: 30th November 2015:
The additional Flash Player security mitigations discussed in this blog post have since been bypassed by attackers. Further details are available from this Trend Micro blog post. Possible further mitigations are in development by security firm Endgame. These additional mitigations are discussed in a more recent blog post.
Thank you.

====================
Original Post:
====================
With the recent public disclosure of 3 Adobe Flash Player zero day vulnerabilities as part of the data breach of the “Hacking Team”; Adobe and Google have worked together to introduce additional exploit mitigations/defences to Adobe Flash Player.

These mitigations incorporate 3 improvements as detailed below:

Heap Partitioning
To protect against general buffer overflows that overflow into another object e.g. Vector. the memory in use by Flash Player for such Vector. objects is no longer stored in one area which means that an overflow cannot occur since one area of memory is no longer located beside another. In reality the Flash heap no longer contains Vector. objects, instead they are placed on the memory heap belonging to the operating system and no longer present on the Flash heap (where they could be corrupted). This mitigation defends against heap overflow and the common use-after-free (defined) exploits (since free chunks of memory are no longer freed within the Flash heap thus the attacker does not know the value to set the pointer to; in order to be able to use a new block of memory placed at the location that was just freed). This mitigation is especially effective with 64 bit versions of web browsers installed on a 64 bit operating systems due to 32 bit address space limitations no longer being present.

Memory Randomization of the Flash Heap
For allocations of memory that are greater than 1 MB are now randomized more thoroughly than before (in other words more entropy has been added). When a 64 bit system is in use, the Flash heaps position in memory will very likely be located far from other memory in use. Since the heap is so far away from other memory sections in use, a buffer overflow would unlikely be able to corrupt enough memory sections in order to use them for malicious purposes (since a 32 bit buffer overflow has a limit e.g. 2^32 * sizeof (in bytes) of variable type in use e.g. char, int, double etc.). The limit would be reached before the overflow could reach far enough into memory to have the intended effect.

At this time, this mitigation is only available within the Flash plugin built into Google Chrome, Adobe plans to make this mitigation available for all other versions of Flash in August.

Vector Length Validation
The final notable mitigation prevents the successful exploitation of buffer overflows for Vector objects. For each Vector object that is created a corresponding length of that object is stored along with a validation secret namely a value generated when the object was allocated by the operating system memory manager. When an exploit corrupts the known length of the Vector object, if they don’t know the value of the validation secret, this will cause a runtime error to be generated and all running code will halt, protecting you from the exploit. This secret value acts very much like the security cookie of Microsoft’s buffer overflow protection built into Windows with the introduction of the /GS (guard stack) compiler flag of Visual Studio 2005. This technology was incorporated into Windows XP Service Pack 2 in August 2004.

Conclusion
While these mitigations will make it harder for exploits to carry out their intended purpose, they won’t stop all exploits (I don’t mean this is in an offensive manner, no mitigation is perfect and these new mitigations were designed to make it harder not impossible for exploits occur).

In addition, it’s very likely that the exploit authors will begin to create exploits that avoid these mitigations either by working around them or using object types that don’t yet have these mitigations in place. However Google have pledged to continue improving the mitigations available as time goes on. It will be interesting to see the kinds of exploits/vulnerabilities emerging in the coming months.

Thank you.