SQL injection attacks resulting in Error ID '3'

SQL injection attacks resulting in Error ID '3'

by Matt Johnson -
Number of replies: 1

I'm a little worried, though probably shouldn't be.  I don't know.  I'm not familiar with the security side of things yet I'm the only person in my department.

Recently we got hit by a lot of very fast attempts at using sql injection through the login page.  It started from 1:19pm and eneded at 1:23 pm filling up 8 pages of logs.  (I'm looking at installing mod_evasive for that issue as they should not have been able to make so many requests so quickly)

it started off as just "username" for the username.  Then it got a lot more complex very quickly.

An example of some of the attempts were like

username union all select null,null,null,null,null,null,null,null,null-- azud

What has me concerned though is that if I enter this same thing into the login form the log that results shows "User does not exist ("error ID '1')."  But all of their attempts resulted in "Most likely the password did not match (error ID '3')."

I've obviously blacklisted their IP both on the server firewall and in Moodle (overkill I know)

But should I be concerned that Moodle returned a different error for them than for me trying the exact same thing?  Is it possible they succeeded in getting information?  None of the logs show what they entered for a password (obviously) 

I've run the security check, almost everything is good (default role says Critical but I tried the reset and that didn't fix it so I'm not sure what the problem is there).  I've updated all admin passwords.

Average of ratings: -
In reply to Matt Johnson

Re: SQL injection attacks resulting in Error ID '3'

by Ken Task -
Picture of Particularly helpful Moodlers

Could you share a clip of web service error logs showing that activity?

Also, never use your own workstation/browser etc. for trying out what you saw someone/something try .... it might work or your access (IP address might be blacklisted ... mod_evasive and or mod_security would do that.

Use another IP'd machine and some other account.

Agree that blocking at firewall and moodle is overkill ... the firewall block is really the one to use as that is at the network level ... not the application level.

Hopefully, your server is using firewalld ... adding an IP or a range of IP addresses from the offending network in the 'drop' zone ... means they never see anything of your server again.   Very effective.

What I normally do is to do a whois on the offending IP address.   If I see it's a server hosted on Amazon, or M$, or DigitalOcean, etc. I might put into the drop zone a CDIR ... all IP's in a range.   If I see in whois it's a customer from a telco in some country and NONE of my users in Moodle would ever be using such a connection, I actually might put  into the drop zone the entire network of telco.

Just be carefull not to block yourself! smile

'SoS', Ken

Average of ratings: -