https://embedi.org/blog/remotely-compromise-devices-by-using-bugs-in-marvell-avastar-wi-fi-from-zero-knowledge-to-zero-click-rce/

In addition to the description of the specific attack, this article outlines the entire process to evaluate the given WiFI SoC and go from “knowing nothing” to a working attack. It is one of the better written guides I’ve seen.

Originally released as a talk at ZeroNights 2018.

 

Priceonomics has a great new summary of cyberattacks over time:

Why Security Breaches Just Keep Getting Bigger and More Expensive

I’d like to draw your attention to just one chart – which I’ll embed below (link may break):

One might look at this and say that firmware is virtually irrelevant. Certainly the baseline security advice is to start with the the things that are the most likely and impactful. So – if something is likely, but the impact is low, or if something is unlikely but the impact is high.. deprioritize it.

Note that the total here is far greater than 100%.. so I guess they’re saying that successful attacks often involve multiple of these categories. eg: Phishing that gets you to click on a bogus link is also a web-based attack? I guess?

But consider that:

• For certain firmware is involved in EVERY attack in the “compromised / stolen devices” category, which represents 25%.
  • If a device is compromised in this way, even if you have full disk encryption, a firmware or side-channel attack may work.
  • Even if you get it back, the device cannot be trusted any longer
• Malicious insider threats should also be considered to possibly involve firmware. What physical devices has that person touched? Ever?
• Because the totals are > 100%, it is possible that firmware is involved in some of the other types of attacks as well – though I acknowledge that the percentage is probably low. Why attack firmware when you can execute a successful phishing attack?
• General Malware – if the firmware can be updated while the OS is running (typically with admin/root privs), then malicious firmware can be installed by any regular malware that gets admin.

While the probability is STILL low, it is worth looking at numbers like this and reading between the lines a bit. Some types of protection, such as Secure Boot are worth enabling, or rather, not disabling!

Every cross fleet operation can balloon into a huge effort, such as deploying and ensuring anti-virus is up to date. So how about firmware updates? Some are now delivered with OS updates via Windows Update and or fwupd on Linux. If you can’t afford the massive amount of labor to consistently ensure that all your machines have up-to-date firmware, AT A MINIMUM, shoot an email to your purchasing department, and pressure your sales engineer that ALL future systems you purchase get firmware updates for ALL OS-updatable firmware – not just UEFI/BIOS, via the OS update mechanisms. Signed, forward-only, please.

Re: https://firmwaresecurity.com/2019/01/28/nsa-hardware-and-firmware-security-guidance-updated/

In addition to the Markdown-based documents on Github, NSA has an updated PDF on side channel attacks, mentioned in this US-CERT announcement:

https://www.us-cert.gov/ncas/current-activity/2019/02/01/NSA-Releases-Updated-Guidance-Side-Channel-Vulnerabilities

https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/CSA_Updated_Guidance_For_Vulnerabilities_Affecting_Modern_Processors_20190130.pdf?ver=2019-01-30-142631-553

PS: Re: https://firmwaresecurity.com/2019/01/28/nsa-lojax-guidance-incorrectly-still-says-secure-boot-is-a-mitigation/
the NSA updated the Lojax guidance w/r/t Secure Boot: 🙂

https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/commit/e2a0241cdee446fbd55a3249167a072e1bbcbce7

Semiconductors are the key components that drive the operation of critical electronic systems in both the commercial and military sectors. However, the security and integrity of the microelectronics that control our electronics is under increasing hardware and software-based attacks which puts large portions of our economy and national security at risk. The Indiana Innovation Institute is working on technologies which help to counter these attacks, increases resistance to counterfeiting, and has applications in nearly all electronic devices. The technologies under development by our team in trusted microelectronics have a number of applications including increasing reliability, anti-counterfeiting, anti-tamper, and hardware security.

https://news.iu.edu/stories/2019/02/iub/01-martin-swany-in3-indiana-innovation-institute.html

https://in3indiana.com/what-we-do/projects/trusted-microelectronics/

Re: https://firmwaresecurity.com/2019/01/07/ltefuzz-a-dynamic-testing-tool-for-lte-network-security/

more info:

https://sites.google.com/view/ltefuzz

 

David, who did the previous Rust UEFI patch from the previous blog post, has written a blog post about Clang, GNU-EFI, and targetting UEFI:

[…]Voilà! No need for GNU-EFI, no need to mess with separated toolchains. With LLVM you get all this through your local toolchain.[…]

https://dvdhrm.github.io/2019/01/31/goodbye-gnuefi/

Click to access intel-th-developer-manual.pdf

Re: https://firmwaresecurity.com/2019/01/28/nsa-hardware-and-firmware-security-guidance-updated/

Hmm, the NDA guidance for Lojax appears to be incorrect. It mentions Secure Boot will mitigate, but a comment from Nikolaj Schlej — and I thought also a tweet from Yuriy, but I can’t find that — and later the updated research says it does not. Guess I should submit a Pull Request to NSAcyber…

https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance

“To mitigate LoJax, ensure that UEFI Secure Boot is enabled and functioning. Standard mode is sufficient. Advanced organizations can also utilize custom mode.”

https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/

“Update, 9 October 2018: The remediation section of the white paper contained inaccurate information. Secure Boot doesn’t protect against the UEFI rootkit described in this research. We advise that you keep your UEFI firmware up-to-date and, if possible, have a processor with a hardware root of trust as is the case with Intel processors supporting Intel Boot Guard (from the Haswell family of Intel processors onwards).”

https://github.com/lijok/walk_the_redfish

FPMurphy has a new blog post on how to configure UDK to use Clang on Linux:

https://blog.fpmurphy.com/2019/01/installing-and-configuring-udk2018-clang-7-0-on-fedora-29.html

This is the sample code developed during my Msc, where I created a UEFI application capable of processing sound streams at UEFI environment.

https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility

see-also:

AudioPkg: Intel HDA UEFI driver WIP