It’s called a proxy hunter. That sounds a little more elegant than “security hole hunter,” which is really what this kind of software does. Among other things, proxy hunters use a word list to probe Web sites, looking for files that are on the server but not linked to a company’s home page.
In December, a hacker pointed a proxy hunter at Comcast Corp.’s Web site and hit pay dirt: a database of potential customers. He also found Web servers he could access using common log-ins and passwords such as user and test.
The 21-year-old hacker didn’t pick Comcast’s site at random. According to a Feb. 8 Computerworld.com news story by reporter Todd Weiss, the hacker knew Comcast had just bought AT&T Broadband. And he figured that Comcast’s Web administrators would be facing a huge amount of work in the wake of the buyout and that they’d probably get sloppy.
He was right. They did get sloppy. There were those servers with easy-to-guess passwords. And that database of customer leads real customer leads, by the way, not the dummy data that should have been used with a Web application that was being tested. And other files that shouldn’t have been sitting on Web servers, without Web links but accessible to anyone who could guess the file names.
At this point, maybe you’re feeling some sympathy for Comcast. Most likely, though, you’re thinking that this couldn’t happen to your systems. Your administrators wouldn’t really do things that dumb, right? Nobody on your staff would actually shortcut your procedures that way would they?
Maybe instead of congratulating yourself on how good you are, you should be asking some pointed questions.
Do you have well-defined procedures for administering your Web servers? And have those procedures been vetted by a security expert to spot any glaring holes? And does everyone on your staff know what those procedures are – and actually follow them?
How often do administrators update and patch your Web server software? Who’s in charge of keeping track of reported security holes and vendor-issued patches? Where’s the database where that information is kept?
How often does an administrator catalogue the complete contents of your Web servers and compare that against what’s supposed to be there? And when was it done last?
When did an administrator last scan the server logs for patterns that might spot hackers at work? Do your administrators use well-known hacking tools, such as proxy hunters, to find vulnerabilities?
And when were the passwords on your servers last changed?
Do your Web developers use your production servers to test their new applications? If so, do those test versions use dummy data or live information? And do the developers delete the applications after each test, or do they leave them up for anyone in the outside world to access?
And – maybe most important – when your administrators’ workload takes a big jump because of a merger or acquisition or major Web initiative, do you beef up the staff to make sure they’re not stretched thin?
Because when they’re stretched too thin well, that’s when a Comcast happens.
As it turns out, there’s a happy ending to the Comcast incident sort of. This particular hacker calls himself a security consultant, so he notified Comcast of the problems. Comcast denied its systems had any vulnerabilities. The hacker then posted some of the information on an Internet security forum. That’s when Comcast finally took notice – and pulled its site down for security improvements.
Comcast was lucky that this hacker was fishing for business not looking for a way to attack its systems or steal its customer data.
Which leads to the most pointed question of all: Will you be so lucky?
Hayes, Computerworld (U.S.) senior news columnist, has covered IT for more than 20 years. Contact him at [email protected].
