SSH tunneling can serve two purposes. One is a point-to-point secure tunnel between two machines (e.g., for Syncthing purposes), and another is to make use of a port you have available when you don’t control the firewall.

Full system compromise possible by peppering servers with thousands of connection requests. //

The severity of the threat posed by exploitation is significant, but various factors are likely to prevent it from being mass exploited, security experts said. For one, the attack can take as long as eight hours to complete and require as many as 10,000 authentication steps, Stan Kaminsky, a researcher at security firm Kaspersky, said. The delay results from a defense known as address space layout randomization, which changes the memory addresses where executable code is stored to thwart attempts to run malicious payloads.

Other limitations apply. Attackers must also know the specific OS running on each targeted server. So far, no one has found a way to exploit 64-bit systems since the number of available memory addresses is exponentially higher than those available for 32-bit systems. Further mitigating the chances of success, denial-of-service attacks that limit the number of connection requests coming into a vulnerable system will prevent exploitation attempts from succeeding. //

The vulnerability affects the following:

• OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109.
• Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative patch for CVE-2006-5051, which made a previously unsafe function secure.
• The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function.

1. First, open PuTTy.
2. For “Host Name” enter the domain name or IP address of the server that will act as the proxy.
3. From the “Category” section on the left, scroll to “Connection” > “SSH” > “Tunnels”.
4. Enter the local port you want to use for the proxy connection in the “Source port” field. A common choice is “8080”.
5. Assuming you picked 8080 for the port, then enter “localhost:8080” (without quotes) as the destination. This tells PuTTY to listen to data sent to it on port 8080 from the same computer putty is running on, and forward it to the remote server.
6. Where it says “Forwarded ports”, select “Dynamic”. This enables the SOCKS protocol.
7. Now click “add”.
8. Go back to the “Session” option in the left panel. Type in a name for this connection under the “Saved Sessions” text box.
9. Now click the “Save” so you’ll be able to open the connection later without repeating these steps again.
10. Almost done! Just click the “Open” button.

The cybersecurity world got really lucky last week. An intentionally placed backdoor in xz Utils, an open-source compression utility, was pretty much accidentally discovered by a Microsoft engineer—weeks before it would have been incorporated into both Debian and Red Hat Linux. //

It was an incredibly complex backdoor. Installing it was a multi-year process that seems to have involved social engineering the lone unpaid engineer in charge of the utility. //

The sophistication of both the exploit and the process to get it into the software project scream nation-state operation. It’s reminiscent of Solar Winds, although (1) it would have been much, much worse, and (2) we got really, really lucky.

I simply don’t believe this was the only attempt to slip a backdoor into a critical piece of Internet software, either closed source or open source. Given how lucky we were to detect this one, I believe this kind of operation has been successful in the past. We simply have to stop building our critical national infrastructure on top of random software libraries managed by lone, unpaid, distracted, or worse individuals.

Cyberduck for mounting volumes in the file explorer.

Mountain Duck lets you mount server and cloud storage as a disk in Finder on macOS and the File Explorer on Windows. Open remote files with any application and work like on a local volume.

Cyberduck is a libre server and cloud storage browser for Mac and Windows with support for FTP, SFTP, WebDAV, Amazon S3, OpenStack Swift, Backblaze B2, Microsoft Azure & OneDrive, Google Drive and Dropbox.

mustached-dog Seniorius Lurkius
22y
30
Subscriptor
Interestingly enough, "Jia Tan" is very close to 加蛋 in Mandarin, meaning "to add an egg". Unlikely to be a real name or a coincidence. //

choco bo Ars Praetorian
11y
402
Subscriptor++
Performance hit is quite substantial, actually. I have no doubt that this thing would have been detected, eventually. However, it might have happened months from now. Then it would have been everywhere already.

But this is a good thing. A very good thing, actually.

There have been discussions about supply chain attacks, for years. Decades, actually. We used to call it "poisoning the well" many years ago. But no matter how much we talk about it, it was all theoretical. I mean, people even assumed that compilers have been backdoored many years ago. But noone was going to spend this much effort just to show that it was possible and to make people accept the possibility. So not much was really done about it.

Until now.

Now we are already seeing changes being made to OpenSSH that would have not been possible few months ago. Native systemd notification integration is already been developed (since 30th of March), so no need for libsystemd linking anymore. It will take some time to get integrated but it will happen. We are seeing people understanding that there is absolutely no need to have binary blobs in source repositories (except rare cases, of course, but those are going to be audited even more now). Checking source repositories against tarballs have been done before, many times. But obviously it wasn't good enough or often enough. That will change as well. People being dicks to maintainers are going to get greeted with "go fuck yourself" now, without a second thought. It will be extreme but it will be safer. For eternity I was terrified of compiling software myself because every time I invoked "./configure ..." I would think "fuck knows what is going on there right now". I did occasionally check scripts, I would grep for unexpected things but I was aware I'd never detect a very skilled attacker, like this one. Now there is going to be much more checking of autoconf/make/CMake/etc files in source repos. It won't be easy to detect things, but it will be easier. More eyes will be put on sources. For example, I am going to pick a random smaller project and just read the commit history, look for oddities, etc. Not because I expect to find something but I want to see what else should be looked at, etc. Eventually, I might end up with toolset that might help speed this process up. So there will be at least one more set of eyes looking at sources. I imagine that companies/organizations with more resources are going to put tons of effort into automating all this. So yeah, xz backdoor is actually a good thing, in a very bizarre way.

Also, I can't hunt all the references at the moment but I believe it was certificate (not the SSH key) that is used as a vector of attack, because certs are checked early and no configuration options will disable that check, while it wouldn't be the case with keys. A change to OpenSSH has already been suggested so OpenSSH will only get more secure because of this and one less vector of attack is now available.

Amount of skill and time/effort invested in this is mind blowing. I don't think people outside security really comprehend the skill/time involved here, this was insanely well executed attack. My first thought was "This had to be TURLA" because it was insanely smart and whoever did this had lots of patience. This does not (and will not) happen often.

So yeah, we were incredibly lucky that a Postgres developer caught it early.

However, it is mind blowing how many times security incidents have been detected by looking at CPU/RAM usage on systems, it is really no surprise that this is how xz backdoor got detected.

PuTTY for Windows saves all sites and configuration in Windows Registry.

Batch file to export sites and configuration from Windows Registry to a .reg file:

@echo off
::
:: export putty sites in ANSI mode
::
regedit /ea "o:\my documents\.ssh\putty-ini.reg" HKEY_CURRENT_USER\Software\SimonTatham\PuTTY

To later import, right-click on putty-ini.reg and select "import" or "merge".

Terrapin isn't likely to be mass-exploited, but there's little reason not to patch.

Novel Terrapin attack uses prefix truncation to downgrade the security of SSH channels.

Although ssh -D is an option, it’s a bit overkill because connections aren’t limited to just a single port – it’s allowing apps on the client to connect to any port and/or network interface on the remote host.

A simpler and more secure option is to forward just the required port. Then you won’t need to change proxy settings and/or rely on web browser add-ons.

For OpenSSH, the command syntax is as follows:

ssh -L local_port:host:host_port user@remote_host

For example…

 ssh -L 1234:127.0.0.1:8384 logmein@10.10.10.10

• ssh – OpenSSH client.
• -L – Forward a local network port.
• 1234 – A locally available network port to listen on.
• 127.0.0.1 – Host to forward connections to.
• 8384 – Network port on the specified host being forwarded to.
• logmein@10.10.10.10 – Remote host to tunnel to, logging on as logmein.

Now choose any suitable web browser – no proxy changes and/or proxy add-ons required – and go to http://127.0.0.1:1234/.

Connections to local port 1234 are tunneled thru remote host 10.10.10.10 and forwarded to 127.0.0.1:8384 where Syncthing’s built-in web server is waiting for connections.

For convenience, add the following OpenSSH configuration block to ~/.ssh/config:

Host syncthing-webui
LocalForward 127.0.0.1:1234 127.0.0.1:8384
HostName 10.10.10.10
User logmein

Then to open the SSH tunnel, refer to the host alias:

 ssh syncthing-webui

Fail2Ban uses the file /etc/fail2ban/jail.local and look for the [ssh] section, you can change the port there.

[ssh]
enabled  = true
port     = ssh

You can change the port value to any positive integer.

An error as small as a single flipped memory bit is all it takes to expose a private key. //

Martin Blank Ars Tribunus Militum

gromett said:
I have read it twice and am still not entirely clear.
Does this affect OpenSSH? As I read it the answer is no?

As happens often in cryptographic attacks that at least start out as implementation-specific, the likely answer is "it is not currently known to affect other implementations." Cryptographic techniques always get cheaper, never more expensive, and it is difficult to guarantee that other implementations are not vulnerable through variations of this attack. //

bobo bobo said:
A link in this article, to a Wikipedia page on Man In the Middle attacks, is labeled as a "malory in the middle" attack. But, um, the Wikipedia page does not use the term "malory". I am confused by use of the word "malory".

Typo? Or am I missing something?
It's a less common use, but it's part of the movement in the IT industry to move away from sensitive terms (e.g., master/slave becoming primary/secondary or similar). I've also heard monster-in-the-middle and monkey-in-the-middle, but really, there are no suggested terms that roll off the tongue the way man-in-the-middle does while keeping the MitM shorthand. //

FabiusCunctator Ars Scholae Palatinae

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.

A good reason to not use RSA keys if possible. I configure all of my ssh setups to use ED25519 keys by default, with a fallback to RSA if ED25519 support is not available.

You can generate an ED25519 key using the standard OpenSSH package by doing:

 ssh-keygen -t ed25519

That will generate two files in your ssh key directory ('~/.ssh/' by default): 'id_ed25519' and 'id_ed25519.pub'. The first is your private key (keep it close!), while the second is your public key. Add that to the public key file you deploy to remote servers, and (where supported *) your logins will then use the new ED25519 keypair in preference to RSA ones.

• The 'where supported' caveats are important. While many if not most ssh implementations today (including OpenSSH) support ED25519 keys, there are still a few around that don't. Hence, it's a good idea to maintain both ED25519 and RSA keys and include both in your public key lists. If an implementation does not support ED25519, it will just ignore those keys and use RSA. //