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

nilay khatri nilay.spartan at gmail.com
Mon Jul 1 16:17:41 GMT 2019

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>

> 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/20190701/6553238b/attachment-0001.html>

More information about the vtigercrm-developers mailing list