Shostack + Friends Blog Archive


Owning Up to Pwnage (Part 2)

On Saturday, I discussed how “I bolluxed our blog theme.”

“More to the point, we here at the New School talk a good game about how we need to talk about problems, rather than cover them up. So here’s our money where our mouths are. I, Adam Shostack, screwed up the blog presentation by not testing the upgrade before rolling it into production.

See! That wasn’t so bad. It didn’t cost that much to talk about what went wrong. Of course, it’s small stakes, but doing these things when the stakes are small develops the habits of talking about them and makes it easier to talk about them when the stakes are (or feel) higher.”

So let me talk about another issue. A few years ago, the server at got turned into a botnet controller, and I want to talk about what happened.

The short story is easy: we failed to keep awstats up to date, and a known vuln was used to take over the account.

I could discuss some of the usability challenges associated with staying up to date, but don’t want to get into a Windows/UNIX debate here. (Just the facts: compare versions here and here, or look at this and consider how you’d decide on up-to-dateness.)

I think it was discovered by random sysadmin work, but we’re not entirely sure. Tripwire (or some variant) was running, but not covering the directory where the bot code was dropped.

More important though, is that we didn’t actually stay up to date on a service that was exposed to the entire net.

I take a couple of lessons. First, keeping everything up to date is hard. Second, we exposed awstats to everyone. We’ve since corrected that, adding a password to get to the page (and code).

The meta-lesson is that it’s easier to keep quiet than to own up to this stuff, but I’m willing to offer up a start.

Once again, if you think that talking about security incidents is a good thing, or could move us forward, I urge you to start small and disclose more as you can. It’s easier than you might think.

3 comments on "Owning Up to Pwnage (Part 2)"

  • LonerVamp says:

    To be honest, I think this is one of, if not the best, blog posts of the year. Important points and very succinctly made with real world example that any security or even admin person has seen (absolutely, has, seen).

    Updating is hard, protect exposed stuff, don’t be quiet, random sheer chance detection, staying abreast of new vulns…

  • MrEthiopian says:

    Windows / UNIX Environments count for nothing if not configured and maintained correctly, Tripwire is a great tool but again if not configured and maintained correctly can be problematic outputting a plethora of erroneous data. The game is never over, your sysadmin /CISSP needs not only traditional training but also slant to the devious side, in that he/she needs to think outside the box and think like a blackhat. What tools can I use to capture data when my edge router is being probed, are applications inside DMZ open to XSS attack, how do I pre – mitigate a DDOS attack . Security has evolved far beyond what it was only a year ago and we need to grow with it, the problem is that large cooperation’s and government don’t think or run well in this model, some of the problem is an old mindset others are regulations, 21 CFR11 FDA will not allow patching of all machines without a plethora of documentation and that documentation can take months to complete. The true problem is that most IT management forget the past and get a lackadaisical altitude for the basics, this happens easily when business drives IT and forecasts 30 projects for the year, yet you only have resources for 20 something has got to give and again its usually the basic mitigation that needs constant attention.
    Security has changed, have you?


  • Crozee says:

    In the military we have lessons learned, hopefully so Soldiers do not end up at Arlington instead of their loved ones. This sharing of information will help others to avoid your pitfalls. The IT world is rife with SA not wanting to disclose vulnerabilities due to litigation or other reasons. On the military side we shared so we can live and come back home. This post has been the most refreshing in quite some time. For all the sysadmin out their can you really in a clear conscience let others make the same mistake? Speaking as a retired solder I would never give bad advice to a soldier (SA) and I would not retain information that would keep a soldier or system operational.

Comments are closed.