Dynetics: seeks Weapons System Analysis, Hardware and Embedded Firmware

This is new kind of role for the new cyberwar era. I wish Consumer Reports was doing likewise for consumer devices.

Weapon System Analysis – Hardware and Embedded Firmware

Job responsibilities/focus areas include:

Embedded hardware and firmware characterization and vulnerability analysis of foreign weapon systems including missiles and radars.

https://careers.dynetics.com/job-view.php?p=4920

Zephyr Project: MCUboot Security Part 1

MCUboot Security Part 1
By Zephyr Project
November 28, 2018

Zephyr Project member David Brown, a Senior Engineer with Linaro Ltd., shares the best practices for security in this blog post, which first ran on Brownian Motion.

This is the first in what I hope to be a series of posts about the MCUboot bootloader from a security perspective. Please note that although I work in security, I am by no means a cryptographer. I appreciate any feedback on any and all flaws in my analysis. The MCUboot Project is a secure bootloader for 32-bit MCUs. The goal of MCUboot is to define a common infrastructure for the bootloader, system flash layout on microcontroller systems, and to provide a secure bootloader that enables easy software upgrade. The essential problem that MCUboot seeks to solve is how to allow firmware updates, while still maintaining some kind of integrity and control over what firmware can be run on the device. The easiest way to prevent unauthorized firmware from running on a device is to configure the flash to be immutable. Unfortunately, this prevents potential security updates (as well as functionality improvements). MCUboot solves this by itself being a small amount of code that can be placed in an immutable section of flash. It then can verify the main code before allowing it to execute, as well as control updates to that code. MCUboot is configurable, and these configuration choices affect the security promises that MCUboot is able to make.[…]

https://www.zephyrproject.org/mcuboot-security-part-1/

https://www.davidb.org/post/mcuboot-security-1/

https://mcuboot.com/

 

Intel: using SGX to improve blockchain security

Intel has a new post about using SGX to help with blockchain security.

https://itpeernetwork.intel.com/blockchain-intel-sgx/

https://www.intel.com/content/www/us/en/security/blockchain-overview.html

Wow, blockchain-based thinking is one thing I don’t want to see to have any part of my firmware. I wish I could wake up and blockchain would just end up being a bad dream about some snake oil.

2 possible ASUS UEFI malware issues?????

Two threads on ASUS issues that might be malicious, but will probably end up to be other kinds of defects. Sorry, no better summary of the issues:

https://tcsltesting.blogspot.com/2018/11/asus-uefi-rootkit.html

Kaspersky TDSS Killer: now with UEFI support (and Kaspersky Anti-Virus for UEFI (KUEFI))

The above tweet hints at UEFI support in Kaspersky TDSS Killer 3.1.0.20, but I’ve not found any more specific information.

https://usa.kaspersky.com/downloads/tdsskiller

PS: Kaspersky has a UEFI AntiVirus product, for OEMs:

Kaspersky Anti-Virus for UEFI (KUEFI) is the EFI BIOS level endpoint security solution providing effective protection from rootkits and bootkits and ensuring safe OS loading. The product’s key feature is that it starts running in the EFI environment even before the OS bootup process begins, thus preventing any resident malware from loading. By working on EFI level, KUEFI ensures reliable protection from rootkits, bootkits and other malware specifically designed to circumvent desktop anti-malware technologies. KUEFI is provided as a small EFI module which nevertheless contains the award-winning Kaspersky Anti-Virus engine. The KUEFI architecture enables its integration into any motherboard firmware supporting the EFI standard, regardless of the vendor.

https://usa.kaspersky.com/antivirus-for-uefi

Kaspersky Security Bulletin 2019: including “The Negative Rings” section

[…]The negative rings:
The year of Meltdown/Spectre/AMDFlaws and all the associated vulnerabilities (and those to come) made us rethink where the most dangerous malware actually lives. And even though we have seen almost nothing in the wild abusing vulnerabilities below Ring 0, the mere possibility is truly scary as it would be invisible to almost all the security mechanisms we have. For instance, in the case of SMM there has at least been a publicly available PoC since 2015. SMM is a CPU feature that would effectively provide remote full access to a computer without even allowing Ring 0 processes to have access to its memory space. That makes us wonder whether the fact that we haven’t found any malware abusing this so far is simply because it is so difficult to detect. Abusing this feature seems to be too good an opportunity to ignore, so we are sure that several groups have been trying to exploit such mechanisms for years, maybe successfully. We see a similar situation with virtualization/hypervisor malware, or with UEFI malware. We have seen PoCs for both, and HackingTeam even revealed a UEFI persistence module that’s been available since at least 2014, but again no real ITW examples as yet. Will we ever find these kinds of unicorns? Or haven’t they been exploited yet? The latter possibility seems unlikely.[…]

https://securelist.com/kaspersky-security-bulletin-threat-predictions-for-2019/88878/

 

GPU-pass-through-compatibility-check: Automatically set up a Linux system for PCI pass-through and check if it is compatible

This project consists of 3 parts.
1) A script (gpu-pt-check.sh) that automatically checks to what extend a computer is compatible with GPU pass-through in its given configuration.
2) A script (setup.sh) that automatically installs and configures your system for GPU pass-through (Only tested on fresh installs of Fedora 28 x64 with Gnome, booted in UEFI mode!)
3) Instructions on how to create a bootable Linux USB stick that automatically runs the gpu-pt-check.sh script when you boot from it without any user interaction required.

example output

https://github.com/T-vK/GPU-pass-through-compatibility-check

NISTIR 8200: Cybersecurity Standardization for the IoT

The Interagency International Cybersecurity Standardization Working Group (IICS WG) was established in December 2015 by the National Security Council’s Cyber Interagency Policy Committee. Its purpose is to coordinate on major issues in international cybersecurity standardization and thereby enhance U.S. federal agency participation in the process. Effective U.S. Government participation involves coordinating across the federal government and working with the U.S. private sector. The U.S. relies more heavily on the private sector for standards development than do many other countries. Companies and industry groups, academic institutions, professional societies, consumer groups, and other interested parties are major contributors to this process. Further, the many Standards Developing Organizations (SDOs) which provide the infrastructure for the standards development are overwhelmingly private sector organizations. On April 25, 2017, the IICS WG established an Internet of Things (IoT) Task Group to determine the current state of international cybersecurity standards development for IoT. This report is intended for use by the working group member agencies to assist them in their standards planning and to help coordinate U.S. Government participation in international cybersecurity standardization for IoT. Other organizations may also find this document useful in their planning.

https://csrc.nist.gov/publications/detail/nistir/8200/final

https://csrc.nist.gov/News/2018/NIST-Publishes-Interagency-Report-(NISTIR)-8200

SAIC seeks Computer Hardware Reverse Engineer

Re:  https://firmwaresecurity.com/2018/07/27/required-skills-of-a-nation-state-attacker-defender/ here’s a similar post:

– Conducting initial analysis of traditional and non-traditional systems in support of HQ US Cyber Command.
– Conducting technical exploitation and examination of high-priority digital media to include reverse-engineering, failure analysis, and vulnerability analysis of hardware to identify exploitation opportunities.
– Modifying hardware to either enable forensic analysis of the media or to change the functionality of the hardware for other purposes.
– Performing inspection, imaging, decapsulation, deprocessing, and other activities related to hardware reverse-engineering and exploitation in a state-of-the-art microelectronics exploitation laboratory.
– Enhancing and maintaining frameworks, processes, design patterns, techniques, tools, and standards for conducting hardware exploitation of digital media.
– Keeping abreast of and reporting on scientific, engineering, and operational advances in hardware exploitation.
– Performing full-scope forensic examinations from the hardware aspect of media.
– Using reverse engineering tools and methods to determine vulnerabilities of the device for technical exploitation purposes.
– Determining how a device boots/initializes, and obtaining a binary that can be used for reverse-engineering.
– Identifying the function that responds to network connections requests; understanding internal communications mechanisms; outlining the general structure of the system software; and determining how system state is altered/saved.
– Leading teams and participating in the analysis of embedded platform firmware and operating systems to understand security vulnerabilities associated with various platform communication links.
– Creating and executing test plans to ensure all requirements of developed capabilities are fully- satisfied.
– Using knowledge gained through the application of reverse-engineering and other research techniques, design and develop low-level C and assembly applications for embedded ARM platforms that interface directly with platform hardware.

– Assembly language and C/C++ programming experience; solid understanding of programming language and operating system concepts.
– Reverse- engineering skills for embedded systems with proprietary operating systems
– Experience examining a hardware platform to understand the software and hardware interaction of embedded systems.
– Experience applying knowledge of C and Assembler software development for embedded platforms that run commercial and/or custom operating systems.
– Experience with embedded system design, communication with peripheral devices at the hardware level, and reverse- engineering of system software.
– Experience scripting with the following Languages: shell, Perl, Python or the like.
– Experience with the following in Microprocessors/Architectures: ARM, MIPS, RISC, PowerPC, XScale, StrongARM, x86.
– Familiarity with microprocessor instruction sets is highly-desired.
– Experience with the following Operating Systems: VxWorks, Integrity, Embedded Linux, JunOS, Linux, Unix, Windows Embedded.
– Experience with RTOS is highly-desired.
– Experience with the following IDEs: Tornado, Workbench, VxSim, MULTI, TimeMachine, TraceEdge.
– Experience with the following Hardware Tools and Debuggers: Green Hills, Probe, SuperTrace Probe, Slingshot, spectrum analyzer, logic analyzer, JTAG, Agilent Technologies equipment.
– Experience with the following Software Tools and Debuggers: Wireshark, IDA Pro, OIlyDbg, pcap, gdb, make, hex editor.

https://jobs.saic.com/job/Huntsville-Computer-Hardware-Reverse-Engineer-Huntsville-Job-AL-35801/509680000/

10 Rules for the Secure Use of Cryptocurrency Hardware Wallets

Earlier this year, the Web3 Foundation (W3F) commissioned Trail of Bits for a security review and assessment of the risks in storing cryptocurrency. Everyone who owns cryptocurrency — from large institutions to individual enthusiasts — shares the W3F’s concerns. In service to the broader community, the W3F encouraged us to publish our recommendations for the secure use of hardware wallets: the small tamper-resistant peripherals that enable users to securely create and protect cryptocurrency accounts. Whether your cryptocurrency holdings amount to a few Satoshis or a small fortune, you will find this post useful.[…]

10 Rules for the Secure Use of Cryptocurrency Hardware Wallets

View story at Medium.com

r-efi: UEFI Reference Specification Protocol Constants and Definitions for Rust

The r-efi project provides the protocol constants and definitions of the UEFI Reference Specification as native rust code. The scope of this project is limited to those protocol definitions. The protocols are not actually implemented. As such, this project serves as base for any UEFI application that needs to interact with UEFI, or implement (parts of) the UEFI specification.

https://github.com/r-util/r-efi

See-also:

https://firmwaresecurity.com/2018/11/28/c-efi-uefi-reference-specification-protocol-constants-and-definitions-2/

More router uPnP hacks, and upnp_info.py

Another day, another uPnP mass hack: https://arstechnica.com/information-technology/2018/11/mass-router-hack-exposes-millions-of-devices-to-potent-nsa-exploit/

Of course, I’ve disabled uPnP on my router, but why take the router’s word for it? Tenable released this handy Python utility a while back:

https://github.com/tenable/upnp_info

It lets you know what devices in multicast range have uPnP enabled, as well as enumerating the service XML description. Handy!

AMIE: A Minimalist Instruction Extender

https://github.com/NeatMonster/AMIE

see-also: FRIEND

https://github.com/alexhude/FRIEND/

ALT Linux adds packages for UEFI keys and certs

https://github.com/alt-packages/alt-uefi-keys
https://github.com/alt-packages/alt-uefi-certs
https://en.altlinux.org/Main_Page
https://www.altlinux.org/UEFI

This package contains ALT Linux UEFI SB CA certificate corresponding to the private key that is now used to sign ALT Linux UEFI bootloaders to cope with UEFI SecureBoot regime (aka “Restricted Boot”). This can be enrolled by the user so that ALT shim and subsequent bootloaders are accepted by firmware without Microsoft’s certificates.

PS: ALT Linux Rescue includes an EFI System Partition (ESP) with a few tools, and a boot option to go into UEFI or Linux.

https://en.altlinux.org/Rescue

c-efi: UEFI Reference Specification Protocol Constants and Definitions

The c-efi project provides the protocol constants and definitions of the UEFI Reference Specification as native C11 code. The scope of this project is limited to those protocol definitions. The protocols are not actually implemented. As such, this project serves as base for any UEFI application that needs to interact with UEFI, or implement (parts of) the UEFI specification. Additionally to providing a C library, this project also serves as documentation base for UEFI programming in C. It provides target-triples for UEFI, bootstrap helpers, and a bunch of documentation how to get started.

https://github.com/c-util/c-efi

https://c-util.github.io/c-efi