Enlarge (credit: Matejmo | Getty Images)

Cisco’s Talos security team is warning of a large-scale credential compromise campaign that’s indiscriminately assailing networks with login attempts aimed at gaining unauthorized access to VPN, SSH, and web application accounts.

The login attempts use both generic usernames and valid usernames targeted at specific organizations. Cisco included a list of more than 2,000 usernames and almost 100 passwords used in the attacks, along with nearly 4,000 IP addresses sending the login traffic. The IP addresses appear to originate from TOR exit nodes and other anonymizing tunnels and proxies. The attacks appear to be indiscriminate and opportunistic rather than aimed at a particular region or industry.

“Depending on the target environment, successful attacks of this type may lead to unauthorized network access, account lockouts, or denial-of-service conditions,” Talos researchers wrote Tuesday . “The traffic related to these attacks has increased with time and is likely to continue to rise.”

Read 9 remaining paragraphs | Comments

Si vous me lisez assidument, vous avez surement tout capté à la fameuse backdoor XZ découverte avec fracas la semaine dernière. Et là je viens de tomber sur un truc « rigolo » qui n’est ni plus ni moins qu’une implémentation de la technique d’exploitation de cette backdoor XZ, directement à l’intérieur d’un agent SSH.

Pour rappel, un agent SSH (comme ssh-agent) est un programme qui tourne en arrière-plan et qui garde en mémoire les clés privées déchiffrées durant votre session. Son rôle est donc de fournir ces clés aux clients SSH quand ils en ont besoin pour s’authentifier, sans que vous ayez à retaper votre phrase de passe à chaque fois.

Cet agent démoniaque s’appelle donc JiaTansSSHAgent , en hommage au cybercriminel qui a vérolé XZ, et ça implémente certaines fonctionnalités de la fameuse backdoor sshd XZ. En clair, ça vous permet de passer par cette backdoor en utilisant votre client SSH préféré.

Ce truc va donc d’abord générer sa propre clé privée ed448 avec OpenSSL puis, il faudra patcher la liblzma.so avec la clé publique ed448 correspondante. Là encore, rien de bien méchant, c’est juste un petit script Python et enfin, dernière étape, faudra patcher votre client SSH pour qu’il ignore la vérification du certificat.

Et voilà !

Une fois que vous avez fait tout ça, vous pouvez vous connecter à cœur joie avec n’importe quel mot de passe sur n’importe quel serveur qui dispose de cette faille. Bon après, faut quand même faire gaffe hein, c’est pas un truc à utiliser n’importe comment non plus. Vous devez respecter la loi , et expérimenter cela uniquement sur votre propre matériel ou avec l’autorisation de votre client si vous êtes par exemple dans le cadre d’une mission d’audit de sécurité. Tout autre utilisation vous enverra illico en prison, alors déconnez pas !

Voilà les amis, vous savez tout sur JiaTansSSHAgent maintenant. Pour en savoir plus, rendez-vous sur le repo GitHub de JiaTanSSHAgent .

Last week, the internet dodged a major nation-state attack that would have had catastrophic cybersecurity repercussions worldwide. It’s a catastrophe that didn’t happen, so it won’t get much attention—but it should. There’s an important moral to the story of the attack and its discovery : The security of the global internet depends on countless obscure pieces of software written and maintained by even more obscure unpaid, distractible, and sometimes vulnerable volunteers. It’s an untenable situation, and one that is being exploited by malicious actors. Yet precious little is being done to remedy it.

Programmers dislike doing extra work. If they can find already-written code that does what they want, they’re going to use it rather than recreate the functionality. These code repositories, called libraries, are hosted on sites like GitHub. There are libraries for everything: displaying objects in 3D, spell-checking, performing complex mathematics, managing an e-commerce shopping cart, moving files around the internet—everything. Libraries are essential to modern programming; they’re the building blocks of complex software. The modularity they provide makes software projects tractable. Everything you use contains dozens of these libraries: some commercial, some open source and freely available. They are essential to the functionality of the finished software. And to its security.

You’ve likely never heard of an open-source library called XZ Utils, but it’s on hundreds of millions of computers. It’s probably on yours. It’s certainly in whatever corporate or organizational network you use. It’s a freely available library that does data compression. It’s important, in the same way that hundreds of other similar obscure libraries are important.

Many open-source libraries, like XZ Utils, are maintained by volunteers. In the case of XZ Utils, it’s one person, named Lasse Collin. He has been in charge of XZ Utils since he wrote it in 2009. And, at least in 2022, he’s had some “ longterm mental health issues. ” (To be clear, he is not to blame in this story. This is a systems problem.)

Beginning in at least 2021, Collin was personally targeted . We don’t know by whom, but we have account names: Jia Tan, Jigar Kumar, Dennis Ens. They’re not real names. They pressured Collin to transfer control over XZ Utils. In early 2023, they succeeded. Tan spent the year slowly incorporating a backdoor into XZ Utils: disabling systems that might discover his actions, laying the groundwork, and finally adding the complete backdoor earlier this year. On March 25, Hans Jansen—another fake name—tried to push the various Unix systems to upgrade to the new version of XZ Utils.

And everyone was poised to do so. It’s a routine update. In the span of a few weeks, it would have been part of both Debian and Red Hat Linux, which run on the vast majority of servers on the internet. But on March 29, another unpaid volunteer, Andres Freund—a real person who works for Microsoft but who was doing this in his spare time—noticed something weird about how much processing the new version of XZ Utils was doing. It’s the sort of thing that could be easily overlooked, and even more easily ignored. But for whatever reason, Freund tracked down the weirdness and discovered the backdoor.

It’s a masterful piece of work . It affects the SSH remote login protocol, basically by adding a hidden piece of functionality that requires a specific key to enable. Someone with that key can use the backdoored SSH to upload and execute an arbitrary piece of code on the target machine. SSH runs as root, so that code could have done anything. Let your imagination run wild.

This isn’t something a hacker just whips up. This backdoor is the result of a years-long engineering effort. The ways the code evades detection in source form, how it lies dormant and undetectable until activated, and its immense power and flexibility give credence to the widely held assumption that a major nation-state is behind this.

If it hadn’t been discovered, it probably would have eventually ended up on every computer and server on the internet. Though it’s unclear whether the backdoor would have affected Windows and Mac, it would have worked on Linux. Remember in 2020, when Russia planted a backdoor into SolarWinds that affected 14,000 networks? That seemed like a lot, but this would have been orders of magnitude more damaging. And again, the catastrophe was averted only because a volunteer stumbled on it. And it was possible in the first place only because the first unpaid volunteer, someone who turns out to be a national security single point of failure, was personally targeted and exploited by a foreign actor.

This is no way to run critical national infrastructure. And yet, here we are. This was an attack on our software supply chain . This attack subverted software dependencies. The SolarWinds attack targeted the update process. Other attacks target system design, development, and deployment. Such attacks are becoming increasingly common and effective, and also are increasingly the weapon of choice of nation-states.

It’s impossible to count how many of these single points of failure are in our computer systems. And there’s no way to know how many of the unpaid and unappreciated maintainers of critical software libraries are vulnerable to pressure. (Again, don’t blame them. Blame the industry that is happy to exploit their unpaid labor.) Or how many more have accidentally created exploitable vulnerabilities. How many other coercion attempts are ongoing? A dozen? A hundred? It seems impossible that the XZ Utils operation was a unique instance.

Solutions are hard. Banning open source won’t work; it’s precisely because XZ Utils is open source that an engineer discovered the problem in time. Banning software libraries won’t work, either; modern software can’t function without them. For years security engineers have been pushing something called a “ software bill of materials ”: an ingredients list of sorts so that when one of these packages is compromised, network owners at least know if they’re vulnerable. The industry hates this idea and has been fighting it for years, but perhaps the tide is turning .

The fundamental problem is that tech companies dislike spending extra money even more than programmers dislike doing extra work. If there’s free software out there, they are going to use it—and they’re not going to do much in-house security testing. Easier software development equals lower costs equals more profits. The market economy rewards this sort of insecurity.

We need some sustainable ways to fund open-source projects that become de facto critical infrastructure. Public shaming can help here. The Open Source Security Foundation (OSSF), founded in 2022 after another critical vulnerability in an open-source library—Log4j—was discovered, addresses this problem . The big tech companies pledged $30 million in funding after the critical Log4j supply chain vulnerability, but they never delivered. And they are still happy to make use of all this free labor and free resources, as a recent Microsoft anecdote indicates. The companies benefiting from these freely available libraries need to actually step up, and the government can force them to.

There’s a lot of tech that could be applied to this problem, if corporations were willing to spend the money. Liabilities will help. The Cybersecurity and Infrastructure Security Agency’s (CISA’s) “secure by design” initiative will help, and CISA is finally partnering with OSSF on this problem. Certainly the security of these libraries needs to be part of any broad government cybersecurity initiative.

We got extraordinarily lucky this time, but maybe we can learn from the catastrophe that didn’t happen. Like the power grid, communications network, and transportation systems, the software supply chain is critical infrastructure , part of national security, and vulnerable to foreign attack. The U.S. government needs to recognize this as a national security problem and start treating it as such.

This essay originally appeared in Lawfare .

Aïe aïe aïe, ça sent le roussi ! Une vilaine backdoor a été dénichée dans l’utilitaire xz Utils , un outil de compression présent dans un paquet de distributions Linux. Et attention, c’est du lourd : cette saloperie est capable de contourner l’ authentification SSH et donc de permettre un accès non autorisé aux systèmes. Autant vous dire que c’est la panique générale !

La faille a été découverte par un dénommé Andres Freund, un développeur qui a flairé l’embrouille dans les versions 5.6.0 et 5.6.1 de xz Utils. Fort heureusement, ces versions n’ont pas été intégrées dans les releases stables des principales distributions. Par contre, elles se sont faufilées dans quelques bêtas, notamment Fedora 40 , Fedora Rawhide et les distributions testing, unstable et experimental de Debian . Même Arch Linux y a eu droit dans une release stable.

Bref, on l’a échappé belle mais c’était moins une. Comme l’a souligné Will Dormann, un analyste en sécu chez Analygence, si la backdoor n’avait pas été repérée à temps, ça aurait pu être une véritable catastrophe à l’échelle mondiale. Il faut dire que le petit malin qui a pondu ce code malveillant n’y est pas allé de main morte. Non content d’ouvrir une porte dérobée dans l’authentification SSH, il a pris soin de bien planquer son œuvre en l’obfusquant. Un travail de pro, il faut l’avouer.

Mais le plus dingue dans l’histoire, c’est que cette backdoor a été commitée par un certain JiaT75, l’un des deux principaux développeurs de xz Utils, qui bosse sur le projet depuis des années ! Autant dire que ça jette un sacré froid. Soit le gars a pété un plomb, soit il s’est fait méchamment compromettre son système. Quoi qu’il en soit, la pilule est dure à avaler pour la communauté.

Depuis, c’est le branle-bas de combat. Les mainteneurs de Fedora et Debian se sont empressés de retirer les versions vérolées et de revenir à une release clean de xz Utils. Et les utilisateurs sont appelés à vérifier s’ils sont affectés en utilisant un script de détection mis à dispo par Andres himself .

Mais le mal est fait et la confiance est ébranlée. Comme l’a fait remarquer un mainteneur de Fedora, ce fameux JiaT75 avait pris soin d’approcher l’équipe ces dernières semaines pour les convaincre d’intégrer la version backdoorée à Fedora 40. Un culot monstre ! Du coup, certains se demandent s’il ne faudrait pas regarder de plus près les précédentes contributions de ce développeur… Voire carrément auditer tout xz Utils, sait-on jamais.

En attendant, on ne peut que saluer le flair d’Andres qui a permis d’éviter le pire. Mais cet épisode laisse un goût amer et rappelle cruellement que la sécurité est l’affaire de tous, y compris au sein des projets open source.

Espérons que cette mésaventure servira de piqûre de rappel parce que mine de rien, on parle quand même du système qui fait tourner une bonne partie d’Internet et des infrastructures critiques.

Source

Enlarge (credit: Getty Images)

Roughly 11 million Internet-exposed servers remain susceptible to a recently discovered vulnerability that allows attackers with a foothold inside affected networks. Once they're in, attackers compromise the integrity of SSH sessions that form the lynchpin for admins to securely connect to computers inside the cloud and other sensitive environments.

Terrapin, as the vulnerability has been named, came to light two weeks ago in a research paper published by academic researchers. Tracked as CVE-2023-48795, the attack the researchers devised works when attackers have an adversary-in-the-middle attack (also abbreviated as AitM and known as man-in-the-middle or MitM), such as when they’re positioned on the same local network and can secretly intercept communications and assume the identity of both the recipient and the sender.

In those instances, Terrapin allows attackers to alter or corrupt information transmitted in the SSH data stream during the handshake—the earliest connection stage, when the two parties negotiate the encryption parameters they will use to establish a secure connection. As such, Terrapin represents the first practical cryptographic attack targeting the integrity of the SSH protocol itself. It works by targeting BPP ( Binary Packet Protocol), which is designed to ensure AitMs can’t add or drop messages exchanged during the handshake. This prefix truncation attack works when implementations support either the "ChaCha20-Poly1305" or "CBC with Encrypt-then-MAC," cipher modes, which, at the time the paper was published, was found in 77 percent of SSH servers.

Read 8 remaining paragraphs | Comments

Si vous voulez traverser des firewalls comme la banane magique traverse les murs, ou si vous voulez exposer à l’extérieur de votre réseau, l’un de vos services web ou projet de dev quelconque, il vous faut la même chose qu’El Chapo, à savoir un bon tunnel !

Et pas n’importe lequel : un tunnel HTTP / Socks !

Et pour ça, je vous présente aujourd’hui Chisel : un tunnel TCP/UDP, écrit en Go, rapide et sécurisé via SSH et fonctionnant au travers de HTTP. Vous pouvez donc l’utiliser pour passer à travers un firewall, pour accéder à des services à vous qui ne sont pas disponibles via le web, ou l’utiliser dans vos missions de pentest .

Pour faire un test rapide, vous pouvez lancer Chisel sur un serveur équipé de Docker comme ceci :

docker run --name chisel -p 9312:9312 -d --restart always jpillora/chisel server -p 9312 --socks5

Le socks5 permet d’y accéder en websockets quand les proxys HTTP ne sont pas supportés par vos outils. Ensuite, il faut installer Chisel également côté client. Vous pouvez donc l’installer avec la commande suivante (ou en récupérant le binaire ici ) :

curl https://i.jpillora.com/chisel! | bash

Une fois que c’est fait, y’a plus qu’à appeler Chisel en mode client comme ceci en remplaçant IP_SERVER par l’adresse IP de votre machine qui héberge Chisel lancé en mode serveur :

chisel client -v IP_SERVER:9312 socks

Ensuite, le tunnel sécurisé va s’établir et y’a plus qu’à configurer vos outils, par exemple votre navigateur pour passer à travers votre serveur et accéder par exemple à tous vos services dispo sur votre réseau local distant.

Mettez 127.0.0.1 et le port 1080 comme serveur Socks et le tour est joué !

À découvrir ici

Et en bonus, une vidéo grâce aux Patreons qui me soutiennent !

Enlarge / Terrapin is coming for your data. (credit: Aurich Lawson | Getty Images)

Sometime around the start of 1995, an unknown person planted a password sniffer on the network backbone of Finland’s Helsinki University of Technology (now known as Aalto University). Once in place, this piece of dedicated hardware surreptitiously inhaled thousands of user names and passwords before it was finally discovered. Some of the credentials belonged to employees of a company run by Tatu Ylönen, who was also a database researcher at the university.

The event proved to be seminal, not just for Ylönen's company but for the entire world. Until that point, people like Ylönen connected to networks using tools which implemented protocols such as Telnet, rlogin, rcp, and rsh. All of these transmitted passwords (and all other data) as plaintext, providing an endless stream of valuable information to sniffers. Ylönen, who at the time knew little about implementing strong cryptography in code, set out to develop the Secure Shell Protocol (SSH) in early 1995, about three months after the discovery of the password sniffer.

As one of the first network tools to route traffic through an impregnable tunnel fortified with a still-esoteric feature known as "public key encryption," SSH quickly caught on around the world. Besides its unprecedented security guarantees, SSH was easy to install on a wide array of operating systems, including the myriad ones that powered the devices administrators used—and the servers those devices connected to remotely. SSH also supported X11 forwarding , which allowed users to run graphical applications on a remote server.

Read 29 remaining paragraphs | Comments

Enlarge (credit: Getty Images)

For the first time, researchers have demonstrated that a large portion of cryptographic keys used to protect data in computer-to-server SSH traffic are vulnerable to complete compromise when naturally occurring computational errors occur while the connection is being established.

Underscoring the importance of their discovery, the researchers used their findings to calculate the private portion of almost 200 unique SSH keys they observed in public Internet scans taken over the past seven years. The researchers suspect keys used in IPsec connections could suffer the same fate. SSH is the cryptographic protocol used in secure shell connections that allows computers to remotely access servers, usually in security-sensitive enterprise environments. IPsec is a protocol used by virtual private networks that route traffic through an encrypted tunnel.

The vulnerability occurs when there are errors during the signature generation that takes place when a client and server are establishing a connection. It affects only keys using the RSA cryptographic algorithm, which the researchers found in roughly a third of the SSH signatures they examined. That translates to roughly 1 billion signatures out of the 3.2 billion signatures examined. Of the roughly 1 billion RSA signatures, about one in a million exposed the private key of the host.

Read 15 remaining paragraphs | Comments

Connaissez-vous quicssh ?

Eh bien, c’est un proxy QUIC qui promet de révolutionner notre façon de se connecter à un serveur SSH.

Pour ceux qui ne le savent pas, QUIC est un protocole de transport qui vise à améliorer la vitesse des connexions et la sécurité sur Internet. Pour les plus anciens, ça vous rappeler peut être l’époque où vous avez découvert le TCP/IP… lol

L’architecture standard d’une connexion SSH fonctionne comme ceci :

Avec quicssh, pas besoin de modifier le client ou le serveur puisque tout est géré par le proxy QUIC. Ainsi, pour utiliser quicssh, il suffit d’exécuter les commandes client et serveur avec les options qui vont bien et votre connexion SSH transitera par QUIC comme ceci :

Pour l’installer, entrez la commande suivante :

go get -u moul.io/quicssh

Voilà, c’est aussi simple que ça ! Après pour le reste, je vous invite à lire la doc.

La différence de vitesse entre un client SSH traditionnel et Quicssh est assez remarquable. Je vous invite à faire vos propres tests, mais attention, Quicssh est un projet relativement jeune, donc attendez-vous à quelques bugs, mais aussi à le voir s’améliorer dans les semaines qui viennent…

Source