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

[Randall]

On 03/13/2012 11:06 PM, Dave Platt wrote:
>> 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.

this will be of little use in this situation, the location is a shared 
office space/building in Vietnam and the local hands i have already 
checked our computers for soft phones, but quit possible some machines 
got swapped there or some local admin installed it somewhere  for 
testing purposes... and the local hands i have, not really usefull 
explaining them to look up the meaning of "packet tracing"

>
> 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!

this was my original idea yes, but how can i call it without it being 
registered?

>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                 http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-users