Skip to main content
Topic: Security improvements (Read 3582 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Security improvements

That's not *a lot*, though I just merged a pull request that adds few security related improvements.

Last week MyBB had a problem with a developer account being hacked and the github repo manipulated with a fake notice of an update carrying some javascript. Thanks to this the hacker was likely able to steal "some"[1] database backups from the MyBB forums around the world (as far as I understood).

For this reason I did some quick tests on ElkArte, but the way Elk grabs updates from GitHub should allow us to avoid a similar attach.

Though, there is always space for improvement, so I took inspiration from MyBB and added the database back to the list of logged actions.
But I felt this was not really enough, so I did something more.

First I made so that in order to download the database backup, is necessary to provide the ftp details. This may not be popular, though considering the type of informations included in the database I am convinced that it's a fair measure. I decided to use the ftp details, because any other detail (such as the database password) may be retrieved somehow from the server itself (with the normal tools provided by ElkArte it's not, or at least it should not, but with addons and other applications it may be possible). FTP login details should instead not be stored on the server itself (and if they are... well, you are looking for troubles, so I can't do anything to save you).

Done that, I decided to let the paranoia-mode run wild, so I also added a "send an email to the admins every time a backup is generated". Is it too much? I don't think so, in the end it's just one more email.

But this was leaving open the last "big" door: php files editing in the theme. I could have added the FTP details here as well, but for the moment I decided to limit it to a sending an email to the admins any time a file is edited.
Why not the FTP data?
No really good reasons.
I guess I'll do sooner or later, but probably not at this round.
It's quite difficult to have an idea of the actual impact of the issue
Bugs creator.
Features destroyer.
Template killer.

Re: Security improvements

Reply #1
Uhm, I don't even run ftp on my server.  What ftp details am I supposed to enter?  I send things to my server via scp.

Re: Security improvements

Reply #2
And you use Elk to take backups of your database?
Bugs creator.
Features destroyer.
Template killer.

Re: Security improvements

Reply #3
I usually do it outside elk.  But I do let elk modify php files.

Re: Security improvements

Reply #4
Then you'll just get an email.
Actually, that reminds me I forgot to add the logAction/emailAdmin to the package manager as well. :-\
I knew I missed something...
Bugs creator.
Features destroyer.
Template killer.

Re: Security improvements

Reply #5
Anyway, I guess we can add some "hidden" setting similar to $db_show_debug that added to Settings.php allow to disable the FTP request.
Bugs creator.
Features destroyer.
Template killer.

Re: Security improvements

Reply #6
And you use Elk to take backups of your database?
sorry for the OT, the backups from elkarte are working good? I remember on SMF it was not indicated to take backups from admin panel, specially on big forums
sorry for my bad english

Re: Security improvements

Reply #7
So I just checked an even though ftp is disabled on my server I can download the database.  I'm not sure what problem this is trying to solve.  ftp credentials are obviously stored somewhere on the server, just outside the http accessible tree typically.  But generally the advice I hear is drop ftp for sftp or scp so why move elk to be dependent on ftp?

Re: Security improvements

Reply #8
And you use Elk to take backups of your database?
sorry for the OT, the backups from elkarte are working good? I remember on SMF it was not indicated to take backups from admin panel, specially on big forums
Elk is using the code I wrote for SMF 2.1 (before the code was removed) and it works better than SMF.
The only situation it is likely to provide a broken backup is if the server times out. The code tries to detect any problem with timeouts and even prohibits the download, but it's not always possible.

So I just checked an even though ftp is disabled on my server I can download the database.
Did you use the code I pushed to the patch_1-0-2 branch?
This is neither in 1.0, nor in 1.0.1, it will be in 1.0.2.

I'm not sure what problem this is trying to solve.  ftp credentials are obviously stored somewhere on the server, just outside the http accessible tree typically. 
Let's just imagine the simple one: an admin account is hacked, the hacker can download the database with everything inside.
Not nice.
Or, an admin account is hacked, the hacker uploads a package or edits a theme file with malicious code that allows him to basically do whatever he likes.
Not nice. (And this has already been exploited on sm.org no more than 1 year ago, so it's not theory, but an unpatched vulnerability.)

Asking an additional pair user/password is just a security measure. Mostly like a two factor authentication.

As I said before, I can't rely on anything that is "available" to ElkArte (the database pwd is stored in plain text in Settings.php, at the moment it's not possible to see the content of Settings.php from within Elk admin panel, but it's not reliable): I can't do a real two-factor authentication (i.e. send a token to the member contact) without having to implement it for changing admin profiles as well (otherwise the hacker could just change the email in the profile), and on any kind of "promotion" to admin (otherwise the hacker could just put another member in an admin or admin-like group).
It is doable, but honestly not at this time, maybe for 1.1 (and I seem to remember @TE already proposed it (two-factor auth for certain operations) a while ago for 1.1).

Mailing admins on editing themes (and as soon as I get few minutes installing packages as well) is just ... well, a way to tell them the horses have bolted, not a real solution.

Yes, ftp data are written somewhere on the server, though hopefully not in a place that can be changed with a php script. And if we are lucky enough, not in plain text (usually some kind of hash).

I'm just trying to make it more secure (or less insecure provided that the option of removing any "easy spot" like file editing is not an option). ;)

But generally the advice I hear is drop ftp for sftp or scp so why move elk to be dependent on ftp?
Because it's already there.
In future there is space to use something different. ;)
Bugs creator.
Features destroyer.
Template killer.

Re: Security improvements

Reply #9
It just seems there should be another place to get a second password.  Why not put a hashed one in the settings file?  Or even the int the database.  Then this secondary password is used to protect changing php files or downloading the database.  If they can pull the hashed password out of the database without supplying the password then they can probably pull the whole database anyway.  And then you're not dependent on something outside of Elk that is quite likely disabled on more security conscious servers.