OpenSSH has minted their 9.0 release, and it includes a pair of security changes. Unlike most of the releases we cover here, this one has security hardening to prevent issues, not emergency fixes for current ones. First up, the venerable scp/rcp protocol has been removed. Your scp commands will now use SFTP under the hood. The more interesting security change is the new default key exchange, the NTRU algorithm. NTRU is thought to be quantum-hard.

So quick primer: Modern encryption depends on trapdoor functions — calculations that are easy to perform in one direction, but very difficult to reverse. The first such scheme was the Diffie-Hellman key exchange, which uses large prime numbers multiplied together. The multiplication is easy, but factoring the result is a very hard problem. If a shortcut were ever found to make factoring easier, the security of Diffie-Hellman would suffer. Such a shortcut has theoretically been found in Shor’s Algorithm. (Similar shortucts have theoretically been found in other schemes, including elliptic curve.)

Shor’s Algorithm is actually quite clever. The video above explains it much better than I can, but the key is that it depends on a feature that can be built into quantum computers, so that many possible solutions can be processed at once, and the incorrect ones cancel out, leaving only a likely-to-be-correct output. The problem is that cutting-edge quantum computers have managed to factor 21 into its prime factors. Not a 21 digit number, mind you, but 21.

We’re a very long ways from the quantum computing crypto-apocalypse we’ve been promised. So why are projects implementing quantum-resistant protocols? The “capture now, decrypt later” scenario. Because it’s the key exchange protocol that will be potentially vulnerable, an entire SSH session can be captured now, and once a quantum computer exists that breaks the handshake, the entire session can be decrypted offline. It’s still anyone’s guess how long till a corporation or nation-state has a practical quantum computer. Even if it takes another 20 years, some data will still be sensitive and subject to decryption.

NTRU uses vector math on a lattice as the one-way function, as it still holds up well against classical computers, and there hasn’t been a quantum-accelerated attack discovered against it. Just in case NTRU turns out to be vulnerable in an unforseen way, it’s being combined with the previous standard, x25519, an Elliptic Curve solution.

NSO Targets the EU?

Software from the NSO Group has popped up in an awkward spot again. This time, ForcedEntry seems to have been used in an attempt to compromise officials in the European Union’s European Commission. NSO has denied the allegation, stating that their tools could not have been responsible for the reported attempts. Remember that NSO sells its spyware to multiple governments will very little oversight as to what those governments do with it. It should be made clear that this is almost certainly not the government of Israel, nor even NSO directly that has gone after the EU. Some coverage has left that point a bit vague. Interestingly, rather than being discovered by professionals at the EU, the affected commissioners were notified by Apple via email.

Git Issues

Git for Windows has just released a round of updates to fix CVE-2022-24765. The problem here is that a .git folder at the root of a Windows drive is seen as a valid configuration for any Git operation outside a legitimate Git directory. The danger is that another user or malicious program could create this directory, and the next time Git is run, arbitrary commands can be triggered via the config.

And speaking of Git, there’s an interesting data leak that was just announced, notgitbleed. Weird name? [Aaron Devaney] and [Will Deane] found the issue in 2021 and picked “GitBleed” as their vulnerability name, but another group of researchers beat them to the name with a similar but distinct problem. Not ones to take themselves too seriously, the tongue-in-cheek alternative was chosen.

The actual problem is developers and our muscle memory when doing a git push. Make the commit, push to Github, and punch in username and password. However, when making that first commit, Git will ask you for your name and email. If not paying attention, it’s all to easy to give it a username and password. Surely, I hear you scoff, no more than a small handful of developers would make that mistake. Extrapolating from their findings, it looks like over 50,000 passwords have leaked in commit metadata over the years.

Social Typosquatting and Takeover

We’ve talked about domain/subdomain takeover, where a domain has been allowed to expire, but is still considered active somewhere. A new tool from [Utku Sen] lets you look for social media links that are vulnerable in the same way. Imagine I intended to link to my Twitter account, asking you all to follow me there, but I typo’d the link. If there wasn’t already an account at the misspelled link, someone could create one and pretend to be me. For evidence, there’s even the article where I linked to the (fake) account. Whoops! That’s where socialhunter comes in. Point it at a URL, and it looks for bogus social media links. Apparently many bug bounty programs will accept such typos as valid issues, so get to work!

Amazon RDS Heist

Some vulnerability finds just read like an old-fashioned caper film, and this is one of them. Lightspin researchers were working on the Amazon Relational Database Service (RDS), which is Amazon’s cloud database offering. One option for the database engine for RDS is PostgreSQL. There are a handful of ways to escape the SQL engine and run code on the machine, but the obvious holes are plugged: You don’t have true superuser access, cannot load an untrusted language extension, etc. There are a handful of extensions available, and log_fwd is the interesting one. This lets you access log files as a foreign table, super useful for debugging. If you can investigate log files, can you check out other files with this trick, too? Researchers tried, attempting to import ../../../../../etc/passwd. This threw an error, naturally. Life can’t be that easy.

A few more requests later, and it was clear that there was a pattern-matching validator function that was blocking path traversal. PostgreSQL uses foreign data wrappers to acess external data like this, and they include validator functions as an optional feature. Optional to the extent, you can disable them at runtime. So, disable the validator, and then try to access the passwd file? Paydirt.

Any file on the filesystem that the PostgreSQL daemon could read, the user could, too. After looking for anything interesting, the term grover popped up. Following a series of linked config files, there was finally an API credential uncovered. This credential allowed access to AWS as a csd-grover-role, an internal AWS service. At this point, researchers had pierced the veil, and were playing in the AWS backend. They called it a day’s work, and turned the findings over to Amazon. AWS security validated the bug, confirmed that it hadn’t been exploited in the past, and were curiously tight-lipped about what the grover service is. Regardless, the bug is fixed, and it’s an interesting tale of escaping the AWS sandbox.

NGINX 0-day — Maybe

There’s been some rumblings, just as this column is headed to the presses, that NGINX may have a 0-day exploit in the wild. It appears that specifically the LDAP reference implementation in NGINX that is vulnerable. F5 has confirmed that there is indeed an issue. There have been security fixes pushed to the nginx-ldap-auth repo, assumably fixing the issue. BlueHornet is the group that leaked the bug, and has published its take on the story. Using LDAP with NGINX? This is one to take a close look at.