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

          Hide
          Walter Doekes added a comment -

          Yuck at reload() calling the cli sip_reload() instead of the other way around. But you didn't do that

          Ok. Your patch looks sane. I added the mandatory null-check for the sip reload in issueA21013_with_null_check.patch.

          I quickly ran the tests against 11.x, and it all seems fixed. Better get a 3rd set of eyes on it and run tests of regular behaviour. Did you run any allowguest and autocreatepeer checks?

          Show
          Walter Doekes added a comment - Yuck at reload() calling the cli sip_reload() instead of the other way around. But you didn't do that Ok. Your patch looks sane. I added the mandatory null-check for the sip reload in issueA21013_with_null_check.patch . I quickly ran the tests against 11.x, and it all seems fixed. Better get a 3rd set of eyes on it and run tests of regular behaviour. Did you run any allowguest and autocreatepeer checks?
          Hide
          Kinsey Moore added a comment -

          The existing tests in the integration testsuite report no problems. allowguest and autocreatepeer look good code-wise after a double check. I have yet to run manual tests on those two settings, but I don't expect any issues to come up for them. I'll get to those tests when I can.

          Show
          Kinsey Moore added a comment - The existing tests in the integration testsuite report no problems. allowguest and autocreatepeer look good code-wise after a double check. I have yet to run manual tests on those two settings, but I don't expect any issues to come up for them. I'll get to those tests when I can.
          Hide
          Kinsey Moore added a comment -

          Testing with allowguest and autocreatepeer looks good with alwaysauthreject enabled.

          Show
          Kinsey Moore added a comment - Testing with allowguest and autocreatepeer looks good with alwaysauthreject enabled.
          Hide
          Walter Doekes added a comment -

          Good. I've been running the patch on a couple of 10.x production machines a couple of days now. Haven't noticed any odd behaviour or customer complaints.

          Show
          Walter Doekes added a comment - Good. I've been running the patch on a couple of 10.x production machines a couple of days now. Haven't noticed any odd behaviour or customer complaints.
          Hide
          Matt Jordan added a comment -

          FYI: The planned security patch date is Thursday, March 7th.

          Show
          Matt Jordan added a comment - FYI: The planned security patch date is Thursday, March 7th.

            People

            • Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development