osquery

osquery is in the news a few places this week. They won an award at O’Reilly Security, the 2017 Project Defender Award. They were at Microsoft BlueHat, and they’ve got a new blog post.

https://twitter.com/mikearpaia/status/928638474651078656

[…]This marks the start of a four-part blog series that sheds light on the current state of osquery, its shortcomings and opportunities for improvement.[…]

How are teams currently using osquery?

https://github.com/facebook/osquery

https://osquery.io/

Many vulnerabilities found in Linux kernel USB subsystem by syzkaller

https://twitter.com/kayseesee/status/927923337543655424

Andrey Konovalov posted a bunch of Linux USB vulnerabilities to the OSS-Security list, found using the syzkaller Linux system call fuzzer.

Hi! Below are the details for 14 vulnerabilities found with syzkaller in the Linux kernel USB subsystem. All of them can be triggered with a crafted malicious USB device in case an attacker has physical access to the machine. There’s quite a lot more similar bugs reported [1] but not yet fixed.[…]

The first message had 14 vulns:
http://www.openwall.com/lists/oss-security/2017/11/06/8
This second message has 8 more:
http://www.openwall.com/lists/oss-security/2017/11/08/2

https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs_usb.md
https://github.com/google/syzkaller

Google syzkaller – Linux syscall fuzzer

 

 

 

LAVA 2017.11 released

Neil Williams of Linaro announced the 2017.11 release of LAVA.

2017.11 is the second release on the roadmap to the removal of V1. This is the single largest change ever made to the LAVA packages.
* All dashboard URLs are permanently disabled in lava-server.
* All devices which were not enabled for V2 are now hidden and unusable.
* All V1 code has been removed from lava-dispatcher.
* All V1 documentation has been removed from lava-server-doc.

2017.11 also includes large changes to the packaging of both lava-server and lava-dispatcher. The prompts formerly used to configure a V1 remote worker have been removed.

https://lists.linaro.org/pipermail/lava-announce/2017-November/000040.html
https://lists.linaro.org/pipermail/lava-announce/2017-September/000037.html
https://github.com/Linaro/pkg-lava-server
https://github.com/Linaro/pkg-lava-dispatcher
https://www.linaro.org/initiatives/lava/
https://validation.linaro.org/
https://wiki.linaro.org/LAVA
https://wiki.linaro.org/QA/AutomatedTestingFramework
https://wiki.debian.org/LAVA

UEFI-Bootkit docs updated

Re: https://firmwaresecurity.com/2016/11/04/uefi-bootkit/

Aidan Khoury of Quarkslab has updated UEFI-Bootkit. Only change to the project in the last year was update to readme, with more info. It is worth reading the USRT review of this bootkit, in the above URL.

https://github.com/dude719/UEFI-Bootkit

UEFI-Bootkit: A small bootkit designed to use zero assembly. Make sure to compile the driver as an EFI Runtime driver (EFI_RUNTIME_DRIVER) or else the bootkit will be freed once winload.efi calls ExitBootServices! Thanks to pyro666, dreamboot, and VisualUEFI.

alt text

 

SeaBIOS 1.11.0 released

New in this release:
* Initial support for NVME drives
* Support for vga emulation over a serial port in SeaBIOS (sercon)
* Support for serial debugging using MMIO based serial ports
* Support for scsi devices with multiple LUNs
* Support for boot-to-boot persistent coreboot cbmem logs
* Improved coreboot vga (cbvga) mode setting compatibility
* Several bug fixes and code cleanups

For full announcement, see Kevin O’Connor’s posting to the SeaBIOS list.

http://seabios.org/Releases
http://seabios.org/Download
https://mail.coreboot.org/mailman/listinfo/seabios

AFL-Unicorn: fuzz any architecture supported by Unicorn

https://twitter.com/revskills/status/928382801400991744

afl-unicorn let’s you fuzz any piece of binary that can be emulated by Unicorn Engine.

https://github.com/njv299/afl-unicorn

http://www.unicorn-engine.org/

Click to access p2313-xuA.pdf

https://hackernoon.com/afl-unicorn-fuzzing-arbitrary-binary-code-563ca28936bf

[…]Unicorn Mode works by implementing the block-edge instrumentation that AFLโ€™s QEMU Mode normally does into Unicorn Engine. Basically, AFL will use block coverage information from any emulated code snippet to drive its input generation. The whole idea revolves around proper construction of a Unicorn-based test harness, as shown in the figure below:

Microsoft launches Project Cerberus, NIST 800-193-compliant

[…]Today, weโ€™re also introducing Project Cerberus, which provides a critical component for security protection that to date has been missing from server hardware โ€“ protection, detection and recovery from attacks on platform firmware.[…] Project Cerberus is a NIST 800-193 compliant hardware root of trust specifically designed to provide robust security for all platform firmware. It provides a hardware root of trust for firmware on the motherboard (UEFI BIOS, BMC, Options ROMs) as well as on peripheral I/O devices by enforcing strict access control and integrity verification from pre-boot and continuing to runtime.[…]

Microsoftโ€™s Project Olympus delivers cloud hardware innovation at scale

https://github.com/opencomputeproject/Project_Olympus

Very excited to see NIST SP 800-193-compliance mentioned!!

https://csrc.nist.gov/publications/detail/sp/800-193/draft

 

VU739007: IEEE P1735 broken crypto

Vulnerability Note VU#739007
IEEE P1735 implementations may have weak cryptographic protections
Date: 03 Nov 2017

The P1735 IEEE standard describes methods for encrypting electronic-design intellectual property (IP), as well as the management of access rights for such IP. The methods are flawed and, in the most egregious cases, enable attack vectors that allow recovery of the entire underlying plaintext IP. Implementations of IEEE P1735 may be weak to cryptographic attacks that allow an attacker to obtain plaintext intellectual property without the key, among other impacts. The P1735 IEEE standard describes methods for encrypting electronic-design intellectual property (IP), as well as the management of access rights for such IP. The methods are flawed and, in the most egregious cases, enable attack vectors that allow recovery of the entire underlying plaintext IP. Some of these attack vectors are well-known, such as padding-oracle attacks. Others are new, and are made possible by the need to support the typical uses of the underlying IP. In particular, the need for commercial electronic design automation (EDA) tools to synthesize multiple pieces of IP into a fully specified chip design and to provide HDL syntax errors. These flaws can be exploited by leveraging the commercial EDA tool as a black-box oracle. In addition to being able to recover entire plaintext IP, one can produce standard-compliant ciphertexts of IP that have been modified to include targeted hardware Trojans.ย  An adversary can recover electronic design IPs encrypted using the P1735 workflow, resulting in IP theft and/or analysis of security critical features, as well as the ability to insert hardware trojans into an encrypted IP without the knowledge of the IP owner. Impacts may include loss of profit and reputation of the IP owners as well as integrated circuits (ICs) with trojans that contain backdoors, perform poorly, or even fail completely. See the researcher’s paper for full impact details.[...]

https://www.kb.cert.org/vuls/id/739007

Standardizing Bad Cryptographic Practice
A teardown of the IEEE P1735 standard for protecting electronic-design intellectual property
Animesh Chhotaray, Adib Nahiyan, Thomas Shrimpton, Domenic Forte, Mark Tehranipoor

We provide an analysis of IEEE standard P1735, which describes methods for encrypting electronic-design intellectual property (IP), as well as the management of access rights for such IP. We find a surprising number of cryptographic mistakes in the standard. In the most egregious cases, these mistakes enable attack vectors that allow us to recover the entire underlying plaintext IP. Some of these attack vectors are well-known, e.g. padding-oracle attacks. Others are new, and are made possible by the need to support the typical uses of the underlying IP; in particular, the need for commercial system-on-chip (SoC) tools to synthesize multiple pieces of IP into a fully specified chip design and to provide syntax errors. We exploit these mistakes in a variety of ways, leveraging a commercial SoC tool as a black-box oracle. In addition to being able to recover entire plaintext IP, we show how to produce standard-compliant ciphertexts of IP that have been modified to include targeted hardware Trojans. For example, IP that correctly implements the AES block cipher on all but one (arbitrary) plaintext that induces the block cipher to return the secret key. We outline a number of other attacks that the standard allows, including on the cryptographic mechanism for IP licensing. Unfortunately, we show that obvious โ€œquick fixesโ€ to the standard (and the tools that support it) do not stop all of our attacks. This suggests that the standard requires a significant overhaul, and that IP-authors using P1735 encryption should consider themselves at risk.

Click to access 828.pdf

http://ieeexplore.ieee.org/document/7274481/
https://standards.ieee.org/findstds/standard/1735-2014.html

Click to access ieeep1735.pdf

 

Positive Technologies: JTAG in each house: full access via USB

It is amazing to see the Intel ME research coming out of Positive Technologies!

From Google Translate:

JTAG in each house: full access via USB

Researchers at Positive Technologies have activated hardware debugging (JTAG) for Intel Management Engine, which allows full access to all PCH devices (Platform Controller Hub) using Intel DCI technology (via USB interface). We plan to share the details at one of the nearest conferences. And how to activate this interface, but for the main processor, we will tell below.[…]

https://habrahabr.ru/company/pt/blog/341946/

https://translate.google.com/translate?hl=en&sl=ru&u=https://habrahabr.ru/company/pt/blog/341946/

Intel ME is the new “Pandora’s Box”, defenders are going to need bigger (better) tools… ๐Ÿ˜ฆ

Tanenbaum responds to Intel about Minix-based ME

Intel ME running Minix is in the news again…

An Open Letter to Intel

[…]I knew that Intel had some potential interest in MINIX 3 several years ago when one of your engineering teams contacted me about some secret internal project and asked a large number of technical questions about MINIX 3, which I was happy to answer. I got another clue when your engineers began asking me to make a number of changes to MINIX 3, for example, making the memory footprint smaller and adding #ifdefs around pieces of code so they could be statically disabled by setting flags in the main configuration file.[…]

Yours truly,
Andrew S. Tanenbaum

http://www.cs.vu.nl/~ast/intel/

https://en.wikipedia.org/wiki/Andrew_S._Tanenbaum

http://www.minix3.org/

Intel ME: based on Minix?

Microsoft adds Time Travel Debugging (TTD) to Windbg

Time Travel Debugging is now available in WinDbg Preview

We are excited to announce that Time Travel Debugging (TTD) features are now available in the latest version of WinDbg Preview. About a month ago, we released WinDbg Preview which provides great new debugging user experiences. We are now publicly launching a preview version of TTD for the first time and are looking forward to your feedback.[…]

https://blogs.msdn.microsoft.com/windbg/2017/09/25/time-travel-debugging-in-windbg-preview/

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-object-model

As I hear, TTD has been used at Microsoft internally for years, just now getting this feature out to the public. Though they are not identical in implementation, GDB has had reverse execution for a while.

https://www.gnu.org/software/gdb/news/reversible.html
https://sourceware.org/gdb/onlinedocs/gdb/Reverse-Execution.html
https://sourceware.org/gdb/wiki/ReverseDebug

PCILeech: updated with new FPGA bitstream design

PCILeech FPGA contains software and HDL code for FPGA based devices that may be used together with the PCILeech Direct Memory Access (DMA) Attack Toolkit. Using FPGA based devices have many advantages over using the USB3380 hardware that have traditionally been supported by PCILeech. FPGA based hardware provides full access to 64-bit memory space without having to rely on a kernel module running on the target system. FPGA based devices are also more stable compared to the USB3380. FPGA based devices may also send raw PCIe Transaction Layer Packets TLPs – allowing for more specialized research.

https://github.com/ufrisk/pcileech-fpga
https://github.com/ufrisk/pcileech/

Automated Detection, Exploitation, and Elimination of Double-Fetch Bugs using Modern CPU Features

Automated Detection, Exploitation, and Elimination of Double-Fetch Bugs using Modern CPU Features
Michael Schwarz, Daniel Gruss, Moritz Lipp, Clรฉmentine Maurice, Thomas Schuster, Anders Fogh, Stefan Mangard
(Submitted on 3 Nov 2017)

Double-fetch bugs are a special type of race condition, where an unprivileged execution thread is able to change a memory location between the time-of-check and time-of-use of a privileged execution thread. If an unprivileged attacker changes the value at the right time, the privileged operation becomes inconsistent, leading to a change in control flow, and thus an escalation of privileges for the attacker. More severely, such double-fetch bugs can be introduced by the compiler, entirely invisible on the source-code level. We propose novel techniques to efficiently detect, exploit, and eliminate double-fetch bugs. We demonstrate the first combination of state-of-the-art cache attacks with kernel-fuzzing techniques to allow fully automated identification of double fetches. We demonstrate the first fully automated reliable detection and exploitation of double-fetch bugs, making manual analysis as in previous work superfluous. We show that cache-based triggers outperform state-of-the-art exploitation techniques significantly, leading to an exploitation success rate of up to 97%. Our modified fuzzer automatically detects double fetches and automatically narrows down this candidate set for double-fetch bugs to the exploitable ones. We present the first generic technique based on hardware transactional memory, to eliminate double-fetch bugs in a fully automated and transparent manner. We extend defensive programming techniques by retrofitting arbitrary code with automated double-fetch prevention, both in trusted execution environments as well as in syscalls, with a performance overhead below 1%.

https://arxiv.org/abs/1711.01254

Dynamic FPGA Detection and Protection of Hardware Trojan: A Comparative Analysis

Dynamic FPGA Detection and Protection of Hardware Trojan: A Comparative Analysis
Amr Alanwar, Mona A. Aboelnaga, Yousra Alkabani, M. Watheq El-Kharashi, Hassan Bedour
(Submitted on 3 Nov 2017)

Hardware Trojan detection and protection is becoming more crucial as more untrusted third parties manufacture many parts of critical systems nowadays. The most common way to detect hardware Trojans is comparing the untrusted design with a golden (trusted) one. However, third-party intellectual properties (IPs) are black boxes with no golden IPs to trust. So, previous attempts to detect hardware Trojans will not work with third-party IPs. In this work, we present novel methods for Trojan protection and detection on field programmable gate arrays (FPGAs) without the need for golden chips. Presented methods work at runtime instead of test time. We provide a wide spectrum of Trojan detection and protection methods. While the simplest methods have low overhead and provide limited protection mechanisms, more sophisticated and costly techniques are introduced that can detect hardware Trojans and even clean up the system from infected IPs. Moreover, we study the cost of using the FPGA partial reconfiguration feature to get rid of infected IPs. In addition, we discuss the possibility to construct IP core certificate authority that maintains a centralized database of unsafe vendors and IPs. We show the practicality of the introduced schemes by implementing the different methodologies on FPGAs. Results show that simple methods present negligible overheads and as we try to increase security the delay and power overheads increase.

https://arxiv.org/abs/1711.01010

Follow Arrigo on Twitter, for many more posts to related academic documents, a great resource.