All WSO2 products expose SOAP web services for management purposes which are called as Admin Services. (You can find an introduction to WSO2 Admin Services in [1])
From this post, I am discussing several security considerations that we must look into when deploying any WSO2 server in a production environment.
Exposing WSDLs of SOAP based Admin Services
WSO2 Admin Services are SOAP based web services. The service contract of the SOAP services are defined in WSDL files. By default, the WSDLs of the Admin Services are hidden and not exposed in the server. This is defined in SERVER_HOME/repository/conf/carbon.xml file’s following property.
<HideAdminServiceWSDLs>true</HideAdminServiceWSDLs>
|
When the Admin Services’ WSDLs are hidden, we cannot view a WSDL of a particular service in the browser. However if we have set the above property to false, then we can view the WSDLs. The URL pattern for accessing the WSDLs in the browser is as following.
https://<HOST || HOST:PORT>/services/<SERVICE_NAME>?wsdl
When the Admin Services are hidden, it would give an error when we try to access a service in the browser.
From an error like this, we can get to know the underlying Apache Tomcat version and if any known vulnerabilities are there for this version of tomcat, we can try to exploit them. Therefore it is important to configure error pages for different HTTP error codes properly to hide these error pages.
If the WSDLs are not hidden, we can view them in the browser.
Here is an example where I view the WSDL of RemoteUserStoreManager Admin Service.
When the WSDLs are exposed, anybody can simply get the URL of a particular WSDL and open it in a SOAP testing tool like SOAP UI and try to invoke the services.
So it is better to hide the WSDLs without exposing them in the server. If your client applications need a WSDL, you can separately share the WSDL file with the client application without exposing it through the server.
But does it solve the problem ? Not really.. Since WSO2 products are open source, the WSDLs can be even downloaded from the source repositories. If not, anybody can run a WSO2 server locally exposing the WSDLs and generate the service contract in SOAP UI. Then the attacker can change the service URL to the victim server and try to invoke the admin services. So even if you have hidden the WSDLs, still the services can be invoked. If you have not changed default admin credentials, the situation is worse !
Invoking Admin Services via Mutual SSL Authentication
Let’s say as shown above, the attacker would try to invoke Admin Services on a victim WSO2 server. If it is a production setup, the admin credentials would not be the default and so the attacker would get Authentication Failure error.
But WSO2 Admin Services can be invoked authenticating with SSL certificates. We call this as Mutual SSL or Certificate Based Authentication. In certificate based authentication, server should trust the client and the client should trust the server. In order to make the trust relationship, client’s public certificate is installed in server’s truststore. Server’s public certificate is installed in client’s truststore. However in this scenario, only the WSO2 server trusting the client would be sufficient. So, if our SOAP client’s public certificate is installed in the WSO2 server’s truststore, we can simply authenticate with the WSO2 server and invoke the Admin Services. This diagram explains this scenario.
So what’s the security risk here ? WSO2 server’s default truststore is the SERVER_HOME/repository/resources/security/client-truststore.jks. It is shipped with the default public certificate of WSO2 server pre-installed where the certificate alias is wso2carbon. Following image shows the default certificates in client-truststore.jks browsed from the Keytool Explorer tool.
Let’s assume that in your production setup, you have not changed the default truststore of the WSO2 server. Now, an attacker can use the default wso2carbon.jks keystore file in any WSO2 server as the keystore of the SOAP client. So when it invokes the WSO2 Admin Services, the server will automatically trust the client because the public certificate of the client is already there in the truststore of the server. Here I use SOAP UI to invoke the services, so I can set this keystore in SOAPUI preferences.
Then, without providing any credentials, I can simply invoke the admin services as shown below where the authentication is successful because the server trusts the client.
However, here I have to add the following SOAP header with the username of a valid admin user. Because WSO2 servers need to check if the service invoker has required permissions. To map the user with the authorization levels, we need to provide a valid admin user’s uesrname. However, if the server has no admin user account with a name that the attacker can guess, then it would not succeed. (More information on this can be found in [2])
|
soapenv:mustUnderstand="0">admin</m:UserName>
|
Above scenario is possible only if the WSO2 server is enabled to support Mutual SSL. However if you have not enabled Mutual SSL Authenticator in the server, then above would not be possible. However some products like WSO2 Identity Server 5.1.0 version comes with Mutual SSL Authenticator by default enabled.
What are the Best Practices ?
As I discussed above, you see if we do not pay attention to these, attackers can try to access your organization data. Therefore you need to properly configure the server to avoid these. You can follow the steps below.
- Hide Tomcat Error pages in the server and redirect to custom error pages.
- Hide the WSDLs of Admin Services
- Manage access to https://<HOST>/services endpoint of the server. Block public access and allow only the trusted clients to access the services endpoint. Configure firewall rules properly.
- If Mutual SSL Authentication is not required for your environment, disable it.
- Remove default admin credentials and set up a different administrator account where the username cannot be guessed.
- Remove default keystore and default truststore of WSO2 server. Manage the trusted SSL certificates in the truststore properly. Keep only the certificates you need to trust and remove all others.
If you follow these steps, then you can enhance the security of the WSO2 server running in your production environment.
References
Tharindu Edirisinghe
Platform Security Team
WSO2
No comments:
Post a Comment