Bunchadogs
Perch
Can anyone help translate a few items I found in my Access Logs?
Is the middle one the server POSTing?
Is the middle one the server POSTing?
Help translating log files
- Thread starter Bunchadogs
- Start date
Bunchadogs
Perch
This looks like the very beginning of the activity:
Yes that is all issuing POST requests.
Here's what happens, and it is hard to know exactly what and when, as files get there in various ways, many times we've seen them included as part of a template or addon, but other times via an insecure uploader they get put there, and sometimes even items like an old copy of FCKEditor, and it doesn't even have to be on the specific domain itself it could be on another domain in the account with FTP access.
Once the POSTS start hitting it it could be a matter of defacing a site, uploading more such files (very common I've seen 'backup' exploitable files littered around after what seems to be a minor case of exploit then turn large by extra files dropped around in 'small' case)
I've even seen them go months untouched on some domains with little to no hit or changes before even being hit again all of a sudden to be hit and abused by a script or bot network all at once to use a long dormant file, very sophisticated in many ways.
For example I found a domain just 2 days back that was having some extra files in it that looked suspect, I got into the logs and found POSTs against a very small asp upload file that was placed there in July 2013, and since there were not many hits on this site I was able to compile its complete log history and review it quickly and determine a core file in their admin system as fckeditor upload exploited (I stopped that at some point in 2013 when reported), but missed this little file there which was used now. It was being used to 'silently' upload other items over 7 months later with not a hit between. That type of activity is hard to track and trace out, but it is being done as I've seen it.
The code itself we can't really stop or block from working, it is a perfectly legit function and it is something customers may use, but it can be used for bad if someone intends as well.
My suggestion for anyone with an upload function they build custom (CMS systems ready made a different matter) would be to make the point of upload totally unscriptable, meaning the drop point for the uploads allows no sort of scripting at all so even if someone gets a script uploaded it won't be capable of running.
Here's what happens, and it is hard to know exactly what and when, as files get there in various ways, many times we've seen them included as part of a template or addon, but other times via an insecure uploader they get put there, and sometimes even items like an old copy of FCKEditor, and it doesn't even have to be on the specific domain itself it could be on another domain in the account with FTP access.
Once the POSTS start hitting it it could be a matter of defacing a site, uploading more such files (very common I've seen 'backup' exploitable files littered around after what seems to be a minor case of exploit then turn large by extra files dropped around in 'small' case)
I've even seen them go months untouched on some domains with little to no hit or changes before even being hit again all of a sudden to be hit and abused by a script or bot network all at once to use a long dormant file, very sophisticated in many ways.
For example I found a domain just 2 days back that was having some extra files in it that looked suspect, I got into the logs and found POSTs against a very small asp upload file that was placed there in July 2013, and since there were not many hits on this site I was able to compile its complete log history and review it quickly and determine a core file in their admin system as fckeditor upload exploited (I stopped that at some point in 2013 when reported), but missed this little file there which was used now. It was being used to 'silently' upload other items over 7 months later with not a hit between. That type of activity is hard to track and trace out, but it is being done as I've seen it.
The code itself we can't really stop or block from working, it is a perfectly legit function and it is something customers may use, but it can be used for bad if someone intends as well.
My suggestion for anyone with an upload function they build custom (CMS systems ready made a different matter) would be to make the point of upload totally unscriptable, meaning the drop point for the uploads allows no sort of scripting at all so even if someone gets a script uploaded it won't be capable of running.
Just dealing with another case now of someons site being defaced and mad at us for 'blaming it on him' (asked what is the issue, not blame, but we told it is outdated (2009) Joomla install and plugins), and gave the logs of it. He made a rather long retort about how that app was not used for a long time and can't be the issue. Oh but it can, unused apps are really one of the WORST issues in allowing site breakins, because they are not updated and run many vulnerable pages within them.
I'm replying this publicly, and to him privately as well but using it to make a point that just because you think something isn't used anymore doesn't mean it isn't in google, and isn't accessible so it is safe, it is likely very unsafe, and the best way to prevent problems is to DELETE the files that are unused. Never leave stray items behind if possible.
I'm replying this publicly, and to him privately as well but using it to make a point that just because you think something isn't used anymore doesn't mean it isn't in google, and isn't accessible so it is safe, it is likely very unsafe, and the best way to prevent problems is to DELETE the files that are unused. Never leave stray items behind if possible.
Bunchadogs
Perch
ABSOLUTELY!
I personally learned this the hard way, I've spent tons of hours cleaning up a defaced site, and I'm STILL spending tons of time pouring over log files to make sure everything is clear.
I can also attest to the issue of editors and plugins - be EXTRA diligent about plugins for things like WordPress, Joomla, etc. - in my case it was an editor we tested, didn't like, and disabled from the CMS control panel. Disabled DOES NOT equal removed!
Also, to further confirm the more advanced techniques these hackers are using - we wrote a custom plugin for a site. The site was defaced and comprimised, so we removed all the files, re-uploaded the CMS from scratch, checked our custom code, and uploaded the custom plugin again. However, hackers had placed an additional sub directory, and an additional file (with the SAME file name as a valid file) - one single PHP file, and it was ONLY hidden in one sub-directory containing containing our custom plugin. Within 12 hours of copying the files back the hacker accessed this PHP file ONCE, apparently to upload a file. One day later they accessed the new file and uploaded several files. Then, over a weekend, they went to town, completely compromising the site again!
This ONE file was in place for at least 9 months - OUR mistake of using the download files versus a local version lead to a second round of deleting, cleaning, and repairing!
Bunchadogs
Perch
One more question - in the first set of POSTs I posted, there is a POST from the server IP:
173.0.129.96 - - [20/Feb/2014:01:59:46 -0600] "POST /modules/mod_ariextmenu/mod_ariextmenu/seotWaI.php
Is there anyway to tell what caused this or what file was being run that caused this POST?
Most of the other POSTs are all from public IPs (LOTS of Russian based IPs!!!) - so I'm sure it's impossible to tell on those, but this one indicated the server.
Thanks!
BTW - As a small reseller this has been maddening dealing with these issues...but I can't imagine the scale of issues JodoHost must face!
I'm sure there is a LOT of working going on behind the scenes, so THANK YOU for that and good luck!
173.0.129.96 - - [20/Feb/2014:01:59:46 -0600] "POST /modules/mod_ariextmenu/mod_ariextmenu/seotWaI.php
Is there anyway to tell what caused this or what file was being run that caused this POST?
Most of the other POSTs are all from public IPs (LOTS of Russian based IPs!!!) - so I'm sure it's impossible to tell on those, but this one indicated the server.
Thanks!
BTW - As a small reseller this has been maddening dealing with these issues...but I can't imagine the scale of issues JodoHost must face!
I'm sure there is a LOT of working going on behind the scenes, so THANK YOU for that and good luck!
Bunchadogs
Perch
Thanks! Just trying to identify any possible item I may have missed.
I'm still seeing a lot of probing in the logs - virtually all of the attempts have been from Russian based IPs, so it's making it pretty easy to deny them by blocks.
Maybe it will be a quiet weekend...
I'm still seeing a lot of probing in the logs - virtually all of the attempts have been from Russian based IPs, so it's making it pretty easy to deny them by blocks.
Maybe it will be a quiet weekend...