Hi All,
My Logwatch was very long today with 404 requests to the Apache server. I dont understand what the person was trying to do by what they were attempting to access. Can anyone explain a method to their madness? The whole things seems weird...
Below
-Jason
------
Requests with error response codes 404 Not Found /!document.body: 1 Time(s) /.exec: 1 Time(s) /.google-analytics.com/ga.js (http://google-analytics.com/ga.js): 1 Time(s) /.player.play: 1 Time(s) /J.cur: 1 Time(s) /Math.pow: 1 Time(s) /VideoJS.isIE: 1 Time(s) /a: 2 Time(s) /apple-touch-icon-precomposed.png: 2 Time(s) /apple-touch-icon.png: 2 Time(s) /blue_bg.png: 1 Time(s) /event.type: 1 Time(s) /favicon.ico: 4 Time(s) /fn.call: 1 Time(s) /lib/flash/mediaroom/video/apple_history/t ... nerds_part1.mp4: 1 Time(s) /lib/flash/mediaroom/video/apple_history/w ... o_macintosh.mp4: 1 Time(s) /lib/js/!==location.host: 1 Time(s) /lib/js/!Fa.test: 1 Time(s) /lib/js/!b.orig: 1 Time(s) /lib/js/!c.data: 1 Time(s) /lib/js/!d.guid: 1 Time(s) /lib/js/!h.guid: 1 Time(s) /lib/js/!h.handler.guid: 1 Time(s) /lib/js/!ia.test: 1 Time(s) /lib/js/!s&&!x.test: 1 Time(s) /lib/js/!t.body: 1 Time(s) /lib/js/$.exec: 1 Time(s) /lib/js/%25d;c.data: 1 Time(s) /lib/js/&&!/!=/.test: 1 Time(s) /lib/js/&&!Ca.test: 1 Time(s) /lib/js/&&!F.call: 1 Time(s) /lib/js/&&!eb.test: 1 Time(s) /lib/js/&&!o.match.ID.test: 1 Time(s) /lib/js/&&!s&&t.body: 1 Time(s) /lib/js/&&$a.test: 1 Time(s) /lib/js/&&Da.test: 1 Time(s) /lib/js/&&Ua.test: 1 Time(s) /lib/js/&&c.css: 1 Time(s) /lib/js/&&c.data: 1 Time(s) /lib/js/&&c.timers.push: 1 Time(s) /lib/js/&&e.old.call: 1 Time(s) /lib/js/&&jb.test: 1 Time(s) /lib/js/&&ta.test: 1 Time(s) /lib/js/+a.guid: 1 Time(s) /lib/js/+c.now: 1 Time(s) /lib/js/,I=J.cur: 1 Time(s) /lib/js/,N.call: 1 Time(s) /lib/js/,a.now: 1 Time(s) /lib/js/,b.find: 1 Time(s) /lib/js/,d=b.css: 1 Time(s) /lib/js/,e=Ia.test: 1 Time(s) /lib/js/,e=d.html: 1 Time(s) /lib/js/,f=c.data: 1 Time(s) /lib/js/,k=c.css: 1 Time(s) /lib/js/,l=c.css: 1 Time(s) /lib/js/,l=qb.test: 1 Time(s) /lib/js/,w=c.data: 1 Time(s) /lib/js/-1?c.map: 1 Time(s) /lib/js/-Math.cos: 1 Time(s) /lib/js/.length,style:/red/.test: 1 Time(s) /lib/js/0&&n.exec: 1 Time(s) /lib/js/0,a.now: 1 Time(s) /lib/js/0?this.bind: 1 Time(s) /lib/js/1&&i.nodeType===9&&!O&&o.match.ID.test: 1 Time(s) /lib/js/1&&x.exec: 1 Time(s) /lib/js/512&&b===t&&!Ca.test: 1 Time(s) /lib/js/:Ja.test: 1 Time(s) /lib/js/:O.call: 1 Time(s) /lib/js/:a.now: 1 Time(s) /lib/js/:c.css: 1 Time(s) /lib/js/:c.data: 1 Time(s) /lib/js/:c.each: 1 Time(s) /lib/js/:f.css: 1 Time(s) /lib/js/:this.die: 1 Time(s) /lib/js/:w.open: 1 Time(s) /lib/js/;Za.test: 1 Time(s) /lib/js/;b.each: 1 Time(s) /lib/js/;b.map: 1 Time(s) /lib/js/;c.curCSS=c.css;c.each: 1 Time(s) /lib/js/;c.data: 1 Time(s) /lib/js/;c.each: 1 Time(s) /lib/js/;c.event.add: 1 Time(s) /lib/js/;d&&h.each: 1 Time(s) /lib/js/;d.filter=Ea.test: 1 Time(s) /lib/js/;d.text: 1 Time(s) /lib/js/;e.call: 1 Time(s) /lib/js/;f.className=c.trim: 1 Time(s) /lib/js/;f=c.data: 1 Time(s) /lib/js/;h.html: 1 Time(s) /lib/js/;j=L.exec: 1 Time(s) /lib/js/;o+=Math.max: 1 Time(s) /lib/js/;r.remove&&r.remove.call: 1 Time(s) /lib/js/;this.each: 1 Time(s) /lib/js/;this.options.complete.call: 1 Time(s) /lib/js/;v!==H&&z.push: 1 Time(s) /lib/js/===a.type?f.push: 1 Time(s) /lib/js/Ba.exec: 1 Time(s) /lib/js/C.add: 1 Time(s) /lib/js/C.push: 1 Time(s) /lib/js/C.test: 1 Time(s) /lib/js/D.pop: 1 Time(s) /lib/js/Fa.test: 1 Time(s) /lib/js/G&&s.call: 1 Time(s) /lib/js/Na.test: 1 Time(s) /lib/js/T.test: 1 Time(s) /lib/js/a&&a.type: 1 Time(s) /lib/js/a,b,this.handle.elem: 1 Time(s) /lib/js/a.call: 1 Time(s) /lib/js/a.nodeType===1&&a!==b&&d.push: 1 Time(s) /lib/js/a.style.display=c.data: 1 Time(s) /lib/js/b&&b.type: 1 Time(s) /lib/js/b.beforeSend&&b.beforeSend.call: 1 Time(s) /lib/js/b.data: 1 Time(s) /lib/js/b.data&&T.test: 1 Time(s) /lib/js/b.map: 1 Time(s) /lib/js/b.type: 1 Time(s) /lib/js/b.url: 1 Time(s) /lib/js/b.url;if(!d)%7Bvar: 1 Time(s) /lib/js/b===b.ownerDocument.body: 1 Time(s) /lib/js/b=b.call: 1 Time(s) /lib/js/c.css: 1 Time(s) /lib/js/c.data: 1 Time(s) /lib/js/c.each: 1 Time(s) /lib/js/c.event.add: 1 Time(s) /lib/js/c.offset.doesAddBorderForTableAndCells&&xb.test: 1 Time(s) /lib/js/d.call: 1 Time(s) /lib/js/d.exec: 1 Time(s) /lib/js/d.guid===C.guid: 1 Time(s) /lib/js/d.push: 1 Time(s) /lib/js/d=k.set: 1 Time(s) /lib/js/e.call: 1 Time(s) /lib/js/e.old: 1 Time(s) /lib/js/e.push: 1 Time(s) /lib/js/e=c.data: 1 Time(s) /lib/js/e=d.nodeType?c.data: 1 Time(s) /lib/js/e=h.get: 1 Time(s) /lib/js/f,a,bb.call: 1 Time(s) /lib/js/f.call: 1 Time(s) /lib/js/f.push: 1 Time(s) /lib/js/f=k.get: 1 Time(s) /lib/js/function(i)%7Breturn%20i.getAttrib ... %20class='TEST': 1 Time(s) /lib/js/h.html: 1 Time(s) /lib/js/h=c.data: 1 Time(s) /lib/js/j.call: 1 Time(s) /lib/js/ja.test: 1 Time(s) /lib/js/m.push: 1 Time(s) /lib/js/n.push: 1 Time(s) /lib/js/o.match.POS.test: 1 Time(s) /lib/js/o=sb.exec: 1 Time(s) /lib/js/q.expr,q.set: 1 Time(s) /lib/js/q=D.pop: 1 Time(s) /lib/js/q=d.exec: 1 Time(s) /lib/js/r=c.map: 1 Time(s) /lib/js/s.call: 1 Time(s) /lib/js/ta.test: 1 Time(s) /lib/js/this,a,b,true,c.attr: 1 Time(s) /lib/js/this,b,d.text: 1 Time(s) /lib/js/this,f,h.attr: 1 Time(s) /lib/js/this,f,h.html: 1 Time(s) /lib/js/this,o,x.attr: 1 Time(s) /lib/js/this,o,x.val: 1 Time(s) /lib/js/this,x,b?r.html: 1 Time(s) /lib/js/this,x,r.attr: 1 Time(s) /lib/js/this.cur: 1 Time(s) /lib/js/this.elem: 1 Time(s) /lib/js/this.elem,this.prop: 1 Time(s) /lib/js/this.find: 1 Time(s) /lib/js/this.get: 1 Time(s) /lib/js/this.one: 1 Time(s) /lib/js/this.type: 1 Time(s) /lib/js/v=h.exec: 1 Time(s) /lib/js/vb.test: 1 Time(s) /lib/js/w,b.url: 1 Time(s) /lib/js/x.val: 1 Time(s) /lib/js/z=A.exec: 1 Time(s) /mediaroom/%E2%80%8Bvideo/%E2%80%8Bkeynote ... cworld_2000.mp4: 1 Time(s) /mediaroom/audio/quarterly_earnings_calls/ ... frame-stamp.png: 1 Time(s) /mediaroom/video/keynotes/expo_paris_2002/keyframe-stamp.jpg: 1 Time(s) /mediaroom/video/keynotes/expo_paris_2003/keyframe-stamp.jpg: 1 Time(s) /mediaroom/video/keynotes/macworld_1998/ne ... frame-stamp.jpg: 1 Time(s) /mediaroom/video/keynotes/macworld_1999/to ... frame-stamp.jpg: 1 Time(s) /mediaroom/video/keynotes/macworld_2002/ne ... frame-stamp.jpg: 1 Time(s) /mediaroom/video/keynotes/seybold_1999/keyframe-stamp.jpg: 1 Time(s) /mediaroom/video/keynotes/wwdc_2010/keyframe-stamp.jpg: 1 Time(s) /mediaroom/video/keynotes/wwdc_2011/introd ... frame-stamp.jpg: 1 Time(s) /mediaroom/video/people/steve_jobs/d8/keyframe-stamp.jpg: 1 Time(s) /num*Math.pow: 1 Time(s) /robots.txt: 5 Time(s) /this.currentSubtitle.text: 1 Time(s)
My Logwatch was very long today with 404 requests to the Apache server. I dont understand what the person was trying to do by what they were attempting to access. Can anyone explain a method to their madness? The whole things seems weird...
Requests with error response codes 404 Not Found /!document.body: 1 Time(s) /.exec: 1 Time(s)
<snip>
Probing your web server for known vulnerabilities/information gathering.
I get that, Barry, what I dont get is what vulnerabilities they think they are going to find.
On Sat, Jun 11, 2011 at 06:14:36PM -0700, Jason wrote:
Hi All,
My Logwatch was very long today with 404 requests to the Apache server. I dont understand what the person was trying to do by what they were attempting to access. Can anyone explain a method to their madness? The whole things seems weird...
Taking one of the probed requests from your email, it turns up a hit for jQuery:
/jquery-1.4.4.min.js
So my guess is they're fuzzing/scanning for potential weaknesses in jQuery...
Steve
On 06/11/2011 10:42 PM steve@echo.id.au wrote:
On Sat, Jun 11, 2011 at 06:14:36PM -0700, Jason wrote:
Hi All,
My Logwatch was very long today with 404 requests to the Apache server. I dont understand what the person was trying to do by what they were attempting to access. Can anyone explain a method to their madness? The whole things seems weird...
Taking one of the probed requests from your email, it turns up a hit for jQuery:
/jquery-1.4.4.min.js
So my guess is they're fuzzing/scanning for potential weaknesses in jQuery...
For those managing web sites it would be good to acquire such scripts and run them in pre-production as system tests. So where do we get scripts such as the one run against Jason's site?
So my guess is they're fuzzing/scanning for potential weaknesses in jQuery...
For those managing web sites it would be good to acquire such scripts and run them in pre-production as system tests. So where do we get scripts such as the one run against Jason's site?
I don't know if this is exactly what you're looking for, but you might check out Nikto http://cirt.net/Nikto2
Barry
On 06/12/2011 10:21 AM Barry Brimer wrote:
So my guess is they're fuzzing/scanning for potential weaknesses in jQuery...
For those managing web sites it would be good to acquire such scripts and run them in pre-production as system tests. So where do we get scripts such as the one run against Jason's site?
I don't know if this is exactly what you're looking for, but you might check out Nikto http://cirt.net/Nikto2
Barry
That's interesting and useful in its way. But I'd prefer to use the same scripts used by the actual crackers/bots. Not only would I be able to test my sites with them, but I'd be able to recognize the probes/attacks when they appear in logs as they did for Jason.
On Sun, Jun 12, 2011 at 1:49 PM, ken gebser@mousecar.com wrote:
That's interesting and useful in its way. But I'd prefer to use the same scripts used by the actual crackers/bots. Not only would I be able to test my sites with them, but I'd be able to recognize the probes/attacks when they appear in logs as they did for Jason.
There are many different scripts out there. I never bothered trying to find the scripts, just keep an eye on the web server logs, /var/log/secure and the syslog.
When you see attempts to fetch things that are not installed on your system it is usually someone up to no good.
Mike
On Sun, Jun 12, 2011 at 1:49 PM, ken <gebser@mousecar.com (mailto:gebser@mousecar.com)> wrote:
That's interesting and useful in its way. But I'd prefer to use the same scripts used by the actual crackers/bots. Not only would I be able to test my sites with them, but I'd be able to recognize the probes/attacks when they appear in logs as they did for Jason.
There are many different scripts out there. I never bothered trying to find the scripts, just keep an eye on the web server logs, /var/log/secure and the syslog.
When you see attempts to fetch things that are not installed on your system it is usually someone up to no good.
Well, I was creating ReWrite rules and directing to 301 when something came in that was not on my system, but it does involve almost daily editing of the rules to keep up with the new invalid requests that I see everyday.
-Jason
On Sun, Jun 12, 2011 at 1:49 PM, ken <gebser@mousecar.com (mailto:gebser@mousecar.com)> wrote:
That's interesting and useful in its way. But I'd prefer to use the same scripts used by the actual crackers/bots. Not only would I be able to test my sites with them, but I'd be able to recognize the probes/attacks when they appear in logs as they did for Jason.
There are many different scripts out there. I never bothered trying to find the scripts, just keep an eye on the web server logs, /var/log/secure and the syslog.
When you see attempts to fetch things that are not installed on your system it is usually someone up to no good.
Well, I was creating ReWrite rules and directing to 301 when something came in that was not on my system, but it does involve almost daily editing of the rules to keep up with the new invalid requests that I see everyday.
-Jason
On Sun, Jun 12, 2011 at 3:19 PM, Jason slackmoehrle.lists@gmail.com wrote:
When you see attempts to fetch things that are not installed on your system it is usually someone up to no good.
Well, I was creating ReWrite rules and directing to 301 when something came in that was not on my system, but it does involve almost daily editing of the rules to keep up with the new invalid requests that I see everyday.
-Jason
Do you edit rewrite rules for every access that would otherwise be a 404 and change it to a 301? If so, what do you redirect them to, and why? Sounds like a lot of work.
My experience has been that they tend to go away if they get 404 (not found) errors. I have noticed, though, that sometimes I seem to get hit with a similar pattern of requests from different IP addresses. Just guessing that multiple different people find the same script or list of stuff to feed a script, and independently try the same requests from different places.
Mike
On Sun, 12 Jun 2011, Mike Williams wrote:
Do you edit rewrite rules for every access that would otherwise be a 404 and change it to a 301? If so, what do you redirect them to, and why? Sounds like a lot of work.
This was covered by me in a blog post some time ago, as to my approach: http://orcorc.blogspot.com/2010/06/reading-logs-part-3-run-your-updates.html
The rationale for having a redirect (offsite, back to the proper's localhost) is to quell noise from the probing, that would otherwise land in Logwatch reports
The effort for maintaining the rules is minor compared to that of wading through logwatch reports full of cruft, multiplied by however many webhosts one reads log files for. As I read a couple hundred logwatch reports each morning, a significant win for me ...
Also, the same probing scripts seem to wash around and after a while, one has most of them identified, and in the redirect file
To get folks started, I've pushed my local packaging of rules 'outside' under a GPLv3+ license in SRPM form at: ftp://ftp.owlriver.com/pub/mirror/ORC/deepsix/
-- Russ herrold
Russ,
On Sun, 12 Jun 2011, Mike Williams wrote:
Do you edit rewrite rules for every access that would otherwise be a 404 and change it to a 301? If so, what do you redirect them to, and why? Sounds like a lot of work.
This was covered by me in a blog post some time ago, as to my approach: http://orcorc.blogspot.com/2010/06/reading-logs-part-3-run-your-updates.html
I used the approach based upon your blog posts.
To get folks started, I've pushed my local packaging of rules 'outside' under a GPLv3+ license in SRPM form at: ftp://ftp.owlriver.com/pub/mirror/ORC/deepsix/
Thanks, I will take a look and compare to what I am doing.
Thanks for being so helpful.
-Jason
On Sun, Jun 12, 2011 at 4:59 PM, R P Herrold herrold@owlriver.com wrote:
This was covered by me in a blog post some time ago, as to my approach: http://orcorc.blogspot.com/2010/06/reading-logs-part-3-run-your-updates.html
The rationale for having a redirect (offsite, back to the proper's localhost) is to quell noise from the probing, that would otherwise land in Logwatch reports
I'm glad I asked, that's a nice technique.
Also, the same probing scripts seem to wash around and after a while, one has most of them identified, and in the redirect file
To get folks started, I've pushed my local packaging of rules 'outside' under a GPLv3+ license in SRPM form at: ftp://ftp.owlriver.com/pub/mirror/ORC/deepsix/
Thanks for the rpm.
Cheers,
Mike
On 06/11/11 6:14 PM, Jason wrote:
I dont understand what the person was trying to do
its not really a person... its a bot script, running on another infected host, thats just blindly trying long lists of known exploits hoping to find a weakness.
-
Barry Brimer -
Jason -
John R Pierce -
ken -
Mike Williams -
R P Herrold -
steve＠echo.id.au