Posted by: Clinek
when relevant content is
added and updated.
when relevant content is
added and updated.
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:
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?
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