# Discourse hacked via sophisticated social engineering **URL:** https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905 **Category:** Site feedback **Created:** [5월 19, 2018, 9:24오후 UTC](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905 "2018-05-19T21:24:55Z") **Posts on this page:** 1 **Showing post:** 2
### 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: [5월 19, 2018, 9: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! :tada: 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 :bulb: 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! --- _[View the full topic](https://meta.discourse.org/t/discourse-hacked-via-sophisticated-social-engineering/87905)._