Networking

Security Minded

As I was setting up FTP access for our clients, I got upset, once again, at how we handle our policy regarding customer access. One of our customers does this right: each person in our company who needs to access their network has an individual username and password. My boss, and most of our customers, just want a single username/password for anyone in their organization to use. Already, this gives me a stomach ache. The idea that someone who does, or used to, work for our customer would have access to our network, with me having no way to block them by IP address, or be able to tie a login attempt to a particular individual is a frightening thought to me.

To make it worse, a number of the higher-ups got upset at the passwords that were being assigned. "They won't be able to remember these passwords!" was the main complaint. Well, Windows 2003 won't let me assign easier passwords, unless I change the default policy. I'm not going to do that. Our customers have been accessing our systems with username/password combinations like "companyname/companyname" for far too long, as far as I am concerned. We process sensitive data, such as sales figures. As it is, I am considered an "inside trader" as far as blackout periods and whatnot are concerned, because I have access to all sorts of raw data, and that data in turn becomes finished reports. It is extremely important that we safegaurd this data to the best of our abilities.

My stance is, if our customers cannot be bothered to learn a complex password to protect this data, they need to get out of the industry. NOW.

This entire situaiton got me thinking back to some of the other security faux pas that I have witness during my time in IT. Here are a few of my personal favorites:

  • A major US bank outsourced its network management. Us peons at the Third Party Vendor had a habit of writing down router usernames/passwords. Even the HQ routers used the same usernames/passwords. Sure, it was all VPNed with IP address filtering, so no one outside of the "green zone" could access their routers. At least not over VPN. Sadly, all of their routers had either ISDN or dialup failover interfaces. The ones with dialup interfaces could also be accessed by dialing in, for troubleshooting purposes. There was no differentiating what you could do based upon which interface you came in on, so in theory, anyone with one of those phone numbers can dial in to one router, telnet to a HQ router, then access then entire network from there. It would be trivial to shut down the entire bank's network of ATM machines and branches in a matter for an hour or two with a well written script or program that can dial a modem. With no accountability, other than the phone number from where the initial call was placed. Oh yeah, did I mention that they have never onced changed their passwords, and that the passwords, as well as all troubleshooting information are freely available within the TPV's intranet to all who want to see it?
  • At one company I worked for, we had a massive Solaris server running HP OpenView. Sadly, HP OpenView is probably the worst engineered piece of software ever to be sold outside of the $10 "Instant Website Maker!" section at Best Buy. It is a testament to Solaris' abilities that the server kept running, because HPOV was leaking memory like a torpedoed ship leaks water. Here's where we had a nice little hole in our security: because HPOV was such a steaming pile of garbage, every user had the root password, so they could kill and restart HPOV. You might as well just make everyone a root user, at that point.
  • Growing up and learning COBOL on an ancient system, what a fun time. too bad we were all umasked so all of our work was chmod'ed to 777. It's not hard to cheat or destroy someone else's project (as happened to me, someone changed one of my PIC statements, and it took me two months to find out why my final project never quite seemed to work right) when hacking is a matter of "cd ~username".
  • File permissions are a favorite security faux pas of mine. A company I used to work for (let's just call them "a Fortune 500 company who's former CEO now runs one of the top three computer makers" and leave it at that) used network storage space for all sorts of important documents. A lot of these documents, frequently pertaining to things such as the status of sales to customers, layoffs, offshoring, outsourcing, contractor conversions, employee pay rates, and so forth were typically created with read permissions to the "Everyone" group, because some nitwit sys admin had turned on inheritable permissions (fair enough) but set the top level permissions too loosely.
  • Microsoft Indexing Service = "Intranet That Can Find The Documents I Am Not Supposed To Find". Just do a search within many corporate intranets for phrases and words such as "layoff", "consolidation", "India", "sexual harrassment", and so forth, and you find all sorts of embarassing things that were never explicitly linked to. What a great thing it is when "out of the box" defaults, mixed with ignorance on the part of a sys admin or a user, can result in anyone within the organization finding what should be restricted to a few top officials. It's even funnier when the mistake occurs not on the corporate intranet, but on the company's public website.
  • Security through (barely) obscurity. This one always gets a chuckle out of me, when I see someone attempt to hide "top secret" information through such crafty ruses as HTML comments to hide the text, turning off the right mouse button via JavaScript, "burying" important information with a piece of Flash, and other easily found out methods. It's especially funny when you find it unintentionally, like if you view the source code to a document to see how they got a nice piece of design to work, and find a database password in there. The folks who write their code like this are typically pretty shoddy on their backends as well, you can usually hit them with a SQL injection attack because their super nifty search system is simply doing something like "sSQLStatement = "SELECT * FROM MY_DATABASE WHERE ID_CODE LIKE '%" + request.item("search_query") + "%"" or something along those lines. These same people often have really shoddy exception handling too, and let their database errors get sent to the client.

This is just a very short list of some of the most common/pathetic security flaws I have personally witnessed. All it takes is for someone to be as curious as me, with less boredom-related motivations and more malicious motivations to exploit most of them. About half of these I found while simply looking for the information I needed to do my job, and finding myself in a "forbidden" directory, or seeing something else on the screen that caught my eye.

Many of these are common mistakes on the part of end users that were enabled by poor systems administration. The vast majority of your end users have no idea that creating a directory for their supervisor in the common network area is going to expose that directory by default to everyone who wants to see it. Sys admins need to make clearly labelled "management only" directories, with the appropriate subdirectories for individual teams. Processes need to be clearly defined for systems operators at the low level for things such as department moves, new hires, employee termination, and so forth that ensure that users have only just as much access as they need. Group policies need to be put in place to disable USB ports from being used to hook up keychain drives, disable file transfers outside the corporate network over instant messaging, and so forth.

Some of these are problems with programmers who simply don't know better, or are too lazy to do better. These problems are trickier to find. There needs to be a rigorous code-review process in place, checking code for things like SQL statements without parameterization and whatnot.

For both groups of people, sys admins and programmers, there needs to be a combination of education and discipline in place for slip ups. All it takes is for one "wrong person" to get a hold of a document to bring your company's stock price tumbling, or have the SEC investigating, or any number of other problems. Why risk your company's well-being?

Unfortunately, systems administrators are often self-taught or trained in a haphazard manner. Too many people in IT have a certification with no experience to back it up. Programmers get cranked out of CS programs now with a lot of "this is how we do it today" knowledge, but little understanding of "why we do it like this". All it takes is for one of these people with paper qualifications but no true understanding to have to work with a new technology or a different language to be in the dangerous land of ignorance. And that will sink your business. Beware, and conduct regular inspections to ensure that standards are met.

J.Ja

About

Justin James is the Lead Architect for Conigent.

Editor's Picks