Finding an OpenSSH 7.4 server in 2025 is rare. Finding one that accepts 1024-bit Diffie-Hellman keys is a critical risk. Here is how I performed a cryptographic downgrade attack, and why the triage team called it "Theoretical."

Introduction: The Cryptographic Time Machine

In the fast-paced world of Web Application security, we often forget about the infrastructure underneath. We look for XSS in the frontend and SQLi in the backend, but we rarely check the door we used to get in: The SSH Protocol.

Recently, while scanning a massive corporate scope (*.redacted-corp.com), I stumbled upon a server that felt like a time capsule. It wasn't just running old software; it was configured to accept cryptographic handshakes that were declared "dead" a decade ago.

I found a server vulnerable to Logjam, running OpenSSH 7.4 (released in 2017), and using broken SHA-1 hashing.

I successfully performed a Downgrade Attack, forcing the server to use a weak 1024-bit key exchange. I reported it. I provided logs. And the result? "Not Applicable — Theoretical Impact."

This is the technical deep dive into that finding, and a discussion on why "Old Crypto" is still a massive risk.

Phase 1: The Discovery (Nmap & SSH-Audit)

I started with a standard port scan on a development subdomain: dev.redacted-corp.com. Port 22 (SSH) was open.

To analyze the cryptographic posture of an SSH server, nmap scripts are good, but ssh-audit is the gold standard. It tells you exactly what algorithms the server supports and rates them based on modern standards.

The Scan:

ssh-audit dev.redacted-corp.com

The Result (Redacted):

(gen) software: OpenSSH 7.4 (End of Life: 2021)
(kex) diffie-hellman-group1-sha1 -- [fail] vulnerable to Logjam
(kex) diffie-hellman-group14-sha1 -- [fail] broken SHA-1
(key) ssh-rsa -- [fail] broken SHA-1

The output was a sea of red text.

  • OpenSSH 7.4: This version is ancient. It contains multiple known CVEs (like user enumeration).
  • Logjam Vulnerability: The server supported diffie-hellman-group1-sha1.

What is Logjam?

The Logjam attack (CVE-2015–4000) allows a Man-in-the-Middle (MITM) attacker to downgrade a connection to use 512-bit or 1024-bit Diffie-Hellman groups.

  • The Risk: 1024-bit discrete logs are estimated to be breakable by state-level adversaries (like the NSA) or massive computing clusters. If cracked, the attacker can decrypt the entire SSH session — passwords, commands, data, everything.

Phase 2: The Exploitation (Forcing the Downgrade)

The triage team often rejects crypto bugs as "Best Practice" if you don't prove they work. To prove this was exploitable, I had to simulate a victim client connecting to this server and being forced into using the weak algorithm.

I used the native OpenSSH client to explicitly request only the weak algorithm. If the server was properly hardened, it would reject the connection.

The Command:

ssh -oKexAlgorithms=diffie-hellman-group1-sha1 user@dev.redacted-corp.com -vv

The Breakdown:

  • -oKexAlgorithms=...: This tells my client "Do NOT use Curve25519. Do NOT use Elliptic Curves. ONLY use this old, broken Diffie-Hellman group."
  • -vv: Verbose mode to see the handshake debug logs.

The Evidence: The server didn't blink. It accepted the handshake immediately.

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group1-sha1  <-- NEGOTIATED
debug2: bits set: 491/1024                          <-- WEAK MODULUS
debug1: SSH2_MSG_NEWKEYS received

Why is this a POC? This proves that the server still accepts this weak crypto. In a real attack scenario, a hacker sitting on the Wi-Fi or ISP level (MITM) allows the initial connection but intercepts the "Algorithm Negotiation" packet. They strip away the strong algorithms (like curve25519-sha256) from the client's list, leaving only diffie-hellman-group1-sha1. The server sees this, says "Okay, let's use that," and the session is established over a channel the attacker can crack.

Phase 3: The Report & The Rejection

I bundled everything into a report.

  • Vulnerability: Weak Cryptographic Primitives (Logjam) & Unsupported Software.
  • Severity: High (P3).
  • Impact: Passive decryption of SSH sessions via MITM.

I waited 2 weeks. Then, the blocker:

"Can you please provide any POC demonstrating the exploitation?"

I provided the SSH downgrade logs shown above. I explained that simply connecting via the weak algorithm is the exploit validation because it proves the server allows the downgrade.

The Final Verdict:

Status: Not Applicable "After reviewing your report, we were unable to identify any security impact. The impact is theoretical only."

Phase 4: The "Theoretical" Debate

Was the impact theoretical?

From their perspective: I didn't actually crack the 1024-bit key. To do that, I would need a supercomputer or a massive cloud cluster running number field sieve algorithms for days/weeks. Since I couldn't hand them the decrypted plaintext of the session, they deemed it "Theoretical."

From a Security perspective: This is a dangerous mindset.

  • State Actors Exist: Just because I (a bug bounty hunter) don't have the budget to crack 1024-bit DH primes doesn't mean threat actors don't.
  • Standards Matter: NIST deprecated 1024-bit RSA/DH years ago. Using it in 2025 is negligent.
  • The "Zombie" Risk: Running OpenSSH 7.4 implies this server hasn't been patched since 2017. If they ignore this, what else are they ignoring? Kernel exploits? Local Privilege Escalation?

Conclusion: When to Report Crypto Bugs

This experience highlights the difficulty of reporting Cryptographic Weaknesses in Bug Bounty.

  • Context is King: If this server was a Payment Gateway or a Critical Database, this might have been accepted. On a Dev server, they care less.
  • The "Crack it or Bust" Rule: Many programs will not pay for SSL/SSH weakness unless you can demonstrate a full break (e.g., Heartbleed or ROBOT). Downgrade attacks often fall into the "Best Practice" bucket.
  • Don't Stop Hunting: Even though this was N/A, finding this server tells me that *.redacted-corp.com has a patch management problem. This is a signal to look deeper into their infrastructure for other "forgotten" endpoints.

Final Score:

  • Tech: Successful Crypto Downgrade.
  • Bounty: $0 (N/A).
  • Lesson: Infrastructure bugs are tough sells without RCE.