The recent xz Utils security incident in the open source circle has shocked the industry, and the current culprit has not yet been identified.
To put it simply, the xz Utils intruder has been in the dark for two or three years, and through social engineering, he first obtained high-level privileges to the project, and then performed a series of intricate operations.
(See the full attack timeline:
https://www.oschina.net/news/286008/xz-timeline）
It can be seen that in this process, the first thing that the intruder is eager to achieve is to elevate the rights, which is a large threshold, so it can be seen that they use real code contributions to pay in the open source project, and at the same time use this as a "bargaining chip" to improve their status in the project, and at the same time constantly change the way to repeatedly urge to take over the project permissions.
In the past two days, the OpenSSF and OpenJS Foundation have also called on all open source maintainers to be vigilant against such social engineering infiltration takeover patterns, identify early threat patterns, and take steps to protect open source projects.
The OpenJS Foundation Interproject Committee has received a series of suspicious emails begging OpenJS to take action to update its JavaScript project to "address any serious vulnerabilities," but without mentioning specific details.
The email authors want OpenJS to designate them as the new maintainers of the project, even though they have barely been involved with the project before.
The OpenJS team also spotted similar suspicious patterns in two other projects and immediately reported to their respective OpenJS leaders, as well as the Cybersecurity and Infrastructure Security Agency (CISA) under the U.S. Department of Homeland Security (DHS).
The following suspicious patterns in social engineering takeovers are of concern:
- A friendly, positive, and ongoing desire for a maintainer or its custodian entity (foundation or corporation) by a relatively unknown member of the community.
- The request is promoted from a new or unknown person to maintainer status.
- Endorsements from other unknown members of the community who may also use false identities, also known as "sock puppets" (white gloves).
- A PR that contains blobs as artifacts. For example, the XZ backdoor is an elaborate file that is part of a test suite, and as opposed to the source code, the file is not human-readable.
- Deliberately obfuscating or making it difficult to understand the source code.
- Security issues escalate. For example, the XZ problem starts with a relatively innocuous replacement of safe_fprintf() with fprintf() to see who notices.
- Deviations from typical project compilation, build, and deployment practices may allow the insertion of external malicious payloads into blobs, zips, or other binaries.
- False sense of urgency, especially when implicit urgency forces maintainers to reduce the thoroughness of the review or bypass control.
These social engineering attacks are manipulating them by taking advantage of the maintainer's sense of responsibility to the project and the community, and it is necessary to pay attention to how the interaction makes you feel, and the interaction that can make you feel self-doubting, inadequate, not doing enough for the project, etc., it may be that you are being attacked by social engineering at this time.
References
https://openjsf.org/blog/openssf-openjs-alert-social-engineering-takeovers
https://www.oschina.net/news/286008/xz-timeline