There are some well known SIP extension enumeration vulnerabilities in different VoIP servers, specially in Asterisk. This brute-force vector is based on the study of the authentication responses of the target server. Sometimes its replies are different in the case that the client uses a valid extension, so it's easy to discover them.
This vector is normally classified as a low security risk. Moreover we're moving towards a federated SIP environment, in which the extension is the public email address of the user. But it's still important in some cases:
This vector is normally classified as a low security risk. Moreover we're moving towards a federated SIP environment, in which the extension is the public email address of the user. But it's still important in some cases:
- To guide next steps during a penetration test. In example, you can use the discovered extension to reduce the number of attempts in the phase of SIP extensión brute-force.
- Some RCE (Remote Code Execution) exploits need a valid extension to work.
After a little research, these are the known vulns:
- CVE-2009-3727: It's quite old and it's practically not present in real environments. It's still not implemented in Bluebox-ng, waiting for the complete re-write of the SIP stack in which is working Damián.
- CVE-2011-2536: It's much more common than the last one. The option "alwaysauthreject", which the CVE speaks about, is disabled by default in old versions of Asterisk and a common bad practice in actual ones. Bluebox-ng implements it in the "sip-brute-ext" module. In this old post I deep a bit more in the used method.
- (There is no CVE): This technique uses INVITE packets, there are some situations in which Asterisk allows the same goal even with the parameter "alwaysauthreject" enabled. They were discovered by Francesco Tornieri and published in packet storm. Now, the same Bluebox-ng module implements it. So @dvirus, you can now use it against your Busy Tone VulnPBX virtual machine ;).
- CVE-2011-4597: It's similar to the other ones, but this time the server (Asterisk) answer to a different port when a valid extension exists due to an specific NAT related setup. This technique is supported through "sip-brute-ext-nat" module.
Finally I've also solved an important problem with the asynchrony in "sip-brute-pass" module which was very annoying to deploy a serious penetration test. :)