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

Prasad prasad at vtiger.com
Thu Jul 4 11:31:13 GMT 2019


Step 1: The cited incidences will be verified against the latest-trunk.
Step 2: Best practises will be taken as enhancements subsequently.

If there any responsible-disclosures - please reach out to us.

I would love to get assistance from good programmers around here.
MRs welcome.


FB <http://www.facebook.com/vtiger> I Twit <http://twitter.com/vtigercrm> I
LIn <https://www.linkedin.com/company/1270573?trk=tyah> I Blog
<https://blogs.vtiger.com> I Website <https://www.vtiger.com/>

On Thu, Jul 4, 2019 at 2:00 PM nilay khatri <nilay.spartan at gmail.com> wrote:

> @Prasad <prasad at vtiger.com> do we have any plans for these security
> concerns?
> 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/cae910bb/attachment-0001.html>

More information about the vtigercrm-developers mailing list