Probing Oracle Eloqua CRM for Sensitive Information Exposure

WORD AHEAD

During this article, we have tried to keep technical details to a comfortable level and anyone should be able to understand how a software security misconfiguration can be spotted, probed, and exploited during a security assessment engagement. As a result, this approach led to a much higher finding outlined with the OWASP Top 10 Web Application Security Risks, A3 Sensitive Data Exposure.

'Anything is possible, but nothing is easy." - Bustlin Billy

From an attacker's perspective, PII Sensitive Information Exposure has several uses. Threat actors seek personally identifiable information to ssky money, compromise identities, or sell them over the dark web for profit.

STORY LINE

This finding started with a Blackbox engagement we had. As a part of the initial discovery phase, we began to cover the usual recon steps:    • Conducting Search Engine Discovery Reconnaissance for Information Leakage
   • Fingerprinting Web Server
   • Reviewing Webserver Metafiles for Information Leakage
   • Enumerating Applications on Webserver
   • Reviewing Webpage Content for Information Leakage
   • Identifying Application Entry Points
   • Mapping Execution Paths Through Application
   • Fingerprinting Web Application Framework
   • Fingerprinting Web Application
   • Mapping Application Architecture

Overall, this job's uniqueness came from not using the Burp Proxy, Zap Proxy, or other similar software. We had to do a web assessment from a slightly different perspective, mostly involving writing custom tooling and using other out-of-the-box approaches.

STUDY TIME

We found this resource a good intro in the matter.

https://medium.com/@sushantkamble/how-to-use-nmap-effectively-for-web-application-penetration-testing-cdf85f9222ea

At this point we started using Google Chrome Developer Tools in conjunction with a Google Cloud Shell for building up tooling, probing, and tracking various bits pieces. Also, during the years, the Developer tools feature was improved a lot and became more than a simple console serving development and debugging purposes.

The target also had a subscription wall where the client was expected to provide some details, and then the user would be allowed to download a pdf document. A quite common scenario.

We noticed that the software attempted to track the user browsing behaviour through three different cookies id:

   • elqTrackId=144133acc2c64af5b619876ed63ade25

   • elqaid=3103

   • elqat=2

Besides, the download link format was somehow unusual for us. We decoded it quickly to get a clear picture of what we have here.



Decoded URL had this format:

http://[images.target.c0m]/Web/UBMTweb/{66813a1d-4d37-4422-aa27-db7d614811b4}_File.pdf

The GUIDv4+ token wrapped this way was slightly different from that we seen before, and we decided to label it as a potential way to fingerprint future underlying applications.

The next step was to test for Directory Indexing. We are usually doing this for two reasons:

   1. Low hanging fruit. It can generate unexpected results.

   2. To test for debugging error messages or stack traces that would expose info regarding the software in use.

This time we've elevated the details provided by a default error message, server-side. Implementing custom error messages is still a reliable configuration to reduce an application attack heat signature for those who wonder.



Q. Now, what is Oracle Eloqua?
A. It is Oracle's CRM, built to orchestrate brilliant campaigns for B2B.

Overall, the Oracle Eloqua CRM has a rich API reference, well documented. We did a quick introspection into how the API reference looks. We got this format.

Script #1



Script #2



In the end, we managed to achieve:

   a. We got hit an endpoint that returned us a remarkable volume of personal information details, PII. Unauthenticated. High impact issue.

   b. We highlighted the current Oracle Eloqua deployment was configured to support basic authentication instead of a more secure Oauth2. We spent some time and we managed to log in. A second High impact issue.

CONCLUSION

CRM systems are complicated beasts. Configuring and secure them might require constant effort and a proper set of skills. The following steps should define a company safe approach:

1. Perform an initial Threat Modeling against the initial business requirements aiming to identify various anomalies.  
2. Execute an offensive security assessment aiming to outline any fundamental security gaps. 
3. Review the findings, identify the root cause, and deploy broad fixes. 
4. Retest and confirm fixes. 
5. Consider repeating the security assessment as part of an ongoing security program. The attack vectors evolve, and the malicious actors always find novel techniques looking to abuse systems.