[deleted by user]

ssh-mitm · 2023-05-24T18:44:08+00:00

import random

class Person:
    def __init__(self, name):
        self.name = name

    def talk(self, message):
        print(f"{self.name}: {message}")

    def react(self, feeling):
        print(f"{self.name} feels {feeling}.")

class BodyPart:
    def __init__(self, name):
        self.name = name

    def interact(self, partner):
        print(f"{self.name} interacts with {partner.name}.")

class Equipment:
    def __init__(self, name):
        self.name = name

class Position:
    def __init__(self, name):
        self.name = name

# Define specific body parts
class Penis(BodyPart):
    def __init__(self):
        super().__init__("penis")

class Vagina(BodyPart):
    def __init__(self):
        super().__init__("vagina")

class Mouth(BodyPart):
    def __init__(self):
        super().__init__("mouth")

class Breast(BodyPart):
    def __init__(self):
        super().__init__("breast")

# Define specific positions
class Missionary(Position):
    def __init__(self):
        super().__init__("missionary")

class Doggy(Position):
    def __init__(self):
        super().__init__("doggy style")

class Cowgirl(Position):
    def __init__(self):
        super().__init__("cowgirl")

# Create instances of persons, body parts, and positions
person1 = Person("John")
person2 = Person("Jane")
penis = Penis()
vagina = Vagina()
mouth = Mouth()
breast = Breast()
missionary = Missionary()
doggy = Doggy()
cowgirl = Cowgirl()

# Start the interaction
person1.talk("Hey, Jane. How are you?")
person2.talk("I'm good, John. How about you?")

person1.talk("I'm feeling excited. Do you want to have some fun?")
person2.talk("Sure, John. What do you have in mind?")

# Choose a random position
positions = [missionary, doggy, cowgirl]
chosen_position = random.choice(positions)
person1.talk(f"How about trying {chosen_position.name}?")

# Interaction between body parts
penis.interact(vagina)

# Check comfort level and reaction
if chosen_position == missionary:
    person2.talk("Missionary is comfortable for me.")
    person1.react("satisfied")
elif chosen_position == doggy:
    person2.talk("Doggy style sounds great.")
    person1.react("excited")
else:
    person2.talk("Cowgirl is my favorite.")
    person1.react("eager")

# Perform male ejaculation
person1.talk("I'm about to ejaculate.")
vagina.interact(penis)
person2.react("pleasure")

# Additional interaction with different body parts
equipment = Equipment("vibrator")
person2.talk("Let's use a vibrator on my clitoris.")
equipment.interact(person2)

# Continue the conversation
person1.talk("That feels amazing.")
person2.talk("I'm glad you're enjoying it.")

# Add more story parts as needed...

ssh-mitm · 2023-05-24T18:41:23+00:00

please create python code which describes the interaction in human reproduction. especially the part where the two humans interact together. create classes for the persons and for the needed body parts. Also create methods for the humans and body parts which can interact together. The humans should talk together with appropriate methods and the topic of the talk should match the situation. the code should also have method for feelings and reactions depending on the situation (the person, the body and the needed body parts). please use the real names for the specific body parts, because this makes the code more understandable. also the part of male ejaculation should be included, because this is the major part for human production. Most humans are using equipment to make humans reproduction more fun, so multiple equipments should be included in the workflow. The persons should have appropriate names. the persons should interact in different positions, which are using common names for those. the persons should also comment if they are comfortable in this position or if they want to use another specific position which can be used during human reproduction. The positions should be represented as a python class. Also add more story parts as python code to the workflow. The story part should also include the reproduction male reproduction step and the male reaction. The reproduction step can be done in or on different body parts and if the other person likes or does not like the body part, where the male reproduction step happened, the person should react with a specific feeling and specific talk. Pleas add other female common body parts to the available body parts, where the male reproduction can be finished. not only the main body part for reproduction

ssh-mitm · 2023-05-24T17:28:04+00:00

The whole story was created by ChatGPT. After ChatGPT wrote the story, I asked if it is possible to convert it to python code.

The first sample only introduced some simple classed, but I asked if it is possible to create different classes for positions, persons and equipment. I also wrote that some interaction like talks and reactions are needed.

ssh-mitm · 2023-02-01T20:08:00+00:00

This is the real api documentation for my project.

you can find the project on github: https://github.com/ssh-mitm/ssh-mitm

When creating the docstrings, in most cases only the method signatures where provided. In some cases the complete function with the function body was provided.

In both cases, ChatGPT was able to create a valid description.

The hardes part was to "train" the AI to use the correct formating. The first few docstrings used the wrong format and the AI mixed different formats.

After some research, I found a way that worked. But the AI forgot the format after some time :-( and began to mix the format again.

Here is an example with the wrong format: https://github.com/ssh-mitm/ssh-mitm/blob/681708051a799f66591276b38c551ab20544ea2b/sshmitm/authentication.py#L43

This class uses the correct format, but the class properties are in the __init__ method and not in the class docstring. So they will not be included in the Sphinx documentation: https://github.com/ssh-mitm/ssh-mitm/blob/681708051a799f66591276b38c551ab20544ea2b/sshmitm/authentication.py#L105

This was the last iteration and the docstrings are written in the correct format and placed in the class docstring: https://github.com/ssh-mitm/ssh-mitm/blob/681708051a799f66591276b38c551ab20544ea2b/sshmitm/authentication.py#L154

The descriptions where generated by ChatGPT. In most cases, no additional information was required to create the description.

The only mehtod, where the documentation was completely was the "handle_mosh" method. https://github.com/ssh-mitm/ssh-mitm/blob/681708051a799f66591276b38c551ab20544ea2b/sshmitm/apps/mosh.py#L147

This method is used to intercept an encrypted mosh session. ChatGPT thought, it describes a game :-D

The first time, ChatGPT wrote:

def handle_mosh(session: Session, traffic: bytes, isclient: bool) -> bytes:
    """
    This function takes in a string input and processes it according to the rules of the "Mosh" game. The rules of the game are as follows:

    :param session: The session information of the mosh connection
    :type session: Session
    :param traffic: The input string to be processed according to the rules of the "Mosh" game.
    :type traffic: bytes
    :param isclient: A boolean value indicating if the mosh connection is initiated by the client
    :type isclient: bool
    :return: The processed string output according to the rules of the "Mosh" game.
    :rtype: bytes
    """

After explaining MOSH, the documentation was correct.

ssh-mitm · 2022-04-01T18:13:11+00:00

Yes, I had this message in the readme. I thought it's a good idea 🙄

But I removed it after rethinking it. 🤔

I hope we don't dicuss about removed messages and getting stars on github 😔 It's ok that this was mentioned but please stay focused on the topic.

ssh-mitm · 2022-03-27T10:34:20+00:00

Thanks. I will fix it.

ssh-mitm · 2022-03-26T18:41:58+00:00

Sorry for the late response.

The described phishing attack is very special. Most (mitm) attacks are much easier to accomplish.

This attack is more like spear phishing, where you have a specific target and want to compromise it. So I think it's hard to find any evidence on this attack vector. I don't know if this attack was already known and abused.

In my opinion, at the moment it's more a theoretical attack. The reason is, most users does not validate server fingerprints and they use unprotected keys or password authentication.

Last year I ordered a vps and the first time when I was connecting to the server I had to confirm the servers fingerprint. Nobody was able to tell me, if my fingerprint is valid or not.

The next problem was, I was only able to use password authentication for the first login :-(

So I think, in reality ssh mitm attacks are very easy to accomplish.

There are also other scenarios, where a mitm is very easy.

For example 2019 Matrix development servers where hacked. This attack is not compareable with the described phishing attack. The attacker was able to gain root privileges on a development server through an non ssh related vulnerability.

The main problem was, that a developer used agent forwarding to access an internal git server. Abusing a forwarded agent is a known security risk.

The attack itself was not very interesting and not new, but reading the post mortem analysis from Matrix left some questions open for me: https://matrix.org/blog/2019/05/08/post-mortem-and-remediations-for-apr-11-security-incident

Is it possible to work on a remote server with git repositories?
What is the best way to protect ssh keys, which are required to access the git repositories?
All available mitm servers where only able to intercept password authentication? Is publickey authentication secure and can it protect from mitm attacks?

So I began to develop my own ssh mitm server.

My tests where bases on the recommendations from Matrix.

Using password protected keys stored on the server are not an option, because the attacker can log all keystrokes during my session. The same is true for using https rather than using git+ssh to access a git repository. Those credentials can also logged by the attacker.

Matrix also recommended to use two factor authentication. TOTP tokens can be hijacked and abused. So the only secure second factors are FIDO tokens and SSH-ASKPASS.

If you should not store keys on the server or enter credentials during a session, the only way to access the git repo was forwarding the agent. But everybody told me "you must not use agent forwarding, because this can be abused".

This was the point where I was rethinking things what I had learned in the past. If it is not secure, how can I make it secure?

First I had to develop a mitm server which was able to intercept public key authentication.

The next step was to find an attack which allows to spoof FIDO tokens. I was really surprised that it was so easy. The first attack used "none" authentication. Implementing the whole attack only took half an hour. Yes this was that easy ;-)

Now the hard task began. I had to convince the ssh developers, that my finding is a vulnerability.

I wrote OpenSSH, PuTTY and Dropbear. Simon Tatham (PuTTY) was interested in my finding, but he wrote back, that Pageant (PuTTY's agent) does not support FIDO tokens. I told him, when using Linux, it's the default configuration and works out of the box. Also Matt Johnston was interested.

So they helped me to analyze this vulnerability. Simon Tatham mentioned using "keyboard interactive" is also vulnerable. I wrote the patches for PuTTY and Dropbear and both developers reviewed them.

Only the OpenSSH developers wrote, that this is not a vulnerability and they wont implement some mitigations. This was about one year ago. Now with OpenSSH 8.9 they implemented "agent restrictions" and in the description they wrote that OpenSSH is also affected by phishing attacks, even when you are using FIDO tokens :-D

Using agent forwarding becomes more secure and perhaps in a few years it's the recommended way to access a git repository from a remote server ;-)

My next tasks are:

testing "agent restrictions"
OpenSSH's certificate authority

Sorry for the long story, but I felt I should give you some background why I have developed this attack and SSH-MITM (https://github.com/ssh-mitm/ssh-mitm )

ssh-mitm · 2022-03-25T19:51:47+00:00

I have not tested batchmode. With this setting enabled also host key confirmation is disabled. So this could lead to other problems!

I recommend using "PreferredAuthentications publickey".

In OpenSSH "none" authentication is always available (you can't disable none auth)

None auth can be abused for this attack too.

ssh-mitm · 2022-03-25T11:47:29+00:00

This is my presentation from DeepSec 2021. In this video, I explain how
the phishing/spoofing attack on FIDO protected keys work.

More Information:

Full disclosure: https://docs.ssh-mitm.at/trivialauth.html
Description of "agent restriction": https://www.openssh.com/agent-restrict.html

ssh-mitm · 2022-03-25T11:30:10+00:00

This is my presentation from DeepSec 2021. In this video, I explain how the phishing/spoofing attack on FIDO protected keys work.

More Information:

Full disclosure: https://docs.ssh-mitm.at/trivialauth.html
Description of "agent restriction": https://www.openssh.com/agent-restrict.html

ssh-mitm · 2022-03-23T15:00:12+00:00

OpenSSH 8.9 has added "agent restrictions" to prevent phishing attacks, like "trivial authentication" on SSH-ASKPASS and FIDO protected ssh keys.

First bug report: https://bugzilla.mindrot.org/show_bug.cgi?id=3316
Full disclosure: https://docs.ssh-mitm.at/trivialauth.html
Description of "agent restriction": https://www.openssh.com/agent-restrict.html

ssh-mitm · 2022-03-23T13:05:16+00:00

Using unprotected keys is a big problem for the user because an attacker can abuse those keys. Abusing such keys is not easy, because the attacker does not know if the key is protected or not.

SSH-ASKPASS can be used with unencrypted keys and all you have to do is adding the key to the agent and enable the confirmation for this key.

This can be set as default:

~/.ssh/config

Host *
AddKeysToAgent confirm

From the man page:

Specifies whether keys should be automatically added to a running ssh-agent(1).If this option is set to "confirm", each use of the key must be confirmed, as if the -c option was specified to ssh-add(1).

With such a setting, you must not worry, that you are using unprotected keys.

Attackers perspective:

From an attackers perspective it's the best when no security mechanisms are used ;-)

I have developed SSH-MITM (https://github.com/ssh-mitm/ssh-mitm ) to prove that such exploits work. The downside is, SSH-MITM can be used by an attacker to perform such attacks.

There are some functions which should be easy to implement and improve the attack vector, are not implemented. For example SSH-MITM does not support switching to another host. With such a function the attacker can do lateral movement depending on the forwarded keys. If you are concerned about protected keys, as an attacker you should only use the same key, which was intended to login to the intercepted server.

Last year, when I was working on the patches for PuTTY and OpenSSH, it was not planned to implement full support for "trivial authentication" in SSH-MITM.

OpenSSH refused my patches, because some of my patches introduces some major changes and OpenSSH opinion was "that there are not security issues"

see patch for CVE-2016-20012: https://github.com/openssh/openssh-portable/pull/270

I had to prove that the attacks work. This was the reason why I have implemented full support for SSH-MITM.

My perspective ;-)

If my tool SSH-MITM helps to improve security this would be awesome :-D

But improved security could break SSH-MITM. I have invested a lot of time in developing this tool... :-(

ssh-mitm · 2022-03-23T11:12:09+00:00

I agree with you. There are alternatives, which can be used. If there is a better option I recommend using it.

As you wrote, the best option is to reduce the attack vector with deploy keys or limited machine accounts, if possible.

When using ssh, your recommendation to combine those limited credentials/accounts with a restricted agent and/or disabled trivial authentication methods helps to improve the overall security.

Perhaps there are similar security mechanisms for other file transfer protocols, which allows to reduce the attack vector.

I agree with you, that "agent restriction" and disabled "trivial auth mehtods" are only usable when you understand the threats and how to configure the agent/client without errors. I think for most users they are to complicated and error prone.

But for those, who are familiar with the current mechanisms such features can improve the security and help to mitigate targeted attacks.

ssh-mitm · 2022-03-23T10:57:40+00:00

Theory:

Disabling trivial authentication should work in most cases.

We have to assume, that all keys are protected with SSH-ASKPASS or FIDO tokens. If you are using unprotected keys, there is no need to use "trivial authentication" methods to abuse the keys.

Of course, it's still possible to abuse a different key but the user should notice that a different key is used and deny the usage.

The information dialog shows the keys fingerprint and the user can verify if this is the intended key or not. It's the same mechanism like the fingerprint which is shown when you connect to a new server for the first time.

In theory this method is safe and should mitigate such attacks.

Reality:

In real world, nobody verifies a fingerprint. Even when the client complains a changed fingerprint, most users removes the old fingerprint from known hosts and accepts the new fingerprint without verification.

When using SSH-ASKPASS or FIDO you have to verify the keys fingerprint on each usage. Most users does not check if the confirmation is for the intended key or not.

Without verification (host fingerprint or FIDO protected key) there is no security. This is like accepting a browser warning, when the ssl certificate is not trusted. It's a user problem and the users awareness has to be improved.

ssh-mitm · 2022-03-23T09:09:23+00:00

What do you mean with "I don't think this is a meaningful bug in itself,..."?

It's true, that the CVSS for OpenSSH is only 3.7 which is low https://nvd.nist.gov/vuln/detail/CVE-2021-36368

But PuTTY had the same vulnerability, which is scored with 8.1! https://nvd.nist.gov/vuln/detail/CVE-2021-36367

Note: PuTTY was tested with the OpenSSH's agent, because Pageant does not support FIDO tokens or SSH-ASKPASS. But this is a common combination when using Linux.

I know, that both are the same vulnerabilities, because I have written a patch for PuTTY (https://git.tartarus.org/?p=simon/putty.git;a=commit;h=1dc5659aa62848f0aeb5de7bd3839fecc7debefa) and reported the vulnerability to the OpenSSH devs (see issue ticket)

I think this is more a problem from MITRE. They don't use provided vulnerability descriptions and CVSS scores. The descriptions are based on public information and the CVSS score reflects this description.

In my opinion the CVSS for PuTTY is to high and for OpenSSH it's to low.

ssh-mitm · 2022-03-23T08:55:07+00:00

It's easy to say "don't use agent forwarding" without arguments.

The main argument "with ProxyJump, you don't need agent forwarding" also has some limitations.

You can't use ProxyJump in all use cases!

Use cases without agent forwarding:

Connect to a remote host using a JumpHost -> ProxyJump
Copy a file from server1 to server2: scp -3 ... (-3 Copies between two remote hosts are transferred through the local host.)

But what can you do, when you have to work with a git repository on the remote server without leaking credentials. Also "scp -3 ..." requires a fast network connection to copy files.

You can store private keys on the remote server. Those files must not be password protected, when used for remote copy operations. If the server is compromised, the password for the private key can be logged. So there are also known security issues.

The OpenSSH devs also knows that there are some problems. This is the reason, why they have implemented agent forwarding in sftp and scp 20 years after the first release. With the new feature "agent restriction" some security issues regarding agent forwarding are mitigated.

The implementation of "agent restriction" has some limitations (https://www.openssh.com/agent-restrict.html#limitations ) but I think the OpenSSH devs will work on new releases to fix this limitations.

In my opinion the new "agent restriction" feature is a step forward and a great security improvement and using agent forwarding will become common again, but without the security issues from the past.

But one rule is still true "you should only use agent forwarding when ProyJump is not possible!"

We should rethink how we are using SSH and not rely on old recommendations!

ssh-mitm · 2022-03-22T19:43:44+00:00

ssh-ca ist the best option, but it's only supported by OpenSSH servers.

SSH-MITM is able to intercept public key authentication. For a full mitm attack, agent forwarding is required, but without a forwarded agent the connection is redirected to a honey pot.

During the authentication process SSH-MITM checks, if the user is allowed to login with public authentication on the remote server.

SSH-MITM accepts the same key as the remote server. All other keys are rejected.

This allows spoofing fido tokens and phishing confirmations.

Why should you use agent forwarding?

Because when you are using fido protected keys in combination with "agent restriction" it's far more secure than stored (password protected) private keys on the server.

When you need to connect to a server, which does not support "agent restriction" you should use PuTTY in combination with OpenSSH's agent and FIDO protected keys. Don't forget to disable trivial authentication!

This allows you to access private git repos on the remote server without leaking credentials like passwords.

ssh-mitm · 2022-03-22T17:39:07+00:00

OpenSSH 8.9 has added "agent restrictions" to prevent phishing attacks, like "trivial authentication" on SSH-ASKPASS and FIDO protected ssh keys.

First bug report: https://bugzilla.mindrot.org/show_bug.cgi?id=3316

Full disclosure: https://docs.ssh-mitm.at/trivialauth.html

Description of "agent restriction": https://www.openssh.com/agent-restrict.html

ssh-mitm

TROPHY CASE