IDA Pro 7.1 released

“With this version of IDA we publish the decompiler intermediate language: the microcode. We were planning to do it since very long time but the microcode was constantly evolving, we could not do it. After ten years of evolution it looks mature and ready to be published. We believe that it will permit our users to implement much more powerful and higher level analysis algorithms than before. In the future we plan to use the microcode in IDA too: if the decompiler is present, the analysis will be improved automatically. “

https://hex-rays.com/products/ida/7.1/index.shtml

https://hex-rays.com/products/ida/7.1/microcode.png

 

IoT, Security and Automotive: Who’s Responsible For Security?

IoT, Security & Automotive: Who’s Responsible For Security?

Experts at the Table, part 2: Cheap components contaminating the supply chain, the need for platforms and certifications, and the futility of trying to future-proof devices.
February 28th, 2018 – By: Ed Sperling

Semiconductor Engineering sat down to discuss security issues and how to fix them with Mark Schaeffer, senior product marketing manager for secure solutions at Renesas Electronics; Haydn Povey, CTO of Secure Thingz; Marc Canel, vice president of security systems and technologies at Arm; Richard Hayton, CTO of Trustonic; Anders Holmberg, director of corporate development at IAR Systems. What follows are excerpts of that conversation.[…]

Who’s Responsible For Security?

Who’s Responsible For Security?

add-to-efi.sh – script to add boot entries to native EFI loader

This script allows users and administrators to automatically add their EFISTUB-enabled Linux system to the system’s native EFI bootloader without the need of any additional bootloader. It’s required that all files needed to perform the boot process (e.g. vmlinuz-xxx, initramfs-xxx.img) reside on the EFI system partition, which has to be mounted somewhere. The tool searches for the EFI partition by its partition type, then for installed kernels and finally for suitable initrds (including Intel Microcode). Furthermore, the tool is able to detect if the root filesystem is encrypted and adds appropriate kernel parameters. If you want to use (PART)UUID for booting, this tool will also do.[…]

 

https://github.com/stertingen/add-to-efi.sh

OpenRAM project: open-source memory compiler for VLSI circuits

The OpenRAM project aims to provide a free, open-source memory compiler development framework for Random-Access Memories (RAMs). It is a joint development project between University of California Santa Cruz and Oklahoma State University to enable memory and computer system research by creating an open-source compiler infrastructure.

https://openram.soe.ucsc.edu/

Click to access OpenRAM_ICCAD_2016_paper.pdf

Click to access OpenRAM_ICCAD_2016_presentation.pdf

https://github.com/mguthaus/OpenRAM

Reusable Firmware Development: A Practical Approach to APIs, HALs and Drivers

Available: December 8, 2017
Reusable Firmware Development: A Practical Approach to APIs, HALs and Drivers
Jacob Beningo

Gain the knowledge and skills necessary to improve your embedded software and benefit from author Jacob Beningo’s more than 15 years developing reusable and portable software for resource-constrained microcontroller-based systems. You will explore APIs, HALs, and driver development among other topics to acquire a solid foundation for improving your own software. Reusable Firmware Development: A Practical Approach to APIs, HALs and Drivers not only explains critical concepts, but also provides a plethora of examples, exercises, and case studies on how to use and implement the concepts.

What You’ll Learn
* Develop portable firmware using the C programming language
* Discover APIs and HALs, explore their differences, and see why they are important to developers of resource-constrained software
* Master microcontroller driver development concepts, strategies, and examples
* Write drivers that are reusable across multiple MCU families and vendors
* Improve the way software documented
* Design APIs and HALs for microcontroller-based systems

Microsoft Device Health Attestation protocol

Re: https://firmwaresecurity.com/2018/02/22/hp-including-expected-pcr0-values-in-firmware-releases/

Microsoft Device Health Attestation protocol

Device Health Attestation
https://technet.microsoft.com/en-us/library/mt750346.aspx

[MS-DHA]: Device Health Attestation Protocol
https://msdn.microsoft.com/en-us/library/mt766195.aspx

IOTA crypto issues

http://iota.org/
https://github.com/IOTAledger
https://en.wikipedia.org/wiki/IOTA_(cryptocurrency)
https://blog.iota.org/official-statement-regarding-the-mit-dci-email-leaks-ea3cacd6699a
https://blog.iota.org/iota-foundation-hires-cybercrypt-615d2df79001

“IOTA is a public distributed ledger and data transfer layer that allows transactional settlement for the Internet of Things. IOTA utilizes the Tangle, a data structure based on a Directed Acyclic Graph (DAG).”

https://spectrum.ieee.org/tech-talk/computing/networks/cryptographers-urge-users-and-researchers-to-abandon-iota-after-leaked-emails

https://github.com/mit-dci/tangled-curl/blob/master/vuln-iota.md

View at Medium.com

Hardware Security: A Hands-On Learning Approach 1st Edition (eta Nov2018)

Release date: November 15, 2018
Hardware Security: A Hands-On Learning Approach 1st Edition
Swarup Bhunia,‎ Mark Tehranipoor
ISBN-13: 978-0128124772
ISBN-10: 0128124776
$89.95
Paperback: 432 pages
Publisher: Morgan Kaufmann

Hardware Security: A Hands-On Learning Approach provides a broad, comprehensive, and practical overview of hardware security encompassing all levels of our electronic hardware infrastructure. It covers basic concepts through advanced attack techniques and countermeasures, as illustrated through theory, case studies, and well-designed hands-on laboratory exercises for each key concept. The book is primarily intended to serve as a textbook for upper-level undergraduate students studying computer engineering, computer science, electrical engineering, and biomedical engineering, as well as a handy reference for graduate students, researchers and industry professionals.

For academic courses, the book contains a robust suite of teaching ancillaries, including:
* Schematic, layout and design files for a printed circuit board for hardware hacking (i.e. the HaHa board) that can be used by instructors to fabricate boards and provide to students for hands-on experiments
* A suite of videos demonstrating different hardware vulnerabilities, hardware attacks and countermeasures (downloadable from Elsevier website)
* Register transfer level (RTL) hardware code for AES to implement side-channel attacks (downloadable from Elsevier website)

 

https://www.elsevier.com/books/hardware-security/bhunia/978-0-12-812477-2

Firmware Test Suite 18.02.00 is released

New Features:
* ACPICA: Update to version 20180209
* uefirtvariable: add test for EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS attribute

See full announcement for list of bugfixes.

In related news, LUV has picked up the latest FWTS.

http://fwts.ubuntu.com/release/fwts-V18.02.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/18.02.00
https://launchpad.net/ubuntu/+source/fwts
https://lists.ubuntu.com/mailman/listinfo/fwts-announce

EFIDroid’s Qt port working on Intel now

The author of EFIDroid posted a comment, in reply to another EFIDroid query comment.  Previously, UEFI Qt of EFIDroid was ARM-centric, now:

“I’ve even recently started adding X64 support so it can be used on regular computers – I only have to add X64 support to UEFIThreads to complete that(which is required by QML).”

Looking forward to seeing UEFITool GUI app working as a UEFI app. 🙂

Qtbase: EFIDroid port of Qt to UEFI!

https://github.com/efidroid/qtbase

Purism has Heads working on Librem laptops

And newer Librems have TPMs bulit-in now.

https://puri.sm/posts/librem-now-most-secure-laptop-under-full-user-with-tamper-evident-features/

Heads booting on a Librem 13v2 TPM

SgxPectre Attacks: Leaking Enclave Secrets via Speculative Execution

SgxPectre Attacks: Leaking Enclave Secrets via Speculative Execution
Guoxing Chen, Sanchuan Chen, Yuan Xiao, Yinqian Zhang, Zhiqiang Lin, Ten H. Lai
(Submitted on 25 Feb 2018)

This paper presents SgxPectre Attacks that exploit the recently disclosed CPU bugs to subvert the confidentiality of SGX enclaves. Particularly, we show that when branch prediction of the enclave code can be influenced by programs outside the enclave, the control flow of the enclave program can be temporarily altered to execute instructions that lead to observable cache-state changes. An adversary observing such changes can learn secrets inside the enclave memory or its internal registers, thus completely defeating the confidentiality guarantee offered by SGX. To demonstrate the practicality of our SgxPectre Attacks, we have systematically explored the possible attack vectors of branch target injection, approaches to win the race condition during enclave’s speculative execution, and techniques to automatically search for code patterns required for launching the attacks. Our study suggests that any enclave program could be vulnerable to SgxPectre Attacks since the desired code patterns are available in most SGX runtimes (e.g., Intel SGX SDK, Rust-SGX, and Graphene-SGX).

https://arxiv.org/abs/1802.09085

 

ASUS doesn’t care about Linux [Firmware]

See image in below tweet. A tweet with a bug report about ACPI and TPM2 on ASUS systems.

Linux users: remember that you’re not using a Linux box, you’re using a Windows box, or a Chrome box, and reinstalling an OS, which the OEM doesn’t support, so they won’t be offering you any way to update your firmware with that OS. Unless you’re buying your machine from an OEM that installs Linux. If you are a Linux user, stop buying Windows/Chrome PCs and buy Linux PCs.

https://twitter.com/orionwl/status/968517661704556545

Amazon [Snowball] seeks Senior Hardware Security Engineer

Sr. Hardware Security Engineer

AWS Security is looking for an experienced Senior Security Engineer, specializing in hardware technologies, to help ensure AWS services are designed and implemented to the highest possible security standards. You will be responsible for supporting AWS service teams in the secure design of services, including customer-facing services with hardware components such as AWS Snowball. As the primary technical and strategic advocate for a variety of AWS-wide security initiatives, you will help internal and external partners to design from the beginning with security in mind.This is not an entry-level position, and a confident understanding of hardware/firmware security and the ability to collaborate with other leaders across the industry are essential to success in this role.
[…]
* Demonstrate *exceptional* judgment, integrity, business acumen, and communication skills
* Minimum 4 years of experience with two or more of the following categories:
— IoT network technologies (Z-Wave, Zigbee, Bluetooth/BLE, WLAN, identity/auth security)
— Hardware security (PCB, JTAG, UART, SPI, ROM, microcode, custom ASIC/FPGA)
— x86 and/or ARM chipset and firmware security (TPM, UEFI, TrustZone, secure boot)
— Local encryption and key management (LUKS, BitLocker, self-encrypting drives, etc)
— PKI and code signing architecture (X.509, EV SSL, certificate pinning, OCSP, CRL, etc)

https://us-amazon.icims.com/jobs/626253/sr.-hardware-security-engineer/job

See-also:

AWS Snowball:
https://aws.amazon.com/snowball/

Oracle Solaris 11.4: UEFI Secure Boot on Intel HW

UEFI Secure Boot on Oracle Solaris x86 enables you to install and boot Oracle Solaris on platforms where UEFI Secure Boot is enabled. This feature provides more security by maintaining a chain of trust during boot: digital signatures of the firmware and software are verified before executing the next stage. No break occurs in the chain because of unsigned, corrupt, or rogue firmware or software during the boot process. This feature helps assure that the firmware and software used to boot Oracle Solaris on a hardware platform is correct, and has not been modified or corrupted.

https://docs.oracle.com/cd/E72435_01/html/E72445/grijo.html
https://docs.oracle.com/cd/E37838_01/html/E60974/index.html
https://blogs.oracle.com/solaris/oracle-solaris-114-beta-released
https://github.com/oracle/solaris-userland/tree/master/components/shim
https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Linux-7-Update-4

 

 

SGX After Spectre and Meltdown: Status, Analysis and Remediations

SGX After Spectre and Meltdown: Status, Analysis and Remediations
Posted on January 25, 2018 by idfusionllc

Much has been written about the recently disclosed micro-architectural cache probing attacks named in the title of this document. These attacks, while known as a possibility for some time, have created significant concerns and remediation activity in the industry, secondary to the significant confidentiality threats they pose. These attacks are particularly problematic since they evade long standing protections that the industry has used as foundational constructs in the security design of modern operating systems.

While the threats to operating system protections have undergone significant discussion, there has been little official information surrounding the impact of this new threat class to Intel’s Software Guard eXtension (SGX) technology. This document is intended to provide support for system security architects and software engineers with respect to the impact of this new class of attack on SGX security guarantees. The development of this document was inspired by dialogue on the Intel SGX developer’s forum surrounding whether or not enclaves provide credible security guarantees in the face of these new threats.

Hardware and microcode enhancements introduced in the Intel Skylake micro-architecture provide the framework for the SGX Trusted Execution Environment (TEE). The SGX security architecture uses the notion of an enclave, which is an area of memory which contains data and code which can only be referenced by the enclave itself. Unauthorized access to these protected memory regions are blocked regardless of the privilege level of the context of execution attempting the access. As a result the premise is that enclaves will provide confidentiality and integrity guarantees even if the hardware, BIOS, hypervisor or operating system are compromised.[…]

https://software.intel.com/en-us/forums/intel-software-guard-extensions-intel-sgx/topic/754168

https://idfusionllc.com/2018/01/25/sgx-after-spectre-and-meltdown-status-analysis-and-remediations/

MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols

MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols

Caroline Trippel, Daniel Lustig, Margaret Martonosi

The recent Meltdown and Spectre attacks highlight the importance of automated verification techniques for identifying hardware security vulnerabilities. We have developed a tool for synthesizing microarchitecture-specific programs capable of producing any user-specified hardware execution pattern of interest. Our tool takes two inputs: a formal description of (i) a microarchitecture in a domain-specific language, and (ii) a microarchitectural execution pattern of interest, e.g. a threat pattern. All programs synthesized by our tool are capable of producing the specified execution pattern on the supplied microarchitecture. We used our tool to specify a hardware execution pattern common to Flush+Reload attacks and automatically synthesized security litmus tests representative of those that have been publicly disclosed for conducting Meltdown and Spectre attacks. We also formulated a Prime+Probe threat pattern, enabling our tool to synthesize a new variant of each—MeltdownPrime and SpectrePrime. Both of these new exploits use Prime+Probe approaches to conduct the timing attack. They are both also novel in that they are 2-core attacks which leverage the cache line invalidation mechanism in modern cache coherence protocols. These are the first proposed Prime+Probe variants of Meltdown and Spectre. But more importantly, both Prime attacks exploit invalidation-based coherence protocols to achieve the same level of precision as a Flush+Reload attack. While mitigation techniques in software (e.g., barriers that prevent speculation) will likely be the same for our Prime variants as for original Spectre and Meltdown, we believe that hardware protection against them will be distinct. As a proof of concept, we implemented SpectrePrime as a C program and ran it on an Intel x86 processor, averaging about the same accuracy as Spectre over 100 runs—97.9% for Spectre and 99.95% for SpectrePrime.

https://scirate.com/arxiv/1802.03802

UEFI BIOS Accessibility for the Visually Impaired

UEFI BIOS Accessibility for the Visually Impaired

Rafael R. Machado, Gustavo M. D. Vieira

People with some kind of disability face a high level of difficulty for everyday tasks because, in many cases, accessibility was not considered necessary when the task or process was designed. An example of this scenario is a computer’s BIOS configuration screens, which do not consider the specific needs, such as screen readers, of visually impaired people. This paper proposes the idea that it is possible to make the pre-operating system environment accessible to visually impaired people. We report our work-in-progress in creating a screen reader prototype, accessing audio cards compatible with the High Definition Audio specification in systems running UEFI compliant firmware.

Submitted 7 Dec 2017 to Computers and Society [cs.CY]
Published 11 Dec 2017
Journal ref: SBESC ’17: Proceedings of the VII Brazilian Symposium on Computing Systems Engineering, IEEE Computer Society, 2017, 155-160
Doi: 10.1109/SBESC.2017.27
http://arxiv.org/abs/1712.03186

Click to access 1712.03186.pdf

https://scirate.com/arxiv/1712.03186

 

ShmooCon2018 videos uploaded

https://archive.org/details/Shmoocon2018

0wn The Con
A Social Science Approach To Cybersecurity Education
AFL-Unicorn Fuzzing The Unfuzzable
AWS Honey Tokens With SPACECRAB
Better Git Hacking
Blink For Your Password, Blink Away Your Civil Rights
Building Absurd Christmas Light Shows
Catch Me If You Can
Certgraph
CITL Quantitative, Comparable Software Risk Reporting
Closing Remarks
Cyberlaw Year In Review
Debates
Deep Learning For Realtime Malware Detection
Defending Against Robot Attacks
Don’t Ignore GDPR It Matters Now
Electronic Voting In 2018 Threat Or Menace
Embedded Device Vulnerability Analysis Case Study Using Trommel
Friday Night Fire Talks – 1
Friday Night Fire Talks – 2
Getting Cozy With OpenBSM Auditing On MacOS
Hacking The News An Infosec Guide To The Media, And How To Talk To Them
IoT RCE, A Study With Disney (audio missing till 3rd minute)
Keynote
Listing The 1337
Ok Google, Tell Me About Myself (part)
Opening Closed Systems With Glitchkit
Opening Remarks, Rumblings, Ruminations, And Rants
Profiling And Detecting All Things SSL With JA3
Pseudo-doppler Redux
Radare2 In Conversation
Running A Marathon Without Breaking A Sweat
Securing Bare Metal Hardware At Scale
SIGINT On A Budget
Skill Building By Revisiting Past CVEs
Someone Is Lying To You On The Internet
Tap, Tap, Is This Thing On Testing Edr Capabilities
The Friedman Tombstone
This Is Not Your Grandfather’s SIEM
Time Signature Based Matching … In Cyber Relevant Logs
When CAN Cant

 

Xen Security Advisory XSA-254 updated to V12 (on Spectre/Meltdown)

The XSA on Spectre/Meltdown has been updated again, with more info on ARM firmware:

Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 12

Information leak via side effects of speculative execution

UPDATES IN VERSION 12:

Corrections to ARM SP2 information:
* ARM 32-bit requires new firmware on some CPUs.
* Provide link to the ARM firmware page, accordingly.
* ARM 32-bit mitigations are complete for Cortex-A CPUs.
We do not have information for other ARM CPUs at this time.

[…]
VULNERABLE SYSTEMS:
Systems running all versions of Xen are affected. For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of ARM processors to SP1 and SP2 varies by model and manufacturer. ARM has information on affected models on the following website. For SP3, only Intel processors are vulnerable. (The hypervisor cannot be attacked using SP3 on any ARM processors, even those that are listed as affected by SP3.) Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH, HVM, and 32-bit PV guests cannot exploit SP3.
[…]

https://xenbits.xen.org/xsa/advisory-254.html
https://xenbits.xen.org/xsa/
https://developer.arm.com/support/security-update
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
https://blog.xenproject.org/2018/01/22/xen-project-spectre-meltdown-faq-jan-22-update/
https://www.qubes-os.org/security/xsa/
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt