There’s a new SSH vulnerability, Terrapin (pdf paper), and it’s got the potential to be nasty — but only in an extremely limited circumstance. To understand the problem, we have to understand what SSH is designed to do. It replaces telnet as a tool to get a command line shell on a remote computer. Telnet send all that text in the clear, but SSH wraps it all inside a public-key encrypted tunnel. It was designed to safely negotiate an unfriendly network, which is why SSH clients are so explicit about accepting new keys, and alerting when a key has changed.

SSH uses a sequence counter to detect Man-in-the-Middle (MitM) shenanigans like packet deletion, replay, or reordering. That sequence isn’t actually included in the packet, but is used as part of the Message Authentication Check (MAC) of several encryption modes. This means that if a packet is removed from the encrypted tunnel, the MAC fails on the rest of the packets, triggering a complete connection reset. This sequence actually starts at zero, with the first unencrypted packet sent after the version banners are exchanged. In theory, this means that an attacker fiddling with packets in the pre-encryption phase will invalidate the entire connection as well. There’s just one problem.

The innovation from the Terrapin researchers is that an attacker with MitM access to the connection can insert a number of benign messages in the pre-encryption phase, and then silently drop the first number of messages in the encrypted phase. Just a little TCP sequence rewriting for any messages between, and neither the server nor client can detect the deception. It’s a really interesting trick — but what can we do with it?

For most SSH implementations, not much. The 9.6 release of OpenSSH addresses the bug, calling it cryptographically novel, but noting that the actual impact is limited to disabling some of the timing obfuscation features added to release 9.5.

There is no other discernable impact to session secrecy or session integrity.

However, for at least one other SSH server, AsyncSSH, there’s quite a bit more at stake. This Python library is both an SSH server and client, and there’s a Terrapin vulnerability in each. For an AsyncSSH client, the vulnerability allows injection of extension info messages prior to the transition to encrypted. The example given is that the client authentication algorithm can be downgraded, which doesn’t seem particularly useful.

The more notable vulnerability is when any SSH client is used to connect to an AsynchSSH server. If the attacker also has an account on that server, the victim’s connection can be routed into an attacker-controlled shell. While this does not break SSH encryption directly, it has essentially the same effect. This is not a sky-is-falling sort of vulnerability, as the prerequisite set of circumstances are very narrow for exploitation. It is definitely a unique and novel approach, and we anticipate more findings from other researchers building on the technique.

AlphV Has been Seized — and Unseized

In a hilarious saga, the FBI has played tag with AlphV over a .onion ransomware site. A TOR onion service uses a public-private key, where the public key is the .onion address, and the private key controls all the routing magic that connects a user to the service. The FBI apparently nabbed the physical server, and used that captured private key to redirect the .onion address to the takedown page.

Apparently the AlphV admins have retained control of that private key, too, as a rather cheeky message kept replacing the FBI’s notice. In the “unseized” version, a black cat presents a new .onion address. Oh, and in retribution for the slight, AlphV has rescinded their restriction against targeting hospitals and other critical infrastructure. The one cutout that remains is their reluctance to target the Commonwealth of Independent States, AKA the old Soviet Union.

Autospill

This one initially sounds pretty bad. Android apps get access to password manager credentials. But a bit deeper look might temper our distress. So first, remember that Android apps have a native view for normal operations, and also have a webview for showing web content. The problem here is that when a password manager autofills into a website in that webview, the contents are leaked back into the native app’s interface.

The threat model then, is that an untrusted app launches a website for an “Log in with” authentication flow. Your password manager detects the Facebook/Google/Microsoft site, and offers to autofill credentials. And upon autofilling, the app itself now has captured them. It’s taking a bit for Google and password manager companies to agree on exactly who’s problem this is, and if fixes are necessary. For more details, there is a PDF available.

Bits and Bytes

Hash collisions are generally a bad thing. If a hashing algorithm has any feasible chance of collision, it’s time to retire it for any serious work. But what if we only needed to collide the first 7 bytes? In use with git, for instance, SHA-256 often gets truncated to the first 7 bytes for usability sake. How hard is it to collide those? And what about adding the last 7 bytes? [David Buchanan] ran the numbers for us, and let’s just say that you really need to check all the bytes of a 256-bit hash for cryptographic robustness. With some tricks for efficiency, 128 bits of a SHA256 hash only costs $93,000 and would take about a month.

Here’s a new/old idea: Send an email, include a . , and second email with full headers. What will the receiving mail server do? In some cases, this odd email is seen as a single message, and in some cases, it’s two. In other words, you get SMTP smuggling. This is really a problem, as it tricks one email host into sending your arbitrary emails as trusted messages. Want to send a message as bill.gates(at)microsoft.com, and have the DKIM check out? Smuggle a message through the office365 servers! On the other hand, this one has already been disclosed to a bunch of vulnerable services, so you’ve probably lost your chance.

And for a bit of fun, Microsoft’s Phishing Simulator catches real Phish! That is, Microsoft now has an Attack Simulator tool that can help you send fake phishing emails, to help train users not to click on that link. [Vaisha Bernard] was giving the tool a test run, and realized that one of the bogus links was off to a non-existent confluence page, and being sent from an unregistered domain. Register both, and that phishing simulator has real teeth. Apparently [Vaisha] earned multiple bug bounties on finally get the whole problem fixed, which goes to show it pays to be curious.