Permalink Reply by nmcbride on September 8, 2010 at 9:15am
Permalink Reply by Ken on October 2, 2010 at 11:12am
Permalink Reply by nmcbride on October 2, 2010 at 2:06pm
Permalink Reply by strandjs on January 7, 2011 at 8:27am
One the topic of ways to mess with attackers.
Ethan Robish, one of our hard working interns, has the unfortunate position of writing python scripts that we request. Lately, Paul and I have been working hard to come up with ways to make life harder for attackers.
So, we had Ethan write a script that is a simple web server that serves up four random links, if you refresh it serves up four more. If you click on a link, it serves up 4 more.
Why?
Run a web crawler at it.
It is simple:
# python spidertrap.py
Then..
$ wget -r 127.0.0.1
There are a number of reasons we did this. First, Ethan rocks. Second, many tester simply run their automated tools over night. This would lead to a very nasty surprise. Finally, if someone was crawling a section of your site and they tripped on this you could generate an alert when it happens.
We also found some very interesting behaviors when we ran a number of commercial scanners against it. Some look for a 404 message and kill the session when it is not found (well done w3af) and other simply freeze. Also, we discovered a number of situations where if you tried to kill the crawl, it killed the whole session.
As with any of the tools we release we encourage you to use caution. I have yet to see exactly how google bot would react. I assume they are smart about these types of things. But angering the google gods may not go well. Rather, I recommend running it on an internal network segment.
Permalink Reply by nmcbride on January 7, 2011 at 8:35am Thanks for sharing John. I'll build this into a plugin for my daemon. :D
P.S. - The hard drive I had the rainbow tables on aparently was mis-handled on my way home from the conference and wasn't working when I got home. How annoying is that!
~Nate
strandjs said:
One the topic of ways to mess with attackers.
Ethan Robish, one of our hard working interns, has the unfortunate position of writing python scripts that we request. Lately, Paul and I have been working hard to come up with ways to make life harder for attackers.
So, we had Ethan write a script that is a simple web server that serves up four random links, if you refresh it serves up four more. If you click on a link, it serves up 4 more.
Why?
Run a web crawler at it.
It is simple:
# python spidertrap.py
Then..
$ wget -r 127.0.0.1
There are a number of reasons we did this. First, Ethan rocks. Second, many tester simply run their automated tools over night. This would lead to a very nasty surprise. Finally, if someone was crawling a section of your site and they tripped on this you could generate an alert when it happens.
We also found some very interesting behaviors when we ran a number of commercial scanners against it. Some look for a 404 message and kill the session when it is not found (well done w3af) and other simply freeze. Also, we discovered a number of situations where if you tried to kill the crawl, it killed the whole session.
As with any of the tools we release we encourage you to use caution. I have yet to see exactly how google bot would react. I assume they are smart about these types of things. But angering the google gods may not go well. Rather, I recommend running it on an internal network segment.
Permalink Reply by nmcbride on January 7, 2011 at 9:13am One other quick comment, my distro and I'm sure some others have switched to python3. I edited spidertrap.py and made it work for python3. Maybe someone other than myself will find it useful.
~Nate
Permalink Reply by strandjs on January 7, 2011 at 8:41pm Do you have a working version of the framework you can share?
I would love to see it.
John
nmcbride said:
One other quick comment, my distro and I'm sure some others have switched to python3. I edited spidertrap.py and made it work for python3. Maybe someone other than myself will find it useful.
~Nate
© 2013 Created by strandjs.
Powered by