What the hell is this hack attempt?

[cprats]

I've found dozens of queries like these in the visitors raw data:

141.98.81.178 - - [23/Dec/2019:13:04:32 -0500] "GET /en/cart?add=1&id_product=14495%27%29%20UNION%20ALL%20SELECT%20NULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL--%20ToBE&token=6dc8273224e872a47705f5c92fce42d6 HTTP/1.1" 200 6635 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.134 Safari/534.16"
141.98.81.178 - - [23/Dec/2019:13:04:33 -0500] "GET /en/cart?add=1&id_product=14495%27%29%20UNION%20ALL%20SELECT%20NULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL--%20YqvM&token=6dc8273224e872a47705f5c92fce42d6 HTTP/1.1" 200 6636 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.134 Safari/534.16"
141.98.81.178 - - [23/Dec/2019:13:04:34 -0500] "GET /en/cart?add=1&id_product=14495%27%29%20UNION%20ALL%20SELECT%20NULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL--%20Auku&token=6dc8273224e872a47705f5c92fce42d6 HTTP/1.1" 200 6637 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.134 Safari/534.16"
141.98.81.178 - - [23/Dec/2019:13:04:34 -0500] "GET /en/cart?add=1&id_product=14495%27%29%20UNION%20ALL%20SELECT%20NULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL--%20DFwZ&token=6dc8273224e872a47705f5c92fce42d6 HTTP/1.1" 200 6637 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.134 Safari/534.16"
141.98.81.178 - - [23/Dec/2019:13:04:36 -0500] "GET /en/cart?add=1&id_product=14495%27%29%20UNION%20ALL%20SELECT%20NULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL--%20KpXZ&token=6dc8273224e872a47705f5c92fce42d6 HTTP/1.1" 200 6639 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.134 Safari/534.16"

I never seen this before.

I have PrestaVault so I did a scan of the site, and found nothing suspicious. Any idea of what did this pretend?

[datakick]

This is some (blind) automated script that tries to find sql injection vulnerabilities in the system. This kind of attack is possible when developer forgets to sanitize input values for sql queries. For example, php script like this is vulnerable:

$id_product = $_GET['id_product'];
$sql = "SELECT name FROM tb_product WHERE id_product = " . $id_product;
Db::getInstance()->executeS($sql);

Php script expects $id_product to be number. But attacker can send anything, for example string like this:

"'non-existing' UNION SELECT password FROM tb_employee"

Which results in sql query

SELECT name FROM tb_product WHERE id_product = 'non-existing'
UNION ALL 
SELECT password FROM tb_employee

This query returns employee password, instead of product name. PHP script will use this value and probably print it somewhere in the page. And attacker now knows (hashed) password of employee.

That's just an example. There are a lot more attacker can do, including gaining admin access to your store.

[cprats]

Thanks for the reply. Should I worry for what happened? How can I check if this has had consequences?

[yaniv14]

Start by blocking the ip address and see if this bot attack again from different ip

[cprats]

18 minutes ago, yaniv14 said:

Start by blocking the ip address and see if this bot attack again from different ip

Thank-you. I stopped the attack while it was ongoig by blocking the IP yesterday afternoon, and since then it has not started again from anywhere else.

[datakick]

13 hours ago, cprats said:

Thanks for the reply. Should I worry for what happened? How can I check if this has had consequences?

It's not easy to answer. Probably not, as this looks like a blind fishing expedition. The bot was just testing the waters to see if anything sticks.

But note that ps / tb codebase is very prone to this kind of attacks. That's because there isn't any real database abstraction layer, and it's common practice to create database query by concatenating strings. There are hundreds / thousands such queries in the codebase (both core and modules). I'm sure few of them is badly written, when developer forgot to sanitize input values