If you know a bit about public key cryptography, you probably know that you don’t directly encrypt a message with a public key encryption algorithm like RSA. This is for many reasons, one of which being that it is incredibly slow. Instead you do what’s called hybrid encryption: first you generate a random AES key (*) and encrypt the message with that (using a suitable authenticated encryption mode), then you encrypt the AES key with the RSA public key. The recipient uses their RSA private key to decrypt the AES key and then uses that to decrypt the rest of the message. This is much faster than trying to encrypt a large message directly with RSA, so pretty much all sane implementations of RSA encryption do this.
But there’s a problem with this approach. An AES key is at most only 32 bytes long, while RSA wants to encrypt things that are approximately the same size as the modulus – i.e., 256 bytes for 2048-bit RSA keys, 384 bytes for 3072-bit keys, and so on. To make this work, we have to add some padding to the AES key until it is the right size. This sounds simple enough, but you may be surprised to find out that padding is one of the most dangerous things you can do in cryptography:
One of the best things about NixOS is the fact that it’s so easy to do configuration management using it. The Nix store (where all your packages live) has a huge flaw for secret management though: everything in the Nix store is globally readable. This means that anyone logged into or running code on the system could read any secret in the Nix store without any limits. This is sub-optimal if your goal is to keep secret values secret. There have been a few approaches to this over the years, but I want to describe how I’m doing it. Here are my goals and implementation for this setup and how a few other secret management strategies don’t quite pan out.
At a high level I have these goals:
It should be trivial to declare new secrets
Secrets should never be globally readable in any useful form
If I restart the machine, I should not need to take manual human action to ensure all of the services come back online
GPG should be avoided at all costs
As a side goal being able to roll back secret changes would also be nice.
The two biggest tools that offer a way to help with secret management on NixOS that come to mind are NixOps and Morph.
Google’s Project Zero has exposed a sophisticated watering-hole attack targeting both Windows and Android:
Some of the exploits were zero-days, meaning they targeted vulnerabilities that at the time were unknown to Google, Microsoft, and most outside researchers (both companies have since patched the security flaws). The hackers delivered the exploits through watering-hole attacks, which compromise sites frequented by the targets of interest and lace the sites with code that installs malware on visitors’ devices. The boobytrapped sites made use of two exploit servers, one for Windows users and the other for users of Android
The use of zero-days and complex infrastructure isn’t in itself a sign of sophistication, but it does show above-average skill by a professional team of hackers. Combined with the robustness of the attack code — which chained together multiple exploits in an efficient manner — the campaign demonstrates it was carried out by a “highly sophisticated actor.”
The modularity of the payloads, the interchangeable exploit chains, and the logging, targeting, and maturity of the operation also set the campaign apart, the researcher said.
No attribution was made, but the list of countries likely to be behind this isn’t very large. If you were to ask me to guess based on available information, I would guess it was the US — specifically, the NSA. It shows a care and precision that it’s known for. But I have no actual evidence for that guess.
All the vulnerabilities were fixed by last April.
Another example, for the curious. This one hosts a web server entirely in userspace. All the kernel sees are incoming and outgoing encrypted WireGuard UDP packets.
MTProto 2.0is a suite of cryptographic protocols for instant messaging at the core of the popular Telegram messenger application, which is currently used by more than 400 millions of people.In this paper we analyse MTProto 2.0 using ProVerif, a symbolic cryptographic protocol verifier based on the Dolev-Yao model. In particular, we provide a fully automated proof of the soundness of MTProto 2.0’s authentication, normal chat, end-to-end encrypted chat, and re-keying mechanisms with respect to several security properties, including authentication, integrity, confidentiality and perfect forward secrecy. To prove these results we proceed in a modular way: each protocol is examined in isolation, relying only on the guarantees provided by the previous ones and the robustness of the basic cryptographic primitives.Our research proves the formal correctness of MTProto 2.0, and it can serve as a reference for implementation and analysis of clients and servers. Moreover, we isolate the aspects of cryptographic primitives that require further investigation, in order to deem this protocol suite definitely secure.
Web browsers are inherently trusted by users. They are trained to trust websites which “have a padlock in the address bar” and that “have the correct name”, This trust leads to users feeling comfortable entering their sensitive data into these websites. From an attackers stand point this trust is an amazing thing, as once you have compromised a users workstation there is a process (with close to zero protections) handling a relatively large amount of sensitive data while being used a great deal by a user. Throw in password managers with browser extensions and you have a natural target for red teams. So naturally when I found myself with some time to spend on a research project, I decided to spend it abusing this trust!
This is a tale of the intersection between thermal physics, cosmology, and a tiny amount of computer science to answer a seemingly innocuous question: “How strong does a password need to be for it to be physically impossible to brute-force, ever?”
During 2017 I participated in many ICO, and I had to manage many files containing private keys in various forms. Then I thought I needed a secrets manager that was able to manage files. In 2018 and 2019, I worked with Tron Foundation, and I was swamped building the developers’ tools. Last spring, I finally had time to focus, and I wrote Secrez (https://github.com/secrez/secrez), a CLI secrets manager that solves many issues with traditional password managers. I build it for myself, and I have no intention to transform it into a company. Still, any opinion, critic, or suggestion is very welcome. Let me know what you think. Thanks.
This is the story of a bug that was discovered and fixed in Telegram’s self-rolled cryptographic protocol about sever years ago. The bug didn’t get any press, and no one seems to know about it, probably because it was only published in Russian.
To this day, it’s the most backdoor-looking bug I’ve ever seen.
OpenSSL is one of the most crucial library on a Unix system: it performs cryptographic functions and it provides Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols to applications.
According to the Arch Linux OpenSSL package, 355 packages, out of the 11523 available, depend on it. You can find it installed on any Unix system (and on Windows too!).
It started in 1998 as a fork of SSLeay and it has been in development since. Two full-time developers work on it, as well as many volunteers.
Fast forward to 2014: a CVE had been issued regarding a high risk vulnerability found in OpenSSL. It has been given the name Heartbleed, because it has been found in the TLS/DTLS heartbeat extension (RFC6520). This vulnerability allowed attackers to steal sensitive data, such as secret keys, user names and passwords.
All the community turned to the OpenSSL project, weighting its implementation and security policy. Heartbleed have been promptly fixed, but another vulnerability there could be new vulnerabilities in the future, if security was not properly prioritized during development.
At this point, OpenBSD’s folks forked OpenSSL and started a new project: LibreSSL. It primary goals were to modernize the codebase and to improve its security. This new project hasn’t been adopted by big distributions such Ubuntu and Arch Linux; instead smaller distributions (at that time) replaced OpenSSL with LibreSSL on their default configuration, such as Alpine and Void.
In the last years, LibreSSL have seen a decline in its usage. Alpine switched back to OpenSSL (link to the thread). Many people and distributions are considering doing the same, since OpenSSL got the improvement that LibreSSL aimed for. And it’s still the de facto standard cryptographic library on Unix.
Wireless networks are a key component of the telecommunications infrastructure in our society, and wireless services become increasingly important as the applications of wireless devices have penetrated every aspect of our lives. Although wireless technologies have significantly advanced in the past decades, most wireless networks are still vulnerable to radio jamming attacks due to the openness nature of wireless channels, and the progress in the design of jamming-resistant wireless networking systems remains limited. This stagnation can be attributed to the lack of practical physical-layer wireless technologies that can efficiently decode data packets in the presence of jamming attacks. This article surveys existing jamming attacks and anti-jamming strategies in wireless local area networks (WLANs), cellular networks, cognitive radio networks (CRNs), ZigBee networks, Bluetooth networks, vehicular networks, LoRa networks, RFID networks, and GPS system, with the objective of offering a comprehensive knowledge landscape of existing jamming/anti-jamming strategies and stimulating more research efforts to secure wireless networks against jamming attacks. Different from prior survey papers, this article conducts a comprehensive, in-depth review on jamming and anti-jamming strategies, casting insights on the design of jamming-resilient wireless networking systems. An outlook on promising antijamming techniques is offered at the end of this article to delineate important research directions.
The NSA has just declassified and released a redacted version of Military Cryptanalytics, Part III, by Lambros D. Callimahos, October 1977.
Parts I and II, by Lambros D. Callimahos and William F. Friedman, were released decades ago — I believe repeatedly, in increasingly unredacted form — and published by the late Wayne Griswold Barker’s Agean Park Press. I own them in hardcover.
Like Parts I and II, Part III is primarily concerned with pre-computer ciphers. At this point, the document only has historical interest. If there is any lesson for today, it’s that modern cryptanalysis is possible primarily because people make mistakes
The monograph a while to become public. The cover page says that the initial FOIA request was made in July 2012: eight and a half years ago.
And there’s more books to come.
This first goal of this blog post is to serve as a comprehensive reference of Samsung RKP’s inner workings. It enables anyone to start poking at this obscure code that is executing at a high privilege level on their device. Our explanations are often accompanied by snippets of decompiled code that you can feel free to skip over.
The second goal, and maybe of interest to more people, is to reveal a now-fixed vulnerability that allows getting code execution at EL2 in Samsung RKP. It is a good example of a simple mistake that compromises platform security as the exploit consists of a single call that allows getting hypervisor memory writable at EL1.
In the first part, we will talk briefly about Samsung’s kernel mitigations (that would probably deserve a blog post of their own). In the second part, we will explain how to get your hand on the RKP binary for your device.
In the third part, we will start taking apart the hypervisor framework that supports RKP on the Exynos devices, before digging into the internals of RKP in the fourth part. We will detail how it is started, how it processes the kernel pages tables, how it protects sensitive data structures, and finally how it enables the kernel mitigations.
In the fifth and last part, we will reveal the vulnerability, the one-liner exploit and take a look at the patch.
This blog article uses the fantastic research from the authors of uncaptcha2 repository. The original scientific uncaptcha paper proposes a method to solves Google’s Audio reCAPTCHA with Google’s own Speech-to-Text API.
Yes you read that correctly: It is possible to solve the Audio version of reCAPTCHA v2 with Google’s own Speech-to-Text API.
Even worse: reCAPTCHA v2 is still used in the new reCAPTCHA v3 as a fall-back mechanism.
Static engines became a standard in automatic detection for large enterprises thanks to their accurate and quick detection. When looking at detection of email attacks on enterprise organizations, they make 91% of all cyber attack attempts. If an attacker can find a way to infiltrate the organization’s defenses, the organization will become compromised the potential damage can be of millions of dollars.
Today, most email file attachments are documents, such as Microsoft Office Word or Excel documents and more (docx, xlsx, xlsm, etc…). Most new Microsoft Office files have a special structure but in reality they are just a ZIP compressed file containing the document media structure and text.
Because all of these files are candidates for attack vectors on organizations, detection engines must be able to parse these files correctly to detect exploitation attempts and attacks on enterprises.
In this blog post I will cover ways to exploit security vendors static detection engines, focusing on ZIP file format, the ways it is parsed, how can different parsers fail to detect malicious contents, and the ways attackers can potentially bypass detection engines and infiltrate the organization. Finally, I will provide an in the wild example of attack exploiting such techniques.