How to harden WebLogic and Fusion Middleware against worm attacksPublished on: Author: Mark Otting Category: Oracle
Earlier this year an internet worm infected WebLogic-based platforms vulnerable to the CVE 2017-10271 exploit. As a remote administration support engineer, my primary responsibility is to maintain the availability of my clients’ Oracle Fusion Middleware stacks. In one week I discovered a semi-successful attack and another vulnerable system. This prompted me to create a set of guidelines to help you harden your platform and prevent these automated attacks in the future.
This guide applies to all 11g and 12c WebLogic based Oracle products (Oracle Forms, SOA Suite, Oracle Enterprise Manager, Oracle Service Bus, Oracle Identity Management, OBIEE and more). First, I’ll explain how the worm attack works.
The method used in this attack was quite similar to an earlier vulnerability: CVE-2015-4852. Both leverage object deserialization in an unexpected way in one of the many libraries used in WebLogic by default. Apache fixed the library – included in the later 12.2 WebLogic releases – and Oracle fixed the T3 weakness. However, this patched just one approach. The original attack continues to be updated, now with attacks based on Spring and Hibernate.
Recommendation 1: cover your platform
Your first action should be to restrict access to your application services by preventing naked servers. A naked server is any backend service or management console that is openly available from the internet or the user domain. Your application servers should never appear in a Google search, as illustrated below.
You should also prevent direct access to search engines like Shodan.io. Shodan is a search engine that indexes server information for internet IP addresses and ports.
To cover your platform, you can configure an HTTP proxy service and prevent application server access from all other sources using firewalling or ACLs. Take care while locking down the admin server console for internal access only. Opt for an F5 load balancer, Apache web server or a different reverse proxy.
This is generally considered to be yet another component and as such an additional vector of attack. But a single-purpose process proxy server has a much smaller attack surface and is easily updated without impacting your application availability.
Another assumption is that locking down the middleware platform is not needed if it is only accessible form the local network. However, this is not a trusted setup, as many devices are used on unaudited networks. With a simple automated network scan you can pivot your WebLogic server into your server network.
Recommendation 2: limit banner grabs
Banner grabbing is a technique used to gain information about a system or a network and the service running on its open ports. Internet worms use this technique to determine vulnerable targets. You can limit banner grabs with the following measures:
1. Set up custom error pages
To prevent the well-known 404 error pages, you should add custom error pages to your Java deployments in web.xml.
In 12c and later you can use a catch-all error page, where the path references a location in your WAR file:
In earlier versions you had to configure an individual error page for each error code using an additional error code tag. If you are using this guide to harden an 11g environment, be sure to set up an error page for HTTP 403 (forbidden), HTTP 404 (page not found) and HTTP 503 (server error) codes.
2. Remove the FMV demo application
During the Fusion Middleware installation process, a demo application in some instances is installed in the default context ‘FMV Welcome Page Application’. You can uninstall this application, as it serves no purpose.
3. Remove leakage from your proxy
If you have Apache or OHS for a proxy service, use the directive below to prevent leaking configuration
You should also swap in custom error pages to override the custom Apache pages.
Your proxy will still send two headers to identify WebLogic. You can unset these, but I would advise against this on servers running ADF applications or any type of Oracle message tracking:
Header unset X-ORACLE-DMS-ECID
Header unset X-ORACLE-DMS-RID
Recommendation 3: least privilege access
In addition to proxy and obscuring, you can also minimize the impact of a successful break in.
1. Operation system level permissions
If the attacker has access to the key stored in SerializedSystemIni.dat, you risk losing all passwords. Prevent this by limiting access to as few users as possible and do not allow service accounts to shell in directly.
Another action by many worms is to download and execute a payload. You can mitigate this risk with the following precautions:
- Limit execution permissions in the system /tmp directories by mounting them with the ‘noexec’ option. This would have stopped the ‘monero’ miner, for example. You could also mount the WebLogic domain directory in this way and copy the /bin files elsewhere.
- Firewall self-initiated outbound traffic (‘egress filtering’) to non-whitelisted hosts.
I also recommend enabling SELinux, which allows you to set fine-grained permissions, such as preventing Java from executing programs (as WebLogic does not need this anyway). This should be easier to manage than file-based permissions.
2. Role-based access
Passwords for generic accounts (such as the WebLogic user) cannot be changed without impact, but if they are commonly known they should be changed whenever an employee leaves the company. That’s a lot of work. To prevent this you should externalize password management by configuring your company’s user directory as an external authenticator in WebLogic and allowing users to log in with their company account. Then lock the WebLogic user password.
These user accounts should be given permissions based on their roles: a monitoring tool should have a read-only monitoring account and a developer allowed to test their OSB service should be given the appropriate permissions for the test console in EM and nothing more.
3. Lock down anonymous access
Java messaging queues and topics allow unauthorized access by default. You can limit access to certain accounts by assigning a role. Configure authorization on JSM by opening the configuration of an existing queue and configuring the roles in the security tab.
In the security tab domain, ‘anonymous admin lookup’ is enabled by default. Only keep the default setting if you have not configured a JMX remote port or if you fully trust your application libraries.
4. Log files and auditing
Most problems will manifest themselves in your log files first.
The CVE-2015-4852 exploit was considered ‘noisy’, as several stack traces could be seen in your server logs after execution. You should set up monitoring on these log files, but the trouble is that a classic approach with Nagios (‘Mail on alert’) requires scripting to prevent unnecessary alerting. You will probably have more time to spare if you either go for a catch-all approach (such as parsing your logs with Logstash, which supports mail alerting) or an intrusion detection system like OSSEC (which traces logs and monitors file usage).
Keep up to date with Oracle security updates
Your WebLogic platform hosts a large number of libraries, making it a prime target for automated and human intruders. An active security policy would stop the majority of these attacks.
I highly recommend updating the WebLogic platform with the most recent PSU (patch set update). Join the critical security bulletin mailing list and organize a process to test and implement the latest patch sets.
For more information, please contact Qualogy by phone on +31 (0)70 319 50 00 or by e-mail: email@example.com.