A few weeks ago I was playing with a blackbox, and I found several problems that cascaded, giving me command execution as root. Since the issue impact open source software and my research was free, I decided to provide a two part analysis of illustrating my research. In this post, I want to illustrate some how hardcoded default configuration settings can inhibit security. The second part to this post will look at the how I identified the issue on the blackbox and successfully exploited the issue.

First of all, default passwords among elements are often common place in the open source world. This post is focused on showing why these defaults can be bad. The thesis is simple:

• Developers: Always make the user change the password after installation.
• Administrators and users: Always change the default password if the service offers authentication of some type

Now lets examine the issue that was discovered. Take a look at the following image captured from a configuration and source code file of the 1.04 branch of FreeSWITCH. Try to understand what the code is doing based on the limited context you are presented.

Service defaults for mod_event_socket found in the config (top) and source (bottom) files.

Do you See What I See?
After examining these excerpts, the reader should be able to discern 2 things. First, by default the password is ClueCon and listens on the 127.0.0.1 as shown in the configuration file. The other observation that should be noted is the default password and default listening IP address are hardcoded. This fact can be insinuated, because if the result of switch_strlen_zero is TRUE then these default values are used instead, respectively. This means that if configuration file is missing the required element, it will be replaced by the default. In a way, this means the module will always be listening, rather than failing. Unless the administrator is aware of these security implications, they are not likely to give these issues a second glance, hence my posts.

Why is this bad?
The default password in every configuration will be ClueCon unless it is changed. If the password is not set, then it is still going to be ClueCon.

But wait doesn’t this run on 127.0.0.1, which is not even accessible from the Internet?
Yes, that is correct, but this fact can lead to a false sense of security, which leads to the next issue at hand.

Apart from the default credentials, there is a command module (mod_commands) that provides a command interface to FreeSWITCH that is also enabled by default. This command interface provides ways to manage calls, service settings, and the best part, execute OS commands. So, if a local or network user knows the password, they can access the interface and execute commands as the FreeSWITCH service user, which could be bad.

How bad?
If FreeSWITCH is running as root, then a local user can run OS commands as root which will escalate into something much worse, like this for example. In the next post, I will discuss the details of how I leveraged this issue to get root command access. (hehe.)

Ok “Mr. Rock’in Rick Roller”, what do you recommend for a mitigation or some kind of remediation?
There are several ways of reducing the likelihood of the issue. The easiest method is to change the password in the configuration file. When an administrator sets the password, they should not use any passwords that are used on any other systems, because the password is sent to the remote service in the clear and unencrypted. If the module is not needed, simply disable it by commenting out or removing the mod_event_socket from the modules.xml in the FreeSWITCH conf directory. Another course of action is to disable mod_commands if they are not needed. Unfortunately, I have not had time to sit down and identify the most reasonable security settings for FreeSWITCH, but these seem like the most feasible at the moment

For long-term mitigation, I would suggest removing default credentials from the configuration file, and causing the application to fail closed when credentials and password are not set in the configuration. Additionally, an error message should be printed to the log or console informing the service administrator of the issue. This behavior would have more secure side effects than simply setting the hardcoded credentials.

What is justification for releasing this in the public and why did you not contact the developer?
Yeah, I am sure one way or another this will come up one way or another in my future. I notified the developer, but the conclusion of that communication was this issue is the responsibility of the user or administrator. They felt there were adequate protections in place to prevent the problem.

This blog post and the next will serve as an education tool for those administrators or users who may not be aware of the potential ease of misconfiguring their installations of FreeSWITCH. Additionally, this work was free, so I am donating my effort to the open source community as a means of understanding the security implications brought on by a lack of prevention (e.g. secure-by-default) and bad default configuration practices. Remember security is only as strong as the weakest link.