Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

XSS/ BAD BEHAVIOR BLOCK


Debs

Recommended Posts

Hi Debs

 

Your contribution is excellent.

What I'm finding lately is that my site is constantly checked for folders e.g. mysql, pma, phpMyAdmin and so on - known folders

 

How can I block such requests to folders?

Getting the Phoenix off the ground

Link to comment
Share on other sites

  • 2 weeks later...
  • Replies 121
  • Created
  • Last Reply

Thanks for the great contribution. I installed over the weekend and successfully blocked my self several times. Now today I noticed this in my whos online

  00:00:00   Guest    217.67.228.245   09:43:49  09:43:49   (Category)  Yes  Not Found  

  00:00:00   Guest    217.67.228.245   09:43:38  09:43:38   (Category)  Yes  Not Found  

  00:00:00   Guest    217.67.228.245   09:43:31  09:43:31   /MY CATEGORY NAME-c-21_22.html?page=2&sort=2a/admin/file_manager.php/login.php  Yes  Not Found  

  00:00:00   Guest    217.67.228.245   09:43:16  09:43:16   /shipping.php/admin/file_manager.php/login.php  Yes  Not Found  

  00:00:00   Guest    217.67.228.245   09:42:23  09:42:23   /allprods.php/admin/file_manager.php/login.php  Yes  Not Found  

They were not blocked. Do you have any suggestions as to why or what rule to add?

 

Tim

 

edit:

If I add that IP manually and leave a blank line after it, then my site won't load even for me.

Link to comment
Share on other sites

Thanks for the great contribution. I installed over the weekend and successfully blocked my self several times. Now today I noticed this in my whos online

  00:00:00   Guest    217.67.228.245   09:43:49  09:43:49   (Category)  Yes  Not Found  

  00:00:00   Guest    217.67.228.245   09:43:38  09:43:38   (Category)  Yes  Not Found  

  00:00:00   Guest    217.67.228.245   09:43:31  09:43:31   /MY CATEGORY NAME-c-21_22.html?page=2&sort=2a/admin/file_manager.php/login.php  Yes  Not Found  

  00:00:00   Guest    217.67.228.245   09:43:16  09:43:16   /shipping.php/admin/file_manager.php/login.php  Yes  Not Found  

  00:00:00   Guest    217.67.228.245   09:42:23  09:42:23   /allprods.php/admin/file_manager.php/login.php  Yes  Not Found  

They were not blocked. Do you have any suggestions as to why or what rule to add?

 

Tim

 

edit:

If I add that IP manually and leave a blank line after it, then my site won't load even for me.

 

 

Yes I no longer support this as it is not an oscommerce only type protection. But to get ya on the right track...

 

You can match differently to catch anything you want. Just add to or change your htaccess rules.

 

 

For example, try changing to something like this in your htaccess:

 

RewriteRule setup\.php$ bad_conduct/ban.php [NC,L]

RewriteRule .s?file_manager\.php? bad_conduct/ban.php [NC,L]

 

The top rule you already have... but I included it so you know where the rule is located in your .htaccess

 

I am certain others will have better expressions/ matching. Many methods would work.

Link to comment
Share on other sites

#666 should be suffice for a group user to write to its own files.

 

Many of the freebee or cheapo shared servers have misconfigured their permissions to allow files that are #644 to be writable. This is a bad mistake as most would assume that 644 is read only except for the owner.

 

This is allowing attackers, once they have uploaded a few upload files, to POST code directly into the headers of critical files like index.php. The fix is of course to go the 444 route but most users assume that uploaded files would have to be made writable rather than be group writable by default.

 

The contrib I am developing called osc_sec has been running for a bit now and some of the feedback I am getting shows me that this writable issue is quite an automated assumption by some of these spam spiders. One osc_sec user is recieving around 5 or so of these malicious post requests per day to their index.php which previous to patching, was successful in appending shell code into the php code which translated to the dreaded iframe code.

 

The POST header looks something like this:

POST /index.php HTTP/1.1
Referer:
Host: www.somesite.com
User-Agent: Mozila/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MyIE2;
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 185
Cookie: 

Post content:
test=asc+%3D+eval%28base64_decode%28%5C%27ZXJyb3JfcmVwb3J0aW5nKDApO3Nld....[trimmed]....7DQp9DQpkaWUoJzExMTFDSEVDS1NUUklORzExMTEnKTs%3D%5C%27%29%29%3B&B1=Submit

 

Because the attacker has previously used the admin exploit to load an uploader or other malicious code onto the victim site, they are then able to POST into a file header which wouldn't be possible if 644 was read only as it should be (in this case because its a spam spider of some sort, its just an automated post that is coming through around every 2 hours from a toggling list of proxy server IPs).

 

So it seems this type of attack is based purely on the attacker running it by the numbers rather than a specific attack by an individual, hoping to catch a misconfigured server and append their code.

 

Unfortunately there are legit reasons for there to be a POST request made on index.php otherwise you could have singled out those attempts using something like

 

...
RewriteCond %{THE_REQUEST} POST /(index.php)
...

 

So some suggestions are (well actually they are questions more than suggestions) for htaccess blacklisting:

1- Other than filemanager doing its thing, should there ever be a POST request made on the image folder? This seems to be where most of the malicious code is being initially uploaded, probably via the admin exploit using the file manager in older versions? Once the code is uploaded the attacker then POSTs via those files to update header iframe code within the likes of index.php, application_top.php and even header.php, or accesses shell code uploaded into the image folder to pretty much do as they like.

 

Now that I think about it, actually just allowing access to image only via images/.htaccess might be the solution to that. Perhaps an addition to the images/.htaccess that send any requests to .php files to ban.php?

 

2- Is there a way in htaccess to ban the POST data string?

A lot of time has been put in by contrib writers to either filter or blacklist query strings and calls to malicious URL constructions, but not much to deal with POST strings yet the feedback I am receiving points to the POST string as being the majority method being used once malicious files have been uploaded via the admin exploit.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

I am able to concede to the fact that this is an oscommerce forum and this type of contribution is not necessary here. I have seen this mentioned a handful of times even in other contributions. Now, I can not even argue that they are wrong. What works for me doesn't always work for others. I've crossed the 40yo mark and ya know what they say about us and change! These last years software and coding have advanced and many of our old methods from even 4-5 years ago are no longer needed.

 

I would hope that one day oscommerce would come to the point where there was no need for any of these security contributions however until then there is great need for a multiple angled approach. Everyone has their own pet perspectives, those that say that whitelist filtering is the way to go often look down on blacklisting. I think htaccess is crucial to catch the base of many of the types of attacks being levelled at oscommerce, so I think your contrib is very important.

 

The thing to keep in mind, and is often the mistake of almost all developers I have worked with in the past, is that there are more security holes in this script that have yet to be plugged or even found and plugged.

 

To make the assumption that whitelist filtering and fixing the PHP_SELF bug is the end of all the worries (as some do) is arrogance on their part by anyone making such claims.

 

All of the security patch contribs other than yours depend on being included into application_top in order to be successful, yet so much of the after action exploiting is going on with files that are not connected in any way to application_top so that is where htaccess reigns supreme because of its ability to detect and filter requests made on files and folders before those files and folders are accessed.

 

What oscommerce needs is a base security class similar in vain to what FWR Media is working on, but needs to go further than that to one day be the catch all of security addons where even contribs will not work unless they comply to a certain level of code security.

 

Oscommerce is also just going to have to be properly patched in future updates to take care of these issues, where what I see at the moment, is a more scatter gunned approach hoping to catch bad people who may or may not do a specific malicious request.

 

Until then, and that is going to be a long way away, the likes of your contibution, mine and others like FWRs are what is keeping people believing in oscommerce and its variants.

 

But the first defence in any battle when it comes to holding the line while this thing gets fixed, is the front line and htaccess is that. If I can help in any way just ask. ;)

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

I would hope that one day oscommerce would come to the point where there was no need for any of these security contributions however until then there is great need for a multiple angled approach. Everyone has their own pet perspectives, those that say that whitelist filtering is the way to go often look down on blacklisting. I think htaccess is crucial to catch the base of many of the types of attacks being levelled at oscommerce, so I think your contrib is very important.

 

Taipo, I am not a skilled coder and run my shops through the good graces of osC packages and folks that put nice add ons out there. I have installed many security add ons and have been following your oscsec that you have been developing. Is there a forum topic devoted to your add on? I'd like to learn more about it before I install it.

Thank you

I am not a professional webmaster or PHP coder by background or training but I will try to help as best I can.

I remember what it was like when I first started with osC. It can be overwhelming.

However, I strongly recommend considering hiring a professional for extensive site modifications, site cleaning, etc.

There are several good pros here on osCommerce. Look around, you'll figure out who they are.

Link to comment
Share on other sites

I probably should write up a decent instructional. Will do so shortly.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

RewriteRule setup\.php$ bad_conduct/ban.php [NC,L]

RewriteRule .s?file_manager\.php? bad_conduct/ban.php [NC,L]

 

The top rule you already have... but I included it so you know where the rule is located in your .htaccess

 

I am certain others will have better expressions/ matching. Many methods would work.

 

Thanks Debs,

 

I pasted that in there this morning. I am assuming

.s?

is a wildcard.

 

Tim

Link to comment
Share on other sites

Thanks Debs,

 

I pasted that in there this morning. I am assuming

.s?

is a wildcard.

 

Tim

Yes, you can change it or leave it out... or perhaps even decide to just end match. You could probably get creative and cover many with one rule. I haven't looked into that, as I believe you only have to match a few as hackers have a list of known files they will hit and will be quickly blocked. I rarely come to the forums but showed up for a moment... saw some activity, and couldn't resist a quick answer.

Link to comment
Share on other sites

  • 2 weeks later...

Great mod! Have it up and running after suddenly noticing these m32.php and other things on the site trying to get in. My only question is about the http://www.domain.com/bad_conduct/data.html....anyone can see that if the type in the domain, is that a big deal?

 

Wait...one more question..lol. How do you feel about adding a contact email into the ban.php file so that if someone innocent gets banned they have an easy way to contact you to be removed from the ip ban? Would this open up a world of spam to the email address?

Link to comment
Share on other sites

Hmmmm it didn't block this stuff:

 

//catalog/product_info.php/admin/categories.php/login.php?cPath=&action=new_product_preview

//catalog/product_info.php/images/m32.php

 

Is there a way to block them? They're not affecting anything since I have admin renamed and security pro installed but they're still trying. Would love to see them hit the block.

Link to comment
Share on other sites

The key phase in there is

 

.php/login.php

 

If you blacklist that via htaccess then you will block the admin bypass exploit which always no matter how long the string, always calls the login.php after the file it is intending to bypass.

 

For example:

 

www.somesite.com/admin/categories.php/login.php

www.somesite.com/index.php/admin/filemanager.php/login.php

www.somesite.com/accounts.php/admin/index.php/admin/administrator.php/login.php

 

So a rewrite rule blacklisting that phrase would do since the only time .php/login.php is ever called is for malicious reasons.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

The key phase in there is

 

.php/login.php

 

If you blacklist that via htaccess then you will block the admin bypass exploit which always no matter how long the string, always calls the login.php after the file it is intending to bypass.

 

For example:

 

www.somesite.com/admin/categories.php/login.php

www.somesite.com/index.php/admin/filemanager.php/login.php

www.somesite.com/accounts.php/admin/index.php/admin/administrator.php/login.php

 

So a rewrite rule blacklisting that phrase would do since the only time .php/login.php is ever called is for malicious reasons.

 

So how would I rewrite those rules....is this right? :

 

RewriteRule .php/login.php$ bad_conduct/ban.php [NC,L]

RewriteRule images/m32.php$ bad_conduct/ban.php [NC,L]

Link to comment
Share on other sites

So how would I rewrite those rules....is this right? :

 

RewriteRule .php/login.php$ bad_conduct/ban.php [NC,L]

RewriteRule images/m32.php$ bad_conduct/ban.php [NC,L]

 

 

I would have thought using \.php/.s?\.php would catch both and any .php/*.php or .php/*/*.php

 

Assuming that .s? can be used as a wildcard in this situation but my knowledge of .htaccess conditions is very sparse

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

So how would I rewrite those rules....is this right? :

 

This looks like it would work

RewriteRule .php/login.php$ bad_conduct/ban.php [NC,L]

 

Test it though, always the best policy.

 

Xpajun, Im not sure you really want to catch every instance of .php/ because in some configurations that is quite commonly called on the catalog side. Whereas in no configurations of oscommerce are .php/login.php called unless for bad intent. So it is probably best to be very specific in this case.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

This looks like it would work

RewriteRule .php/login.php$ bad_conduct/ban.php [NC,L]

 

Test it though, always the best policy.

 

Xpajun, Im not sure you really want to catch every instance of .php/ because in some configurations that is quite commonly called on the catalog side. Whereas in no configurations of oscommerce are .php/login.php called unless for bad intent. So it is probably best to be very specific in this case.

 

 

I can remember you posting about that before - I haven't seen any instances of it yet though,

 

as I said though my knowledge of writing .htaccess conditions is very little but growing daily :D

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

I guess the main point is that it is not dangerous to call files dovetailed together (on unpatched websites) UNLESS login.php is called as well.

 

So a uri call like:

www.somesite.com/admin/index.php/product_info.php/admin/index.php

does not lead to an admin login no matter how many times you try variations of it, except, if login.php was appended:

www.somesite.com/admin/index.php/product_info.php/admin/index.php/login.php

 

Well now you have an admin bypass situation. So in order to reduce the chances of a wrongful ban, and more accurately target the hack attempts, it is better to go after the combination that is actually doing the damage in terms of this specific security hole which is about tricking the $PHP_SELF script to produce the wrong result which can and has only ever happened when /login.php was appended to the target filename.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

I can remember you posting about that before - I haven't seen any instances of it yet though,

 

as I said though my knowledge of writing .htaccess conditions is very little but growing daily :D

 

Nope didn't work. Seems to ban just about everything. When I was looking at my who's online in the admin it even banned me there. LOL.

Link to comment
Share on other sites

Try this Jayman

RewriteRule \.php/login.php$ blocked.php [NC,L]

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

in .htaccess conditions . is a wildcard for any one character .* is a wildcard for any sequence of characters so anywhere you want . to mean a period as in login.php the . must be escaped - login\.php

 

 

so

 

RewriteRule \.php/login\.php bad_conduct/ban.php [NC,L]

 

also removed the $ as this implies that only URLs that end in login.php would be subject to the condition

 

RewriteRule images/.*\.php$ bad_conduct/ban.php [NC,L]

 

this should subject any URL request to any .php in images to the condition

 

 

still learning but getting somewhere - I hope ;)

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

Aren't we all. Well done.

- Stop Oscommerce hacks dead in their tracks with osC_Sec (see discussion here)
- Another discussion about infected files ::here::
- A discussion on file permissions ::here::
- Site hacked? Should you upgrade or not, some thoughts ::here::
- Fix the admin login bypass exploit here
- Pareto Security: New security addon I am developing, a remake of osC_Sec in PHP 5 with a number of fixes
- BTC:1LHiMXedmtyq4wcYLedk9i9gkk8A8Hk7qX

Link to comment
Share on other sites

 

RewriteRule \.php/login\.php bad_conduct/ban.php [NC,L]

 

also removed the $ as this implies that only URLs that end in login.php would be subject to the condition

 

RewriteRule images/.*\.php$ bad_conduct/ban.php [NC,L]

 

this should subject any URL request to any .php in images to the condition

 

 

still learning but getting somewhere - I hope ;)

 

Julian, I am not near up to snuff where you and Taipo are, but I did install Deb's add on and it's been working well. In particular nabbing file_manager.php intruders daily.

 

But so I understand....

 

RewriteRule \.php/login\.php bad_conduct/ban.php [NC,L]

 

will nab intruders tagging a "login.php" anywhere in the tailend of a uri ending in .php, do I have that correct?

 

and

 

RewriteRule images/.*\.php$ bad_conduct/ban.php [NC,L]

 

will nab anyone trying to get into the images folder with a .php extention (followed by whatever else)

 

Is that correct?

 

still learning from others..... :thumbsup:

I am not a professional webmaster or PHP coder by background or training but I will try to help as best I can.

I remember what it was like when I first started with osC. It can be overwhelming.

However, I strongly recommend considering hiring a professional for extensive site modifications, site cleaning, etc.

There are several good pros here on osCommerce. Look around, you'll figure out who they are.

Link to comment
Share on other sites

Julian, I am not near up to snuff where you and Taipo are, but I did install Deb's add on and it's been working well. In particular nabbing file_manager.php intruders daily.

 

But so I understand....

 

RewriteRule \.php/login\.php bad_conduct/ban.php [NC,L]

 

will nab intruders tagging a "login.php" anywhere in the tailend of a uri ending in .php, do I have that correct?

 

and

 

RewriteRule images/.*\.php$ bad_conduct/ban.php [NC,L]

 

will nab anyone trying to get into the images folder with a .php extention (followed by whatever else)

 

Is that correct?

 

still learning from others..... :thumbsup:

 

Steve, like you I am on a learning curve with .htaccess but as I understand it

 

RewriteRule \.php/login\.php bad_conduct/ban.php [NC,L]

 

should nab intruders that have .php/login.php/something_following.php as well as plain .php/login.php

 

RewriteRule \.php/login\.php$ bad_conduct/ban.php [NC,L]

 

will just nab intruders that have .php/login.php but not .php/login.php/something_following.php

 

RewriteRule images/.*\.php$ bad_conduct/ban.php [NC,L]

 

should nab intruders looking for images/xxxxx.php

 

There should be no .php files in your images folder and it would be an idea to protect it with a .htaccess file containing:

 

# $Id$
#
# This is used to restrict access to this folder to anything other
# than images

# Prevents any script files from being accessed from the images folder
<FilesMatch "\.(php([0-9]|s)?|s?p?html|cgi|pl|exe)$">
  Order Deny,Allow
  Deny from all
</FilesMatch>

My store is currently running Phoenix 1.0.3.0

I'm currently working on 1.0.7.2 and hope to get it live before 1.0.8.0 arrives (maybe 🙄 )

I used to have a list of add-ons here but I've found that with the ones that supporters of Phoenix get any other add-ons are not really neccessary

Link to comment
Share on other sites

 

Thanks Julian, I have had the images directory protected for a while, so far so good.

 

But if someone's trying a .php into the images folder then they are up to no good I'd say.

 

My take on Debs concept is if that someone's nosing around using URIs that have no legitimate purpose, she blocked their IP with such code in .htaccess.

 

Earlier in this forum I saw the code for blocking file_manager.php variations. I put that in my system and pretty every day intrusion attempts are identified and blocked. Heretofore, I was unaware of such activity on my sites. Even though long ago I removed file_manager.php and there was no (hopefully) no possibility of their success, I was amazed how common these attempts are.

 

I am going to add those rewrites you worked up to my code and see what happens from there. After some testing of course....:)

 

Thank you.

I am not a professional webmaster or PHP coder by background or training but I will try to help as best I can.

I remember what it was like when I first started with osC. It can be overwhelming.

However, I strongly recommend considering hiring a professional for extensive site modifications, site cleaning, etc.

There are several good pros here on osCommerce. Look around, you'll figure out who they are.

Link to comment
Share on other sites

amazing....I have had it up since yesterday and can't believe how many attempts:

 

23-03-11 / 13:00:06 - 95.171.126.17 - /catalog/admin/file_manager.php/login.php

23-03-11 / 14:11:08 - 173.203.126.125 - /admin/file_manager.php/login.php

23-03-11 / 15:07:56 - 72.29.94.177 - /catalog/admin/file_manager.php/login.php

23-03-11 / 17:21:24 - 72.233.113.114 - /admin/file_manager.php/login.php

23-03-11 / 17:36:22 - 94.229.79.75 - /admin/file_manager.php/login.php

23-03-11 / 18:56:42 - 202.229.134.2 - /catalog/admin/file_manager.php/login.php

23-03-11 / 19:12:16 - 67.205.76.76 - /admin/file_manager.php/login.php

23-03-11 / 19:45:41 - 62.142.11.3 - /catalog/admin/file_manager.php/login.php

23-03-11 / 19:45:41 - 62.142.11.3 - /catalog/admin/file_manager.php/login.php

23-03-11 / 20:38:54 - 209.200.244.229 - /catalog/admin/file_manager.php/login.php

23-03-11 / 20:46:57 - 81.19.234.16 - /admin/file_manager.php/login.php

23-03-11 / 20:57:33 - 69.73.179.26 - /catalog/sitemapcategories.xml/admin/file_manager.php/login.php

23-03-11 / 21:01:04 - 87.238.90.186 - /admin/file_manager.php/login.php

23-03-11 / 21:15:34 - 208.99.251.145 - /admin/file_manager.php/login.php

23-03-11 / 21:30:30 - 213.251.169.85 - /admin/file_manager.php/login.php

23-03-11 / 22:49:03 - 69.72.157.131 - /catalog/admin/file_manager.php/login.php

23-03-11 / 23:51:29 - 216.17.105.253 - /admin/file_manager.php/login.php

24-03-11 / 01:02:37 - 67.192.120.211 - /admin/file_manager.php/login.php

24-03-11 / 01:18:13 - 77.232.72.161 - /admin/file_manager.php/login.php

24-03-11 / 01:18:26 - 193.218.152.107 - /catalog/admin/file_manager.php/login.php

24-03-11 / 01:21:05 - 87.229.45.159 - /catalog/admin/file_manager.php/login.php

24-03-11 / 04:11:40 - 202.190.123.20 - /catalog/admin/file_manager.php/login.php

24-03-11 / 04:15:48 - 68.71.33.122 - /admin/file_manager.php/login.php

24-03-11 / 04:15:59 - 94.23.48.205 - /admin/file_manager.php/login.php

24-03-11 / 04:16:08 - 62.193.235.191 - /admin/file_manager.php/login.php

24-03-11 / 04:49:37 - 122.201.80.95 - /admin/file_manager.php/login.php

24-03-11 / 05:04:53 - 200.69.223.195 - /admin/file_manager.php/login.php

24-03-11 / 05:45:56 - 91.121.8.126 - /catalog/conditions.php/admin/file_manager.php/login.php

24-03-11 / 05:49:30 - 66.103.128.12 - /catalog/conditions.php/admin/file_manager.php/login.php

24-03-11 / 06:09:54 - 184.107.137.194 - /catalog/admin/file_manager.php/login.php

24-03-11 / 06:19:00 - 62.75.204.249 - /admin/file_manager.php/login.php

24-03-11 / 06:24:58 - 98.100.212.162 - //images/m32.php

24-03-11 / 06:56:25 - 212.54.128.17 - /admin/file_manager.php/login.php

24-03-11 / 07:01:50 - 70.86.145.66 - /admin/file_manager.php/login.php

24-03-11 / 07:18:18 - 78.85.117.182 - /catalog//images/image_resizer.php

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...