Asterisk SIP Server, From “Info” to “Ouch”

Carrie Roberts //

ADVISORY: The techniques and tools referenced within this blog post may be outdated and do not apply to current situations. However, there is still potential for this blog entry to be used as an opportunity to learn and to possibly update or integrate into modern tools and techniques.

I learned some new stuff that will make me pay attention to “Asterisk Detection” Nessus informational findings in the future . . .

On an external network scan, Nessus reported two hosts running Asterisk SIP services as an informational finding.

 When entering the IP address in a browser, only a blank page was returned, however I ran dirbuster on it and found a login page at http://<ip address>/mobile.

Looking at the server response for this page showed that extensions and usernames are revealed in javascript.

The IPitomy user manual indicated that a login page exists at http://<ip address>/ippbx on these systems.  This login page is shown in the image below.  

The manual indicated that the default admin credentials are pbxadmin:ipitomy and that the non-admin user username is always their extension with a default password equal to the extension as well. For example, the extension 123 would have a username of 123 and a default password of 123.

The default admin credentials did not work in this case but some of the default user credentials did.  I used Burp Suite’s Intruder functionality to guess the same username and password for extensions 100-999. To set this attempt up in Burp Intruder I used Battering ram attack type to place the same payload in all defined positions as shown below.

On the payloads tab, I set a payload type of “Numbers” and set the number range from 100 to 999 counting by ones.  

Some of the accounts were using the default password. The successful login credentials could be spotted in the intruder results window by comparing the length of the response.  In this case, a length of 361 versus 231 was the indicator.

Comparing response length is often a good way to quickly determine success of an intruder attack but using the grep extract option is a life saver when response length isn’t a good enough indicator.  You can define the portion of the response you want to extract from the Intruder options menu as shown below.

I set the grep extract expression to show any text after “ocation:” and before “Vary:” in order to pick out the location header in the redirect response.

This makes the successful response really stand out as shown below.

With a successful login, a person can configure call settings like call forwarding, view call logs and listen to voicemail.

Lastly, I checked for account lockout by guessing 100 bad passwords in less than one minute immediately followed by a successful login with the correct password.  This means it is likely that other passwords could be discovered through brute-forcing since the user names are known and there is no account lockout mechanism.

All in all, this “Informational” finding for “Asterisk Detection” as reported by Nessus led to the discovery of three vulnerabilities in this case.

1)  Information disclosure of employee first and last names and associated phone extensions on the login page.

2)  Non-administrative access to user accounts through default credentials giving access to call settings and voicemail.

3)  No account lockout to prevent password guessing for known extensions.