Oracle hackers horror stories

We need not look far to see the public cases of computer security violations and the liability suffered by the custodian of the Oracle data.  With millions of dollars at stake, there are many resourceful people waiting for you to make a mistake and expose your confidential information.  These attacks on your information take many forms, from malicious hackers, dishonest employees and honest mistakes.  Let's look at some specific ways that companies lose control of their information. 

Oracle Security Breaches, Hacks (outside-in)

 

Threats from hackers remain a major concern, especially threats from overseas countries in Eastern Europe and Asia.   Some companies report access attempts by automated hacker 'bots' every few minutes as these rogue programs constantly sweep the Internet looking for ports with access vulnerabilities.

 

These automated bots contain very sophisticated logic and are designed by criminals to identify and exploit weaknesses in online computer systems.  Some of the common exploits include: 

:         Tipping the user ID : This is where a telnet or FTP access attempt tells you that you have entered a valid ID, but provided an improper password.

 

:         No password disabling : Hacker routines love systems that do not disable a user ID after repeated password attempts and run bots to try hundreds of thousands of password until they gain entry.

 

:         Man-in-the middle attacks : Hackers can gain access to computer systems by guessing the IP address of a connected user and sending a TCP/IP packet with that users IP information.

 

:         Injection threats : Many Oracle database systems have vulnerabilities where access to confidential Oracle data can be gained via a SQL injection, a technique where a '1=1' string is added to a sign-on string.  For example, this query might return the 'real' password for a user named Jane: 

 

select

   userid, password

from

   dba_users

where

   userid = 'jane'

and

   password = 'xxx'

OR 1=1;

 

:         Buffer Overflow attacks : In these attacks, the web cache buffer is deliberately overloaded to gain unauthorized entry to the system. 

Hacker attempts for web-enabled systems are constant and many companies report thousands of attempts every day.  A comprehensive auditing system will record all illegal access attempts and include the time, referrer IP address and all other relevant information.  Let's take a look at a real-world case.

The Extortion Attack Case
 

In this case a hacker exploited a server vulnerability, siphoned confidential information from the corporate Oracle database, and shipped it to a foreign nation that did not honor U.S copyright law.  A foreign cohort then extorted the company, proving that they had the Oracle data, and threatened to disclose proprietary secrets to a competitor unless they were paid a significant sum of money.

 

Faced with the loss of their competitive advantage, the company contacted the FBI and was told that there was no reciprocity with the nation and that Interpol would not be able to investigate or arrest the extortionists.  Even worse, Oracle management had not detected the leak, and had no idea how the thieves had accessed their Oracle database.

 

Surprisingly, this is not an uncommon occurrence, and many multi-national companies have accounts for bribery and extortion expenses because they are a legitimate requirement for doing business in some overseas nations.  In this case the company quietly paid the extortionist in return for the promise to destroy the Oracle data and details about how the Oracle data was stolen.

 

While there are always exposures from the outside world, we must also account for attacks from within our company firewall. In practice, 'inside jobs' are more common than external attacks, and they can often have devastating consequences. 

Internal Fraud (inside jobs)
 

IT managers report that internal fraud is the most common type of threat and special auditing mechanisms must be used to audit all access by authorized employees.  Inside job threats include the following: 

:         Root kit attacks : In a root kit attack, the operating system is compromised.  I once fixed a client site with a root kit that had installed a daemon process that was constantly accessing confidential information and e-mailing it to a competitor.  This attack went undiscovered for more than a year and virtually all of the company's proprietary information was lost.

 

:         Fire-me attacks : Internal Oracle personnel have been know to write routines that trigger an Oracle data extraction on the day when their user ID is removed from the computer system.  Because most Oracle procedures required pulling the user ID before notifying the employee, these hackers will return home to find all of the confidential information waiting for them in their in-box.
 

:         Trojan horse : Once an employee gets the internal IP address of another employee, they can map-out phony sign-on screens to their boss and get a privileged password.  These attacks are usually easy using tools such as X-Windows that allow screen images to be redirected onto other screens.

 

:         PC Privacy tools : Common tools such as PC Anywhere can be used to look-over the shoulder of a co-employee, snooping into their activities and passwords.

Inside jobs are the most difficult to detect, but complete audits will always reveal the 'who' and 'how' aspects of the attack.  For example, coded implants can be tracked using your source code control system software that is required by almost all Federal Regulations including SOX and HIPAA. 

 

Here are many documented cases of Oracle data disclosure by disgruntled employees, especially 'privileged users' who were given unaudited access privileges.  Let's look at some specific real-world horror stories.  These are not fictional stories. They actually happened, and they serve as examples of what can happen when a slack Oracle manager entrusts their access and auditing controls to a Systems Administrator or Oracle database Administrator. 

The Root Kit Case
 

We received a call from a client who was complaining of performance problems on their Oracle database which was running on a standalone Linux server.  The company was in the business of providing credit information to third-party companies to access an individual's probability of financial default.

 

Upon accessing the server, it was apparent that something was terribly wrong. Even when idle, the Oracle database was performing I/O operations and the processors were active, even though Linux did not show any active processes.  The Linux 'ps' command failed to reveal any active processes.

 

After a Linux expert was consulted the real issue was discovered.  A disgruntled Systems Administrator had left a time-bomb on the server, to be activated when their user account was removed from the /etc/passwd file, indicating that they had been fired.

 

This time-bomb was activated when the System Administrator left the company to 'pursue other opportunities', and the attack was both clever and devastating.  The attacker placed a Linux daemon process called 'vacuum' on the Linux server and this process was constantly polling the Oracle database, seeking new information, and e-mailing it to an overseas mailbox.

 

This attack has disclosed the entire Oracle database of confidential information to an unknown party, and the company was held fully responsible because they failed to institute a third-party employee to manage their server security.

 

The attack was very sophisticated and unobtrusive.  The malicious employee had replaced the standard Linux commands with a 'root kit', an attack method readily available on the Internet.  In a root Kit attack, the Linux commands are replaced with an alias to disguise the presence of the Oracle data stealing mechanism.  In this case, the process command 'ps' was replaced with the command 'ps|grep 'i vacuum', such that the process would not appear within Linux.

 

Sometimes internal fraud occurs when employees are entrusted with Oracle data that has value to outside parties.  Let's take a look at one such case. 

The Phony College Transcript Case
 

In this real-world case, a Oracle database Administrator for a major university was caught 'enhancing' college transcripts to allow people to gain acceptance to top professional schools.  The DBA had complete control over the Oracle database and the auditing mechanism and was charging friends and acquaintances thousands of dollars to add courses and improve existing grades.  Because the DBA controlled the audit mechanism she was able to completely erase all traces of the fraudulent changes.

 

This fraud went undetected for more than five years until a professor discovered the fraud.  The professor was asked questions about a former student as part of a pre-employment background check and discovered that the student had never taken his class even though the official university transcript indicated an 'A' for the course.

 

Ironically, the bulk of the fraudulent transcripts were used to gain entrance to law schools and several of them had graduated and were practicing law.  The losses and penalties from this access violation were substantial: 

:         The Director of Oracle database Systems was fired for malfeasance for allowing the security loophole.

 

:         The university suffered a huge loss of credibility and the accuracy of over 100,000 graduates were tainted, all because of a single privileged violation.

 

:         The perpetrator DBA pled guilty to computer fraud and grand larceny and received 5-10 years in Federal prison.

 

:         The university had to undertake a grade re-verification process that cost more than $600,000 dollars.

 

:         Several practicing attorneys were disbarred, but ironically many of those who had successfully completed their graduate schools were allowed to retain their degrees, even though they entered the schools with falsified transcripts.

Of course, not all privileged disclosures are malicious.  Next, let's look at cases where honest mistakes can disclose confidential information to third parties. 

Honest Mistakes
 

In many cases multi-million dollar losses are the result of human error and bad judgment on the part of the users of the Oracle database, and in some cases, the Oracle staff.  These types of mistakes can take the form of trusting a telephone caller who wants a password (the Kevin Mitnik approach), or a failure to recognize the impact of the disclosure.

 

There is also an important issue when information is aggregated by the Oracle department for marketing purposes.  The privacy and security laws allow the sharing of summarized information so long as the identity of any individual cannot be ascertained.  However, when the summarization includes 'outer bounds' Oracle data then it is sometimes easy to violate disclosure laws.  For example, a report summary of HIV patients, aggregated by city and profession might reveal the personal identity of the only Taxidermist in Nome Alaska.

 

Caution must be taken when sharing summarized and aggregated personal information to remove all results with a limited set of participants so that personal identities are not revealed.  Let's take a look at how honest mistakes can cause irreparable harm to your company. 

The Hotel Fiasco Case
 

In a widely publicized court case from the 1990s, a major hotel chain collected detailed information about their weekday guests' use of their hotels.  They employed an Oracle data warehouse analyst who created a target marketing campaign, offering special coupons to those guests who frequently used the hotel on weekdays.  This targeted mass mailing of weekday-stay coupons were sent to the home addresses of the guests, with disastrous results.  More than a dozen people were informed about their spouse's infidelity as a direct result of this coupon campaign and more than six divorces resulted from the company's actions.

 

While this action was not in violation of the privacy laws per se, the result of the campaign was to disclose private information about embarrassing information to a third party.  A more appropriate approach in this case would have been to mail the coupons to the guests work addresses.

 

These horror stories serve to remind the Oracle manager that a comprehensive auditing and security system must have controls to audit all telephone disclosures of confidential information, including verifiable information about the recipient of the information. 

Privacy Issues Associated with Oracle data Viewing
 

The protection of personal privacy is an important aspect of system auditing, and the Oracle manager must remember that Oracle is their responsibility to ensure that the information is not improperly disclosed to third parties.  However, an important legal issue arises when one of your employees accesses private information for non work-related purposes.  These purposes might include an employee finding 'dirt' on an ex-friend or previous boss, or using their access to your computer system for extortion or harassment. 

 

In one important appellate case, a woman's job description involved accessing confidential information.  As an authorized user, she accessed embarrassing information about her ex-husband and used the information to her benefit in a child custody case.  The court ruled that even though the information was obtained with an unsavory motive, the ex-wife was authorized to view the Oracle data and the damning confidential evidence was allowed in the case.  The ex-husband, outraged at the privacy violation, sued the ex-wife's employer for millions of dollars for allowing his ex-spouse access to his confidential Oracle data.  In this case, the company needed safeguards to verify 'why' the Oracle data was needed.  It's not enough to issue a blanket authorization and hope that the privilege is not abused by your employees.

 

In these cases the Oracle manager must have a full audit trail but they must also be also be able to show 'why' that employee needed access to the confidential information. To provide this level of detail the Oracle audit trail must show contextual information about the employees work session and show the flow-of-control within the computer system.

 

This is another area where a 'detective' approach to audit analysis is valuable.  Sophisticated audit control systems allow for specific decision rules to be applied to audit trials and these algorithms are designed to detect unusual patterns of access to private information.

 

Taken together, these issues make Oracle privacy security auditing a scary and risky proposition.  Let's face it, with something as mission critical and challenging as auditing an Oracle manager would be insane to attempt to create their own solution.  It would be like an Oracle shop writing a proprietary Oracle database management system.  Of course, such things are best left to companies who specialize in such matters.

 

Even more importantly, the Oracle manager has enough responsibilities without being held accountable for Oracle data security software.  By acquiring a nationally-known and respected product, the scope of liability for the Oracle manager drops dramatically and they are only responsible for the proper installation, administration and management of the auditing software.

 

Oracle Training from Don Burleson  The best on site "Oracle training classes" are just a phone call away! You can get personalized Oracle training by Donald Burleson, right at your shop!