vt71 - Outgoing Email Server Security

Outgoing Email Server stores email server_password in plain format in vtiger_systems - server_password

This should be encrypted to protect data.

Added enhancement security labels

Title changed from vt71 - Outgoing Server Security to vt71 - Outgoing Email Server Security

Since there are some security improvments in the past days, this deserve a fix.

@manuelgit - Since the password has to be exchanged with the SMTP server encryption is not an option here. Also this data is protected for administrators only. Best way is to lock SMTP to allow connection from CRM Server by IP.

Lets wait to hear more.

@prasad i consider a big security issue since if for some reason, access to database was violated, someone can see password for that email and access directly to that email server. Even worse, create a spy email account on their local computer.

@manuelgit - If they have access to database ...would they have access to the code too?

@prasad through ModuleImport yes, but that's not the point. In my point of view, a password is always a password and nowadays we are getting used to think password's are always encrypted. It would be just a step forward in security.

@manuelgit - You are stating viewer has access to DB but not code here and want to avoid exposure of data in this case. Is that right?

@prasad no, sorry for the misunderstanding. Once user have access to database can see Outgoing Email Server Password and that specific email account it's compromised since then.

Not many but after a quick research, found that some other systems stores the password this way:

@manuelgit - Thank you for the clarification. The screenshot shows base64 encoding, will need to get a better one. Will keep you posted here.

Status changed to closed by commit 696ed946

@manuelgit - Please review the commit. With these changes - if you edit the outgoing-server and change should mask the credentials.

@prasad this needs to looked into with high priority.

Recently one of our client was hacked. This was a series of hacks:

1. How intruder got login details: when we use webservices and try the login operation, webservice returns relative messages. That is "user does not exist", "password is wrong". This helped the intruder to guess an existing user.

2. After a user name was confirmed, they did brute force on passwords and gained access to a non-admin user. (mistake was to use easy password assuming no harm could be done using non-admin account)

3. Then another exploit was executed to gain admin privileges. (this was fixed in the recent hotfix release, but the patch was not applied)

4. Once they had the admin privileges, intruder uploaded a new version of WSAPP module with malicious code (lightweight File Manager and Adminer for Database).

They also uploaded another extension from VGS "VGS Document manager" that comes with a file explorer, using which one could modify any file ont he server if permissions are not set very restrictively.

4. Then the uploaded File Manager was executed from browser to read database credentials from config.inc.php.

5. Once they had the database credentials, they executed Adminer script and were able to access database.

6. As they had access to database, they were able to access the Email password (stored in base64 format), SMS server details as even that is stored in plain text, FTP server password (using the Vtexpert Backup extension), get access key of all the users (again stored in plain text), password of all email accounts used in Mail Manager, password of all email accounts used in Mail Converter.

7. Using the above details, they were able to download all the backups.

8. Intruder sent emails and SMS to all customers with threatening message.

9. Then they deleted the Login history.

10. After this they used webservices to get the latest data from the CRM over a long period without being identified.

Everything is good until the intruder does not have access to the system. But as soon as a slightest of access is achieved the system becomes too much vulnerable.

@nilay.automatesmb - 3rd-party services credentials cannot be stored in encrypted form as it need to be decoded to establish connection with runtime decode. I filed an enhancement request #1311

Its unfortunate that weak-passwords were used! I could not co-relate the issue you mentioned to this specific ticket. Letting someone gain access to db through backdoor endpoints is as good as handing over the key. Please be double sure when installing 3rd-party extensions.

Update: webservice login failure message normalized now (refer 406512fa)

@prasad

1. mail converter and scanner passwords are stored in encrypted manner, then why not outgoing email server. But even then since the attacker had gained access to files, they were able to decrypt the mail converter and scanner passwords.
2. there is no fool proof mechanism without close sourcing the algorithm used to encrypt/decrypt the passwords.
3. an approach is to use a salt based encryption and to keep the salt outside the public folder. This makes it mandatory to have file access to decrypt the passwords. (This will prevent leakage from hacked FTP backups, only database access and similar scenarios )
4. .htaccess files should be put in place with restrictive permissions. I can not find any blog or article online which provides basic set of .htaccess files for Vtiger.

are we considering key based encryption for 7.2 release?

@nilay.automatesmb - no.