Well this is sobering stuff for internal auditors and SOX compliance professionals: a cybersecurity firm is raising alarms about flaws in the Oracle business software that countless companies use to manage their finances, which lets hackers steal or alter financial data — all undetectable by standard internal controls or GRC technology.
Be warned, this is a dense technical issue. The implications for internal control, however, are disturbing enough to send CFOs, financial compliance teams, and audit committee chairs breathing into a paper bag. So let’s unpack this carefully.
The security firm that pieced together the threat is Onapsis, which studies vulnerabilities in business software platforms such as Oracle and SAP. Onapsis released a report on June 16 analyzing weaknesses it found in Oracle E-Business Suite. More than 21,000 companies use Oracle EBS to run corporate accounting, supply chain management, logistics, HR management, and lots of other mission-critical functions.
Picture Oracle EBS as the physical structure of your house, with each business application working in its own room. All the data managed by those applications is stored in the Oracle General Ledger application, which is the basement of the house. Other Oracle business applications extract, process, and return data to the General Ledger all the time.
The threat is that through security flaws in Oracle EBS code, hackers can directly access the General Ledger to alter data or execute commands as they like. When audit teams later pull reports from the General Ledger to compare that data against information in other Oracle EBS applications — nobody can find the original hack, because no transaction record exists.
Go back to our house analogy. You might have a key-entry security system on all the doors, generating a complete record of who comes and goes. Onapsis’ discovery is akin to a design flaw in the windows. An intruder can pry one open in the basement, steal valuables in storage, and vanish. When you look for those valuables weeks later, you’ll have no idea when they disappeared, and the security logs for your front and back doors won’t show anything was amiss.
Another Example, This Time With Numbers
Say the corporate accounting team uses Oracle Accounts Payable to manage financial transactions, and processes data through the General Ledger. After the quarter closes, the external auditors want to see a trial balance report.
So the auditors pull that data from the General Ledger. In a normal scenario, the trial balance report shows the company had $1 billion in cash at the start of the quarter, deposited another $500 million, paid out $750 million, and ended the period with cash balances of $750 million. See Figure 1, below.
In our scenario, however, shortly after the quarter ended and the accounting team closed the books, hackers used command-line attacks to access the General Ledger and alter the numerical values of the accounting data stored there. They increased the value of credits paid out from $750 million to $10.75 billion — so while the cash balances should be $750 million, the trial balance report would show a deficit of $9.25 billion. See Figure 2, below.
The auditors would see that $9.25 billion deficit and ask the accounting team what happened. But the accounting team wouldn’t know what happened, because no record of that changed data would exist.
Why not? Because this vulnerability is known in IT security as an unauthenticated attack. That is, the hackers exploited vulnerabilities in Oracle EBS code to change data without ever needing a user ID or password.
That’s very different from false authentication attacks, where someone steals your user ID and password in a phishing scam and then uses those credentials to access corporate IT systems. At least in that case, audit teams could sift through access logs to pinpoint where someone using stolen credentials changed the trial balances to create a $9.25 billion deficit.
The vulnerability Onapsis uncovered leaves no such trace. From the accounting team’s perspective, all transactions were recorded properly, all internal controls worked properly, and no unauthorized access ever occurred — right up until a $9.25 billion deficit in the trial balance report demonstrates that nothing was working properly.
What are the internal control headaches here? Let’s count:
- If hackers changed the data, by definition that means that first they saw the original data. So your company’s confidential financial information has been compromised.
- At the least, a mismatch between application records and General Ledger records means you have ineffective internal controls, and probably a material weakness. You’ll need to disclose that.
- Because this hack leaves no trace, you’ll need to undertake a forensic analysis to figure out exactly which accounting data was altered. That takes time and money. It could lead to a late filing of quarterly reports, and will definitely lead to higher audit and consultant fees as you unravel the mess.
The Bigger Picture of Risk Here
The good news is that this specific vulnerability is known. It’s called the BigDebIT vulnerability, and Oracle sent around a patch earlier this year to seal up that weakness in your Oracle EBS.
The bad news is that this is only one example of the concept. Where there’s one vulnerability that exposes corporate data in this manner, there are more; and the compliance implications for ignoring an avenue of attack like this can be severe.
For example, hackers could use this exploit to access the HR data stored in General Ledger, and cause a privacy breach. They could use the exploit to execute actual commands — like, say, transferring cash from a corporate account to an overseas bank. They could steal confidential financial data to trade ahead of an earnings release, commit corporate espionage, and lord knows what else.
In all of these scenarios, GRC tools and segregation of duties wouldn’t help because they are meant to prevent users from executing improper transactions among your software applications. This vulnerability circumvents all of those protections to manipulate data directly. As one internal auditor told me, “I didn’t believe it at first. This is like someone telling you ‘The Matrix’ is real and we’re living in a fake world.” Yes. Exactly.
How could something like this strike your company? Well, the more connections your Oracle EBS system has to the Internet, the more exposed it is to hackers. So if you’ve been giving employees more remote access to Oracle EBS lately — like, say, maybe there’s a pandemic going on or something — then your risk is increasing.
The appropriate move would be strong patch management for your Oracle software. Many companies do take software patches seriously, but plenty don’t. Or various groups know that patch management is important, but aren’t sure who is in charge of implementing patches. That should be the job of the CISO or IT manager, but if you have immature oversight of IT controls then issues like this can go overlooked.
And we should also note that while I’ve talked about Oracle EBS today, the same basic risk exists for those of you operating SAP software. The code itself can be hacked, leaving financial data exposed, and all of it goes undetected by typical internal controls. Auditors won’t know what happened, and neither will you.