Back in January, we covered the news that Ubiquiti had a violation of undisclosed gravity. One reader pointed to the compromise with a handful of devices as potentially related. Since there were no such reports, I didn’t think too much about it then. Now, however a Ubiquitous informant gave Krebs the juicy details.
The “third-party cloud provider” to which the original disclosure applies is Amazon Web Services (AWS). According to the whistleblower, almost everything was available, including the keys to access any Ubiquiti device on the Internet, as long as it was activated in the cloud. The attackers installed several back doors in Ubiquiti’s infrastructure and sent a threat of 50 bitcoin extortion. To their credit, Ubikiti ignored the blackmail and cleared up the mess.
The claim that there is no evidence that hackers had access to user accounts seems to be that the database in question simply did not activate registration. There was no evidence because he was not looking at anything. So far, I have only seen one device compromise report that is potentially the result of an attack. If you had a Ubiquiti device that became a scammer around December 2020 – January 2021, be sure to let us know.
Ransomware in safe mode
This is a new trick – We usually use safe mode to fix computers, but a strain of malware abuses it to break them. The idea seems to be that your antivirus is probably not working in safe mode, so the encryption process is more likely to succeed. On the other hand, Safe Mode may mean that shared folders on your server are not accessible, limiting the destruction to a single computer.
The fantastic trick to doing this job is to put the payload in RunOnce registry key and add the name of the key with an asterisk. This spell signals to Windows that it should work even in safe mode. The encryption process slows down the startup of explorer.exeso that the machine appears to hang on the blank Safe Mode screen.
Violation of PHP Git
A malicious engagement was sneaked into the PHP code on the 27th and returned about five hours later. The account of the developer who submitted the bad code is believed to have been compromised and access denied. A few hours later, the reversion was returned from another programmer’s account. This time, the bad code was present for less than two hours before being returned with the humorous message of engaging Revert "Revert "Revert "[skip-ci] Fix typo""" The consensus is that the server hosting the PHP code was probably compromised in some way and it was decided to move the PHP development process to GitHub.
The malicious code was quite simple. Check for magic string in useragent header and executable PHP code from that header, if found. If the PHP version was actually shipped with this code intact, the damage would be overwhelming, as it would be an easy-to-use background in any web service using PHP. It is worth noting that the open source nature of the PHP project led to the very rapid detection of the injected code, and because of this speed, the actual damage from this attack is likely to be essentially zero. It didn’t seem like a particularly complex attack and wasn’t even disguised to look like innocent code. Was it just a test run?
Through Phoronics
Disadvantages of OpenSSL
OpenSSL just fixed a couple of serious bugs in their version 1.1.1k. The first is CVE-2021-3449, which allows a malicious renegotiation request to crash an OpenSSL server. This is a zero pointer redirection, which is known to be difficult to turn into a full RCE, though impossible.
The second bug, CVE-2021-3450, is less annoying but potentially more serious. If OpenSSL is configured to validate a certificate and a certain strict mode flag is activated, then a self-signed certificate can be accepted as signed. This is because strict mode checking can replace the results of a reliable CA check.
Network mask trouble
There are a few oddities in how IP addresses are spelled. We usually write the IP in “decimal point” format. Consider the following three IP addresses:
10.0.0.1,, 010.0.0.1, and 0x10.0.0.1. The first two are identical, and the last is an invalid address, right? Well, it depends. If you stick to what is considered “standard”, with a decimal point, then yes. But an early implementation of BSD with a decimal point includes both hexadecimal and octal. This has become something of a competitive standard and appears from time to time. See the image on the right for a surprising example.
Well what about a library like NPM netmaskthat checks if an IP address is part of a particular network? Net masks .contains a function accepts a dotted string as input and returns true or false based on whether the IP is on the given subnet. In versions before 2.0.0, he understood decimal notation and hexadecimal notation, but otherwise ignored the leading “0”. This means that the octal representation would instead be understood as decimal. This is a problem when other parts of your application see the IP as octal. Checking the strength of the network mask considers that the IP is part of the local network (10.0.0.1) when it really belongs to layer 3 Communications (8.0.0.1). The front of the security sees the connection as coming from the local network when it really comes from outside.
This little oddity was discovered by [Victor Viale], and fixed by researchers which is the work we have considered before. In fact, these were the earlier adjustments to private-ip package that led to this discovery. This package is being considered 0127.0.0.1 to be a personal address. That’s right … unless your code understands 0127.0.0.1 to be equivalent to 81.0.0.1. Let’s do a little experiment. Try navigating to or pinging this IP address with the leading 0. What does your browser or terminal understand? The octal format is surprisingly widely accepted.
Now here’s the kick. How do I fix this? Remember that there is no RFC that explicitly defines how dotted IP address notation works. I’m sure some NPM packets ignore leading zeros in IP addresses, and some OSes probably do the same. If you change netmask to understand the octal notation, then these applications are already vulnerable exactly the way you are trying to fix. No matter what, something will break.
Semantic version helps here, although it is not a silver bullet. NPM uses a 3-digit system, starting with 1.0.0 for initial versions. For error corrections that are otherwise backward compatible, increase the third number. For updates with new features but that do not compromise compatibility, increase the second number. Finally, for large changes that violate backward compatibility, the first number gets a boom. Netmask is no longer backward compatible, so the fix was released as 2.0.0. Many applications are written with a flexible dependencies section, which allows automatic updates on the go when bug fixes are released, but not automatic switching of major versions. It doesn’t solve the problem automatically, but again, it really wasn’t possible.
Recover funds from Ransomware?
Bleeping Computer presents the story of a ransomware campaign that does something unexpected – redemption payment back to the victims. Well, that’s the statement. Bitcoin has not been returned yet. It is alleged that the authors of the malware fear the actions of law enforcement agencies and plan to become legitimate researchers after paying the ransom. You’ll excuse me if I’m a little skeptical, but that sounds too good to be true. Time will tell whether this is a second scam or a real change of mind.
Campaign for Redux researchers
Remember the North Korean APT that targeted researchers with a fake security company and malicious connections? The people at Google who follow these things, the Threat Actor Group, have warned this this campaign returns under a different name. SecuriElite is the new fake company, and a new gang of fake researchers is active on Twitter and LinkedIn. That is, they were active until Google’s TAG raised the alarm. The attackers will probably go to the ground for a week or two and then jump out somewhere else.