How Meta and the security industry work together to keep the Internet safe

Bug hunting is difficult and can sometimes go unnoticed in our industry. Building scalable bug detection methods on large code bases and open source libraries is an underrated but critical endeavor that every engineering company faces. Because the ideal outcome is for bugs to be found and fixed before they’re exploited, some of the best work in our industry is often unknown.

However, sharing information about bug discoveries among our engineers or bug bounty researchers has generated new ideas and led to new ways to improve the security of our platform. We believe that sharing our key learnings externally on a more regular basis is an important step forward for transparency and progress in our industry.

Today, we’re excited to release the first in a series of regular bug bulletins, in which we’ll be sharing details of some of the notable bug fixes identified in our own and third-party code. We will use these bulletins to share overviews, and occasionally insights, on specific bugs, as well as updates on relevant security programs.

How we go bug hunting in Meta

Before we dive into the recent knowledge, here’s some context on how we search for security bugs on Meta: Finding and fixing bugs is an essential part of our Security strategy “defense in depth”.. This approach means that we have implemented layers of protection throughout our platform. If a vulnerability in our code crosses a line of defense, we have extra layers of support to prevent and fix bugs as quickly as possible.

Because it’s virtually impossible to write flawless code, it’s not uncommon for software, both internal and open source, to have bugs. Like our colleagues, our strategy is twofold: While we’re constantly working to improve the quality of our code before it goes into production, we’re also building layers of protection to prevent and detect bugs in existing code as quickly as possible. We rely on a combination of automated toolingsafety reviews, red teamit’s ours Bug Bounty Program to help keep our community safe. This work is not done in a vacuum or within a single team. And often, bugs discovered in one product area can affect how we approach our work in a completely different part of the code base.

In this first post in the series, we’ll share important bugs we’ve found and fixed in our software and reported to third-party developers, and highlight some of the findings from our bug bounty researchers.

Static analysis work

Our automated static analysis tools help us review large amounts of code at scale, which frees up our engineers to spend time analyzing more complex scenarios. Over the past five years, we’ve built and continuously improved our internal tools – they now help us find around 70% of the security vulnerabilities we discover. For example, our work on Zoncolanwhich examines the Hack code, has helped us find over 1,300 bugs this year.

Zoncolan recently identified a bug in Messenger’s backend production that could have allowed a bad actor to put “You celebrated a friendversary with a friend” in a chat thread between two people. This may have been exploited by a malicious actor to create a false sense of long-term authentic connection to be exploited for scams. The message would appear inside someone’s chat list if they were already logged in or in their message request folder if they weren’t. Zoncolan discovered this bug by observing that our systems accepted user input and created a display context for it. These vulnerable endpoints had no front-end integration and were nowhere to be found in our production apps. Our team quickly reviewed Zoncolan’s report, found no evidence of abuse, and mitigated the affected endpoints to resolve the issue.

The work of the red X team

In addition to finding bugs in our code, our Red X Team works to find security vulnerabilities in external hardware and software and maintain the security of the broader internet. As part of our responsible disclosure policy, we regularly report bugs in third-party code to companies and work directly with them to test and confirm their mitigations. Here are some recent examples of interesting collaborations we’ve had across the industry.

Our team is working with Schneider Electric, a company that specializes in digital automation and energy managementto address a number of vulnerabilities in two Ethernet modules that bring modern networking capabilities to the M580 line of PLCs (programmable logic controllers). PLCs or PACs (Programmable Automation Controllers) allow equipment to act on complex instructions and are used in industrial control systems for machinery across many industries. If chained together, the identified vulnerabilities could allow an authenticated attacker to bypass multiple firmware verification steps and the module’s secure boot process by remotely overwriting the module’s firmware. This could lead to permanent bricking or backdooring of the device. To exploit these vulnerabilities, an attacker would require network access and valid credentials for the privileged “installer” account. Schneider Electric is performing a comprehensive analysis to identify and provide fixes for all products affected by these findings. These vulnerabilities have been assigned CVE-2022-34759, CVE-2022-34760, CVE-2022-34761, CVE-2022-34762, CVE-2022-34763, CVE-2022-34764And CVE-2022-34765.

We also partnered with Airspan, a company that supplies hardware and software for 4G and 5G networks, to beef up a line of eNodeBs, wireless access points that provide cellular service to phones and other LTE devices and allow them to connect to the network. We have reported issues and tested fixes for vulnerabilities that could allow local and network adversaries to obtain root command execution. By controlling the “last hop” of LTE infrastructure, an attacker could have impacted availability by disabling cellular service. Our investigation found that while an attacker could have accessed encrypted user traffic, he would not have been able to decrypt it. A malicious actor could have used their access to move further into the cellular infrastructure to further impact corporate networks where these eNodeBs are deployed, or even connect to major network operators that route and handle LTE data and calls. These issues have been assigned CVE-2022-36306, CVE-2022-36307, CVE-2022-36308, CVE-2022-36309, CVE-2022-36310CVE-2022-36311 and CVE-2022-36312.

Our Red Team X recently reported a vulnerability in Apple’s Big Sur operating system that allows kernel code to run in Darwin kernels. This could have been exploited by forking processes and leveraging the host_request_notification API. We found this bug through a hand check of the Darwin kernel and experimentation. Apple disclosed the vulnerability and released software fixes in Security Update 2021-005 Catalina; iOS 14.8 and iPadOS 14.8; TV OS 15; iOS 15 and iPadOS 15; watch OS 8; and macOS Big Sur 11.6. This achievement has been awarded CVE-2021-30857.

Through manual code review, Red Team X also found a number of bugs in EternalTerminal, an open source third-party remote terminal service that can automatically reconnect after events such as network outages and IP roaming without interrupting the session. In particular, they reported a bug that could allow the attacker to change ownership permissions on arbitrary and later filesI earn root privileges on the host machine. These bugs have been fixed by the maintainers of EternalTerminal and patched CVE-2022-24949, CVE-2022-24950, CVE-2022-24951And CVE-2022-24952.

Bug cutting job

One of the perks of being over 10 years old Bug Bounty Program is that some of our researchers have spent years hunting on our platform and have become extremely familiar with our products and services. These researchers are able to dig past surface-level issues and help us identify impactful but niche bugs that the wider community may not necessarily know how to look for.

For example, one of our longtime researchers, Youssef Sammouda, spent seven months looking for bugs on our Facebook API, known as the Canvas App. More than a decade ago, we built the Canvas App to help developers embed their games and apps on our web gaming platform. Sammouda verified the client side code inside app.facebook.com and we found a number of high-severity bugs in our OAuth implementation that could have led to an account takeover scenario. These were complex scenarios where, to attempt to exploit bugs, an attacker would have to trick their target into clicking a link, for example. We’ve investigated these reports, fixed the issues, and found no evidence of abuse. In total, Sammouda has submitted six bug reports to us, for a total of $187,250 in bounty awards. To date, this is the largest series of payments we’ve made to a researcher for a single implementation. We have been working with him to confirm our mitigations and appreciate his continued cooperation in testing our defenses. Sammouda shared further insights and advice for security researchers in his blog.

Another of our longtime researchers, Philippe Harewood, recently identified an endpoint vulnerability that could have allowed an attacker to retrieve an Instagram app access token. The great benefit of developing these reports with our researchers is that even when we have protections in place to prevent the most impactful exploit scenarios, as in this case, the collaboration often leads us to make changes to prevent similar problems in the future in our database. code and reward researchers based on the maximum potential impact we find as a result of our internal security research. We fixed this endpoint issue, found no indicators of abuse, and placed Harewood with a bounty of $30,000. Harewood shared more insights on his blog.

We are grateful to the security community for contributing great research to our program. We are continuing to do our part to expand the pool of researchers who will join the bug bounty community. We recently hosted our inaugural BountyConEDU conference in Madrid, where we invited university students and recent graduates from all over Europe to study how we look at reports and to participate in a live hacking event. In three days, we received 26 valid referrals and paid out more than $35,000 in rewards. This pilot event has far exceeded our expectations and we are excited to use the learnings to create similar opportunities around the world.

As we continue to shape the format of these Bug report updates, we welcome any feedback from our partners and industry peers and hope they let us know what they find most helpful to read next the Engineering at Meta blog.