SQL Injection & Amazon AWS

Hi @icks13

I don’t understand at all most of your post. For example, I don’t understand what Trend Micro’s relationship is to “Two of their clients answered back this”.

I think what you are trying to say is that you are giving other people’s unsatisfactory experience of trying to report abuse to AWS.

About half of all internet traffic is automated bot traffic and a good amount of it is malicious so it is not unusual at all to see the Wordfence firewall blocking a lot of automated attacks.

If you are seeing a lot of attacks from AWS then you may want to use the AWS hostname block example you can see in the Custom Pattern blocking option on the Firewall >> Blocking page. However, make sure that you don’t have any plugins installed on your site that may send and receive calls to and from an AWS server that the plugin author uses for plugin functionality.

For the things that AWS support want to see then you can send them screenshots from your Wordfence Live Traffic page feed as you can’t export the data. For everything else, your hosting provider can help you with that.

“Two of their clients answered back this” refers to Amazon AWS. When you report to Amazon AWS they take your report and send it to the company who is using their server, the company answer back and the tell you what the company has said.

I think what you are trying to say is that you are giving other people’s unsatisfactory experience of trying to report abuse to AWS.

No, what I’m trying to say is that Wordfence report SQL injection from Amazon AWS, while Amazon AWS report their customers reply (two of them so far) saying that basically is not an SQL injection, putting me in the situation of not understanding if Wordfence detect wrong report SQL Injection or not.

For the things that AWS support want to see then you can send them screenshots from your Wordfence Live Traffic page feed

No I can not, because like I’ve said is what I was doing until at some point, Amazon AWS replied that such data were not enough and wanted the things listed above.

Personally I use right commands in .htaccess file + Wordfence, which used to be ok for a long time.

.htaccess line

# Deny SQL injection
RewriteCond %{query_string} concat.*\( [NC,OR]
RewriteCond %{query_string} union.*select.*\( [NC,OR]
RewriteCond %{query_string} union.*all.*select [NC]
RewriteRule ^(.*)$ index.php [F,L]

and some additional:

# Block wp-includes folder and files
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ – [F,L]
RewriteRule !^wp-includes/ – [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ – [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php – [F,L]
RewriteRule ^wp-includes/theme-compat/ – [F,L]
</IfModule>

# Block 64x links
Options +FollowSymLinks -Indexes
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]

# Deny Http headers reading
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* — [F]

# Deny access to all .htaccess files
<files ~ “^.*\.([Hh][Tt][Aa])”>
order allow,deny
deny from all
satisfy all
</files>

• This reply was modified 5 years, 1 month ago by Wadham.

@panascanic thank you! I’m not a tech guy but I’ll ask to a friend of mine to have a view.

However what about the capability of Wordfence to correctly detect an SQL Injection? Do you know if is what it is, or Wordfence can interpret one thing for another? and so give a wrong information? ty

You are welcome. I`m not a geek as well, thats smth.what I have learnt in a period of time when some guys were trying to hack a website I have created.

Yes Wordfence must detect SQL injections correctly. But this thing with .htaccess file is kind of REcheck when all is checked. More to say, there are probably some vulnerabilities in Wordfence as well, maybe they are hard to find and implement. So still .htaccess file is a free option to be more secured.

In my case some guys where trying to reach xmlrpc.php like for 3 months long. Its a well known issue with WP connected with xmlrpc.php which lets to post from phones. Since I dont need this option, first thing what I did (when noticed requests to this file) - I have googled what is for. After I have deleted this file (zipped it before, in case of any issue Im able to extract it), website was just fine, so I have kept it like that.

So, basically instead of those “many many ways” to hack WP they use about 5-10 very common ones. Most of them I have covered with .htaccess

https://yadi.sk/i/EFxcY2EtElUGbw

Such a funny and everyday issue of getting to wp-login.php I have covered with WPS Hide Login. In order to login correctly one need to know right URL
like https://www.cnn.com/anotherfunnystory23youhavetoknow – only after one gets to WP-Login window.

I have added “wp-login” request as a rule in Wordfence to be banned – just to imitate that its covered by Wordfence, but its not so.

Another not harmfull but annoying thing was many attempts to find the name of WP folder at hosting server.

https://yadi.sk/i/nHVhCYEcPk7f3Q

Even there is a pattern Browser: undefined I couldnt block it via Wordfence Rule. But I have cut it via another .htaccess rule.

And I keep backup my website every week and its database as well. So even its hacked – I`ll erase it and reinstall it in 20min.

p.s. www.remarpro.com moderators – please change your patterns of identifying text connected with Hacks, WP Issue and other words. Cause this forum will never be used to post some usefull things about hacking, so why would you even try to cut some text for personal moderation later on ?? Unless you have plenty of time and illusion of control

• This reply was modified 5 years, 1 month ago by Wadham.
• This reply was modified 5 years, 1 month ago by Wadham.
• This reply was modified 5 years, 1 month ago by Wadham.
• This reply was modified 5 years, 1 month ago by Wadham.
• This reply was modified 5 years, 1 month ago by Wadham.
• This reply was modified 5 years, 1 month ago by Wadham.
• This reply was modified 5 years, 1 month ago by Wadham.
• This reply was modified 5 years, 1 month ago by Wadham.

@wfphil as I was saying the information provided by Wordfence, does not please AmazonAWS all the time, once in a while they reply (just received):

* Complete, accurate timestamps of the activity including:
– Date
– Time
– Time Zone

* All source IPs
* Log extracts showing the intensity and duration of the activity

and other times they ask:
* Destination IP(s)
* Destination port(s) and protocol(s)

also, is it accurate Wordfence when detect an SQL injection or can make mistakes

Hi @icks13

The block is due to the index term.

Try these any you won’t get blocked:

example.com/?s=index

example.com/?s=index/index

Try this and you will be blocked:

example.com/?s=index/index/index

This is because each term has a weight of 40% and when it exceeds 100% the block is carried out.

The following you can get from your raw access logs if you ask your hosting provider:

Complete, accurate timestamps of the activity including:
– Date
– Time
– Time Zone

* All source IPs
* Log extracts showing the intensity and duration of the activity

and other times they ask:
* Destination IP(s)
* Destination port(s) and protocol(s)

@wfphil ok I understand your explanation but then I do not understand the explanation of Trend Micro, which is the customer of Amazon AWS that is constantly getting blocked by Wordfence as SQL injection attempt.

Trend Micro stated that is not a malicious action and that they are simply performing a check on the exact URL used bu their customer. (Apparently they are a cyber security business)
Wordfence is showing this URL https://my-website-server-IP/public/?s=index%2Findex%2Findex and so for me is difficult to imagine a person that type such URL and this make Trend Micro explanation a no sense at least for my ignorance on this matter.

@wfphil today by checking live traffic I’ve just found out that Wordfence has detected this:

Croydon, United Kingdom arrived from https://my-site-ip/public/?s=index%2Findex%2Findex and was blocked by firewall for SQL Injection in query string: s=index%2Findex%2Findex at https://my-site-ip/public/?s=index%2Findex%2Findex
10/31/2019 7:32:20 AM (8 hours 48 mins ago)
IP: 5.62.43.79 Hostname: r-79-43-62-5.consumer-pool.prcdn.net
Human/Bot: Human
Browser: Chrome version 0.0 running on Win10
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36

the IP 5.62.43.79 is registered to Avast Software.

So, isn’t that Wordfence when it’s about SQL injection is generating a lot of false alerts? (literally a lot)

Because Trend Micro, Fireeye and Avast are all involved in cyber security, so perhaps when they check something in the way in which they check it, Wordfence wrongly detect it as SQL injection

Hey @icks13
You may try to modify your .htaccess file with this:

# Deny SQL injection
RewriteCond %{query_string} concat.*\( [NC,OR]
RewriteCond %{query_string} union.*select.*\( [NC,OR]
RewriteCond %{query_string} union.*all.*select [NC]
RewriteRule ^(.*)$ index.php [F,L]

So you may check how it goes with Wordfence and SQL injinjection after.

Additionaly I have in my .htaccess these commands:

# Block access to PHP files
RewriteCond %{REQUEST_URI} !^/wp-content/plugins/file/to/exclude\.php
RewriteCond %{REQUEST_URI} !^/wp-content/plugins/directory/to/exclude/
RewriteRule wp-content/plugins/(.*\.php)$ – [R=404,L]
RewriteCond %{REQUEST_URI} !^/wp-content/themes/file/to/exclude\.php
RewriteCond %{REQUEST_URI} !^/wp-content/themes/directory/to/exclude/
RewriteRule wp-content/themes/(.*\.php)$ – [R=404,L]

# Deny access to all .htaccess files
<files ~ “^.*\.([Hh][Tt][Aa])”>
order allow,deny
deny from all
satisfy all
</files>

Hi @icks13

The SQL injection rule looks for multiple SQL keywords, and when found, it runs a parser that checks for SQL-like syntax. It can’t check for perfect SQL statements without a lot of extra processing on a fair number of hits that would decrease performance.

If anti-malware and other security product vendors are making the same unusual requests as the customers of those products then that would indicate that those URL’s may possibly be being generated by a bug somewhere on your site when normal visitors visit your site.

I have seen something similar once a long time ago for an unusual WordPress search query string parameter on another user’s site that was intermittent. They didn’t report back what was causing it.

Naturally we can’t help you debug your site as we can only provide support for our plugin and general WordPress security.