[Vtigercrm-developers] Can Vtiger 7 be made secure enough?

Błażej Pabiszczak b.pabiszczak at yetiforce.com
Mon Jul 1 13:55:14 GMT 2019 

@socialboostdk 

Together with Partner we worked on the deployment of YetiForce for PZU
(the biggest insurance company in Poland) for more than 12.000 users.
Before the product was selected it had to undergo security audits
performed by Partner and PZU (https://www.pzu.pl/ [2]). Only after these
audits were completed we understood what the expectations of large
companies towards software were. Since then we've been undergoing
monthly security audits performed by one of the best security companies
in Poland. 

Security is a process but the product needs to be changed every day so
that it complies with the highest standards. If your company doesn't
improve the security every day, it won't manage to deliver a secure
product (no matter what product you implement). Each line of code
requires security analysis, it can't be done without internal and
external training as well as striving for perfection. The fact that you
will implement a few guidelines from @nilaykhatri won't cause the
problem to disappear. It will not disappear unless you understand what
the security problem in Vtiger is. 

Only the system producer has a real impact on security and no matter how
hard you try, you won't significantly affect the security of Vtiger
because security begins with the system's architecture. If you want to
learn more about security, I recommend reading the documentation
https://www.owasp.org/images/d/d4/OWASP_Application_Security_Verification_Standard_4.0-en.pdf
[3]. This document is the standard for architecture that Vtiger should
strive for.  

@nilaykhatri 

What you wrote is 1% of what you need to do (however, I do have some
comments to make). For example: 

 	* ".htaccess" is wrong and shouldn't be used, unless you have no
choice. In addition to the fact it slows down the server, developers
constantly forget about it or overwrite it what causes many security
problems.
 	* The administrator doesn't know which files should be accessed
externally and which shouldn't, the application should take care of it!
For example, in our application there is a "public_html" folder
(https://github.com/YetiForceCompany/YetiForceCRM/tree/developer/public_html
[4]) and it's the only one that should be public, otherwise, the system
will generate security message informing about wrong configuration. In
Vtiger, all files are always accessible externally, which is a huge
threat. 
 	* The system does not have any protection against brute force, there
are no mechanisms responsible for secure passwords, it does not enforce
changing the password when the password was generated by the
administrator, there is no built-in 2FA or no integration with
Yubikey....

I won't go into much more detail because I don't have time for this, but
take a look at what the security verification is like in our system
during installation or when it's already installed. The whole panel can
be found here:
https://gitdeveloper.yetiforce.com/index.php?parent=Settings&module=ConfReport&view=Index&block=14&fieldid=65
[5]  

@Prasad 
When I look at your answers I'm not sure if you're a programmer or just
a PR person. Maybe ask a programmer for help? 

I'm telling you that you have 50 outdated libraries in the system and
the majority of them have critical security errors, and you answer that
jQuery is a user side library instead of figuring out how to solve this
issue and how to update the libraries in the new version… What a lack of
competence… Maybe you'll only understand the problem if I launch a DoS
attack that exists in jQuery against a couple hundreds of your clients
in the On-Demand version? 

I don't know if you ignore the security problem because you don't have
the knowledge to understand it, or that's your company's strategy - and
I'm not sure which one is worse… A year ago we tested VTiger 7.1 with
the library list (unfortunately not all of them are there) to see how
huge the library problem is in VTiger. I used snyk.io to present the
problem for a few libraries

 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › cakephp/cakephp at 3.0.1
[Affected versions of cakephp/cakephp are vulnerable to Arbitrary File
Inclusion through View template name manipulation.] 
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › cakephp/cakephp at 3.0.1
[Affected versions of cakephp/cakephp are vulnerable to Denial of
Service (DoS) attacks.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › codeigniter/framework at 3.0.1
[Affected versions of codeigniter/framework are vulnerable to HTTP
Header Injection via the set_status_header() common function.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › codeigniter/framework at 3.0.1
[Affected versions of codeigniter/framework are vulnerable to SQL
Injection in the ODBC driver.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › codeigniter/framework at 3.0.1
[Affected versions of this package are vulnerable to Session Fixation
because session.use_strict_mode in the Session Library was mishandled.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › phpmailer/phpmailer at 5.2.6
[Affected versions of phpmailer/phpmailer are vulnerable to Arbitrary
Code Execution.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › phpmailer/phpmailer at 5.2.6
[Affected versions of this package are vulnerable to Object Injection
attack.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › phpmailer/phpmailer at 5.2.6
[Affected versions of phpmailer/phpmailer are vulnerable to Arbitrary
Code Execution.
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › adodb/adodb-php at 5.20.9
[Affected versions of this package are vulnerable to SQL injection. The
SelectLimit function has a potential SQL exploit through the use of the
nrows and offset parameters which are not forced to integers.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › cakephp/cakephp at 3.0.1
[Affected versions of cakephp/cakephp are vulnerable to Cross-site
Request Forgery (CSRF). The CsrfComponent fails to invalidate requests
that are missing both the CSRF token, and the CSRF post data.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › cakephp/cakephp at 3.0.1
[Affected versions of this package are vulnerable to Deserialization of
Untrusted Data. The SmtpTransport class has the potential to deserialize
untrusted user input provided as part of an SMTP connection. An attacker
could leverage this vulnerability to call arbitrary class methods within
the application.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › codeigniter/framework at 3.0.1
[Affected versions of codeigniter/framework are vulnerable to Cross-site
Scripting (XSS) attack.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › pear/pear at 1.10.4 ›
pear/archive_tar at 1.4.3 [Affected versions of this package are vulnerable
to Remote Code Execution (RCE)]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › phpmailer/phpmailer at 5.2.6
[Affected versions of phpmailer/phpmailer are vulnerable to Multiple
CRLF injection vulnerabilities.]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › phpmailer/phpmailer at 5.2.6
[Affected versions of phpmailer/phpmailer are vulnerable to Cross-site
Scripting (XSS).]
 	* Vtiger_Libraries_Vulnerabilities at 0.0.0 › phpmailer/phpmailer at 5.2.6
[An issue was discovered in PHPMailer before 5.2.22. PHPMailer's msgHTML
method applies transformations to an HTML document to make it usable as
an email message body. One of the transformations is to convert relative
image URLs into attachments using a script-provided base directory. If
no base directory is provided, it resolves to /, meaning that relative
image URLs get treated as absolute local file paths and added as
attachments. To form a remote vulnerability, the msgHTML method must be
called, passed an unfiltered, user-supplied HTML document, and must not
set a base directory.]

This is only the beginning of the problems resulting from outdated
libraries in VTiger, I assume there's much more than that… unfortunately
the problem is that VTiger doesn't use anything to centralize libraries,
eg. composer, yarn, package so nobody really knows how serious this
issue is. Apart from the easy to find problems like the ones I mentioned
above, there are many errors in the code directly. For example:   

 	* Loading various things from the Vtiger server to the login page is a
critical security error. If someone is in an untrusted LAN, anything can
be injected, including JavaScript files that will capture logins and
passwords on the fly. Will taking over the Vtiger server cause the
attacker to have control over ALL Vtiger systems?!
 	* Attachments to e-mails are saved in a publicly accessible folder
(what's the point? Since you don't have any tools to monitor
unauthorized attempts to access this folder, the administrator will
never detect the problem).
 	* After connecting to your store, you disable the verification of the
certificate. 
 	* If you have export permissions in any module, you can export all
users to CSV as a regular user. 
 	* isPermited (main function for permissions verification) provides
access to the tool (e.g. export) if this action isn't available in the
profile.
 	* You can change user's data even without GUI, e.g. you can change the
username or role. All you have to do is to modify the request. 
 	* You can create users with the same parameters as yours (with no
admin permissions). 
 	* You can read all fields from a record (if you have access to record
but some fields are disabled for a user, the system blocks them only on
the GUI level so you can access all record info by modifying a request)
 	* SQL Injection in all modules on the admin side. 
 	* You can display all records in any module and any related module
(this is a serious issue and exists in hundreds of places, it results
from the fact that the system doesn't verify actual permissions in a
number of places). Example:
index.php?module=Contacts&relatedModule=ModComments&view=Detail&record=17&mode=showRelatedList&relationId=165&tab_label=ModComments&app=MARKETING
 (you have to match the parameters/actions depending on the version)
 	* Access any record:
index.php?module=Accounts&view=MergeRecord&records=9 (problem results
from the fact that many functions, eg. MergeRecord don't have a
permission layer and display anything you want)
 	* Access any record, comment, history
index.php?module=Contacts&view=ListViewQuickPreview&record=8

	* Incorrect validation of permissions 

 	* modules\Vtiger\actions\DeleteImage.php (you can delete any document
regardless of your permissions because Vtiger, for the purpose of
security,  checks a parameter that doesn't exist).
 	* modules\Vtiger\actions\ExportData.php (here the problem is that
Vtiger checks permissions to a different module than the one you're
exporting)
 	* modules\Vtiger\actions\MassSave.php (permissions to edit field are
not verified so you can edit any field even if you don't have
permissions to save) 
 	* modules\Vtiger\actions\RelatedRecordsAjax.php (no verification of
permissions to calculate the number of related records, it allows you to
check if a record exists and how many related records there are) 
 	* modules\Vtiger\actions\RelationAjax.php - no verification of
permissions to all actions which allows you to add relations between
records, remove relations, check the number of related records, get the
label of any record
 	* modules\Vtiger\actions\SaveStar.php - No verification of permissions
to mark records
 	* modules\Vtiger\actions\TagCloud.php - No verification of permissions
to use tags, it is possible to add tags to any record, download all tags
and delete tags

	* modules\Vtiger\views\EmailsRelatedModulePopup.php - No verification
of permissions to the Users module, it is possible to display all users.
index.php?module=Users&view=EmailsRelatedModulePopup&name=CalendarActivities&type=all
	* modules\Vtiger\views\ExportExtensionLog.php - No verification of
permissions to download logs from WSAPP
 	* modules\Vtiger\views\ExtensionViews.php - No verification of
permissions to download logs from WSAPP

 	* No permissions when displaying widget content - all data from each
widget can be displayed, e.g. it is possible to display all calendar
events to which you don't have permissions
index.php?module=Home&view=ShowWidget&name=CalendarActivities&type=all 

	* Possibility to execute any file: permissions to the Home and Users
modules aren't verified (?!?) and in the Home module there is include
'modules/' . $_REQUEST['module'] . '/' . $_REQUEST['file'] . '.php' so
everything from the address can be executed, e.g.
URL:
http://test/coreBOS/7.0/index.php?action=HomeAjax&module=Home&file=../VtigerBackup/VtigerBackupRequest
Triggers the file from VtigerBackup module:
modules/Home/../VtigerBackup/VtigerBackupRequest.php  
	* Examples of SQL Injection: 

 	* modules\Campaigns\models\Relation.php updateStatus
 	* modules\Settings\Leads\models\Mapping.php save()
 	* modules\Settings\Picklist\models\Module.php updateSequence()
 	* modules\Vtiger\models\Block.php updateSequenceNumber()
 	* modules\Vtiger\models\Relation.php updateRelationSequenceAndPresence

 	* DoS: try to trigger modules/Mobile/api.test.php a few times and the
server will crash

We know more than 100 errors like those above (I could write a book
about them). Unfortunately, other errors require something more than
simply changing parameters, e.g. in order to display logins of all CRM
users, it is necessary to write a script and trigger it as a non-logged
user and after a few minutes we have all users in the CRM without the
need to log into it.  

This is just the tip of the iceberg, there are hundreds of
XSS/SQLInjection errors in the system and in order to fix them you have
to centralize the validation mechanisms first of all (right now it's a
mess); without first fixing the entire mechanism there is no point in
patching individual reported errors (you fix it in one place, but it
still exists in 20 other places). 

--

Z poważaniem / Kind regards 
Błażej Pabiszczak 
CEO & Co-Founder at YetiForce 
+48 884 999 123 | b.pabiszczak at yetiforce.com 
www.yetiforce.com 

W dniu 2019-06-28 13:22, socialboostdk napisał(a):

> Hi Nilay,
> 
> Thank you very much for this excellent list!  
> 
> Should we (the open source community) try to collect a master-list to maintain somewhere, so we have a ready list of tasks for security improvements + "best practices" within security checks? 
> 
> :) 
> 
> Cheers! 
> 
> On Fri, 28 Jun 2019 at 13:05, nilay khatri <nilay.spartan at gmail.com> wrote: 
> Hi Chris, 
> 
> no it is not secure enough if you use it as it is. 
> 
> As I had sent an email warning everyone about hacks going on related to vtigersupport.com [1] here are few things: 
> 
> 1. if you are using SMS integration, which I guess would be the case for the insurance industry, the passwords are stored in plain text. We need to have a salt-based encryption 
> 
> 2. Database credentials are stored in plain text, so if the file system is compromised the attacker would gain access to the database as well easily. Use some encryption system to encrypt the whole config file or store the database credentials in a separate file outside the document root and include that file in config.inc.php 
> 
> 3. Make sure you apply the change to normalize the web service error for invalud username or password 
> 
> 4. Disable import from zip files if not required 
> 
> 5. Define the .htaccess rules properly such that it allows access to only the files which should have direct access such as index.php, capture.php, .png jpeg etc. files in storage, etc.. Everything rest should be forbidden 
> 
> 6. There is no rule to set a secure password, even if you tel the users to always use a secure password, you can not be sure that users will do that. Quite possible the can set a password just 1 character long :) 
> 
> 7. Review the custom extension thoroughly, such as VGS Document Manager(it is all good unless you set the file permissions properly) 
> 
> 8. Make sure no 2 CRM systems on the same server have same application key. This normally happens if you use a Dump of already installed CRM to setup a new CRM 
> 
> These are a must "security checks" you should consider. 
> 
> To make it more secure you can consider few more things: 
> 
> 1. Keep the CRM behind Cloudflare. There are some issues which occur if you use Cloudflare, such captcha validation while sending an Email. 
> 
> 2. Have 2FA, we are working on this and will soon have an Open Source patch for this 
> 
> Hope this helps. 
> 
> I guess Blazej will have more comments :) 
> . 
> 
> On Fri, Jun 28, 2019 at 1:22 PM socialboostdk <socialboostdk at gmail.com> wrote: 
> Hi there,
> 
> I have a client who needs very high security (think "insurance" category). They're asking if Vtiger 7 open source can actually be made secure enough? Ie. assuming we apply all patches, collect all known bugs/holes etc., and try to fix those. 
> 
> I would like to give them a honest answer. 
> 
> What do you think? 
> 
> Thanks,
> Chris _______________________________________________
> http://www.vtiger.com/ _______________________________________________
> http://www.vtiger.com/

_______________________________________________
http://www.vtiger.com/ 

Links:
------
[1] http://vtigersupport.com
[2] https://www.pzu.pl/
[3]
https://www.owasp.org/images/d/d4/OWASP_Application_Security_Verification_Standard_4.0-en.pdf
[4]
https://github.com/YetiForceCompany/YetiForceCRM/tree/developer/public_html
[5]
https://gitdeveloper.yetiforce.com/index.php?parent=Settings&module=ConfReport&view=Index&block=14&fieldid=65
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20190701/1b77e1f8/attachment-0001.html>

More information about the vtigercrm-developers mailing list