2013/05/21 Update: I made a correction to specify that AES uses a cipher key and not an initialization vector (more information on AES can be found here).
Some may have positive reactions while others may have negative ones with the title of this post. The Securing Oracle WebLogic Server series was building up to this in some way. I mentioned it before. A wrongdoer, a disgruntled employee for example, may exploit an unprotected WebLogic Server environment to gain access to the vast majority of applications it hosts. This includes the new Oracle Fusion Applications such as Fusion Financials!
I do not imply in this post that WebLogic Server is easy to breach. WebLogic Server is used in highly secured environments such as top secret and sensitive compartmented information facilities. However, if the actual resources are left in their default state following an install, meaning unprotected, it takes only a few minutes to gain access.
WebLogic Server uses Advanced Encryption Standard (AES) to encrypt a lot of critical information. When creating a new domain, the WebLogic configuration wizard randomly creates a cypher key (or simply an encryption key), which it stores in a file called
SerializedSystemIni.dat. This file is located in the
security subdirectory of the domain. Here’s an example:
Armed with the content of this file, a wrongdoer can decrypt any of the encrypted information within the associated domain. Let’s have some fun shall we?! I assume at this point that the system administrator (is complacent and) did not protect the WebLogic Server installation and domain.
Explore key considerations, integrating the cloud with legacy applications and challenges of current cloud implementations.
First, let’s start with my favorite ethical hacking trick. Operations, administration and management (OA&M) best practices for WebLogic Server suggest leveraging the auto login capability of WebLogic Server. There are many benefits of leveraging the auto login feature. As an example, WebLogic Server will look up the required username and password to start an instance as part of the startup sequence in a file called
boot.properties. This file is generally located in the
security subdirectory of a WebLogic server instance. As an example, assume the administration server is called
AdminServer. This file would be located in the subdirectory
<domain_home>servers/AdminServer/security. Here’s an example from my local Oracle Service Bus development environment:
After doing a quick search on the Internet using Google for “recover weblogic password”, I find a web site. It asks me for the
SerializedSystemIni.dat file, and any file that contains encrypted data from WebLogic Server. I provide both, and voila!
My next move is to exploit this to gain access to resources configured in the WebLogic domain. More specifically, the WebLogic domain configuration is stored in the
config subdirectory of the domain. I can use the same technique to breach any of the passwords stored in those files. Let me spell it out to emphasize the risks. If there is a data source (a.k.a. database connection pool) to the Oracle EBS system as an example, I can ethically hack it to get access to the EBS database. It does not mean that the actual user has all the right privileges to do real damage. However, how about using the WebLogic system administration account to access any application hosted on WebLogic Server? Could that do some real damage? If you are skeptical, feel free to try it. It works on products such as Oracle Business Intelligence Enterprise Edition (OBIEE) 11g as an example. If there are sensitive reports in OBIEE, that could lead to disaster.
I can already hear some people arguing that a wrongdoer needs access to the files first. I am not done yet; I am just getting warmed up. I started working with WebLogic Server when it was version 4.5.1. I have had plenty of time to think about security vulnerabilities and how a wrongdoer could exploit them.
I understand I have provided people with information that may enable them to exploit vulnerabilities, potentially providing them access to sensitive resources. My objective is to provide system administrators with information to prevent this from occurring. Before you get upset with me exposing these basic tricks, please consider that hackers are already aware of those tricks. Why shouldn’t you be? Would you rather learn it from me or after the fact (i.e. following a real security breach)?
Following are links to older posts in the series: