Voice of the DBA

Tag: security

  • Default Credentials

    Years ago I got a call to help someone with a database. I walked over to their desk (when this was possible) and sat down. They asked me how they could get into a database they had been told about. I quickly realized this was an Oracle database and asked for credentials for SQL*Plus. This person didn’t have any, but I was able to log in with SYSTEM and MANAGER. This was a small department system of some sort, but it always struck me that the default credentials were available. Since then, every time I’ve encountered an Oracle database, I’ve tried those credentials. I’ve been amazed how often they worked, even for production systems.

    Recently there was a report that the Nissan corporation had some of their source code leaked. While I would prefer that the code running inside cars was open and widely examined, I was more dismayed that the leak was from an internal Git server with default credentials. Maybe even worse is the defaults are admin and admin, something that might not be hard to guess.

    I understand people make mistakes, and I do get that there are pressures people feel to get work done, but there isn’t a good excuse to stand up any server in production with default credentials, and I’d argue a VCS server is production. Even if you didn’t install the server and were just moving it to a new role, or you take over administration, you can’t leave default credentials around. You certainly can’t accept “admin” as a password in 2021.

    To me, this is grounds for termination. If nothing else, it’s certainly a reason to remove someone from a privileged position. Being this lax with security would worry me, and I don’t know that I could trust that you’d been careful with other parts of your job. If I encountered this, I would request that every other system under management be audited for improper admin accounts.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Security in the Aftermath

    Not too long ago was a very sad and embarrassing day for the US. The US capital was breached and rioters had hours inside without authorities. Ignoring the reasons and politics behind the event, think about the security of the building and systems after the criminals were removed from the building.

    Someone else brought up this point, which I think is fair. Can you trust any system in the building? Keyloggers, cameras, who knows what devices might have been planted. As a friend noted, anything with a plug should be thrown out. Who knows what might have been replaced or altered to create a security vulnerability.

    I haven’t had intruders in an office, but I have had to evacuate offices and returned to find unsecured systems. I’ve seen unlocked computers, when there were law enforcement or fire department staff walking around unsupervised. I doubt they did anything, and certainly never heard of any breach, but it is something to think about before you have to deal with the event.

    Have you thought about this or had to deal with this situation? Are you ready to audit systems and ensure nothing happened? Forget about spy devices, though those are certainly possibilities in this day of hot-plug USB keyboards, what about someone accessing information? If someone left a machine unlocked, would you think to check the history of the machine? Look at sites visited or emails sent? I don’t know I’ve ever thought about this, though in today’s world, this is something to consider. We are seeing some crazy types of attacks on systems, and I suspect it will continue to get worse.

    I learned a long time ago to lock my machine when I leave for any reason. A large group of administrators took delight in changing configurations, wallpaper, even sending embarrassing emails from unlocked machines to the group. After making a couple mistakes, it became a habit to lock a machine before you stood up for any reason.

    Most of us won’t deal with criminals walking around our office space, but we certainly should be careful and aware that unsupervised people around privileged systems is always a bad idea. I used to hate taking out the trash from a computer room I worked in, but I now appreciate that allowing cleaning staff into that space might not have been a good idea in a nuclear power plant.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • The Best Way to Protect Sensitive Data

    I was listening to someone talk about data privacy recently, and the ways that you can protect the sensitive information in your databases. They had a great quote about something you might consider. They said, “The best way to protect data is not hang onto the raw data at all.”

    If we don’t have sensitive data, then a loss of data can’t occur. Hacks won’t cause issues, we can’t accidentally send out data or leave it lying around. There’s a good case to be made that keeping less sensitive data around is a good idea.

    For some applications, we can’t avoid keeping sensitive data. Medical databases keep private health information. E-commerce systems likely need financial information. Many of us will definitely have to deal with some sensitive data, and protect it, but we can minimize our struggles.

    We often don’t have a good reason for keeping lots of data around. Lots of queries run by users end up looking at only a small portion of data. Often recent data is needed, and some aggregates for older data, but we don’t actually look at the details of old data often. We may even have older data around that we’ve forgotten about, and our users don’t even know is available.

    We certainly don’t often need sensitive data in non-production environments. Plenty of people use scripts or tooling to obfuscate, anonymize, generate, or otherwise ensure sensitive data isn’t in unprotected environments. We can archive, or even change, old data to ensure it isn’t a liability. We can even do this in production, preserving metrics, but delinking data from any individual.

    I’ve always been someone that kept more data than necessary, just in case I needed it. However, over time, I find that the costs, and the potential risks, just aren’t worth it. Moving forward, archival, anonymization, and other strategies need to be a part of any system I manage.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • A Need for Monitoring without Administration

    There was a report recently that a number of US government agencies were hacked through a network management system. Apparently Solarwinds had their code hacked, and this resulted in a backdoor being distributed to customers via software updates.

    There is a lot that went wrong here, and this ought to make many system management software vendors very nervous. Attacks on your software developers, designed to allow a hacker to put backdoors into source code repositories is a wild second (or third) order attack. I would certainly be nervous to be a software developer right now, and be extra cautious about any sort of potential phishing email sent to me. Yes, that’s a thing.

    The bigger issue, to me, is that monitoring most systems ought to be possible without requiring escalated privileges. While there are some ways to get metrics without requiring administrative rights, most OSes and most administrative and monitoring software expects to have complete rights to all resources.

    That’s a hole in design. There are plenty of cases where we want monitoring data (and alerts/notifications) distributed to other automated systems or to interested individuals, but we don’t want to expand the number of administrators. Every additional individual or system that can potentially change something as an administrator is another potential attack vector.

    We have built our core operating systems with the idea that someone needs complete control of the system to work with it. For some things, that’s true, but for resource usage, especially in the way that many of us need to watch at scale, I’m not sure that this needs to be the case. My view is that Windows, MacOS, and Linux ought to undertake fundamental design reviews to determine if they can further shrink the scope of privileges for monitoring systems.

    In the meantime, granting privileged access to an automated system for monitoring ought to be done very carefully, even more carefully than for human sysadmins. This account will run by itself, and someone might not notice if it is compromised. Set strong, very long passwords, change them periodically, and audit the account to be sure it is only accessing what you think it should access.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.