Canonicalization Attacks occur when a protocol that feeds data into a hash function used in a Message Authentication Code (MAC) or Digital Signature calculation fails to ensure some property that’s expected of the overall protocol.
But there’s a more interesting attack to think about, which affects the design of security token/envelope formats (PASETO, DSSE, etc.) and comes up often when folks try to extend basic notions of authenticated encryption (AE) to include additional authenticated (but unencrypted) data (thus yielding an AEAD mode).
Let’s start with a basic AE definition, then extend it to AEAD poorly, then break our extension. Afterwards, we can think about strategies for doing it better.
We performed a detailed security analysis of the encryption offered by the popular Telegram messaging platform. As a result of our analysis, we found several cryptographic weaknesses in the protocol, from technically trivial and easy to exploit to more advanced and of theoretical interest.
For most users, the immediate risk is low, but these vulnerabilities highlight that Telegram fell short of the cryptographic guarantees enjoyed by other widely deployed cryptographic protocols such as TLS. We made several suggestions to the Telegram developers that enable providing formal assurances that rule out a large class of cryptographic attacks, similarly to other, more established, cryptographic protocols.
By default, Telegram uses its bespoke MTProto protocol to secure communication between clients and its servers as a replacement for the industry-standard Transport Layer Security (TLS) protocol. While Telegram is often referred to as an “encrypted messenger”, this level of protection is the only protection offered by default: MTProto-based end-to-end encryption, which would protect communication from Telegram employees or anyone breaking into Telegram’s servers, is only optional and not available for group chats.
We thus focused our efforts on analysing whether Telegram’s MTProto offers comparable privacy to surfing the web with HTTPS.
TCC is meant to protect user data from unauthorized access, but weaknesses in its design mean that protections are easily overridden inadvertently.
Automation, by design, allows Full Disk Access to be ‘backdoored’ while also lowering the authorization barrier.
Multiple partial and full TCC bypasses are known, with at least one actively exploited in the wild.
TCC does not prevent processes reading and writing to ‘protected’ locations, a loophole that can be used to hide malware.
The continuous improvement of security solutions has forced attackers to explore alternative ways to compromise systems. The rising number of firmware attacks and ransomware attacks via VPN devices and other internet-facing systems are examples of attacks initiated outside and below the operating system layer. As these types of attacks become more common, users must look to secure even the single-purpose software that run their hardware—like routers. We have recently discovered vulnerabilities in NETGEAR DGN-2200v1 series routers that can compromise a network’s security—opening the gates for attackers to roam untethered through an entire organization.
We discovered the vulnerabilities while researching device fingerprinting in the new device discovery capabilities in Microsoft Defender for Endpoint. We noticed a very odd behavior: a device owned by a non-IT personnel was trying to access a NETGEAR DGN-2200v1 router’s management port. The communication was flagged as anomalous by machine learning models, but the communication itself was TLS-encrypted and private to protect customer privacy, so we decided to focus on the router and investigate whether it exhibited security weaknesses that can be exploited in a possible attack scenario.
Here’s a funny bug: a security researcher has found that a carefully crafted network name causes a bug in the networking stack of iOS and can completely disable your iPhone’s ability to connect to Wi-Fi.
On Twitter, Carl Schou showed that after joining a Wi-Fi network with a specific name (“%p%s%s%s%s%n”), all Wi-Fi functionality on the iPhone was disabled from that point on.
Once an iPhone or iPad joins the network with the name “%p%s%s%s%s%n”, the device fails to connect to Wi-Fi networks or use system networking features like AirDrop. The issue persists after rebooting the device (although a workaround does exist, see below).
Although Schuo does not detail exactly how he figured this out, any programmer should notice a pattern in the funky network name required to trigger the bug.
This article is about a recent vulnerability in the Linux kernel labeled CVE-2021-3609. The issue was initially reported by syzbot. The vulnerable part of the kernel was the CAN BCM networking protocol in the CAN networking subsystem ranging from kernel version 2.6.25 to 5.13-rc6. In the following, I am going to cover the vulnerability and my exploitation approach for kernel version >= 5.4 which led to successful local privilege escalation to root.
Capabilities in Linux are special attributes that can be allocated to processes, binaries, services and users and they can allow them specific privileges that are normally reserved for root-level actions, such as being able to intercept network traffic or mount/unmount file systems. If misconfigured, these could allow an attacker to elevate their privileges to root.
ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using compatible certificates, such as multi-domain or wildcard certificates. Attackers can redirect traffic from one subdomain to another, resulting in a valid TLS session. This breaks the authentication of TLS and cross-protocol attacks may be possible where the behavior of one protocol service may compromise the other at the application layer.
We evaluated the real-world attack surface of web browsers and widely-deployed Email and FTP servers in lab experiments and with internet-wide scans. We find that 1.4M web servers are generally vulnerable to cross-protocol attacks, i.e., TLS application data confusion is possible. Of these, 119k web servers can be attacked using an exploitable application server. As a countermeasure, we propose the use of the Application Layer Protocol Negotiation (ALPN) and Server Name Indication (SNI) extensions to TLS to prevent these and other cross-protocol attacks.
Although this vulnerability is very situational and can be challenging to exploit, there are some configurations that are exploitable even by a pure web attacker. Furthermore, we could only analyze a limited number of protocols, and other attack scenarios may exist. Thus, we advise that administrators review their deployments and that application developers (client and server) implement countermeasures proactively for all protocols.
Intel refers to the root cause of discarding issued µOps as Bad Speculation, and classifies this matter into two main subclasses:
Branch Misprediction: A misprediction of the direction or target of a branch by the branch predictor will squash all µOps executed within a mispeculated branch.
Machine Clear (MC): A machine clear condition will flush the entire processor pipeline and restart the execution from the last retired instruction.
After the discovery of the Spectre and Meltdown vulnerabilities, most of the transient execution attack variants found, simply built on the well-known class of branch mispredictions and the aborts of Intel TSX (which is no longer supported on recent processors).
In this work, we perform the first deep and systematic analysis of the class of transient execution based on machine clears (MC), reverse engineering the corresponding (previously unexplored) root causes such as Floating Point MC, Self-Modifying Code MC, Memory Ordering MC, and Memory Disambiguation MC.
We show these events not only originate new transient execution windows that widen the horizon for known attacks, but also yield entirely new attack primitives:
KrebsOnSecurity recently had occasion to contact the Russian Federal Security Service (FSB), the Russian equivalent of the U.S. Federal Bureau of Investigation (FBI). In the process of doing so, I encountered a small snag: The FSB’s website said in order to communicate with them securely, I needed to download and install an encryption and virtual private networking (VPN) appliance that is flagged by at least 20 antivirus products as malware.
The reason I contacted the FSB — one of the successor agencies to the Russian KGB — ironically enough had to do with security concerns raised by an infamous Russian hacker about the FSB’s own preferred method of being contacted.
KrebsOnSecurity was seeking comment from the FSB about a blog post published by Vladislav “BadB” Horohorin, a former international stolen credit card trafficker who served seven years in U.S. federal prison for his role in the theft of $9 million from RBS WorldPay in 2009. Horohorin, a citizen of Russia, Israel and Ukraine, is now back where he grew up in Ukraine, running a cybersecurity consulting business.
I’ve spent a lot of time trying to understand the attack surface of popular password managers. I think I’ve spent more time analyzing them than practically anybody else, and I think that qualifies me to have an opinion!
First, let’s get a few things out of the way. For some reason, few subjects can get heated faster than passwords. Maybe politics and religion, but that’s about it. It’s okay if you don’t like my opinion.
Second, everyone needs to be using unique passwords. You don’t have to use a password manager to do that, whatever system works for you is fine. If you want to use a notebook in a desk drawer, that’s totally acceptable.
Okay, let’s begin.
Signal provides a free, cross-platform private messenger app. Folks in all kinds of unsafe situations rely on Signal, as a highly visible and popular app which the security and privacy professional communities endorse. Journalists rely on Signal to ensure confidential communication with their sources.
What privacy guarantees does one really have though if you can’t prove the identity of who you’re communicating with?
A VMware vulnerability with a severity rating of 9.8 out of 10 is under active exploitation. At least one reliable exploit has gone public, and there have been successful attempts in the wild to compromise servers that run the vulnerable software.
The vulnerability, tracked as CVE-2021-21985, resides in the vCenter Server, a tool for managing virtualization in large data centers. A VMware advisory published last week said vCenter machines using default configurations have a bug that, in many networks, allows for the execution of malicious code when the machines are reachable on a port that is exposed to the Internet.
It’s a good idea to avoid remembering passwords – the more passwords you need to remember, the more tempting it is to re-use them. Ideally you should use a password manager like Bitwarden to store almost all of your passwords.
But of course you can’t store your Bitwarden password in Bitwarden, so it’s still necessary to memorize at least that one password. You’ll probably also need to memorize your disk encryption password and your user account password for your computer. So how do you choose these passwords to be secure and memorable?
In the process of going paperless, we recently acquired multiple reMarkable 2 epaper tablets. Among other things, the tablets will be used for taking notes about engagements. These data are highly sensitive and must be well protected. Unfortunately, by default the reMarkable offers little protection against attackers with physical access. We therefore opted to add a layer of encryption to our tablets. In this blog post we outline our journey from threat modeling to a secure, reliable and user-friendly implementation using
gocryptfs, C++, Qt and
systemd. The final result has been released on GitHub.
Today, we are sharing details around our discovery of Half-Double, a new Rowhammer technique that capitalizes on the worsening physics of some of the newer DRAM chips to alter the contents of memory.
Rowhammer is a DRAM vulnerability whereby repeated accesses to one address can tamper with the data stored at other addresses. Much like speculative execution vulnerabilities in CPUs, Rowhammer is a breach of the security guarantees made by the underlying hardware. As an electrical coupling phenomenon within the silicon itself, Rowhammer allows the potential bypass of hardware and software memory protection policies. This can allow untrusted code to break out of its sandbox and take full control of the system.
Malicious hackers have been exploiting a vulnerability in fully updated versions of macOS that allowed them to take screenshots on infected Macs without having to get permission from victims first.
The zeroday was exploited by XCSSET, a piece of malware discovered by security firm Trend Micro last August. XCSSET used what at the time were two zerodays to infect Mac developers with malware that stole browser cookies and files; injected backdoors into websites; stole information from Skype, Telegram, and other installed apps; took screenshots; and encrypted files and showed a ransom note.
RISC-V is a promising open-source architecture primarily targeted for embedded systems. Programs compiled using the RISC-V toolchain can run bare-metal on the system,and, as such, can be vulnerable to several memory corruption vulnerabilities. In this work, we present HeapSafe, a lightweight hardware assisted heap-buffer protection scheme to mitigate heap overflow and use-after-free vulnerabilities in a RISC-VSoC. The proposed scheme tags pointers associated with heap buffers with metadata indices and enforces tag propagation for commonly used pointer operations. The HeapSafe hardware is decoupled from the core and is designed as a configurable coprocessor and is responsible for validating the heap buffer accesses. Benchmark results show a 1.5X performance overhead and 1.59% area overhead, while being 22% faster than a software protection. We further implemented a HeapSafe-nb, an asynchronous validation design, which improves performance by27% over the synchronous HeapSafe.
This blog post series provides a practical step-by-step guide to using deep learning to carry out a side-channel attack – one of the most powerful cryptanalysis techniques. We are going to teach you how to use TensorFlow to recover the AES key used by the TinyAES implementation running on an ARM CPU (STM32F415) from power consumption traces.
This short post explains how code compiled for iOS can be run natively on Apple Silicon Macs.
With the introduction of Apple Silicon Macs, Apple also made it possible to run iOS apps natively on these Macs. This is fundamentally possible due to (1) iPhones and Apple Silicon Macs both using the arm64 instruction set architecture (ISA) and (2) macOS using a mostly compatible set of runtime libraries and frameworks while also providing /System/iOSSupport which contains the parts of the iOS runtime that do not exist on macOS. Due to this, it should be possible to run not just complete apps but also standalone iOS binaries or libraries on Mac. This might be interesting for a number of reasons, including:
It allows fuzzing closed-source code compiled for iOS on a Mac
It allows dynamic analysis of iOS code in a more “friendly” environment
This post explains how this can be achieved in practice. The corresponding code can be found here and allows executing arbitrary iOS binaries and library code natively on macOS. The tool assumes that SIP has been disabled and has been tested on macOS 11.2 and 11.3. With SIP enabled, certain steps will probably fail.
We originally developed this tool for fuzzing a 3rd-party iOS messaging app. While that particular project didn’t yield any interesting results, we are making the tool public as it could help lower the barrier of entry for iOS security research.