A chain is only as strong as it’s weakest link.Unknown Origin
Summary
Do you know where your weak links are?
Your DataPower environment may not be as secure as you think. Through a combination of:
- Not being on the latest firmware levels
- Administrator password sharing / lack of password rotation for built-in user accounts
- Using weak encryption ciphers for connecting clients
- Supporting old version of the SSL/TLS standard
- Leaking service behavior information via exception messages.
Your environment could be vulnerable to either an inside or outside attack, impacting the services provided by the platform and the business itself.
For these issues identified above, recommendations are made in each section for mitigation.
Introduction
A DataPower device is hardened by default when it leaves the IBM factory. In fact, it’s so hardened that the only way to initially set up the device is via a physical cabled connection. This initial setup process involves explicitly enabling the various components of the device until it’s considered ready for consumption by the internal users.
Over time, as the device configuration is touched by Infrastructure Experts, project deployments, and through standard technological innovation. It is possible that your DataPower environment is no longer as secure as that initial state.
This article will discuss the common potential security issues that could be present in your DataPower environment right now.
Firmware Currency
The firmware version installed on your device is critical to the security and general health of your appliance. FixPacks contain all the fixes (APARs) that were identified and resolved in that release. They typically contain between 5 and 30+ fixes per release.
- Firmware 5.0 FixPack List
- Firmware 6.0 Fixpack List
- Firmware 7.0 Fixpack List
- Firmware 7.1 Fixpack List
For each supported firmware and supported hardware level, a FixPack is released every 2 months and a new top level version every year. These fixes address platform stability (reducing restarts) and platform security (identified CVE’s).
The older your firmware is, the fewer fixes the platform contains and the higher the chance of missing a critical fix that could be exploited by a would-be attacker.
While it is ideal to upgrade your firmware every time a new one is released, in reality, this tends to be costly given the frequent release cycle and the amount of testing required to deploy into production.
Recommendation #1
Your DataPower team should be aware of the individual fixes contained in every release. During this review, fixes should be marked as urgent or non-urgent. Finally, a determination should be made if any urgent fixes are severe enough to require planning an immediate upgrade.At a minimum, the firmware should be updated once per year.
Recommendation #2
You must be prepared to execute a firmware upgrade at least every year. Ensure that your promotion process and testing is in place to support an endeavor like this. In a perfect world, you would have a suite of automated test cases for all your endpoints and scripts that upgrade/downgrade the device as needed. In a not-so-perfect world, you should identify the top apps and target your test cases at them to determine platform stability.Insecure Administrator Accounts
Once two people know a secret, it’s not a secret anymore.Common Sense
An administrator account has full access to change all settings in the environment at any time. Therefore, these credentials must be stored securely.
DataPower provides many different integration points for user accounts, but the most popular are LDAP and local accounts.
Local accounts are easier to initially configure, but are also more costly in terms of time and security. Someone must be assigned to actively manage these user ids and ensure that passwords are changed according to the corporate policy. Every single local administrator account is an opportunity for illicit system access.
The LDAP solution requires more initial configuration time, but existing enterprise directory, groups and process are leveraged. This frees resources from the above user management issues. An assumption could be made that choosing LDAP frees yourself entirely from problems associated with local accounts, but unfortunately, that’s not true. What happens when your external authentication server is down? Does it render the entire environment inaccessible to all administrators?. Yes, it would and it’s not acceptable.
To accommodate this scenario, IBM recommends that the device be configured with at least two local administrator accounts: the standard ‘admin’ user and a second privileged id that can unlock the admin account. These are present on all DataPower devices.
This means that the ‘keys to the kingdom’ are actually only as secure as the location where the passwords for these accounts are stored.
Recommendation #1
All users of the DataPower platform should log into the device via an external authentication server (generally LDAP) and never with local administrator accounts.Never allow all administrators share a single local account, you will wind up with a device where the configuration is modified ‘magically’ because there is no ownership over changes.
Recommendation #2
Local administrator accounts should only be used in case of emergency. The password for these accounts should be stored in a highly-secure location that can only be accessed by a highly trusted individual.In addition, these accounts must have their password rotated on a regular basis to limit the potential impact of an unknown breach.
Outdated TLS Cipher Suites
As part of the handshake that occurs during TLS negotiation, the client and the server negotiate on the specific encryption algorithm to use to secure the connection. This is known as the Cipher. The strength of the Cipher selected in this process defines the security of the data exchanging between the two systems. Choose a weak cipher and the data flow could be decrypted and read by an attacker.
The client sends a list of ciphers that they support and from that list, the server will choose a cipher that meets the cipher selection string set by the server. If the client and server cannot come to an agreement, the connection will be closed.
The default Cipher selection string in DataPower has evolved twice. At first (firmware 3.6 and earlier) it was ‘DEFAULT’ and since 3.8.0 it has been ‘HIGH:MEDIUM:!aNULL:!eNULL:@STRENGTH’. DEFAULT allows very weak ciphers like 56bit export ciphers. Interestingly, the SSL/TLS protocols define a NULL cipher which literally means no encryption. The ‘!’ signifies not allowed.
‘HIGH:MEDIUM:!aNULL:!eNULL:@STRENGTH’ represents:
- HIGH: currently AES or 3DES Ciphers
- MEDIUM: 128 bit RC2 and 128 bit RC4
- !aNULL & !eNULL: Don’t allow the NULL Ciphers
- @STRENGTH: Choose the Strongest Cipher that both the client and server support.
Over time, vulnerabilities are found in Ciphers and what is secure today can become insecure tomorrow. As an environment matures, care must be taken to ensure that the initial services deployed in the environment are still secure.
It is important to be aware of the Ciphers being used by TLS. Just because you have HTTPS:// in your URL does not imply you are magically safe from attackers.
Recommendation #1
If you see the word NULL or ALL or DEFAULT in your SSL Proxy Profile, run. It means you accept the weakest of the weak ciphers or even no encryption at all!Recommendation #2
Every service has different requirements for security. Ensure that the Ciphers your SSL Proxy Profile accurately reflects the importance and privacy of the data being transferred. It’s always better to err on the side of too much security than too little.HIGH is the best and secure in all situations. MEDIUM should be used only by an intentional decision.
Recommendation #3
Should you have a requirement to accept an insecure Cipher Suite from a client, you should isolate that SSL Proxy Profile from the rest of your system. If that profile is used for inbound traffic, then all consumers of that port will be allowed to use the insecure cipher.Outdated TLS Protocol Versions
Once upon a time, there was SSL 1.0. It was bad (and never released publicly). 1995/96 brought SSL 2.0 and 3.0. TLS 1.0 was introduced in 1999, 1.1 in 2006 and 1.2 in 2008. TLS 1.3 is currently an RFC draft.
Technology constantly progresses and care needs to be taken to ensure that the environment is updated to account for the latest discovered vulnerabilities.
If your service accepts:
- SSL v2 – you are running with technology created when most people used a dial-up internet connection (if they even had one)
- SSL v3 – you are vulnerable to POODLE attacks and weak encryption
- TLS 1.0 – you require workarounds to ensure that strong ciphers are used and not MD5 or SHA-1 based ciphers.
- TLS 1.1 – you are ‘ok’, but can improve
- TLS 1.2 – you are on the current gold standard
In an SSL Proxy Profile, there are checkboxes that disable these insecure specifications. The default in DataPower is to disable SSL v2 and v3 but allow TLS 1.0,1.1 and 1.2, which is not an ideal configuration.
When you accept outdated TLS protocol versions, your connections are insecure.
Recommendation #1
All SSL Proxy Profile’s should be set to only accept TLS 1.2. If you have a vendor that doesn’t support it, then TLS 1.1 should be used (for now).If they don’t support 1.1, you should consider a new vendor.
Exception Information Leaks
Easy is the descent into Hell, for it is paved with good intentions John Milton
When an attacker targets a service, they’re looking for any sliver of information that gives them more information about the behavior of that service. They then take all these small bits of info and improve their next attack.
An overlooked part of endpoint security is how your endpoint behaves when an error occurs. Let’s look at how DataPower responds to an error out of the box.
By default, for a Web Service invocation to DataPower, the device will respond with one of two faults: “Internal Error (from Server)” or “Internal Error (from Client)”. These are two very non-descriptive errors, but it’s completely intentional. An attacker can’t use either of these messages to glean information about what failed and they will need to try another method of attack. (You can argue than even those two messages should be refined into a single “Error” message shared by all technologies so the attacker doesn’t even know that it’s a DataPower appliance responding).
Another good example of this is a failed TLS connection between two servers. If the client or server decides to reject the connection, it will immediately terminate the connection by ending a FIN packet to the TCP port. This closes the connection but no error message is sent to the other party. While this does have a tradeoff of longer debugging times in new integrations, it pays for itself in security. (In practice, the side that closed the connection will write a reason into its own log).
Think about the scenario if our service responded with precise error messages.
Security would be compromised if we said “Closing connection because the certificate was not issued by VeriSign” or “Expected WS-Security Header”. The attacker would now know they need to track down a certain type of certificate or re-format their message and try again. Can the attacker continue to refine the attack using your own information against you? Is your breadcrumb trail of failure messages so good that it leads a would-be attacker to success?
It’s a good intention that your endpoints respond with informative error messages, but be aware that prying eyes could see them and take remedial action to improve attacks on your infrastructure.
Recommendation #1
If you are exposing a private service to the internet, ensure that you aren’t leaking internal service behavior details in your exception messages. There’s no need to tell a trusted third party the exact reason the transaction failed in a production environment. The reason can be locally logged and then accessed by support when needed.Conclusion
A DataPower device is a cornerstone of a sound enterprise security policy. Most assume that a device must be implicitly secure. The truth is that nothing ever comes for free. Care must be taken in all stages of deployment and administration ensuring that environment security is maintained.
A security policy is only as strong as its weakest link, hopefully this article helped to identify where yours may be.
About the Author
If you've found this information useful, please share it.