Over the years I've been fortunate to work with very knowledgable consultants, and blessed to be in consulting roles that have given me the knowledge and ability to help organizations with gaping security issues they never even knew they had. Often organizations are very concerned about the attacks from the outside world and set their security up accordingly, neglecting due diligence that should be applied from an inside perspective as well. In other situations, quick fixes or new hardware and networking can lead to security holes even to the outside world. The following are glaring security issues I've actually discovered myself in large companies and organizations.
1. Web Consoles for Infrastructure. Companies often upgrade their hardware or networking systems. Many of these systems come with web consoles that allow you to configure the new system over the web. Ignoring these consoles is NOT the right thing to do. While working as a consultant in one large organization, I was doing netstats to help with tracking down good servers and ports to monitor with Nagios. During this exercise I discovered a server that retained open connections to most of the servers I was interested in tracking. So I thought I'd go see what this box was. It turned out that the box was a management console for one of the organizations two UPS (Universal Power Source) boxes. The login page I was directed to gave me a default username. I tried the first password that came to my mind and 'presto' I was in! This management console give me the ability to shut down entire loads of servers with one click of a button. Entire environments (including production) were configured in loads. Besides these load configurations, none of the configuration had been changed from when the box was originally installed.I was shocked. Other consoles that might be lurking with default, easy to crack passwords and easy to change configurations could include VMWare management consoles, firewall consoles, router consoles, and the list goes on. Anybody that said running and managing infrastructure is an easy job is fooling themselves.
2a. Open Shared Drives. One thing that baffles me - I've seen it in two large organizations now and neither of them (to my knowledge) has done anything about it, is having wide open shared drives. I've seen this on both Linux operating systems and Windows operating systems. Users are allowed to access drives and folders (entire files systems) on other users' computers. This potentially opens companies up to litigation, particularly in the area of privacy. I could be wrong on this point, but still, it seems wrong that I can see most everything on anybody's computer (doesn't matter which drive) in the enterprise.
2b. Open Shared Folders. Using shared folders to do deployments into production is a real no-no. I'd even be uncomfortable with using a shared drive to view logs on a production server. Shared drives on any production box leaves the opportunity for someone to put one file in the wrong spot (in a shared drive folder), and you've got a major security/audit issue. If you absolutely have to have them, make sure they are very closely monitored to ensure that only information you want disseminated from there is put in that shared folder. Configuration files, *.udl files, and logs are all examples of files that you want to be very careful of the content. Someone could find the shared folder, simply search it for *.udl or look for text like 'password' and wowza! you've got a big problem.
3. IPSec Rules. Firewall rules, and any other networking rules can be lumped into this one. Sometimes these rule sets can get compilicated. Sometimes they just get forgotten about when your setting up a new box or network. It takes time to test and ensure that all your rules work properly and are in place. I helped with a new installation of a set of servers and a network that managed sensitive information for an international set of users. Some time after this installation was complete and running in production I thought I try to log into the production box from home, just for kicks. Imagine my surprise when I got in just as easily as I logged in from work. The IP Sec rules weren't set up correctly and as a result, they weren't blocking ip's. Yikes. We had our network guy get that fixed right away.
4. Get rid of old users. Part of due diligence in an enterprise organization is ensuring that users who aren't with the company any more are no longer users in the system. I've seen companies keep old users around for over a year - beyond that I don't know as I had left as well.But keeping those old usernames and passwords hanging around is just asking for trouble. Keep your user lists updated.
5. Lax Network Rules. Typically in a software development shop there will be a number of environments where compiled code gets successively deployed as testing gets more rigorous. Most shops I've been in have had 3 or 4, named something along these lines: Dev, Test, Staging, and Production. While it can be convenient to have an open network between these environments (for example, boxes in the dev environment can ping and telnet to boxes in all the other environments) it's a big security risk. Why? While you may have all your boxes in production locked down with passwords that only a select few members on your release team know, the open network allows opportunities for mistakes and inside attacks to occur.
Case in point: Within 2 weeks of starting at a Windows dev shop, I discovered that administrators in the Dev environment had mapped a view to the production COM+ console parallel to their Dev COM+ console so they could conveniently compare what was running. Unfortunately, this allowed any users on the Dev box to view, edit, stop, and even delete COM+ applications on the production server. I alerted the authorities immediately about this. To my surprise, six months down the road I discover that the mapping is still there! Sigh. This time I've alerted authorities somewhat higher up the totem pole - we'll see what happens.
Case in point 2: On the day before a release into production, one of our DBA's was doing some 'extra' checking and discovered that a stored procedure that was happily running and tested in the staging environment was actually hard-coded to point to the development database. All our testing for this piece of functionality in staging was effectively useless - even though it passed! If the network didn't allow that kind of communication, we would have caught the problem lickety split. As things turned out, that part of the release turned into a bit circus because the developer responsible for that stored proc wasn't available and we didn't know if we should run it and risk data corruption in production or wait and get cuffed by the business the next day.
6. Poke Around. As I mentioned earlier, if you manage to get into positions in an enterprise where you are entrusted with the ability to navigate your way around a fair bit of the infrastructure, it doesn't hurt to be curious. You'll likely learn something and likely help the organization in the process. I helped one enterprise discover they were getting only half of the CPU power they were paying for on some of their production boxes.
7. Passwords in cleartext. It's way too easy to seach a shared folder for text like 'password'. It's amazing what you'll find. Everywhere possible, try to encrypt your passwords or look for ways not to have them in files that are readable in cleartext. Notorious files for exposing this kind of information have the following extensions: *.udl, *.xml, *.config, *.conf,*.ini, *.properties.
8. Backdoors I had a situation where I was working with a piece of technology that I was quite comfortable with and discovered that there was a root password hardcoded in the default configuration. I changed it on all my implementations of this software that I managed. If other people implement this same piece of software and aren't aware of this root password configuration, it creates an open backdoor for knowledgable people to enter.
I hope you enjoyed this little overview. More to come in the future. If you have questions or comments, please send them to me @ email@example.com.