I know that we expect our volunteer Open Source Language leaders to be exemplars of best practise and always on the ball, but there is never enough volunteers or enough funds to pay for all the sysadmins you need.
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.
The people who maintain this are volunteers right? If so there shouldn't be too much blame.
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.
This is why write-only backups aren't just a good idea; like gravity, it's the law. I know funding for these things are on a shoestring budget, but there should have been an external service to ensure backups are being made on a regular basis. Or else, you don't know something's wrong until something's really, really wrong.
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)
I will try to recover it with http://recovermywebsite.com (I might get something a bit newer). Anyone who knows who I can contact with the download when I am done?
I might have some data gotten through crawling them with Nuuton. Anyone from their team here? I'm going to check. Though not very positive, because I'm not currently scrapping ever single page completely.
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. :(
I think he's saying that he set up a web crawler to scrape python.org, and he was hoping that in the process it had made copies of those Wiki pages. He's apologizing that, as it turns out, the crawler did not make it to those pages after all.
Exactly. I thought my crawler had covered all of python.org, but it strayed off to stack overflow. Had not noticed due to the sheer amount of data it goes through. On one side, this sucks because I cannot help put the wiki back online. One the other, this led me to discover this bug.
Couldn't someone at Google provide a dump of the wiki. Assuming that they have it in their page cache they might be willing to help, given they seem to be one of the largest organizations using Python.
Right, but some of us thought that meant the Python folks couldn't use it because Google's servers were limiting the rate of GET requests for the cached pages. I.e. the data is inside Google but difficult to get out quickly (without Google's specific help).
Alfred Pennyworth: Well, because he thought it was good sport. Because some men aren't looking for anything logical, like money. They can't be bought, bullied, reasoned, or negotiated with. Some men just want to watch the world burn.
Just as disturbing: "The attack used on the wiki was apparently the same as the one which hit Debian" [on 2012-07-25]
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 :|
And many other people have been affected (probably everyone decent sized site running MoinMoin): MoinMoin itself, Mercurial, also I think FreeDesktop. I wonder if Ubuntu was too.
It gets better and better: "We will also enable HTTPS access to the wiki to further enhance security and avoid having to send clear text passwords over the network in order to log in to the wikis."
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.
It's really a shame there's so little overlap between the security people and the people creating non-security standards.
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
HTTP responses are incredibly difficult to work with. I was under the impression that a login form should return 200, as the HTML page that loaded was indeed returned OK. I can't find any documentation that actually says, and a lot of live websites don't seem to do one or the other consistently.
You are right though, HTTP basic auth should have always returned some sort of salted hash. It was probably only omitted for simplicity.
"We were subsequently approached by the person who ran the rm -r * " ... " It is also obvious that the people who installed the plugin, had different intentions than causing easy to detect damage on the system."
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
Given that this is the same attack of Jan 5, about which we have already seen posts, and has not indicated a bug in anything except MoinMoin and PSF's systems administration staff, I wonder why this is being posted again today, with a headline which could easily be taken to suggest a fresh attack.
When this happens on sites run by tech-savvy folks, it makes me wonder: How frequently is this happening (and going undetected) on sites with less savvy admins?
This reminds me when divmod.org was attacked. The site has been "temporarily" offline for years now. It's really sad because divmod had some quality Python libraries which have never become popular because they have no documentation; the documentation was destroyed when the site was attacked.
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.