Security Issue: Fake new user, deletes addresses

  • Posts: 59
  • Thank you received: 0
6 years 4 months ago #93645

I had discussed this issue before in the following thread:

www.hikashop.com/en/forum/4-how-to/78299...oints-questions.html

Every so often we get a fake user injected into the system through what seems to be a backdoor. Doesn't use the registration form, no tracks in the Joomlawatch logs for bots or browsers, nothing suspicious in the redirects log, so creating a new user some other way. I'm new to Joomla and Hikashop, so not sure how they are injecting this new user.

We use Akeeba Admin Tools, so we get the IP of the intruder/fake user and can block the ranges (for what that is worth), and the user is, of course, blocked as far as I can see, before we delete them (not activated since we have confirmation set for registering).

The curious thing is that when this new fake user is created, it also wipes out (or turns off) the stored addresses of the admin user in Hikashop (user ID 1). This is not a 1-time thing. It has happened repeatedly, which tells me that somehow they are accessing and/or affecting the Hikashop address database while injecting this fake user.

We clear out the fake user from the Joomla user manager and check to be sure that user is gone from Acymailing, K2 and Hikashop. We add the addresses back into the admin user in Hikashop (user 1) and they stay showing until we get another fake user injected. It may be a day, or it may be a couple weeks. But when we get a new fake user injected, the addresses for the hikashop admin user (user 1) disappear.

In looking at phpMyAdmin today, it is interesting that deleting the users through Joomla user manager does not remove the address info from the Hikashop address tables for the deleted users. The fake users addresses are all still there.

Even more interesting, the hikashop admin user's addresses are all still there, but they are now flagged as not published.

Perhaps it is a coincidence that the addresses somehow get flagged as not published at the exact same time as someone is injecting a new user through a backdoor. However, it seems to be related in that it has happened repeatedly.

Question: If I delete a user through Joomla's user control, does it not remove the user and their addresses from all of Hikashop? Hate to think that I have to go into phpMyAdmin every time to remove the fake addresses. Don't know if there is a vulnerability if the fake addresses remain in the table.

Not sure what to think about all of this. It does bother me that this hacking is changing data in the Hikashop addresses table. Makes me wonder what else is happening. Sure would appreciate some insight, and also wonder if anyone else experiences this.

Thanks.

Please Log in or Create an account to join the conversation.

  • Posts: 66305
  • Thank you received: 9729
  • MODERATOR
6 years 4 months ago #93650

With that information and looking at the code, I see really only one case where that could be possible:
if someone proceed to the checkout by entering the email address of the admin while the checkout would be in "no registration" mode. In that case, the system doesn't check if the user account already exists and directly unpublish the addresses and allow the user to proceed with the checkout. However, in that case, the admin should automatically get the address of the user who did that in his account. But you seem to say that it's not the case.
I'm not really sure if it comes from that though and if that's really possible.
We would need more information on how you configured your checkout to confirm that theory or infirm it.

You can try to replace the code:

$this->database->setQuery('SELECT * FROM '.hikashop_table('user').' WHERE user_email = '.$this->database->Quote($userData->user_email));
			$this->user_id = $this->database->loadObjectList();
with
$this->database->setQuery('SELECT * FROM '.hikashop_table('user').' WHERE user_email = '.$this->database->Quote($userData->user_email));
			$userInDB = $this->database->loadObjectList();
			if($userInDB->user_cms_id){
				JError::raiseWarning('', JText::_('EMAIL_ADDRESS_ALREADY_USED'));
				return false;
			}
			$this->user_id = $userInDB->user_id;
in the file administrator/components/com_hikashop/classes/user.php
That will make sure that it is not possible for someone to unpublish addresses on the registration checkout whatever the config.

Please Log in or Create an account to join the conversation.

  • Posts: 59
  • Thank you received: 0
6 years 4 months ago #93651

Thanks, Nicolas. I'll try that.

We don't see any tracks of anyone using the shopping cart (with joomlawatch), nor see any new carts created. We don't have the site set to no registration. Using registration with email confirmation, reCaptcha. We don't see the hacker's IP in joomlawatch at all, but do get it captured with Admin Tools when they create the new user. They are also filling in the normal data for hikashop addresses, etc. as opposed to the joomla more extensive registration input, so I am guessing they must know it is a hikashop install ??? (again, I am VERY new to joomla/Hikashop). I see that when the user was injected, info was put into the record for hikashop address info.

Example from the table (starting with the title field):

NULL Susankph NULL Susankph NULL Georgia|Mtskheta,Tbilisi
Slovakia|Nove Mesto nad Vahom,Liptovsky Mikulas,Zi... China|Lianyungang,Lijiang,Shangzhi,Hami,Sog Xian,M... NULL NULL state_North_Dakota_4290 country_United_States_of_America_223 1 NULL 1

Again, makes me wonder if they can use the cart without it showing in joomlawatch??? Therefore, would the code change be of any use in this case since we don't have it in the no registration mode and it requires email confirmation to register?

Thanks for your thoughts on this. Since it is happening regularly, it does concern me as we try to ramp up that new web store.

Please Log in or Create an account to join the conversation.

  • Posts: 66305
  • Thank you received: 9729
  • MODERATOR
6 years 4 months ago #93690

Is a joomla user account also created for that user ? Is the address linked to that user ? Is the joomla user activated ?

If you aren't in "no registration" mode, then that code won't help.

It's possible that the website was hacked and that the user and address is directly inserted in the database, going around your loggers. But I don't see the purpose of such thing ?
Is the info provided real (or crap added automatically to fill forms by spam robots) ?

Please Log in or Create an account to join the conversation.

  • Posts: 59
  • Thank you received: 0
6 years 4 months ago #93713

Yes, a Joomla account is created. Also a Joomla Contact, an Acymailing entry and the Hikashop account. The hikashop info is linked to the joomla user. The joomla account is not activated, likely because we have email confirmation setup for activation.

The info provided is junk field fillers meant to be close (random city names, etc.), so obviously a script/robo. My previous post had a sample of the data inserted into the H/S address table.

Had a different user insertion last evening (a russian going through france). This time it was logged by joomlawatch (as a BOT, so they did not use a browser). They used the following path:

Home
component/hikashop/user/form?Itemid=XXX
component/hikashop/checkout/activate_page/lang-en
component/hikashop/user/form?Itemid=XXX
component/hikashop/user/register?Itemid=XXX

they then went to the user login page a few times, but could not get in because of the email confirmation required to activate the account. Admin Tools auto blocked them after a few attempts.

So this insertion of a fake user was different than the others discussed previously and could be seen in the logging. That is different than the others where they do not show up in the logging, none of the above pages showed in the logs with the other insertions, and the admin user's H/S addresses were not set to not-published with last night's fake user, unlike the ohers where they are always turned off.

On a related point, I am also a bit confused. If we delete a user in Joomla, should it not delete them and their addresses from Hikashop? I would also think it should delete them from the Joomla Contacts as well, but it didn't.

I am thinking that since the user accounts are not activated, hopefully there is no danger. But being absolutely new to Joomla and Hikashop, I do not know that. I am trying to ensure for our clients that the sites are as secure as possible. It makes me nervous that these injections can not only create a new user, but can change settings in an existing user. Of course, the user affected is always ID 1 since that is what Hikashop assigns the super user admin, so a hacker may know that if the address thing is somehow intentional. Not sure what the point of that would be, but I am not even close to a security expert.

Thanks for your ongoing assistance. Hopefully it is nothing, but it is curious.

Please Log in or Create an account to join the conversation.

  • Posts: 66305
  • Thank you received: 9729
  • MODERATOR
6 years 4 months ago #93743

Hi,

Well, from the example of yesterday night, we can learn that the creation of a fake account and the unpublishing of the admin address is not related. So that's good. No security issue on the registration. The address with the id 1 being unpublished is probably coming for another glitch somewhere and that's probably the only address affected. It would be nice to catch it but we would first need to find a way to reproduce the issue. At leas, that won't affect the security or the use of your website.

If you delete a user who has already done orders in HikaShop, HikaShop does not delete the user nor its addresses since otherwise you would miss that data in the addresses. You would need to first delete the orders for the delete to be done on the hikashop user and its addresses.
I can't comment on Joomla Contacts.

Please Log in or Create an account to join the conversation.

  • Posts: 59
  • Thank you received: 0
6 years 4 months ago #93776

Nicolas,

I think you misread my comments. The newest fake user did not employ the same method to create the user. They came in through the front end and registered with a bot. Their tracks showed up, as would be expected. Thus the results are predictable.

All of the other injections had no tracks. The logging did not show any pages hit by them. Thus it would seem to me that they employed a different method to insert a user into joomla/hikashop. And EVERY time they did this, it turned the flags off for the user 1 addresses in the hikashop address table.

The addresses being flagged off for publication has always happened ONLY when there has been one of these "silent" user injections, which makes me think their script is possibly doing more than just creating a single new user. Not sure what they would be trying to do, since I am not aware of how hikashop and joomla function (being so new to both). But it is troubling that this "silent" injection affects the address table.

On deleting users, none of these fake users have had any transactions or carts. Therefore, if I delete them from joomla and/or hikashop, should that not also delete their address records in the table? Upon deleting these fake users, they do not appear in hikashop customers any longer, but their address info is still in the hikashop address table (looking at that table with phpMyAdmin). Should not that data also be deleted when deleting a user that has no transactions? Otherwise that table will build up with fake, useless data.

Please Log in or Create an account to join the conversation.

  • Posts: 59
  • Thank you received: 0
6 years 4 months ago #93783

I just tried deleting a user directly from hikashop (with no transactions/purchases). The address data was still in the address table after deletion. Would that be correct? Seems like you would have excess and extraneous data in the table. I understand if there were a purchase record, but if they never purchased anything, why would the address record stay in the table?

Please Log in or Create an account to join the conversation.

  • Posts: 59
  • Thank you received: 0
6 years 4 months ago #93790

Also curious if it is a problem that some of these intruders can register a fake user using the hikashop registration form without an email notification being sent to admin of a new user?? Have that set in joomla, but none of the fake registrants triggered the email notification. Is that an issue or is that normal if they are scripting the registration to bypass reCaptcha, etc.??

The intruders who leave tracks for their fake registrations are pretty much using the same path to do it:
Home
component/hikashop/user/form?Itemid=XXX
component/hikashop/checkout/activate_page/lang-en
component/hikashop/user/form?Itemid=XXX
component/hikashop/user/register?Itemid=XXX

or

Home
component/hikashop/user/form?Itemid=XXX
component/hikashop/checkout/activate_page/lang-en

Seems to allow them to bypass reCaptcha and the email notification to admin.

Please Log in or Create an account to join the conversation.

  • Posts: 66305
  • Thank you received: 9729
  • MODERATOR
6 years 4 months ago #93793

HikaShop does not send any admin notification when someone register regardless of the option in Joomla as this is not handled yet.

I recall a bug in previous versions of HikaShop where the user addresses were not deleted when you deleted the user (that's not really a problem though... it just leaves unnecessary data in the database). Maybe you're not using the latest version ?

ReCaptcha, like any captcha protection system, can be bypassed by spam bots. That doesn't mean that there is a problem.

Please Log in or Create an account to join the conversation.

  • Posts: 59
  • Thank you received: 0
6 years 4 months ago #93804

I have the latest version, although I upgraded it from the previous version. We installed just before the upgrade came out. It appears that some features and other things are not working correctly possibly because of the upgrade. Not sure if we should simply reinstall (overwrite) through the extension manager?? Don't want to screw up a working store.

Please Log in or Create an account to join the conversation.

  • Posts: 66305
  • Thank you received: 9729
  • MODERATOR
6 years 4 months ago #93932

Hi,

I did a test on our end and I was able to reproduce the issue. The address is still there when the user is deleted.
I've fixed that and it will be included in next release.

That actually explains the problem.
The issue is when you have a user with the user_id 1 in the database and that you delete another user via joomla without orders. That will unpublish the addresses of the user with the id 1 instead of deleting the addresses of the user you deleted.
So I think that the address disappearing was not caused by the spam registration but by the fact that you were deleting them.

Please Log in or Create an account to join the conversation.

  • Posts: 59
  • Thank you received: 0
6 years 4 months ago #93960

Thanks, Nicolas. Nice to find out what the issue is rather than worrying about some unknown exploit. Good work!

Please Log in or Create an account to join the conversation.

  • Posts: 30
  • Thank you received: 2
1 month 2 weeks ago #307161

In my case delivery adresses are changed to valid other adresses. Adressees can't explain this.
How can I force billing adress = delivery adress, would you know by any chance?
Thomas

Please Log in or Create an account to join the conversation.

  • Posts: 30
  • Thank you received: 2
1 month 2 weeks ago #307162

grafixpress wrote: In my case delivery adresses are changed to valid other adresses. Adressees can't explain this.
How can I force billing adress = delivery adress, would you know by any chance?
Thomas

The adress is changed if a client does not tick "same adress"
Only registered users, self reg.
ReCaptcha
The adress doesn't belog to any registered user, so it must be is injected.
Nice weekend Nicolas

Please Log in or Create an account to join the conversation.

  • Posts: 66305
  • Thank you received: 9729
  • MODERATOR
1 month 2 weeks ago #307178

Hi,

I'm sorry but I don't understand your messages.
Please create a new subject as your issue is different than the issue reported here.
Please also provide a link to the shop and precise step by step instructions to reproduce the issue so that we can understand what is the problem.

Please Log in or Create an account to join the conversation.

Time to create page: 0.056 seconds
Powered by Kunena Forum