Attacks on SSH not detected when publickey authorization is enforced.

[Christopher Engelhard]

Hi, there appear to be some issues with detecting attacks when the ssh daemon is configured to enforce public key authentication:

Working:

(0) Invalid user (both with and without public key):

sshd[12196]: Connection from <IPv4> port <Port> on <IPv4> port 22
sshd[12196]: Invalid user pi from <IPv4> port <Port>
sshd[12196]: Connection closed by invalid user pi <IPv4> port <Port> [preauth]
sshguard[695]: Attack from "<IPv4>" on service 100 with danger 10.

Not working:

(1) Existing user without valid public key:

sshd[12194]: Connection from <IPv6> port <Port> on <IPv6> port 22
sshd[12194]: Failed publickey for root from <IPv6> port <Port> ssh2: ED25519 SHA256:<Hash>
sshd[12194]: Connection closed by authenticating user root <IPv6> port <Port> [preauth]

(2) Valid user with key but wrong password or other failure authenticating the key:

sshd[12188]: Connection from <IPv6> port <Port> on <IPv6> port 22
sshd[12188]: Accepted key ED25519 SHA256:<Hash> found at /var/lib/ssh/ce/authorized_keys:2
sshd[12188]: Postponed publickey for ce from <IPv6> port <Port> ssh2 [preauth]
sshd[12188]: Connection closed by authenticating user ce <IPv6> port <Port> [preauth]
sshd[12192]: Connection from <IPv4> port <Port> on <IPv4> port 22
sshd[12192]: Received disconnect from <IPv4> port <Port>:11:  [preauth]
sshd[12192]: Disconnected from <IPv4> port <Port> [preauth]

(3) Root with valid key, but root login not permitted

sshd[12531]: Connection from <IPv4> port <Port> on <IPv4> port 22
sshd[12531]: Accepted key ED25519 SHA256:<Hash> found at /var/lib/ssh/root/authorized_keys:1
sshd[12531]: Postponed publickey for root from <IPv4> port <Port> ssh2 [preauth]
sshd[12531]: Accepted key ED25519 SHA256:<Hash> found at /var/lib/ssh/root/authorized_keys:1
sshd[12531]: ROOT LOGIN REFUSED FROM <IPv4> port <Port>
sshd[12531]: Failed publickey for root from <IPv4> port <Port> ssh2: ED25519 SHA256:<Hash>
sshd[12531]: ROOT LOGIN REFUSED FROM <IPv4> port <Port> [preauth]
sshd[12531]: Connection closed by authenticating user root <IPv4> port <Port> [preauth]

For (1), SSHGuard could match

Failed publickey for <User> from <IP> port <Port> ssh2: <KeyAlgo> <Hash>

I don't understand why (3) is not matched, because this has nothing to do with publickey auth, but in any case, one could easily match

ROOT LOGIN REFUSED FROM <IP> port <Port>

(2) is more difficult, because it would involve multi-line matching. It is also somewhat out of scope for SSHGuard, as it involves an attacker having the private keys to that account. The same applies to (3) if that problem only exists with pubkey auth. (1), however, should be matched, since a key-less attack on root is one of the most commonly occurring attacks in my logs, and it would be nice if those guys were banned, even if they have no chance of actually breaking in.

Maybe someone can test whether (3) also occurs when using password logins. I can't, because on Fedora, this test gets handed off to PAM, and with UsePAM=no nothing works properly ...

Version: sshguard-2.2.0 on Fedora 28

[Daniel Aleksandersen]

Do you want to attempt a patch for (3), @lcts?

I believe you can use commit d46780116a527394de3d9baa204586a4bea3e63d as a template for what changes needs to be done (sans defining a new service, reuse the existing SSH service). Start by copying a sample of the line you want to match into attacks.txt so you can use test-sshg-parser to quickly test your work.

(2) requires a lot more work and should be split out into its own issue.

[Christopher Engelhard]

Sure, I can do that.

(2) is probably not worth tackling, tbh. If you know the account and have its key, why would you then use the server to crack the key's passcode? That would be insane.

[Christopher Engelhard]

I created a pull request.

I also did some more testing, and there are some caveats to these changes: (1) Following your other rules, I'm matching both ROOT LOGIN REFUSED FROM x.y.z and ROOT LOGIN REFUSED FROM x.y.z [preauth]. This can result in one attempt being counted as 2 attacks. (2) I also added matching for Failed publickey ... . However, if a user has a lot of keys in e.g. ssh-agent, each one triggers this rule, causing the user to be banned. A user really shouldn't do that, but it isn't strictly speaking an attack, so you might not want to include it. An attacker will either have stolen the correct key or have none at all, so it's not that important.

[Kevin Zheng]

Where's the pull request?

[3Yan]

I’ve ran into the same issue (OpenBSD 6.5, sshguard 2.3.1). Is there any progress with it? Can I be of any assistance? I believe it is still important/relevant, as during trials I’ve ddosed my server for a while. Is there any WIP version of the patch? Should I start to try to make a patch from the scratch?

[Kevin Zheng]

@3Yan Unfortunately, this is not currently being worked on. Two things that will help:

• A patch to src/parser/tests.txt that tests the new messages that we care about.
• Patches to src/parser/attack_parser.y and src/parser/attack_scanner.l that would catch these attacks. The SSH stuff is around line 167 in attack_scanner.l. In addition to not breaking existing attacks, try to make sure the rules don't expand the DFA states by too much (you can tell via lex -v, or simply that running lex takes a long time).

[3Yan]

@kevin zheng ok. Thx for quick response.

I received “access denied” when I was trying to create a pull request. Maybe it is error on my side. Please let me know if I am allowed to create the pull requests. I’ve the commit ready in my cloned repo (https://bitbucket.org/3yan/sshguard/commits/6eef76066a6b50d0450b90c3616b674b6393a4cd , hopefully it is ok, I’ve written the code based on cargo-cult approach). Old: 19157/23000 DFA states (306952 words), new: 19191/23000 DFA states (307192 words). Seemed that it worked as it should, hopefully it wont matches things multiple times.

Note to testing (mainly reaction to the first message - 2018-10-06):

ipv6 logs were generated from debian stretch and tested against openbsd 6.5 sshguard v2.3.1
ipv4 logs were generated and tested on openbsd 6.5 and tested against sshguard on openbsd 6.5 v2.3.1

ipv6 layout - got different logs than one mentioned in the initial bug description (maybe newer ssh version or different settings), sshguard was already able to notice these violations.
ipv4 layout - (1),(2),(3) - added single message into tests.txt which catches all of them, added single line to attack_scanner.l to fix the issue.

I compiled the patched git version on the Archlinux and then tested it against the new message present in tests.txt - worked.

[Kevin Zheng]

Update signature for OpenSSH preauth

This new pattern appears in Debian Stretch and OpenBSD 6.5. This partially fixes issue #102.

→ <<cset 036efe21bd46>>

[Kevin Zheng]

I don’t know why you weren’t able to submit a pull request; you should be able to.

I’ve committed your patch with a modified commit message in 036efe2. Thank you for your contribution!

[Kevin Zheng]

Still in progress.

[3Yan]

I’m not experienced with push request and this is my first code on Bitbucket, so probably I’ve done something wrong with it. Thx for incorporating my commit. It was a pleasure for me to contribute.

What are things required to fully resolve the issue? Check of the patched version on newest fedora/ssh? Something else?

[Kevin Zheng]

Looking at the issue description, I think your patch fixes the key issues. Please re-open if we're missing anything.

[Kevin Zheng]

Removing version: 2.2 (automated comment)