mirror of
https://github.com/privacyguides/privacyguides.org.git
synced 2024-12-21 05:44:34 -05:00
Common Threats: Supply chain attacks (#2467)
Signed-off-by: Jonah Aragon <jonah@triplebit.net>
This commit is contained in:
parent
93136f2a0b
commit
a8a4adee73
@ -4,5 +4,5 @@
|
||||
"name": "Privacy Guides",
|
||||
"image": "ghcr.io/squidfunk/mkdocs-material:9.5.17",
|
||||
"forwardPorts": [8000],
|
||||
"postCreateCommand": "git submodule init; git submodule update theme/assets/brand; ./run.sh"
|
||||
"postCreateCommand": "git submodule init; git submodule update theme/assets/brand; apk add bash; /bin/bash run.sh --cmd=mkdocs --cmd_flags=--dev-addr=0.0.0.0:8000"
|
||||
}
|
||||
|
@ -42,7 +42,7 @@ schema:
|
||||
|
||||
These myths stem from a number of prejudices, but whether the source code is available and how software is licensed does not inherently affect its security in any way. ==Open-source software has the *potential* to be more secure than proprietary software, but there is absolutely no guarantee this is the case.== When you evaluate software, you should look at the reputation and security of each tool on an individual basis.
|
||||
|
||||
Open-source software *can* be audited by third-parties, and is often more transparent about potential vulnerabilities than proprietary counterparts. It also allows you to review the code and disable any suspicious functionality you find yourself. However, *unless you do so*, there is no guarantee that code has ever been evaluated, especially with smaller software projects. The open development process has also sometimes been exploited to introduce new vulnerabilities into even large projects.[^1]
|
||||
Open-source software *can* be audited by third-parties, and is often more transparent about potential vulnerabilities than proprietary counterparts. It also allows you to review the code and disable any suspicious functionality you find yourself. However, *unless you do so*, there is no guarantee that code has ever been evaluated, especially with smaller software projects. The open development process has also sometimes been exploited to introduce new vulnerabilities known as <span class="pg-viridian">:material-package-variant-closed-remove: Supply Chain Attacks</span>, which are discussed further in our [Common Threats](common-threats.md) page.[^1]
|
||||
|
||||
On the flip side, proprietary software is less transparent, but that doesn't imply that it's not secure. Major proprietary software projects can be audited internally and by third-party agencies, and independent security researchers can still find vulnerabilities with techniques like reverse engineering.
|
||||
|
||||
@ -94,4 +94,4 @@ One of the clearest threat models is one where people *know who you are* and one
|
||||
|
||||
Using Tor can help with this. It is also worth noting that greater anonymity is possible through asynchronous communication: Real-time communication is vulnerable to analysis of typing patterns (i.e. more than a paragraph of text, distributed on a forum, via email, etc.)
|
||||
|
||||
[^1]: One notable example of this is the [2021 incident in which University of Minnesota researchers introduced three vulnerabilities into the Linux kernel development project](https://cse.umn.edu/cs/linux-incident).
|
||||
[^1]: A notable supply chain attack occurred in March 2024, when a malicious maintainer added a obfuscated backdoor into `xz`, a popular compression library. The backdoor ([CVE-2024-3094](https://www.cve.org/CVERecord?id=CVE-2024-3094)) was intended to give an unknown party remote access to most Linux servers via SSH, but it was discovered before it had been widely deployed.
|
||||
|
@ -9,13 +9,14 @@ Broadly speaking, we categorize our recommendations into the [threats](threat-mo
|
||||
- <span class="pg-purple">:material-incognito: Anonymity</span> - Shielding your online activity from your real identity, protecting you from people who are trying to uncover *your* identity specifically.
|
||||
- <span class="pg-red">:material-target-account: Targeted Attacks</span> - Being protected from hackers or other malicious actors who are trying to gain access to *your* data or devices specifically.
|
||||
- <span class="pg-orange">:material-bug-outline: Passive Attacks</span> - Being protected from things like malware, data breaches, and other attacks that are made against many people at once.
|
||||
- <span class="pg-viridian">:material-package-variant-closed-remove: Supply Chain Attacks</span> - A vulnerability or exploit introduced into otherwise good software either directly or through a dependency from a third party.
|
||||
- <span class="pg-teal">:material-server-network: Service Providers</span> - Protecting your data from service providers (e.g. with E2EE, which renders your data unreadable to the server).
|
||||
- <span class="pg-blue">:material-eye-outline: Mass Surveillance</span> - Protection from government agencies, organizations, websites, and services which work together to track your activities.
|
||||
- <span class="pg-brown">:material-account-cash: Surveillance Capitalism</span> - Protecting yourself from big advertising networks, like Google and Facebook, as well as a myriad of other third-party data collectors.
|
||||
- <span class="pg-green">:material-account-search: Public Exposure</span> - Limiting the information about you that is accessible online—to search engines or the general public.
|
||||
- <span class="pg-blue-gray">:material-close-outline: Censorship</span> - Avoiding censored access to information or being censored yourself when speaking online.
|
||||
|
||||
Some of these threats may be more important to you than others, depending on your specific concerns. For example, a software developer with access to valuable or critical data may be primarily concerned with <span class="pg-red">:material-target-account: Targeted Attacks</span>, but they probably still want to protect their personal data from being swept up in <span class="pg-blue">:material-eye-outline: Mass Surveillance</span> programs. Similarly, many people may be primarily concerned with <span class="pg-green">:material-account-search: Public Exposure</span> of their personal data, but they should still be wary of security-focused issues, such as <span class="pg-orange">:material-bug-outline: Passive Attacks</span>—like malware affecting their devices.
|
||||
Some of these threats may be more important to you than others, depending on your specific concerns. For example, a software developer with access to valuable or critical data may be primarily concerned with <span class="pg-viridian">:material-package-variant-closed-remove: Supply Chain Attacks</span> and <span class="pg-red">:material-target-account: Targeted Attacks</span>. They will likely still want to protect their personal data from being swept up in <span class="pg-blue">:material-eye-outline: Mass Surveillance</span> programs. Similarly, many people may be primarily concerned with <span class="pg-green">:material-account-search: Public Exposure</span> of their personal data, but they should still be wary of security-focused issues, such as <span class="pg-orange">:material-bug-outline: Passive Attacks</span>—like malware affecting their devices.
|
||||
|
||||
## Anonymity vs. Privacy
|
||||
|
||||
@ -57,6 +58,31 @@ By design, **web browsers**, **email clients**, and **office applications** typi
|
||||
|
||||
If you are concerned about **physical attacks** you should use an operating system with a secure verified boot implementation, such as Android, iOS, macOS, or [Windows (with TPM)](https://learn.microsoft.com/windows/security/information-protection/secure-the-windows-10-boot-process). You should also make sure that your drive is encrypted, and that the operating system uses a TPM or Secure [Enclave](https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/1/web/1) or [Element](https://developers.google.com/android/security/android-ready-se) to rate limit attempts to enter the encryption passphrase. You should avoid sharing your computer with people you don't trust, because most desktop operating systems don't encrypt data separately per-user.
|
||||
|
||||
<span class="pg-viridian">:material-package-variant-closed-remove: Supply Chain Attacks</span>
|
||||
|
||||
Supply chain attacks are frequently a form of <span class="pg-red">:material-target-account: Targeted Attack</span> towards businesses, governments, and activists, although they can end up compromising the public at large as well.
|
||||
|
||||
<div class="admonition example" markdown>
|
||||
<p class="admonition-title">Example</p>
|
||||
|
||||
A notable example of this occurred in 2017 when M.E.Doc, a popular accounting software in Ukraine, was infected with the *NotPetya* virus, subsequently infecting people who downloaded that software with ransomware. NotPetya itself was a ransomware attack which impacted 2000+ companies in various countries, and was based on the *EternalBlue* exploit developed by the NSA to attack Windows computers over the network.
|
||||
|
||||
</div>
|
||||
|
||||
There are few ways in which this type of attack might be carried out:
|
||||
|
||||
1. A contributor or employee might work their way into a position of power within a project or organization, then abuse that position by adding malicious code.
|
||||
2. A developer may be coerced by an outside party to add malicious code.
|
||||
3. An individual or group might identify a third party software dependency (also known as a library) and work to infiltrate it with the above two methods, knowing that it will be used by "downstream" software developers.
|
||||
|
||||
These sorts of attacks can require a lot of time and preparation to perform and are risky because they can be detected, particularly in open source projects if they are popular and have outside interest. Unfortunately they're also one of the most dangerous as they are very hard to mitigate entirely. We would encourage readers only use software which has a good reputation and makes an effort to reduce risk by:
|
||||
|
||||
1. Only adopting popular software that has been around for a while. The more interest in a project the greater likelihood that external parties will notice malicious changes. A malicious actor will also need to spend more time gaining community trust with meaningful contributions.
|
||||
2. Finding software which releases binaries with widely-used, trusted build infrastructure platforms, as opposed to developer workstations or self-hosted servers. Some systems like GitHub Actions let you inspect the build script that runs publicly for extra confidence. This lessens the likelihood that malware on a developer's machine could infect their packages, and gives confidence that the binaries produced are in fact produced correctly.
|
||||
3. Looking for code signing on individual source code commits and releases, which creates an auditable trail of who did what. For example: Was the malicious code in the software repository? Which developer added it? Was it added during the build process?
|
||||
4. Checking whether the source code has meaningful commit messages (such as [conventional commits](https://conventionalcommits.org)) which explain what the change is supposed to accomplish. Clear messages can make it easier for outsiders to the project to verify, audit, and find bugs.
|
||||
5. Noting the number of contributors or maintainers a program has. A lone developer may be more susceptible to being coerced into adding malicious code by an external party, or to negligently enable undesirable behavior. This may very well mean software developed by "Big Tech" has more scrutiny than a lone developer who doesn't answer to anyone.
|
||||
|
||||
## Privacy From Service Providers
|
||||
|
||||
<span class="pg-teal">:material-server-network: Service Providers</span>
|
||||
|
@ -30,7 +30,7 @@
|
||||
:root, [data-md-color-scheme="default"] {
|
||||
--md-default-bg-color: rgb(247, 247, 252);
|
||||
--md-primary-fg-color: rgb(255, 255, 255);
|
||||
--md-primary-fg-color--light: #FFD06F;
|
||||
--md-primary-fg-color--light: #ffd06f;
|
||||
--md-primary-fg-color--dark: #db9d21;
|
||||
--md-primary-bg-color: rgba(0,0,0,.75);
|
||||
--md-primary-bg-color--light: rgba(0,0,0,.54);
|
||||
@ -45,17 +45,18 @@
|
||||
--pg-blue: #0e66ae;
|
||||
--pg-green: #2e7e31;
|
||||
--pg-blue-gray: #546d78;
|
||||
--pg-viridian: #40826d;
|
||||
}
|
||||
:root, [data-md-color-scheme="slate"] {
|
||||
--md-default-bg-color: rgb(26, 26, 27);
|
||||
--md-primary-fg-color: rgb(15, 15, 15);
|
||||
--md-primary-fg-color--light: #FFD06F;
|
||||
--md-primary-fg-color--light: #ffd06f;
|
||||
--md-primary-fg-color--dark: #db9d21;
|
||||
--md-primary-bg-color: rgba(0,0,0,.75);
|
||||
--md-primary-bg-color--light: rgba(0,0,0,.54);
|
||||
--md-accent-fg-color: #ffdb57;
|
||||
--pg-light-border: rgb(47, 47, 47);
|
||||
--pg-hero-color: #FFD06F;
|
||||
--pg-hero-color: #ffd06f;
|
||||
--pg-purple: #af94de;
|
||||
--pg-red: #ff6c6a;
|
||||
--pg-orange: #e97b5a;
|
||||
@ -64,6 +65,7 @@
|
||||
--pg-blue: #74b9f1;
|
||||
--pg-green: #72cd75;
|
||||
--pg-blue-gray: #9ab2bc;
|
||||
--pg-viridian: #40826d;
|
||||
--md-footer-bg-color--dark: var(--md-default-bg-color);
|
||||
}
|
||||
|
||||
@ -301,6 +303,10 @@ details[class="downloads annotate"] > p .md-annotation span span::before {
|
||||
color: var(--pg-blue-gray);
|
||||
}
|
||||
|
||||
.pg-viridian {
|
||||
color: var(--pg-viridian);
|
||||
}
|
||||
|
||||
/* Make header icons smaller */
|
||||
.md-header__button.md-icon svg {
|
||||
height: 1rem;
|
||||
|
Loading…
Reference in New Issue
Block a user