Stuff for the Stash, Week 46
My weekly take on what's been noteworthy in my corner of cybersecurity
Welcome to my weekly attempt and a subjective take on what I found noteworthy in the field of cybersecurity this week. As usual, my interests go towards low-level topics, embedded and cyber-physical systems, and industries where these are prevalent.
This week we have stories about memory-safe languages, emerging cyber threats, custom modchips that do voltage glitching, software defined vehicle architectures, Linux trusted boot, smart grid privacy, software development pipeline threat modelling, packet-in-packet attacks and more !
The NSA is recommending that we should all be using more memory safe languages because, well, after a few decades of trying, we still seldom write code without memory corruption issues and that’s bad for your security posture.
Luckily, we have plenty of choices these days, with new challengers such as Go and Rust, but we shouldn’t forget languages such as C# and Java either. With some further recommendations to apply static and dynamic application security testing, use of anti-exploitation features and a clear message to still be careful, I can only agree with the recommendation. Full information sheet to be found at https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
Renault Group and Google announced they are expanding their partnership to deliver the architecture for Software Defined Vehicles based on the “Android Automotive Operating System and Google Cloud”. I’d say this is a mixed blessing. Full announcement at https://www.renaultgroup.com/wp-content/uploads/2022/11/partnership-renault-group-google_en.pdf
ENISA has released their top cyber threats most likely to emerge by 2030. I would say that many of the listed issues are already present today, though might be getting less media attention than some other areas. As usual, I’m pleased with the attention given to topics close to my personal interests so I can do nothing else than highlight those
Human error and exploited legacy systems within cyber-physical systems
Targeted attacks enhanced by smart device data
Lack of analysis and control of space-based infrastructure and objects
And maybe most surprisingly and something many should take note of I suppose, not a single mention of cloud security. Peculiar huh ?
The good people of the COSIC research group at the KULeuven university in Belgium continue their exploration and attacks against the Starlink terminals by releasing information on an attack using a custom modchip that performs voltage-based glitching. Interestingly, this is done with a Raspi 2040 chip.
More info about the project is at https://github.com/KULeuven-COSIC/Starlink-FI
A prior introduction can be read at https://www.esat.kuleuven.be/cosic/blog/dumping-and-extracting-the-spacex-starlink-user-terminal-firmware/
The main researcher has also recently given an interesting presentation at DEFCON 30 on his research, which you can watch below.
Lennart Poetering has put forward some notes on his proposed design of how the Linux kernel should be booted. An interesting read for anyone interested in Trusted Boot and its attack scenarios.
The people over at Trail of Bits published a very interesting blog post covering divergent representations of a variable in compiled programs due to compiler optimizations. Apparently, this could lead to more beneficial conditions for exploiting certain bugs.
https://blog.trailofbits.com/2022/11/10/divergent-representations-variable-overflows-c-compiler/
Someone on the interwebs was good enough to spend some of their free time scraping GitHub for repositories which contain exploits and PoCs for particular CVEs. They only found close to 8000 ! If you’re in need of a PoC, an exploit, or simply some inspiration head over to https://github.com/tg12/PoC_CVEs/blob/main/cve_links.csv
A paper was released titled “An Integrity-Focused Threat Model for Software Development Pipelines”. Find it at https://arxiv.org/abs/2211.06249
We develop a systematic threat model for a generic software development pipeline using the STRIDE framework and identify possible mitigations for each threat. The pipeline adopted as a reference comprises five stages (integration, continuous integration, infrastructure-as-code, deployment, and release), and we review vulnerabilities and attacks in all stages reported in the literature. We present a case study applying this threat model to a specific pipeline, showing that the adaptation is straightforward and produces a list of relevant threats.
A paper was released titled “Unique in the Smart Grid -The Privacy Cost of Fine-Grained Electrical Consumption Data”. Find it at https://arxiv.org/abs/2211.07205
In particular, we show that knowing 5 consecutive electric measures allows to re-identify on average more than 90% of households in our 2.5M half-hourly electric time series dataset. Moreover, uniqueness remains high even when data is severely degraded. For example, when data is rounded to the nearest 100 watts, knowing 7 consecutive electric measures allows to re-identify on average more than 40% of the households (same dataset). We also study the relationship between uniqueness and entropy, uniqueness and electric consumption, and electric consumption and temperatures, showing their strong correlation.
Andrey Konovalov released his slides, presented at the Linux Security Summit Europe, on “Sanitizing the Linux Kernel: On KASAN and other Dynamic Bug-finding Tools”. Slides are here. A summary of the talk titled “Finding bugs with sanitizers” was published at https://lwn.net/Articles/909245/
A paper was released titled “PCSPOOF: Compromising the Safety of
Time-Triggered Ethernet”. Find it at https://web.eecs.umich.edu/~barisk/public/pcspoof.pdf. An interview with the researchers covering their findings has been published by IEEE https://spectrum.ieee.org/cyberattacks.Very nice also to see the paper referring to the work on packet-in-packet attacks done by my colleagues Andrea Barisani and Daniele Bianco, titled Fully Arbitrary 802.3 Packet Injection, and presented at Blackhat back in 2013.
Designers are increasingly using mixed-criticality
networks in embedded systems to reduce size, weight, power, and
cost. Perhaps the most successful of these technologies is Time-
Triggered Ethernet (TTE), which lets critical time-triggered (TT)
traffic and non-critical best-effort (BE) traffic share the same
switches and cabling. A key aspect of TTE is that the TT part
of the system is isolated from the BE part, and thus BE devices
have no way to disrupt the operation of the TTE devices. This
isolation allows designers to: (1) use untrusted, but low cost, BE
hardware, (2) lower BE security requirements, and (3) ignore BE
devices during safety reviews and certification procedures.
We present PCSPOOF, the first attack to break TTE’s isolation
guarantees. PCSPOOF is based on two key observations. First,
it is possible for a BE device to infer private information about
the TT part of the network that can be used to craft malicious
synchronization messages. Second, by injecting electrical noise
into a TTE switch over an Ethernet cable, a BE device can trick
the switch into sending these malicious synchronization messages
to other TTE devices. Our evaluation shows that successful
attacks are possible in seconds, and that each successful attack
can cause TTE devices to lose synchronization for up to a second
and drop tens of TT messages — both of which can result in the
failure of critical systems like aircraft or automobiles. We also
show that, in a simulated spaceflight mission, PCSPOOF causes
uncontrolled maneuvers that threaten safety and mission success.
We disclosed PCSPOOF to aerospace companies using TTE, and
several are implementing mitigations from this paper.NIST released a major revision of their SP800-160 Engineering Trustworthy Secure Systems publication. To be found at https://csrc.nist.gov/publications/detail/sp/800-160/vol-1-rev-1/final
The intent of this publication is to advance systems engineering in developing trustworthy systems for contested operational environments (generally referred to as systems security engineering) and to serve as a basis for developing educational and training programs, professional certifications, and other assessment criteria.
That’s it for this week. I started publishing on Substack to make the writing easier for me, and to give more subscription options to you in case you can appreciate these summaries. Do share with colleagues, friends and family !