blogs.perl.org

It seems that last night blogs.perl.org was hacked. I first became aware of it when someone pointed me at this story a few hours ago. As you’ll see, the contents of the mt_author table have been made public.

We’re still investigating the extent of the hack. But, as a precaution, we have configured the site so that all dynamic pages return a 404 response. This will, unfortunately, prevent you from logging on to the site.

We will publish more information when we have it.

Apologies for the inconvenience.

Update:

  • As I said, the mt_author table was leaked
  • This contains both your username and password
  • The password is salted and encrypted (with crypt)
  • If you use your blogs.perl.org password elsewhere, we strongly recommend that you change it

Update 2:
Here’s a cut-down version of the published data that includes only the name columns. Hopefully you can use this to work out whether or not you have an account on the system.

26 thoughts on “blogs.perl.org

    1. It was a standard MT4 installation. Which, apparently, just uses Perl’s built-in crypt function. The source code is available on Github if you want more detail.

      It appears that MT5 moved to using SHA-512 (or SHA-1 as a fallback). We never upgraded to MT5 as it didn’t support the “professional” edition that we were using.

  1. I used my password, that I used on blogs.perl.org on another resource.

    This resource was compromised. I tried to change blogs.perl.org password after that, but that feature did not work https://github.com/blogs-perl-org/blogs.perl.org/issues/206

    So in the end that password compromised twice.

    blogs.perl.org had so many bugs, so it’s not surprise that it’s hacked. I think need to use something more reliable and open source (not commercial), so others can contribute to source code without buying a license.

    > We never upgraded to MT5 as it didn’t support the “professional”

    that’s another disadvantage of commercial installation.

  2. Wait, I’m confused. Are you saying that MT was the attack vector to gain access to the server and database? And if so, are we talking about access to the system via weak credentials or a vulnerability in the system itself? MT has always been pretty damn solid in terms of security, especially when you compare it to others. Especially PHP-based others…

    If there’s anything I can do to help, just let me know. I’ve been an MT developer since 2001 and can help to diagnose the issue and/or harden your system and MT.

    1. No. I’m not saying that MT was the attack vector.

      What I can say is that someone managed to upload a PHP file into the MT PHP library directory, and that program was then able to access the MT database and extract the contents of the MT table.

  3. Following up on what vsespb said, all Melody (our ill-fated MT fork, https://github.com/openmelody/melody) lacked was a critical mass of developer muscle. If the perl community wanted to have an excellent Perl-based CMS and some were willing to put in some time, I would be ABSOLUTELY THRILLED to start that project back up. Especially now with Six Apart’s about-face on dual-licensing with closed-source Movable Type 6.

    We could even forward-port all of the bug fixes and features made to Melody (NONE of which, unbelievably, were EVER incorporated into MT 4/5.x by Six Apart who I suspect were trying to kill Melody by making our work of integrating new MT features more difficult) to the last open source version of MT (v5.2.x) and diverge from there.

    If you’re interested in having a CMS you can hack on without making your eyes bleed (OH HAI PHP), drop me a line (see jayallen.org for contact info).

  4. Can we get a list of exposed usernames? I for one can’t remember if I ever created a blogs.perl.org account, but I may have.

    1. We’re getting a lot closer to being able to turn the site back on. We’ve found and closed the hole that the attacker used and we’ve cleaned up all of the damage they did.

      I’m not making any promises, but it’s likely to be back in the next 24 hours. Before we bring it back, we’ll invalidate all of the passwords so you’ll need to do a password reset before logging on.

      1. “We’ve found and closed the hole that the attacker used”

        It would be *very* helpful and interesting if someone does a limtied but sufficiently technical writeup on what exactly happened. “Learn from my mistakes” kind of postmortem.

  5. Are you planning on sending e-mail to the users whose credentials were leaked? I think that most will not check the site regularly.

  6. One more reason to hate PHP. Ironic.

    I’m not sure why there’s not a little more angry here. While one of the 7 deadly sins, anger is useful social feedback. Apparently, I’m the first to cast stones.

    A lot of damage was done to a lot of good people. If due to carelessness, some public pillorying, err, accountability may be in order. Dave, you seem like a nice guy, but I deserve a better explanation. I have never knowingly (more irony) created a login on a PHP driven website. That architecture was never intended (before the cult of PHP anyway) for such rigorous use. So why is there a PHP interpreter with access to the database on your server?

    1. blogs.perl.org is not hosted on a dedicated server. (server as in Apache, which adds nothing to your cost). This sort of carelessness reflects intrinsic poor judgement.

    2. MoveableType is shipping proprietary software with a PHP interpreter Trojan Horse. Anger is still an appropriate response- in this case is remedied by a legal response.

    3. You knew about MT’s PHP interpreter. Still careless, but not so neglectful.

    Perl has a bad reputation for discipline. Until you come clean, you are personally part of the problem.

    I’m also wondering, generally, why anyone would buy CMS on a PHP architecture, Presumably the $$$ value is in the reduced security risk. Separate thread, though.

    ???

    1. Movable Type has included PHP components since at least 2007. I was well aware of its presence on the server (which, by the way, only hosts blogs.perl.org).

      As it happens, although PHP was used for the defacement and extracting the database, it seems likely that the initial incursion was through a security hole in the Perl components of MT. We’ll publish a full report once we’ve finished putting the server back together.

      No-one bought a PHP CMS. At the time that we set the site up Movable Type was open source. Actually, the professional edition that we used wasn’t open source but Six Apart donated a licence to the Perl community.

      I’ve moved most of my blogs to WordPress. One reason for that is that when they find a security hole, they fix it quickly and get a new version out. And the upgrade process is seamless. I’ve lost count of the number of times I’ve trashed a site by upgrading MT.

  7. So why not run blogs.perl.org on WordPress then? I know, it’s ironic to run *the* Perl site on PHP, but at least WP is more usable, mature enough and gets fixed in due time. Although you’d have to upgrade PHP every two weeks then, along with libxml, freetype, gd and whatnot. I know this from personal experience and it’s a PITA on some systems (BSD). PHP is such a disaster, security and otherwise.

Leave a Reply