mirror of
https://0xacab.org/optout/into-the-crypt.git
synced 2024-12-12 09:24:33 -05:00
Elaboration on Dead Man's Switch, added section WIP for canary
This commit is contained in:
parent
752bc27bae
commit
d2edb459b0
87
README.md
87
README.md
@ -7,7 +7,6 @@
|
||||
- [Hardware Selection](#hardware-selection)
|
||||
- [Operating System](#operating-system)
|
||||
- [Disable Logging](#disable-logging)
|
||||
- [Clear Caches](#clear-caches)
|
||||
- [Secure Deletion](#secure-deletion)
|
||||
- [MAC Randomization](#mac-randomization)
|
||||
- [Traffic Manipulation](#traffic-manipulation)
|
||||
@ -30,10 +29,12 @@
|
||||
- [Obscurity](#obscurity)
|
||||
- [Justification](#justification)
|
||||
- [Code Implementation](#code-implementation)
|
||||
- [Stylometry](#stylometry)
|
||||
- [Blending](#blending)
|
||||
- [Minimize Architecture](#minimize-architecture)
|
||||
- [Automated Shutdown Procedures](#automated-shutdown-procedures)
|
||||
- [Dead Man's Switch](#dead-mans-switch)
|
||||
- [Silent Canary](#silent-canary)
|
||||
- [Play on Resources](#play-on-resources)
|
||||
- [Radio Transmitters](#radio-transmitters)
|
||||
- [EMF Shielding](#emf-shielding)
|
||||
@ -97,7 +98,38 @@ What is to come throughout this book consists of not only methods of strong cryp
|
||||
## Identifiers
|
||||
Before diving deep into the concepts, I must layout some of the identifiers that stand to de-anonymize systems. Users must understand what they are trying to defend before they lay a target on their back.
|
||||
|
||||
There are identifiers that pertain to hardware, software, and networking. Hardware identifiers that can be used to fingerprint a system include (and are not limited to) the computer model, CPU information, motherboard information via the system BIOS, USB interaction with the system DBUS, type and amount of RAM, connected HDD/SSD drives. Software identifiers are vast and include any software that attempts to beacon home to services with telemetry to create a profile on the user. Network-based identifiers include the IPv4 address, IPv6 address (if enabled), Domain Name Resolution (DNS) communication, and MAC address (can be randomized). Any, if not all of these identifiers can be used to fingerprint or de-anonymize a host.
|
||||
There are identifiers that pertain to hardware, software, and networking. Hardware identifiers that can be used to fingerprint a system include (and are not limited to) the following:
|
||||
- Computer model
|
||||
- CPU information
|
||||
- Motherboard information via system BIOS
|
||||
- USB interaction with the system DBUS
|
||||
- Type and amount of RAM
|
||||
- Connected HDD/SSD drives
|
||||
|
||||
Software identifiers are vast and include any software that will attempt to beacon home to services with telemetry to profile a user. These commonly include:
|
||||
- Host name
|
||||
- Browser information (fingerprint)
|
||||
- Browser Type
|
||||
- Version
|
||||
- Operating System
|
||||
- Screen Resolution
|
||||
- Cookies
|
||||
- Local Storage
|
||||
- Font Settings
|
||||
- Languages
|
||||
- Extension IDs
|
||||
- User agent(s)
|
||||
|
||||
Network-based identifiers include:
|
||||
- IPv4 address
|
||||
- IPv6 address (if enabled)
|
||||
- Domain Name Resolution (DNS) communication
|
||||
- MAC address
|
||||
- WiFi / Ethernet
|
||||
- Bluetooth
|
||||
- SSID Broadcast
|
||||
|
||||
Any, if not all of these identifiers can be used to fingerprint or de-anonymize a host.
|
||||
|
||||
## Hardware Selection
|
||||
This section has been prioritized as hardware is at the core of your operations. A supply chain attack resulting in embedded hardware or inherently vulnerable hardware can compromise your operation before it has even begun.
|
||||
@ -145,11 +177,6 @@ systemctl disable systemd-journald.service
|
||||
|
||||
While it is wise to reduce your logging footprint locally on your device, full disk encryption (FDE) is a sufficient anti-forensic mitigation for logging. If the attacker obtains access to your device as it is running (either physical or remote via a security compromise), logging is likely the least of your concerns.
|
||||
|
||||
### Clear Caches
|
||||
There are various caches containing sensitive information on both mobile devices and GNU/Linux systems. Linux systems have the tendency to push most logs to the /var/log/ directory. This is a simple deletion process.
|
||||
|
||||
Due to Android sandbox implementations, caches can no longer be centrally erased; caches must be cleared on individual applications. System logging is also sprawled across various directories. Reducing locally generated logs on Android is comparable to removing telemetry from Windows OS variants. Clearing caches on Android provides no serious benefit, but it does remove the amount of data present on the device. For proper privacy, only trusted applications should be used - preferably Free and Open-Source (FOSS).
|
||||
|
||||
## Secure Deletion
|
||||
Deletion of files in most operating systems today is a loose version of the term. Deletion implies the eradication of the selected file. Rather, this is deletion of the file's reference. To truly delete a file from the drive, one must completely overwrite the data. This can be done over time by passive dumb luck or it could be a conscious effort. There are existing tools for secure deletion (wiping over the file) on most platforms. On GNU/Linux systems, there is a tool in the "secure-delete" package called shred that will zero over the file. This performs deletion using the Gutmann method. Another tool called Bleachbit[^17] is known to clean the caches of the system. Built into the tool is an option to overwrite all free space on the disk. This could be a routine cleanup procedure for the concerned. On Windows, there is a tool included in the SysInternals[^18] package called SDelete that will provide a similar function to GNU/Linux's shred.
|
||||
|
||||
@ -225,7 +252,7 @@ These flags can also be appended directly to the `/usr/bin/Chromium` file so eve
|
||||
|
||||
### Search Engine Selection
|
||||
#### DuckDuckGo
|
||||
DuckDuckGo (DDG)[^31] has long been used as an alternative to Google. It is worth mentioning that DDG is TOR Projects default selection. This has granted them significant notoriety and trust. There are some underlying problems with DDG such as being based in the US, and they are not completely open-source. Without having reviewable source code, there is no way of validating their seemingly well-intentioned privacy mission statement. However, source code review becomes a moot point when you consider the fact that you are using their centralized services. Odds are that the providers of the service do not make the entirety of their systems publicly reviewable/auditable. Arbitrary code or excess applications could exist on their servers.
|
||||
DuckDuckGo (DDG)[^31] has long been used as an alternative to Google. It is worth mentioning that DDG is the TOR Project's default selection. This has granted them significant notoriety and inherent trust. There are some underlying problems with DDG such as being based in the US, and they are not completely open-source. Without having reviewable source code, there is no way of validating their seemingly well-intentioned privacy mission statement. However, source code review becomes a moot point when you consider the fact that you are using their centralized services. Odds are that the providers of the service do not make the entirety of their systems publicly reviewable/auditable. Arbitrary code or excess applications could exist on their servers.
|
||||
|
||||
#### Searx
|
||||
Searx instances[^32] are decentralized search engines that can be stood up by anyone. Decentralization with Searx doesn't remove the issue of inherent trust that must be placed in the instances, but it ensures that you have control in where you place your trust. This also enables people to stand up their own instances and configure them with better protections. Decentralization is preferred, however some of the instances are likely ran by intelligence agencies.
|
||||
@ -360,6 +387,33 @@ Perhaps mechanisms for clandestine messaging are set in place, standing up your
|
||||
### Code Implementation
|
||||
Code is a great complement to cryptographic ciphers. It has an incredibly easy implementation, and its application can be as simple or complex as desired. Using the principle of randomness, you and your affiliates could generate a word list to send out messages in a similar way that cryptocurrency wallets generate word phrase seeds. Anyone in the conversation would be given the word list and their correlated meanings (i.e. snow = money, owl = printer). Think of this method as speaking cryptically without a real cryptographic implementation. For conversations over-the-air, phrases and words can be reused; however, reuse of codes will give away more and more of the true message (under the assumption that your messages are decrypted by unauthorized parties). Once a certain amount of messages have been sent using the code for messages, it is advised to have each of your affiliates burn the page correlating the words and code. Frequency analysis is a cryptographic code-breaking technique for deciphering messages that could make short work of finding the hidden meanings. The technique is exactly how it sounds - praying upon reused messages to determine the meaning of words and phrases.
|
||||
|
||||
### Stylometry
|
||||
Stylometry is the study of linguistic style and can be used to de-anonymize people by analyzing their writing style. This can be done by comparing a person's writing samples to a dataset of known authors to find similarities and patterns that can be used to identify the author.
|
||||
|
||||
One example of this is the use of stylometry to identify the anonymous author of the "Federalist Papers." In the late 18th century, these papers were published anonymously in newspapers to promote the ratification of the U.S. Constitution. However, using stylometric analysis, scholars were able to identify Alexander Hamilton, James Madison, and John Jay as the authors of the papers.
|
||||
|
||||
Another example is the use of stylometry in forensic linguistics to identify the authors of ransom notes, threatening letters, and other anonymous documents. The technique can also be used in online platforms to detect the authorship of anonymous comments and reviews.
|
||||
|
||||
In recent years, stylometry has been used to identify the authors of fake news and propaganda. For instance, researchers at University of California Berkeley used stylometry to identify the authors of fake news articles and bots on social media platforms.
|
||||
|
||||
The Unabomber, Ted Kaczynski, was de-anonymized using stylometry. Kaczynski was a domestic terrorist who sent a series of letters and package bombs to universities and airlines between 1978 and 1995, resulting in three deaths and 23 injuries. In 1995, he sent a 35,000-word manifesto called "Industrial Society and Its Future" (also known as the "Unabomber Manifesto") to several newspapers, promising to stop the bombings if the manifesto was published. The FBI and the U.S. Department of Justice were able to use stylometry to identify Kaczynski as the author of the manifesto by comparing it to a set of writing samples from Kaczynski's personal papers. One of the key pieces of evidence was the use of the word "you" which Kaczynski used quite frequently in his manifesto as well as in his personal writings. The analysis also revealed that Kaczynski had a preference for short, simple words and that he used similar grammatical structures and sentence patterns in both his manifesto and his personal writings.
|
||||
|
||||
In addition to the stylometry, the FBI also used forensic linguistics to analyze the language and grammar used in the letters and manifesto and found that they matched the writing style of Kaczynski's known writings. In April 1996, the FBI searched Kaczynski's cabin in Lincoln, Montana, and found evidence linking him to the Unabomber crimes, including bomb components and a typewriter used to type some of the Unabomber letters. Ted Kaczynski pleaded guilty in 1998 and was sentenced to eight life sentences without the possibility of parole.
|
||||
|
||||
Stylometry, like any method of analysis, is not foolproof and can be influenced by a number of factors, such as the length of the text, the genre of the text, and the writing style of the author. Therefore, it should not be used as the sole means of identifying an author.
|
||||
|
||||
One counter-defense against stylometry is to use a technique called "stylometric camouflage," which involves deliberately changing one's writing style to evade detection. This can be done by using synonyms, changing sentence structures, or even using a different writing medium, like handwriting or dictation software.
|
||||
|
||||
Another counter-defense is to use a technique called "stylometric anonymization," which involves removing or obscuring identifying features of the text before publishing it. This can be done by using tools that randomly shuffle the words in a text or by replacing words with synonyms.
|
||||
|
||||
Journalists and other writers who are operating in a hostile environment can also use these techniques to protect their identity and freedom of expression. Some of the best practices that journalists can follow to protect themselves from stylometry are:
|
||||
- Use a variety of writing styles and formats, such as handwriting, dictation software, and text-to-speech software.
|
||||
- Use synonyms and vary sentence structures.
|
||||
- Use a different writing medium for different projects.
|
||||
- Use stylometric anonymization tools, like JStylo, Anonymouth, and Stylo.
|
||||
|
||||
It is important to note that these countermeasures don't guarantee the anonymity but it makes the identification process more difficult. These techniques are constantly evolving and changing, so it's important for journalists and writers to stay informed about the latest developments in stylometry and anonymization techniques.
|
||||
|
||||
### Blending
|
||||
"Do not speak truth to power; they will hammer you." While this is more a statement from the perspective of dissident political discourse, it stands true in an anti-forensic threat model. Operating under the radar in your operations can stand to provide valuable protection. To say the least, having federal agents breathing down your neck is an undesirable position. The concept of blending is applied with the use of previously discussed TOR and mixnet traffic routing. Simply put, "anonymity loves company," and standing out in the vulnerable world of computing is ill-advised.
|
||||
|
||||
@ -382,9 +436,22 @@ Depending on your threat model, not all operations can be conducted from a coffe
|
||||
While some of these proposed methods may be unconventional, these are unconventional times. Mechanisms can be put in place to ensure that your systems are sent shutdown signals that will lock them behind disk encryption. Shutdown signals are the most common, however we are not limited to the commands we issue. The use of radio transmitters to issue shutdowns have some level of intricacy that surpasses skills of the novice user.
|
||||
|
||||
### Dead Man's Switch
|
||||
A physical wired dead man's switch reduces attack surface and intricacy. After the dead man's switch aka killswitch is configured, we can move on to the commands to issue. If we wanted to securely wipe the random access memory before shutting down, we could issue the "sdmem -v" command to verbosely clean the RAM as the killswitch is activated. The killswitch can be activated from a system event. Any form of shell command that is compatible with the particular GNU/Linux system can be ran based on a specified system behavior. See resources at the end of this section [^41], [^42], and [^43] for USB dead man's switch. In a nutshell, this is configured to watch system USB events. When a change occurs, the switch commands are invoked. Panic buttons are another form of a killswitch that essentially remains active on your display and is ready to select at any moment. (Centry.py[^44] is a good example of a panic button). There are USB devices known as "Mouse Jigglers" that are used by forensic teams after device seizure. These jigglers are serial devices plugged in to interface with the system to keep the screenlock from being invoked.
|
||||
A Dead Man's switch is a mechanism that automatically triggers a specific action (such as shutting down a system or wiping data) if a certain condition is not met (such as the user not interacting with the system within a certain period of time). In the context of protecting journalists, a Dead Man's switch can be used to ensure that sensitive information is not compromised if a journalist's device is seized or if they are under duress.
|
||||
|
||||
There are easy preventative software-based solutions such as USBCTL[^45] that can prevent these devices for operating, however this will likely be picked up on and human mouse jigglers can take their place. Ideally a process can be utilized to detect such a device and invoke a shutdown process. A mitigation for the human mouse jigglers could be implementing forced authentication every half hour to an hour. If the credentials have not been entered, the user session could be terminated, memory could be cleared, or the shutdown command could even be invoked.
|
||||
For example, a journalist could configure a Dead Man's switch to wipe the memory of their device if it has not been used for a certain period of time, or if a specific button is not pressed at regular intervals. This would ensure that any sensitive information that is stored on the device is not accessible to unauthorized parties.
|
||||
|
||||
There are various ways to implement a Dead Man's switch, such as using USB devices, system events, or panic buttons. A physical wired dead man's switch reduces attack surface and intricacy, however remote switches can also be used to propagate a panic signal to all nodes on a network. This can be useful in situations where multiple journalists are working together and need to quickly destroy sensitive information if their operation is compromised.
|
||||
|
||||
Implementing a panic signal to invoke a Dead Man's switch can involve several steps, depending on the specific requirements and the systems involved. Here is a general overview of the process, with some references that provide more detailed information:
|
||||
1. Define the panic signal: The first step is to define the panic signal that will trigger the Dead Man's switch. This can be a button, a keyboard shortcut, a voice command, or any other type of signal that can be captured by the system.
|
||||
2. Capture the panic signal: The next step is to capture the panic signal and convert it into a system event that can be handled by the Dead Man's switch. This can be done using various methods such as using keyboard hooks, USB device monitoring, or voice recognition.
|
||||
3. Create a script or program to handle the panic signal: Once the panic signal is captured, you need to create a script or program that can handle the panic signal and invoke the Dead Man's switch. This script or program should be able to run on the target system and be able to interact with the system's resources.
|
||||
4. Configure the Dead Man's switch: After the panic signal is captured and handled, you need to configure the Dead Man's switch to respond to the panic signal. This can involve defining the actions that should be taken when the panic signal is received, such as shutting down the system, wiping memory, encrypting data, or sending an alert.
|
||||
5. Test the Dead Man's switch: Before deploying the Dead Man's switch, you should test it to ensure that it works as expected and that it does not cause any unintended consequences. You can test the Dead Man's switch by simulating a panic signal and observing the system's response.
|
||||
|
||||
After the dead man's switch, aka killswitch, is configured, we can move on to the commands to issue. If we wanted to securely wipe the random access memory before shutting down, we could issue the `sdmem -v` command to verbosely clean the RAM following activation. Any form of shell command that is compatible with the particular GNU/Linux system can be ran based on a specified system behavior. See resources at the end of this section [^41], [^42], and [^43] for USB dead man's switch. In a nutshell, these tools are configured to watch system USB events. When a change occurs, the switch commands are invoked. Panic buttons are another form of a killswitch that remain active on your display and are ready to invoke at any moment. (Centry.py[^44] is a good example of a panic button).
|
||||
|
||||
There are USB devices known as "Mouse Jigglers" that are used by forensic teams after device seizure. These jigglers are serial devices plugged in to interface with the system to keep the screenlock from being invoked. There are easy preventative software-based solutions such as USBCTL[^45] that can prevent these devices for operating, however this will likely be picked up on and human mouse jigglers can take their place. Ideally a process can be utilized to detect such a device and invoke a shutdown process. A mitigation for the human mouse jigglers could be implementing forced authentication every half hour to an hour. If the credentials have not been entered, the user session could be terminated, memory could be cleared, or the shutdown command could even be invoked.
|
||||
|
||||
Remote switches are interesting devils, and their utility should be placed under high consideration if the size of the operation warrants it. Panic buttons such as Centry.py can be used to broadcast or propagate a panic signal to all nodes on the network.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user