Critical log error

[SulevFan]

Two new errors in our logs are flagged as Critical.   

The error message says

JSON decode error: Control character error, possibly incorrectly encoded

I can't make much of it, it's a call to php.index with action =php://filter/ followed by more than 200 calls to convert.iconv or convert.base64-encode or base64-decode.



The IP traces to a RIPE-managed .ru domain.

Should I be worried? What, if anything should I do?

[Kindred]

It's a hack attempt.  Not successful.

[Steve]

In other words, you don't need to worry and nothing you need to do at the moment.

[SulevFan]

Thank you for the responses, @Kindred and @Steve . 

I'm all for being alerted to hack attempts. But this error smacks of not being critical. It's a failed hack attempt, so there seems to be nothing I can do about it. It seems it should just be a notification^*, rather than a critical error.

The inverse of this is more worrisome, if the hack attempt *did* work, I'm kind of thinking there would have been no notification?

Which brings me to an ancillary question: Just how is this supposed hack supposed to work? Or any hints as to where I can read more about it and any mitigation efforts I can make?

Would it have succeeded on an older, unpatched version of SMF?

^* A notification that I *do* need, rather than the many notifications I get of users mistyping their passwords. Which I don't need.

[Doug Heffernan]

Would it have succeeded on an older, unpatched version of SMF?

I don't think so. Looking at the error message, they tried to use php filters, in combination with other aforementioned encoding filters, to generate arbitrary content as output. This allows for generating a Base64-encoded minimalist webshell, which can be decode by a final convert.base64-decode filter into active PHP content.

That being said, it is always best, security wise, to use the latest version of whatever forums and/or other scripts that you are running on your server. All the known security issues are patched in the latest version(s).

[SulevFan]

I don't think so.

That was more or less my uneducated guess as well. Which even more raise the issue of *why* SMF flags this as a Critical error rather than an informational one?

And note that I'm making this case as part of my *I don't want to be notified of informational errors" larger case. I find the new way that SMF alerts me of trivial issues such as user password mistypes and now this clearly non-functional hack attempt, intrusive, unnecessary and ultimately serving to diminish the attention that should be devoted to real issues.  My 2 cents' worth.

[Kindred]

Well, because,  if this WAS a valid SMF function, the failed json decode would be a critical error that would need to be fixed.

SMF normally, quietly protects your site... under many circumstances,  you would not even see the hack attempt in the SMF logs. (Look in your server access logs to get an idea of how often the script kiddies are hitting your site with all sorts of hack attempts  (many of them for WordPress or Joomla - so, it's not like they are even looking at what software your site is running).
That's why it is critical to keep your entire site up-to-date!

[SulevFan]

I see this has been marked "solved". Don't recall doing that, don't see who did that either.

I'm going to have to think this over for a bit. Arguing with the likes of those who had been helpful on this thread feels unproductive and I would be arguing from ignorance, which is never a good place to start.

I'm aware of the constant attacks on our site - we look at server logs regularly and had actually suffered financial losses (not SMF-related) some years back, so paranoia is a part of our MO, probably leading to some of my reaction on this thread.

Which is why I'm still mulling this over. It seems that SMF worked well in this instance, and "saved" us from a hack attack. I'm vaguely understanding that somehow the same type of failure could have been caused by SMF receiving some "legit" malformed (if that is not a contradiction in terms) JSON that would appear to be similar to what triggered this event.

How that happens and in what situations, that is not clear. I'm not sure when SMF gets incoming JSON data. If that even is what that is.

So, I'm on this balance point of not knowing enough but knowing that I don't have to react to a critical error. Which isn't a good place to be.

[Steve]

You didn't mark it solved, I did. If you think it shouldn't be mark solved yet then by all means, mark it unsolved.

[mgcAna]

Such kind of attempt can be handled easily with WAF. Depending upon your setup, you can configure WAF on hosting if you are managing it or you can ask your host if its managed by someone else.

If you can, you can also use Cloudflare, its free plan mitigate may such attacks.

There is no need to worry here as SMF a nice piece of software, core smf can easily withstand such attacks.

[Kindred]

That was a pointless response since it had absolutely nothing to do with the question.

[mgcAna]

That was a pointless response since it had absolutely nothing to do with the question.

I would not deny if @Kindred says so, I only suggested WAF implementation assuming that someone is trying to use malformed URLs thus caused that error in logs. 

it's a call to php.index with action =php://filter/ followed by more than 200 calls to convert.iconv or convert.base64-encode or base64-decode.

Or am I reading it all wrong ?

[CRM 114]

I had the same critical errors (4 times from the same IP as in the first posting above) in the log. After the first 2, the IP was put on the banlist. But a few days ago, there were errors again.

So i assume, that it is useless, to ban the IP. Is this correct?

[Kindred]

well, banning an IP in SMF still requires SMF to LOAD in order to check the IP.

If you truly must ban by IP (which is mostly useless, since getting access from a new IP is simple) then do so in the .htaccess using DENY

[CRM 114]

That makes sense. Thanks for the explanation.