Last week, I was horrified to discover a problem with my vulnerability scanner. The product I use relies on a user account to connect to our Microsoft Windows servers and workstations to check them for vulnerable versions of software, and that user account had never been configured properly. As a result, the scanner has been blind to a lot of vulnerabilities. And this has been going on for a long time.
I hate to think how much longer I might have remained blind to this problem if I hadn’t set out this week to search for a particular set of vulnerabilities inherent in Apple’s Safari browser. You see, Apple ended support for its Safari browser on Microsoft Windows a while ago, but I know that some of my users have installed it on their own, and I wanted to find out how many. It worries me because vulnerabilities in Safari for Windows will accumulate indefinitely. That’s the last thing I need. In fact, I plan to get rid of Safari entirely, but first I wanted to get some information about how much of a risk it really is.
So I unleashed the vulnerability scanner on the problem. I’ve been using it for a couple of years now, and it’s been helpful in our patching efforts. Once I weed out false positives and prioritize the reported vulnerabilities based on what our various computers are used for (for example, Internet-facing Windows servers have a higher priority than computers on our internal network), I get good, actionable data from the system. I run reports every week and provide them to IT system administrators so they know what security updates to apply. This helps us track the effectiveness of our patching efforts. And patching, thankfully, has been going well lately.
I expected to see a dozen or so computers with Safari on the list. So I was quite surprised when none turned up, especially since I personally know about three Windows computers on my network that run Safari.
I had a bad feeling about Safari’s complete absence from the report. I checked again; still no Safari. I scanned the report for the computers I know have Safari installed, and there they were. Some vulnerabilities were listed, but none for Safari. I double-checked to make sure the computers were actually still running Safari, and they were. So what was going on?
Then I looked at the vulnerability scanner itself. Was something not working right? I checked the configuration to see if it was missing any computers or vulnerabilities, but everything looked OK. I looked at the latest scan times, and all the scans seemed to be running fine, right on schedule. Was it getting regular, automatic updates in its vulnerability database from the manufacturer? Yes. I didn’t see any application errors or other problems in the system logs.
When I looked at the logs associated with the actual scans, I found a problem. There were some permission errors when the scanner logged into our computers with the user account we set up for it. The logins were successful, but some of the scans came back with “permission denied” errors.
You see, the user account used by any kind of automated tool like my vulnerability scanner needs to have proper permissions to access the files and locations where it needs to look. In the Windows world, that generally means Administrator rights, or at least some kind of elevated privilege beyond basic, normal user access. And as it turned out, basic access was all that account had on our network.
What this means is that my scanner has never been able to give me a full list of vulnerabilities. And I didn’t know that, because I have been getting plenty of good data from it — just not all the data, as I found out when the problem was resolved by giving the scanner’s user account full privileges and ran a new scan. Suddenly, my total number of vulnerabilities tripled!
This came as quite a shock, both to me and the IT administrators who now have an unexpectedly huge list of vulnerabilities to work on. And yes, I found the Safari installations I was looking for. There were exactly 12, just as I had expected.
But this situation leads me to wonder how many of our security tools are configured effectively, and how we can validate their configurations. It’s good that this problem has been solved, but this experience has left me with a gnawing unease. Where are my blind spots, and how can I find them?
This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.
Click here for more security articles.