[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>
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/20190701/6553238b/attachment-0001.html>
More information about the vtigercrm-developers
mailing list