The Log4J Vulnerability in Bing Domain

This article is originally published by our partner, Reflectiz. Click here to view the original article.

Reflectiz platform detected a Log4J vulnerability in a domain owned by Microsoft. The Bing domain is now patched and secure, but what about the others?

As reports of the Log4J vulnerability have turned the information security world into turmoil, we’ve put all of our efforts and resources to mitigate the client’s risk. We scanned thousands of websites and applications to identify Log4J vulnerabilities in any of them.

Since the Log4J event started, Reflectiz scanned (and is still scanning) thousands of websites and services to detect Log4J vulnerabilities that can impact our clients. Our platform detected a major vulnerability in one of Microsoft’s services – bing.com. Here’s how it played out:

The Bing Domain – What We Found and How

We started scanning for any domains connected to any of the Apache Advisory digital components by sending a non-malicious payload to try and trigger a reaction from the potentially compromised server and determine whether it’s vulnerable or not.

One of these domains we checked was bat.bing.com, a domain connected to the Microsoft UET component that exists within roughly 300k websites, including Fiverr, Canva, WordPress, Booking.com, and many more.

Just to emphasize the scale, we’re talking about hundreds of millions of users that had their data exposed and unprotected, as this vulnerability enabled an attacker to access any data that was processed by the Spark servers.

Why It Matters

The Log4J vulnerability doesn’t only threaten an organization’s servers; it may exist in any one of its dozens of third parties and digital vendors. It means that while your servers may be secured, your third and fourth parties may not be.

The communications that your website maintains with your digital vendors’ servers create a blind spot that has the potential to impact your website’s security and data privacy, just like what happened in this case with Apache’s Spark components.

When your website is communicating with your vendors’ servers. These vendors may send and receive data, which means that your user’s sensitive data can also be on that server. It means that even if your servers are fully secured, your users’ data is still at high risk since it’s all being processed by an unprotected vendor of yours.

This can end up with data leakage and privacy violations that threaten your organization with brand damages and heavy fines, or it might even escalate into the attackers sending malicious JavaScript into your website (i.e., e-Skimming, or Magecart attacks).

In simple words: if a server controlled by a third party that connected to your website has been attacked, your website will probably be attacked as well.

How did we respond to the discovery?

As part of our efforts to make our clients safe, we notified all of our clients and prospects and worked closely with their security teams, explaining the vulnerability, the risk, and how we suggest to act. In this case, we recommended removing the service until the vulnerability is solved from the vendor’s (Microsoft) side.

Under the responsible disclosure procedure, we also notified Microsoft and shared our findings with them. Once the issue was resolved and the vulnerable component patched, we notified all of our clients that it is safe to use it again.

The Log4J blind spot – An Ongoing Event

It’s important to emphasize that the Log4J vulnerability is an ongoing event, and we are still looking for more vulnerabilities that haven’t been discovered yet. However, it is also crucial that any organization learn their lessons from this case and make sure that they have the tools to mitigate risks coming from the third- and fourth-party dependencies connected to their websites.

Want to scan Log4J vulnerabilities caused by digital applications connected to your website? Start now for free and get full website mapping in just 10 minutes.