Anti-Forensics Precautions: Difference between revisions - Whonix by @madaidan
so the Linux kernel’s memory erasing features (
page_poison,slub_debugorinit_on_free) and/or your firmware reset attack mitigation can kick in
I’ll make that a footnote. That’s interesting but too much information for a user just trying to learn recommended steps.
New section added on Signal Desktop.
TODO test and research. Personally I am not interested until the mobile no. requirement and desktop instance independence is possible which may never happen. It’s documented for people out there to know and experiment if interested.
Related:
i have deprecated nheko and replaced it instead with quaternion: (added tchncs server for registration)
replaced element with riot:
I have deleted lilias and myself from ppl who can create accounts for users as we are not admins/moderaters in the forum to have the ability do that.
I have modified chromium comparison of chrome://flags to about:config:
and added desktop chromium forks:
Uploading images for outside sources can be achieved through:
Clearnet
https://anonfiles.com/
Onion
http://iuploadwnensanof.onion/
I want to add warning from mobile phones due to their ease of trackability and penetration through SIMcards like IMSI-catcher or Pegasus or Finspy, The use of wireless… shall it be here with the points mentioned:
https://www.whonix.org/wiki/Template:Kicksecure_Android
or create new warning section here
Awesome stuff!
Nitpick: Avoid Oneboxing for Anchored Links
Not sure yet it fits there. But since that Template:Kicksecure_Android is only used on /wiki/Kicksecure (not Whonix) and /wiki/Dev/mobile (/Dev/ is for developers, not users), it is not a great fit. The template is for: "This section details potential future security enhancements for Kicksecure ™. "
Better suited would be this page which is supposed to be user documentation for users of Whonix related to their use of mobile phones. (Or rather avoid use of popular mobile phone anywhere near sensitive computer systems.)
Documentation for this is incomplete. Contributions are happily considered!
- A compromised mobile phone could turn on the microphone and eavesdrop without any compromise indicator noticeable by the user. The audio leakage from keyboard typing can be used to infer the words up to a certain degree of accuracy. This might reveal passwords. See Microphone.
- Similar for camera.
Documenting this is difficult. Some issues won’t be applicable to Android AOSP, GrapheneOS, phones without sim cards. These details and discussions then easily overshadow the reality of most users.
Awesome. Now documented here:
While I was at it, also documented this:
And moved / revamped other documentation on Whonix forums:
Free Support for Whonix ™
This is not an issue with mobile devices in general but the insecurity of cellular protocols. You can always use airplane mode or remove the SIM card.
What is the significance of these? Could use some quotes.
Finspy - a phising attack. User tricked into installing malicious flash upgrade (probably on the windows platform). Not related to mobiles.
Finspy - Quote New FinSpy iOS and Android implants revealed ITW | Securelist
Malware features
iOS
FinSpy for iOS is able to monitor almost all device activities, including record VoIP calls via external apps such as Skype or WhatsApp.
Well, that is interesting but that is a feature of computer malware too. Once root compromised, all computer functions can be used against the user. Nothing specifically related to iOS / Android here.
However, functionality is achieved by leveraging Cydia Substrate’s hooking functionality, so this implant can only be installed on jailbroken devices
Well, jailbreak is very much discouraged by Apple. However, adding the risks of rooting / jail breaking / some custom ROMs to Account and Mobile Devices Security would be good.
IMSI-catcher: If someone is already targeted then it’s game over anyhow in context of Whonix. However, briefly explaining IMSI-catcher would be good too as I guess many people are unaware of it.
Though FinFisher - Wikipedia sounds pretty devastating wrt iphones:
The security flaw in iTunes that FinFisher is reported to have exploited was first described in 2008 by security software commentator Brian Krebs.[3][4][18] Apple did not patch the security flaw for more than three years, until November 2011. Apple officials have not offered an explanation as to why the flaw took so long to patch. Promotional videos used by the firm at trade shows which illustrate how to infect a computer with the surveillance suite were released by WikiLeaks in December, 2011.[10]
Interesting.
How many users are aware of that and doing that? The point of documenting this would be pointing that out.
Not sure what you mean by insecurity of cellular protocols. That 3G, 4G, 5G encryption isn’t as safe as let’s say .onion, or gpg? That MITM eavesdropping is possible? Well, that may be true but the critical point is here is device exploitation and the device turning into a snitch, uploading all voice, contents, video elsewhere.
Quote:
Zero-Click Exploits
Marketed as an “NSO uniqueness, which significantly differentiates the Pegasus solution from any other solution available in the market”, the Over-the-Air (OTA) installation vector works by sending a stealth push notification to the target’s phone and requires no interaction from the target in the form of either clicking links or opening messages, rendering the spyware installation “totally silent and invisible”. This kind of attack is known as a ‘zero-click’ exploit. However, the applicability of the OTA vector appears to be limited, with a footnote noting that “some devices do not support it; some service providers block push messages”, as well as noting that the attack will not work if “target phone number unknown.”
many more examples of another NSO zero-click installation vector being utilized nonetheless appeared in 2019 when WhatsApp announced that NSO Group had leveraged a zero-click RCE (Remote Code Execution) exploit in their app which allowed NSO Group to successfully infect targets simply by placing a call via WhatsApp to the target; “the person did not even have to answer the call” to be infected. According to the WhatsApp complaint, NSO Group attempted to infect more than 1,400 phone numbers via this attack vector, with “attorneys, journalists, human rights activists, political dissidents, diplomats, and other senior foreign government officials” being more than 100 of those targeted by NSO Group via the WhatsApp exploit.
As zero-click vulnerabilities by definition do not require any user interaction, they are the hardest to defend against.
This sounds pretty big. I.e. some phones, some people targeted got hacked without falling for phishing. All that was needed in many cases was knowing a phone number of a target. “Never mind eaves dropping a phone call over insecure cellular network.” It’s about owning the whole device.
airplane mode would have defended that but that’s kinda saying “unplug your computer from the internet”. Then it’s no longer a very useful device.
No simcard + WiFi wouldn’t have defended the mentioned whatsapp example above either.
Of course but it should be clarified that it’s not an issue inherent in mobile devices but in cellular protocols specifically as mobile devices can be used without a SIM card.
Cellular has historically been easy to compromise/MITM or be used for device triangulation.
That requires an exploit chain. Peforming a MITM attack on cellular protocols doesn’t immediately give the attacker access to the entire device. They must exploit other vulnerabilities on the device.
You can use airplane mode to disable cellular but then re-enable WiFi.
I am not sure what inherent means here.
However, putting More than a billion hopelessly vulnerable Android gizmos in the wild that no longer receive security updates – research • The Register + How to Defend Against Pegasus, NSO Group's Sophisticated Spyware together with the massive list of successfully exploited targets, that’s big. A pandemic vulnerability waiting to be exploited.
Sure, it’s not about the form factor. A mobile device running Debian would be comparable to a computer running Debian. Also might not be an issue for Android AOSP, GrapheneOS. But concentrating on the tiny minority amount of users with such devices misses the main issue which most users are facing.
See the WhatsApp case…
many more examples of another NSO zero-click installation vector being utilized nonetheless appeared in 2019 when WhatsApp announced that NSO Group had leveraged a zero-click RCE (Remote Code Execution) exploit in their app which allowed NSO Group to successfully infect targets simply by placing a call via WhatsApp to the target; “the person did not even have to answer the call” to be infected. According to the WhatsApp complaint, NSO Group attempted to infect more than 1,400 phone numbers via this attack vector, with “attorneys, journalists, human rights activists, political dissidents, diplomats, and other senior foreign government officials” being more than 100 of those targeted by NSO Group via the WhatsApp exploit.
That would have happened with SIM card removed too. (After registration, apps such as WhatsApp, Telegram or Signal can be used with a SIM card. Actually even sign-up without SIM card is possible if one can find a virtual mobile number online which is not blacklisted by these services. Or simcard is another phone is also possible.)
Indeed. However, as per above, this I’d call this pandemic.
Sure, however that WhatsApp path to exploitation by Pegasus issue would have happened in airplane mode + WiFi enabled too.
The issue is not in mobile devices themselves. It’s in cellular networks specifically. E.g. a vulnerability in some Android app doesn’t mean Android devices are insecure as they are not what’s at fault - the app is.
I’m saying this because of the wording TNT used “warning from mobile phones due to their ease of trackability and penetration”.
NSO Group only sells to governments. Only specific individuals that are targeted by government agencies will be hit with these exploits. The average user isn’t going to be affected.
I’m talking specifically about the insecurity of cellular protocols. That WhatsApp vulnerability isn’t related. Zero-click exploits overall are a separate topic.
Part of this wiki page on the topic of OpenPGP encryption is outdated. This is due to the enigmail extension recently becoming no longer available. OpenPGP encryption functionality is now built-in Thunderbird [archive]. Documentation is yet to be updated. Contributions are welcome.
Hey. This needs updating Instant Messenger Chat
Pidgin Security Advisories page is located here Advisories.
Also why does the ‘poor security record’ exist? Seems Pidgin had no bugs since 2017 according to their Advisories page and Pidgin Pidgin : List of security vulnerabilities
The complete lack of reported bugs after 2017 is much more concerning than it is reassuring. It shows that there has been no attempt at reviewing the code and uncovering bugs. That advisories page is also quite incomplete. There have been many more vulnerabilities than what’s listed there. cvedetails is much more thorough.
Also see https://web.archive.org/web/20190917093114/https://pidgin.im/news/security/
Strange that they took it down and replaced it with a massively inferior version.
Hmmm I see. So the page I sent was the proper one.
new wiki page:
Could you please slightly update Full Disk Encryption (FDE)? @HulaHoop
The plausible deniability feature is available with volume types
Normal+Hidden Truecrypt/Veracrypt. Veracrypt volumes support crypto-cascades as a feature, so manual nesting is unnecessary. However, be warned that Truecrypt/Veracrypt volume types only support AES-128. Plain dm-crypt containers with a non-zero offset can be used to provide hidden volumes according to Zulucrypt’s manual. This is yet to be tested by Whonix ™ developers.
As is could be misconstrued as endorsement of deniable decryption?
It may be possible to get plausible deniability on Linux hosts using methods other than those listed below, but the topic is a rabbit hole (see footnotes). [2]
That reference is offline and not archived.
Plausible deniability and Full Disk Encryption (FDE) are also useless if subjected to physical abuse by a captor.
Could you please add its own chapter for plausible deniable encryption?
Could you please also add that in some scenarios it is actually better to avoid using software with plausible deniable encryption? Using such software by itself is suspicious. If one unlocks the decoy disk and the adversary is not happy, one might face indefinite detention or worse, if there really is no hidden volume. Related to that, is this article any good to link to or quote from?
Sleep mode:
Hibernation is also a safe alternative because the swap partition is encrypted in the default FDE configuration for various platforms (like Debian), so long as no changes were made.
But cryptsetup LUKS key does not get wiped from RAM.
systemd feature request: cryptsetup luksSuspend (wipes encryption key from kernel) on suspend [archive]
Perhaps own chapter for sleep mode too?