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