OSR on Windows IoT on Rasberry PI 3

Peter at OSR has a new blog post about using Embedded Windows — now called Windows IoT — on a Rasberry PI3, with a lot of advice for embedded Windows developer using this beta platform.

[…] You can’t connect WinDbg to the RPI 3 via the network.  You have to use the serial port.  To be successful in this endeavor, you’ll need a super-secret TTL to USB Serial Port cable (this one from Adafruit works just dandy).  […]

Secrets of Using Win10 IoT Core on the RPI 3 (and staying sane)

If you do Windows, and have not looked at OSR’s online resources, it is worth a look, they have some tools that beat SysInternals, and the NTDev mailing list is probably the best public source of NT experienced developers, and one of the few places outside MSDN blogs that Microsoft developers publicly post technically useful information:
http://www.osronline.com/section.cfm?section=27
http://www.osronline.com/cf.cfm?PageURL=showlists.cfm?list=NTDEV

Kansa: incident response framework for Windows Powershell

I saw one of the speakers of Kansa recently, speaking about their project. Bryan tweeted about that talk:

[…] Kansa is a modular incident response framework in Powershell. It uses Powershell Remoting to run user contributed, ahem, user contributed modules across hosts in an enterprise to collect data for use during incident response, breach hunts, or for building an environmental baseline. […]

Kansa kindof reminds me of a Windows-centric, PowerShell-centric version of OSquery. 🙂 It runs a remote powershell with various scripts on all the remote systems, and gathers the data into CSVs for analysis. It has multiple plugins. IMO, it needs many new firmware-related plugins (eg, one for the x-UEFI Configuration Database, etc.).

More info:
https://github.com/davehull/Kansa
http://trustedsignal.blogspot.com/search/label/Kansa
http://www.powershellmagazine.com/2014/07/18/kansa-a-powershell-based-incident-response-framework/

LibEnclave: create Intel SGX secure enclaves in Rust

Jethro Beekman has released libenclave, a Rust-based tool for Intel SGX’s SDK for Windows:

This guide will get you started building SGX secure enclaves in Rust using libenclave and sgxs-tools. […]

https://github.com/jethrogb/sgx-utils
https://github.com/jethrogb/sgx-utils/blob/master/doc/GUIDE.md

new Microsoft ACPI table: WSMT

As mentioned earlier this week, Microsoft just released a spec for their new ACPI table WSMT (Windows SMM Security Mitigations Table):

Windows SMM Security Mitigations Table

The Windows SMM Security Mitigations Table specification contains details of an ACPI table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features. This information applies for Windows Server Technical Preview 2016, and Windows 10, version 1607. […]

Full spec:
http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx

The UEFI Forum maintains ACPI specs. AFAICT, their ACPI spec list does not yet list this new WSMT table.
http://www.uefi.org/acpi

Also, there’s a strange copyright in this spec:

Portions of this software may be based on NCSA Mosaic. NCSA Mosaic was developed by the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. Distributed under a licensing agreement with Spyglass, Inc.

Maybe I am just noticing this paragraph, and Microsoft always uses that on copyright pages, and does not mention other old software, only NCSA Mosaic. But why NCSA Mosaic-centric copyrights in an WSMT ACPI table?? Microsoft IE 1.0 was based on NCSA Mosaic source code, via Spyglass purchase, but that was long before EFI or ACPI. I didn’t notice anything Win9x/BIOS/ISA-PNP-centric about WSMT. :-).

In related news, Jiewen Yao of Intel has submitted the WSMT definition into the tianocore EDK-II project:

MdePkg: Add WSMT definition. This patch adds Windows SMM Security Mitigation Table @ http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx

 …/WindowsSmmSecurityMitigationTable.h            | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)

+#define EFI_ACPI_WINDOWS_SMM_SECURITY_MITIGATION_TABLE_SIGNATURE  SIGNATURE_32(‘W’, ‘S’, ‘M’, ‘T’)

Jiewen also submitted a 12-part patch, enhancing SMM to deal with this new table:

[PATCH 00/12] Enhance SMM Communication by using fixed comm buffer. This series patches are generate to meet Microsoft WSMT table definition on FIXED_COMM_BUFFERS requirement. Before this series patches, the DXE or OS module can use any non-SMM memory as communication buffer to exchange data with SMM agent. Microsoft WSMT table has requirement to support fixed communication buffer – so that SMM agent can only support communication buffer with type EfiReservedMemoryType/EfiRuntimeServicesCode/EfiRuntimeServicesData/EfiACPIMemoryNVS, which will not be used by OS during runtime. So we clean up all SMM handler to only use these memory regions for SMM communication, and enhance check in SmmMemLib to catch the violation. This series patches are validated on real platforms with SMM enabled. This series patches are validated on OVMF ia32-x64 with SMM enabled.

For full patch, see list archives:
https://lists.01.org/mailman/listinfo/edk2-devel

WinFlashROM: moving hosts

Darmawan Salihun has posted a new blog about WinFlashROM, a Windows port of FlashROM he did, and is moving it from Google Code to Github:

“This is old news because the code haven’t been updated for years. However, it might still relevant for those who want to port flashrom or other similar utility to present day Windows. I haven’t developed Windows driver anymore since Windows Server 2003. I’m not even sure if WDM-style driver is still in use in Windows. But, I might be returning to develop Windows driver this year. So, yeah, you (and I) never know.”

More information:
https://github.com/pinczakko/winflashrom
http://bioshacking.blogspot.co.id/2016/04/moving-winflashrom-code-to-github.html

(I haven’t looked into this, but I wonder if the CHIPSEC HAL for Windows (and Linux) might be useful in such a port. At least the kernel driver is maintained by Intel….)

Intel Ethernet diagnostics driver for Windows vulnerable

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00051&languageid=en-fr

Potential vulnerability in the Intel® Ethernet diagnostics driver for Windows®
Intel ID:      INTEL-SA-00051
Product family:      Intel® Ethernet diagnostics driver for Windows®
Impact of vulnerability:      Denial of Service
Severity rating:      Important
Original release:      Apr 11, 2016
CVE Name:  CVE-2015-2291

A vulnerability was identified in the Intel diagnostics driver IQVW32.sys and IQVW64.sys, also identified as CVE-2015-2291. Intel released an update to mitigate this issue in June 2015. Intel highly recommends that customers of the affected products obtain and apply the updated versions of the driver.

https://downloadcenter.intel.com/download/22283/Intel-Ethernet-Adapters-Connections-CD
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00051&languageid=en-fr

ByoSoft supports Intel Firmware Engine

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

Intel Developer Forum (IDF) takes place in San Francisco and also in China, and the one in ShenZhen is in the news now. Nanjing Byosoft Co., Ltd — aka Byosoft, a UEFI firmware vendor, announced that their ByoCore(TM) BIOS will fully support Intel Firmware Engine:

“Byosoft is the first vendor announce to fully support Intel® Firmware Engine among the independent firmware vendors in the industry, and the Intel® Firmware Engine technology will offer a low-cost, high-flexibility, easy-to-use service solution to Byosoft’s customers in Internet of Thing (IoT) and embedded market.”
 
“Byosoft believe Intel® Firmware Engine can greatly help customer to use ByoCoreTM BIOS and finish the customization, especially for those who don’t purchase source code of the ByoCoreTM. Intel® Firmware Engine offers flexible method of firmware customization based on binary, and without involving Byosoft engineer direct support, the customer can finish the firmware modification by themselves to create the required image.”

“Byosoft has co-worked with Intel and upgraded the ByoCoreTM BIOS codebase to support Intel® Firmware Engine. ByoCoreTM customer can fast customize ByoCoreTM firmware through Intel® Firmware Engine, configuring, adding or removing the existed firmware packages, and integrate user-defined payload. With Intel® Firmware Engine, ByoCoreTM customer can build customized firmware faster and easier.”

Full announcement:
http://www.byosoft.com.cn/xwzxx/98.htm

This is great news for the Windows UEFI ecosystem. Again, I wish Intel would release a Linux version of the Windows-only Firmware Engine. 😦

SimpleVisor: new hypervisor for Intel x64 Windows

https://twitter.com/aionescu/status/710477975288827904

Alex Ionescu has released a new hypervisor for Windows:

SimpleVisor is a simple, Intel x64 Windows-specific hypervisor with two specific goals: using the least amount of assembly code (10 lines), and having the smallest amount of VMX-related code to support dynamic hyperjacking and unhyperjacking (that is, virtualizing the host state from within the host).

http://ionescu007.github.io/SimpleVisor/

Windows 10 Secure Boot information

Yung Chou has a blog post on Windows 10’s implementation of UEFI Secure Boot:

An Introduction of UEFI Secure Boot in Windows 10 Enterprise

As a firmware interface standard to replace BIOS (Basic Input/Output System), UEFI (Unified Extensible Firmware Interface) specification has been a collective effort by UEFI Forum members for a while. UEFI is in essence an abstraction layer between firmware and OS, and independent of device hardware and architecture. Which provides flexibility for supporting multiple and various OS environments and as well acts as a generic target boot environment of drivers for cross-platform compatibility, as opposed to the need to develop a particular driver for particular hardware. With UEFI, there are also security opportunities to better defend a class of malware like bootkit and rootkit targeting the pre-boot environment of a device. […]

An Introduction of UEFI Secure Boot and Disk Partitions in Windows 10

Windows Device Guard information

Ash de Zylva of Microsoft has a blog post on Windows 10’s Device Guard and Credential Guard:
Windows 10 Device Guard and Credential Guard Demystified
While helping Windows Enterprise customers deploy and realize the benefits of Windows 10, I’ve observed there’s still a lot of confusion regarding the security features of the operating system. This is a shame since some of the key benefits of Windows 10 involve these deep security features. This post serves to detail the Device Guard and Credential Guard feature sets, and their relationship to each other. […]
http://blogs.technet.com/b/ash/archive/2016/03/02/windows-10-device-guard-and-credential-guard-demystified.aspx

 

Windows UEFI development course

WinInsider — probably via Alex Ionescu — has a UEFI development course available.  Alex is the author of VisualUEFI, which hides the non-Visual Studio’isms of EDK-II development. Alex, along with others at Wininternals, is also one of the current authors of the “Windows Internals”  book from Microsoft Press, now a 2-volume 6th edition set, originally called “Inside Windows NT”, written by Helen Custer.

Windows UEFI Development (3 Days or 5 Days)

In this course, one can expect to learn the internals of the Unified Extensible Firmware Interface inside and out, from the high-level concepts and overview of its functionality, down to the low-level development of actual UEFI applications, drivers, and services. The seminar will go over the history of UEFI’s development, from its original “Intel Boot Initiative” days to today’s SecureBoot facilities (and controversies), discuss the core UEFI data structures that form the basis of the environment, describe the different internal boot phases of the UEFI Runtime, and go in detail over the main UEFI protocols and their semantics. The course will also cover how UEFI leverages several Microsoft technologies, such as Authenticode and the Portable Executable (PE) format. Finishing off the lecture section will be a deep dive on how Windows 8 and later take advantage of UEFI to support booting off GPT disks, implementing SecureBoot, and speeding up the boot experience. Windows user-mode and kernel-mode APIs that interact with UEFI, as well as internal kernel data structures and capabilities in the UEFI HAL will also be shown off. Alongside the lecture period, attendees will get their hands dirty with bare-to-the-metal UEFI development using Visual Studio, as well as learning how to setup the UEFI SDK (EDK) to work alongside Microsoft’s development tools. Participants will get the chance to build their own UEFI applications, drivers, and runtime services, as well as learn how to debug and test their work in the OVMF environment alongside QEMU, without requiring actual UEFI hardware. The course will also show how to develop and build SecureBoot-compatible binaries. Finally, attendees will discover the Windows-specific Boot Application Runtime Environment, how to build compatible applications, and how to leverage the environment from both a UEFI and PCAT perspective. Attendees will then write both offensive and defensive UEFI code that hooks and/or protects the Windows Boot Loader.

UEFI Course Outline:
* Introduction to UEFI
* UEFI Architecture
* UEFI Protocols & Services
* Windows and UEFI
* Windows Boot Application Environment
* Windows Boot Loader Internals
* EDK and Visual Studio Development
* Windows & UEFI Interfacing

Topics:
* UEFI Protocols: UEFI Device Handles, UEFI Text and Graphics, UEFI Local and Remote I/O, UEFI USB & PCI, UEFI File System, Custom Protocols
* UEFI Services: UEFI Boot Services & Runtime Services, UEFI System Table, ACPI & UEFI, Custom Services
* UEFI Architecture: Measured Boot & Secure Boot, UEFI Stages & Layers (SEC, PEI, DXE), GPT Partitioning, Types of UEFI Binaries
* Windows & UEFI: Calling UEFI Services, Accessing UEFI Variables, Windows Boot Library and UEFI, BCD and UEFI, HAL and UEFI
* Windows Boot Environment: PCAT and UEFI Portability, Core Data Structures, Entrypoint and Callbacks,  Building a Windows Boot Application
* Windows Boot Loader: Boot Stages, Boot Loader Functionality, Security Services (BitLocker and more), Boot Structures, Handoff to Kernel
* UEFI Development: Obtaining and Installing the EDK, Setting up Visual Studio with the EDK, EDK Hello World, Interfacing with EDK Libraries, Obtaining and Installing OVMF
* Offensive UEFI: Hooking UEFI Services and Protocols, Windows Boot Environment Hooks, Persistence with UEFI
* Defensive UEFI: Checking for Boot Loader Integrity, Detecting UEFI Hooks and Bootkits

http://www.windows-internals.com/?page_id=1673

http://www.alex-ionescu.com/

Microsoft EMET pre-5.5 exploitable

Microsoft Releases Update for EMET

US-CERT is aware of a vulnerability in Microsoft Enhanced Mitigation Experience Toolkit (EMET) versions prior to 5.5. Exploitation of this vulnerability may allow a remote attacker to bypass or disable EMET to take control of an affected system. US-CERT recommends users and administrators visit the Microsoft Security TechCenter and upgrade to EMET version 5.5.

https://technet.microsoft.com/en-us/security/jj653751
https://www.fireeye.com/blog/threat-research/2016/02/using_emet_to_disabl.html
https://www.us-cert.gov/ncas/current-activity/2016/02/23/Microsoft-Releases-Update-EMET

Microsoft releases EMET 5.5

If you use Windows, you should probably check out EMET:

https://twitter.com/MattT_Cyber/status/694920707474530304

As Wikipedia describes: Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) is a freeware security toolkit for Microsoft Windows . It provides a unified interface to enable and fine-tune Windows security features. It can be used as an extra layer of defence against malware attacks, after the firewall and before antivirus software.

http://blogs.technet.com/b/srd/archive/2016/02/02/enhanced-mitigation-experience-toolkit-emet-version-5-5-is-now-available.aspx
https://www.microsoft.com/en-us/download/details.aspx?id=50766&WT.mc_id=rss_windows_allproducts
https://en.wikipedia.org/wiki/Enhanced_Mitigation_Experience_Toolkit

Windows 10 health check features

https://twitter.com/dfullerto/status/690555872917987328

Microsoft has an article that describes the new health check security features of Windows 10, which include use of UEFI Secure Boot and TPM technology, among others:

This article details an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and reporting the health of Windows 10-based devices, including hardware requirements.

https://technet.microsoft.com/en-us/library/mt592023%28v=vs.85%29.aspx

Intel Memory Protection Extensions (MPX) documentation available

https://twitter.com/intelswfeed/status/689591155516923904

https://software.intel.com/en-us/articles/intel-memory-protection-extensions-enabling-guide

Intel® Memory Protection Extensions Enabling Guide

This document describes Intel® Memory Protection Extensions (Intel® MPX), its motivation, and programming model. It also describes the enabling requirements and the current status of enabling in the supported OSs: Linux* and Windows* and compilers: Intel® C++ Compiler, GCC, and Visual C++*. Finally, the paper describes how ISVs can incrementally enable bounds checking in their Intel MPX applications.

SwiftOnSecurity on Windows/UEFI security

http://decentsecurity.com/#/securing-your-computer/

There’s a new guide to securing Windows systems. I enjoyed it because step 2 of the steps are firmware-centric, excerpted below, view the original doc, the excerpted formatting is a bit mangled, sorry.

I wish the advice mentioned using CHIPSEC to do security tests to see if system came from OEM with unfixable security flaws, and to use CHIPSEC or other tools — perhaps via LUV-live or directly — to save  a NIST SP-147-style ‘golden image’ of your ROM, doing periodic offline/forensic examination of your ROM images with CHIPSEC, UEFI Firmware Parser, and other tools. (I have no input as to the non-firmware Windows-centric input in the list.)

1.) Update BIOS
For best compatibility and security you should update your computer’s BIOS. A modern BIOS (really UEFI) is a full operating system that runs below and at the same time as Windows, and it needs patches too. People who built computers in the early 2000’s will tell you BIOS updates are risky, and they were, but not anymore. They deliver fixes, features, and security updates you won’t hear about on the news. Even new computers/motherboards need updates. If you’re starting from scratch, do the BIOS update after installing Windows 10. You can find the BIOS update tool on your manufacturer’s driver page for your computer model. You will need to reboot for it to take effect. If you have a Surface, BIOS updates are delivered through Windows Update.

3.) Configure BIOS
This is important and is something nobody talks about. From the boot of your computer, press the setup hotkey. It may be F1, F2, F8, F10, Del, or something else to get into SETUP mode. In the BIOS: Set a setup password. Make it simple, this is only to prevent malicious modification by someone in front of the computer or by a program trying to corrupt it. Change boot to/prioritize UEFI. Disable everything except UEFI DVD, UEFI HDD, and USB UEFI if you plan on using a USB stick to install Windows. Enable the TPM (if available) and SecureBoot (if available) options. This is super important. Disable 1394 (FireWire) and ExpressCard/PCMCIA (if you’re on a laptop) as a layer to further mitigate DMA attacks. This isn’t as important anymore, but if you don’t use them you might as well turn it off. If you want, and if the computer offers it, you can enable a System and HDD password. We will be using BitLocker to protect the disk, but this is an extra layer you can add if you want. I don’t. If you don’t use webcam or microphone, you may be able to turn them off in the BIOS. Save settings and shut down.

The Linux Foundation has some UEFI-centric, Linux-centric desktop advice, which has some overlaps in security methods to the above UEFI-centric, Windows-centric desktop advice:

Linux Foundation IT Security Policies: firmware guidance

The Crypto Party Handbook also has some related advice, for security/privacy-minded use. The Secure Desktop mailing list is the center of the universe for this, where the handful of Linux distributions that focus on secure/privacy as their main features, hang out. If you care about a secure OS, you should be using one of theirs, not an OS where security is not their primary concern.

https://github.com/cryptoparty/handbook

https://secure-os.org/pipermail/desktops/2015-October/000000.html
https://secure-os.org/desktops/charter/

[I need to find some similar security hardening checklist for ChomeOS-based, coreboot-based systems, instead of Windows-based UEFI/BIOS-based systems,  talking about ensuring TPM on x86/x64, using coreboot with Verified Boot, specifics on how to best adopt those keys, like how Nikolaj shows us how to adopt UEFI Secure Boot keys, and others show how to use MOK. Any tips appreciated, please leave a Comment (see left) or send email (see above right). Thanks.]

Win10 for ARM?

It sounds like non-embedded Windows may end up being available for platforms outside Intel again. Long ago, Microsoft Windows NT supported MIPS, Alpha, PowerPC, Itanium, as well as x86/x64. Embedded Windows supported many other processors, including ARM. And Microsoft already has ARM-based Surface devices, and Windows 10 for ARM-based RPI2.

http://www.winbuzzer.com/2016/01/14/rumor-microsoft-to-offer-windows-10-desktop-edition-for-arm-architecture-xcxwbn/
https://twitter.com/h0x0d/status/687501104947400704
https://msdn.microsoft.com/en-us/windows/hardware/dn940797%28v=vs.85%29.aspx
http://www.ubergizmo.com/2016/01/microsoft-might-be-developing-windows-10-for-arm-based-processors/
http://www.windowscentral.com/desktop-version-windows-10-arm-based-chips-might-be-development

 

 

SysInternals tools updated

SysIntenals, now acquired by the Microsoft TechNet team, has some new tool announcements:

http://blogs.technet.com/b/sysinternals/archive/2016/01/05/update-sigcheck-v2-4-sysmon-v3-2-process-explorer-v16-1-autoruns-v13-51-accesschk-v6-01.aspx

Sigcheck v2.4
Sysmon v3.2
Process Explorer v16.1
Autoruns v13.51
AccessChk v6.01