» VIEW ALL POSTS Jul 9 2007   10:11AM GMT

Oracle security bloopers II



Posted by: Clinek
Tags:
Managing an Oracle shop
Oracle database administration

Last week, I asked you DBAs and consultants to send in the worst Oracle security nightmares you’ve come across. A few of you have responded so far. Read them and weep:

************************** 

Terry M. wrote:  

I was working as a software consultant going on site at a defense contractor.  Security was so tight that I had to be escorted to the bathroom and searched before going into and out of the site.

I was there to install a database monitoring software package for several of their Oracle 8i database instances.  The install requires the user to enter the sys ID and password to grant select on some data dictionary tables and the on site DBA that I was working with requested that I step outside of his cube while he entered the sys password.

After several failed attempts, and my hearing him curse a few times,  I noticed a repeating pattern of keystrokes which I immediately recognized — see if you can guess:

Tap Tap Tap Tap Tap Tap … Pause … Tap … Pause … Tap Tap … Pause … Tap … Pause … Tap Tap Tap Tap Tap Tap Tap

After about 5 minutes of listening to him fail to get the password correct and cursing, I finally had to speak up . . . as I turned around and walked back into his cube, I said “excuse me, but your sys password wouldn’t happen to be ‘change_on_install’ would it?” He immediately became suspicious and accused me of somehow watching him enter the password when I was clearly behind the outside of his cube wall.  I quickly told him that I bet I knew his system user password also: ’manager’.  He was astonished and extremely embarrassed when I explained to him that those two passwords were the default passwords for the sys and system accounts on every Oracle database installed.  And that it was common practice for every DBA to immediately change those passwords to secure their database instances.

Unfortunately, we lost the sale — he explained that he had over 100+ database instances that he had to go change the passwords on; ushered me out the door; and never called back to reschedule another visit.

**************************

Rick K. wrote:

Like most Oracle professionals, I subscribe to several Usenet groups so I can keep my skills current.  Well, a few years ago a DBA needed some assistance and posted a question in which he shared his tnsnames.ora file and wondered why he could not connect to SQL*Plus with the following syntax:

sqlplus system/SecurePswd@prod

Almost immediately several people connected to this person’s production system and was able to fish around the system.  Numerous people emailed the DBA back and pointed out that he just broadcasted to the world his production connection string and password. How crazy is that?

************************** 

Anonymous wrote:

I know a firm that has a partnership arrangement with several credit card companies.  These partnerships involve the credit card companies initiating an electronic process to create an account with the firm for their card holders to receive services from that, which are then billed to their credit cards. 

Unfortunately, the credit card companies seem to have a remarkable difficulty keeping track of which accounts are billed to which credit card numbers.  As a result, the credit card companies sometimes need to ask the firm for a list of accounts associated with certain credit card numbers.  On more than one occasion, a representative of a credit card company has sent an unencrypted email listing tens of thousands of credit cards numbers, thus breaching the PCI DSS which the credit card companies are trying to enforce.

************************** 

Sean S. wrote:

Unfortunately, this comes from the government, in fact, the military. I was brought in as a consultant to manage a set of Oracle8 databases for a branch of the US military. One in particular contained sensitive data which could be used to track the whereabouts of strategic military assets around the world. It was open to the internet, on port 1521, so that remote locations could connect through the application. When I came on board, the first thing I checked for were default passwords. Of course, scott/tiger was there. What’s worse was system/manager and sys/change_on_install were, too. So I approached the manager to tell her that the password needed to be changed.

“Oh no, you can’t do that!”

“Why not, I asked?”

It turns out that there was a committee of about 60-70 individuals, contractors, vendors, and representatives that met via conference call on a weekly basis to discuss the database and application. When the database was first installed, the subject of changing the password came up, but the committee couldn’t decide on a suitable password to change it to. Debate raged for several minutes over who had the best password and policy, and with no solution in sight, the idea of changing passwords was tabled until the group could reach agreement. No action was taken, and the subject never came up again, apparently.

Your government in inaction. Needless to say, I changed the password and told them they could change it back when I left.

But wait. It gets better…

Just prior to Y2K, we learned that foreign hackers were going to attempt to compromise military computer networks. A couple of security drills ensued, but a few days prior to Christmas, 1999, we had a new task at hand. We were instructed to label every cable leading in and out of every machine in the server room, be it a server, disk array, network switch, or monitor. On December 29, we powered down every machine, and unplugged them from everything. Literally. Both ends of every cable were disconnected, be it power, network, SCSI, or a keyboard. Machines were moved out into the middle of the room so you could walk around them and see they were physically disconnected from everything. Tiles on the raised floor were left up so that you could verify that nothing was plugged in. Everything was to be left in that state until at least January 3rd.

We were told in our briefing that this was to prevent terrorists from disrupting our activities. Of course, I raised my hand to ask what I felt was the obvious question: “Aren’t we doing for the terrorists exactly what we only think they might attempt–that is, disabling our computer systems–and assuring them of widespread success where they might not accomplish anything at all?”

The answer: “No. We’re doing this on our terms.”

That’s like saying that if we had intelligence about an attack on Pearl Harbor, that we should have sunk the Arizona on December 6th, in order to be doing it on “our terms.” Sigh.

************************** 

Sigh indeed. It’s like driving by a car crash — we’re drawn to it and repulsed at the same time. If you have any (anonymous) additions to this sad and funny parade of ignorance, let’s hear it!

Have a good week, Tim 

4  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Clinek
    What an awesome post. I come across such stories all the time. Default usernames/passwords, shared usernames/passwords and sending of sensitive data on non-secure channels is definitely a recurring theme.
    0 pointsBadges:
    report
  • Clinek
    This isnt Oracle security, but it is security. In the late 80s, I was working for a defense contractor, shortly after the first of the internet worm attacks went through and locked up most of the Unix systems on the internet. Someone their decided to publicly announce that our systems were secure from attack. I discovered this after the fact, of couse. I had never seen such a perfect case of painting a target on oneself.
    0 pointsBadges:
    report
  • Clinek
    How silly can you get? Every single one of those cases you have listed is not an Oracle security problem. For some reason I was under the impression that some users may have figured out something clever to get around a security mechanism provided by Oracle, but not so. All cases you have listed are problems with naive users not knowing what to do, not a problem with the Oracle product (no I don't work for Oracle). For example in an Oracle 8i and below, a user with export permissions could view passwords set in database links by extracting the text using the strings command. That I think they have fixed in the later releases. This is an example of a security hole in Oracle, you shouldn't have to know other people's passwords even if you are a dba. Now if I write my password on a paper and stick it in my cubicle with a push pin, then that is my problem, not Oracle's. In the IT field there is no shortage of people, many holding advanced IT positions and running the show who clearly don't know what they are doing, but they also don't hesitate in preventing other people in doing what needs to be done. But I wouldn't call that an Oracle blooper.
    0 pointsBadges:
    report
  • Clinek
    Krah, That's a valid point. However, securing enterprise data is more than just using Data Vault or other Oracle features properly. There is definitely a "human element" and these examples show how incredibly important that is. --Tim
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: