NOTE: On October 17th, 2018 Oracle released a patch for this vulnerability as several others: https://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html There are times when finding a 0day in a major-branded product like Oracle takes months of research, and there are times when it just jumps off the screen and you think to yourself, 'There's no possible way that is what I think it is.' Such was the case on a red team engagement I was working on in July, and believe me, you will feel let down by the end of this article with a remarkable, 'That's it?!' feeling. Don't say I didn't warn you. It also turns out that I was not the first person to discover this, not by a long shot. More on that later. We had internal access as a low privilege domain user, but the client's defenses were top-notch and much of what I was doing was getting discovered, despite my attempts at stealth (bravo [redacted]!). As a red teamer, this is complicated emotion, because we love it when the client has good defenses, but we also love our shellz! So, I decided to take a deeper dive into Active Directory and see what there was to be seen. The client was using Microsoft ATA, which is a great product for defenders, but as of version 1.9 still had a glaring oversight that allowed red teamers to easily circumvent it's prying eyes: it didn't evaluate LDAPS-based queries (nothing new here, this is per Microsoft documentation). As I was proxying through a beacon, I used openssl to retrieve the domain controller's certificate, then configured ldapsearch to send all my queries against DC:636. Besides, TLS is good, and attackers need good security too, right? <evilgrin>. But, I digress… Using ldapsearch, I pulled down all attributes for all users. This amounted to quite a bit of data, however, ldif format is easily read and I started scrolling through standard users to see what could be found. A single attribute jumped off the screen: orclCommonAttribute. [caption id="attachment_15071" align="aligncenter" width="689"] <blink blink>[/caption] I kept scrolling, incredulous. I noticed that every single computer and user object had this attribute, and it was populated with what appeared to be a simple SHA hash. My first thought was that Oracle was storing its user authentication information in Active Directory, but that didn't make sense, because Oracle has its own directory for such things (Oracle Virtual Directory). This wasn't the user's Active Directory password hash was it?? I grabbed all the attribute values for user object (including Domain Admins!) and we got them loaded into our password cracking rig. Instantly, passwords started to crack. This particular client only had a single ADFS instance open to the internet, so I used the excellent Invoke-ExternalDomainBruteForce PowerShell script from NetSPI (github: here) and sent one of the credentials to ADFS. Now I can't dance, but in my mind's eye… Thousands of hashes cracked overnight, and we were DA by morning. Victory beers were had by all (that evening of course), and there was much rejoicing. I sent an email to Oracle's security team with the discovery and I contacted my client to let them know about a critical internal vulnerability. My contact said, "Oh yeah, that. Do you know Sean Metcalf over at Trimarc? He discovered the same thing two weeks ago…" I spit my coffee… THE Sean Metcalf? Sure enough, he had. It turns out my client had utilized Trimarc just a few weeks prior to our red team engagement and Sean discovered the same vulnerability in the same way. I contacted Sean, we compared notes, and both realized that we had each independently contacted Oracle with the finding. Sean's email to them basically said, 'Hey, this could be used by an attacker for privilege escalation purposes,' and my email said, 'Hey, we used this for privilege escalation purposes.' The biggest danger wasn’t so much the hash being stored in Active Directory as it was the fact that Authenticated Users had read access to it. That means all user and computer objects in Active Directory by default, including the low privilege user I had a shell as. Also, mighty kind of Oracle to inform us of the hash type and keep it unsalted. xDDD You might be asking why Oracle would hash the Active Directory user and computer password, then store it in an Oracle named attribute. I asked the same thing and Sean was kind enough to provide the answer: Apparently with certain Oracle products, customer have the option of installing a password filter on the DCs (oidpwdcn.dll) which captures when all user & computer password changes occur and the new password value. The Oracle password filter gets the new password, hashes it using SHA1, and updates the orclCommonAttribute value with the new hash. This process works for all computers (including Domain Controllers) and users (including service accounts and the krbtgt account). When a user connects to an Oracle system and authenticates using the username and password, the Oracle system hashes the user’s password and compares the password against the value on the user account’s orclCommonAttribute attribute. If it matches, the user is allowed access.Note that using Kerberos authentication avoids this configuration. Oracle confirmed the vulnerability and assigned it CVE-2018-3253. They requested we both hold off blogging until after the patch was released in October, and we were happy to oblige. Turns out, though we might have been the first ones to report it, we were not the first ones to find it. A specific search for that attribute is already in tools like LDAPPER (github: link). Moral of the story: Always check Active Directory. Always check Active Directory. For everything. You never know what you might find! Happy Hacking! @curi0usJack   PS - Having worked with Active Directory for many years (both in offense and defense roles), Sean's name was well known to me via has outstanding blog: adsecurity.org and his many excellent tweets (@PyroTek3). I was so excited that he was going to be at DerbyCon 8.0 that I went up to his booth and got a hug AND a coozie! Thanks Sean!!