Some switches in Cisco’s 9000 series are susceptible to a remote vulnerability, numbered CVE-2019-1804 . It’s a bit odd to call it a vulnerability, actually, because the software is operating as intended. Cisco shipped out these switches with the same private key hardcoded in software for all root SSH logins. Anyone with the key can log in as root on any of these switches.

Cisco makes a strange claim in their advisory, that this is only exploitable over IPv6. This seems very odd, as there is nothing about SSH or the key authentication process that is IPv6 specific. This suggests that there is possibly another blunder, that they accidentally left the SSH port open to the world on IPv6. Another possibility is that they are assuming that all these switches are safely behind NAT routers, and therefore inaccessible through IPv4. One of the advantages/disadvantages of IPv6 is that there is no NAT, and all the network devices are accessible from the outside network. (Accessible in the sense that a route exists. Firewalling is still possible, of course.)

It’s staggering how many devices, even high end commercial devices, are shipped with unintentional yet effective backdoors, just like this one.

Git Repository Ransomware

In a first, ransomware has been targeted at Git repositories. Hundreds of repositories across GitHub, Gitlab, and other services have been replaced with a ransom note, demanding 0.1 bitcoin for recovery. Interestingly, the ransom note threatens to make the code public. This is a problem that open source definitely solves.

How did someone break into so many accounts at once? Badpackets.net, a security research company, has the lowdown.

Dang, I thought all those "/.git/config" scans we detected were harmless. Guess we know what the goal was now.

— Bad Packets Report (@bad_packets) May 3, 2019

Dang, I thought all those “/.git/config” scans we detected were harmless. Guess we know what the goal was now.

Yes, it seems that the compromised accounts leaked their credentials by accidentally hosting their .git folders online. Someone realized this was a commonplace mistake, and scraped credentials from these folders across the internet. After collecting what credentials were available, the attack was launched. A look at the specified bitcoin address seems to indicate that no-one has paid the ransom, and several of the affected have discovered that the overwritten code is still accessible, given the right git-fu.

In a Reddit thread, a user claiming to be the attacker links to a 2015 write-up detailing exactly how the .git folder leak can happen.

PGP Signature Spoofing

PGP Signatures are a useful way to absolutely know that a message is genuine, right? According to a recent paper, not always. You may remember how Efail allowed an attacker to take advantage of a weakness in email clients, and send the decrypted message to the attacker. A new set of attacks takes advantage of client weaknesses to break message verification. Imagine what happens when someone forwards a correctly signed message from someone you trust, but adds their own note at the top of the forwarded email. The mail client shows the unsigned note, and then also shows the signed block. The paper points out that the unsigned portion of the email could include HTML and CSS code that hides the remainder of the message. The email would show a valid trusted signature, and without inspection of the raw message text, is a rather convincing forgery.

The paper outlined several other techniques of a similar nature. Similar to the Efail attack, these researchers didn’t find vulnerabilities in the PGP signature itself, but in how signed messages are processed and presented to the end user. Thus not every e-mail client is affected, but many of the big names were on the list.

Blockchain!

It seems not a day goes by that something related to blockchain doesn’t cross my radar. Ethercombing is interesting and a good illustration of a common cryptography problem. The researchers at ISE took a look at the Ethereum blockchain, particularly the randomness of private keys. You see, Ethereum has a key space of 256 bits. A good random number generator could generate trillions of unique keys and never once repeat the same key. Trying to find someone’s private key in that sea of randomness would be exercise in futility, assuming of course that everyone was using good random number generation.

Since they had to start somewhere, the ISE researchers started with private key 0x01. The odds of this, or any other given private key being in use should be extremely low (1 in 2^256). Key 0x01 was in use, and had 592 transactions in its history. This suggests two possibilities. We humans are odd in that we just like certain numbers. Maybe someone intentionally used this key in the past, picking it in the same non-random way the researchers did. The other possibility is that a poorly written Ethereum client accidentally used a private key value of 1.

The researchers then considered other programming bugs that could feasibly result in weak keys, like truncating 256 bits to a 32 bit key. Another educated guess resulted in success. All told, they were able to “crack” 732 private Ethereum keys. At least one key had been previously compromised. They transferred about a dollar of Ethereum into this compromised account, and watched as the funds were quickly siphoned to another account. Now that this research has been made public, many of these weak accounts are sure to be similarly monitored, so be careful.