Microsoft disclosed in a blog post that in addition to using the trojanized Orion software, the hacking group behind the SolarWinds attack also viewed Microsoft source code for unnamed products.
The tech giant said that the SolarWinds hackers were able to access a small number of internal accounts having permissions to view the source code in a number of source code repositories.
Microsoft, however, downplayed the breach, saying that the security of its products does not depend on the secrecy of its source code.
Contrarily, Microsoft source code for most high-profile products remains to be among the most jealously guarded corporate secrets, shared only with a few trusted customers and governments.
Tech giant admits that SolarWinds hackers accessed Microsoft source code
In an update on Microsoft Security Resource Center (MSRC), the company disclosed that it discovered “activities beyond just the presence of malicious SolarWinds code” in its environment.
The company said that it detected unusual activities with a small number of internal accounts. Further investigation revealed that “one account had been used to view source code” in several Microsoft source code repositories.
Microsoft downplays the risk of revealing its source code
Source code is a set of instructions contained in a piece of software that controls an operating system or computer hardware to perform certain functions.
Having access to those instructions could allow the SolarWinds hackers to modify or insert malicious instructions into Microsoft source code as they did with SolarWinds Orion software. Accessing Microsoft source code may also provide the SolarWinds hackers insights on how to engineer attacks or exploit Microsoft products.
However, Microsoft says that its customers should not worry because source code secrecy is not the company’s primary security strategy.
The blog post also claimed that Microsoft adopted the “open-source software development best practices” and assumes that the “attackers have knowledge of source code.”
Consequently, viewing Microsoft source code did not elevate the risk of an attack, according to Microsoft’s blog update.
The personal computing software giant added that the compromised accounts could only view Microsoft source code without allowing the SolarWinds hackers to modify the contents of repositories.
Further investigation also failed to detect common tools, techniques, and procedures (TTP) consistent with the “abuse of forged SAML tokens” against Microsoft corporate domains.
Microsoft assured customers that there was no evidence of access to production services or customer data during the investigation, which is ongoing.
Additionally, the company confirmed that the Microsoft platform was not used to launch attacks on other targets.
While Microsoft reported the breach, it did not disclose which components were accessed by the SolarWinds hackers. Additionally, there was no clarification if Microsoft source code was copied, leading to the assumption that the breached accounts did not have “copy” privileges.
Risks of Microsoft source code exposure
Days earlier, Microsoft confirmed that the highly sophisticated SolarWinds hackers exploited the Security Assertion Markup Language to authenticate against the Microsoft Azure cloud platform.
The SolarWinds hack on FireEye also got the tech giants admitting that the SolarWinds hackers employed techniques that none of the companies had witnessed before. Knowing Microsoft source code may allow the hackers to carry out more sophisticated attacks using new and innovative techniques.
With the number of victims and attack vectors expanding with each investigation, likely, the effects of the initial SolarWinds attack would only intensify.
Mark Shavlik, CEO at Senserva, said that source code breaches were the cybersecurity industry’s worst-case scenario. He added that all security products were at risk of compromise by various threat actors.
“Security products need to run with a higher level of permissions and when breached they have the opposite effect of helping with security,” Shavlik said. “All products are at this risk; Security products are no different.”
Despite taking due diligence, “at some point something bad will happen,” according to the Senserva CEO.
“That said, we all must up our game around security training and monitoring for our development environments. But beyond that, we need to design security products in new ways to lessen the risk of a breach and the impact when a breach occurs”
