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