Posts Tagged ‘Information Security’

Securing Oracle WebLogic Server – The Hack Patch

Before I start, it is important to understand Oracle’s license terms. It is not uncommon to download Oracle products from the Oracle Technology Network (OTN). Here’s an extract from the Oracle Technology Network Free Developer License Terms “You may not cause or permit reverse engineering (unless required by law for interoperability), disassembly or decompilation of the programs”. In other words, decompiling WebLogic Server, at the very least, voids the license agreement. That said…

Assuming the WebLogic Server installation is accessible, another technique to gain access to “protected” resources is to use a “hack” patch. The whole idea is to tamper with the WebLogic Server product itself. As an example, when BEA used license keys to activate products and product features, some people would use a hack patch to disable some of the license checks (e.g. expiration). Leveraging this technique, a wrongdoer could create a hack patch to write the WebLogic Server administrator’s account name and password in clear text to a text file or in the server logs. Before you think that this is not possible, consider that if there is a compelling reason, spending time to reverse engineer code to understand how to exploit it is not such a big deal.

Although the risks are minimal, a hack patch could potentially be used in conjunction with a man-in-the-middle attack. More specifically, as an example, an attacker could use this technique to intercept a request to download WebLogic Server 12c from OTN, and provide a tempered version that includes a rootkit. Did I mention a few times to put your paranoiac hat on a few times in past posts? Nevertheless, I recommend doing due diligence and validating the checksum (a.k.a. digest, hash) when downloading products from the Internet (mentioned during the pre-installation steps).

If the system administrator has done its due diligence and limited access to the WebLogic Server installation and the WebLogic domains, special code could be deployed with application code. This scenario assumes a great deal of paranoia and distrust of employees though. Regardless, a disgruntled employee, as an example, could develop a basic web application that is packaged within the EAR file of the project he is working on. The web application could be used to gain access to the content of the file. Leveraging WebLogic Server’s private APIs, the content of this file can be decrypted without the need of the SerializedSystemIni.dat file.

In closing…

Concerns about information security vary from one organization to another. Repeating myself, information security at times requires a certain degree of paranoia. In some cases, the paranoia may be unwarranted. The use of hack patches, generally speaking, represents extreme cases. The possibility is nonetheless, there.

Please note that I have intentionally left many details out in this post. I have also kept some of the details vague on purpose. A quick search on the internet will provide you with some of those details (e.g. private security APIs). The key takeaway is simple: protect the WebLogic Server installation and the WebLogic domains. That is a basic and easy thing to do that will prevent many other issues, not limited to information security.

Securing Oracle WebLogic Server – Ethical Hacking?

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 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.


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:

  1. Securing Oracle WebLogic Server – Intro
  2. Securing Oracle WebLogic Server – Roadmap
  3. Securing Oracle WebLogic Server – Pre-Install (Part 1)
  4. Securing Oracle WebLogic Server – Pre-Install (Part 2)
  5. Securing Oracle WebLogic Server – Install
  6. Securing Oracle WebLogic Server – Configure

Securing Oracle WebLogic Server – Configure

The next step after installing the software consists of creating the WebLogic domain. Before we do, as stated in the pre-installation posts, following OA&M best practices, application and user data must be separate from software products. The WebLogic domain could easily be created in the /var hierarchy on Linux or within the home or user directory of the account used for installing WebLogic Server. I typically create it in the home or user directory, and will assume you do the same.

Obviously, to create the domain, we use the Configuration Wizard. As part of the process, there are a few specific configurations or pages of the wizard where I suggest being paranoiac:

  • When prompted for the administrator user name and password, use an original user name, not weblogic or system. As for the password, the rules are simple: the wizard expects a password with at least 8 alphanumeric characters, at least one number or special character.
  • On the Domain Mode Configuration page, select Production Mode to prevent code from being automatically deployed when copied to specific directories.
  • On the Select Optional Configuration page, I recommend editing the Administration Server. More specifically, use an original port number for the listen port, not 7001.
  • I personally prefer to configure the Managed Servers using the WebLogic administration console. You can optionally configure them using the Configuration Wizard. Here again, use original listen port numbers.

Several techniques and tools can be used to determine what ports a server listens to. Regardless, why make things easy?

After the domain is created, the next step is to protect it. Again, I suggest locking down the domain directory. Assuming the domain was created in /home/aUser/user_projects, specifically:

  • I ensure that the subdirectory user_projects is owned by the dedicated user account and group created as part of the pre-installation of the WebLogic Server. Again, if making a change, it is critical to ensure the update is recursive (i.e. affects the full file system hierarchy, all subdirectories and files this directory includes).
  • I also remove all permissions for the group and world (or everyone in Windows environments). Only the dedicated user account should have access to the entire subdirectory user_projects and all subdirectories and files it includes.

One of the disadvantages of globally or blindly changing ownership and permissions on all files and folders of a WebLogic domain is that it prevents developers from accessing the server logs. Generally speaking, information security introduces restrictions. It does not mean that the results must become impractical to all. I am a huge believer that developers should have access to the server logs. This can be easily remedied by opening up the appropriate directories, creating symbolic links to those directories, replicating the log files (in real-time mode), and many other techniques.

In closing…
Over the past few weeks, I have covered the basics, from pre-installation, installation all the way to configuration. In the next series of post, I will cover beyond basics. As an example, I will talk about how easy it is to gain access to the WebLogic super user given some basic access when an installation is left unprotected.

Securing Oracle WebLogic Server – Install

This post discusses the actual installation of WebLogic Server. Generally speaking, the installation of Oracle WebLogic Server, in reality, involves installing two software products: Java – typically a Java software development kit (SDK) – and WebLogic Server.

In a secured deployment, I will install the Java SDK in the same location as WebLogic Server. On Linux as an example, assuming the Fusion Middleware home directory is /usr/local/oracle/middleware, I install the Java SDK to a directory such as /usr/local/oracle/middleware/jdk1.6.0_25 (for Java SDK version 1.6.0 Update 25). As a reminder, the Fusion Middleware home is simply a convention used for installing all the Oracle Fusion Middleware products within the same file hierarchy. During the execution of the installation wizard of the Java SDK, there is no specific security concern or task to perform. Although it is not primarily a security concern, I typically do not install the Java SDK samples and source code on a server. Finally, the installation of the Java SDK will be secured as part of the process of securing the installation of WebLogic Server since the two are collocated.

On Linux as an example, assuming the Fusion Middleware home directory is /usr/local/oracle/middleware, WebLogic Server 11g will typically be installed to the directory /usr/local/oracle/middleware/wlserver_10.3. I very seldom change this path. During the install I recommend subscribing to received security updates (if not already subscribed). Similarly, there is no specific security concern or task to perform during the execution of the installation wizard. Here as well, I do not install samples and examples (e.g. WebLogic Server examples, Coherence examples).

Finally, when both products are installed, I locked down the Fusion Middleware home directory. Assuming it is /usr/local/oracle/middleware, specifically:

  1. I ensure that the directory /usr/local/oracle is owned by the dedicated user account and group created as part of the pre-installation of the WebLogic Server. If making a change, it is critical to ensure the update is recursive (i.e. affects the full file system hierarchy, all subdirectories and files this directory includes).
  2. Next, I remove all permissions for the group and world (or everyone in Windows environments). Only the dedicated user account should have access to the directory /usr/local/oracle and all subdirectories and files it includes.

These two steps prevent access from any other user, limiting access to the Java SDK and WebLogic Source product files. This limits the number of users who can access and temper those directories and files. This may seem paranoia once again. However, a secured WebLogic domain and its critical configuration files could be breached by tampering with the Java classes that make up WebLogic Server as an example.

In my next post, I will discuss the configuration of WebLogic Server, which consists in creating the WebLogic domain and securing its critical files.

Securing Oracle WebLogic Server – Pre-Install (Part 2)

This post continues where we left off in discussing the pre-installation tasks of Oracle WebLogic Server.

1) Operating System Firewall

Most operating systems include a (software) firewall. The existence of the Windows firewall and Linux firewall (a.k.a. iptables) are common knowledge. Just in case, here are some articles for Solaris and AIX:

I am sad to say that it is not uncommon for system administrators to disable the firewall on Linux. It is also common practice of not installing and/or configuring a firewall on Unix. Typically, this is done to simplify general operations, administration, and management (OA&M). As an example, on a project, a consultant was installing a database on Linux. He did not want to deal with creating the rules in the firewall and simply disabled it (he also disabled SELinux).

I highly recommend running the firewall on machines where any Fusion Middleware product is installed; this obviously includes WebLogic Server. In addition, please do your due diligence; review all the rules, removing the unnecessary ones (e.g. closing all unused or irrelevant ports).

2) Security-Enhanced Linux (SELinux)

SELinux is another necessary component of a secured Linux environment. The National Security Agency (NSA) was involved in its inception. If you read their hardening guide, you know they recommend running it. The SELinux Project Wiki provides the following definition for SELinux: “SELinux is a security enhancement to Linux which allows users and administrators more control over access control”. If you have read about information security, or your role involves information security, you know that access control is a critical part of information security.

Sadly, it is not uncommon for system administrators to disable SELinux. Generally, it does not affect the Java virtual machine (e.g. JRockit) and WebLogic Server operations. There is no specific policy that need to be disabled. If you have a web server tier (e.g. Oracle HTTP Server, Apache HTTP Server) in front of the WebLogic Server tier, changes are required on the web tier, but not on the WebLogic Server tier. However, those challenges do not warrant disabling SELinux altogether.

Let me be explicit about it. I highly recommend enabling SELinux. Furthermore, please do your due diligence and consult the NSA’s hardening guide. It provides a full section on SELinux, and recommended practices to harden it.

3) Obtain the Software

A very common mistake is to download Oracle products from the Oracle Technology Network (OTN). If you are a licensed customer, you must download the software products from the Oracle Software Delivery Cloud. I recommend doing your due diligence and validating the checksum (a.k.a. digest, hash). Here’s how Oracle introduces this concept: “A message digest (also known as a checksum or hash) is used to verify data has not been altered in transit”. At this point, you may feel we are being paranoiac. However, it is best practices to validate the checksum for all software packages you download from the internet, not just Oracle products.

In closing…

In the last two posts, I have provided general basic recommendations to prepare the environment before proceeding with the installation of WebLogic Server. Some of those practices are common knowledge. For some system administrators, many of these practices are part of their standard operating procedures. Unfortunately, there are too many installations that are left unsecured. Please do me a favor; most importantly, do your organization a favor: don’t be complacent about information security. If you do not do your due diligence to harden your environment, taking a holistic approach, your information strategy is as strong as your weakest link.

In my next post, I will discuss the installation and configuration of WebLogic Server.

Securing Oracle WebLogic Server – Pre-Install (Part 1)

This post discusses the tasks for preparing the operating system before installing WebLogic Server.

1) Validate Operating System

The very first thing to do is to validate that the latest critical updates and patches are applied. Everyone talks about it. However, breaches occur regularly because it is not done.

I recommend manually running the process to validate that the latest critical updates and patches are all applied before starting the installation. This means running Windows update on Windows machines. Linux and Unix provide similar capabilities.

Next, I recommend validating that the process is scheduled to run regularly to retrieve and install the latest critical updates and patches. It is one thing to check manually; it is another to be proactive about it.

Another aspect that is critical is subscribing to vulnerability alerts. It is simple, if you are serious about information security, you must subscribe. Software vendors such as IBM, Microsoft, Novell, Oracle, Red Hat and many more publish them. You must be proactive about it. There might be a delay before a critical update or patch is available. This window presents an opportunity. I suggest being paranoid about it and assume your systems are at risk instead of scrambling to deal with a breach.

2) Create Dedicated User and Group

Linux and Unix security best practices recommend using dedicated users and groups for operations, administration, and management (OA&M) of application software, services and components that can be accessed remotely. The same approach applies to a Windows machine. Obviously, when installing WebLogic Server, I recommend applying this practice. Many Oracle products are installed using a user named oracle. Here again, I suggest being paranoid and using an original user name.

3) Create Installation Directories

Generally, on Unix and Linux machines, I recommend installing WebLogic Server following the Filesystem Hierarchy Standard (FHS). As an example, I usually install WebLogic Server on Linux in a directory such as /usr/local/oracle/middleware. On Windows, I will install in a directory such as \oracle\middleware (obviously in the root of the drive). In beyond basics, I will explore the benefits and tradeoffs of using a known or common path to install WebLogic Server.

Most importantly, you must secure the installation directory. Assuming WebLogic Server will be installed to /usr/local/oracle/middleware, access control should be set up to limit access to the /usr/local/oracle directory (all files and subdirectories it includes) to the account used for installing WebLogic Server. I even recommend removing all permissions for the group, not just world (or everyone in Windows).

Furthermore, following OA&M best practices, I recommend locating (application and user) data separately from software products. The WebLogic domain could easily be located in the /var hierarchy on Linux or within the home or user directory to the account used for installing WebLogic Server. Similarly, this directory must be “locked down”, and only accessible to the account used for installing WebLogic Server.

In Closing…

Those are general basic recommendations to prepare the environment before proceeding with the installation. Some are basic, well-known, and common practices. However, as stated before breaches occur regularly because they are not followed.

When preparing the operating system, there are other practices that can be applied depending on the level of risks, and/or your appetite for risks. I suggest having a look at the NSA Hardening Guides. You can also find many additional resources on the internet along the same lines.

In my next post, I will discuss additional security practices (e.g. software firewalls) to consider before proceeding with installing WebLogic Server.

Securing Oracle WebLogic Server – Roadmap

This is the second in a series of posts, as the title implies, that focuses on securing Oracle WebLogic Server. This software product is a full fledge Java Platform, Enterprise Edition (Java EE). Thus, this series is about technology, right? Yes, it will be primarily focused on technology. However, we have to consider information security holistically. Along these lines, I intend to share some of my reflections on topics that may be not be as relevant to system administrators such as risk management, information security strategy and information security policy. This will provide some context why WebLogic Server should be secured. In case of a breach, did you know that a WebLogic Server instance could become an entry point to a database, a data warehouse, or a business application?

First, I will cover basics, which will provide a lot of strategies and techniques to harden WebLogic Server quickly.

  • Pre-Installation will address the preparation of the operating system where WebLogic Server will be installed. This post will discuss best practices, and make some recommendations to harden the environment.
  • Installation and configuration will address hardening a WebLogic deployment (e.g. protecting critical configuration files).
  • Management will address some key risks, challenges, and issues with the management of a WebLogic deployment (e.g. forgotten admin password).

Beyond the basics will cover non-technical and technical topics, including strategy and policy. If there are specific topics you would like to see addressed, please feel free to let me know.

Securing Oracle WebLogic Server – Introduction

I have been working with Oracle WebLogic Server for quite some time. I can count on my hands the number of deployments where security was a concern. This is a first post of a series that focusses on securing WebLogic Server. This series is inspired by the work I am currently doing with a client in the retail industry. The client has two primary concerns, namely Personally Identifiable Information (PII) and Payment Card Industry Data Security Standard (PCI DSS) compliance. More specifically, Oracle Fusion Middleware (FMW) products such as WebLogic Server, SOA Suite and Oracle Service Bus may be used to process and transport this type of data.

There is plenty of information on securing WebLogic Server out there. Why am I blogging on this topic you may ask? One, I believe there are a lot of poor practices when it comes to information security. I am a big believer that securing WebLogic Server has to be approached holistically. I will start from the installation, and build from there all the way to operations, administration and management (OA&M). Two, what you will find in these posts are actual strategies I am helping real clients implement. If they are concerned about information security why shouldn’t you? Three, soon WebLogic Server will be the foundation for many of Oracle’s products. You would be surprised of how quickly a disgruntled employee could literally breach a WebLogic Server environment. Would you want them to exploit this to gain access to other applications, custom developed or commercial off the shelf (COTS) products? In my next post, I will provide a roadmap for this series. In other words, I will provide a list of the topics I intend to cover in the short term.

In closing, as advised by Gideon T. Rasmussen, in his article Implementing Information Security: Risks vs. Cost, a healthy dose of paranoia may be warranted here. Paranoia is definitely on the menu!