# Discourse 遭高级社会工程学攻击被黑 **URL:** \ **Category:** Site feedback\ **Created:** [2018年五月19日 21:24 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905 "2018-05-19T21:24:55Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\ **Post date:** [2018年五月19日 21:24 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905/1 "2018-05-19T21:24:55Z")
@pfaffman brought this story to our attention, and I’m glad he did, because it is fascinating: > **[ownCloud forum hack: Why password security is more important than ever -...](https://owncloud.com/blogs/owncloud-forum-hack-why-password-security-is-more-important-than-ever/)** > > A hack on the social media platform LinkedIn happened in 2012 made the unauthorized access to user data of the ownCloud forum possible. Weak and old passwords are still a major threat to online services. I’ll break down the specifics, and how we mitigate each one, in a reply. ---
**Author:** ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\ **Post date:** [2018年五月19日 21:42 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905/2 "2018-05-19T21:42:47Z")
At its heart, this is a password reuse problem. > In 2012, hackers were able to gain [unauthorized access to LinkedIn’s database](https://en.wikipedia.org/wiki/2012_LinkedIn_hack) and downloaded password hashes (SHA-1) from 6.5 million user accounts, (the password hashes became public in 2016). > > Using a rainbow table, an attacker was able to guess login credentials of a user who **used the same credentials for his GitHub account**. Being able to login to the GitHub account, the attacker used the OAuth login to gain access to the forum account. Still, it is worth thinking through all the steps here to consider what could have been done at each stage, and what Discourse / Forum Admins / Users can do to mitigate an attack like this: 1. LinkedIn is breached and used crappy password hashes, which are easy to reverse (turn the hash back into a password string) 2. User has same email/password on LinkedIn as GitHub 3. Hacker takes email/pass credentials from LinkedIn and uses them on GitHub where they also work 4. The Discourse forum has multiple login methods configured, user/pass as well as GitHub social logins. Since social logins are equivalent to user/pass.. bam the hacker is now in as an admin on Discourse. 5. The hacker is logged in as an admin (this is very bad) and now needs to download the Discourse database. Except.. **an admin login alone is not sufficient; Discourse requires email access to get the emailed download token for the Discourse database**. So yay! 🎉 protected, right? Bear in mind _this is a very sophisticated, in-depth attack_, and it could have been stopped many levels above with practices that are already strongly recommended, just read through the lightbulb callouts 💡 above. Still, we believe strongly in being _safe by default_ at Discourse, and we think there is more we can do after closely analyzing this story. As a result, we [just implemented a change](https://github.com/discourse/discourse/commit/9f422c93f67f156c3216a57cdf1afc0c5fc94e28) such that _nobody_, not even an admin, can modify that particular email template. We believe it is a rare case, but worth addressing, because: - this particular email template is _only_ ever sent to staff on email change, as both the _old_ and new email addresses must be confirmed. For a regular user only the _new_ email address needs to be confirmed. So changing this template for cosmetic design reasons would only be seen by staff, never by regular users, and is thus unimportant. - the risk of allowing admins to change this template is too high, as illustrated by the above REAL WORLD story which actually happened, and was the critical step that allowed the attacker access to the complete Discourse database. Also, before commenting on this story, a few other things you should know: - Enabling 2FA (two factor auth) in Discourse logins automatically disables all social logins. - It is definitely possible to have 2FA login enabled through Google, Github, and other social logins, but I’m not aware of any way Discourse could enforce that, or know about it. - We don’t _yet_ have the ability to print paper backup codes for Discourse 2FA but that is slated for 2.1. - it’s worth thinking about what one logged-in admin can do to another admin’s account. Email changes through the web UI, for example, have to be verified on both new and old email addresses no matter who initiates the email change, so that is safe. Demoting a user from admin to regular user is a potential workaround – but granting admin to another account requires email confirmation via the current admin email address. Gotcha! ---
**Author:** ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\ **Post date:** [2018年五月19日 21:56 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905/3 "2018-05-19T21:56:42Z")
~~It also occurs to me that we might be incorrectly including “secrets” in email send logs like email confirmation change URLs – @techapj let’s make a strong note to take a look at this for 2.1 as well.~~ Aha – as @jomaxro helped me understand, this is indeed all caused by the single modified “confirm old email address” template, which the attacker edited from > please confirm your old email address {link} before we change it to > backup failed! please click this {link} to troubleshoot .. and then triggered an email change on multiple admin accounts hoping at least one admin would fall for it. And one did. The attacker never knew the confirmation URL which is what I was concerned about. So another potential mitigation here is > 💡 Forum admins: strongly limit the number of admin accounts you have. ---
**Author:** ![itsbhanusharma](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/itsbhanusharma/32/180717_2.png) [@itsbhanusharma](https://meta.discourse.org/u/itsbhanusharma)\ **Post date:** [2018年五月20日 02:48 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905/9 "2018-05-20T02:48:12Z")
Can social logins be disabled for staff or at least admins? E.g. staff & admins can only be allowed to log in via discourse’s username \> password \> 2FA validation where there is a limit of minimum number of characters in password that is global. I’ve read your articles about passwords and think that 10+ characters for staff should be a good choice. Also, one more thing can be is that if there had been any changes to an admin account, those accounts should be put into a cooldown period. This can be tricky but if anyone has made any changes to an admin account e.g. email change or modification of 2FA that admin account should not be permitted access to admin area for the next 24 hours or so … Just so that if anyone has gained access maliciously then there is some grace period before damage is made to the whole community. ---
**Author:** ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\ **Post date:** [2018年五月20日 03:03 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905/10 "2018-05-20T03:03:57Z")
> [@itsbhanusharma](#): > > I’ve read your articles about passwords and think that 10+ characters for staff should be a good choice. Staff password minimum has been 15 chars for quite some time now. ---
**Author:** ![jomaxro](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jomaxro/32/126216_2.png) [@jomaxro](https://meta.discourse.org/u/jomaxro)\ **Post date:** [2018年五月20日 03:30 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905/11 "2018-05-20T03:30:53Z")
> [@itsbhanusharma](#): > > Can social logins be disabled for staff or at least admins? > [@codinghorror](#): > > Enabling 2FA (two factor auth) in Discourse logins automatically disables all social logins. Ensure your admins enable 2FA, that’s your solution right now. One future possibility to enforce this would be a new site setting to require 2FA for all admins. ---
**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\ **Post date:** [2018年五月21日 00:23 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905/12 "2018-05-21T00:23:23Z")
> [@jomaxro](#): > > One future possibility to enforce this would be a new site setting to require 2FA for all admins. This is actually my preference here. But it is a bit of a tricky setting to get right, especially when you enable it. - Enable 2fa on all admin accounts Quite a lot of work is involved in making this work properly. ---
**Author:** ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\ **Post date:** [2018年五月21日 01:24 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905/13 "2018-05-21T01:24:53Z")
No such “forcibly log out all admins, then force them to enable 2fa” exists at all on GitHub (for example) that I know of, so we’d be in uncharted territory here. ---
**Author:** ![Azareal](https://avatars.discourse-cdn.com/v4/letter/a/13edae/32.png) [@Azareal](https://meta.discourse.org/u/Azareal)\ **Post date:** [2018年五月21日 01:43 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905/14 "2018-05-21T01:43:29Z")
Doesn’t Github have a thing to make 2FA mandatory on organizations? ---
**Author:** ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)\ **Post date:** [2018年五月21日 01:43 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905/15 "2018-05-21T01:43:50Z")
Yeah but that only affects new signups, it does not kick everyone out and force them to do it. Plus in order to enable 2FA you need to be logged in _somehow_.