Jump to content

rebus9

Members
  • Posts

    25
  • Joined

  • Last visited

Posts posted by rebus9

  1. Running version 4.2.1.  System has previously passed all PCI scans, until now.  CardPointe scanner is now returning a failing result, with the vulnerability listed as "Insecure configuration of Cookie attributes".  

    The only additional info provided is a link to:  
    https://wiki.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)

    The site is running on IIS 8.5 with only port 443 bound, so everything should be over TLS 1.2.  Port 80 binding was removed.

    Any idea how cookies are being passed insecurely?  Is there some communication via another method other than 443/TLS 1.2?  

    Most importantly, what are suggestions on how to close this hole so the PCI scans pass?

  2. On 12/3/2018 at 5:25 PM, Tyson said:

    Hi @rebus9,

    Blesta does not perform cross-domain AJAX requests without specifying the dataType option, so I don't see how the vulnerability mentioned (i.e. https://snyk.io/vuln/npm:jquery:20150627) could be exploited as it is described. Blesta, actually, does not perform any cross-domain AJAX requests at all except for one in the admin interface in order to load the "Follow @blesta" button in the Feed Reader plugin. Unless you have installed some other third-party extensions with Blesta that do perform cross-domain AJAX requests, I don't think you have anything to worry about regarding that jQuery XSS vulnerability.

    Thanks Tyson.  That extra detail was enough to get an exception from TrustWave.  The exception is not permanent, but hopefully the Blesta software will have an updated jquery version before the it comes up for review/re-evaluation.
     

  3. On 11/28/2018 at 6:03 PM, Paul said:

    I was hoping @Tyson or @Jono would respond. Normally the response I provided for you to give them would be sufficient. As far as I can tell, Blesta does not call the vulnerable function in jQuery, so it's implemented securely and cannot be exploited. The version seems irrelevant to this fact, especially since they know the version because they scanned it. Maybe the guys can provide a more technically worded response that will tickle the keywords they are looking for in their review, but I see no reason they shouldn't give you a pass on this for now. Nothing to see here.

    Can you ping them internally, since they are not responding here?  The PCI compliance vendor (TrustWave) says what's been provided in this thread is insufficient explanation, and we're getting financially penalized for PCI non-compliance.
     

  4. On 11/27/2018 at 2:15 PM, rebus9 said:

    Here's the response from Trustwave:  "In order for us to properly process this dispute, we require the full jQuery version currently running on this system."

    Can you please provide that info, along with any notes that would be helpful to give to them to process the dispute?  I already sent them the CORE-2779 link, but they want more.

    Paul, are you still here?  This single issue failing PCI is causing us to be charged a PCI-non-compliance penalty fee by our merchant account provider.

  5. On 11/26/2018 at 11:24 AM, Paul said:

    CORE-2779 has been created for this, but the vulnerability described does not impact Blesta as implemented. There are a number of issues that must be resolved for compatibility with the latest jQuery and we're working on it. (Simply updating jQuery will break the software) For now I would suggest contesting the item with something along the lines of:

    The software is implemented securely, and in such a way that it is unaffected by this jQuery vulnerability. We are waiting on a software update from our vendor an will update as soon as it's available.

    Here's the response from Trustwave:  "In order for us to properly process this dispute, we require the full jQuery version currently running on this system."

    Can you please provide that info, along with any notes that would be helpful to give to them to process the dispute?  I already sent them the CORE-2779 link, but they want more.

     

  6. On 11/22/2018 at 7:32 PM, activa said:

    Is a jquery components, shipped with blesta but maintained by third party. Blesta use jquery series 2, it should upgraded to series 3 .

    If that is true, they will HAVE to update it-- and FAST.  We are failing our mandatory PCI scans, and the jquery version detected is the sole reason for the failing grade.  We passed on all other points.

    PCI scan failure means we are out of compliance, and will be charged a monthly non-compliance fee... not to mention the additional legal exposure for failing to meet standards.

     

  7. Blesta 4.2.1 installed.  Until now, monthly PCI scans all passed.  Today, I woke up to a notification the overnight PCI scan failed:
     

    Quote

    jQuery Cross-Domain Asynchronous JavaScript and Extensible
    Markup Language Request Cross-site Scripting Vulnerability:
    CVE:  CVE-2015-9251
    NVD:  CVE-2015-9251
    Reference:
    https://github.com/jquery/issues/2432
    https://snyk.io/vuln/npm:jquery:20150627

    Unfortunately, Blesta doesn't run as a self-contained app (we're on Windows Server 2012 R2), and requires various 3rd party components, such as ioncube loader.

    Is the fail related to a component that ships inside Blesta, or one of the external components?   

    If it helps, the full text on the PCI report is:

    Quote

    jQuery is vulnerable to Cross-site Scripting (XSS) attacks when a cross-domain
    Asynchronous JavaScript and Extensible Markup Language
    (AJAX) Request is performed without the dataType option, causing
    text/javascript responses to be executed.

    This finding indicates that either the root domain url, sub-domain url, or
    an imported/sourced version of jQuery is below jQuery version 3.0. All
    three scenarios allow an attacker to execute cross site scripting attacks
    on the root domain.

    This finding is based on version information which may not have been
    updated by previously installed patches (e.g., Red Hat "back ports").

    All Cross-Site Scripting vulnerabilities are considered non-compliant by PCI.

    Evidence:
    Match: '2.0.3' is less than '3.0.0'

    Remediation:
    Upgrade jQuery to version 3.0.0 or higher. This includes versions of
    jQuery used on the root domain, subdomain, or imported/sourced
    libraries.

     

  8. This is exactly what I've been waiting for.  To inhibit an emailed invoice, we have to set delivery to Paper (per your instructions in another thread).  But, also per your instructions, that means we have to periodically delete messages in the queue waiting to be printed.  A "none" option would solve all of this.

     

     

  9. Maybe in a future build, then.  It's common for multi-service clients to have several open invoices at any given time of month.  If they owe $1250 across 4 invoices, and a $310 check comes in, we (currently) include this format in the receipt email:

    Payment Received:  $310  
    Balance Remaining:  $940

    That was based on feedback from many years ago, where customers would often ask us how much they still owed.  When we added the Balance Remaining field, feedback was overwhelmingly positive.  I hate to lose that functionality when we cut over to Blesta next week.

     

  10. Found some docs, but didn't see a reference to available variables for email.  What's the variable to show the remaining account balance (total balance of all monies still due)?  When we send out payment receipts in our current system, we include both the payment amount, and any remaining balance due on the account overall.  

    The total due and past-due amounts are shown on the client login page, so I'm assuming the total due has to be a variable available for email.

    A pointer to the list of available variables would be appreciated, too.  (so I can feed for myself going forward)

  11. Some customers on auto-pay do not want invoices emailed, and for them I un-checked the "Invoice Delivery - Email" option when the recurring invoice was created.  (see screenshot)

    Problem-- the invoices are still being sent via email overnight.

    Any ideas why, and what can be done to fix it?  Disabling the invoice delivery email template is not an option, because some customers DO want invoices via email.

    emailedinvoice.jpg

  12. 11 hours ago, evolvewh said:

    I don't remember for sure but you may have to 'enable login' for them to receive these notices but hopefully someone else can clarify that.

     

    For your 2nd need, you can go to 'my info' in the upper right corner when each admin is logged in and check the boxes under the 'Notices' tabs for the ones you want to receive.

    Thanks for the tip.  The key to BCC to our accounts team was Staff Groups.  Unfortunately, if there are multiple contacts, we get BCC'd on every copy sent out-- not just once.  If 3 people at the customer's side get a copy of the invoice, our team gets 3 CC's... one for each email sent to each contact.  We can live with that, I suppose-- but it would be nice in a future build if this was addressed.  Our current system puts the primary contact as the TO recipient, the secondary contact as a CC, and us as a BCC-- all on the same message.  (hint, hint, Blesta team)

    But this still leaves an unsolved problem.  Assume 3 contacts:

    • Owner/Account Holder:   owner@company.com
    • Billing person #1:  billing1@company.com  (additional contact)
    • Billing person #2:  billing2@company.com  (additional contact)

    Both billing persons have been set up with login permissions and all items/permissions are checked/enabled.

    On the main account screen, the "Address Invoices To" option is set to Billing Person #1.  

    When a new invoice comes out, both billing persons (#1, and #2) get a copy of the invoice.  (good) 
    The owner does not get a copy of the invoice.  (bad)

    But when a payment is made, ONLY the owner gets a copy of the receipt. 
    Neither billing person gets notified the payment was received.  (bad)

    Any ideas?

     

  13. 18 hours ago, evolvewh said:

    I thought it was...... but when I added additional contacts to the account (contact type = billing) those contacts still do not receive payment receipt emails.  Only the primary email address in the account-info section gets a copy.

    But the opposite is true of new invoices.  When I created a new invoice, the secondary "billing" contact got the invoice but not the account owner.

    1st need:  I need all contacts-- primary account owner plus any additional "billing" contacts, to all get a copy of any emails sent related to billing (invoices, receipts, late notices, etc.)

    2nd need:  I also want our in-house accounts team to get a copy of all emails auto-generated by the system (receipts, invoices, etc.).  VERY IMPORTANT.  Our current system does this (it was a one-click global option) and we use it for sanity checking and verification.  We don't want any emails from the system going to clients without a BCC going to our accounts team, so we know exactly what our customers are receiving.  (We've caught errors this way.)

    .... other than that, this seems to be a pretty nice product.

  14. Our legacy billing system supports 2 email addresses per account, which is extremely useful.  Many of our high-line clients have more than 1 person responsible for accounts payable-- or in some cases, the owner wants CC'd on all billing related correspondence sent to their A/P department.

    Put in perspective, more than half of our clients have 2 billing email addresses tied to their account.

    Is there a way to associate more than 1 email address per account?

  15. 7 minutes ago, Paul said:

    If the only issue at this point is writing the config and finishing the install I'll do a quick install and send you the config + database dump, and we'll see if you can login ok. Doing an install now and I'll email or PM you soon. I'm not as concerned if there's just some kind of permissions issue here.

    Ok, and just to be sure, this is running under IIS 8.5 on Server 2012 R2.  Not linux.

     

  16. Just now, Paul said:

    The installer uses blesta-new.php as a template and writes blesta.php into the ~/config/ directory. The /config/ directory must also be writable, not just blesta-new.php, so that blesta.php can be created.

    Depending which user your web server runs as, you could probably install Blesta as Administrator via CLI: php index.php install

    If you have higher privileges, it may not encounter this issue.

    I'm doing all this while logged on to the server console as the Administrator.  I also did the CLI option-- see my last post.

    The entire /config  and  /cache directories (not just individual files) all have Write/Modify control for the AppPool user, IUSR, and even the Everyone group.

    This has to be something simple.... because the CLI is hanging on the same error  (see my last post above).

  17. Another update. 

    Started again, fresh.... but this time I used the command line instead of web.

    Errored out at the same step:  

    Attempting to write config... Ensure that the file (C:\Blesta\public_html\config\blesta-new.php) is writable.
    Press any key to retry.

    I triple-checked that the config directory has write/modify permissions for the Everyone group, the AppPool user, and IUSR.  

    Can you think of any reason the installer shouldn't be able to write to that file?

  18. 14 minutes ago, Paul said:

    Yes, take all of that out and set it to blank: sql-mode=""

    Then give it another try. If it still doesn't work, I'm not sure and I'd be happy to do an install and send you a working database you can try to import. The only other thing is that there could be an issue during RSA key generation.. check that you have bcmath and gmp extensions in your PHP.

    Ok, sql-mode="" has been set.

    I deleted all Blesta files and the Blesta database and started fresh with new files, plus the 7.1 hotfix.

    Both the IIS DefaultAppPool user and the "Everyone" group are set to Full Control (while this problem is being worked on) on both the Config and Cache directories.

    Created a new database, then Launched the Blesta installer again.

    Got the following message (see screenshot).  

    So I'm not immediately understanding why the installer seems to be unable to write to it.

    There is nothing new at all written to the PHP error log.

     

    screenshot.jpg

  19. 2 minutes ago, Paul said:

    While Blesta should disable STRICT_TRANS_TABLES, try disabling it in your MySQL config my.ini on Windows

    sql_mode=""

    Restart MySQL, and then check again as you did previously: mysql -u blesta -p -e "SELECT @@GLOBAL.sql_mode, @@SESSION.sql_mode;"

    Do you see any other errors in the logs at the time the white screen of death is presented?

    No other entries in the PHP error log since the white screen of death.

    Here's what is in the my.ini file right now:

    # Set the SQL mode to strict
    sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

    Should I turn the entire thing to an emptry strink like this:   sql-mode=""

    or just take out STRICT_TRANS_TABLES and leave the rest in there: sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTUTION" ?
     

  20. 6 minutes ago, Paul said:

    Does this file exist? C:\Blesta\public_html\config\services.php

    You don't need mailparse unless Blesta will be importing emails into tickets. Outgoing emails will work fine without it.

    Yes,  config\services.php exists.  Here's the contents:
     

    <?php
    
    return [
        'Blesta\\Core\\ServiceProviders\\Logger',
        'Blesta\\Core\\ServiceProviders\\MinphpBridge',
        'Blesta\\Core\\ServiceProviders\\Pagination',
        'Blesta\\Core\\ServiceProviders\\Pricing'
    ];


    OK about mailparse.  I'll get rid of the DLL since we won't be using the ticket system.
     

  21. 24 minutes ago, Paul said:

    Most likely there is a MySQL error running the database migrations. Check that only_full_group_by is not enabled. I know you aren't running MySQL 5.7, but if this is enabled in 5.5 it would still be an issue.

    From https://docs.blesta.com/display/user/Requirements

    If you have php error logs, those may be helpful also.

     

    C:\Program Files\MySQL\MySQL Server 5.5\bin>mysql -u blesta -p -e "SELECT @@GLOBAL.sql_mode, @@SESSION.sql_mode;"

    +----------------------------------------------------------------+----------------------------------------------------------------+
    | @@GLOBAL.sql_mode                                              | @@SESSION.sql_mode                                             |
    +----------------------------------------------------------------+----------------------------------------------------------------+
    | STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION | STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
    +----------------------------------------------------------------+----------------------------------------------------------------+


    And in the PHP error logs:

    A LOT of these:
    -------------------------------
    PHP Warning:  A non-numeric value encountered in C:\Blesta\public_html\iC_Loader_Install_1518794082\php_script.php on line 459
    
    
    Followed by:
    -------------------------------
    Use of undefined constant LOADER_PHP_VERSION_URL - assumed 'LOADER_PHP_VERSION_URL' in C:\Blesta\public_html\iC_Loader_Install_1518794082\php_script.php on line 223
    
    PHP Notice:  Undefined variable: is_too_recent_php in C:\Blesta\public_html\iC_Loader_Install_1518794082\php_script.php on line 256
    PHP Notice:  Undefined index: oscode in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3567
    PHP Notice:  Undefined index: arch in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3568
    PHP Notice:  Undefined index: wordsize in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3569
    PHP Notice:  Undefined index: php_version in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3570
    PHP Notice:  Undefined index: thread_safe in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3571
    PHP Notice:  Undefined index: compiler in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3572
    PHP Notice:  Undefined index: oscode in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3567
    PHP Notice:  Undefined index: arch in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3568
    PHP Notice:  Undefined index: wordsize in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3569
    PHP Notice:  Undefined index: php_version in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3570
    PHP Notice:  Undefined index: thread_safe in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3571
    PHP Notice:  Undefined index: compiler in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3572
    PHP Warning:  require(C:\Blesta\public_html\config\services.php): failed to open stream: No such file or directory in C:\Blesta\public_html\lib\init.php on line 10
    PHP Warning:  require(C:\Blesta\public_html\config\services.php): failed to open stream: No such file or directory in C:\Blesta\public_html\lib\init.php on line 10
    PHP Fatal error:  require(): Failed opening required 'C:\Blesta\public_html\config\services.php' (include_path='.;C:\php\pear') in C:\Blesta\public_html\lib\init.php on line 10
    PHP Warning:  require(C:\Blesta\public_html\config\services.php): failed to open stream: No such file or directory in C:\Blesta\public_html\lib\init.php on line 10
    PHP Warning:  require(C:\Blesta\public_html\config\services.php): failed to open stream: No such file or directory in C:\Blesta\public_html\lib\init.php on line 10
    PHP Fatal error:  require(): Failed opening required 'C:\Blesta\public_html\config\services.php' (include_path='.;C:\php\pear') in C:\Blesta\public_html\lib\init.php on line 10
    


    I believe the warning about Pear is related to me adding the DLL for mailparse... but since I don't want Blesta to RECEIVE emails (only SEND them to customers) can I leave out mailparse?

    NOTE:   Using PHP  Thread-Safe  was recommended AGAINST in WIndows.... (noticed threadsafe mentioned in the error log above)... and is DISABLED in my install.

     

  22. 4 minutes ago, timnboys said:

    did you apply the patch for php 7.1 in the install files? as the white screen is likely ioncube stating to you php 5.6 encoded files doesn't work on php 7.1.

    as I run my dev instance off IIS on 2012R2 so I know the tricks of how you have to configure IIS to make it work with blesta.

    Yes-- I absolutely copied the files from "hotfix-php71" into the Blesta install BEFORE kicking off the configuration.

  23. Unable to get Blesta to config.  Running through the web installer for the app, all I get is a blank white screen after entering in the info requested and clicking the Start Install button.

    Environment is Windows Server 2012 R2
        PHP 7.1 
        MySQL 5.5

    IonCube Loader for 7.1 (Windows VC14 Non-TS 64 bit from here: https://www.ioncube.com/loaders.php )
        Modified php.ini for the DLL per instructions (zend_extension = "C:\Program Files\PHP\v7.1\ext\\ioncube_loader_win_7.1.dll") is at top of .ini.

    phpinfo() shows:
        API Extensions:  mysqli.pdo_mysql
        PDO drivers:  mysql, sqlite
        cUURL Support:  enabled
        cURL Information:  7.54.1
        OpenSSL Support:  enabled
        OpenSSL Library Version:  OpenSSL/1.0.2k 
      
    Used PHPmyAdmin to create a Blesta database in MySQL and created a user with full permissions on it.

    Everything seems to meet the minimum requirements.  

    Deleted all Blesta files and replaced with a fresh copy from the ZIP downloaded from Blesta for eval.  Same results.

    Some DATABASE tables appear to have been created, from "accounts_ach" thru "log_account_access" (alphabetical order)... so at least SOME of the install routines fired off.

    Advice, next steps?

×
×
  • Create New...