Jump to content

Potential Malicous Attack


keat

Recommended Posts

New accounts are created daily, but about once per week I see a pattern, which I'm guessing is some form of malicous attack, but I've no idea what.

A new account will be created where the surname is identical to the christian name. In the most recent example LydiaTrucTSO LydiaTrucTSO.

There's never an address in the account, no order is ever placed, it usually has a russian TLD in the email, and the IP generally points to the Netherlands, although I've seen Russia, Belarus and Ukrane, which are now blocked on my server.

I've no idea what it is they are trying to do when creating an account, and as the pattern is always the same, I'm assuming it's a BOT of some sort.

 

any thoughts as to what might be going on ?

 

[04/Mar/2019:19:20:05 +0000] "GET /index.php?seo_path=lubrication-cleaning%2Fgrease%2Fcopper-thread-compound-500g HTTP/1.0" 200 27391 "https://www.mydomain.com/index.php?seo_path=lubrication-cleaning%2Fgrease%2Fcopper-thread-compound-500g" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.99"


[04/Mar/2019:19:20:06 +0000] "GET /register.html?agreed=true HTTP/1.0" 200 21478 "https://www.mydomain.com/register.html?agreed=true" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.99"


[04/Mar/2019:19:22:40 +0000] "POST /register.html?agreed=true HTTP/1.0" 302 - "https://www.mydomain.com/register.html?agreed=true" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.99"


[04/Mar/2019:19:22:41 +0000] "GET /?_a=account HTTP/1.0" 200 20048 "https://www.mydomain.com/?_a=account" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.99"


[04/Mar/2019:19:22:41 +0000] "GET /register.html?agreed=true HTTP/1.0" 302 - "https://www.mydomain.com/register.html?agreed=true" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.99"


[04/Mar/2019:19:22:42 +0000] "GET /index.php?seo_path=lubrication-cleaning%2Fgrease%2Fcopper-thread-compound-500g HTTP/1.0" 200 27462 "https://www.mydomain.com/index.php?seo_path=lubrication-cleaning%2Fgrease%2Fcopper-thread-compound-500g" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.99"
[04/Mar/2019:19:22:43 +0000] "GET /index.php HTTP/1.0" 200 30029 "https://www.mydomain.com/index.php" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.99"

 

   
Link to comment
Share on other sites

Looking for newsletter sign up and it doesn't appear on my home page, but the link (if I type it in manually) is still live.

index.php?_a=newsletter.

However, this appears to only contain an email address, so it's not this.

 

If I log in to the cart back end, choose 'customer list', it will be in there.

Sticks out like a sore thumb due to the pattern.

 

I alredy deleted the recent entry, so there would be nothing to see.

 

I'm using Recapture V2, maybe I should consider V3, is there any code for this ?

Link to comment
Share on other sites

I have added some code to the very beginning of when CubeCart is waking up that looks at the POST payload. This robot has a known "signature" and is easily tested for. If the signature is found in POST, PHP dies.

Link to comment
Share on other sites

  • 3 weeks later...

Got another one yesterday.

There's a class B subnet pattern emerging 212.92.x.x

 

Since monitoring, I've seen 114, 116 and 117 class C's.

We have no customers in any of these subnets, so I blocked the subnets in my firewall for now.

 

Link to comment
Share on other sites

  • 2 months later...

Create a file named ini-custom.inc.php. Using a programmer's text editor, the contents of this file will be:

<?php
if(
  (
    (isset($_GET['seo_path']) && $_GET['seo_path'] == "register")
    ||
    (isset($_GET['_a']) && $_GET['_a'] == "register")
  )
  &&
  !empty($_POST['first_name'])
  &&
  !empty($_POST['last_name'])
  && 
  (
    (!empty($_POST['phone']) && $_POST['phone']=="123456")
    ||
    //preg_match('/[A-Z]\z/',trim($_POST['first_name']))===preg_match('/[A-Z]\z/',trim($_POST['last_name']))
    (ctype_upper(substr(trim($_POST['first_name']),-2)) && ctype_upper(substr(trim($_POST['last_name']),-2)))
    ||
    !empty($_GET['agreed'])
  )
) exit; // Kills PHP leaving browser with white screen

It seems this robot always submits a first name and last name with the last character the same (Latin encoding) and capitalized. It also seems to include agreed=true in the querystring - which is not part of CubeCart.

Edit: It seems the preg_match isn't consistently giving what I expected. It worked in some places, but not in other places. So, comment out that line and use the ctype_upper version of that statement.

Link to comment
Share on other sites

There's a first name= last name fix on here from a long time ago. I think SemperFi provided it. But I couldn't find it. It simply prevents those logins from being recorded with no indication to the "bot" that it did not work.

Found it!

 

Link to comment
Share on other sites

Hi Brian.

 

Could you explain how your script works please.

Could this cause problems for legitimate customers.

 

Also, any ideas how this bot has circumvented Re-Capture ?

As an experiment, I deleted and recreated my recapture key yesterday.

 

Link to comment
Share on other sites

It's a simple test. It is presumed that this is a carefully crafted, custom-built submission (POST).

* The page being submitted must be the Registration page. And,
* The POST must have a firstname and a lastname. And,
* One of:
** A phone number that is 123456. Or,
** The last letter of the firstname is capitalized and is exactly the same as the last letter of the lastname. Or,

Edit: This didn't work everywhere. So, a different test is made:
** The last two letters are capitalized of the first name and last name, but may not necessarily be the same two letters.

** There is 'agreed' in the querystring part of the web address.

If this test passes, PHP is instructed to quit right then and there. CubeCart has actually done essentially nothing at all.

For a legitimate registration, the only trip would be if the customer enters a phone number of 123456. That's not likely.

I have no idea how reCaptcha has been thwarted. But it has and Google is building better methods because of that.

Link to comment
Share on other sites

  • 2 weeks later...
  • 6 months later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...