Tools & Tricks of the Trade

A Free Tool for Testing Your Firewalls and Routers

I see a LOT of firewall configuration files and router configuration files. It’s the bane of my auditor’s existence to read through a PIX firewall config (up to 500 pages of a text file). After the 35th page of text, you could drive a truck through that firewall while I tried to wake up.

Plus, I can’t just log on to the firewall and look at it, oh no. I’m an auditor, and we aren’t trusted with such things (probably just as well). So, when I find a tool that will look at the configuration text file, analyze it and give me a nice HTML report, I want to throw a party.

Allow me to introduce Nipper. It takes a microsecond to turn out an absolutely superb report (and found things I missed!). AND it doesn’t just do Cisco, it also handles Nortel, Sonicwall, Juniper and Nokia. I’m in love. AND I gave the guy $50.00. I hope he had a party for himself. What an awesome piece of work.

It runs in Linux or Windows, and somebody else built a GUI front end, if command line makes your eyes cross. Grab your config files and see what you might have missed.

Looking for Some Good (and FREE!) IT Policy Templates?

Thanks to an email, I’ve come across a great website to offer you when it’s time to go looking for some good policy templates.

SANS, the be-all end-all of security training, has organized a website that offers us free policy and standards templates, as well as a course, if you need it.

You’ll need to scroll down a bit to get to all the templates. There are also some nifty security awareness posters and some explanations for the difference between policy, standards, and procedures.

I downloaded over two dozen document templates. There’s some really good stuff here for Admins and Auditors.

Scans and Pentests and Audits, Oh My!

Why isn’t a vulnerability scan part of a penetration test? A scan looks for vulnerabilities the way hackers do - but hackers are MUCH better at it. Scans look for what they are programmed to look for - hackers look for holes.

Penetration testing certainly involves scanning, but most professional pentesters don’t waste time with scanners. They’re nice to have if you have a lot of money and only a little time to check your security. But the guy who gets in doesn’t usually have one in his kit. Scanning software tends to be huge (think database on the backend) and cumbersome.

Don’t get me wrong; there are some terrific pieces of software out there that can and should be used on a regular basis. They can catch the misconfigured server and identify the “low hanging fruit” that needs to be cleaned up. They are a part of a security audit, and VERY handy to have. I’d like to have a few in MY toolkit.

Do I use them for pentesting? No.

The first two or three steps in a penetration test have nothing to do with scanning the network for vulnerabilities, and often are far more effective than a scan will ever be. The nice man who lets me in the door does far more for me than a scan….why do a whole bunch of scanning when I can access the server physically? Ten minutes (or less) with your server and it’s MINE.

Of course, because I’m an auditor, and the First Rule is usually: “Don’t break anything,” I settle for leaving my business card on the back of the chassis or a little file in the root directory. But a thumb drive with some fun software can capture the SAM database pretty quickly and erase traces of itself pretty fast.

So don’t let anyone call a scan a pentest - it just means they don’t know their business.

Securing the Security Devices

OK, so you’ve bought the glow-in-the-dark, meets all the compliance requirements and looks really shiny “security solution” from a vendor (one or many).

Or maybe your management has bought it and presented it to you as a fait accompli. (Hope I’m spelling that fancy French right!) And of course either you have to manage it (without training, “that’s too expensive, just watch the consultants put it in”), or it’s been “outsourced.”

Or as an auditor, you’ve been told to use it for all auditing functions, and not worry about doing any follow up or periodic testing because this product is such a “time-saver.”

So, how do you know (my favorite question) it’s working and doing a good job? Not what the fancy report it produces says, not what the consultant says, not what the manual says, not what the boss says. What you can actually see.

I’ve been following a discussion on the Security Focus “pen-test” mailing list about how security software has just as many issues as regular software. I don’t like thinking that the software protecting me and writing to a SQL database is using an unencrypted ODBC connection that can be captured by ARP poisoning.

So, although I am rarely asked to audit or test a firewall, IDS or host IDS, having run and learned on all of them, I have some suggestions for you to try out.

NEXT: How to Audit Your IDS/Firewall/ECM for free.

More on Cell Phone (IN)Security

I’m having very mixed feelings, I must say, on what I’ve been reading about accessing information from cell phones. On the one hand, in my line of work, which occasionally includes forensics, I’m pleased to see new tools come out that make my job that much easier. The Cell Seizure Investigator “stick” from Paraben for under $500 is a great new piece of equipment for pulling all information off of a corporate cell phone.

On the other hand, knowing that there is a quick tool to pull all the data off my phone in five minutes or so doesn’t give me warm feelings inside. Given that there isn’t really a secure delete function that is available, anything that is on my phone could be recovered in the same way we can recover deleted data from a hard drive. When will we have the ability to encrypt the storage on these things?

I have seen some early reports of cell phones that use biometric identification, but none that appear to be here in the USA.

I have run across a free tool for deleting data on your cell phone by recellular.com that offers some software based on model of phone. Not all models are covered, and I haven’t had a chance to test it out. If you do, please let me know your results.

In the meantime, review what is on your cell phone, and keep it to a minimum!

Let’s Get Physical

When I do an audit, or a penetration test, I start by walking around the building, both inside, outside, and sometimes even on the roof. In my travels, I’ll leave my business card where I can gain unauthorized access. How often am I successful? 95% of the time.

I mentally catalog the exterior doors, the signs on them, and I keep an eye on whether people use them a lot. Then I monitor where the smokers go; I’ve often been able to enter a building undetected that way.

From there, I move to the Data Center. How many doors? Do the doors close firmly and immediately behind whoever enters? I’ve gotten in that way, too.

How about door locks? At a business I was at recently, they were still using push-button locks with a four digit code. After the fourth visit to the server room, I had the code in my head. They couldn’t recall when the last time was they had changed the code, either.

Keys? How many keys are there? I’ve never seen a key that couldn’t be duplicated. How about having to deal with when they get lost? One memorable evening, I went around the IT staff’s desks, looking in desk drawers (in pen tests, all “politeness” is off). I found a very nice key ring labeled “Server Room.”

What about contractors or cleaning people? Does someone escort them while they’re in there, or are they left to their own devices? As boring as that is, leaving someone alone with the corporate crown jewels is equivalent to unlocking the barn door. Are the server cages secured? Are there segments to your Data Center, so that the really significant equipment is in a further secured area inside the Data Center?

I recently visited a really nice Data Center, and the Security guys were very proud of their camera system. It was an excellent system, covering all the doors. But what about once someone actually gets in? What are they doing? Where do they go? The company used a lot of subcontractors, and I pitched to the Security guys the idea that they needed cameras for all areas of the Data Center, not just the doors.

They needed to be able to see where someone went down the server rows to do their work. It’s great physical evidence that says it all in a court of law. If someone says they didn’t touch that server, and you have pictures showing them walking down that row and stopping at that rack, well, game over.

We often think about hacking or breaches as something that is completed with some esoteric piece of magical computer code. I think like the bad guys: what’s the easiest way in?

Auditing iSeries

IBM’s system iSeries are some of the most solid server systems around. Formerly (and by some, still called) the AS400, those servers are at the top of the food chain for reliability and stability. DB2, the native database system for iSeries, is as solid as a rock, and powers many of the banking, healthcare and service industries I get to see.

A lot of engineers will tell you that the iSeries is the most secure OS around, due to the object-level security functions. Those object levels are great, but I can tell you that I find that iSeries are incredibly easy to get into, for two reasons:

First, default services are left enabled. FTP, DDM and ODBC ports on the server are open, and unless you have an exit program, no logging of access takes place. So if I have an application ID and password, I can gain access to see what I can get into. Try a port scan and see what the server tells you.

Last year I saw an iSeries at a merchant (details fudged to protect the guilty) that had NETBIOS enabled. Sitting on a Windows 95 computer in their training room, with a guest ID access, I could see every single file on that iSeries. And I had Full Control of those files. Ooops.

And let’s talk about telnet! Many legacy “green-screen” applications that connect to an iSeries are running via telnet, which means that usernames and passwords are passed to the iSeries in clear text.

Second, special authorities are not locked down. What initial program are users accessing (UPINPG)? If the response is NONE, then they can break through to the command line. How about user classes (UPUSCL)? Have you got people that are part of the programmers group (PGMR) or SECOFR, or SYSOPR? Regular users shouldn’t be in these classes either.
UPSPAU indicates what special authorities each user has. By default, a user should only have access to their printer queue jobs (*SPLCTL), not all objects (*ALLOBJ).

Last, but not least,are the users changing their passwords? I found two with UPPWCD last week… Are there users that are using their username as a password? UPPWON will tell you the facts.

FREE Tool - Changing Local Administratior Passwords On Your Domain

I just love VBS.

And I love the folks that share their tools, AND give us a nice interface AND allow us to push a report to a .csv file. So a BIG thank-you should go out to Jeffrey Hicks, who has his own site, anjd a helpful Blog.

He has a nifty free tool for changing the local Administrator password, PWDMan. This tool also reports on the password age. I’ve been looking for a tool like this to give to the admins I “visit” so that I don’t have to hear any more excuses about how hard it is to change that password periodically.

Jeffrey also has a whole page of VBS scripts and yes, Power Shell scripts, something I’m going to learn when I grow up.

I look for tools I can offer to help admins do their jobs, detect problems and provide easy ways to assess their own systems. I teach how to fish, and try to get buy-in so that the watchfulness happens all year long, not just during an audit.

Host vs. Network IDS

I’ve noticed a definite tendency for organizations to move to monitoring network traffic with their Intrusion Detection Systems. It’s a lot easier than trying to update a host IDS service/agent and keeps the increased CPU at the monitor, where it belongs. Also, host agents are limited by what the operating system is willing to log.

Windows, for instance, will give you hundreds of logging messages that actually have no useful information for an IT Admin or Auditor to review. The setup of their Event Log auditing mechanism is still klugy, outdated and difficult to interpret. (Micro$oft, are you listening?). I can’t say I get to wow about UNIX either, and FORGET anything like logging with Novell.

So, why bother? I still think that a host IDS has a place, because there are things it can watch for that you will only see on the server. For instance, if someone is doing brute-force against the administrator account. If someone has made Active Directory changes who should not be in there.

How would you tell if someone added themselves to the Server Operator group? (where I’d go to look around and maybe get my hands on a SAM database). If you’ve got an Event Log monitoring function, you could pick it up that way, but wouldn’t it be nice if the IDS would pick it up? If you just installed a host IDS on certain critical servers? There’s lots of options if you step out of the all-or-nothing approach.

Speaking of which, monitoring development and test servers really does have to be included. As much as we’d like to forget that they’re there, that’s the first place hackers look. As a penetration tester, I can attest to that, as well. Patch ‘em, monitor ‘em, they’re on YOUR network.

Auditing MS SQL - Roles, and Why They Matter

SQL “Server” runs on top of MS Windows, and it has groups inside of it that are not seen on the Windows server or even the Windows Domain. That’s why we have to check and make sure that inappropriate users don’t have complete access to everything inside the database. Not everyone should be looking at those payroll files!

So, to confuse us a little more, instead of calling them groups (like Users, Administrators, Power Users, etc) SQL calls them “roles.” There are roles based on SQL as a whole (the SQL “Server”) and roles based on individual databases. Kind of like Domain Admins vs Local Admins.

SQL Server roles are equal to Domain Admins inside SQL Server. They give rights to many different core functions of SQL, and the sysadmins role has rights to everything inside SQL. By default, sa is here, but you should look very carefully at any other user in this group. DBAs like to give themselves a “backdoor” into the server this way, but that should be removed. Best practices recommend always having the DBA use their Domain ID for insertion into this role. This way you can log and monitor their access, and when they leave the company and their ID is disabled, they won’t be able to access the SQL databases. It also let’s them know that you are watching, and people tend to behave better that way.

I have found that software developers LOVE to put their names in this group, and not their Domain IDs, either. If it’s a production database, they have no business having anything other than SELECT rights anywhere. Kick ‘em out!

Here’s the SQL Server roles default permissions:

Fixed Server Roles
Sysadmin – can perform any activity (and Builtin\Administrators are part of this group by default)
Serveradmin – can set SQL-server config options and shut down SQL Server.
Securityadmin – manage logins and CREATE DATABASE permissions, read error logs and change passwords (within SQL, not Windows)
Setupadmin - manages linked servers and startup procedures
Processadmin – can manage processes running in SQL server
Dbcreator- can create alter and drop databases
Diskadmin - can manage disk files
Bulkadmin - can execute BULK INSERT statements

How do you find out who is in these roles? Use the results of a stored procedure: sp_helpsrvrolemember with the results taken from the Master database.

For individual databases, there are database roles. People in these roles can be all powerful, but only within that individual database, not all of SQL. How do you know how many databases are inside one SQL Server installation? Again, a stored procedure: sp_helpdb

You’d be surprised how DBAs like to create their own little mini databases (on production boxes!) just to “do things.” They may be great “things,” but those databases need to go somewhere else.

In order to see the members of all the database roles, run another stored procedure: sp_helprolemember run from each production database in SQL Server. It’s a little tedious, but you will get the information you need.

I commonly monitor the membership in the db_owner role (equivalent to a local server Administrator). By default, the dbo, or db_owner is the only one in this role. If the DBAs are already sysadmins, they don’t need to be in this role, unless you want to be very granular in your controls (NOT a bad idea). Developers shouldn’t be in this role, or just as bad, the application ID of an application accessing data.

This is where a lot of software development falls off the security bandwagon. If the application ID is db_owner, it means that the ID has access to everything in that database. If I can acquire the application ID’s password, (and some of them don’t have one) I can get into all the data. I wouldn’t use the application, just connect directly via ODBC or even Excel.

It’s easier to write applications using the application ID as db_owner, but unless you are using middleware to vet everyone’s login via the Windows Domain, you take the risk of losing all that confidential data out the back door.

If you can acquire this information on a quarterly basis, you will go a long way towards having an easy audit and a better night’s sleep!