Tag: Microsoft

UEFI Forum updates Secure Boot revocation database?

~ hucktech ~ Leave a comment

I wish I knew some more authoritative sources of news for this Microsoft Secure Boot story… 😦 The below post implies that the UEFI Forum’s Secure Boot recovation list file has been updated in response to recent news.

I REALLY wish the UEFI Forum would *announce* when they update their Secure Boot revocation list, and include version history to the changes, and keep older releases available for diffing against current one. It seems something this important should not be under public version control so you can see when keys come and go, and why. The current web page on this database should include information about the entries in the current database, and show changes and why. The page for this database should include end-user information for sysadmins to apply this to their systems, I see no real documentation on this page on how to properly use this database.
http://uefi.org/revocationlistfile

excerpt from https://blog.uncooperative.org/blog/2016/08/18/secure-boot-failures-and-mitigation/

[…] In response, UEFI is distributing an updated version of the Secure Boot revocation list, aka dbx. dbx is used to remove previously granted access from a UEFI driver or application, or from a signing certificate, declaring that signature invalid or signatures with the blacklisted certificate to be invalid. This update adds 64 new new individual signature entries into dbx, raising the total to 77.  […]

more on Microsoft UEFI Secure Boot golden key news

~ hucktech ~ Leave a comment

There are a few news stories coming out saying that the recent Microsoft Secure Boot stories are mostly false, pointing to a Steve Gibson video podcast.

If someone had some good technical background on this story, please leave a Comment to this post, thanks!

https://redmondmag.com/articles/2016/08/17/windows-secure-boot-slip-up.aspx

Kurt Mackie has a story in Redmond Magazine about the recent Microsoft Secure Boot news:

[…] There were no actual software keys involved when anonymous researchers claimed that Microsoft had leaked so-called “golden keys” to the Windows secure boot protection scheme, according to an industry veteran. That point of view was offered by Steve Gibson, president and founder of Gibson Research Corp., a small software development firm in Laguna Hills, Calif. “It was completely wrongly reported” by the press, Gibson said in a “Security Now” show yesterday. Gibson is cohost on the show, which is published by the Twit network. “It was nice work,” Gibson said about the researchers’ findings, “but the whole golden key was an absolute red herring referring to the notion of backdoor systems. But this wasn’t that. It was a mistake.” […] “What this actually was was an implementation design error in the handling of boot permission policies which can be used to trick older versions of the UEFI secure boot manager using some components of an update. So the so-called ‘Redstone’ version of Windows 10, which is version 1607, we know it as the ‘anniversary update,’ it added some new technology in the concept of supplemental secure boot policies, which can, for example, be used for test-signing development code. And of course, that could also be [used for running] malicious rootkits and so on.” […]

http://www.winbeta.org/news/microsofts-golden-key-agenda-actuality

Kareem Anderson of WinBeta has a similar story:

Microsoft’s ‘Golden key’ is more agenda than actuality “None of that is true. Complete misreporting.”

Microsoft removes Firewire from kernel debugger

~ hucktech ~ Leave a comment

The Windows kernel debugger needs to operate even when some device drivers fail, and for other reasons, the debugger can’t use the normal Windows drivers for remoting the debugger over serial, network, USB, Firewire (1394), so the debugger needs to write it’s own driver and do other hacks to remote itself. In the beginning, serial was the only requirement, but later faster cables were needed, like USB and 1394.

Well, it looks like Firewire is fading away, Microsoft has removed 1394 support from the mainstream release of the kernel debugger, only keeping it in the WDK build. Also, AFAIK, this is the first time the Windows debugger is being built separately like this.

https://blogs.msdn.microsoft.com/windbg/2016/08/11/kd-1394-work-around/

 

Microsoft UEFI Secure Boot key problem

~ hucktech ~ Leave a comment

Chris Williams has a story in The Register about some problems that Microsoft is having with UEFI Secure Boot:
Bungling Microsoft singlehandedly proves that golden backdoor keys are a terrible idea
Redmond races to revoke Secure Boot policy

Updated Microsoft leaked the golden keys that unlock Windows-powered tablets, phones and other devices sealed by Secure Boot – and is now scrambling to undo the blunder.

These skeleton keys can be used to install non-Redmond operating systems on locked-down computers. In other words, on devices that do not allow you to disable Secure Boot even if you have administrator rights – such as ARM-based Windows RT tablets – it is now possible to sidestep this block and run, say, GNU/Linux or Android. […]

http://www.theregister.co.uk/2016/08/10/microsoft_secure_boot_ms16_100/

Secure Boot and driver signing changes in latest Windows 10

~ hucktech ~ Leave a comment

Joshua Baxter of Microsoft posted a new article in the Windows hardware certification blog, about changes in Win10 driver signing:

Driver Signing changes in Windows 10, version 1607
Last year, we announced that beginning with the release of Windows 10, all new Windows 10 kernel mode drivers must be submitted to the Windows Hardware Developer Center Dashboard portal (Dev Portal) to be digitally signed by Microsoft. However, due to technical and ecosystem readiness issues, this was not enforced by Windows Code Integrity and remained only a policy statement. Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal. OS signing enforcement is only for new OS installations; systems upgraded from an earlier OS to Windows 10, version 1607 will not be affected by this change. We’re making these changes to help make Windows more secure. These changes limit the risk of an end-user system being compromised by malicious driver software. […]

More info, including a FAQ on how Secure Boot impacts this:

https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/

Microsoft on TPM Lockout

~ hucktech ~ Leave a comment

Rafal Sosnowski of Microsoft has a new blog post on TPM:

Hello everyone. It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today, I am going to talk about TPM Lockout state. TPM (Trusted Platform Module) is a small chip on the motherboard (discrete TPM) or part of the CPU implementation (firmware TPM) which can be used to securely store small amount of information (certificates, private keys, virtual smartcards, Bitlocker keys etc.). That data is completely isolated from HDD and partially from OS thus giving it maximum protection. To get access to that information from OS level user has to present some kind of authorization value. For example, Bitlocker PIN to get access to the Bitlocker Keys, Virtual smart-card PIN to get access to the certificates and private keys etc. However, TPM has special anti-hammering logic which prevents malicious user from guessing that authorization data indefinitely. Number of possible PIN failures varies across TPM specification: […]

Full post:
https://blogs.technet.microsoft.com/dubaisec/2016/07/10/tpm-lockout/

Microsoft MEX Windbg extension

~ hucktech ~ Leave a comment

Microsoft recently released a new Windows Windbg debugger extension called MEX. It has a variety of features, dozens of commands for many of Microsoft’s products. It appears to have been removed from the download site for a while, but it is up now, at least for the moment.

 

There’s a copy of the MEX help usage listed here:
https://github.com/REhints/WinDbg/tree/master/MEX

 

Intel Graphics Driver for Windows: EOP vulnerability

~ hucktech ~ Leave a comment

Intel has released a security advisory for Intel Graphics Drivers for Windows. Excerpted announcement:

Multiple Potential Vulnerabilities in the Intel® Graphics Driver for Microsoft Windows
Impact of vulnerability:      Elevation of Privilege
Severity rating:      Important

Multiple potential vulnerabilities exist in the Intel® Graphics Driver for Microsoft Windows impacting versions prior to 28MAR2016.  The vulnerabilities can lead to a privilege escalation or denial of service condition. Intel highly recommends that customers of the affected products obtain and apply the latest versions of the driver. Discovered by Piotr Bania of Cisco Talos

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00054&languageid=en-fr
https://downloadcenter.intel.com/product/80939/Graphics-Drivers
http://www.talosintelligence.com/reports/TALOS-2016-0087/

Microsoft SystemContainer

~ hucktech ~ Leave a comment

The Microsoft blog post even references CHIPSEC:

“[…] Based on this, it’s an exciting time for customers, Microsoft, and of course our partners, as we’re finally on a path to breaking through some of the biggest security challenges we’ve been facing. In the remainder of this blog, we’ll discuss the work we’re doing with industry partners like Intel and our OEM’s to build devices that are more secure at the hardware level, and then we’ll discuss how that hardware has enabled us to deliver a new security architecture for Windows that is going to put attackers in an extremely difficult position, and will prove exponentially more challenging for them to circumvent. […]”

https://blogs.technet.microsoft.com/windowsitpro/2016/06/29/step-change-in-security-with-modern-devices-and-architecture/

 

ASUS UEFI Update Driver Physical Memory Read/Write

~ hucktech ~ Leave a comment

“A short while ago, slipstream/RoL dropped an exploit for the ASUS memory mapping driver (ASMMAP/ASMMAP64) which was vulnerable to complete physical memory access (read/write) to unprivileged users, allowing for local privilege escalation and all sorts of other problems. An aside to this was that there were also IOCTLs available to perform direct I/O operations (in/out instructions) directly from unprivileged usermode, which had additional interesting impacts for messing with system firmware without triggering AV heuristics.
[…]
In addition to the ASMMAP bugs, I also reported the exact same bugs in their UEFI update driver (AsUpIO.sys). This driver is deployed as part of the usermode UEFI update toolset, and exposes almost identical functionality which (as slipstream/RoL pointed out) is likely from an NT3.1 example driver that was written long before Microsoft took steps to segregate malicious users from physical memory in any meaningful way.”
[…]

ASUS UEFI Update Driver Physical Memory Read/Write

https://www.exploit-db.com/exploits/39785/

a bit more on Intel CET

~ hucktech ~ Leave a comment

http://blogs.intel.com/evangelists/2016/06/09/intel-innovating-stop-cyber-attacks/

http://blogs.intel.com/evangelists/2016/06/09/intel-release-new-technology-specifications-protect-rop-attacks/

https://forums.grsecurity.net/viewtopic.php?f=7&t=4490

The GRSecurity post has a few more links as well:

[…]
Full disclosure: we have a competing production-ready solution to defend against code reuse attacks called RAP, see [R1], [R2]. RAP isn’t tied to any particular CPU architecture or operating system, and it scales to real-life software from Xen to Linux to Chromium with excellent performance.
[…]
Conclusion

In summary, Intel’s CET is mainly a hardware implementation of Microsoft’s weak CFI implementation with the addition of a shadow stack. Its use will require the presence of Intel processors that aren’t expected to be released for several years. Rather than truly innovating and advancing the state of the art in performance and security guarantees as RAP has, CET merely cements into hardware existing technology known and bypassed by academia and industry that is too weak to protect against the larger class of code reuse attacks. One can’t help but notice a striking similarity with Intel’s MPX, another software-dependent technology announced with great fanfare a few years ago that failed to live up to its many promises and never reached its intended adoption as the solution to end buffer overflow attacks and exists only as yet another bounds-checking based debugging technology.

Finnbarr on diagnosing Windows UEFI startup issues

~ hucktech ~ Leave a comment

Finnbarr has a new blog post, on diagnosing UEFI-centric issues with modern Windows systems, with lots of figures and screenshots and background information:

[…] I hope this detailed explanation of how Windows 10 boots on a UEFI-platform will help you keep your sanity the next time you boot and see a missing or corrupt BCD message. Remember to always configure your platform so that you can boot into a UEFI shell using the UEFI firmware-based boot manager and make a backup of your BCD store.

http://blog.fpmurphy.com/2016/06/uefi-based-windows-10-platform-failure-to-boot-due-to-bcd-error.html

Intel updates Firmware Engine

~ hucktech ~ Leave a comment

https://twitter.com/FirmwareEngine/status/735564887267500032

Intel® Firmware Engine Release 2.0.0
Program installer for Microsoft* Windows 7/8/8.1/10.
Includes program and MinnowBoard Max and MinnowBoard Turbot platform support.

https://firmware.intel.com/learn/intel-firmware-engine/downloads

<soapbox>
Intel: please port Firmware Engine to Linux (and FreeBSD, which also has UEFI support), the current Windows-only release only helps Windows subset of your target firmware vendor ecosystem. Thanks!
</soapbox>

Microsoft and Secure Boot

~ hucktech ~ Leave a comment

A few document updates from Microsoft on Secure Boot and one news article on Windows hardware requirements:

Justin Hall of Microsoft has updated their document on how to disable Secure Boot:

https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/disabling-secure-boot

Justin has also updated their guidance on Secure Boot keys:

https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance

Milad Aslaner of Microsoft has updated their document on how to access UEFI security features in their Surface devices:

https://technet.microsoft.com/en-us/itpro/surface/advanced-uefi-security-features-for-surface

The Windows driver doc team has updated their document on Booting and UEFI:

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/boot-and-uefi

Extreme Tech has a story on Windows hardware requirements increasing:

http://www.extremetech.com/computing/229101-new-windows-10-update-will-change-hardware-requirements-for-the-first-time-since-2009

It mentions that Windows 10 Mobile OEMs must not disable Secure Boot. I have not been following Microsoft’s changes to Secure Boot guidance too closely, this might be a change.

 

HackBGRT: changes Windows boot logo on UEFI systems

~ hucktech ~ 4 Comments

Metabolix has written HackBGRT, a tool that changes the Windows boot logo on UEFI systems. It works on Intel 64-bit UEFI systems, with Secure Boot disabled.

“HackBGRT is intended as a boot logo changer for UEFI-based Windows systems. When booting on a UEFI-based computer, Windows may show a vendor-defined logo which is stored on the UEFI firmware in a section called Boot Graphics Resource Table (BGRT). It’s usually very difficult to change the image permamently, but a custom UEFI application may be used to overwrite it during the boot. HackBGRT does exactly that. Important: If you mess up the installation, your system may become unbootable! Create a rescue disk before use. This software comes with no warranty. Use at your own risk.” […]

https://github.com/Metabolix/HackBGRT

Microsoft’s new Security Auditing and Monitoring Reference

~ hucktech ~ Leave a comment

Microsoft has published a new  guide on Windows’ security events. It’s a 700+ page doc!

Windows 10 Security Auditing and Monitoring Reference V1

You can record and store security audit events for Windows 10 to track key system and network activities, monitor potentially harmful behaviors, and mitigate risks. You control the amount of data you collect by controlling the categories of security events you audit, for example, changes to user account and resource permissions, failed attempts to access resources, and attempts to modify system files. The reference in this download can help you decide what to monitor and how to interpret the data you collect.

https://www.microsoft.com/en-us/download/details.aspx?id=52630

 

 

UEFI Secure Boot exploit for Windows Surface??

~ hucktech ~ Leave a comment

A kind reader of this blog pointed this out to me:

It appears that Longhorn has a UEFI exploit, related to Windows surface devices. I’m not sure yet if it requires ARM or Intel system, and I don’t know the details of the exploit, it appears that it has not been released.

https://twitter.com/never_released/status/723144680507117568
https://twitter.com/never_released/status/723146681940738055
https://twitter.com/never_released/status/724506763240833025
https://twitter.com/never_released/status/725355698431905793
https://twitter.com/never_released/status/725355698431905793
https://twitter.com/never_released/status/725034729599307777
https://twitter.com/never_released/status/724984950584446976
https://twitter.com/never_released/status/724506763240833025
https://twitter.com/never_released/status/723896207475675136
https://twitter.com/never_released/status/723796480281182208