Merry Christmas and happy holidays! I took Christmas day off from writing the security roundup, coming in a day early with this week’s installment, dodging New year’s day. The SolarWinds story has continued to dominate the news, so lets dive into it a bit deeper.

Microsoft has published their analysis of Solorigate, and the details are interesting. The added code was carefully written to blend in with the rest of the code, using the name OrionImprovementBusinessLayer.Initialize, which sounds like a perfectly boring-yet-legitimate function. The actual backdoor is obfuscated using zip compression and base64 encoding.

Once this bootstrap code begins, it runs a series of checks before actually doing anything malicious. It waits 2 weeks after installation to do anything, and then checks the system domain name for any indication it’s running in a test environment. It then checks for certain security applications, like Wireshark, and refuses to run if they are detected. This series of checks all seem to be an effort to avoid detection, and to only run in a deployed environment. Even the Command and Control URL that the backdoor uses is constructed to appear benign. Beyond this, it seems that the malware simply waited for instructions, and didn’t take any automated actions. All the attacks were performed manually.

One of the side-effects of the sudden attention given to SolarWinds devices is that a whole slew of other problems will be found and fixed, like CVE-2020-10148, an authentication bypass. The most surprising finding, however, is a *second* backdoor in the SolarWinds code, nicknamed Supernova. It’s possible that this was an earlier backdoor from the same actors as Solarigate, but the current theory is that it’s a backdoor installed by yet another, unrelated attacker.

Pi-hole Logs Vulnerability

If you have a Raspberry Pi running the Pi-hole software, you might want to patch a newly discovered vulnerability in the administrative interface. The issue, CVE-2020-35659, is a cross site scripting vulnerability, where viewing the logfile could allow arbitrary JS to run. The payload is JS embedded in a DNS name, which gets triggered by the log view. While it takes user interaction to view the log file, it’s frighteningly easy to get the malicious DNS request in the log. All it takes is a single resource request in any website visited by any device on the network. The PoC hasn’t been published yet, to give everyone time to update. This isn’t a sophisticated attack, so once the rest of the details are released, it should be easy to adapt the sample for real-world attacks. That said, it’s unclear how useful it is to be able to run arbitrary JS in the context of a Pi-hole.

Bouncy Castle Bypass Bug

“Don’t roll your own encryption” is still a worthy principle, but it doesn’t mean that well-known implementations can’t have problems. In this case, Bouncy Castle’s Java implementation has a coding mistake in the OpenBSDBcrypt routines. doCheckPassword is the vulnerable function, and it has a particular problem. So first, know …read more

Source:: Hackaday