[asterisk-users] how to show used "wrong password"

[Dave Platt]

> Ouch.  That isn't going to be so easy to spot, then!  You would have to guess 
> a bunch of likely passwords, fake up a challenge with some known nonce, and  
> compare the response against those you would expect with each of the various 
> possible passwords.  (You've already got the Source Code to do all this, of 
> course.)
> 
> You'll have to try the selective unplugging method instead .....

There may be a way to do this, even in the face of the nonce-and-hash
security system.

As I understand it:  when a system (re)registers with a good
password, what you'll typically see is:

-  A registration request from the client (with the client's ID
   in the SIP parameters)

-  A response from Asterisk, saying something on the order of
   "Stale authentication.  Try again.  Here's a new nonce for you."

-  Another registration request from the same client, specifying
   the newly-issued nonce, and having a hash based on that nonce and
   the shared secret.

-  An "OK" response from Asterisk.

When a system (re)registers, and has the wrong password/secret,
the exchange will be different.

-  A registration request from the client (with the client's ID
   in the SIP parameters)

-  A response from Asterisk, saying something on the order of
   "Stale authentication.  Try again.  Here's a new nonce for you."

-  Another registration request from the same client, specifying
   the newly-issued nonce, and having a hash based on that nonce and
   the shared secret.

-  A response from Asterisk, rejecting the second registration request
   with something like a "bad digest" error.

So, if you examine all of the SIP protocol exchanges taking place,
you should see a whole bunch of successful four-way handshakes (from
clients that have the correct secrets), and an occasional four-way
handshake failure (from the one client that has the wrong password in
its configuration).

You won't be able to tell what password the client is actually trying
to use - that's the whole point of the nonce-and-hash approach -
but you'll be able to identify its client name, and (unless the
far end is using a NAT or proxy) its IP address.

To pin down the actual location of the client, you'll either have
to go there, or have someone at the remote site do some investigation
and (possibly) packet tracing on the LAN.

Or, I suppose one could simply use Asterisk to try to phone the
device or softphone in question, at whatever address it called in
from, and ask whoever answers the phone to disable it!