(2014-11-18, 10:08 AM)Pirata Nervo Wrote: [ -> ]No problem. We're also thinking that we should add ACP PIN confirmation (in case a PIN is set in config.php) for the following actions:
- Delete Users
- Delete Groups
- Delete Forums
- Backup Database
This way, even if someone takes advantage of an XSS vulnerability in the ACP, they'd need to know the ACP PIN in order to cause any real damage or take database dumps.
I agree! PIN should be required, now it is only optional. And you idea for pin confirmation is excellent, I hope it will be in 1.8.3
What about this?
-------------------------
Perhaps MyBB could implement CSP headers throughout the ACP to prevent external scripts/assets being loaded by default. Sure, something like this is unlikely to happen again but it would remove the possibility of it or anything similar being able to happen.
Code:
Content-Security-Policy: script-src 'self' $cdnurl; connect-src 'none' frame-src 'self', object-src 'none';
--------------
I guess it's something we could take a look at so I'm not really sure how they work so I'd need to look into it first.
(2014-11-18, 10:08 AM)Pirata Nervo Wrote: [ -> ]We're also thinking that we should add ACP PIN confirmation (in case a PIN is set in config.php) for the following actions:
- Delete Users
- Delete Groups
- Delete Forums
- Backup Database
This way, even if someone takes advantage of an XSS vulnerability in the ACP, they'd need to know the ACP PIN in order to cause any real damage or take database dumps.
There are many ways around to cause damage or obtain sensitive information (creating a new user and granting him admin access wouldn't require your PIN, as wouldn't getting the current backups list to get direct links to
.zip files). Moreover, it would be a burden to perform standard administrative tasks.
The main cause of these attacks, which is lack of data filtering will be fixed and if the two additional but non-obtrusive, related security measures that have been proposed will be implemented (
httpOnly & CSP) there's no need to require every administrator to type in his passwords everywhere.
(2014-11-18, 01:15 PM)Devilshakerz Wrote: [ -> ] (2014-11-18, 10:08 AM)Pirata Nervo Wrote: [ -> ]We're also thinking that we should add ACP PIN confirmation (in case a PIN is set in config.php) for the following actions:
- Delete Users
- Delete Groups
- Delete Forums
- Backup Database
This way, even if someone takes advantage of an XSS vulnerability in the ACP, they'd need to know the ACP PIN in order to cause any real damage or take database dumps.
There are many ways around to cause damage or obtain sensitive information (creating a new user and granting him admin access wouldn't require your PIN, as wouldn't getting the current backups list to get direct links to .zip files). Moreover, it would be a burden to perform standard administrative tasks.
The main cause of these attacks, which is lack of data filtering will be fixed and if the two additional but non-obtrusive, related security measures that have been proposed will be implemented (httpOnly & CSP) there's no need to require every administrator to type in his passwords everywhere.
Nothing guarantees me there are no other vulnerabilities and therefore I'd like to prevent this from happening again. I'm not suggesting to ask the administrator to enter his password everywhere so I'm not exactly sure where you took that idea from.
My suggestion is pretty simple: if the admin has setup an ACP PIN, it should be requested not only on login (the hacker can create a user as you're suggesting but you forgot that the hacker needs to enter the ACP PIN to login - my suggestion applies to the ACP PIN, not passwords) but also when doing sensible actions like the ones I mentioned. They could destroy data (deleting forums, users, etc) and could retrieve plenty of data (database backups).
Also, regarding the earlier question about the attacking site, it's worth noting hub.org (the site that had the script on) was also attacked and did not realise they were being used to serve that script.
(2014-11-18, 02:37 PM)Pirata Nervo Wrote: [ -> ]the hacker can create a user as you're suggesting but you forgot that the hacker needs to enter the ACP PIN to login - my suggestion applies to the ACP PIN, not passwords
Correct, although if there was a hypothetical XSS vulnerability I could make a browser send a request to modify the forum templates so that they contain a JavaScript that sends me the admin cookie, like the recent malicious payload (PIN is not needed in the templates; CSP would not be implemented on the front end, if it is even considered; I don't require the PIN to use a session that has already been created; ACP cookies are available from the frontend [reported:
http://community.mybb.com/thread-162999.html]).
What I actually mean is, there are lots of ways to do harm using various ACP tools and if the PIN confirmation was meant to form a decent layer of protection it would have to be implemented in many more places...
Quote:Nothing guarantees me there are no other vulnerabilities and therefore I'd like to prevent this from happening again. I'm not suggesting to ask the administrator to enter his password everywhere so I'm not exactly sure where you took that idea from.
...and that would require the administrator to type in his PIN while performing standard tasks.
He has already signed in (and can be signing in using 2FA in future releases) and there is a wide set of mechanisms that can ensure his session will be kept safe.
I also don't like the idea of forcing administrators to use PIN authentication that has been brought up in this thread - I consider this, along with such things as forcing strong passwords in the installation process that I have encountered in other web software, a bad practice. It makes the development workflow harder (who needs advanced security on test forums or local machines) and if an administrator needs to be
forced to use strong passwords, his website is going to be compromised sooner or later.
(2014-11-18, 03:36 PM)Devilshakerz Wrote: [ -> ] (2014-11-18, 02:37 PM)Pirata Nervo Wrote: [ -> ]the hacker can create a user as you're suggesting but you forgot that the hacker needs to enter the ACP PIN to login - my suggestion applies to the ACP PIN, not passwords
Correct, although if there was a hypothetical XSS vulnerability I could make a browser send a request to modify the forum templates so that they contain a JavaScript that sends me the admin cookie, like the recent malicious payload (PIN is not needed in the templates; CSP would not be implemented on the front end, if it is even considered; I don't require the PIN to use a session that has already been created; ACP cookies are available from the frontend [reported: http://community.mybb.com/thread-162999.html]).
What I actually mean is, there are lots of ways to do harm using various ACP tools and if the PIN confirmation was meant to form a decent layer of protection it would have to be implemented in many more places...
Sure, you could get the admin cookie but you couldn't still delete users, delete forums, etc...it's a way to minimize the attack. At least it would buy the administrators time to stop the attack. The idea behind the ACP PIN confirmation is not blocking the unauthorized login permissions (by this I mean the ability to have a fully working login after stealing cookies) but rather minimize the risk of a successful unauthorized login. To prevent you from stealing those cookies, httpOnly should do the job as long as the user uses some modern browser. In case you forget your session open somewhere...on a public computer for example, the ACP PIN will protect the board from being completely destroyed.
(2014-11-18, 03:36 PM)Devilshakerz Wrote: [ -> ]I also don't like the idea of forcing administrators to use PIN authentication that has been brought up in this thread - I consider this, along with such things as forcing strong passwords in the installation process that I have encountered in other web software, a bad practice. It makes the development workflow harder (who needs advanced security on test forums or local machines) and if an administrator needs to be forced to use strong passwords, his website is going to be compromised sooner or later.
I don't like the idea of forcing a PIN and I'm sure we won't do that. The ACP PIN is optional and will remain optional of course. It's our job to provide the means for the user to secure his website but it's not our job to enforce they're used.
(2014-11-18, 09:24 AM)Euan T Wrote: [ -> ]We're not sure what has happened to the data. The third party website informed me via email that they had removed all foreign objects from their servers, but did not specifically list which files they were. It would be best to assume you were compromised and to reset all passwords and login keys.
I presume the third party website you are speaking of here is hub.org?
(2014-11-18, 03:35 PM)Euan T Wrote: [ -> ]Also, regarding the earlier question about the attacking site, it's worth noting hub.org (the site that had the script on) was also attacked and did not realise they were being used to serve that script.
This is what worries me. I must ask again:
So what does this mean in regards to the data that was stolen from my site and others? Has it been transferred from the attacking website to yet a malicious site/person? And is it known which site/person it all originated from? And what they might do with the data? Is is still thought this was just "an act to show power" rather than to actually abuse the data?
We have no answers for you, we only know the website it came from.