Why is the ACP So insecure if you have my password?

[RevengeFNF]

Im not talking about "what if". You are responsible for your site security. If you protect your acp, even in a shared host, its almost impossible for someone to hack your acp. 

[OctoDev]

Just now, RevengeFNF said:

Im not talking about "what if". You are responsible for your site security. If you protect your acp, even in a shared host, its almost impossible for someone to hack your acp. 

When you give a theme developer like Ehren for example template access. Only that, you don't expect him to also have full control of your *entire* website database?  Well he does technically, since he can shell your server.

Even it's in admin panel, it's considered as a vulnerability when I can do anything with it.

All permission rules in ACP; made pointles when giving someone template access.

[sudo]

4 minutes ago, Jimmy Gavekort said:

When you give a theme developer like Ehren for example template access. Only that, you don't expect him to also have full control of your *entire* website database?  Well he does technically, since he can shell your server.

In all honesty not even IPB will be getting access to our production site but we are lucky enough to be able to duplicate the whole setup and provide them with access to that to fault find in the vast amount of scenarios.

[OctoDev]

3 minutes ago, ZeroHour said:

In all honesty not even IPB will be getting access to our production site but we are lucky enough to be able to duplicate the whole setup and provide them with access to that to fault find.

Yes yes, it's a example of a situation. 

The situations are endless, i am starting to get really tired of people that have to twist or find "solutions" like do that and do that. On the end of the day, the vulnerability is still here.

Yes, adding a fool-proof login security would do the job ; 2FA; Mail Verification etc.

And just to make it clear; such security features i rather not depend on 3rd party developers to make.

[sudo]

1 minute ago, Jimmy Gavekort said:

Yes yes, it's a example of a situation. 

The situations are endless, i am starting to get really tired of people that have to twist or find "solutions" like do that and do that. On the end of the day, the vulnerability is still here.

Yes, adding a fool-proof login security would do the job ; 2FA; Mail Verification etc.

Well I suggested that along with a *hardened* mode to help mitigate the majority of everything. That way if someone is stupid enough to use their admin password as their email password they still couldnt do anything other that wipe the data using the admin system tools rather than direct db access/uploads.

Extra security hurts nobody.

[OctoDev]

Just now, ZeroHour said:

Well I suggested that along with a *hardened* mode to help mitigate the majority of everything. That way if someone is stupid enough to use their admin password as their email password they still couldnt do anything other that wipe the data using the admin system tools rather than direct db access/uploads.

Extra security hurts nobody.

That's what I am trying to say here. I my self, i ed up once. Not anymore tho, i was lazy. I didn't want to use LastPass; now I do.

But there are thousands of other customers that will not depend on such, and to make their life a little easier.. Add some extra security layers for ACP There are none? 

[RevengeFNF]

I would never give acp access to anyone but Invision themselves. 

What you are telling is something like this: You have a problem with your site because its down, so you come here to ask for help. You pay to someone to fix it, and give them access to your server. They fix the issue, but also they make a dump of your database and create a backdoor for later access. Will you complain to centos team because of this? 

[Mopar1973Man]

Even like myself I use a wonderful program call KeePassX and use typically use extremely long passwords. Typically regenerate new passwords random periods of time. Between disabling certain PHP modules, renaming the ACP, and the .htaccess login it should make it rather tough to enter the ACP. Again on the server level its up to you to secure your server and software. I've been hacked in the past with vB3, vB4, Joomla, PHPbb, etc. It will happen eventually. Like mention above I was smart and keep backups rolling. 

Personally The Xenforo / vBulletin is mute its the same group of people from vBulletin making Xenforo. This why I'd walk away from both vBulletin and Xenforo, same people just different label.

[RevengeFNF]

15 minutes ago, Jimmy Gavekort said:

That's what I am trying to say here. I my self, i ed up once. Not anymore tho, i was lazy. I didn't want to use LastPass; now I do.

But there are thousands of other customers that will not depend on such, and to make their life a little easier.. Add some extra security layers for ACP There are none? 

Another thing, if you disable the php dangerous function that IPS4 expressly tell's you to disable, will it still be possible to shell the site?

[Colonel_mortis]

24 minutes ago, Jimmy Gavekort said:

When you give a theme developer like Ehren for example template access. Only that, you don't expect him to also have full control of your *entire* website database?  Well he does technically, since he can shell your server.

Themes have to support PHP, otherwise they wouldn't be anywhere near as possible, and at this stage, there's no way that they will change that. The only secure solution to that specific problem is therefore to just not give out ACP access to anyone that you don't trust completely. They could make it clearer that giving template access is a very powerful option, but even if it didn't give them PHP access, it would obviously allow them to inject scripts/etc into your site, allowing them to steal login details regardless, so hopefully it doesn't come as a surprise that being able to edit templates is a powerful option.

Just now, RevengeFNF said:

Another thing, if you disable the php dangerous function that IPS4 expressly tell's you to disable, will it still be possible to shell the site?

IPS4 still requires that eval is enabled, so you can still execute arbitrary PHP code, though you are confined to only executing PHP code, and no shell code, which is much better.

[Mopar1973Man]

3 minutes ago, RevengeFNF said:

will it still be possible to shell the site?

Not that I can see... If you disable PHP module "exec, system, popen, proc_open, shell_exec" then that whole problem stops. Unless there is a another method I'm not seeing.

[RevengeFNF]

2 minutes ago, Colonel_mortis said:

IPS4 still requires that eval is enabled, so you can still execute arbitrary PHP code, though you are confined to only executing PHP code, and no shell code, which is much better.

I know, that's why i asked him

[Coment]

Template stuff aside, there's something REALLY concerning about IPB's "check IP address" feature.

OP is from a different country from the user he logged in on his "proof-of-concept" towards madman. Across the North Atlantic Ocean. Yet IP.Forums thinks nothing else of it? Not even a "is this really you" email? What use is that feature then?

[Mopar1973Man]

17 minutes ago, Coment said:

Template stuff aside, there's something REALLY concerning about IPB's "check IP address" feature.

OP is from a different country from the user he logged in on his "proof-of-concept" towards madman. Across the North Atlantic Ocean. Yet IP.Forums thinks nothing else of it? Not even a "is this really you" email? What use is that feature then?

I would say ask one of the "Support Techs" and they will tell you want it's designed to do.

[Lindy]

My goodness... I've done some cleanup of incredibly inappropriate conduct here... play nice, folks.

A few things:

1. It should not be possible to  "shell" a properly configured server. Exec, all derivatives and other holes should be closed by disable functions. Further, open_basedir should prevent one from using other methods from breaking out of the allowed directory. If your server gets "rooted" via a PHP application - you're a terrible system administrator, or your site is managed by one. Period. 

2. Believe me, I for one would love to get rid of the SQL toolbox or significantly limit it. Clients have, in the past, spoken firmly against this. You're welcome to start a new feedback topic specifically about that and if there's enough movement, I think we'd be happy to gut or limit it. 

3. If you really think XenForo, vB, etc. cannot be "hacked" (and I use that term loosely because if you leave the key in your front door, is it really "breaking" and entering?) via the ACP relatively easily - I'm not really sure what to say that would convince you otherwise. 

4. We always tell people: 

• The ACP is your house. Don't let people in your house that you don't trust, even if it's just to use the bathroom. 
• It's a good idea to both obscure (rename) and secure (htaccess, a WAF such as what IPS uses, etc.) access to the ACP. 
• Never use the same password twice. This is really inexcusable in today's day and age with so many great integrated utilities available like LastPass, 1Password, etc. 

5. "Owner" level permissions are coming soon to the ACP - only someone with an owner flag would be able to use tools such as the SQL toolbox (unless, of course, you push to remove it... wink wink.), install plugins and other things we at IPS consider to be high risk areas. 2FA is also on the roadmap.

6. It is true that someone could obtain the database from the ACP with mild determination. The same applies to any similar software - that's why it's important to protect the ACP before you actually even get to the ACP. 

7. We strive to find an appropriate balance between power, flexibility and security. One could strip the ACP of all external points of entry -- this would include SQL toolbox, raw code in templates, plugins (after all, one could write a plugin to completely destroy your community and e-mail the database in a few minutes) etc. It ought to make more sense to secure that power vs strip it. 

 

[Colonel_mortis]

10 hours ago, Coment said:

Template stuff aside, there's something REALLY concerning about IPB's "check IP address" feature.

OP is from a different country from the user he logged in on his "proof-of-concept" towards madman. Across the North Atlantic Ocean. Yet IP.Forums thinks nothing else of it? Not even a "is this really you" email? What use is that feature then?

That setting only works for ACP - for the front, it will invalidate the session, but, assuming you checked "remember me", it will just reauthenticate you with the longer lived login tokens. For ACP, if you change IP address, you do get logged out.

[OctoDev]

8 hours ago, Lindy said:

 

7. We strive to find an appropriate balance between power, flexibility and security. One could strip the ACP of all external points of entry -- this would include SQL toolbox, raw code in templates, plugins (after all, one could write a plugin to completely destroy your community and e-mail the database in a few minutes) etc. It ought to make more sense to secure that power vs strip it. 

 

 

Honestly, a config variable to disable this would be awesome. Also let's remember that there are so many that uses cPanel Hosting/Shared Web Hosting. There are multiply sellers, it's saturated market. Which means there are a lot of insecure hosts as well  

All I want is some more security for the ACP. If it's email verification before logging in, 2 factor auth, a config bool to disable sql toolbox and raw template editing! Whatever would help. At the moment, it's up to your end only (IP Protecting, which for some users seems ineffective due Dynamic IP Address).

If i am sure around 50% at least of IPS Customers uses same password on multiply sites, including their own forum. Yes, it's a security concern. Yes, it's their fault. But there is also stuff that IPS can do to make the situation "less" worse. Which is adding some more verification for ACP; or adding a config to disable raw/sql toolbox.

I hope you will take adding some more security enhancements into the ACP to consideration. Whatever it ends up with, I'll be happy with. I would never say no to some extra security, especially in ACP.

 

I was a victim my self, it's something you don't really think over but you should. The "hacker" cracked my password, and uploaded malicious code via the template editor. Luckily I had all the insecure PHP Functions disabled as I use PHP Suoshin.. However, he was still able to dump the database - Might be obvious, since he had admin account but there are ways to prevent this even ) 

[Ahmad E.]

As Lindy already mentioned, if someone gets as far as to the ACP they can go further (assuming that the server itself is insecure).

Let's assume the SQL Toolbox is disabled and so is the template editor. Well, I'd write a plugin (takes me a few minutes) that uploads a shell. They got in...

What if the dangerous functions are disabled, shell won't work BUT it is possible to dump the database with a "legit" (one that doesn't use dangerous functions) script. It takes more time but it still is possible.

For myself the SQL Toolbox is a very handy tool that I use frequently. Yes I can go into ssh or phpmyadmin or something similar but for quick stuff I prefer to stay in the ACP.

IMO it should be more important to take measures to prevent someone to access the ACP in the first place. Be it 2FA, additional htaccess pass, email notifications etc. which IPS has plans to work on.

[OctoDev]

4 hours ago, Ahmad E. said:

As Lindy already mentioned, if someone gets as far as to the ACP they can go further (assuming that the server itself is insecure).

Let's assume the SQL Toolbox is disabled and so is the template editor. Well, I'd write a plugin (takes me a few minutes) that uploads a shell. They got in...

What if the dangerous functions are disabled, shell won't work BUT it is possible to dump the database with a "legit" (one that doesn't use dangerous functions) script. It takes more time but it still is possible.

For myself the SQL Toolbox is a very handy tool that I use frequently. Yes I can go into ssh or phpmyadmin or something similar but for quick stuff I prefer to stay in the ACP.

IMO it should be more important to take measures to prevent someone to access the ACP in the first place. Be it 2FA, additional htaccess pass, email notifications etc. which IPS has plans to work on.

If the hook uploader allow you to do such then that also need some extra security to prevent backdoors in hooks.. You can make IPS Hooks, that create new malicious PHP files? 

[Colonel_mortis]

Just now, Jimmy Gavekort said:

If the hook uploader allow you to do such then that also need some extra security to prevent backdoors in hooks.. 

The whole point of hooks is that they allow you to add to or modify the code running on the server. That means that they have to be able to override other classes, and they have to be able to access the database. You should never install a plugin (or application for that matter) that you don't trust, just as you shouldn't install random software on your computer.

[Ahmad E.]

1 minute ago, Jimmy Gavekort said:

If the hook uploader allow you to do such then that also need some extra security to prevent backdoors in hooks.. You can make IPS Hooks, that create new malicious PHP files? 

You can make a plugin/app that gives you the ability to upload raw php files. You can do that with any forum software. That can't be prevented unless you disallow app/plugin installation. 

[CalvinK]

If someone is able to crack your forum password, then there is nothing to stop them from cracking the passwords to gain access to your server, database or anything like that.

There is no two step auth to gain access to your server through FTP or PHPMyAdmin. More damage can be inflicted there.

To start removing features simply because some admins are unable to secure their own server or practise basic password handling is utterly ridiculous.

As far as I can recall (without checking through it right now), those areas of your Admin CP can be restricted to everyone but yourself anyway. In any case, you shouldn't be allowing Administrator access to members who you don't trust or who are unable to look after their own computer security. That's just basic forum administration.

[OctoDev]

17 hours ago, Ahmad E. said:

You can make a plugin/app that gives you the ability to upload raw php files. You can do that with any forum software. That can't be prevented unless you disallow app/plugin installation. 

Yeah, i realize that now. Well, then the option would also be a config to disable hooks, apps and raw template/sql access.

[RevengeFNF]

4 minutes ago, Jimmy Gavekort said:

Yeah, i realize that now. Well, then the option would also be a config to disable hooks, apps and raw template/sql access.

A person that cares so much about security to disable hooks, sql access, templates etc etc, will for sure secure their server.

People that don't care about security, use the same password in every place, etc etc, will not disable hooks, sql, templates... They will not care.

So, whats the point?

[Daniel F]

You can already use the NO_WRITES constant which will disable following features:

• installing new theme
• installing apps
• installing hook
• installing editor plugins