Tag Archives: security mitigations

Microsoft Releases EMET 5.5

====================
Update: 11th July 2017:
As noted in a new blog post, an upcoming update to Windows 10 will contain some features of EMET. Further details are available in the above mentioned blog post.

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

====================
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.

Linux Foundation Issues Security Checklist for Sys Admins

The Linux Foundation recently made available a set of best security practices specifically aimed at Linux system administrators to assist them with protecting the systems they are responsible for from compromise.

The advice is divided into 4 severity levels categories: low, moderate, critical, and paranoid. The list of recommendations should help you better defend any Linux systems that you administer in your corporate environment and can be used to supplement your existing defences/procedures.

I hope that you find this list useful. The checklist can be viewed here. Further advice on hardening Linux workstations is provided at the end of a previous blog post

Thank you.

Windows 10 Will Offer Increased Security (updated)

On the 29th of July 2015, the next version of Windows from Microsoft, Windows 10 will become available to the general public (with Windows 10 Enterprise for corporate customers becoming available in the Fall of 2015). Windows 10 will offer new features such as DirectX 12, virtual desktops and an improved Start menu among others. However I wish to focus on the security improvements that we can look forward to seeing in the upcoming release:

Microsoft Edge
As mentioned in my post discussing the bug bounty for Microsoft Edge (Microsoft’s new browser), it will feature security changes such as the removal of now obsolete technologies such as VBScript, ActiceX, toolbars, Browser Helper Objects (BHOs) and VML which will mean that less code is present to attack. The less code there is, the less scope there is to exploit it (i.e. its attack surface has been reduced).

Microsoft Edge will offer more convenient and more secure ways (Windows Hello and Microsoft Passport) to authenticate to websites (assuming that popular websites adopt this new approach of authentication). I’m really excited about these features since it will mean fewer passwords to manage and also means that if the website is hacked, your password hash can’t be stolen since the website doesn’t store a password hash. Updating high risk and/or frequently passwords is a chore and these new authentication methods will mean this chore will slowly begin to be a thing of the past.

In addition, for the first time Edge will offer support for both Content Security Policy (CSP) (appears to be CSP Level 1 i.e. v1.0 rather than Level 2 i.e. v2.0) and HTTP Strict Transport Security (HSTS).

What is Content Security Policy (CSP)?
Content Security Policy (CSP) is a W3C standard that allows a website owner to specify the sources of trusted content used to build/display a page e.g. scripts (JavaScript), embedded videos (CSP Level 2 only), audio, fonts, forms (CSP Level 2 only) and plugins (CSP Level 2 only) as well as other object types. Since this content can only load from a website address that you specify (since inline JavaScript is ignored), if the websites’ content has been altered and additional content inserted by an attacker (usually JavaScript), it won’t be able to load since the content will come from a source that you have not approved (not whitelisted). This helps to protect against cross-site scripting (XSS) attacks.

The differences between CSP Levels 1 and 2 are detailed in this W3C document. Unfortunately not many websites at this time use CSP to protect their users. Twitter, Facebook and Google Gmail are known to being CSP. Smaller sites such as SendSafely also make use of it.

What is HTTP Strict Transport Security (HSTS)?
HSTS allows your web browser (e.g. Mozilla Firefox, Google Chrome etc.) to only access a web site using a secure connection (HTTPS, which will display a padlock in your browser address bar) and to never attempt to access that website using an unsecured connection namely HTTP. One of the other benefits of HSTS (a more comprehensive list is available in the paragraph titled “Threats” within this page) is that HSTS does not allow a user to override an invalid certificate message (otherwise known as a HTTPS click through). Thus if there is an issue with the certificate being used to verify the identity of the website, you can’t click “Continue anyway” (whether there is genuinely a malicious issue with the site or its certificate has simply expired) and thus any risk is eliminated. An example of a pop up window showing such a click through message is shown in the section “Why click-throughs are so dangerous” within this Microsoft MSDN blog post.

Support for HSTS was added to Internet Explorer 11 for Windows 8.1 and Windows 7 by Microsoft when the June 2015 security update is installed. Further information is available in this blog post and this knowledge base article.

Why are these 2 security features noteworthy? As more legitimate websites become to be hacked and extra content added to them, having CSP should stop those attackers compromising your device when accessing the now hacked site. In addition, when something is wrong with the certificate used to verify a websites identity its best not to conduct sensitive transactions with it during that time, while the certificate may simply be expired, there may also be a malicious reason why you are seeing that message and this is where HSTS can protect you.

Other Security Enhancements of Microsoft Edge
Microsoft Edge will also include a Memory Garbage Collector (MemGC) to defend it against Use-After-Free security flaws (where the browser marks memory that it has finished using as free but then tries to use it again (either unintentionally via a software bug resulting from human error or maliciously via a piece of malware). I previously mentioned these flaws in this blog post where a group of security researchers were rewarded due to providing additional defences against them. This is excellent news since these flaws are now very popular with malware authors.

The final noteworthy mitigation is Control Flow Guard (CFG) which seeks to prevent an attacker obtaining control of the browser by manipulating the program counter of your CPU (Central Processing Unit). The program counter is a register within your CPU which always holds the memory location of the next instruction to be executed. I previously discussed how this mitigation has been bypassed before but the attacker’s code would need to know how to bypass this mitigation and thus this defensive measure still has value.

The decision that Microsoft Edge should always be a 64 bit program running on your computing device (as opposed to a 32 bit program) is significant since the mitigation known as ASLR (Address Space Layout Randomization) becomes far more effective with a 64 bit process. When used with a 64 bit process, it’s known as High Entropy (HE) (i.e. highly random) ASLR. HEASLR is discussed in more detail in this post and this post. It’s advantages include making heap spraying techniques far less effective. Further information on HEASLR can be found on Alex Ionescu’s blog.

I very much approve of this choice to make Edge 64 bit by default since I was very surprised to learn just how many users still use Internet Explorer 32 bit on a 64 bit version of Windows. This forum thread shows how many users were affected by an issue that only occurred if they were using a 32 bit version of Internet Explorer. While a 64 bit version of Internet Explorer has been available since the release of Windows Vista in January 2007, 32 bit versions are still very widely used. I’ve done some quick checks and can confirm that opening Internet Explorer 8 on a newly installed Windows 7 64 bit system will by default launch a 32 bit version (unless Enhanced Protected Mode (EPM) is enabled (which was only introduced to Windows 7 with Internet Explorer 10)). A newly installed Windows 8.1 64 bit system also showed the same behaviour (opening a 32 bit version of Internet Explorer 11). Only the Modern UI (Windows Store) app otherwise known as the Immersive Internet Explorer of Windows 8.1 was a 64 bit process.

While Microsoft mentions that Edge is 64 bit only when running on a 64 bit processor, for 32 bit versions of Windows 10 as expected it remains a 32 bit browser. Please find below screenshots from Sysinternals Process Explorer showing Microsoft Edge on Windows 10 32 bit and Windows 10 64 bit:

Edge 32 bit:
Edge_32bit

Edge 64 bit:
Edge_64bit

Please note the CPU architecture of the Edge process is not shown in the Windows 10 32 bit screenshot (this option is not available on a 32 bit system since only 32 bit programs can run). However the type of process can be confirmed from looking at the VirusTotal results for Spartan.exe. The Intel 386 architecture mentioned is 32 bit:

VirusTotal_Edge_32bit

An older blog post discussed a 64 bit version of Internet Explorer and detailing why it was not at the time made the default version. EPM is explained in more detail here and here. 64 bit versions of Internet Explorer are more secure since:

  • They have EPM enabled
  • All 64 bit processes (not just Internet Explorer) have Data Execution Prevention (DEP) enabled all the time since it’s not optional for 64 bit processes
  • All 64 bit processes (not just Internet Explorer) can (if they choose to/opt-in) use HEASLR (making heap spray attacks less effective, as mentioned above)
  • Are more resistant to shellcode exploits since the shellcode must be 64 bit and not 32 bit. 64 bit shellcode is less common.
  • Only 64 bit DLLs can be loaded into a 64 bit version of Internet Explorer. This can increase stability since fewer (if any) add-ons will be loaded when Internet Explorer starts and this helps to reduce the attack surface (since those add-ons aren’t loaded they can’t be targeted). EPM further reduces the likelihood that a 64 bit DLL will be loaded since add-ons not compatible with EPM are not loaded.
  • In addition Google mentioned the advantages they saw when they made 64 bit versions of Chrome available (the speed advantage mentioned may or may not apply to Internet Explorer in this case).

Windows Device Guard
This security feature is an evolution of Windows AppLocker (a feature which I mentioned is useful for protecting against ransomware in a corporate environment) that checks that an app is trusted before allowing it to run (be used) on your computing device. Device Guard is intended for devices used within mission critical settings such as a hospital, a factory assembly line, a power plant, an air traffic control tower, a PoS (Point of Sale terminal e.g. a cash register) terminal or an ATM.

Device Guard checks that the app is signed (verified as trustworthy) from one of the following sources:

  • By a known and trusted software vendor
  • From the Windows Store (Microsoft’s online app store)
  • Your company (if the original software vendor did not sign it) for line of business applications that you use

This new feature is particularly effective against APTs (Advanced Persistent Threats) since in a similar manner to AppLocker an APT would not be trusted and would not be allowed to run. This is so effective since Device Guard (again similar to AppLocker) does not rely on receiving updates to detect known threats in the same way that anti-malware software does. It works simply by determining if you have allowed this program, if not it will block it.

What Advantages Does Device Guard Have Over AppLocker (or other whitelisting solutions)?
Even if a system has been fully compromised (where the attacker has already obtained administrative access), Device Guard can block malware by using hardware virtualization to isolate the decision to block/allow from Windows even if the Windows kernel is fully compromised. This isolated mode which makes use of the Local Security Authority (LSA) to protect against Pass the Hash (PtH) attacks.

However Device Guard will not be able to protect against apps that use Just-In-Time (JIT) code compilation such as Java, .Net or macros embedded in Microsoft Office documents but using existing anti-malware software and having a Windows device user use a standard user account rather than an administrative account will provide the necessary protection.

Finally, Device Guard should be easier to administer/maintain since AppLocker requires that unsigned executable (runnable) files (that you trust) be approved by whitelisting their file hash. Since Device Guard relies solely on an application being signed, this extra task will be eliminated. The only flaw that I can see with Device Guard is that it may be open to attacks on digital signatures whereby a signing certificate can be stolen and used to sign malware, noteworthy examples involving Adobe, Microsoft, Opera and Realtek/JMicron have taken place.

It’s not clear how prevalent the use of Device Guard will be in a corporate environment (it won’t be present in consumer versions since according to this post Device Guard is available for Windows 10 Enterprise edition only). Most existing Windows 8 devices will support the use of Device Guard; provided they are recent enough to have UEFI firmware and their CPUs support AMD-Vi or Intel VT-d. The full requirements of Device Guard are listed here.

Update: 5th July 2015:
Windows 10 Additional Security Features: PowerShell Script Logging Capabilities
In addition to the improvements discussed above, Windows 10 will offer additional security for PowerShell scripts that are executed (allowed to run) on a Windows 10 system (and on Windows 8.1/Server 2012 R2 systems with update kb3000850 installed).

If a Windows 10 system is compromised it will offer much more detailed logging that can be used to determine how much the system was compromised and what changes were made. Moreover, even if obfuscated (garbled scripts (used to make detection of such scripts more difficult) that must be un-garbled before being allowed to run) are used by the attacker, such scripts must eventually be deciphered in order for the system to carry out the malicious commands, thus Windows 10 will be able to show you what these obfuscated have done to your system, this was not previously possible. The above improvements will allow incident responders to determine what data was compromised (if such scripts were used to steal data) and what remediation’s to take to revert the system back to a secure state.

Furthermore there are occasions when the logging of such PowerShell scripts may also inadvertently capture sensitive information. Windows 10 provides the capability for applications to encrypt their sensitive information before it is added to the logs. This encryption can later be removed while reviewing the logs to ensure that crucial data is still legible.

The above capabilities are discussed in more detail in this Microsoft SRD blog post.

One additional capability that PowerShell will feature will be to address a previous limitation of using Windows AppLocker in Allow Mode (namely that only recognised/trusted applications are allowed to run also known as application whitelisting). This limitation was that while any unrecognized/unauthorized PowerShell script (within a file) would be blocked by AppLocker, if such a script was entered manually (e.g. using the keyboard) within a PowerShell prompt (similar to a terminal window), this interactively created script would run. The Constrained PowerShell feature of PowerShell v5 available with Windows 10 will block this interactive means of running a PowerShell when AppLocker is enabled in the more restrictive Allow mode that will address this previous weakness. Further information on this feature is available in this Microsoft PowerShell blog post.

A new feature debuting in Windows 10 will be the Antimalware Scan Interface (AMSI) which can be integrated with an anti-malware application to allow the evaluation of any script (PowerShell, VBScript among others) once that script has been de-obfuscated and is ready to carry out its intended purpose. This will also protect against code/scripts that only ever exist in memory (are never written to disk within a file). Windows 10 will automatically benefit from this feature since its scripting engines will use the AMSI feature by default. This feature can also be used by application developers (when that application wishes to use scripts for automation purposes) as well as 3rd party anti-malware vendors.

It’s amazing to see these capabilities being added to thwart more advanced means of compromising systems that make use of in-memory scripts that are obfuscated to avoid detection by standard anti-malware signatures. The addition of the Constrained PowerShell feature also addresses a key weakness in previous implementations of this robust application white-listing feature.

In conclusion, Windows 10 will bring a range of technologies that will help to ensure our device’s remain secure even as advanced persistent threats (APTs) and insider threats become more commonplace. If you have any questions about this blog post or any of my other posts, please feel free to contact me.

Thank you.

===========================
Please find below further references for Content Security Policy (CSP), HTTP Strict Transport Security (HSTS) and Data Execution Prevention (DEP) which were discussed above:

References:
Content Security Policy (CSP):
An Introduction to Content Security Policy
Content Security Policy (CSP)
Reject the Unexpected – Content Security Policy in Gmail
Content Security Policy
Time to Review/Implement Content Security Policy v1.0
Improving Browser Security with CSP

HTTP Strict Transport Security (HSTS):
HTTP Strict Transport Security comes to Internet Explorer
HTTP Strict Transport Security (Mozilla)
HTTP Strict Transport Security (OWASP)
HTTP Strict Transport Security (Entrust)
How to enable HTTP Strict Transport Security (HSTS) in IIS7+
Firefox joins Chrome in supporting HTTP Strict Transport Security (HSTS)

Data Execution Prevention (DEP):
Understanding DEP as a mitigation technology part 1
Understanding DEP as a mitigation technology part 2

Siemens Updates Simatic Products Against “Ghost” (glibc) Security Flaw

Earlier this week security updates were made available by Siemens for its Simatic products (Industrial Data Network Controllers) to resolve an issue in the GNU C library that was reported in January this year. Updates were already available for its Ruggedcom (industrial routers) and its SINUMERIK controllers in March. These products are deployed in industrial sectors to provide data networking capabilities within large production lines and processing facilities e.g. water treatment.

Please follow the instructions within the ICS CERT security advisory to update any affected industrial Siemens products that you may be using.

Background on the Ghost Flaw

In January of this year a buffer overflow affecting the gethostbyname() and gethostbyname2() functions within the GNU C library was discovered by security researchers at Qualys. Both functions are considered deprecated since a newer function getaddrinfo() replaces them. This is a denial of service flaw (in the context of the above mentioned industrial networking components) but there is a possibility of remote code execution.

This flaw was caused by an efficiency improvement within the gethostbyname(). If this function receives an IP address, it will not have to resolve a hostname to an IP address for you (by using a DNS lookup) since the parameter passed is already an IP address. However this code does not check the length of the IP address passed to it as a parameter and this causes the buffer overflow. Please note that the parameter being passed to this function would need to be specifically chosen to crash the code in a way that allows remote code execution for that specific software and hardware platform. Thus such attacks would need to more targeted and would not be trivial to exploit.

Updates to resolve this flaw were released in January by Red Hat, SUSE Linux, Ubuntu and Debian (among others). If you have not already done so, please apply any security updates to your Linux systems and restart those systems for the updates to take effect.

Update: 29th May 2015:
Further defence in-depth advice concerning how to defend a Linux system from attack is provided in this blog post.

Update: 7th September 2015: In addition, as mentioned in this more recent blog post, the Linux Foundation has published a security checklist (intended for Linux system administrators) to harden Linux systems against attack.

Thank you.