RCE Vulnerability Affecting Microsoft Defender

Microsoft has released a security advisory to address a remote code execution vulnerability, CVE-2021-1647

in Microsoft Defender. A remote attacker can exploit this vulnerability to take control of an affected system. This vulnerability was detected in exploits in the wild.

CISA encourages users and administrators to review Microsoft Advisory for CVE-2021-1647 and apply the necessary updates.

Dear Customer,

We recently became aware of unauthorized access to certain of our information technology systems hosted by a third party cloud provider. We have no indication that there has been unauthorized activity with respect to any user’s account.

We are not currently aware of evidence of access to any databases that host user data, but we cannot be certain that user data has not been exposed. This data may include your name, email address, and the one-way encrypted password to your account (in technical terms, the passwords are hashed and salted). The data may also include your address and phone number if you have provided that to us.

As a precaution, we encourage you to change your password. We recommend that you also change your password on any website where you use the same user ID or password. Finally, we recommend that you enable two-factor authentication on your Ubiquiti accounts if you have not already done so.

We apologize for, and deeply regret, any inconvenience this may cause you. We take the security of your information very seriously and appreciate your continued trust.

Thank you,
Ubiquiti Team

Personally I have respect for the firm to come out with a announcement

I have tried to contact them via phone and email asking if SolarWinds Orion monitoring tools are used in there network but at the time of this article there has been no response yet

Microsoft says there is no increase in security risk; however, experts say access to source code could make some steps easier for attackers.

Microsoft confirmed last week that attackers were able to view some of its source code, which it found during an ongoing investigation of the SolarWinds breach. While its threat-modeling approach mitigates the risk of viewing code, many questions remain that could determine the severity of this attack. 

In a blog post published on Dec. 31, 2020, officials said Microsoft has not found evidence of access to production services or customer data, nor has it discovered that its systems were used to attack other companies. The company has not found indications of common tactics, techniques, and procedures (TTPs) linked to abuse of forged SAML tokens against its corporate domains. 

It did find an internal account had been used to view source code in “a number of code repositories,” according to the blog post, from the Microsoft Security Response Center (MSRC). This activity was unearthed when investigators noticed unusual activity with a small number of internal accounts, the post explains, and the affected account didn’t have permissions to change any code or engineering systems. The accounts were investigated and remediated, officials noted. 

The news began to generate attention in the security community, and with good reason: Microsoft’s software is among the most widely deployed in the world, and organizations of all sizes rely on the company’s products and services. It’s an appealing target, in particular among advanced attackers like those behind the SolarWinds incident.

“It’s something they can’t access themselves, and there’s a lot of assumption that there’s super-secret things there that are going to compromise [their] security,” says Jake Williams, founder and president of Rendition Infosec, regarding why businesses might understandably panic at the news.

While it’s certainly concerning, and we don’t know the full extent of what attackers could see, Microsoft’s threat-modeling strategy assumes attackers already have some knowledge of its source code. This “inner source” approach adopts practices from open source software development and culture, and it doesn’t rely on the secrecy of source code for product security.

“There are a lot of software vendors, and security vendors, that rely on the secrecy of their code to ensure security of applications,” Williams explains. Microsoft made a big push for secure software development in Windows Vista. It didn’t make the decision to open source the code but designed it with the assumption that could possibly happen someday. Source code is viewable within Microsoft, and viewing the source code isn’t tied to heightened security risk.

“If the code is all publicly released, there should not be new vulnerabilities discovered purely because that occurs,” Williams adds.

Microsoft’s practice isn’t common; for most organizations, the process of adopting the same approach and revamping their existing code base is too much work. However, Microsoft is a big enough target, with people regularly reverse engineering its code, that it makes sense. 

While attackers were only able to view the source code, and not edit or change it, this level of access could prove helpful with some things — for example, writing rootkits. Microsoft, which did not provide additional detail for this story beyond its blog post, has not confirmed which source code was accessed and how that particular source code could prove helpful to an attacker.

It’s one of many questions that remain following Microsoft’s update. What have the attackers already seen? Where was the affected code? Were the attackers able to access an account that allowed them to alter source code? There is still much we don’t know regarding this intrusion.

This “inner source” approach still creates risk, writes Andrew Fife, vice president of marketing at Cycode, in a blog post on the news. Modern applications include microservices, libraries, APIs, and SDKs that often require authentication to deliver a core service. It’s common for developers to write this data into source code with the assumption only insiders can see them.

“While Microsoft claims their ‘threat models assume that attackers have knowledge of source code,’ it would be far more reassuring if they directly addressed whether or not the breached code contained secrets,” he writes. In the same way source code is a software company’s IP, Fife adds, it can also be used to help reverse engineer and exploit an application.

This is an ongoing investigation, and we will continue to provide updates as they are known. In the meantime, Williams advises organizations to continue applying security patches as usual and stick with the infosec basics: review trust relationships, check your logging posture, and adopt the principles of least privilege and zero trust.

“Supply chain attacks are really difficult to defend against, and it really comes back to infosec foundations,” he says. “If your model of protecting against an attack is ‘give me an indicator of compromise and I will block that indicator,’ that’s ’90s thinking.”

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial

SolarWinds shareholders accuse the company of lying about its security practices ahead of the disclosure of a massive security incident.

A class-action lawsuit filed against SolarWinds and some of its executives accuses the company of lying and misleading shareholders about its security posture in the year leading up to its disclosure of a massive breach affecting public and private entities.

The suit was filed by shareholders and names SolarWinds, in addition to outgoing CEO Kevin Thompson and CFO Barton Kalsu, as defendants. It alleges Thompson and Kalsu, who were involved with the company’s daily operations and had access to proprietary data, made false and misleading statements to the Securities and Exchange Commission throughout last year.

The complaint states that SolarWinds “failed to disclose the following adverse facts pertaining to the Company’s business, operations, and prospects, which were known to Defendants or recklessly disregarded by them.” 

It continues to say SolarWinds failed to disclose that since mid-2020, its Orion monitoring tools had a vulnerability that enabled attackers to compromise the server on which its products ran. It also notes the company’s update server had an easily accessible password of “solarwinds123.” Consequently, SolarWinds customers would be vulnerable to hacks and, as a result, the company would suffer “significant reputational harm,” the suit states. 

“As a result, Defendants’ statements about SolarWinds’s business, operations and prospects were materially false and misleading and/or lacked a reasonable basis at all relevant times,” according to the suit.

Read more details here.