[Vtigercrm-developers] Can Vtiger 7 be made secure enough?
Prasad
prasad at vtiger.com
Thu Jul 4 11:31:13 GMT 2019
Nilay,
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.
Regards,
Prasad
--
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