2020-12-08 14:11:00
The following article is an exploit write-up which I published on my Github repository. It describes a security vulnerability I found in Tibco's software, which I submitted to the vendor through proper responsible disclosure. Now that Tibco have finished their follow-up, I am allowed to publish my findings.
During a pen-test of an internally developed application, I discovered that the engineers in question had re-used a commercial Java library for password obfuscation.
While their application was not part of a Tibco stack, nor did it use Tibco, they did make use of Tibco's "ObfuscationEngine". On Tibco systems, this tool is used to obfuscate (and sometimes encrypt) passwords for safe storage in configuration files.
My colleague Wouter R. referred me to a project from a few years ago, which apparently did the exact same attack: Thomas D's "tibcopasswordrevealer", built in Python. At the time of my pentest, nor up until an hour ago, was I aware of this previous work. Until my colleague pointed out the project, I had only found people re-using the "tibcrypt.jar" library.
Tibco's documentation states that there are three modes of operation for this ObfuscationEngine tooling:
This write-up pertains to #3 above. The documentation states both:
"The fixed key […] does not provide the same level of security as the use of a machine key or a custom encryption key. It is used to encrypt an administration domain’s password.”
and
"Passwords encrypted using Obfuscate Utility cannot be decrypted. Ownership is with customers to remember passwords in clear text. There is no utility provided by TIBCO to decrypt passwords encrypted using Obfuscate Utility.”.
Secrets obfuscated using the Tibco fixed key can be recognized by the fact that they start with the characters #!.
For example:
#!oe2FVz/rcjokKW2hIDGE7nSX1U+VKRjA
The first statement does not make clear the risks that are involved, while the second statement is blatantly incorrect.
On Tibco's forums, but also on other websites, people have already shared Java code to decrypt secrets encrypted with this fixed key.
For example:
I performed a pen-test on an application, where the above-mentioned ObfuscationEngine had made its way into their in-house code. Because I did not have access to Tibco's copyrighted libraries, I was happy to find one source online that had the older “tibcrypt.jar” available.
-> https://mvnrepository.com/artifact/tibco-ems/tibcrypt/4.1
By analyzing this JAR file, I recovered the fixed key. Using that I wrote a small Java utility that can decrypt any secret that was encrypted using the Tibco fixed key regardless whether Tibco libraries are available.
The code is provided in my Github repository as “decrypt.java”.
Regardless of country, customer, network or version of Tibco, any secret that was obfuscated with Tibco's ObfuscationEngine can be decrypted using my Java tool. It does not require access to Tibco software or libraries.
All you need are exfiltrated secret strings that start with the characters #!.
This is not going to be fixed by Tibco, this is a design decision also used for backwards compatibility in their software.
Compile with:
javac decrypt.java
Examples of running, with secrets retrieved from websites and forums:
java Decrypt oe2FVz/rcjokKW2hIDGE7nSX1U+VKRjA
7474
java Decrypt BFBiFqp/qhvyxrTdjGtf/9qxlPCouNSP
tibco
I have shared my findings internally with my client. I have advised them to A) stop including Tibco's copyrighted classes and libraries into their own Java applications, B) replace all secrets encrypted using this method, as they should be considered compromised.
The proof of concept code has been shared with the customer as part of the pen-test report.
I reported this situation to Tibco's responsible disclosure team (security@tibco.com) on September 9th 2020.
On December 8th Tibco's security team responded that they have updated the Tibco administrators documentation to make it clear that the fixed key method of ObfuscationEngine should not be considered secure.
-> https://docs.tibco.com/pub/runtime_agent/5.11.1/doc/pdf/TIB_TRA_5.11.1_installation.pdf?id=3
The text now reads:
"The fixed key is compatible with earlier versions of TIBCO Runtime Agent but should not be treated as secure. A machine key or custom encryption key should be used whenever possible."
No CVE was awarded as the vendor did not recognize this as a vulnerability. This is intended functionality, which "works as designed".
kilala.nl tags: work,
View or add comments (curr. 1)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Tess Sluijter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.
2020-12-08 14:22:00
Posted by Tes
This case is almost identical to the vulnerability I found in another piece of software, which I described in my zine "The tale of the Dubious Crypto."