6 ms·

No backups since June 24, 2012?!

quink 14y ago
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 :|
- jyap 14y ago
  No, not really. 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 http://wiki.debian.org/DebianWiki/SecurityIncident2012
  - tonfa 14y ago
    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.
- bhaak 14y ago
  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.
  - nwh 14y ago
    Have a look at some of the websites you visit daily. A lot won't be using any type of protection. Most forums don't, for example.
    - mhurron 14y ago
      Which is one of the reasons why you shouldn't be using the same credentials everywhere. More to the topic, I wonder if they're looking for more volunteers now.
    - KMag 14y ago
      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
      - nwh 14y ago

quink 14y ago

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 :|

jyap 14y ago
No, not really. 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 http://wiki.debian.org/DebianWiki/SecurityIncident2012
- tonfa 14y ago
  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.
bhaak 14y ago
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.
- nwh 14y ago
  Have a look at some of the websites you visit daily. A lot won't be using any type of protection. Most forums don't, for example.
  - mhurron 14y ago
    Which is one of the reasons why you shouldn't be using the same credentials everywhere. More to the topic, I wonder if they're looking for more volunteers now.
  - KMag 14y ago
    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
    - nwh 14y ago