Cisco warns of default SSH key in several products

Posted on

Cisco security engineers have disclosed that there is a single default ‘maintenance’ SSH key hardcoded into several families of Cisco security appliances.

The default authorised SSH keys and SSH host keys are associated with remote access for maintenance, meaning that a successful attack would allow hackers to access the devices at will. Once obtained, the private keys would allow an attacker to decrypt traffic after collecting it during a man-in-the-middle attack, or impersonate one of the appliances and alter traffic.

Cisco warns of default SSH key in several products
Cisco warns of default SSH key in several products

According to Cisco, Web Security Virtual Appliances, Email Security Virtual Appliances, and Content Security Management Virtual Appliances are affected by the security issue, reports theSecurityAffairs blog.

“Multiple Cisco products contain a vulnerability that could allow an unauthenticated, remote attacker to decrypt and impersonate secure communication between any virtual content security appliances. Updates are available”, said the company in a widely-quoted statement.

The vendor has pushed out a security patch to rectify the issue, (“cisco-sa-20150625-ironport SSH Keys Vulnerability Fix”), and says all versions prior to 25 June need the update.

The Register quotes the patch advisory as saying: “IP address connectivity to the management interface on the affected platform is the only requirement for the products to be exposed to this vulnerability. No additional configuration is required for this vulnerability to be exploited.

“This patch is not required for physical hardware appliances or for virtual appliance downloads or upgrades after June 25, 2015,” the advisory continues.

However, according to ComputerWorld, Cisco said it “is not aware of any public announcements or malicious use of the vulnerabilities that are described in this advisory.”



OpenSSL Patches Five Flaws, Adds Protection Against Logjam Attack

Posted on

The OpenSSL project has patched several moderate- and low-severity security vulnerabilities and also has added protection against the Logjam attack in new releases of the software.

Most of the vulnerabilities fixed in the new releases are denial-of-service bugs, but one of them can potentially cause memory corruption. That vulnerability only affected older versions of OpenSSL.

If a DTLS peer receives application data between the ChangeCipherSpec and Finished messages, buffering of such data may cause an invalid free, resulting in a segmentation fault or potentially,  memory corruption. This issue affected older OpenSSL versions 1.0.1, 1.0.0 and 0.9.8,” the OpenSSL advisory says.

In addition to the patches, the new versions of OpenSSL also include protection against the Logjam attack, which was disclosed in May. That attack involves the way that servers handle the Diffie-Hellman key exchange.

OpenSSL Patches Five Flaws, Adds Protection Against Logjam Attack
OpenSSL Patches Five Flaws, Adds Protection Against Logjam Attack

“Millions of HTTPS, SSH, and VPN servers all use the same prime numbers for Diffie-Hellman key exchange. Practitioners believed this was safe as long as new key exchange messages were generated for every connection. However, the first step in the number field sieve—the most efficient algorithm for breaking a Diffie-Hellman connection—is dependent only on this prime. After this first step, an attacker can quickly break individual connections,” says an explanation of the vulnerability and attack, which was researched by a group of academic and industry experts from Johns Hopkins University, Microsoft, the University of Michigan and elsewhere. 

OpenSSL has added protection against the attack in version 1.0.2b and 1.0.1n.

“A vulnerability in the TLS protocol allows a man-in-the-middle attacker to downgrade vulnerable TLS connections using ephemeral Diffie-Hellman key exchange to 512-bit export-grade cryptography. This vulnerability is known as Logjam (CVE-2015-4000). OpenSSL has added protection for TLS clients by rejecting handshakes with DH parameters shorter than 768 bits. This limit will be increased to 1024 bits in a future release,” the advisory says.

The new releases also fix an exploitable issue that could allow an attacker to create malformed certificates and CRLs.

“X509_cmp_time does not properly check the length of the ASN1_TIME string and can read a few bytes out of bounds. In addition, X509_cmp_time accepts an arbitrary number of fractional seconds in the time string. An attacker can use this to craft malformed certificates and CRLs of various sizes and potentially cause a segmentation fault, resulting in a DoS on applications that verify certificates or CRLs. TLS clients that verify CRLs are affected. TLS clients and servers with client authentication enabled may be affected if they use custom verification callbacks,” the advisory says.