how to show used “wrong password”

Home » Asterisk Users » how to show used “wrong password”
Asterisk Users 9 Comments

hi all,

have asterisk set up in combination with fail2ban.
all works as expected only there is 1 extension that is trying to
register with a wrong password causing fail2ban to block the IP address,
normally that is ok behaviour but i have several extensions on that IP
address.

someone has once setup this extension as a test, but it seems to be
impossible to find where it was installed (probably a softphone) and its
a bit far away for me to go check it out.

since there is no way to stop the troubling extension i figured i might
as well let it connect by setting the wrongly used password as correct,
at least in that case the other extensions won’t be blocked and i can
try to call that extension myself.

anyway to see which “wrong password” is being used?

much obliged,

Randall

9 thoughts on - how to show used “wrong password”

  • tcpflow.

    (And don’t underestimate the power of simply disconnecting things until it
    works ….. last thing you disconnected was the faulty one.)

  • This will not help. Assuming we are talking about a SIP REGISTER here,
    the password is *not* sent in the request. Asterisk issues a challenge
    including a randomly generated value (called a ‘nonce’), then the UA
    attempting to register responds to that challenge with an MD5 digest of
    a string composed of various elements, including both the nonce and the
    shared secret (‘password’). Asterisk computes the same digest
    internally, and if they match, then the assumption is that both ends
    know the shared secret.

    By their very nature, digest functions are not reversible; given the MD5
    digest present in an SIP request containing an Authorization header,
    there is no way to figure out what shared secret was used in the
    computation of that digest. Since you know the nonce and the other
    portions of the calculation, you could attempt to try various ‘likely’
    passwords to see if any of them result in the same digest value… this
    is called the brute-force method, and it could take a *very* long time
    to arrive at a shared secret that would allow the endpoint to register.

  • Thanks will give that a try.

    p.s.
    i know the method, only problem that its a time consuming process (in
    this case it includes a 9000 km travel and not all equipment on that
    side is mine)

  • 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:

    in the SIP parameters)

    “Stale authentication. Try again. Here’s a new nonce for you.”

    the newly-issued nonce, and having a hash based on that nonce and
    the shared secret.

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

    in the SIP parameters)

    “Stale authentication. Try again. Here’s a new nonce for you.”

    the newly-issued nonce, and having a hash based on that nonce and
    the shared secret.

    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!

  • 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”

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

  • First of all, white list the IP in fail2ban and you won’t accidentally ban
    the whole office. This can be done by following this guide:
    http://www.fail2ban.org/wiki/index.php/Whitelist

    Second, this is kind of outside the box thinking, so it may not work at
    all, but try setting the NAT on that peer to no, and then tcpdump the
    incoming registration attempts and see if you can see the internal private
    IP address of the packet. If there’s a SIP helper on the far end, this may
    not help. Possibly, remove the secret= line from that peer in sip.conf and
    see if it successfully registers. Again, with the right nat= setting, you
    may be able to tcpdump the communication with that peer and get the private
    IP address so that you can then attempt narrow it down. This is not a long
    term solution, obviously, as it would create a gaping security hole, but
    it’s worth a shot.

  • There’s an interesting option in there: if you remove the ‘secret’, then
    the peer will be able to register. Once it is registered, you can call
    it, and the user/owner/etc. will hopefully be there so you can tell them
    to fix their endpoint.