Tag: security

When I worked in a large Operations team, we had various passwords for some systems that we stored in a password vault. This was on a network share that only the administrators had access to read. We used this for keeping a number of passwords for various services and systems that required sysadmins to access.

However, we tried not to use shared accounts whenever possible. We wanted to ensure an audit trail, for both compliance and understanding of what happened in our environments. All sysadmins had two accounts, which allowed them to access most services. We only had a user/password stored for certain systems that needed some sort of separate account, and we did change those passwords regularly.

Our customers didn’t always do this. In fact, I regularly found different groups using a single account, always logged in, for which everyone knew the user name and credentials. They never seemed to consider this a problem, despite regular security warnings from administrators.

I was reminded of this story about a water treatment facility in Florida that was hacked. They had a shared account, used by many people, the same password for everyone, and a lack of a firewall. An intruder caused a release of chemicals, but no one was injured.

Firewalls prevent a lot of issues, if they are configured to limit access. In addition, ensuring that each user has different passwords is important. This allows you to turn off access for certain people, which includes former employees. That’s basic security, and I’m surprised how often people forget about this, often because they worry about some system breaking.

The tools we have to enforce stronger security have improved over the years, but we need to take advantage of them, and we need to ensure that good, if not best, security practices are followed. It’s easy to become lax over time, but remember that there are lots of threats out there, from hackers to malware, to former employees.

Far too many people are attacked, more than are in the news, so don’t get complacent. We are all at risk.

Steve Jones

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

I hadn’t heard about this problem at all until I saw a story recently. Apparently a one line command can be hidden inside a Windows shortcut file, a ZIP archive, batch files, or various other vectors. This command can trigger hard drive errors that corrupt the device.

Yikes. A researcher apparently has been trying to draw attention to this since August, but it has not been fixed. What is scary is that this issues can be exploited by tricking standard accounts in Windows, not just privileged ones.

However.

It’s not really a big problem. I asked around and someone sent me a few links that this doesn’t actually corrupt the drive, but just gets Windows to report this. In that case, this might not actually do anything, but it certainly would cause my blood pressure to rise and my heart to skip a beat. This also might be a great phishing vector.

If you get a message about corruption, check that it’s actual corruption and not just the report from a shortcut or link that uses this message. Certainly, be careful about what you click.

And if you’re thinking of playing a joke on someone, this isn’t a good choice. This is more like vandalism than fun. I certainly wouldn’t be pleased if you did this to me.

Steve Jones

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

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.

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.