Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label Kernel Hacks. Show all posts

Unprotected Access to Windows' Centre: Signed Kernel Drivers

 

ESET researchers investigated the misuse of vulnerable kernel drivers in depth saying "Software" drivers are among the different types of kernel drivers that provide particular, non-hardware-related capabilities such as software debugging and diagnostics, as well as system analysis. These have the potential to greatly increase the attack surface. 

Although it is no longer possible to directly load a malicious, unsigned driver in current versions of Windows, and kernel rootkits are deemed obsolete, there are still ways to load malicious code into the kernel, particularly through manipulating legal, signed drivers. There are many drivers available from a variety of hardware and software suppliers that allow you to completely access the kernel with minimal effort. 

The most common vulnerabilities detected in-kernel drivers:
  • Checks that restrict read and write access to critical model-specific registers are disabled (MSRs). 
  • Exposing the ability to read and write from physical memory in user mode. 
  • The ability to read and write to virtual kernel memory from user mode is now enabled. 

"When malware actors need to run malicious code in the Windows kernel on x64 systems with driver signature enforcement in place, carrying a vulnerable signed kernel driver seems to be a viable option for doing so," says Peter Kálnai, Senior Malware Researcher at ESET and one of the report's co-investigators. 

Bring Your Own Vulnerable Driver, or BYOVD, is a technique that has been observed in the wild by both high-profile APT actors and commodity malware, such as the RobbinHood ransomware, which, as commodity malware, aims to reach as many people as possible. As a result, seeing it use a BYOVD approach is uncommon but significant. 


Mitigation strategies that work :
  • Virtualization-based security is a Windows 10 feature that uses hardware virtualization to place the kernel in a sandbox, safeguarding the operating system with various protections.
  • Drivers in recent Windows systems have a valid signature based on an "acceptable" certificate, which can be revoked. Revocation of a vulnerable driver's certificate would be a simple approach to "disarm" it and render it useless. 
  • When the most notoriously susceptible drivers are detected on a system, Microsoft and numerous third-party security product suppliers, including ESET, use driver blocklisting to detect and eliminate them. 
Vulnerable drivers have been exploited by both game cheaters and malware producers, and while significant progress has been made to reduce the impacts, the fight continues. The people responsible for the problem want to remedy it — the vendors who were contacted were quite proactive during the disclosure process, eager to repair the flaws that were discovered. 

Microsoft released temporary fix for Kernel 0-day Security Flaw


Few days back, Symantec and the Laboratory of Cryptography and System Security (CrySyS) discovered the zero day security flaw in windows kernel while analyzing the Duqu malware.  Microsoft released a temporary fix this problem.  Microsoft determine the problem is in the Win32k TrueType font(TTF) parsing engine.

An attacker can exploit this vulnerability and install programs; view, change, or delete data; or create new accounts with full user rights.

Microsoft is working on to fix this vulnerability with partners in Microsoft Active Protections Program (MAPP). In mean time, Microsoft released "Fix this problem" tool as a temporary solution.

This tool will disable the system access to the T2embed.dll file. The problem with that is it will prevent any applications that rely on embedded TTFs from rendering properly. This is a common practice in Microsoft Office documents, browsers and document viewers.

Security breach on kernel.org

Security Breach occurred on Kernel.org. This is news from their official Website:

Earlier this month, a number of servers in the kernel.org infrastructure were compromised. We discovered this August 28th. While we currently believe that the source code repositories were unaffected, we are in the process of verifying this and taking steps to enhance security across the kernel.org infrastructure.


What happened?


  •  Intruders gained root access on the server Hera. We believe they may have gained this access via a compromised user credential; how they managed to exploit that to root access is currently unknown and is being investigated.
  •  Files belonging to ssh (openssh, openssh-server and openssh-clients) were modified and running live.
  • A trojan startup file was added to the system start up scripts
  •  User interactions were logged, as well as some exploit code. We have retained this for now.
  •  Trojan initially discovered due to the Xnest /dev/mem error message w/o Xnest installed; have been seen on other systems. It is unclear if systems that exhibit this message are susceptible, compromised or not. If developers see this, and you don't have Xnest installed, please investigate.
  •  It *appears* that 3.1-rc2 might have blocked the exploit injector, we don't know if this is intentional or a side affect of another bugfix or change.


What Has Been Done so far:

  •  We have currently taken boxes off line to do a backup and are in the process of doing complete reinstalls.
  •  We have notified authorities in the United States and in Europe to assist with the investigation
  •  We will be doing a full reinstall on all boxes on kernel.org
  •  We are in the process of doing an analysis on the code within git, and the tarballs to confirm that nothing has been modified

The Linux community and kernel.org take the security of the kernel.org domain extremely seriously, and are pursuing all avenues to investigate this attack and prevent future ones.


However, it's also useful to note that the potential damage of cracking kernel.org is far less than typical software repositories. That's because kernel development takes place using the git distributed revision control system, designed by Linus Torvalds. For each of the nearly 40,000 files in the Linux kernel, a cryptographically secure SHA-1 hash is calculated to uniquely define the exact contents of that file. Git is designed so that the name of each version of the kernel depends upon the complete development history leading up to that version. Once it is published, it is not possible to change the old versions without it being noticed.


Those files and the corresponding hashes exist not just on the kernel.org machine and its mirrors, but on the hard drives of each several thousand kernel developers, distribution maintainers, and other users of kernel.org. Any tampering with any file in the kernel.org repository would immediately be noticed by each developer as they updated their personal repository, which most do daily.


We are currently working with the 448 users of kernel.org to change their credentials and change their SSH keys.


We are also currently auditing all security policies to make kernel.org more secure, but are confident that our systems, specifically git, have excellent design to prevent real damage from these types of attacks.

Source: Kernel