www.riscure.com Open in urlscan Pro
136.144.231.149  Public Scan

Form analysis
1 forms found in the DOM

GET /

<form method="get" action="/">
  <span class="search-form__label pre-title">Search</span>
  <div class="search-form__field">
    <input type="text" placeholder="I'm looking for..." name="s" class="search-form__input">
    <button type="submit" value="Search" class="search-form__submit">
      <i class="icon-search"></i>
    </button>
  </div>
</form>

Text Content

To use our site, you agree to the use of cookies and data processing according
to our privacy statement.
Close

driving your security forward

 * Get in touch
 * 

Menu
 * About Riscure
    * About Riscure
    * News
    * Events

 * Test Tools
    * All Test Tools
    * Inspector SCA
    * Inspector FI
    * True Code
    * Huracan Automotive

 * Security Services
    * Security Certification
    * Security Fitness
    * Riscure Academy
    * Secure Development Support

 * Industries
    * Automotive
    * Payment
    * Media & Multiple service operators
    * Internet of Things (IoT)
    * Semiconductor
    * All Industries

 * Knowledge Base
    * Blog
    * Publications
    * Support Portal
    * Riscure Github

 * Join Us
    * Working at Riscure
    * Careers
    * Our Team

Search

 * Home
 * Blogs
 * Security Highlight: Glitched on Earth by Humans

WRITTEN BY JASPER VAN WOUDENBERG ON 12/10/2022

Share

 * 
 * 
 * 


SECURITY HIGHLIGHT: GLITCHED ON EARTH BY HUMANS

The Black Hat conference always brings up interesting and current research
within the device security industry. Jasper van Woudenberg attended the latest
conference, where the research by Lennart Wouters caught his attention.

Lennart Wouters of COSIC studied the security of the Starlink User Terminal.
After some PCB-level reverse engineering, he found a serial port and observed
various boot loaders, U-boot, and Linux running on the device. However, there
was no obvious way to gain further access: the boot images were signed, U-boot
did not take serial input, and the development login was disabled.

These are all the standard practices to be expected from an embedded system that
has to resist logical attacks. As the title of the talk already hints at, the
question is whether it also resists fault injection attacks.

Lennart opts for voltage fault injection (VFI) first, using ChipWhisperer Lite.
This device uses the crowbar glitching technique, which momentarily shorts VCC
and ground. The downside is that it is only able to target a specific time, not
a specific location on the die. However, EMFI, laser fault, or BBI require
positioning over the chip, which presents some physical challenges for the XYZ
stage, because the PCB is very large.

With VFI, he managed to fault a shell script that determines whether a device is
in developer mode or not, giving shell access. The problem is that it had a low
success rate, and needed to fully boot (12 seconds) for each fault attempt. To
solve this, Lennart aimed the VFI at the Trusted Firmware A (TF-A) bootloader.
He found that with two glitches in BL1, he can bypass firmware signature
verification, and he could load arbitrary BL2 code.

So far, the story follows a very similar process to what we do at Riscure. Next,
Lennart took it one step further by creating Modchip – a fitted custom PCB to
inject the fault and load the attacker firmware. The Modchip can be easily
soldered to Starlink, and automates the entire FI process, giving the attacker
‘automatic root’ on their Starlink Terminal.

Another interesting note is the use of FI simulation to simulate single and
double instruction skips, based on the Unicorn Engine. This is the same approach
we utilize in Riscure FiSim. Lennart noted that although he could find double
instruction skips that caused the same effect as on the hardware, the actual
fault there was likely different. This aligns with (ongoing) Riscure internal
research, where instruction-skip simulators are compared to netlist-based
simulators.

One corollary from the research is that the TF-A BL1 is vulnerable to fault
injection. This means not only that Starlink is vulnerable, but potentially all
devices using TF-A without additional FI countermeasures. This aligns with the
TF-A documentation, which talks about FI countermeasures in software and states
“At the moment TF-A doesn’t implement such mitigations.” Interestingly, for TF-M
there is some ongoing work in hardening against FI. You can learn more about
this work here.

For more information on how to implement (software) countermeasures yourself,
more information can be found in our whitepaper Secure Application Programming
in the presence of Side Channel attacks, or contact Riscure at
inforequest@riscure.com for countermeasure validation.



FOLLOW US

 * 
 * 
 * 

Riscure Head Office

+31 (0)15 251 4090 (9:00 – 17:00 CET)
inforequest@riscure.com

Delftechpark 49
2628 XJ Delft
The Netherlands

Chamber of Commerce: 27287509
VAT: NL815984753B01

Resellers | Support portal

Riscure North America

+1 (650) 646 9979
inforequest-na@riscure.com

550 Kearny St.
Suite 330
San Francisco, CA 94108
USA

Riscure China

+86 21 5117 5435
inforcn@riscure.com

Room 2030-31
No. 989, Changle Road
Shanghai 200031
China

 

© Riscure. All rights reserved.