On 03/23/2016 08:21 PM, Always Learning wrote:
mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
I spotted something strange and immediately installed a routine to automatically impose an iptables block when the key used for database access is excessively long.
My URL was something like this
...../...../.....php?key=123456
The injection was something like this
...../...../.....php?key=876711111111111111111111111111' UNION SELECT 13,CONCAT([X],count(*),[X],13,13,13,13,13,13 FROM information_schema.TABLES WHERE `TABLE_NAME` LIKE "%wp_users%" -- /* order by 'as
There are no user permission on information_schema.
There seems to be 2 versions of the coding floating around on Austrian and Russian IPs. One is ineffective but the other works. It seems the author is expert in the intricate structure and design of SQL.
Always use parameterized statements (aka prepared statements) for SQL that involves untrusted input.
I like to use them even for input that involves trusted input because it is easy to make a change in my code and not think about how it impacts the parameters.
-=-
This is an attack on WordPress ??? Or just trying to get WordPress database from a different app?
Be careful with WordPress - it's database handler doesn't actually use parameterized statements, it emulates them with printf - one (of many) reasons I do not like the product.
If it is not an attack on WordPress directly - your WordPress database should be using a different uname/pass from anything else, so actual queries for data should fail.