This Week In Security: Terrapin, Seized Unseized, And Autospill

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.

Continue reading “This Week In Security: Terrapin, Seized Unseized, And Autospill”

FLOSS Weekly Episode 762: Spilling The Tea

Editor’s Note: We’re excited to announce that Hackaday is the new home of FLOSS Weekly, a long-running podcast about free, libre, and open-source software! The TWiT network hosted the podcast for an incredible seventeen years, but due to some changes on their end, they recently had to wind things down. They were gracious enough to let us pick up the torch, with Jonathan Bennett now taking over hosting duties.

Tune in every Wednesday for a new episode, featuring interviews with developers and project leaders, coverage of the free/libre software you use everyday (maybe without even knowing it), and the latest Open Source news.


This week Jonathan Bennett and Simon Phipps talk with Neal Gompa of Fedora, CentOS, openSUSE and more. The conversation starts off with asking Neal how he went from working on a minor project 11 years ago, to being the lead of KDE on Fedora. How does a company properly sponsor Open Source development? Neal speaks from his experience at Red Hat and other places, to give some really interesting answers.

The crew move on to what happened at Red Hat with CentOS, and why just maybe it was a good thing. Is the age of a company a good indicator of how they will treat Open Source? Is CentOS Stream the best thing to happen to Red Hat Enterprise Linux? What was it like to be at Red Hat during that time? How does a company manage the tension between sales and engineering? We cover this and more!

Continue reading “FLOSS Weekly Episode 762: Spilling The Tea”

This Week In Security: Traingate, DNS, And JMP Slides

Remember Dieselgate, the scandal where certain diesel vehicles would detect an emissions test, and run cleaner for it, “cheating” the test? Traingate may just put that one into perspective. We’ll tell the story from the beginning, but buckle up for a wild and astonishing ride. It all starts with Polish trains getting a maintenance overhaul. These trains were built by Newag, who bid on the maintenance contract, but the contract was won by another company, SPS. This sort of overhaul involves breaking each train into its components, inspecting, lubricating, etc, and putting it all back together again. The first train went through this process, was fully reassembled, and then refused to move. After exhausting all of the conventional troubleshooting measures, SPS brought in the hackers.
Continue reading “This Week In Security: Traingate, DNS, And JMP Slides”

Binary Clock Kit Blips Again

Back in 1978, the world was a bit different. There was no Raspberry Pi, no Internet, and not even an ESP32 to build projects with. And rather than order electronics kits from Tindie or Adafruit, [Dr. Francitosh] selected this binary clock with his mother from a catalog, and made the order via mail. Simpler times. The good Doctor, AKA [Greg Smith], was a young electronics tinkerer, and his mother wanted a good project-in-a-box to show off his skills. Thus, a Greymark Binary Clock was ordered and assembled. Then, sadly, the beloved clock crashed from its proud mantle position, doomed to never to blink or blip again. Or was it?
Continue reading “Binary Clock Kit Blips Again”

This Week In Security: LogoFail, National DNS Poison, And DNA

When there’s a vulnerability in a system library, we install updates, and go on with our lives. When there’s a vulnerability in a Java library, jars get rebuilt, and fixed builds slowly roll out. But what happens when there’s a vulnerability in a library used in firmware builds? And to make it even more fun, it’s not just a single vulnerability. All three major firmware vendors have problems when processing malicious images. And LogoFail isn’t limited to x86, either. UEFI Arm devices are vulnerable, too.
Continue reading “This Week In Security: LogoFail, National DNS Poison, And DNA”

This Week In Security: Owncloud, NXP, 0-Days, And Fingerprints

We’re back! And while the column took a week off for Thanksgiving, the security world didn’t. The most pressing news is an issue in Owncloud, that is already under active exploitation.

The problem is a library that can be convinced to call phpinfo() and include the results in the page response. That function reveals a lot of information about the system Owncloud is running on, including environment variables. In something like a Docker deployment, those environment variables may contain system secrets like admin username and password among others.

Now, there is a bit of a wrinkle here. There is a public exploit, and according to research done by Greynoise Labs, that exploit does not actually work against default installs. This seems to describe the active exploitation attempts, but the researcher that originally found the issue has stated that there is a non-public exploit that does work on default installs. Stay tuned for this other shoe to drop, and update your Owncloud installs if you have them. Continue reading “This Week In Security: Owncloud, NXP, 0-Days, And Fingerprints”

This Week In Security: SSH, FTP, And Reptar

It’s time to strap on our propeller beanies, because we’re going to talk crypto. The short version is that some SSH handshakes can expose enough information for a third party to obtain the host’s private signing key. That key is the one that confirms you are connecting to the SSH server you think you are, and if the key validation fails, you get a big warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

The math that makes this warning work is public-private key cryptography. The problem we’re talking about today only shows up in RSA authentication. Specifically those that use the Chinese Remainder Theorem (CRT) to quickly calculate the modulos needed to generate the cryptographic signature. If something goes wrong during that calculation, you end up with a signature that is mathematically related to the secret key in a different way than intended. The important point is that knowing this extra value *significantly* weakens the security of the secret key.

This attack has been known for quite some time, but the research has been aimed at causing the calculation fault through power vaults or even memory attacks like Rowhammer. There has also been progress on using a lattice attack against captured handshakes, to make the attack practical with less known information. The real novel element of this week’s approach (pdf) is that it has been tested against SSH.

The paper’s authors performed weekly scans of the entire IPv4 public network space, capturing the handshake from any listening SSH server, and also had 5 years of historic data to draw from. And the results are mixed. There is a Cisco SSH server string that is extremely common in the dataset, and only once did one of these machines send a miscalculated handshake. Possibly a random ram bit flip to blame. And on the other hand, the string “SSH-2.0-Zyxel SSH server” had so many bad signatures, it suggests a device that *always* sends a miscalculated signature. Continue reading “This Week In Security: SSH, FTP, And Reptar”