PGP SIGNED MESSAGE content gets flagged

Description

My service accepts PGP SIGNED MESSAGE text files to be uploaded via HTTP POST. Looks like the \r\n required by PGP ascii armored file specification gets flagged. The digital signature part also seems to get flagged somehow.

Audit Logs / Triggered Rule Numbers

[Fri Sep 04 05:06:51.532088 2020] [:error] [pid 21278] [client IP:PORT] [client IP] ModSecurity: Warning. Pattern match "[\\\\n\\\\r]" at ARGS_NAMES:-----BEGIN PGP SIGNED MESSAGE-----\\r\\nHash: SHA512\\r\\n\\r\\nProduct: FileBot\\r\\nNAME: adam\\r\\nEmail: EMAIL\\r\\nOrder: P17245884\\r\\nIssue-Date: 2020-08-26\\r\\nValid-Until: 2021-09-02\\r\\n-----BEGIN PGP SIGNATURE-----\\r\\n\\r\\niQEzBAEBCgAdFiEEc1MV/TP2QOyyCr5UyhKNCCTOINkFAl9GZeEACgkQyhKNCCTO\\r\\nINl eAf/bRZ8hwNds8tPaPOWTWXdYS1PrEnGCvuDWlb07NV14JlhuqL7JQaDJ9KH\\r\\nFeiUzDG/JbncmBIRRFVG rGdMBmt8OCnj1yW8QardcHvBz/5A4NOIUZweijFejvb\\r\\n8NDXZ4NxU4BrbGGROG7OLW/R26ELLpgBuLZbG5/NDD6R/QEJmBnvNtUfMOBEn64I\\r\\n6nNqO4WH3cVq4qSv/ApVU/Iek8vXbXHE/nC/A8lcX8pphyLV9nCEST3XeqgjR0HP\\r\\n696Po qyH3XPzDrDRZ1JdqsxF5HDFSHlmcDY0OCl7e8 ekXuTg1wA3m975Adyqis\\r\\n3LPWsdKTuBdbuK LwJmZHbIt01WbKg. [file "/dh/apache2/template/etc/mod_sec3_CRS/REQUEST-921-PROTOCOL-ATTACK.conf"] [line "171"] [id "921150"] [msg "HTTP Header Injection Attack via payload (CR/LF detected)"] [data "Matched Data: \\x0d found within ARGS_NAMES:-----BEGIN PGP SIGNED MESSAGE-----\\x5cr\\x5cnHash: SHA512\\x5cr\\x5cn\\x5cr\\x5cnProduct [hostNAME "HOST"] [uri "/verify/P17245884"] [unique_id "X1It2@kyOZuAIv3a6OjZ0gAAAAs"]
[Fri Sep 04 05:06:51.533329 2020] [:error] [pid 21278] [client IP:PORT] [client IP] ModSecurity: Warning. Pattern match "(?i)(?:;|\\\\{|\\\\||\\\\|\\\\||&|&&|\\\\n|\\\\r|`)\\\\s*[\\\\(,@\\\\'\\"\\\\s]*(?:[\\\\w'\\"\\\\./]+/|[\\\\\\\\'\\"\\\\^]*\\\\w[\\\\\\\\'\\"\\\\^]*:.*\\\\\\\\|[\\\\^\\\\.\\\\w '\\"/\\\\\\\\]*\\\\\\\\)?[\\"\\\\^]*(?:m[\\"\\\\^]*(?:y[\\"\\\\^]*s[\\"\\\\^]*q[\\"\\\\^]*l(?:[\\"\\\\^]*(?:d[\\"\\\\^]*u[\\"\\\\^]*m[\\"\\\\^]*p(?:[\\"\\\\^]*s[\\"\\\\^ ..." at ARGS_NAMES:-----BEGIN PGP SIGNED MESSAGE-----\\r\\nHash: SHA512\\r\\n\\r\\nProduct: FileBot\\r\\nNAME: adam\\r\\nEmail: EMAIL\\r\\nOrder: P17245884\\r\\nIssue-Date: 2020-08-26\\r\\nValid-Until: 2021-09-02\\r\\n-----BEGIN PGP SIGNATURE-----\\r\\n\\r\\niQEzBAEBCgAdFiEEc1MV/TP2QOyyCr5UyhKNCCTOINkFAl9GZeEACgkQyhKNCCTO\\r\\nINl eAf/bRZ8hwNds8tPaPOWTWXdYS1PrEnGCvuDWlb07NV14JlhuqL7JQaDJ9KH\\r\\nFeiUzDG/JbncmBIRRFVG rGdMBmt8OCnj1yW8QardcHvBz/5A4NOIUZweijFejvb\\r\\n8NDXZ4NxU4BrbGGROG7OLW/R26ELLpgBuLZbG5/NDD6R/QEJmBnvNtUfMOBEn64I\\r\\n6nNqO4WH3cVq4qSv/ApVU/Iek8vXbXHE/nC/A8lcX8pphyLV9nCEST3XeqgjR0HP\\r\\n696Po qyH3XPzDrDRZ1JdqsxF5HDFSHlmcDY0OCl7e8 ekXuTg1wA3m975Adyqis\\r\\n3LPWsdKTuBdbuK LwJmZHbIt01WbKg. [file "/dh/apache2/template/etc/mod_sec3_CRS/REQUEST-932-A [hostNAME "HOST"] [uri "/verify/P17245884"] [unique_id "X1It2@kyOZuAIv3a6OjZ0gAAAAs"]
[Fri Sep 04 05:06:51.538980 2020] [:error] [pid 21278] [client IP:PORT] [client IP] ModSecurity: Access denied with code 418 (phase 2). Operator GE matched 7 at TX:anomaly_score. [file "/dh/apache2/template/etc/mod_sec3_CRS/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "91"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 10)"] [severity "CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostNAME "HOST"] [uri "/verify/P17245884"] [unique_id "X1It2@kyOZuAIv3a6OjZ0gAAAAs"]
[Fri Sep 04 05:06:51.544745 2020] [:error] [pid 21278] [client IP:PORT] [client IP] ModSecurity: Warning. Operator GE matched 7 at TX:inbound_anomaly_score. [file "/dh/apache2/template/etc/mod_sec3_CRS/RESPONSE-980-CORRELATION.conf"] [line "86"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 10 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=5,PHPI=0,HTTP=5,SESS=0): individual paranoia level scores: 10, 0, 0, 0"] [tag "event-correlation"] [hostNAME "HOST"] [uri "/verify/P17245884"] [unique_id "X1It2@kyOZuAIv3a6OjZ0gAAAAs"]

Your Environment

Shared hosting environment via Dreamhost.

Confirmation

[X] I have removed any personal data (email addresses, IP addresses, passwords, domain names) from any logs posted.

[dune73]

We have not heard from @rednoah anymore. Closing this issue.

[airween]

Hi @rednoah,

thanks again for the quick curl tip, I could reproduce your issue.

I think these are not false positives, the engine with the rule set does what it has to do.

You didn’t mention what CRS version you are using, so in my dev environment I checked your request against v3.4/dev. This is just relevant because the links below have generated based on this version’s URL’s. This is a small script what I used (it helps to find the rule as quickly). (If you want to test it, don’t forget to replace the BASEH variable at the top of the code.)

I’m using CRS in that environment on PL4, with SecRuleEngine DetectOnly. This means the given curl command triggered all available rules, because the request will not blocked after the first match. With this setting, I discovered these rules in my log:

920272 Invalid character in request (outside of printable chars below ascii 127) 920273 Invalid character in request (outside of very strict set) 920360 Argument name too long 921150 HTTP Header Injection Attack via payload (CR/LF detected) 942430 Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (12) 942431 Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (6) 942432 Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (2) 942440 SQL Comment Sequence Detected 942460 Meta-Character Anomaly Detection Alert - Repetitive Non-Word Characters 949110 Inbound Anomaly Score Exceeded (Total Score: 68) 980130 Inbound Anomaly Score Exceeded (Total Inbound Score: 68 - SQLI=28,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=5,SESS=0): individual paranoia level scores: 10, 13, 24, 21

I think the solution in your case should be to make an exclusion. After I checked the matched variables in these rules above, I’ve created this exclusion:

SecRule REQUEST_URI "@beginsWith /verify/P17245884" \
    "id:1001,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    ctl:ruleRemoveTargetById=920272;ARGS,\
    ctl:ruleRemoveTargetById=920272;ARGS_NAMES,\
    ctl:ruleRemoveTargetById=920272;REQUEST_BODY,\
    ctl:ruleRemoveTargetById=920273;ARGS,\
    ctl:ruleRemoveTargetById=920273;ARGS_NAMES,\
    ctl:ruleRemoveTargetById=920273;REQUEST_BODY,\
    ctl:ruleRemoveById=920360,\
    ctl:ruleRemoveTargetById=921150;ARGS_NAMES,\
    ctl:ruleRemoveTargetById=942430;ARGS_NAMES,\
    ctl:ruleRemoveTargetById=942431;ARGS,\
    ctl:ruleRemoveTargetById=942431;ARGS_NAMES,\
    ctl:ruleRemoveTargetById=942432;ARGS,\
    ctl:ruleRemoveTargetById=942432;ARGS_NAMES,\
    ctl:ruleRemoveTargetById=942440;ARGS,\
    ctl:ruleRemoveTargetById=942440;ARGS_NAMES,\
    ctl:ruleRemoveTargetById=942460;ARGS,\
    ctl:ruleRemoveTargetById=942460;ARGS_NAMES"

This solved the problem, and the request didn’t trigger any rule.

Put this rule into your /dh/apache2/template/etc/mod_sec3_CRS/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf, and check again.