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