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

nilay khatri nilay.spartan at gmail.com
Thu Jul 4 08:29:58 GMT 2019

@Prasad <prasad at vtiger.com> do we have any plans for these security

It would be helpful for the community to know if any actions have been
planned by Vtiger team for mentioned security issues.

On Mon, Jul 1, 2019 at 9:47 PM nilay khatri <nilay.spartan at gmail.com> wrote:

> Thanks, Blazej!
> I hope the community developers like us would contribute to the Open
> Source to make it more secure.
> On Mon, Jul 1, 2019 at 7:55 PM Tony Sandman <tonysandman999 at gmail.com>
> wrote:
>> Gonna read tomorrow. Cannot wait! hehe
>> T
>> On Mon, Jul 1, 2019 at 8:57 PM Błażej Pabiszczak <
>> b.pabiszczak at yetiforce.com> wrote:
>>> @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/). 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.
>>> 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)
>>>    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
>>> @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
>>>    1. 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.]
>>>    2. 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.]
>>>    3. 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.]
>>>    4. 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.]
>>>    5. 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.]
>>>    6. Vtiger_Libraries_Vulnerabilities at 0.0.0 › phpmailer/phpmailer at 5.2.6
>>>    [Affected versions of phpmailer/phpmailer are vulnerable to Arbitrary Code
>>>    Execution.]
>>>    7. Vtiger_Libraries_Vulnerabilities at 0.0.0 › phpmailer/phpmailer at 5.2.6
>>>    [Affected versions of this package are vulnerable to Object Injection
>>>    attack.]
>>>    8. Vtiger_Libraries_Vulnerabilities at 0.0.0 › phpmailer/phpmailer at 5.2.6
>>>    [Affected versions of phpmailer/phpmailer are vulnerable to Arbitrary Code
>>>    Execution.
>>>    9. 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.]
>>>    10. 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.]
>>>    11. 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.]
>>>    12. 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.]
>>>    13. 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)]
>>>    14. 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.]
>>>    15. 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).]
>>>    16. 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:
>>>    1. 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?!
>>>    2. 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).
>>>    3. After connecting to your store, you disable the verification of
>>>    the certificate.
>>>    4. If you have export permissions in any module, you can export all
>>>    users to CSV as a regular user.
>>>    5. isPermited (main function for permissions verification) provides
>>>    access to the tool (e.g. export) if this action isn’t available in the
>>>    profile.
>>>    6. 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.
>>>    7. You can create users with the same parameters as yours (with no
>>>    admin permissions).
>>>    8. 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)
>>>    9. SQL Injection in all modules on the admin side.
>>>    10. 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)
>>>    11. 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)
>>>    12. Access any record, comment, history
>>>    index.php?module=Contacts&view=ListViewQuickPreview&record=8
>>>    13. 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
>>>    14. 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
>>>    15. 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
>>>    16. Examples of SQL Injection:
>>>       1. modules\Campaigns\models\Relation.php updateStatus
>>>       2. modules\Settings\Leads\models\Mapping.php save()
>>>       3. modules\Settings\Picklist\models\Module.php updateSequence()
>>>       4. modules\Vtiger\models\Block.php updateSequenceNumber()
>>>       5. modules\Vtiger\models\Relation.php
>>>       updateRelationSequenceAndPresence
>>>    17. 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 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/
>>> _______________________________________________
>>> http://www.vtiger.com/
>> _______________________________________________
>> http://www.vtiger.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20190704/0420f8ff/attachment-0001.html>

More information about the vtigercrm-developers mailing list