Thursday, September 17, 2020

ZeroLogon Vulnerability and EPM On-Premises AND Cloud

I don't normally write about Microsoft vulnerabilities and related patches, but this one is important for all Oracle EPM / Hyperion instances... whether on-premises or in Oracle's EPM SaaS Cloud.

A little background.  Vulnerabilities are ranked on a score from 0.1 to 10.0.  What I'm about to discuss here is a 10.0, which is the most dangerous score.

The official designation of this particular critter is "CVE-2020-1472".  Independent security research firms, such as Secura, refer to it as ZeroLogon.

Microsoft issued a patch for it in August 2020's "Patch Tuesday", but the extent of the problem wasn't fully known at the time.

If you want to read the gory details, you can check out Secura's white paper on the subject.  I'll summarize in brief:

The vulnerability allows anyone having access to the network to become a Windows Domain Administrator.  You don't even need network credentials if you stroll into the office and plug a device into an Ethernet port.  Remote workers, of course, often have the access required. The point being that once the attacker runs the exploit and elevates himself to a domain admin, or creates a new domain admin account with a known password, he can cause all sorts of mischief with far-reaching consequences throughout the organization.

Now let's talk about EPM, starting with on-premises and then moving on to Oracle's EPM SaaS Cloud (PBC, FCC, etc.).

Microsoft Active Directory ("MSAD") is ubiquitous within the on-premises EPM space.  The vast majority of EPM implementations I've supported, installed, or health checked use MSAD for end-user authentication.  Hyperion Shared Services and the various EPM components connect to a Windows Domain Controller in order to authenticate end-user login attempts.

Disclaimer: the following paragraph contains theoretical conjecture.  We won't know the effects for sure until an non-patched system is attacked. 

Our fictional attacker who exploits ZeroLogon can completely break this.  Worse, the attacker could kick the EPM servers out of the domain, making it hard to hop on the EPM servers and troubleshoot why nobody can login.

I have worked with a few customers who use alternatives to Microsoft for end-user authentication, such as Novell eDirectory or other LDAP solutions.  By and large, though, there can be a Microsoft Windows Domain lurking somewhere within the network.

They key takeaway here is EPM system stakeholders should inquire with the IT department and confirm the Domain Controllers have had the August 2020 Microsoft patches applied.  I've noticed it is a mixed bag "out in the wild"; some organizations patch immediately, while others lag behind... especially during financial Quarter-End or Year-End change freezes.

Now let's talk Cloud briefly.

Oracle's EPM SaaS Cloud products for Consolidation, Planning, Account Rec, etc. all share one thing in common: EPMAutomate.

EPMAutomate is the Cloud's command-line utility used for a variety of tasks: upload data to the Cloud, run it through Data Management, fire off Calculation Rules, download reports and audit logs, and more.  EPMAutomate resides on a server under the customer's control, either on-premises or in a hosted cloud such as AWS, Azure, OCI, etc.  The vast majority of EPMAutomate implementations I've seen happen to sit on MS Windows servers.  (It can be hosted on Linux, and sometimes I witness that variation)

If EPMAutomate is hosted on MS Windows, and that machine happens to be joined to the MS Windows Domain... well, there's a possibility your EPM Cloud automation might stop working someday if an intruder bricks your network account or kicks the EPMAutomate host server out of the domain.  (Again, I use the word possibility until we see the fallout when it eventually happens)

2020 has been an awful year thus far, so please do your part not to make it... awful-er.  Insist your network domain controllers get patched for "CVE-2020-1472", included in August 2020 Microsoft Patch Tuesday.


Hat tip: Penetration Tester Dustin Heywood

4 comments:

  1. Hi Dave,

    We have an issue with Login into workspace for few Active directory users

    Users are facing this error ""Loading the module 'wksp.mode' failed."

    When ever we see the above error for those few users we got to know that the below windows event viewer error causing that issue.Please confirm

    Error:
    Faulting application name: HyS9RaFramework_Foundation1.exe, version: 1.0.0.2, time stamp: 0x512cbfcc
    Faulting module name: ntdll.dll, version: 6.1.7601.24559, time stamp: 0x5f28ed4c
    Exception code: 0xc00000fd
    Fault offset: 0x0000000000031102
    Faulting process id: 0x30e0
    Faulting application start time: 0x01d689e644fdaf6c
    Faulting application path: C:\Oracle\Middleware\user_projects\domains\EPMSystem\bin\HyS9RaFramework_Foundation1.exe
    Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
    Report Id: 35afa069-f767-11ea-a553-0050568f7eee


    ReplyDelete
    Replies
    1. This is the error and please let me know your suggestions on this since I could not find any solutions

      Faulting application name: HyS9FoundationServices_Foundation1.exe, version: 1.0.0.2, time stamp: 0x512cbfcc
      Faulting module name: ntdll.dll, version: 6.1.7601.24560, time stamp: 0x5f472aa1
      Exception code: 0xc00000fd
      Fault offset: 0x0000000000031102
      Faulting process id: 0x52dc
      Faulting application start time: 0x01d690f48850531b
      Faulting application path: C:\Oracle\Middleware\user_projects\domains\EPMSystem\bin\HyS9FoundationServices_Foundation1.exe
      Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
      Report Id: dde4a71f-fce8-11ea-9b3b-0050568f7eee

      Delete
    2. Hello! I've hit a similar issue before. You might need to do 2 things. First, check that your custom shutdown script is pointing to the correct drive and folder. If it is wrong, files in c:\windows\system32 will go missing. The second things is you might need to re-run the visual C runtime. You'll find the installer buried under your \oracle\middleware\common folder if I remember. Best wishes.

      Delete
    3. I shouldn't post so early in the morning. :) What I meant to say is some custom shutdown scripts I've seen attempt to wipe out the temp folder. If there's a typo in the script then it instead blows away files in the system32 folder, which is the default folder when you launch a dos script. If this happened to you, either run the visual c runtime installer again, or copy files from system32 from a working server.

      Delete