Google’s Titan Security Key is a FIDO universal 2nd-factor (U2F) hardware device that became available since July 2018.

Unfortunately, the security key is susceptible to side-channel attacks observing the local electromagnetic radiations of its secure element — an NXP A700x chip which is now discontinued — during an ECDSA signing operation [RLMI21].

The side-channel attack can clone the secret key in a Titan Security Key.

Watch the USENIX Security ’21 presentation on the side-channel attack:

The standard countermeasures are those that apply to CWE-1300 “Improper Protection of Physical Side Channels” and its parent weakness CWE-203 “Observable Discrepancy”.

CWE-1300:

• Apply blinding or masking techniques to implementations of cryptographic algorithms.
• Add shielding or tamper-resistant protections to the device to increase the difficulty of obtaining measurements of the side channel.

CWE-203:

• Compartmentalise the system to have “safe” areas where trust boundaries can be unambiguously drawn.

  Constrain sensitive data to within trust boundaries.

• Ensure that appropriate compartmentalisation is built into the system design, and the compartmentalisation allows for and reinforces privilege separation functionality.

  Apply the principle of least privilege to decide the appropriate conditions to use or drop privileges.

• Ensure that error messages only contain minimal details that are useful to the intended audience and no one else.

  The messages should achieve balance between being too cryptic (which can confuse users) and being too detailed (which may reveal more than intended).

  The messages should not reveal the methods used to determine the error because this information can enable attackers to refine or optimise their original attack, thereby increasing their chances of success.

• If errors must be captured in some detail, record them in log messages not accessible by attackers.

  Highly sensitive information such as passwords should never be saved to log files.

• Avoid inconsistent messaging that might unintentionally tip off an attacker about internal state, such as whether a user account exists or not.

The GhostTouch attack [WMY+22] generates electromagnetic interference (EMI) signals on the scan-driving-based capacitive touchscreen of a smartphone, which result in “ghostly” touches on the touchscreen; see Fig. 1.

The EMI signals can be generated, for example, using ChipSHOUTER.

These ghostly touches enable the attacker to actuate unauthorised taps and swipes on the victim’s touchscreen.

Watch the authors’ presentation at USENIX Security ’22:

Product specification should include expectations for how the product will perform when it exceeds physical and environmental boundary conditions, e.g., by shutting down.

Where possible, include independent components that can detect excess environmental conditions and are capable of shutting down the product.

Where possible, use shielding or other materials that can increase the adversary’s workload and reduce the likelihood of being able to successfully trigger a security-related failure.

A long list of mitigation measures exist, so only a few are mentioned here:

• Use a safe programming language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

  • For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows.
  • Other languages, such as Ada and C# (see Example 3), typically provide overflow protection, but the protection can be disabled by the programmer.
  • Nevertheless, a language’s interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
• Use a vetted library or framework that is not vulnerable to CWE-787, e.g., Intel’s Safe String Library, and Microsoft’s Strsafe.h library. 👈 These libraries provide safer versions of overflow-prone string-handling functions.
• Use compilers or compiler extensions that support automatic detection of buffer overflows, e.g., Microsoft Visual Studio with its buffer security check (/GS) flag, the FORTIFY_SOURCE macro on Red Hat Linux platforms, GCC with a range of stack protection flags (that evolved from StackGuard and ProPolice).

Read about more measures here.

Using the unsafe keyword, we can write code involving pointers in C#, e.g.,

// compile with: -unsafe
class UnsafeTest
{
    unsafe static void Main()
    {
        int *p; int i = 0;
        p = &i;
        p[2] = 1;
        // Console.WriteLine(p[2]);
    }
}

Enabling compilation of unsafe code in Visual Studio as per Fig. 1, the code above can be compiled.

Once compiled and run, the code above will not trigger any runtime error, unless the line writing p[2] to the console is uncommented.

Question: What runtime error would the Console.WriteLine statement in the code above trigger?

The vulnerability CVE-2022-20916 caused the web-based management interface of Cisco IoT Control Center to allow an unauthenticated, remote attacker to conduct an XSS attack against a user of the interface.

The vulnerability was due to absence of proper validation of user-supplied input.

A long list of mitigation measures exist, so only a few are mentioned here:

• For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters (e.g., the symbols “<” and “>”).
• Use a vetted library or framework implementing defences against XSS, e.g., Microsoft’s Anti-XSS API, the OWASP Enterprise Security API, and Apache Wicket (for Java-based web applications).
• For any security checks that are performed on the client side, duplicate these checks on the server side, because attackers can bypass client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely (e.g., using the Web Developer Tools in Firefox).

Read about more measures here and also consult the OWASP Cross Site Scripting Prevention Cheat Sheet.

The infamous vulnerability Log4Shell (CVE-2021-44228) that occupied headlines for months in 2022 cannot be a better example.

Watch an explanation of Log4Shell on YouTube:

Avoid adding user-controlled data into an expression interpreter.

If user-controlled data must be added to an expression interpreter, one or more of the following should be performed:

• Ensure no user input will be evaluated as an expression.
• Encode every user input in such a way that it is never evaluated as an expression.

By default, disable the processing of EL expressions. In JSP, set the attribute isELIgnored for a page to true.