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