Got $50k spare? Then you can crack SHA-1 – so OpenSSH is deprecating flawed hashing algo in a 'near-future release' The maintainers of OpenSSH, the widely used toolkit for connecting securely to servers and devices over networks, have warned that the SHA-1 algorithm will be disabled in a "near-future release". SHA stands for Secure Hash Algorithm. The SHA-1 implementation has been known to be vulnerable since 2005 though still requiring …
I used to work at NIST, which famously does a lot of security research and advised SHA-1 be disallowed. However, the IT teams inside NIST were often total dogshit, there was a lot of SHA-1 floating around on internal sites. In 2016 they started providing a new VDI service which allowed Linux users like me to access Windows on the occasions that we needed. The service was given a new SHA-1 cert. When I was unable to connect due to security policy the IT team happily gave me instructions on how to turn off disallowing SHA-1.
The only way forward is to just remove support!
Several older bits of equipment have firmware that can not be changed to support more secure protocols. These devices require SHA-1 . In many cases the cost of replacing the equipment would be prohibitive. (For example a controller that is part of an expensive industrial machine.)
A means of using SHA-1 still has to be available - and preferably NOT by disabling updates on a computer to keep the facility.
Maybe it would be a good idea if they removed it's support in the ssh server code, and not (yet) in the client?
Or of course, replacng equipment wouldn't be needed: Just plug it instead to a small 2 port box with the other port instead going to the lan.
Run a hardened ssh server on the box, that relays to a less secure ssh connection privately to the device.
A small arm box/rouer could do that. The 50 quid edgerouter X, for example
"Just plug it instead to a small 2 port box with the other port instead going to the lan."
so that system that has just 1 port that can be administered via sha1 needs another box in-front of it to proxy sha2.
you could do that or you could put a fw in the logical path blocking all ssh to everything you want & a single bastion host in the subnet of the sha1 system that will only permit sha2 or whatever you want.
Then you use strong auth to get to the bastion host in the required subnet and then sha1 to the old system and any other systems in that subnet that can only use sha1.
you could put the bastion host elsewhere but it ups the risk of the traffic being intercepted from 0 for the solution with the box in front of the sha1 system to a little bit more for something on the same subnet intercepting that traffic (can't happen on a switched network unless a port mirror is configured) to again a bit more if the traffic is routed through a number of systems that could intercept or chnage on route (fw's load balancers, virtual systems, IDS/IPS) etc
the attack risk is much lower on your internal systems than it is if your traffic has to go across a public network even if you use a vpn or private peering in a colo.
I have seen this argument so many times going back to "it needs to support MS-DOS."
Firmware can be updated and equipment can be swapped out. It's not necessarily easy or cheap but the alternative is leaving your company vulnerable.
Besides, do you really want a hacker into your industrial machines?
It's rarely that black & white, though. I used to have a rack of a dozen old machines in a test lab, they were great for prototyping new builds of code where performance wasn't an issue. The code on the actual servers was often Beta, with potential security issues, so the system was on an isolated lab network.
The one downside was that the console access to each system was via SSH to a service processor which only supported old algorithms. The systems were obsolete, no-one was generating new firmware, so to login I had to override the block on unsafe algorithms. It didn't matter, the consoles were on a completely isolated management network. The alternative would have been to ask for a dozen new systems, an unnecessary expense that would probably have been reduced to one or two per annual budget cycle.
There are times when blocking old stuff by default, but allowing it to be selected, is justified.
We still have VAXes running on emulators for our plant, and they are critical.
Corporate security forced us to get off cleartext telnet, so we looked at SSH. The Microfocus Reflections terminal clients were going to cost us hundreds of thousands, and not really offer any visible feature improvements.
Instead, we wrapped our old Reflections with stunnel clients, served by a set of Linux stunnel servers, and left our old software in place with cleartext telnet wrapped in TLS. I generated the keys and wrote the configs.
This decision gets criticized from time to time. Attempting alternatives has revealed other systemic problems, beyond expense.
Sorry, but at some point you have to cut off support. It's the only way to move forward. If you have equipment with firmware that cannot be changed, then maybe it's time to upgrade that equipment. MS-DOS has been dead for years. They don't even make DOS boot disks for system maintenance any more. Much of the issues with different and strange limitations is compatibility with legacy equipment. The BIOS in PCs is a real example here. This is why UEFI was developed. If a piece of equipment is truly vital, I'm sure if the vendor/manufacturer has enough money thrown at them, they will figure out a solution...maybe even a new controller or new ROM that has the new protocols in it. Either way, this is a software issue.
When the old PC is part of a piece of industrial equipment that costs over £500k and would cause excessive loss of production if it was taken out and replaced then discarding it is NOT an option. In many cases the original supplier is no longer in business so updating the control PC to something more modern is not possible. In industry, big machinery is often expected to work for over 20 years - sometimes over 40 years.
If you really need SHA-1 support for legacy kit with non-upgradeable firmware, you can always put that equipment on a separate VLAN that can't see the Internet; and then either have a simple proxy translating requests, or just reencapsulate the traffic in a more secure transport.
The code isn't going anywhere, except behind an ifdef and some dire warnings. You will still be able to build an OpenSSH with SHA-1 support. You'll just have to prove you really, really want it, is all.
Because of this and other deprecated ssh stuff, it forces me to keep around old systems, with all updates turned off so that I can still get into old gear that doesn't have any upgrade path but is still in use.
The alternative is to turn telnet back on and telnet into them. :-(
At least technically it was address with the V2 BitTorrent protocol in 2017. It switches to SHA-256 and uses the Merkle Root Tree for individual files instead of a SHA-1 hash for each file among other improvements.
http://bittorrent.org/beps/bep_0052.html
How many third party clients, torrents, and magnet links have been updated I have no clue, but there is a fix barring weaknesses in SHA-256.
I remember back in 2012 a worm was discovered on a computer in Iran. This worm was called Flame or Flamer. It literally spoofed the Microsoft software signing certificate using an unknown chosen prefix attack. This attack was different than the attack vector used in the 2007 paper. So whoever pulled it off used world-class cryptanalysis. What was the result of this certificate spoofing? It made the computer think the update was coming from Microsoft and installed it, no questions asked, when in fact it was malware.
SHA-1 has been vulnerable for a long time. If you have equipment that requires it, then I'm sorry, but you need to upgrade your equipment. As an alternative, why connect industrial equipment to the internet to begin with? That's just asking for something to happen. Best to have it on an air-gapped network so someone has to do an up-front intrusion to gain access.
Some time ago I noticed that some Linux ISOs were being signed with two different types of hash - usually an MD5 and some type of SHA. Whilst I realise that this is not really applicable to OpenSSH, surely this is still a reasonable defence against hash collisions?
That doesn't really address the point. Even if two different hashes are compromised, using them both as separate hashes still gives some measure of assurance that the file has not been tampered with. If only one is compromised file integrity is guaranteed by the other. If both are compromised it may still be extremely difficult to find a hash collision for both.
I was merely using MD5 as an example.
My question really is - are two hashes more secure than one?
"are two hashes more secure than one?"
even with one of them being weak, like MD5 or SHA1, a two-hash collision attack would be virtually impossible. Add file length comparison, even more impossible. BUT... if the cost of producing a "poison packet" for torrent is based on randomly generating blocks of bytes until you get a match, and THAT determines the cost, it would only be slightly slower to test against 2 algorithms than against a single one, for each pass.
I'd give it "a qualified yes" - it's more secure. Maybe the chances of even finding a hash-collision where BOTH algorithms collide is the saving grace here... so you won't get as many successful attempts with two hashes, even if they're weak, regardless of the length of time needed to find the collisions.
Better: just use SHA256 and other more secure hashes. Maybe two of THOSE, even.
It's now feasible to create a file having the same MD5sum as another file using readily-available equipment, so an MD5 match can't be relied on as proof that a file downloaded from some random website has not been altered from the original version.
It still takes a deliberate effort to force a clash, so MD5 probably is still good enough for determining if or not a file has been edited *by you*.
A double collision is at least as hard to engineer as the harder collision, and *might* be actually impossible; but that depends on the algorithms used.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
