USB Type-C to Become More Secure With Authentication Standard

https://www.usb.org/node/1899

The security of USB-based connections and devices is taking a step forward, with the official launch of the USB Type-C Authentication Program on Jan. 2[…]

USB Type-C to Become More Secure With Authentication Standard

 

Chris Rohlf: Cross DSO CFI – LLVM and Android

https://twitter.com/chrisrohlf/status/1080233428660953088

Control Flow Integrity is an exploit mitigation that helps raise the cost of writing reliable exploits for memory safety vulnerabilities. There are various CFI schemes available today, and most are quite well documented and understood. One of the important areas where CFI can be improved is protecting indirect calls across DSO (Dynamic Shared Object) boundaries. This is a difficult problem to solve as only the library itself can validate call targets and consumers of the library may be compiled and linked against the library long after it was built. This requires a low level ABI compatability between the caller and the callee. The LLVM project has documented their design for this here. The remainder of this post looks at that design, it’s drawbacks, and then briefly explores how the Android PIE Bionic linker implements it.[…]

http://struct.github.io/cross_dso_cfi.html

SedNit, CCC, Kaspersky and ESET

Re: https://firmwaresecurity.com/2018/09/27/apt28-malware-lojax-uses-uefi-rootkit/ and https://firmwaresecurity.com/2018/08/05/bluehat-v18-first-strontium-uefi-rootkit-unveiled/

Sednit UEFI malware is back in the news, because of the recent CCC video, some are hearing about it for the first time, and because Kaspersky Lab is tweeting about it, confusing people that the news came from Kaspersky instead of ESET. Instead, I wish Kaspersky’s GReAT team would be giving some new news about their UEFI research, as hinted from an upcoming BlueHat Israel talk:

[..]For the past year, Kaspersky’s Global Research and Analysis Team (GReAT) extracted and processed thousands of UEFI dumps, applying anomaly analysis and code similarity techniques in order to find the “things that lurk in the shadows”[…]

Costin Raiu, Kaspersky Lab: The Things That Lurk in the Shadows

https://twitter.com/hatr/status/1080103152811155456

 

Costin Raiu, Kaspersky Lab: The Things That Lurk in the Shadows

BlueHat Israel has multiple interesting presentations, including this one, one on AMDFlaws, bunnie on supply chain security, and more:

The Things That Lurk in the Shadows
Costin Raiu, Kaspersky Lab / Wednesday, Feb 6, 12:30-1:00 PM

Looking at the discussions and development of sophisticated attack techniques, it is immediately obvious there is significant gap between the theory and in-the-wild observations. One can easily come up with a list of techniques which have been demonstrated in the past, however, they are not very popular findings across APT researchers. It is especially hard to believe that sophisticated adversaries with huge budgets haven’t been able to implement techniques presented at major conferences 4-5 years ago, right? So, what is missing nowadays from all big APT research announcements?

Here are a few likely culprits:

Virtualization / hypervisor malware – although the infamous Blue Pill was discussed as far back as 2006, we haven’t seen any ItW attacks leveraging this
SMM malware – although Dmytro Oleksiuk aka Cr4sh developed an SMM backdoor as far back as 2015, this is something yet to be seen in real world attacks
UEFI malware – the hacking of HackingTeam revealed that a UEFI persistence module has been available since at least 2014, but we have still to observe real world UEFI malware (with the exception weaponized Absolute Computrace implants)
Malware for the Intel ME

In this talk we will look at the places which have been neglected in terms of APT research with a focus on UEFI. For the past year, Kaspersky’s Global Research and Analysis Team (GReAT) extracted and processed thousands of UEFI dumps, applying anomaly analysis and code similarity techniques in order to find the “things that lurk in the shadows”.

https://www.bluehatil.com/abstracts

 

P1kachu: A tour of automotive systems from 20 years ago

[…]Most of this is now available on Github, meaning the code that I use to query information for the IVI, the code used to dump the firwmare, and the code used to modify the VSS signal. I won’t publish the firmware dump for legal reasons (I’m not 100% sure about Japan’s position, but let’s be safe).[…]

https://p1kachu.pluggi.fr/project/automotive/2018/12/28/subaru-ssm1/

https://github.com/P1kachu/ssm1-gc8

OpenSource.com: Troubleshooting hardware problems in Linux

[…]The following tips should make it quicker and easier to troubleshoot hardware in Linux. Many different things can cause problems with Linux hardware; before you start trying to diagnose them, it’s smart to learn about the most common issues and where you’re most likely to find them.[…]

https://twitter.com/opensourceway/status/1079953868765704193

https://opensource.com/article/18/12/troubleshooting-hardware-problems-linux

HackInTheBox Dubai 2018: videos online

Hack In The Box Security Conference

Alternatives for SMM usage in Intel Platforms

2019 OCP Global Summit:
Case Study: Alternatives for SMM usage in Intel Platforms
Sarathy Jayakumar, Principal Engineer – Firmware, Intel Corporation

The broadcast System Management Mode (SMM) model has been used for many years to manage priority system events but has a number of disadvantages. Overuse of System Management Interrupts (SMI) results in performance degradation, increases latency with higher core counts, and introduces potential race conditions. SMM is also difficult to debug and has access to system resources outside of the OS environment, which makes it target for firmware exploits. This session expands on Intel’s initiative to reduce SMM footprint and provide alternatives for handling runtime platform events. Intel described SMI reduction methods based on Protected Runtime Mechanism (PRM), UEFI Capsule, and the Baseboard Management Controller (BMC) at the 2018 OCP Regional Summit. The presentation features a case study and demonstration using Intel® Xeon® Scalable Processors with EDK II firmware.

https://2019ocpglobalsummit.sched.com/event/Jin2/case-study-alternatives-for-smm-usage-in-intel-platforms

https://www.opencompute.org/summit/global-summit

 

NASM-UEFI: UEFI sample application built in NASM

OS Development on Windows – Part 1: Building a UEFI Application in NASM

This is a series of articles on developing your own operating system. We will be focusing on modern techniques, like UEFI booting and 64-bit assembly, and everything will be created from scratch. I will be going step-by-step, explaining every tool we use and every line of code, so that you have a thorough understanding of the process. You should be able to copy-paste these steps and get the same results I am describing. In addition, we will be doing this on Windows and using the tools available on this platform only. OS development is almost exclusively done on UNIX-like systems because the tools are more readily available and documented. I hope to show you how easy this is to do on Windows too.[…]

https://github.com/BrianOtto/nasm-uefi

https://hackerpulp.com/os/os-development-windows-1-building-uefi-applications-nasm/

UEFI

MicroWiki: collaboratively documents microscope techniques and other info

This wiki collaboratively documents microscope techniques and other information. Its a spin off from siliconpr0n where its primary focus was to help maintain semiconductor microscopes. Unlike generic resources like Wikipedia, this wiki has a high focus on practical aspects, like info on maintaining specific microscope models.

http://microwiki.org/wiki/index.php/Main_Page

http://siliconpr0n.org/

353C videos online or streaming soon…

Lots of stuff is happening at CCC…

https://streaming.media.ccc.de/35c3/

PANDA-VM’s LAVA 2.0 released

LAVA (Large-scale Automated Vulnerability Addition) 2.0 is out. This is the PANDA (Platform for Architecture-Neutral Dynamic Analysis) VM LAVA, not the Linaro CI LAVA…

https://github.com/panda-re/lava

build-anywhere: Create highly portable ELF binaries using the build-anywhere toolchain

This post describes the basic requirements for compiling highly portable ELF binaries. Essentially using a newer Linux distro like Ubuntu 18.10 to build complex projects that run on older distros like CentOS 6. The details are limited to C/C++ projects and to x86_64 architectures. The low-level solution is to use a C++ runtime that requires only glibc 2.13+ runtime linkage and link all third-party libraries as well as the compiler runtime and C++ implementation statically. Do not make a “fully static” binary. You will most likely find a glibc newer than 2.13 on every Linux distribution released since 2011. The high-level solution is to use the build-anywhere scripts to build a easy-to-use toolchain and set compiler flags.[…]

https://github.com/theopolis/build-anywhere

https://casualhacking.io/blog/2018/12/25/create-highly-portable-elf-binaries-using-the-build-anywhere-toolchain