Python.org Wiki has been Attacked
wiki.python.org
wiki.python.org
But my first reaction here is "There, but for the grace of God, go I"
Embarrassing yes. End of the world, no. Heads to roll ? No, but arse to be kicked yes. Won't happen again will it.
And therein lies the problem of disaster recovery. Even if you have a catastrophic bug, you should not be losing 6 months of data.
It was exactly 31 days later, but still on a reasonable schedule for a monthly backup. Either the backups where disabled or the staff don't trust the backups they do have (though that seems unlikely, given that it would allow them to recover the content offline without having to execute any of the backing code)
There isn't enough information. I would have thought sometime between June and January someone would have looked to see if back ups were being made and if the size of the back ups were consistent with the amount of data stored on the website even if they weren't properly checking that back ups were valid.
I would expect from this someone has now been assigned to checking that regular back ups are stored and are correct. I have been a part of a few communities were back ups were supposedly being taken but no one was given the responsibility for ensuring they were correct or even actually being made. Once or twice a moderator rampage has lead to a lot of lost data. I would expect this is one of the key lessons they have learned from this.
Bad news update:
I had not covered the wiki yet. The crawler seems to have ventured off to SO (the crawler runs 24/7 by itself). I'm so sorry. :(
The exploit was out there and had been used to hit debian.org in a big way, and had been fixed. But python.org didn't update MoinMoin or check whether their MoinMoin installation hadn't been compromised until their data got deleted about half a year after the original exploit :|
Debian Timeline
2012-07-25: Debian's MoinMoin was exploited (due to what is eventually called CVE-2012-6081).
2012-10-18: First use of the backdoor.
2012-10-28: Theft of email addresses, password hashes and reCAPTCHA key.
2012-11-09: Last use of the backdoor.
2012-12-28: We are informed about a potential security issue in MoinMoin by the friendly people at dyne.org.
From: http://wiki.debian.org/DebianWiki/SecurityIncident2012
Wait, what? They did send the login passwords as clear text up until now? So even if the logs weren't deleted there is a probability that the original attacker would have used a stolen account.
More to the topic, I wonder if they're looking for more volunteers now.
Security is all in the defaults. It's a crying shame that whomever came up with type=password for HTML input tags didn't make it require an attribute holding the id of another field holding the salt, and have form submission submit something like base64(md5_hmac(password, hostname + ' ' + salt)) (md5 was considered good at the time) as the field's form value. All of the tutorials would have people using the username as the salt, which isn't good. However, we'd be in a much much better place than we are now if the easiest way to bumble your way through creating a login meant taking a salted hash of the password directly from the submitted form. We'd still have tons of data that could be stolen to authenticate to the same site, but at least the salted hashes would need to be cracked in order to use the stolen credentials to authenticate to any other host. Also, people would need to go out of their way to store plaintext passwords in databases.
Better yet, when it became clear that people were using forms for auth data because the browser's HTTP 401 response dialogs were ugly, they would have created a new HTML header tag to allow the page to specify the HTML element IDs of the username and password fields, so that a web browser could send an HTML login screen as the body of an HTTP 401 response.
Of course, HTTP basic auth should never have been allowed.
As it stands, we're in the crazy place where UI designers are forced to make security decisions that really should be shoved way down the stack and made transparent to them.
Edit: clarified the name used for 401 response dialogs
You are right though, HTTP basic auth should have always returned some sort of salted hash. It was probably only omitted for simplicity.
Seems like a case of a script kiddie who got the login information from someone else...probably doesn't know his way around Linux too well and thought it would be funny to run a few commands, then got scared once he realized what he'd done and fessed up
Who rebooted the VM? If it was the attackers, this implies that they had root. But the post only states that they could execute code as the moin user.
</sarcasm>