Suitecrm: New Install SuiteCRM Version : 7.8.3 - WAF Blocks Login "Blind SQL Injection Attack"

[itmonitor]

Issue

Hi!

I made a fresh install of SuiteCRM using Softaculous on WHM (LAMP). After the clean instal, login will not work. Password retrieve will not work. I checked all the preconditions in the server for SuiteCRM to work, they are ok except ZLIB. On requesting help with my hosting provider, they say the login issue is related to SuiteCRM coding, which is blocked by Comodo WAF. Comodo WAF thinks this is a Blind SQL Injection. This happens also with modsecurity.org. They supplied me with this from error log:

[Sun May 21 11:36:01.619314 2017] [:error] [pid 3640] [client 220.225.193.249] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(?i:\\b(?:t(?:able_name\\b|extpos[^a-zA-Z0-9_]{1,}\\()|(?:a(?:ll_objects|tt(?:rel|typ)id)|column_(?:id|name)|mb_users|object_(?:id|(?:nam|typ)e)|pg_(?:attribute|class)|rownum|s(?:ubstr(?:ing){0,1}|ys(?:c(?:at|o(?:lumn|nstraint)s)|dba|ibm|(?:filegroup|o ..." at ARGS_NAMES:user_password. [line "18"] [id "211540"] [rev "9"] [msg [color=#880000]"COMODO WAF: Blind SQL Injection Attack[/color]||mydomain.com|F|2"] [data "Matched Data: use r_password found within ARGS_NAMES:user_password: user_password"] [severity "CRITICAL"] [tag "CWAF"] [tag "SQLi"] [hostname "mydomain.com"] [uri "/stcr/index.php"] [unique_id "xxx"] Hide full text Request: POST /stcr/index.php Action Description: Access denied with code 403 (phase 2). Justification: Pattern match "(?i:\b(?:t(?:able_name\b|extpos[^a-zA-Z0-9_]{1,}\()|(?:a(?:ll_objects|tt(?:rel|typ)id)|column_(?:id|name)|mb_users|object_(?:id|(?:nam|typ)e)|pg_(?:attribute|class)|rownum|s(?:ubstr(?:ing){0,1}|ys(?:c(?:at|o(?:lumn|nstraint)s)|dba|ibm|(?:filegroup|o ..." at ARGS_NAMES:user_password tailf /usr/local/apache/logs/error_log Please, any advice to solve this SuiteCRM security issue and let me login is welcome. Looking forward to your reply, Rgs IM[file "/var/cpanel/cwaf/rules/24_SQL_SQLi.conf"] [line "18"] [id "211540"] [rev "9"] [msg "COMODO WAF: Blind SQL Injection Attack||mydomain.com|F|2"] [data "Matched Data: use

r_password found within ARGS_NAMES:user_password: user_password"] [severity "CRITICAL"] [tag "CWAF"] [tag "SQLi"] [hostname "mydomain.com"] [uri "/stcr/index.php"] [unique_id "xxx"]
Hide full text
Request:
POST /stcr/index.php
Action Description:
Access denied with code 403 (phase 2).
Justification:
Pattern match "(?i:\b(?:t(?:able_name\b|extpos[^a-zA-Z0-9_]{1,}\()|(?:a(?:ll_objects|tt(?:rel|typ)id)|column_(?:id|name)|mb_users|object_(?:id|(?:nam|typ)e)|pg_(?:attribute|class)|rownum|s(?:ubstr(?:ing){0,1}|ys(?:c(?:at|o(?:lumn|nstraint)s)|dba|ibm|(?:filegroup|o ..." at ARGS_NAMES:user_password
tailf /usr/local/apache/logs/error_log

Expected Behavior

Login should work seamlessly without triggering WAF. Other software work properly with WAF, like Wordpress.

Actual Behavior

Login is Blocked by WAF

Possible Fix

Change the login code to avoid triggering WAF.

Steps to Reproduce

https:aksert.com/stcr

1.
2.
3.
4.

Context

Unable to login and use SuiteCRM.

High: I believe this could be a security issue and also because many SuiteCRM potential users are turned away when they see the login will not work properly. According to user pgr at SuiteCRM forum, this login + WAF issue is happing more frequently recently.

Your Environment

• SuiteCRM Version used: 7.8.3
• Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): Chrome Version 58.0.3029.110 (64-bit)
• Environment name and version (e.g. MySQL, PHP 7): PHP7.0, MariaDB 10.0
• Operating System and version (e.g Ubuntu 16.04): Centos 6.9

[pgorod]

I can only add that this modsec (or modescurity) problem has been appearing frequently in the forums lately - one case per week perhaps, starting about 3 weeks ago. The basic initial complain is "can't login".

People tend to be happy with the solution of simply turning off modsec. But their hosting might not let them - and it might be better to avoid this stumbling block altogether, if possible.

Of course, first we'd have to understand what this error means and whether it's our fault in any way...

[wayneoutthere]

This also affects me in cpanel. Let me know what information you need for me to post. Basically I just tried to install suite crm on shared cpanel hosting and for the first time in about 6 years of using suite crm I had a snag where the password will not accept. After disabling ModSecurity in cpanel and logging in again, I was able to successfully log in. This seems bad as now this security thing is totally turned off in my cpanel and I'd like to turn it on. Thanks to all of you!

[pgorod]

In the original error reported by @itmonitor, it's complaining about special characters found in the argument user_password. So I guess if you can try it with a simple password, one that does not include any special characters, and see if it makes any difference, that would help. Thanks.

[wayneoutthere]

Tried that. tried almost everything related to password. Also tried updating PHP to 7.0.... shorter password, no special characters, no numbers, blah blah. The only thing that fixed it was shutting off the ModSecurity now it's working fine...

[itmonitor]

@pgorod in my case the password never had any special characters as I am still testing SuiteCRM. If Comodo WAF is reporting special characters that does not exist, then there it is an indication that can help SuiteCRM solve the issue. Hope this information helps.

[chris001]

@itmonitor @wayneoutthere
The Comodo WAF firewall rule is matching the field user_password.

[msg "COMODO WAF: Blind SQL Injection Attack||mydomain.com|F|2"] [data "Matched Data: user_password found within ARGS_NAMES:user_password: user_password"] [severity "CRITICAL"] [tag "CWAF"] [tag "SQLi"] [hostname "mydomain.com"] [uri "/stcr/index.php"] [unique_id "xxx"]

https://github.com/salesagility/SuiteCRM/search?utf8=%E2%9C%93&q=user_password&type=
You can edit the firewall rule and change it to match something else like user_pw.

[wayneoutthere]

thanks @chris001 I'll try that. Is there a longer term solution for this for cpanel users though? the fact that suitecrm is so darn awesome and so easy to install in cpanel is a massive boon. it would seem that whatever it takes to keep the cpanel instant-install thing working without a hitch is critical. my two bits but for now I'll see if I can figure out how to do what you did...

[pgorod]

Oh, it matches the actual parameter name, not something inside the parameter... I see.

Then for more definitive fix there could be two approaches:

1. bugging the Comodo people to remove this over-zealous, illogical rule
2. refactoring the code on our side to change that name user_password on a couple of places (only the ones setting and getting the $_REQUEST values).

[itmonitor]

@chris001 Not all SuiteCRM users can access WAF rules and modify them. Even for us that can access the rules, it is a pain... Why change a rule that works with every other software we have installed in our servers? :-) Think about a perfect SuiteCRM usability immediately after install without any further need to config WAF or whatever. SuiteCRM new/existing users will love it. @pgorod @chris001 please, go for the second option.

[pgorod]

I agree with you that we should get to a point where this works out of the box.

The allure of option 1 is the simple fact that they seem to have messed up, not us. As far as I can tell, that is a stupid rule because the name of a parameter does not justify calling this an injection attack. By the way, I wasn't speaking of bugging your hosting service to change the rule for you, I was speaking of bugging whoever writes that software in the first place, if you can find them and contact them... and they can change the rule everywhere.

[wayneoutthere]

@pgorod agreed...

[itmonitor]

@pgorod @ wayneoutthere @chris alright, let me check now with the Comodo people. I post their reply here.

[chris001]

Comodo WAF is a web front end for Apache ModSecurity.
This "False Positive" issue has been an issue for about 10 years, and for many other apps which also use a parameter named user_password.

Read more about it here.

• https://suitecrm.com/community/forum/installation-upgrade-help/4128-suitecrm-blind-sql-injection-issue

Since implementing mod_security ModSecurity for Apache/2.9.0 (www.modsecurity.org/); with rules OWASP_CRS/2.2.9 I have the same problem.

It is a problem with the parameter name user_password

I have implemented a custom rule in modsecurity_crs_60_customrules.conf to ignore that parameter. You can see two attempts both work.

# SuiteCRM login parameter name problem
#SecRuleUpdateTargetById 950007 !ARGS_NAMES:user_password

# SuiteCRM login parameter name problem
SecRule REQUEST_FILENAME "@endsWith index.php" \
"phase:1,t:none,nolog,pass,id:9500071,ctl:ruleRemoveTargetByID=950007;ARGS_NAMES:user_password"

>

See here: https://www.trustwave.com/Resources/SpiderLabs-Blog/ModSecurity-Advanced-Topic-of-the-Week--%28Updated%29-Exception-Handling/ for more details.

Cheers

Question is, what's the current best names for the login password field.

Let's look at Google.

Google uses this:

<label class="hidden-label" for="Passwd">Password</label>

<input id="Passwd" name="Passwd" type="password"
       placeholder="Password"
       class=""
       autofocus>

<input id="signIn" name="signIn" class="rc-button rc-button-submit" type="submit" value="Sign in">

  <label class="remember">
  <input id="PersistentCookie" name="PersistentCookie"
                 type="checkbox" value="yes"
                 checked="checked">
  <span>
  Stay signed in
  </span>

SuiteCRM login form probably ought to be updated to use something similar to Google's login form.

[chris001]

The real reason ModSecurity is flagging this as a security issue is, it's concerned the password value may be passed to the database as part of the SQL command without being hashed or escaped first, without which, the app is vulnerable to an SQL injection attack,
http://www.webhostingtalk.com/showthread.php?t=1465278
Fortunately SugarCRM 6.5 hashes and encrypts user_password so there is no risk of SQL injection attack from this.

[wayneoutthere]

hey folks. So, just wanted to update that interestingly my other instance of suitecrm has done a 403 error out of the blue. it was working perfectly for about 1.5 years and then today (interesting timing??) it gave me a nasty 403 error and scared me quite bad.
Then I found this guys' post in the forum and figured out that it was, again, ModSecurity. When I disabled ModSecurity completely for this domain that runs my suitecrm instance, all was good in the hood again... but now all my suitecrm instances have ModSecurity disabled which is... bad, yes? For now, if there is a way to turn it on and tweak something to make it work with security on while this bug gets fixed that would be great and greater!

[chris001]

@wayneoutthere
Until the login form gets fixed to not trigger this attack alert, you, or your server's tech support admin, will need to go into your ModSecurity control panel - Comodo WAF, Cpanel, Plesk, or whichever one you're using - and disable rule 211540 for your SuiteCRM instance domain.

[wayneoutthere]

ok. seems like not possible via my cpanel for some reason.
I could find 'ModSecurity" but there was only one option inside "disable/enable" and you can do that for an entire domain.
I search cpanel and could not find a firewall where I could do this but maybe it has a different name?

[itmonitor]

@cris001 @pgorod if I understood well, cris001 says that while SugarCRM 6.5 hashes and encrypts the password, SuiteCRM does not so. Is that right?

If yes, then SuiteCRM should code the login to be hashed and encrypted too. With hackers all around theses days, not wise to not encrypt login data and furthermore, taking into account the confidential/strategic information that is available inside a CRM app. Information from the CRM owner and also from the client companies. This could pose a serious risk of the clients suing the CRM owner in the case their information is leaked - if the hacker gets into the CRM data through the non-encrypted/hashed login.

I still did not receive the reply from Comodo WAF, but it seems their software is pointing to an existent security risk involving user and password login data. Therefore, they will not change their rules. I believe SuiteCRM login should be encrypted and hashed ans cris001 proposes: "SuiteCRM login form probably ought to be updated to use something similar to Google's login form."

How about fixing this security bug now?

[gunnicom]

@itmonitor calm down and stop to shout.
suitecrm does hash passwords, so no reason to worry here.

[itmonitor]

@gunnicom stay calm, nobody is shouting, that was a mistake in the "insert code" function here.

[itmonitor]

@gunnicom you mean the passwords are not hashed, this means SuiteCRM stores passwords in clear text? Please, clarifly.

[pgorod]

@itmonitor you can forget about Comodo, it's just a front end. I didn't know that until Chris explained, sorry.

And after some more web-browsing it seems this Apache modsec issue is quite old and known, so I don't think we can get it changed. Strategy number 2 is now clearly looking like the best option.

[pgorod]

@itmonitor both @chris001 and @gunnicom wrote the SuiteCRM does hash and encrypt password, yes.

Just read it carefully.

[itmonitor]

Hi pgorod, many thanks. Agree with you. :-) The code should be refactored to eliminate this issue. Any idea when this could be done within your availability?

[jobst]

@itmonitor if you (had) check(ed) the database of SuiteCRM you would clearly see that the passwords are hashed. You could also shout at ModSecurity - from memory they are ONLY checking for that one instance "user_password" not all the other possible ways of writing/storing/accepting passwords e.g. "uPasswd" or "upwd" .... just saying,

[itmonitor]

@jobst thank you. As I posted above, I already contacted Comodo about this issue and are waiting their reply. I will post their reply here.

[chris001]

@itmonitor

• SuiteCRM runs on top of SugarCRM 6.5. Passwords are stored encrypted:
  https://developer.sugarcrm.com/2012/05/16/new-for-sugar-6-5-stronger-password-storage-encryption/

• To workaround this 403 access denied, ask your server admin or hosting tech support, to disable ModSecurity rule 211540 for your crm domain. Here's a tutorial:
  https://samhobbs.co.uk/2015/09/example-whitelisting-rules-apache-modsecurity-and-owasp-core-rule-set

[wayneoutthere]

Thanks very much for the work around. I'll try that on for size and confirm they were able to do it with relative ease. I will ask them to disable 211540, and, turn Mod Security back on (it's fully disabled now) Thanks again for the help and look forward to the more solid solutions above for the long term fix.

[wayneoutthere]

just want to confirm that it appears the work around above works. hosting company disabled 211540 and everything seems to be working wtih modsecurity enabled. Thanks!