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.
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.
In closing…
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.
Remark
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:
Weblogic passwords uses SHA-1 hash algorithm that weblogic encrypts the passwords with, but this file stores on boot.properties 3DES algorithm which is running Data Encryption Standard 3 times, is a symmetric block cipher. A block cipher breaks up the plain text into pieces, and runs a reversible (two-way) encryption on it so that if you have the key, you can recreate the data from the cypher text. This differs from SHA in that you can NOT recreate the data from an SHA hash.
As long as this file “SerializedSystemIni.dat” is properly protected in production mode from unauthorized access on server level and I am pretty sure this would not be accessible by anyone else apart from DBA’s and Administrators only.
Hi Sagar,
Thanks for pointing it out. My post was misleading in some aspects. As an example, AES involves a cipher key and not an initialization vector. In addition, I should have specified the version of WebLogic Server, or simply omit mentioning AES altogether. For example, WebLogic Server version 8 used 3DES whereas 11g uses AES.
My post’s primary objective was to point out that the file
SerializedSystemIni.datcan be used to get access to encrypted data such as usernames and passwords.Thanks again.
Alan Belisle
Thank you, very useful resource to learn weblogic
Good pointing it out by sagar.Thank you Alan Belisle for educating on securing weblogic server.