August Update to ssh-keygen breaks puttygen

Update From Kali Team: 10/2/2018

Everything you need to know is in/usr/share/doc/openssh-server/NEWS.Debian.gz.
  OpenSSH 7.8 includes a number of changes that may affect existing   configurations:
   * ssh-keygen(1): Write OpenSSH format private keys by default instead of      using OpenSSL's PEM format. The OpenSSH format, supported in OpenSSH      releases since 2014 and described in the PROTOCOL.key file in the      source distribution, offers substantially better protection against      offline password guessing and supports key comments in private keys.      If necessary, it is possible to write old PEM-style keys by adding "-m      PEM" to ssh-keygen's arguments when generating or updating a key.

Looks like that puttygen only supports the PEM-style private keys. In any case, it's not a Kali bug, possibly a puttygen one about lacking support of the OpenSSH key format. 

After pulling out my hair all day long trying to figure out the differences between the Kali RasberryPi and Kali Live build on my thumbdrive, I finally realized there was a ssh-keygen update done in August 2018.

To outline the problem let me first outline how I was generating and converting the private keys for ssh.

1. On the host system
1. ssh-keygen -t rsa
1. enter file name
2. enter super secure secret password
3. repeat step 2
2. Copy the file to the client(s) that are logging into the host
2. On the Client
1. Run PuttyGen
1. Import id_rsa (or whatever you named the file)
2. Save private key with .ppk extension

Normally this works just fine but on 10/1/2018 this stopped working for me.  Anytime I got to step 2.1.1 I would be met with an error indicating an unrecognized cipher name.

After much trial and error and testing my google searching ability I came across the last post on a familiar site all the way at the bottom which led me to this conclusion.  The post deals with ed25519 but I was using RSA.  As you will see in the last post it directly states the author does not believe this to be an ed25519 issue.  Using the advice found in the same article I tested the same with RSA.

$ cp ~/.ssh/id_rsa ~/.ssh/id_rsa-for-putty

$ ssh-keygen -p -f ~/.ssh/id_rsa-for-putty
Enter old passphrase: <your passphrase>
Enter new passphrase (empty for no passphrase): <press Enter>
Enter same passphrase again: <press Enter>

Much to my surprise it worked!  Someone much smarter than me might be able to comment on what changed in the August update to ssh-keygen but I know this was working in the March 2018 update I have on my thumdrive.

Video can be found here:

https://youtu.be/q6LmHqdJvuo

Dangers of Split Tunneling and Segmentation Gaps

This overview is an attempt to show the impact of bridging multiple design flaws into an attack to compromise and environment. Although this document will not go into the details of how an attack is carried out it does provide a Proof of Concept (PoC) representing the possibility of an attack. The tools used in this PoC are freely available on the internet and represents only one possible method among many.

Split Tunneling 

Split tunneling, as defined here, is a computer networking concept which allows a mobile user to access dissimilar security domains like a public network (e.g., the Internet) and a local LAN or WAN at the same time, using the same or different network connections.

In some default configurations you might find split tunneling enabled. When segmentation is an issue VPN solutions should be configured to not allow split tunneling. In our test configuration split tunneling is enabled allowing the internet and the corporate WAN to be bridged.

Segmentation

PCI DSS 3.2 states that out-of-scope networks should not have direct interaction with in-scope networks. Typically we would find a firewall blocking all access yet allowing for a jump box to be accessed inside the CDE using a Multi-Factor Authentication (MFA) solution.

When a network has unfiltered access to in-scope systems, including the Cardholder Data Environment (CDE), an attack can be launched from the less secure out-of-scope network. The out-of-scope networks are the typical starting point for attackers or pen testers to base their efforts. The out-of-scope starting point still presents challenges for the attacker as these networks are typically still within the corporate environment. Therefore, corporate firewalls, ACL’s, and other security products are most likely in use to detect attempts to compromise the environment.

Bridging the Gap

In this PoC will find that Split Tunneling is allowed on the VPN solution and there is a segmentation gap between the VPN subnets and the CDE allowing corporate users access to IP addresses and ports inside the CDE. Although the segmentation gap is actually behind a MFA solution for the VPN it still allows for unauthorized users direct access which brings the VPN subnets into scope.

The largest danger is when the segmentation flaw is combined with split tunneling. If corporate user were infected with some sort of Remote Command Execution (RCE) tool through a web page, email, or some other means such as social engineering, an attacker who could obtain a reverse shell on the corporate laptop would have access to the CDE. The attacker would not have to enter through any type of MFA solution but rather wait for the corporate user to make the VPN connection.

The attacker could be anywhere in the world with internet access connecting through the laptop to launch an attack. Any traffic would entering the CDE would then be initiated from the corporate laptop thereby having a high probability to not set of any monitoring alerts.

PoC

In our simplified example we are using NCAT to send a remote shell to an attacker who resides on the internet. This tool represents how a typical payload would reach out to a Command and Control (C&C) server or an attacker’s laptop.

Once the connection is made on the attackers system we can see they now have command and control of the laptop through the VPN and can connect to the CDE through the segmentation gap an start to enumerate IP addresses and ports.

Summary

In this PoC we see how an attacker who has successfully landed a payload on a corporate laptop can access the CDE environment through a misconfigured VPN solution that allows split tunneling and combined with overly permissive firewall rules which allow VPN traffic to connect directly to Ports and IP addresses inside the CDE.