Problems logging via SSH to the honeypot

[bontchev]

I have set up a honeypot to accept any user credentials:

auth_class = AuthRandom
auth_class_parameters = 1, 1, 0

Today I noticed in the logs that login attempts often fail. So, I started investigating by trying to login to the honeypot via Telnet and SSH, using the username foo and the password bar.

Logging in over Telnet works as it should. I get a login prompt, then a password prompt, the credentials I enter are accepted and I am logged in.

Logging in over SSH, however, gives strange results. If I do

ssh foo@honeypot_ip

everything works as it should - I am asked just for a password, the password bar is accepted and I am logged in.

However, if I do just

ssh honeypot_ip

I am not asked for a username. I am still asked for a password only and no matter what I enter, I am not logged in.

Any ideas what might be the problem? If no username is specified to ssh, it should prompt for it, no? (On real machines when I open SSH access, one of the first things I do is disable password access and leave access by public keys only, so I am not sure what is supposed to happen.)

[micheloosterhof]

If you don't specify a username, the SSH client on Unix will use your local username. This should show up in the authentication logs.

…

On Fri, Feb 16, 2018 at 22:17 Vesselin Bontchev ***@***.***> wrote: I have set up a honeypot to accept any user credentials: auth_class = AuthRandom auth_class_parameters = 1, 1, 0 Today I noticed in the logs that login attempts often fail. So, I started investigating by trying to login to the honeypot via Telnet and SSH, using the username foo and the password bar. Logging in over Telnet works as it should. I get a login prompt, then a password prompt, the credentials I enter are accepted and I am logged in. Logging in over SSH, however, gives strange results. If I do ssh ***@***.***_ip everything works as it should - I am asked just for a password, the password bar is accepted and I am logged in. However, if I do just ssh honeypot_ip I am *not* asked for a username. I am still asked for a password only and no matter what I enter, I am *not* logged in. Any ideas what might be the problem? If no username is specified to ssh, it should prompt for it, no? (On real machines when I open SSH access, one of the first things I do is disable password access and leave access by public keys only, so I am not sure what is supposed to happen.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#677>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABA4g-QwOyvss-5VNDCSBu10Eop7JZKpks5tVcY2gaJpZM4SIuiA> .

[bontchev]

OK, that explains why I wasn't asked for a username. But why was I not logged in, given that the honeypot is configured to accept any credentials - and that it did work that way when I was supplying explicitly a username?

[micheloosterhof]

Did you check the Cowrie logs of your interaction?
If SSH reused your existing user id, and the honeypot was not set up to allow that userid, that would not have been a valid login.

[bontchev]

Yes, the log shows a username equal to my username on the computer from which I conducted the test and a password equal to the password I entered - just as you said. But why does the login attempt fail, given that I have configured the honeypot to accept any credentials? This setting in the config applies both to the SSH and the Telnet logins, right?

[micheloosterhof]

How did you configure the honeypot to accept any credentials?

[bontchev]

See my original message - in cowrie.cfg, I set

auth_class = AuthRandom
auth_class_parameters = 1, 1, 0

This definitely works for Telnet - I've tested it. I assumed that it would also work for SSH - is that not the case?

[bontchev]

OK, I am having this problem with Telnet now, too.

Apparently, there is something wrong with the logic of caching credentials. Once you log in with a new username/password pair (as long as it is a new username, the above setting will let you in), these credentials are remembered and you can't log in again with the same username and a different password.

I thought that this was supposed to happen only if the 3rd paramter of auth_class_parameters was a positive number? What is the proper way of instructing the honeypot to allow logins with any credentials, regardless of whether they have been used before or not?

[micheloosterhof]

I don't know; i didn't write that part. You'll have check out the code to see what it's doing.

…

On 23 February 2018 at 21:15, Vesselin Bontchev ***@***.***> wrote: OK, I am having this problem with Telnet now, too. Apparently, there is something wrong with the logic of caching credentials. Once you log in with a new username/password pair (as long as it is a new username, the above setting will let you in), these credentials are remembered and you can't log in again with the same username and a different password. I thought that this was supposed to happen only if the 3rd paramter of auth_class_parameters was a positive number? What is the proper way of instructing the honeypot to allow logins with any credentials, regardless of whether they have been used before or not? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#677 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABA4g0t5pdkJs6C6yf9lgbf5nekWjbb3ks5tXvJIgaJpZM4SIuiA> .

[SecPascal]

I wrote that code ;-)

(the AuthRandom class in https://github.com/micheloosterhof/cowrie/blob/master/cowrie/core/auth.py)

The AuthRandom class is IP address focused, once a login succeeds that username/password is fixed for that IP address. If someone returns from the same IP the stored username/password is verified.
It is also possible to access with the same username/password pair from another IP if it is still in the cache (hence the cache parameter). Otherwise the same random parameters are applied again for a new IP address.

So the caching is created to provide access for a common pattern: first a scan is performed from some IP, then later the successful combinations are used from another IP.

If you want a pure random access, you'll have to write another authentication class.

[bontchev]

@SecPascal, thanks for the explanation. @micheloosterhof, perhaps put something like this in cowrie/cowrie/core/auth.py?

class AuthAny(object):
    def checklogin(self, thelogin, thepasswd, src_ip):
        """
        Allow any username/password combination
        """
        return True

[micheloosterhof]

Sure, Please send a pull request

…

On Sat, Feb 24, 2018 at 12:53 Vesselin Bontchev ***@***.***> wrote: @SecPascal <https://github.com/secpascal>, thanks for the explanation. @micheloosterhof <https://github.com/micheloosterhof>, perhaps put something like this in cowrie/cowrie/core/auth.py? class AuthAny(object): def checklogin(self, thelogin, thepasswd, src_ip): """ Allow any username/password combination """ return True — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#677 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABA4gz011zM_FfulXcn0ci3jcoKu-aKOks5tX84KgaJpZM4SIuiA> .

[bontchev]

I am afraid that I am not familiar enough with the whole authentication logic. Probably some other changes have to be made, too. If I just add the above class and set auth_class = AuthAny in cowrie.cfg, I am getting strange errors in the log, like

2018-02-24T09:59:57+0000 [-] 'root' failed auth 'password'
2018-02-24T09:59:57+0000 [-] Traceback (most recent call last):
          File "/home/cowrie/cowrie/cowrie-env/local/lib/python2.7/site-packages/twisted/conch/ssh/userauth.py", line 180, in ssh_USERAUTH_REQUEST
            d = self.tryAuth(method, user, rest)
          File "/home/cowrie/cowrie/cowrie-env/local/lib/python2.7/site-packages/twisted/conch/ssh/userauth.py", line 153, in tryAuth
            ret = f(data)
          File "/home/cowrie/cowrie/cowrie/ssh/userauth.py", line 97, in auth_password
            IConchUser).addErrback(self._ebPassword)
          File "/home/cowrie/cowrie/cowrie-env/local/lib/python2.7/site-packages/twisted/cred/portal.py", line 119, in login
            return maybeDeferred(self.checkers[i].requestAvatarId, credentials
        --- <exception caught here> ---
          File "/home/cowrie/cowrie/cowrie-env/local/lib/python2.7/site-packages/twisted/internet/defer.py", line 150, in maybeDeferred
            result = f(*args, **kw)
          File "/home/cowrie/cowrie/cowrie/core/checkers.py", line 78, in requestAvatarId
            credentials.ip):
          File "/home/cowrie/cowrie/cowrie/core/checkers.py", line 122, in checkUserPass
            theauth = authname(self.cfg)
        exceptions.TypeError: object() takes no parameters

[micheloosterhof]

I recently changed the way configuration informatin is passed. Try without the (object) in the function definition.

[bontchev]

I am not convinced that the problem is there. I used the master branch and the classes UserDB and AuthRandom there both have an object argument. I was trying to construct an equivalent class with a checklogin function that always returns success.

Perhaps I need to define an (empty) __init__ constructor? I didn't bother with it, because I don't have anything to initialize there.

[SecPascal]

Isn't it easier for your goal to just use the UserDB class and change it such that it also accepts a wildcard for usernames?

So just in auth.py line 74 change:
if login == thelogin and passwd in (thepasswd, b'*'):
into
if login in (thelogin, b'*') and passwd in (thepasswd, b'*'):

and add a *:x:* entry in userdb.txt
Then it will allow any username/password combination unless explicitly denied with a ! entry.