Daily Archives: April 3, 2016

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.

Linux Routers Potentially Vulnerable To Telnet Worm

In late March ESET security published a blog post detailing how an updated version of an existing malware infection can exploit many consumer broadband routers and wireless access points.

Why Should This Infection Be Considered Important?
If your router becomes infected with this malware it can communicate back to its creator via a command and control (C2) server (defined). Under their control your router can be used for purposes such as a distributed denial of service attack (DDos) attack (defined) among any other action the attackers may choose. An example of a DDoS attack occurring in the past using routers is the subject of this article and this article.

Given that the malware comes to reside on a router by attempting to connect to random IP addresses (defined) that have port 23 open it may only be a matter of time before your router is tested for this open port.

By convention port 23 is used by the now deprecated Telnet (defined) protocol. If your routers firewall (defined) does not block access to this port from external sources the attackers have a favourable opportunity to infect your router since the malware can download various versions customized to the individual CPU architecture used within the router e.g. MIPS, ARM etc. The malware attempts to gain access to your router using a stored list of username and passwords that are commonly used or are used by default by consumer routers. Once access is obtained the malware is downloaded and installed.

How Can I Protect Myself from This Malware?
As discussed in a previous blog post, please follow the recommendations provided by the US-CERT to secure your router. This will involve (among other changes) changing the default username and password of the router (making it much harder for the malware to guess the correct credentials).

Blocking commonly used protocols from being used to access your router (which in this case is the Telnet protocol) using your firewall is explained here. Use of a tool (e.g. Steve Gibson’s ShieldsUP!) to test the effectiveness of your router’s firewall will also provide additional protection against this threat and other threats that may attempt to access your router is discussed here. A guide for using ShieldsUp to do this is here with a video demo here. Scanning your router using Nmap (a more advanced tool) is discussed in this article.

Since many Internet Service Providers (ISPs) block/prevent end-users/consumers from making many changes to their routers, please contact your ISP for advice on how to block port 23 from being accessed externally to protect against the threat discussed in ESET’s blog post.

Thank you.