Note: This post is advanced and is mainly aimed at system administrators, but any Joomla administrator can still read it and understand the main points as we have simplified it as much as we can.
One of our customers constantly emailed us about people getting randomly blocked from accessing their Joomla website. At first, our response was as simple as manually unblocking the blocked IPs in CSF (ConfigServer Security & Firewall) as we thought it was just something that they mistakenly did on the website that caused them to get blocked. However, the situation became more of an issue when some of these people became blocked on a daily basis (and, in some cases, on an hourly basis). We needed to investigate the issue…
So, we checked the modsec_audit.log file (which is the ModSecurity log file) that is located under the /usr/local/apache/logs folder for one of the blocked IPs and here’s what we saw:
--c39ced72-A-- [31/Dec/2017:13:05:01 --0800] WklQ-dEvE6fYw87vIOCzMwAAAVU [offending-ip] 54353 [server-ip] 443 --c39ced72-B-- PROPFIND /media/kunena/emoticons/smile.png HTTP/1.1 Host: our-client-joomla-website.com User-Agent: Apache OpenOffice/4.1.3 Accept-Encoding: gzip Depth: 0 Content-Type: application/xml Transfer-Encoding: chunked --c39ced72-C-- <?xml version="1.0" encoding="utf-8"?><propfind xmlns="DAV:"><prop><resourcetype xmlnx="DAV:"/><IsReadOnly xmlnx="http://ucb.openoffice.org/dav/props/"/><getcontenttype xmlnx="DAV:"/><supportedlock xmlnx="DAV:"/><lockdiscovery xmlnx="DAV:"/></prop></propfind> --c39ced72-F-- HTTP/1.1 500 Internal Server Error Content-Length: 679 Connection: close Content-Type: text/html; charset=iso-8859-1 --c39ced72-H-- Message: Access denied with code 500 (phase 2). Match of "rx ^$" against "REQUEST_HEADERS:Transfer-Encoding" required. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "183"] [id "340004"] [rev "1"] [msg "Dis-allowed Transfer Encoding"] [severity "CRITICAL"] Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client [offending-ip]] ModSecurity: Access denied with code 500 (phase 2). Match of "rx ^$" against "REQUEST_HEADERS:Transfer-Encoding" required. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "183"] [id "340004"] [rev "1"] [msg "Dis-allowed Transfer Encoding"] [severity "CRITICAL"] [hostname "our-client-joomla-website.com"] [uri "/media/kunena/emoticons/smile.png"] [unique_id "WklQ-dEvE6fYw87vIOCzMwAAAVU"] Action: Intercepted (phase 2) Stopwatch: 1514754301176673 671 (- - -) Stopwatch2: 1514754301176673 671; combined=117, p1=35, p2=82, p3=0, p4=0, p5=0, sr=12, sw=0, l=0, gc=0 Producer: ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/). Server: Apache Engine-Mode: "ENABLED" --c39ced72-Z--
If you look closely at the first paragraph, you will notice that the whole cycle of events started with a request from OpenOffice to the smile.png emoticon in a Kunena forum. The request was innocent, looked innocent, but it didn’t act as innocent: the Transfer Encoding value sent by OpenOffice was not allowed, and, as such, it was blocked by a custom ModSecurity rule developed by LiquidWeb. Looking at the file modsec2.liquidweb.conf which contained the blocking rule, we found the following:
# Don't accept transfer encodings we know we don't handle # (and you don't need it anyway) SecRule HTTP_Transfer-Encoding "!^$" "id:340004,rev:1,severity:2,msg:'Dis-allowed Transfer Encoding'"
The above lines define the rule 340004 which blocks unknown transfer encodings. So, a quick solution to the problem was to remove the above rule (or comment it out with a #) from the modsec2.liquidweb.conf file and then restart Apache, and this is what we did. However, it wasn’t the ideal solution, since that rule was there for a reason, and it was additional protection. Then again, it was happening so often to the members of the site that it threatened the very existence of the business.
But, why did OpenOffice try to load the image?
An analysis to the problem, as well as statements from members, revealed that the problem started with the affected members copying content from the forum and then pasting that content into an OpenOffice document. That content contained emoticons (images), which only had their references copied, and so OpenOffice tried to load them (using the wrong headers) from the remote site in order to display them in the document.
Isn’t there a better solution to the problem than to remove the rule?
Well, yes. The best solution is that OpenOffice sends valid requests (including a valid Transfer Encoding value). Another solution would be to tell members not to copy content from the forum into OpenOffice, and use another tool instead to copy content. Admittedly, both solutions are a bit unrealistic, but we do hope that the people at OpenOffice resolve the problem.
So, the next time, our dear reader, your clients complain about being randomly blocked from accessing your website, think about checking your ModSecurity log; it might be OpenOffice. If you need help uncovering the culprit, then please contact us. We are Joomla security experts, we are based in Montreal, we are hard workers, and our rates are always affordable.