[asterisk-users] How to allow AMI access to Originate yet deny Application: System

Alex Villací­s Lasso a_villacis at palosanto.com
Mon May 20 09:48:45 CDT 2013


El 15/05/13 10:10, Alex Villací­s Lasso escribió:
> While doing a security audit on a system I maintain, I stumbled upon an unvalidated use of a variable to compose an Originate request to the local Asterisk instance via AMI. Taking as an example an earlier exploit for FreePBX, I realized that this, 
> combined with Application: System as an injected value, could allow arbitrary code execution. I am in the process of fixing all instances of this bug in our system. However, there are third parties that plug into our system, and that reconfigure the 
> manager.conf file to allow remote access to AMI logins that allow Originate (by default, the manager.conf remains configured to deny login to any system except localhost). I want to have a guideline on how to proceed in order to make these applications 
> work, without allowing malicious users to compromise the system. I know that one way to proceed is to deny remote access to AMI, and build an application-specific proxy that will perform the Originate on behalf of the remote requester, after filtering 
> the values. However, I want to know if there is a simpler way to remove the danger of code execution while allowing applications to use AMI to place calls.
>
> The intended scenario is that a remote desktop application (for Windows) is configured with the AMI credentials, and connects over the LAN to Asterisk in order to place calls and otherwise monitor the system. The attack I want to protect against is that 
> of a malicious user that collects the credentials from the desktop application and proceeds to use the Application: System trick. I know of the SSL support for AMI, but it will not protect against a malicious end user.
Is this question too basic, or just cannot be done other than with the proxy approach?



More information about the asterisk-users mailing list