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

https://twitter.com/Mr_pwn/status/1067742111003492353

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.[…]

Kaspersky Security Bulletin 2018. Threat Predictions for 2019

 

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 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:

c-efi: UEFI Reference Specification Protocol Constants and Definitions

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

Lenovo LEN-24374: Multiple SMM vulnerabilities, CVE-2018-(9083-9084,16089-16092,16094-16096)

System Management Module Vulnerabilities

Lenovo Security Advisory: LEN-24374
Potential Impact: Privilege escalation
Severity: High
Scope of Impact: Lenovo-specific

CVE Identifier: CVE-2018-9083, CVE-2018-9084, CVE-2018-16089, CVE-2018-16090, CVE-2018-16091, CVE-2018-16092, CVE-2018-16094, CVE-2018-16095, CVE-2018-16096

Summary Description:

A Lenovo security audit of the System Management Module firmware uncovered the following vulnerabilities. SMM networking is disabled by default, and these cannot be exploited until networking is enabled:

CVE-2018-16089: A field in the header of SMM firmware update images is insufficiently sanitized, allowing post-authentication command injection on the SMM as the root user.

CVE-2018-16090: The SMM certificate creation and parsing logic is vulnerable to post-authentication command injection.

CVE-2018-16091: The SMM certificate creation and parsing logic is vulnerable to several buffer overflows.

CVE-2018-9083: The SMM contains weak default root credentials which could be used to log in to the device OS — if the attacker manages to enable SSH or Telnet connections via some other vulnerability.

CVE-2018-9084: If an attacker manages to log in to the device OS, the validation of software updates can be circumvented.

CVE-2018-16092: The FFDC feature includes the collection of SMM system files containing sensitive information; notably, the SMM user account credentials and the system shadow file.

CVE-2018-16094: An internal SMM function that retrieves configuration settings is prone to a buffer overflow.

CVE-2018-16095: The SMM records hashed passwords to a debug log when user authentication fails.

CVE-2018-16096: The SMM web interface for changing Enclosure VPD fails to sufficiently sanitize all input for HTML tags, possibly opening a path for cross-site scripting.

https://support.lenovo.com/pt/fi/solutions/len-24374

see-also:
https://exchange.xforce.ibmcloud.com/vulnerabilities/153003

NVMe adds TCP support

This week the ratified NVMe™/TCP Transport Binding specification has been made available for public download. TCP is a new transport added to the family of existing NVMe™ transports; PCIe®, RDMA, and FC. NVMe/TCP defines the mapping of NVMe queues, NVMe-oF capsules and data delivery over the IETF Transport Control Protocol (TCP). The NVMe/TCP transport offers optional enhancements such as inline data integrity (DIGEST) and online Transport Layer Security (TLS).[…]

Welcome NVMe™/TCP to the NVMe-oF™ Family of Transports

https://nvmexpress.org/wp-content/uploads/NVM-Express-over-Fabrics-1.0-Ratified-TPs.zip

http://git.infradead.org/nvme.git/shortlog/refs/heads/nvme-tcp

https://review.gerrithub.io/c/spdk/spdk/+/425191/

Amazon.com announces Firecracker: a Secure, Open Source microVM

https://github.com/firecracker-microvm/firecracker/blob/master/SPECIFICATION.md

https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/

Firecracker logo

Breaking into the (Digital) BitBox

Saleem Rashid
Breaking into the (Digital) BitBox
Nov 26, 2018

In this post, I am going to discuss the security issues I discovered in a hardware wallet known as BitBox, formerly known as “Digital Bitbox”. It is important to note that I have not audited the device, and these issues were found from a preliminary look at the device. Note that, while I intended to quote BitBox’s own descriptions of the fixes, they denied me permission to do so. However, they assure me that they will be publishing their own report which I trust will help fill in the gaps.[…]

https://saleemrashid.com/2018/11/26/breaking-into-bitbox/

see-also:

https://digitalbitbox.com/ (aka https://shiftcrypto.ch/ )

Seattle-area open source firmware presentation this December

If you’re in the Seattle area and want to see Vincent Zimmer of Intel give a recap of his presentations at the Platform Security Summit and the Open Source Firmware Conference, attend the December DC206 Meeting, the monthly Seattle-area DEF CON user group:

What: December Seattle Locksport and DC206 Meeting
When: Dec 16th (3rd Sundays), 11:00am-~4:00pm
Where: Black Lodge Research
Who: (Vincent, Noah, Zach, Dune, Panic, and the DC206 community)

Open Source IA Firmware
by
Vincent Zimmer, Intel Corp.

Provide highlights on the open source firmware ecosystem, including
details from the Platform Security Summit[1] and Open Source Firmware
Conference[2].

[1] https://www.platformsecuritysummit.com/
[2] https://osfc.io/

Vincent Zimmer @vincentzimmer is a sr. principal engineer at Intel
Corporation. He leads the UEFI Security Subteam of the UEFI Forum.

Full announcement:
https://www.dc206.org/?p=278