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

Tony Sandman tonysandman999 at gmail.com
Mon Jul 1 14:17:18 GMT 2019


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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20190701/0bd59b17/attachment-0001.html>


More information about the vtigercrm-developers mailing list