Category: Uncategorized

Firmware attacker -vs- defender job trends

~ hucktech ~ Leave a comment

A small observation: While searching for news on firmware, I have a variety of job searches, using various keywords, mostly scoped (due to tool limitations) to US-based jobs. I notice that most jobs related to firmware security are based around D.C. and require security clearance.

What concerns me is it seems the ratio is growing towards attackers, fewer related jobs by either device vendors or enterprises.

Granted vendors are hiring up all the firmware security researchers. But only a much smaller ratio of these kinds of jobs than for attacker jobs.

One good sign I have seen is a small rise in firmware security skills by enterprise sysadmins. Only a small number, but more than previously.

I wish some data scientist would do a study in attack/defense job ratios, without all the biases involved in my observations…

ReFirm Labs: IoT firmware security startup

~ hucktech ~ Leave a comment

“ReFirm Labs is at the forefront of IoT firmware security, vulnerability and zero-day discovery, and firmware remediation for IoT devices.”

https://www.refirmlabs.com/

http://i95business.com/2017/10/offit-kurman-represented-refirm-labs-1-5m-venture-capital-raise/

https://www.linkedin.com/pulse/iot-disasters-you-cannot-escape-terry-dunlap

Their “sister company” is Tactical  Network Solutions:

https://www.tacnetsol.com/

 

Fall UEFI Plugfest agenda

~ hucktech ~ Leave a comment

The Fall UEFI Plugfest is happening, a week of interop testing with UEFI vendors, along with some presentations. The presentation abstracts are below, see the full itenary for speaker bios.

http://www.uefi.org/events/upcoming

http://www.uefi.org/sites/default/files/resources/Agenda%20and%20Session%20Abstracts%20-%20Final_Oct%2024%202017.pdf

“Last Mile” Barriers to Removing Legacy BIOS (Intel)
While UEFI has become a dominant standard since its introduction in 2005, many use cases still rely on compatibility with PC/AT Legacy BIOS. These legacy corner cases are a barrier to completing the transition to modern firmware standards. Intel has identified maintaining compatibility as an issue for platform security and validation costs, and plans to eliminate legacy BIOS elements in our 2020 data center platforms. This session discusses “last mile” gaps for 16-bit compatibility and identifies UEFI capabilities that the industry can promote as alternatives, including HTTPS Boot, OS Recovery, and Signed Capsule Update.

UEFI Firmware – Security Concerns and Best Practices (Phoenix)
(no Abstract)

Strategies for Stronger Software SMI Security in UEFI Firmware (Insyde)
Avoid design errors and software coding pitfalls when implementing SMI handlers. Device manufacturers customize UEFI firmware using new runtime interfaces that are implemented using software SMIs. Heavy customization, tight deadlines and poor code implementation can accidentally allow malware to abuse the power of SMM. This session focuses on four common software SMI vulnerabilities and how to change your UEFI firmware and applications to avoid them.

Advances of UEFI Technologies in ARM Systems (ARM)
This session will discuss the ARM-related interfaces defined in the latest UEFI and ACPI specifications, the requirements of the UEFI and ACPI interfaces for the SBBR Specification, and the use of UEFI SCT and FWTS in the SBBR compliance test. Also, discussed will be the required UEFI interfaces for the embedded space when the separation of the device and OS development is desired.

Introduction to the Self-Certification Test (SCT) in UEFI World (Canonical and Intel)
The UEFI Test Working Group (UTWG) endorses two test suites: Firmware Test Suite (FWTS) and the UEFI Self-Certification Test (SCT). FWTS is focused on validating Linux compatibility, and is endorsed by UTWG for ACPI validation. The UEFI SCT is designed to validate firmware and driver behavior per the UEFI Specification. This session demonstrates the operation of both tools, and discusses how they use open source models to improve test quality.

Firmware Test Suite Introduction: Uses, Development, Contribution and GPL (Canonical)
Firmware Test Suite (FWTS) is the recommended ACPI 6.1 Self-Certification Test (SCT). This command line tool is easy to use and provides explanatory and informative. Its open-source nature allows developers to add new tests easily, and many code examples such as ACPI, UEFI and SMBIOS are available for references. Code contribution are appreciated and technical discussion and code reviews on the mailing list are answered by an active community. As licensed by GPL, FWTS ensures it is available and suitable to everyone who wants to use it publicly and privately.

NFC and UEFI (AMI)
NFC is a technology that has permeated many aspects of everyday life. Using NFC, you can now pay with your phone or enter secure building areas. However, the UEFI specification lacks any implementation of NFC. AMI will cover a proposed solution for NFC implementation in UEFI, how to best fit NFC into the UEFI specification, and potential use cases.

Edk2 Platforms Overview (Linaro)
For a couple of years now, the Linaro OpenPlatformPkg repository has been used to collate a number of (at least partially) open source EDK2 platform ports. However, with a now properly defined process for the TianoCore edk2-platforms and edk2-non-osi repositories, these platforms are now moving over there and OpenPlatformPkg. This session will discuss the process, the current state of things and the practicalities of working with edk2-platforms.

UEFI Manageability and REST Services (HPE and Intel)
With the increase in platform firmware complexity and capabilities, there is an increased need to standard firmware manageability is increasing. The UEFI 2.7 Specification defines REST services to provide secure solutions for managing modern platforms. This session describes enterprise configuration scenarios, discusses implementation gaps in the UEFI specification, and proposes enhancements related to vendor-specific REST services.

Alex Matrosov joins NVIDIA!!

~ hucktech ~ Leave a comment

This is great news for NVIDIA security!!

Also anyone from ARM Ltd must be quite excited to see recent career paths of ex-CHIPSEC Project members. Alex and Yuriy of Eclypsium has an ARM port of CHIPSEC, which they says they they’re going to release (when!?!). Now Alex is joining Nvidia and will also be focusing on ARM. Note to the Linaro team working on the AArch64 port of LUV-live, once CHIPSEC works on ARM, you really need to get this project active again.

I hope the CHIPSEC team, and or (ARM Ltd, Linaro, Eclypsium, or now NVIDIA) helps update the CHIPSEC Project’s release of CPython. Today it is a binary-only release for x86 and x64, in the Github source tree. It’ll need ARM versions of CPython, and hopefully make CPython build for CHIPSEC transparent, or at least sign the blobs. Actually, this points out an upstream problem to Tianocore: CHIPSEC is an example of an ISV with a UEFI app that needs CPython, and has to ship it themselves. Tianocore should consider shipping CPython binaries along with ShellPkgBin binaries.

PS: I also just noticed that their book has a nice (new?) domain name: http://bootkits.io/ (no HTTPS).

 

Intel patch for UEFI pre-memory DMA protection in PEI

~ hucktech ~ Leave a comment

Intel has submitted a V3 patch to the tianocore EDK2 project, with additional DMA protection for UEFI on Intel systems.

[PATCH V3 0/2] IntelSiliconPkg: Add Pre-Memory DMA protection in PEI

V3:
1) update the function comments of InitDmar()
2) update the function comments of SiliconInitializedPpiNotifyCallback()
3) remove duplicated BAR debug message.
4) fix the size field in the mPlatformVTdNoIgdSample structure.

V2:
Minor enhancement: Replace IsDmaProtectionEnabled() by GetDmaProtectionEnabledEngineMask(), for better code management.

V1:
This series patch adds Pre-Memory DMA protection in PEI. The purpose is to make sure when the system memory is initialized, the DMA protection takes effect immediately. The IntelVTdPmrPei driver is updated to remove the global variable and add VTD_INFO_PPI notification. The VTdInfoSample driver is updated to install the initial VTD_INFO_PPI before memory init, and add more content after memory init by reinstalling VTD_INFO_PPI. This patch is validated on one Intel Client kabylake platform.

For more info, see full patch:
https://lists.01.org/mailman/listinfo/edk2-devel

more on Infineon TPM issue

~ hucktech ~ Leave a comment

https://www.rsa.com/en-us/blog/2017-10/roca-blaming-infineon-is-the-easy-way-out

https://www.ncsc.gov.uk/guidance/roca-infineon-tpm-and-secure-element-rsa-vulnerability-guidance

https://lwn.net/Articles/736736/

https://lkml.org/lkml/2017/10/25/382

https://blog.rapid7.com/2017/10/25/roca-vulnerable-rsa-key-generation/

https://en.wikipedia.org/wiki/ROCA_vulnerability

http://www.cvedetails.com/cve/CVE-2017-15361/
http://www.securityfocus.com/bid/101484
https://www.cvedetails.com/bugtraq-bid/101484/Infineon-RSA-Library-CVE-2017-15361-Cryptographic-Security-B.html

https://secems.com/2017/10/25/vulnerability-in-code-library-permits-attackers-to-work-out-private-rsa-keys/

https://answers.microsoft.com/en-us/windows/forum/windows_10-update/windows-10-update-version-1703/f5fa72fe-3d59-45d4-a4c4-eb849774b657?auth=1

 

Google wants servers without Intel ME and UEFI

~ hucktech ~ 2 Comments

Golem has a story about the recent Google presentation at OSSEU2017:

From Google Translation of German text:

Google wants servers without Intel ME and UEFI
by Sebastian Grüner
According to the motto “Are you afraid?” a team of Google’s coreboot developers is working with colleagues to make Intel’s ME and the proprietary UEFI harmless in servers. And probably with success.[…]

Click to access Replace%20UEFI%20with%20Linux.pdf

https://www.golem.de/news/freie-linux-firmware-google-will-server-ohne-intel-me-und-uefi-1710-130840.html

https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

Ronald Minnich auf dem Open Source Summit in Prag

Maybe I missed it, but I didn’t see the video of this presentation archived.

 

AMI blog post with ‘firmware BSOD-like’ photos

~ hucktech ~ Leave a comment

AMI has a new blog post with a nice collection of firmware splash screens seen in the wild.

 

https://ami.com/en/tech-blog/aptio-and-amibios-in-interesting-places/

See-also: https://twitter.com/samkottler/status/757571758606147584

11 Myths About Platform Security

~ hucktech ~ Leave a comment

Jarvis Wenger has an interesting article in Electronic Design, listing misconceptions about hw/fw security, list below, read the article for all the details!

11 Myths About Platform Security: Greater system complexity means more areas are vulnerable to security breaches. This article examines the role hardware and software play in ensuring a secure computing platform.

1. When buying a product, such as a hypervisor, the software takes care of all additional security concerns in virtualization.
2. Security is only a concern for the OS/hypervisor/application.
3. I have taken care of my hypervisor, OS, application, and boot process, so my system is as secure as it can be.
4. A secure system is also a safe system.
5. My system isn’t connected to the outside world, so it’s secure.
6. My computer is isolated from the outside world, so I don’t need to run updates for the OS/Hypervisor/Application.
7. Only my most trusted employees have physical access, which means my system is secure.
8. My system is relatively secure and physically inaccessible, so it should be safe.
9. I’m using the latest up-to-date containers, therefore my application is safe.
10. The data on my device is encrypted, making it inaccessible.
11. Security is only a concern externally to a device.

http://www.electronicdesign.com/embedded-revolution/11-myths-about-platform-security

“Linux/Acpi.A!tr”: Linux ACPI malware?

~ hucktech ~ Leave a comment

I noticed this on an AV vendor’s site, about some Linux-centric (?) ACPI malware. Wish there was more info on it. If you have more details, please leave a Comment on this blog, thanks!

Linux/Acpi.A!tr
ID 7546097
Released Oct 26, 2017

Linux/Acpi.A!tr is classified as a trojan.

A trojan is a type of malware that performs activites without the user’s knowledge. These activities commonly include establishing remote access connections, capturing keyboard input, collecting system information, downloading/uploading files, dropping other malware into the infected system, performing denial-of-service (DoS) attacks, and running/terminating processes. The Fortinet Antivirus Analyst Team is constantly updating our descriptions. Please check the FortiGuard Encyclopedia regularly for updates.

https://www.fortiguard.com/encyclopedia/virus/7546097

MEAnalyzer v1.32.0 released

~ hucktech ~ Leave a comment

v1.32.0 includes:
Added support for CSME 11.8, 11.11 & 11.21 firmware
Added support for CSME 12 SPI FD Region structures
Added CSE Extension 22 for proper CSME 12 parsing
Added CSE Extension 14 Mod for proper DNX parsing
Added CSE Extension 5 Mod for proper Process parsing
Added CSE Extension data overflow error detection
Added CSE Extension data division error detection
Added CSE Extension data total size error detection
Improved CSE Extensions 1, 13 with CSME 12 support
Improved CSE Extension structure Revision detection
Fixed CSE unpacking crash at Key modules/regions
Fixed issues at unknown CSE Extension detection
Fixed wrong CSME 11 FIT PCH-H Z370 SKU detection

https://github.com/platomav/MEAnalyzer

 

Reptile: Linux LKM rootkit

~ hucktech ~ Leave a comment

Reptile is a LKM rootkit for evil purposes. If you are searching stuff only for study purposes, see the demonstration codes. Features:

Give root to unprivileged users
Hide files and directories
Hide files contents
Hide processes
Hide himself
Boot persistence
Heaven’s door – A ICMP/UDP port-knocking backdoor
Client to knock on heaven’s door 😀

http://www.kitploit.com/2017/10/reptile-lkm-linux-rootkit.html

https://github.com/f0rb1dd3n/Reptile

 

gdb-symbolic: symbolic execution for GDB

~ hucktech ~ Leave a comment

gdb-symbolic – symbolic execution extention for gdb

Commands
* symbolize argv Make symbolic
* memory [address][size]
* target address Set target address
* triton Run symbolic execution
* answer Print symbolic variables
* debug symbolic gdb Show debug message

https://github.com/SQLab/symgdb

Click to access d2_s1_r0.pdf

https://bananaappletw.github.io/2016/02/23/symbolic-exection-introduction.html

Chipsec v1.3.4 released

~ hucktech ~ Leave a comment

New or Updated Functionality:
* Updated support for 7th/8th generation Intel processors
* Added ability to undefine a configuration entry
* Added HAL and utilcmd for TPM Event Log
* Added utilcmd for TPM commands
* Added support for Apollo Lake
* added utilcmd to inspect PCI command/control registers

https://github.com/chipsec/chipsec/commits/master

https://github.com/chipsec/chipsec/releases/tag/v1.3.4