Microsoft SystemContainer

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/

 

exploiting Lenovo firmware, part 2

Cr4sh has written the second article in his series on Lenovo firmware security research:

Exploring and exploiting Lenovo firmware secrets
Hi, everyone! In this article I will continue to publish my research of Lenovo ThinkPad’s firmware. Previously I shown how to discover and exploit SMM callout vulnerabilities on example of SystemSmmAhciAspiLegacyRt UEFI driver 1day vulnerability. Also, I introduced a small toolkit called fwexpl that provides API for comfortable development of firmware exploits for Windows platform. My previous Lenovo exploit was able to execute custom code in SMM, such conditions allow relatively easy bypass of BIOS_CNTL security mechanism which protect firmware code stored inside SPI flash chip on motherboard from unauthorized modifications by operating system (BIOS_CNTL bypass also was discussed in my another article “Breaking UEFI security with software DMA attacks”). In addition to BIOS_CNTL, modern Lenovo computers also use SPI Protected Ranges (aka PRx) flash write protection, so, in this article I will present my generic exploitation technique that allows to bypass PRx and turn arbitrary SMM code execution vulnerability into the flash write protection bypass exploit. This technique also can be applied to UEFI compatible computers of other manufacturers — they all use similar design of specific firmware features that responsible for platform security. In second part of the article I will present a new 0day vulnerability in Lenovo firmware that allows arbitrary SMM code execution on a wide range of Lenovo models and firmware versions including the most recent ones. Exploitation of this vulnerability may lead to the flash write protection bypass, disabling of UEFI Secure Boot, Virtual Secure Mode and Credential Guard bypass in Windows 10 Enterprise and other evil things. […]

http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html
https://github.com/Cr4sh/ThinkPwn
See-also:

fwexpl – PC Firmware Exploitation Tool and Library

Cr4sh on SMM exploits in Lenovo firmware!

DebConf16

DebConf, Debian’s annual conference is happening in Cape Town, South Africa. Even if you aren’t in Cape Town this week, the DebConf event team is very good at providing postconference video archives, look for them to be available shortly.

https://bits.debian.org/2016/06/debconf16-schedule.html
https://debconf16.debconf.org/

Amongst the many interesting presentations, here’s a few firmware-related presentations to look forward to:

Secure Boot BOF
Ben Hutchings
Secure Boot is a UEFI feature that prevents unsigned boot code from being loaded. Assuming the bootloader checks the signature on the kernel, and the kernel checks the signature on code it itself loads, this chain of trust can be extended quite far into the running system. Unfortunately, the only signing key that is trusted by most implementations is held by Microsoft.
There are 2 major reasons for supporting Secure Boot in Debian:
 * some computers now ship with Secure Boot enabled by default, making it harder to install Debian;
 * while not perfect, it is a technology that can be used to make Debian user safer.
The plan the Ben (bwh) has been hatching is as follows:
 * a minimalistic shim bootloader is signed by Microsoft;
 * the shim load a bootloader that was properly signed by Debian (in the long run, ftpmaster@; right now, it’s bwh’s signing key);
 * the bootloader loads a kernel signed by Debian;
 * the kernel only accepts to load code signed by Debian (securelevel = 1).
The signing process itself uses signature packages, so as not to keep signing keys on the buildds or break reproducibility.
Advantages:
 * no dependency on Microsoft, once the shim is signed (and it should need fixes very seldom);
 * robust process that can take advantage of reproducible builds;
 * gives reasonable guarantees that the running kernel is a legitimate one;
 * trusting only Debian (as opposed to anything Microsoft signs) can easily be achieved by shipping a Debian-signed shim and having the user put the Debian key as the only trusted one.
Caveats:
 * doesn’t protect the userspace (yet!);
 * still vulnerable to somebody with a kernel exploit (but this doesn’t grant persistence) or who can get a bootloader signed by Microsoft.
Help us, fellow Debian hackers! You are our only hope.
https://debconf16.debconf.org/talks/79/

Secure Boot for Debian Linux
Ben Hutchings
Three years after a “Plan of action” for Secure Boot support, we’ve had another release without it and there are still many changes required. What is left to do and how will we finish it in time for “stretch”?
https://debconf16.debconf.org/talks/33/

Using LAVA for Debian
Neil Williams
How to use LAVA to provide test support on real hardware which can be remote or local to the user.
 * lava.debian.net
 * publish local tests from your desk to support testing packages like u-boot.
 * install lava-dispatcher on a machine on your LAN and publish local tests for everyone to view and analyse
 * run CI on the Linux kernel packages on hardware – ramdisk, NFS and SATA media
 * test DI on real hardware (typically ARM).
 * publish local tests of VM images, including live images, and potentially run tests on VM images where appropriate hardware is available.
 * run server-client tests on relevant hardware which cannot be easily performed in sbuild or single VM instances.
 * support for VLAN testing is available although unlikely to be via lava.debian.net itself.
 * support for Debian SSO for account creation.
 * XMLRPC and REST API interfaces.
https://debconf16.debconf.org/talks/10/

Debugging the IoT
Bdale Garbee Bernelle Verster Andy Simpkins
Panel discussion, aimed at the general public and more technical participants alike. The panel will discuss the open hardware movement, and how it fits in with Smart Homes. It will highlight and discuss the futurology, trends, and challenges. Challenges include security, the role of big vendors, the requirement for a more powerful platform, competing interests and the role of industrial providers. The panel will be hosted by Bernelle Verster, and panelists include Andy Simpkins and others. (Please get in touch if you want to be on the panel too).
https://debconf16.debconf.org/talks/119/

Debian on ARM devices
Martin Michlmayr
This talk will cover Debian on ARM devices, including NAS devices, development boards and other devices. The talk will briefly explain how the installer works on ARM from the point of view of a user. It will then cover in detail how Debian on ARM is different to Debian on x86 devices and what infrastructure we created in Debian to support a wide range of ARM devices, such as flash-kernel. Some supported platforms and devices will be covered as well.
https://debconf16.debconf.org/talks/90/

LUV v2.1-rc1 released

Ricardo Neri of Intel announced LUV version 2.1-RC1. There is now 32-bit support! The 64-bit image has network boot support.

(Unless you’ve compiled CHIPSEC yourself, you’ve probably never run CHIPSEC on a 32-bit system, this’ll be a good first time to test it out.)

Highlights:

* Naresh Bhat reworked our kernel recipe to improve readability and
maintainability.
* Megha Dey worked on bumping the kernel to v4.5 and updating the
testing and management tool for non-volatile DIMMs, NDCTL, to v50.
* Sai Praneeth Prakhya updated the kernel configuration to include
support for X2APIC. This is useful mainly when booting servers where we
can have lots interrupt lines.
* Write errors seen in GRUB when running bits due to a buffer alignment
problem was resolved.
* A new HTML test report is included. Now, in a single HTML file, we
include all the test information that previously was spread in separate
files. Every single test case now contains all of its execution details.
By clicking at any given test case, the report is expanded to reveal the
test details. Also, test names are colored by their pass/fail/skip
status, making them easier to spot.
* Miscellaneous bug and warning fixes at runtime and build time

      luv-efi.bblcass: Remove the commented out line from the file
      linux-yocto-efi-test: Update recipe for Linux v4.5
      linux-yocto-efi-test: Update linux-libc-headers
      ndctl: bump to version 50(v50)
      ndctl: Include package version in the recipe
      ndctl: build test suite only for 64 bit systems
      ndctl: fix build where /bin/sh is not a link to bash
      ndctl: do not build the documentation
      linux-yocto-efi-test: generalize across architecture
      linux-yocto-efi-test: Update acpi.cfg
      luv-efi: Update AArch64 filename convention
      grub: Change the grub image name to bootaa64.efi
      chipsec: set COMPATIBLE_HOST variable
      ovmf: update OVMF source revision
      linux-yocto-efi-test: Remove __init modifier from efi_mem_desc_lookup
      luv-test: convert do_install_runner into an append of do_install
      ndctl: back-port implementation of optional documentation
      efivarfs: add runtime dependency on e2fsprogs
      fwts: bump to V16.05.01
      bits: grub: efidisk: respect block_io_protocol buffer alignment
      grub: efidisk: respect block_io_protocol buffer alignment
      ovmf: update OVMF source revision
      luv-test-parser: update schema description
      luv-test-parser: correct description of tag data
      luv-test-parser: add support to process warnings
      luv-test-manager: count warnings issued by the luv test parser
      ndctl: parser: use the ‘warns’ field to report errors
      chipsec: parser: report errors and warnings correctly
      chipsec: parser: report test cases that issue warnings
      fwts: parser: correct emission of the RESULT tag
      kernel-efi-warnings: use a function for pattern searching
      kernel-efi-warnings: search dmesg for Firmware Bug/Warn/Info
      kernel-efi-warnings: parser: emit the START and END tags
      kernel-efi-warnings: parser: emit all the test cases’ info
      efivarfs: parser: emit START and END tags
      efivarfs: parser: emit all the test cases’ info
      ndctl: parser: emit START and END tags
      ndctl: parser: emit all the test cases’ info
      bits: parser: emit the START and END tags
      bits: emit all the test cases’ info
      chipsec: parser: emit the START and END tags
      chipsec: parser: count the test cases’ results before emitting status
      chipsec: parser: emit all the test cases’ info
      fwts: parser: emit the START and END tags
      fwts: parser: emit all the test cases’ info
      luv-test-parser: use the START tag
      luv-test-parser: add functions to generate HTML content
      luv-test-parser: create an HTML container for the test suite results
      luv-test-parser: save test result in a variable
      luv-test-parser: put test case info into HTML div elements
      luv-test-manager: remove unneeded tees
      initscripts: add files for base HTML code generation
      luv-test-manager: refactor HTML test report generation
      LUV v2.1-rc1
      kernel: linux-yocto-efi-test: Add linux_quirks.cfg file
      ovmf: linux-yocto-efi-test: Enable BGRT

https://download.01.org/linux-uefi-validation/v2.1/
https://download.01.org/linux-uefi-validation/v2.1/sha256_sums.asc
https://download.01.org/linux-uefi-validation/v2.1/nightly

For more information, including list of known bugs, see the full announcement on the LUV list:
http://lists.01.org/pipermail/luv/

Unicorn-based EFI emulator?

OSX Reverser has a new blog post on Apple EFI firmware passwords:

https://twitter.com/osxreverser/status/746479354570477568

[…] This is when I had an idea! How about creating an EFI emulator and debugger using the Unicorn Engine framework? I had a feeling this wouldn’t be extremely hard and time consuming because the EFI environment is self contained – for example no linkers and syscalls to emulate. I also knew that this binary was more or less isolated, only using a few Boot and RunTime services and very few external protocols. Since the total number of Boot and RunTime services are very small this meant that there wasn’t a lot of code to be emulated. And with a couple of days work the EFI DXE Emulator was born. To my surprise I was finally able to run and debug an EFI binary in userland, speeding the reverse engineering process up immensely and quickly providing insight to previously tricky code. […]

https://reverse.put.as/2016/06/25/apple-efi-firmware-passwords-and-the-scbo-myth/
https://sentinelone.com/blogs/apple-efi-firmware-passwords-and-the-scbo-myth/

Looking forward to an URL to this EFISwissKnife IDA plugin, and ESPECIALLY this new Unicorn-based EFI emulator! I can’t find an URL yet, though. 😦

BadUSB 2.0

BadUSB 2.0 USB MITM POC: The advanced uses and capabilities of rogue USB hardware implants for use in cyber espionage activities is still very much an unknown quantity in the industry. Security professionals are in considerable need of tools capable of exploring the threat landscape, and generating awareness in this area. BadUSB2, is a tool capable of compromising USB fixed-line communications through an active man-in-the-middle attack. It is able to achieve the same results as hardware keyloggers, keyboard emulation, and BadUSB hardware implants. Furthermore, BadUSB2 introduces new techniques to defeat keyboard-based one-time-password systems, automatically replay user credentials, as well as acquiring an interactive command shell over USB. […] So how is this any different from existing USB hardware implants like the Rubber Ducky, or keyloggers. Firstly, the devices I’ve seen can only achieve one or two attack classes such as eavesdropping or message fabrication. BadUSB2 can eavesdrop, replay, modify, fabricate, exfiltrate data and BadUSB in one device. Furthermore, when combining these attack classes really interesting attack scenarios begin to surface. Secondly, keyboard emulation devices register as an additional USB device making them easy to detect and block, i.e. why do I now have two keyboards attached!? Yes, such devices can be easily detected and blocked. The same can be said of BadUSB, it often needs to register as a secondary USB device to perform a malicious task. BadUSB2 is an INLINE hardware implant giving it the stealth of a hardware keylogger but far more capabilities as mentioned above. Finally, (law of 3’s), just cos. […] This project builds on the USB-MITM architecture introduced by Rijnard van Tonder and Herman Engelbrecht in their paper titled, “Lowering the USB Fuzzing Barrier by Transparent Two-Way Emulation”. A special thanks to Rijnard for such a brilliant idea. […]

https://github.com/withdk/badusb2-mitm-poc

U-Boot: Secure Boot by Authenticating/Decrypting SPL FIT blobs

Andreas Dannenberg of TI submitted a patch to the U-Boot list, with an update to an earlier Secure Boot patch. Here’s the intro comment from the patch:

This patch series is derived from an earlier RFC [1] with (most of the) feedback implemented that was provided by Simon, Tom, and Lokesh (see change log at the end). There are still some loose ends namely affecting the make process (see discussion here [2], maybe Yamada-san has some inputs?) as well as the conversion of the “weak” post-process function call to a Kconfig option. We did experiment with a few options regarding the Kconfig conversion but couldn’t really settle on a good way. Simon or Tom- if you could provide a tiny bit of additional direction here we will be happy to re-visit this and change the current implementation.

Here’s again the high-level summary of what we are trying to achieve:

A method is introduced that uses a “weak” post-process function call that’s injected into the SPL FIT loading process after each blob has been extracted (U-Boot firmware, selected DTB) which is populated with a platform specific function. In case of TI high-security (HS) device variants a ROM API call is performed (via SMC) that transparently handles authentication and optional decryption. This essentially allows authenticating (and optionally decrypting) U-Boot from SPL. The post-processing injection is implemented such to enable a more universal use of this feature by other platforms or for other purposes.

Furthermore the build process has been modified to automatically invoke a TI blob signing/encryption tool through the $TI_SECURE_DEV_PKG env variable already introduced into U-Boot. This singing/encryption step happens for each artifact that gets bundled into the final u-boot.img FIT blob.

Why do we need this for our platforms if some generic form of verified boot already exists in U-Boot? The approach proposed here provides support for decryption which is currently not available in U-Boot (and may not be easily implementable generically for example due to the need for keeping symmetric keys secure). Furthermore it allows for a consistent build as well as runtime flow no matter authentication and/or decryption is used (as opposed to using existing U-Boot verified boot for authentication and an additional TI-specific ROM API call for decryption for example). It also allows for a faster and more efficient boot process (auth and decryption can be performed in a single step by the ROM APIs also utilizing crypto HW accelerators in a completely transparent fashion). However anyone can still use the standard U-Boot verified boot scheme from U-Boot onwards if they so chose and only need authentication.

I also just re-rested the patch series on actual AM437x HS, DRA7 HS, DRA72 HS, and AM57 HS device variants by building and running SPL/U-Boot. I’ve also build-tested the corresponding non-HS device variant configurations to make sure nothing is broken there.

Changes RFC->PATCH:
– Update of README.ti-secure
– Unification of some of the secure ROM API call stuff between AM43xx and
  OMAP5-based platforms by moving those into common files
– Replacement of puts() with printf()
– Minor build simplification/cleanup
– Addition of “Reviewed-by:” comments for files that were pretty much carried
  over from the RFC as-is
– Addition of AM437x HS device build support (was missing in RFC)
– Removal of some redundant conditional compile directives
– Rebased on upstream U-Boot commit “Prepare v2016.07-rc2”

Regards,
Andreas Dannenberg

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg216299.html
[2] https://www.mail-archive.com/u-boot@lists.denx.de/msg216298.html

Andreas Dannenberg (4):
  arm: omap-common: add secure rom call API for secure devices
  arm: omap-common: secure ROM signature verify API
  arm: omap-common: Update to generate secure U-Boot FIT blob
  arm: omap5: add U-Boot FIT signing and SPL image post-processing

Daniel Allred (4):
  arm: cache: add missing dummy functions for when dcache disabled
  spl: fit: add support for post-processing of images
  arm: omap-common: add secure smc entry
  doc: Update info on using secure devices from TI

Madan Srinivas (1):
  arm: am4x: add U-Boot FIT signing and SPL image post-processing

See the patch email thread on the U-Boot list for more details.
http://lists.denx.de/mailman/listinfo/u-boot

FWTS 16.06.00 released, new ACPI features

Ivan Hu of Canonical.com announced the 16.06.00 release of Firmware Test Suite (FWTS).

New Features in this release include ACPI-related functionality:
  * acpi: method: acpi 6.0 adds USB-C Connection to _UPC
  * acpi: method: add _WPP method test (introduced in ACPI 6.1)
  * acpi: method: add _WPC method test (introduced in ACPI 6.1)
  * ACPICA: Update to version 20160527
  * acpi: hest: Add GHESv2 checking (LP: #1587624)
  * lib: acpi: Add support for HEST GHESv2

http://fwts.ubuntu.com/release/fwts-V16.06.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.06.00
https://launchpad.net/ubuntu/+source/fwts

There were some bugfixes, in ACPI, IPMI, UEFI, and some other technology areas, see the release notes — or the post on the FWTS list — for the list of bugfixes.

ARM on IoT/embedded security

Jim Wallace has a new post on the ARM Embedded blog, on “Securing the embedded IoT world”.

 

Simply put, security for Embedded  IoT devices is about protecting assets from malicious attack. Typically this protection is thought about in terms of keeping some assets, such as crypto keys, secret and controlling how software and data is modified. In order for the Internet of Things (IoT) to be successful it is important that devices and services are appropriately protected. As IoT products become successful they will become increasingly attractive for attackers and so appropriate security must be baked into every system and at every level. This will require a scalable “building block” approach where designers can use established security approaches that can scale from low cost microcontrollers through to high performance application processor based systems. However, understanding how to protect devices, data and services can be an overwhelming task for developers who are new to security and who must focus on other challenges such as battery life, form factor and user interfaces, just to name a few. […]

https://community.arm.com/groups/embedded/blog/2016/05/27/securing-the-embedded-iot-world

ARMSCGen: ARM Shellcode Generator

ARM Shellcode Generator: Shellcodes for ARM/Thumb mode. Ideas came from shell-storm and pwntools/pwnies. Thanks to share all of brilliant sources on the net. I’m interested in mobile platform and archtecture like Android on ARM, Router on MIPS and so on. This project named ARMSCGen focus on shellcode on ARM Architecture especially ARMv7 Thumb Mode.

https://github.com/alexpark07/ARMSCGen

Fujitsu to use ARM for next supercomputer

[…] “The latest milestone in our HPC journey came this week at the International Supercomputing Conference (ISC) in Frankfurt. Fujitsu, a global leader in HPC, announced Japan’s next-generation flagship supercomputer at the RIKEN Advanced Institute for Computational Science, will be powered by SoCs based on the ARMv8-A architecture. The “Post-K” supercomputer is the successor to the “K-supercomputer” which is currently ranked No. 5 in the Top 500 supercomputing rankings. Today, the K-computer today is used to solve critical compute problems in fields ranging from earthquake/tsunami research to drug discovery. The K-computer has taken complex problems like a human heart simulation that previously took 2 years and delivered results in 1 day. The Post-K computer is being developed to address similar challenges.” […]

Full post:
https://community.arm.com/people/lakshmimandyam/blog/2016/06/21/fujitsu-and-arm-collaborate-for-japan-s-post-k-supercomputer

http://www.fujitsu.com/

 

hardware timing attack research

https://twitter.com/johnregehr/status/745239417183416320

A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware
Qian Ge, Yuval Yarom, David Cock, Gernot Heiser

Microarchitectural timing channels expose hidden hardware state though timing. We survey recent attacks that exploit microarchitectural features in shared hardware, especially as they are relevant for cloud computing. We classify types of attacks according to a taxonomy of the shared resources leveraged for such attacks. Moreover, we take a detailed look at attacks used against shared caches. We survey existing countermeasures. We finally discuss trends in the attacks, challenges to combating them, and future directions, especially with respect to hardware support.

Debugging ARM with SOMINUM DRT

Daniel Ohara has posted a new article on the ARM blog, starting to show the debugging features of the commercial SOMNIUM DRT tools:

Debugging Embedded Systems: the Problems and Solutions
This article is the first in a series on the new debug features in SOMNIUM DRT. We all know from experience(and this is confirmed by many studies) that debugging takes up a significant part of the time in software development. Software systems are complex and debugging is hard. This is especially true for embedded systems where there may be real-time constraints on when data is received or sent, the timing of interrupts, and so on. This means that traditional techniques, such as breakpoints or changing to code to print out state information, cannot be used because they will drastically change the timing and therefore the behavior of the program. Program flow is often controlled by asynchronous and external events, for example inputs from touch sensors and other peripherals. Therefore the real-time behavior of the program cannot be understood simply by looking at the control flow in the source code. SOMNIUM DRT includes features to support debugging embedded systems. One of these enables the live, non-intrusive display of interesting data. Another is the ability to trace program flow so you can step backwards and forwards through the execution history to see how you to to a particular state. SOMNIUM DRT is is a set of development tools for ARM Cortex-M based devices [such as the Kinetis and LPC devices from NXP and the STM32 devices from STMicroelectronics]. It is fully compatible with industry-standard tools such as the GNU toolchain and Eclipse IDE. DRT uses our patented techniques to produce highly optimized code by exploiting information about the embedded processor, the memory system and other peripherals to deliver improved performance, lower code size and reduced energy use. It also includes some great debugging tools such as trace, live expressions and fault diagnosis. […]

https://community.arm.com/groups/embedded/blog/2016/06/08/debugging-embedded-systems-the-problems-and-solutions
http://www.somniumtech.com/software-tools/somnium-drt-cortex-m-ide

Intrinsic-ID increase MIPS security

Steve Bush has an article in Eletronics Weekly about Imagination Technology — the company that owns MIPS chips — teaming with “Eindhoven chip security firm Intrinsic-ID to add a ‘physically un-cloneable function’ (PUF) to MIPS cores – initially the M5150 CPU – for authentication and anti-cloning.”

Imagination increases security on MIPS processors

updated AMD DASH tools

https://twitter.com/AMDDevCentral/status/743910103657570304

AMD uses DMTF DASH and SMASH on some of it’s systems. It appears the Windows System Center download is newly-updated.

http://developer.amd.com/tools-and-sdks/cpu-development/tools-for-dmtf-dash/

http://developer.amd.com/tools-and-sdks/cpu-development/tools-for-dmtf-dash/#downloads

new UEFI chain-of-trust whitepaper

The UEFI Form has a new whitepaper on UEFI and the Chain of Trust:

https://twitter.com/Intel_UEFI/status/743874217603538946

The Chain of Trust: Keeping Computing Systems More Secure
UEFI Forum white paper explaining the Chain of Trust and its role in keeping computing systems secure

 

http://www.uefi.org/learning_center/papers
http://www.uefi.org/sites/default/files/resources/UEFI%20Forum%20White%20Paper%20-%20Chain%20of%20Trust%20Introduction_Final.pdf

DEF CON 24

If DEF CON 24 is not cancelled this year, it will be this Summer in Las Vegas. There are multiple hardware/IoT-centric presentations and workshops. The Hardware Hacking Village and IoT Village are there.

I don’t see a lot of firmware-centric stuff, but there is a lot of hardware-centric stuff so far. Maybe they’ll be added later, or they’ll only be at Black Hat Briefings. Or all the firmware researchers are busy being employed by OEMs now, no time for new presentations showing how to exploit their current employers. 🙂

https://www.defcon.org/html/defcon-24/dc-24-workshops.html
https://www.defcon.org/html/defcon-24/dc-24-speakers.html

==========

A few of the workshops that sound interesting to me:

Embedded system design: from electronics to microkernel development
Rodrigo Maximiano Antunes de Almeida Professor, Federal University of Itajubá
The workshop consists of a introduction on the embedded systems design. We’ll start building a simple electronic embedded system design. This will be used as the target platform. Later I pretend to talk about the low level side of C language as bit fields arrays and bitwise operations, pointers to fixed memory addresses/registers, how to access the microcontroler peripherals etc. These will be the base to develop a full embedded microkernel using ISO-C without the standard libraries. They will have a better understanding on the electronics-programming relationship and how these questions can impact on the kernel development. Aside they`ll get a deep knowledge in the kernel basic functions (processes scheduling, i/o drivers controller etc).

Applied Physical Attacks on Embedded Systems, Introductory Version
Joe FitzPatrick Instructor & Researcher, SecuringHardware
This workshop introduces several different relatively accessible interfaces on embedded systems. Attendees will get hands-on experience with UART, SPI, and JTAG interfaces on a MIPS-based wifi router. After a brief architectural overview of each interface, hands-on labs will guide through the process understanding, observing, interacting with, and exploiting the interface to potentially access a root shell on the target.

Car Hacking Workshop
Robert Leale President, CanBusHack
KC Johnson Security Researcher
Introduction to connecting to Vehicle Networks. In the workshop we’ll connect and send data to vehicle simulators and use scripts to fuzz messages. We will learn about vehicle systems and how they are connected.

Hunting Malware at Scale with osquery
Sereyvathana Ty Detection Infrastructure Team, Facebook
Nick Anderson Security Engineer, Facebook
Javier Marcos de Prado Security Engineer, Facebook
Teddy Reed Security Engineer, Facebook
Matt Moran Security Engineer Facebook
This workshop is an introduction to osquery, an open source SQL-powered operating system for instrumentation and analytics. osquery is developed and used by Facebook to proactively hunt for abnormalities. Since osquery allows us to easily ask questions about our infrastructure, it provides powerful capabilities, such as finding malware persistence techniques and scanning IOCs across our fleets of machines. This workshop is a very hands-on training and we expect participants to be comfortable with CLI.t to get familiar with how osquery works under the hood. Who should attend? This workshop is designed for information security professionals who defend small to large scale enterprise networks.

You CAN haz fun with with cars!
Javier Vazquez Vidal Product Security Engine Code White GmbH
Ferdinand Noelscher Security Researcher
So you already know that you can hack cars and do nasty remote stuff, right? But what about all the underlying data transfers that are going on in it? Do you want to learn how a target is approached, what info can you get out of each ECU, or what Security measures are in place to prevent you from doing so on a protocol level? We want to show you how all this stuff works, and what can you do about it! And for this, we will have the help of the CANBadger. Come and learn about protocols used over CAN, and use a CANBadger connected to real ECUs to learn what you can do with it. Oh, and you can assemble your own CANBadger board too!

PCB Design Crash Course: A primer to designing your own hacking tools
Seth Wahle Electronics Engineer & Hardware Hacker
Have you ever seen a system that knew you could hack, if you could only find a way to connect to its ridiculously exotic interface? What about that idea for an awesome hacking tool you imagined but didn’t know how to build? If the massive learning curve to hardware design is holding back your plans to hack the world, then this is the workshop for you! In this workshop, you will design your own basic LAN tap (based on the throwing star LAN tap from Great Scott Gadgets). We will go from the very basics all the way to a full set of design documentation that you could use to get your hardware design mass produced.

Physical Security for Computing Systems, a Look at Design, Attacks and Defenses
Steve Weingart Security Researcher
Physical security for computing systems is a topic that usually gets left to FIPS 140 and tamper labels, but it is a much broader and more interesting subject. As the value of data on computing systems increases and operating systems become more secure, physical attacks on computing systems to steal or modify assets become more likely. At the low end are locks and tamper labels, at the high end are complex mechanisms to detect and respond to tampering and intrusion from the box level all the way down to the chip level. All of this technology requires constant review and improvement, just as other competitive technologies need review to stay at the leading edge. The bar is ever rising. Physical security is an interdisciplinary field. The materials and chemistry are as important as the electronics, circuits and physics. A tamper label can be defeated by application of the right solvent. A cover switch can be defeated by piping super glue in through an air vent or a slightly bent cover. Hard epoxies can be removed with drain cleaner and a tamper detection circuit can be defeated by setting the supply voltage to a critical value or a microprocessor’s start up tests bypassed by manipulating the width of the reset pulse. This training session will show many of the known attack and defense methods from the basic to the exotic. It will include easy and low tech ways of performing high tech attacks, as well as descriptions of the highest tech methods. Design examples will be shown with examples of the tools, devices, circuits and materials used to implement both attack and defense systems. Demonstrations will be included.

Brainwashing Embedded Systems
Craig Young Security Researcher, Tripwire
Learning the secret incantations to make embedded systems carry out your will is not as hard as one might think. In the world of IoT, the hardened system is rare and most times a firmware image is more than enough to find and exploit weakness. This session explains in detail a process for going from zero-knowledge to zero-day on real-world devices without breaking a sweat. Attendees to this tutorial session will learn the ropes of firmware dissection, app decompilation, and manual fuzz testing in a hands-on hack lab. Participants will be provided with a customized Kali Linux virtual appliance and given access to several consumer devices for analysis. These techniques have been successfully employed by the author to identify over 100 CVEs on embedded/IoT devices as well as to win the 0-day and CTF tracks in the DEF CON 22 SOHOpelessly Broken router hacking competition.

==========

Some of the Presentations that caught my eye:

A Monitor Darkly: Reversing and Exploiting Ubiquitous On-Screen-Display Controllers in Modern Monitors
Ang Cui PHD, CEO & Chief Scientist, Red Balloon Security
Jatin Kataria Principal Research Scientist, Red Balloon Security
Francois Charbonneau Research Scientist, Red Balloon Security
There are multiple x86 processors in your monitor! OSD, or on-screen-display controllers are ubiquitous components in nearly all modern monitors. OSDs are typically used to generate simple menus on the monitor, allowing the user to change settings like brightness, contrast and input source. However, OSDs are effectively independent general-purpose computers that can: read the content of the screen, change arbitrary pixel values, and execute arbitrary code supplied through numerous control channels. We demonstrate multiple methods of loading and executing arbitrary code in a modern monitor and discuss the security implication of this novel attack vector. We also present a thorough analysis of an OSD system used in common Dell monitors and discuss attack scenarios ranging from active screen content manipulation and screen content snooping to active data exfiltration using Funtenna-like techniques. We demonstrate a multi-stage monitor implant capable of loading arbitrary code and data encoded in specially crafted images and documents through active monitor snooping. This code infiltration technique can be implemented through a single pixel, or through subtle variations of a large number of pixels. We discuss a step-by-step walk-through of our hardware and software reverse-analysis process of the Dell monitor. We present three demonstrations of monitoring exploitation to show active screen snooping, active screen content manipulation and covert data exfiltration using Funtenna. Lastly, we discuss realistic attack delivery mechanisms, show a prototype implementation of our attack using the USB Armory and outline potential attack mitigation options. We will release sample code related to this attack prior to the presentation date.

Universal Serial aBUSe: Remote Physical Access Attacks
Rogan Dawes Researcher, Sensepost
Dominic White CTO, SensePost
In this talk, we’ll cover some novel USB-level attacks, that can provide stealthy remote access to a machine’s console, and release a toolset using freely available hardware. In 2000, Microsoft published its 10 Immutable laws of security. One of which was ‘if a bad guy has unrestricted access to your computer, it’s not your computer anymore.’ This has been robustly demonstrated over the years. Examples include numerous DMA-access attacks against interfaces such as firewire, PCMCIA and thunderbolt as well as USB-based attacks including simple in-line keyloggers, ‘evil maid‘ attacks and malicious firmware. Despite these warnings, groups such as the NSA were still able to use physical access to bypass software controls with toolsets such as COTTONMOUTH. […]
CANSPY: a Framework for Auditing CAN Devices
Jonathan-Christofer Demay Airbus Defence and Space
Arnaud Lebrun Airbus Defence and Space
In the past few years, several tools have been released allowing hobbyists to connect to CAN buses found in cars. This is welcomed as the CAN protocol is becoming the backbone for embedded computers found in smartcars. Its use is now even spreading outside the car through the OBD-II connector: usage-based policies from insurance companies, air-pollution control from law enforcement or engine diagnostics from smartphones for instance. Nonetheless, these tools will do no more than what professional tools from automobile manufacturers can do. In fact, they will do less as they do not have knowledge of upper-layer protocols. Security auditors are used to deal with this kind of situation: they reverse-engineer protocols before implementing them on top of their tool of choice. However, to be efficient at this, they need more than just being able to listen to or interact with what they are auditing. Precisely, they need to be able to intercept communications and block them, forward them or modify them on the fly. This is why, for example, a framework such as Burp Suite is popular when it comes to auditing web applications. In this paper, we present CANSPY, a framework giving security auditors such capabilities when auditing CAN devices. Not only can it block, forward or modify CAN frames on the fly, it can do so autonomously with a set of rules or interactively using Ethernet and a packet manipulation framework such as Scapy. It is also worth noting that it was designed to be cheap and easy to build as it is mostly made of inexpensive COTS. Last but not least, we demonstrate its versatility by turning around a security issue usually considered when it comes to cars: instead of auditing an electronic control unit (ECU) through the OBD-II connector, we are going to partially emulate ECUs in order to audit a device that connects to this very connector.

pin2pwn: How to Root an Embedded Linux Box with a Sewing Needle
Brad Dixon, Hacker
Security assessments of embedded and IoT devices often begin with testing how an attacker could recover firmware from the device. When developers have done their job well you’ll find JTAG locked-up, non-responsive serial ports, locked-down uboot, and perhaps even a home brewed secure-boot solution. In this session you’ll learn details of a useful hardware/software penetration technique to attempt when you’ve run out of easier options. We’ve used this technique on two commercial device security assessments successfully and have refined the technique on a series of test devices in the lab. This session will cover the prerequisites for successful application of the technique and give you helpful hints to help your hack! Best of all this technique, while a bit risky to the hardware, is easy to try and doesn’t require specialized equipment or hardware modification. We are going to take pieces of metal and stab them at the heart of the hardware and see what happens. For the hardware/firmware developer you’ll get a checklist that you can use to reduce your vulnerability to this sort of attack.

Stumping the Mobile Chipset
Adam Donenfeld Senior Security Researcher, Check Point
Following recent security issues discovered in Android, Google made a number of changes to tighten security across its fragmented landscape. However, Google is not alone in the struggle to keep Android safe. Qualcomm, a supplier of 80% of the chipsets in the Android ecosystem, has almost as much effect on Android’s security as Google. With this in mind, we decided to examine Qualcomm’s code in Android devices. During our research, we found multiple privilege escalation vulnerabilities in multiple subsystems introduced by Qualcomm to all its Android devices in multiple different subsystems. In this presentation we will review not only the privilege escalation vulnerabilities we found, but also demonstrate and present a detailed exploitation, overcoming all the existing mitigations in Android’s Linux kernel to run kernel-code, elevating privileges and thus gaining root privileges and completely bypassing SELinux.

I Fight For The Users, Episode I – Attacks Against Top Consumer Products
Zack Fasel Managing Partner, Urbane
Erin Jacobs Managing Partner, Urbane
This is not just another “I found a problem in a single IOT device” talk. Focusing on attacking three major consumer product lines that have grown rapidly in the past years, Zack and Erin will review flaws they’ve discovered and weaponized against home Windows installs, DIY security solutions, personal fitness tracking devices, and digital notification devices. We’ll review the security of these popular products and services in a ‘consumer reports’ style walkthrough, the attack methods against the 21 devices reviewed, release some tools for the lulz, and highlight the threats facing similar products. It’s time to Fight for the Users. END OF LINE.

101 Ways to Brick your Hardware
Joe FitzPatrick SecuringHardware.com
Joe Grand (Kingpin) Grand Idea Studio
Spend some time hacking hardware and you’ll eventually render a piece of equipment unusable either by accident or intentionally. Between us, we’ve got decades of bricking experience that we’d like to share. We’ll document the most common ways of temporarily or permanently damaging your hardware and ways to recover, if possible. We’ll also talk about tips on how to avoid bricking your projects in the first place. If you’re getting into hardware hacking and worried about messing something up, our stories will hopefully prevent you from experiencing the same horrors we did. If you’re worried about an uprising of intelligent machines, the techniques discussed will help you disable their functionality and keep them down.

Direct Memory Attack the Kernel
Ulf Frisk Penetration Tester
Inexpensive universal DMA attacking is the new reality of today! In this talk I will explore and demonstrate how it is possible to take total control of operating system kernels by DMA code injection. Once control of the kernel has been gained I will execute code and dump gigabytes of memory in seconds. Full disk encryption will be defeated, authentication will be bypassed and shells will be spawned. This will all be made possible using a $100 piece of hardware together with the easy to use modular PCILeech toolkit – which will be published as open source after this talk.

Hacker-Machine Interface – State of the Union for SCADA HMI Vulnerabilities
Brian Gorenc Senior Manager, Trend Micro Zero Day Initiative
Fritz Sands Security Researcher, Trend Micro Zero Day Initiative
Over the last year, synchronized and coordinated attacks against critical infrastructure have taken center stage. Remote cyber intrusions at three Ukrainian regional electric power distribution companies in December 2015 left approximately 225,000 customers without power. Malware, like BlackEnergy, is being specially developed to target supervisory control and data acquisition (SCADA) systems. Specifically, adversaries are focusing their efforts on obtaining access to the human-machine interface (HMI) solutions that act as the main hub for managing the operation of the control system. Vulnerabilities in these SCADA HMI solutions are, and will continue to be, highly valuable as we usher in this new era of software exploitation. This talk covers an in-depth analysis performed on a corpus of 200+ confirmed SCADA HMI vulnerabilities. It details out the popular vulnerability types discovered in HMI solutions developed by the biggest SCADA vendors, including Schneider Electric, Siemens, General Electric, and Advantech. It studies the weaknesses in the technologies used to develop HMI solutions and describes how critical vulnerabilities manifest in the underlying code. The talk will compare the time-to-patch performance of various SCADA vendors along with a comparison of the SCADA industry to the rest of the software industry. Finally, using the data presented, additional guidance will be provided to SCADA researchers along with a prediction on what we expect next in attacks that leverage SCADA HMI vulnerabilities.

BSODomizer HD: A Mischievous FPGA and HDMI Platform for the (M)asses
Joe Grand (Kingpin) Grand Idea Studio
Zoz Hacker
At DEF CON 16 in 2008, we released the original BSODomizer (www.bsodomizer.com), an open source VGA pranking tool and introductory hacking platform for the multicore Propeller micro-controller. Hours of productivity were replaced with rage and frustration as unwitting computer users were confronted with fake Blue Screens of Death and revolting ASCII art. But, the world has changed. The machines have risen in capability. HDMI is the graphical transmission protocol of choice and hacking with micro-controllers is standard issue. The as-seen-on-HDTV duo of Joe Grand and Zoz return with the next generation of mischievous hardware, a device that supplants or captures any inline HDMI signal in a discreet, pentest-worthy package. BSODomizer HD is an FPGA-based system that not only improves on the graphics interception and triggering features of its predecessor, but can now capture screenshots of a target system and also provides a fully open design that you can use for your own experiments into the mystical world of massive, customizable arrays of digital logic. We’ll guide you through the process of going from lamer zero to hacker hero with FPGAs, while savagely fucking with a few unfortunate friends along the way!

==========

U-Boot Secure Boot

Sumit Garg of NXY has submitted a 4-part patch to U-Boot to add Secure Boot support to U-Boot’s SPL framework. Sumit’s patch announcements follow.
(No, I didn’t edit out step 2 in next paragraph, there were only two steps, 1 and 3.)

The patch-set does the following :
1. Enable chain of trust in SPL framework for ARM based platforms.
3. Add SD secure boot target for ls1021atwr platform.

Sumit Garg (4):
  DM: crypto/fsl: Enable rsa DM driver usage before relocation
  SECURE_BOOT: Enable chain of trust in SPL framework
  SECURE_BOOT: Enable SD as a source for bootscript
  arm: ls1021atwr: Add SD secure boot target

[PATCH 1/4] DM: crypto/fsl: Enable rsa DM driver usage before relocation

Enable rsa signature verification in SPL framework before relocation for verification of main u-boot.

[PATCH 2/4] SECURE_BOOT: Enable chain of trust in SPL framework

Override jump_to_image_no_args function to include validation of u-boot image using spl_validate_uboot before jumping to u-boot image.
Also define macros in SPL framework to enable crypto operations.

[PATCH 3/4] SECURE_BOOT: Enable SD as a source for bootscript

Add support for reading bootscript and bootscript header from SD. Also renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and NOR flash.

[PATCH 4/4] arm: ls1021atwr: Add SD secure boot target

Add SD secure boot target for ls1021atwr.
Implement board specific spl_board_init() to setup CAAM stream ID and corresponding stream ID in SMMU. Change the u-boot size defined by a macro for copying the main U-Boot by SPL to also include the u-boot Secure Boot header size as header is appended to u-boot image. So header will also be copied from SD to DDR.

For more information, see the full patch on the list:
http://lists.denx.de/mailman/listinfo/u-boot

U-Boot Secure Boot

Andreas Dannenberg of TI has submitted a 9-part patch to the U-Boot project, adding LOTS more security to the boot process. It includes and depends on some other recent patches by Madan Srinivas, Daniel Allred, and others I think (sorry for lack of attribution).

[RFC 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs

This is an RFC for a method that uses a “weak” post-process function call that’s injected into the SPL FIT loading process after each blob has been extracted (U-Boot firmware, selected DTB) which is populated with a platform specific function. In case of TI high-security (HS) device variants a ROM API call is performed (via SMC) that transparently handles authentication and optional decryption. This essentially allows authenticating (and optionally decrypting) U-Boot from SPL. The post-processing injection is implemented such to enable a more universal use of this feature by other platforms or for other purposes.

Furthermore the build process has been modified to automatically invoke a TI blob signing/encryption tool through the $TI_SECURE_DEV_PKG env variable already introduced into U-Boot. This singing/encryption step happens for each artifact that gets bundled into the final u-boot.img FIT blob.

Why do we need this for our platforms if some generic form of verified boot already exists in U-Boot? The approach proposed here provides support for decryption which is currently not available in U-Boot (and may not be easily implementable generically for example due to the need for keeping symmetric keys secure). Furthermore it allows for a consistent build as well as runtime flow no matter authentication and/or decryption is used (as opposed to using existing U-Boot verified boot for authentication and an additional TI-specific ROM API call for decryption for example). It also allows for a faster and more efficient boot process (auth and decryption can be performed in a single step by the ROM APIs also utilizing crypto HW accelerators in a completely transparent fashion). However anyone can still use the standard U-Boot verified boot scheme from U-Boot onwards if they so chose and only need authentication.

The patch series has been tested on DRA7 HS, DRA72 HS, and AM57 HS device variants. The AM43 HS support is still missing some Makefile changes but the principle in the final implementation will be similar what’s implemented for the other devices.

  spl: fit: add support for post-processing of images
  arm: cache: add missing dummy functions for when dcache disabled
  arm: omap-common: add secure smc entry
  arm: omap-common: add secure rom call API for secure devices
  arm: omap5: add secure ROM signature verify API
  arm: omap5: add FIT image post process function
  ti: omap-common: Update to generate secure FIT

  arm: am4x: add secure ROM signature verify API
  arm: am4x: add FIT image post process function

[RFC 1/9] spl: fit: add support for post-processing of images
The next stage boot loader image and the selected FDT can be post-processed by board/platform/device-specific code, which can include modifying the size and altering the starting source address before copying these binary blobs to their final desitination. This might be desired to do things like strip headers or footers attached to the images before they were packeaged into the FIT, or to perform operations such as decryption or authentication.

[RFC 2/9] arm: cache: add missing dummy functions for when dcache disabled
Adds missing flush_dcache_range and invalidate_dcache_range dummy (empty) placeholder functions to the #else portion of the #ifndef CONFIG_SYS_DCACHE_OFF, where full implementations of these functions are defined.

[RFC 3/9] arm: omap-common: add secure smc entry
Adds an interface for calling secure ROM APIs across a range of OMAP and OMAP compatible devices.

[RFC 4/9] arm: omap-common: add secure rom call API for secure devices Adds a generic C-callable API for making secure ROM calls on OMAP and OMAP-compatible devices. This API provides the important function of flushing the ROM call arguments to memory from the cache, so that the secure world will have a coherent view of those arguments. Then is simply calls the omap_smc_sec routine.

[RFC 5/9] arm: omap5: add secure ROM signature verify API
Adds an API that verifies a signature attached to an image (binary blob). This API is basically a entry to a secure ROM service provided by the device and accessed via an SMC call, using a particular calling convention.

[RFC 6/9] arm: omap5: add FIT image post process function
Adds a board specific FIT image post processing function for when CONFIG_SECURE_BOOT is defined.  Also update the omap common config header to enable CONFIG_SECURE_BOOT always for secure TI devices (CONFIG_TI_SECURE_DEVICE is defined).

[RFC 7/9] arm: am4x: add secure ROM signature verify API
Adds an API that verifies a signature attached to an image (binary blob). This API is basically a entry to a secure ROM service provided by the device and accessed via an SMC call, using a particular calling convention. This API is common across AM3x HS and AM4x HS devices.

[RFC 8/9] arm: am4x: add FIT image post process function
Adds a board specific FIT image post processing function when u-boot is compiled for the high-secure (HS) device variant.

[RFC 9/9] ti: omap-common: Update to generate secure FIT
Adds commands so that when a secure device is in use and the SPL is built to load a FIT image (with combined u-boot binary and various DTBs), these components that get fed into the FIT are all processed to be signed/encrypted/etc. as per the operations performed by the secure-binary-image script of the TI SECDEV package.

For more information, see the full patch on the list:
http://lists.denx.de/mailman/listinfo/u-boot