Requiring CERT ADD to use only the fingerprint currently connecting with

[maroonbells]

Proposing that /nickserv CERT ADD either change so that it does not accept 'fingerprint' as a parameter, or offers this as a network's setup option.

This would be similar to how Anope used by SwiftIRC does, where nickserv ignores the 'fingerprint' parameter and instead uses the fingerprint of the client certificate you used to connect, so would require you to connect using a certificate before SASL External would accept the fingerprint.

With the current behavior, there's not the guarantee that SASL External is logging someone into an account who both possessed the certificate being used and who also ever possessed the nickserv password for that account.

--

The only downside for this change is that it requires people reconnect to the server while their client has the certificate installed, rather than being able to swap certificates multiple times without requiring any reconnecting.

Under the proposed behavior, the syntax changes to "/nickserv CERT ADD", where it ignores any supplied fingerprint, and instead adds the certificate you're currently using. The only way other than breaking the crypto for the attacker to use SASL External to access your account without having your nickserv password - would be if they can arrange for you to install a certificate into your client for which they control the private key.

For many legitimate users, they would be reconnecting anyway, as a way to input their fingerprint without all those colons.

--

This avoids the exploit where someone can be tricked into adding a fingerprint to their account for which they don't have either the public or private key. While someone could be tricked into giving away their nickserv password, that problem can be solved by changing the password.

This issue involves a string stored in a Nickserv setting which is unlikely to be looked at for a very long time, so people could easily not notice it. This attack also doesn't interfere with that person's ability to have their 'real' fingerprint also stored in that same nickserv setting, since some users have the need to use multiple certificates for multiple devices. Also, this vulnerability remains even after someone changes their nickserv password.

In addition to persuading someone to type a command which they don't understand, another avenue for this exploit is to take advantage of the 'announce' style of scripts which take strings from external sources and PRIVMSG them to channel. This would include scripts that display the title of a url, or even display tag information in an mp3 being listened to. If someone can be tricked into sending a PRIVMSG of a string containing an embedded $crlf, the trailing portion is treated as a server command, which could contain the 'CERT ADD fingerprint' command if the portion preceding the $crlf is short enough.

The attacker would not need to even be logged in for the exploit to be triggered, and they can later check if someone has taken the bait. From their own account they can see what happens when they try to add that fingerprint, and see whether nickserv refuses to allow them to add a fingerprint which has already been added to someone else's account. They could then login later using SASL and discover whose account they were logged into. Since they're logged into nickserv without a password, they could then change that account to have a different fingerprint, which would allow them to wait for the next MP3 victim to add the original fingerprint to their account. This would allow them access to an account without needing to change the email address or the password which would be much more likely to be noticed, and wouldn't require them to even know what the nickserv password is.

[glguy]

It seems that any of these arguments would apply to someone overriding a password with "SET PASSWORD".

The way to deal with confirming important changes can be seen in the case of DROP commands that require a confirmation code to be sent.

It was only a few days ago that I added a new mIRC client to my account by generating a fresh certificate in client, and then adding that fingerprint from another already logged in client. This is way better than ever having to enter a plain password on the new computer to get it connected for the first time.

mIRC isn't the only client that has this handy internal certificate generation feature.

[aaronmdjones]

Right, tricking the user into executing CERT ADD foo is no different to tricking them into executing SET PASSWORD bar.

Furthermore,

While someone could be tricked into giving away their nickserv password, that problem can be solved by changing the password. [...] Also, this vulnerability remains even after someone changes their nickserv password.

... this one can be solved by removing the fingerprint.

another avenue for this exploit is to take advantage of the 'announce' style of scripts which take strings from external sources and PRIVMSG them to channel. This would include scripts that display the title of a url, or even display tag information in an mp3 being listened to. If someone can be tricked into sending a PRIVMSG of a string containing an embedded $crlf, the trailing portion is treated as a server command, which could contain the CERT ADD fingerprint command

It could also contain a SET PASSWORD command. In either case, the account is immediately compromised. Also, a changed password is no more noticeable than an added fingerprint, because NickServ/SASLServ will send a notice to all current connections logged into your account when someone logs into it from a new connection, regardless of what credential they used to login.

[maroonbells]

Having an email alert sent whenever a cert is added, rather than requiring a confirmation code, is probably an acceptable solution.

This is completely different than someone changing your password using SET PASSWORD. And maybe a SET PASSWORD change should also be a reason for an email alert.

For someone who had never tried installing a certificate, they would have no thought to look at CERT LIST to see if there's any fingerprints there. Having fingerprints is also not mentioned in the reply of a /whois against yourself.

While someone using SASL External may not know if their nickserv password has been changed by SET PASSWORD, this exploit also works against people who don't know that certificates even exist, and I guarantee they'll notice the next time they try to nickserv-pass or sasl-plain login if someone has changed their password.

What you're talking about is the idea that someone breaking into a computer system would immediately change the password to lock the real owner out.

What I'm talking about is that they would create a hidden user with root privileges who can connect at-will, regardless if the real owner changes their nickserv password. Yes they are sent a server notice if someone logs into their account while they're logged in, but that notice can easily scroll away from view if it happens while they're not at the keyboard, and the notice isn't there if it happens while they're offline. Once an attacker uses SASL External to login and discover whose account has the certificate attached to it, they can switch the fingerprint to use one of their other pet certificates, and then they can monitor that user to see when they're more likely to be offline.

[tacerus]

Being able to provide a fingerprint as a parameter is very useful for bootstrapping an account. I use a certificate-only IRC bouncer setup - when I configure a new network, I first use a regular client to register and CERT ADD the fingerprint, then enable the bouncer.