The Great Big Thing(tm): Ra-Ra-Russian Facebook Edition

I have spent the last year angry at basically everyone I know for participating in this Facebook Fake News/Russian psychological warfare campaign. I washed out of Facebook because convincing my friends and relatives that they’d been conned was slowly bleeding away my will to live. I also left because of the revelations about Cambridge Analytica’s role in swaying the election through targeted marketing. Just logging in to Facebook made me complicit in the whole campaign. As time goes on, it would seem that the HyperNormalization of Facebook users has been manipulated to one extent or another to sway a few key votes. Not sure how that helps me to be honest.

I don’t yet see a causal link between Cambridge Analytica, the Guccifer2.0 email leaks and APT28 hacking the DNC, but there does seem to be a fair amount of correlation. If it wasn’t a coordinated effort, at least a few people must have known they were happening. At the very least, some decision maker was advised by someone who was aware of these operations. A fair amount of my existential angst over the past year has been the polarization of the views of my Facebook friends. I don’t know if it helps me or hurts me more to know that at least part of it was a deliberate and cynical attempt by well funded groups to make it happen. On the one hand I can feel smug and superior that I am a freethinker that didn’t get caught up in Russian PsyOp. On the other hand, feeling smug is pretty much all I’ve got, and it’s just not worth it. The way that HyperNormalization works is being for a group or against the group doesn’t matter. All that matters is that you are interacting with whatever it is. It could be Nationalism, it could be political corruption, it doesn’t matter because it needs both supporters and opponents to continue to exist. Fighting it only makes you a part of it. Also, being in exile from Facebook has forced me to confront the fact that I’m a really shitty friend.

The Russia Thing

So my friends and family aren’t idiots, they’re just pawns in someone else’s game. That’s a relief, I guess?

That still leaves the whole Mueller investigation and the steady flow of soul destroying information that comes with it. As I have stated before, I don’t care about the Trump presidency. They had Richard Nixon dead to rights and all he did was resign and be pardoned by his successor. All the pee tapes and white-hot smoking guns in the world won’t make Trump suffer a single bit. So it’s not worth even daydreaming about. Also, if you think Trump is empowering White Power and Christian Identity Nationalism, wait until President Pence takes over.

What I *do* care about the collateral damage Russia and Cambridge Analytica have caused and will continue to cause. I also care about how we as an electorate deal with the huge vulnerability social media poses to democracy. Allowing the United States to descend into fascist tyranny is a hell of a price to pay for a couple of tax cuts. I like it when the government stays out of basically everything, but replacing the government with unchecked corporate power isn’t even remotely a good idea. On the list of “Top 10 Corporations that shouldn’t be in charge of the United States” Facebook owns at least two of them.

The thing that worries me the most is the fact that 12 of the Russians indicted in the Mueller investigation are officers with Russian Military Intelligence. Meaning that this was basically a military operation. Maybe GRU is military in the way that the NSA is – national level not operational level – but that still doesn’t make me feel good. If Russia was a country full of brown people, the US would be invading it right now. Fortunately for the world, US foreign policy is pretty racist and Russia is a Caucasian ethno state, so two nuclear superpowers probably aren’t going to go to war directly.

Intelligence isn’t evidence

My involvement with the American intelligence community was minimal at its very best about 20 years ago. I am not an expert on the subject, but I do understand a couple of basic concepts of military intelligence, such as casus belli. Before you can perform a military operation, you need to have intelligence to justify its necessity.

The difference between intelligence and evidence is that intelligence is information that something either has happened, is happening, or will happen. Evidence is proof of what happened and of the damage done as a result. As we learned about the Gulf Wars, the burden of proof to justify a war is far lower than the burden of proof for a judgement in an American court of law. Also, an indictment is a far cry from a conviction, but an indictment of 12 foreign nationals probably still requires more evidence than it takes to sanction any kind of military operation. Usually spies just get traded back to their home countries under diplomatic cover.

This is why the Russia thing is so concerning. Of course the US interferes in foreign elections. Of course the US is conducting PsyOps of its own against other countries. Of course the US is conducting like 6 shadow wars in Central Asia and North Africa. All that shit is proxy for conflict with Russia. APT28 and APT29 are taking direct action against the US which is threatening the delicate balance of terror between the US and Russia. Even without full-scale invasions, proxy wars between the US and Russia are sending the world into chaos. Just look at the baffling situation in Syria.

I can’t help but fear that the pieces on the chess board are lining up into an Assassination of Archduke Ferdinand-type situation. The elements are starting to form: trade disputes, economic sanctions, complicated [even contradictory] diplomatic alliances, and clandestine military operations on foreign soil. The scary thing isn’t a new WWI, it’s the genocidal chaos that followed WWI. Oh, and that it led to WWII and even more genocide.

Stupid SSH Tricks

I use this site for a number of reasons. One them is to keep a little diary of things that I have figured out so that I can reference them later. The problem is that those little discoveries are buried in rambling posts about why I chose to do something. So here is where I talk about setting up a dynamic port to use as a SOCKS proxy for securing web traffic, local ports for accessing resources inside of closed network, and remote ports for making resources inside of a closed network publicly available on the Internet.

I have given 2600 talks about SSH tunnels but I really don’t have a permanent record of my various [mis]uses of SSH, so I thought I would put them all in a post for future reference. I have written about securing SSH with asymmetric encryption keys, but there are many more things that you can do with SSH.

IMPORTANT NOTE: – none of these tricks work unless your host has TCP port forwarding enabled. This option is usually enabled by default, but you should double check your /etc/ssh/sshd_config file:

nano /etc/ssh/sshd_config

Then make sure that the option is uncommented and enabled:

 AllowTcpForwarding yes

Also, if all this putty crap looks tough to do, just remember that all of this is way easier with UNIX. Particularly using the -J option for jumping SSH connections.

Dynamic Ports: slip past content filters with this one weird trick

This is the go-to use for an SSH tunnel. University and corporate networks are often overseen by petty tyrants who limit access to sites of questionable content, or sites that are prone to eating bandwidth, like social and streaming media. Ironically, most of these networks allow outbound SSH. SSH kills content filters dead.

You can create a SOCKS proxy using an SSH connection by creating a dynamic port. You can then point your browser to use your local address (127.0.0.1) as a SOCKS proxy to smuggle all of your browser traffic thru the SSH tunnel.

I like using Firefox specifically for this task because Chrome or IE does dumb things when you mess with the proxy settings. Or rather, they did dumb things that one time I used them to tunnel 10 years ago and then decided on using FireFox. If you want to also tunnel your DNS queries, in Firefox type “about:config” in the browser bar and then find the setting “network.proxy.socks_remote_dns” and set it to “true”. There’s probably a more modern way to to that, but that’s the tried and true way. Tunneling DNS isn’t strictly necessary, but it does help you stay under the radar on a restrictive network.

It should be noted that once you tunnel your browser traffic through the tunnel, you are likely to lose access to intranet sites on your local subnet. For this and a number of other reasons, I like to run Brave (Chrome) for my normal stuff, and Firefox for the tunneled stuff. Running two browsers at the same time seems wasteful, but it saves a bunch of headaches.

On Windows, you can drop the port one of three ways:

If you are into radio buttons and text boxes, you can configure PuTTY to open one every time you connect. On the tree control to the left, click Connection -> SSH -> Tunnels. You’ll need to select dynamic and enter a source port (5555 in the picture to the right) and click ‘Add’. Your new port should appear in the list above as ‘D5555’. Be sure to go back to your session and click ‘Save’ of you want the port to be created every time you open the session. As long as you are messing with your PuTTY session, you might as well set your terminal colors to green text so you look like a real hacker.

If using the GUI makes you feel like a wimp, you can just script it with a handy batch file:

putty -D 5555 user@ssh.server.com

You can also feel like a real UNIX badass by copying putty.exe to c:\Windows\System32 and renaming it to ssh.exe so you can kick off your session from DOS like a real console cowboy.

OR you can dump the whole interactive shell pretense and use plink.exe to make your connection and drop your ports without the whole pesky PuTTY window getting in your way:

plink -D 5555 user@ssh.server.com

Plink is bascially PuTTY with no window. It functions basically the same in all other respects.

If you are using a Unix or Linux workstation, you can set up your dynamic port with a similar syntax:

ssh -C -D 5555 user@ssh.server.com

Note: the -C switch compresses traffic going thru the tunnel, theoretically increasing network speeds through the tunnel.

Local Ports: I heard u like shells so we tunneled SSH thru yo SSH so you can get a shell while you gettin a shell

You can use SSH to secure more than just your web browsing. You can use it to secure pretty much any TCP connection. I like using it to secure notoriously insecure VNC and X sessions.

Another use is to get around port restrictions. Some networks may allow outbound SSH, but only on port 22. Some home ISP’s get shitty about running servers on reserved ports like 22. This means you have to forward some bunk port on your home router, like 62222 to the SSH server on your home network. I used to do this when I had Time Warner cable. The problem would get worse when I was trying to connect remotely from a restrictive network that only let SSH out on port 22.

To get around this problem, I would have to SSH to a public access Unix system like the Super Dimensional Fortress on port 22 and then drop a local port that forwarded to the bunk SSH port on the IP of my home router. When I did that with different windows that had different text colors it looked like I was on CSI: Hacker Girl back tracing the killer’s IP address.

The setup is pretty much the same as for the dynamic port, only you have to specify a destination IP and port as well. The idea is to connect to a remote host that is on the other side of a restrictive firewall and using the SSH tunnel to make something accessible to your local your local network. It forwards all traffic to your local port to the remote destination thru the tunnel. In the example above it was SSH but it could be RDP or any other TCP connection. I’ll use RDP (port 3389) in the example below.

To tunnel a Microsoft Remote Desktop session through SSH using the PuTTY gui, use the tree control to the left, click Connection -> SSH -> Tunnels. You’ll need to select local and enter a source port (13389 in the picture to the right), set the destination address or host+domain name and the port (192.168.1.10:3389 in the picture to the right) and click ‘Add’. 13389 will be the port on your workstation that is now connected to the RDP port on the remote network (3389). Your new port should appear in the list above as ‘L13389 192.168.1.10:3389’. Be sure to go back to your session and click ‘Save’ of you want the port to be created every time you open the session. In your RDP client, you would connect to 127.0.0.1:13389.

If you are scripting this setup, use the -L switch along with your source port, destination IP/host and the destination port. Using the scenario from above, you forward local port 13389 to 192.168.1.10 port 3389 like this, where your SSH username is ‘alice’ and your home network’s dynamic DNS hostname is casa-alice.dynamic.DNS:

putty -L 13389:192.168.1.10:3389 alice@casa-alice.dynamic.DNS

And finally, the syntax is the same with plink:

plink -L 13389:192.168.1.10:3389 alice@casa-alice.dynamic.DNS

You can actually specify multiple local ports to remote destinations. I do this with PuTTY to get direct access to the web interface on my Proxmox cluster and to RDP to a Windows host using just the one tunnel and without having to mess with my proxy settings.

Remote Ports: SSH kills firewalls dead.

In the local port scenario, you are connecting to a remote host behind a firewall and using the SSH tunnel to make a host inside the remote firewall accessible to your local your local network. You can also do the opposite, which is to connect to a remote host outside of your firewall and use the SSH tunnel to make a host inside your local firewall accessible to either the Internet or to hosts on a remote network.

You do this by dropping a port at the other end of the tunnel. On the remote host. The obvious use is to temporarily punch a hole in the local firewall to expose an internal web server to the Internet. If the remote host that you are connecting to is directly connected to the Internet, (like a hosted VM from Cloud At Cost) you can temporarily open a port on the remote server to tunnel traffic to the web server on your internal network.

A more nefarious use for a remote port would be for a leave-behind box (formerly known as a dropbox before the term became a brand name for cloud storage) to phone home from a target network. Basically you build a cheap single board PC, like a Raspberry Pi or a plug server that you physically plug into a network that you plan on hacking testing for security holes. This approach saves a ton of time reverse engineering firewalls to gain access. There are two basic approaches, load up the box with tools and drop it, or use a minimal box as a router/pivot for tools you are running outside the target network.

To do this with the PuTTY gui, it’s basically the same as setting up a local port. Use the tree control to the left, click Connection -> SSH -> Tunnels. You’ll need to select remote and enter a source port (58080 in the picture to the right), set the destination address or host+domain name and the port (192.168.1.10:80 in the picture to the right) and click ‘Add’. You also need to click the check both of the boxes next to “Local ports accept connections from other hosts” and “Remote ports do the same (SSH-2 only)”. Your new port should appear in the list above as ‘R58080:192.168.1.10:80’. Be sure to go back to your session and click ‘Save’ of you want the port to be created every time you open the session.

If you are scripting this setup, use the -R switch along with your source port, destination IP/host and the destination port. Using the scenario from above, you forward remote port 58080 on ssh.server.com to port 80 on your internal home web server with the IP 192.168.1.10 like this:

putty -R 58080:192.168.1.10:80 alice@ssh.server.com

And finally, the syntax is the same with plink:

putty -R 58080:192.168.1.10:80 alice@ssh.server.com

The only gotcha with scripting your remote port drop with putty/plink is that I don’t think that there is a command line switch for enabling connections from other hosts, so you have to enable the remote port sharing on the SSH server side.

Making Local and Remote Ports Accessible to other hosts

Sharing your remote and local hosts lets you set up your SSH tunnel on one host and then connect to the tunnel from a different host.

In the case of a local port, you could initiate the SSH session on your home Linux server, and then connect to that port from your Windows workstation. This is handy if you are tunneling RDP and you don’t have PuTTY available on your Windows box. Although PuTTY is super portable so it’s dead simple to smuggle it onto the most locked down of Windows machines.

In the case of the remote port, it’s pretty much mandatory for the web server or dropped box use cases. You can still script the connection, you just have to modify your sshd_config file on your SSH server. On a Debian-esque server you do this by using sudo or su to become root and then type:

nano /etc/ssh/sshd_config

You then add the GatewayPorts option. You can put it anywhere in the file, but I prefer to keep it in the first few lines of the file where entries for port configuration are.

# What ports, IPs and protocols we listen for
Port 22
GatewayPorts yes

Then save the file and restart SSH:

systemctl restart ssh

Or on Debian 9, you use ‘service’ to restart SSH:

service ssh restart

I am sure that this option is a big security risk, so I recommend a cheap low powered VM dedicated specifically to bouncing SSH connections. I also recommend securing it with SSH keys. If you are looking to script SSH connections that are secured with SSH keys, I recommend not setting a passphrase on your private key. You can include your private key on the putty/plink commandline with the -i switch:

putty -L 13389:192.168.1.10:3389 alice@casa-alice.dynamic.DNS -i c:\path\to\your\key\key.ppk