Tag Archives: Mitigations

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.

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