Archive for category /dev/urandom
Vulnerable systems setup
Posted by scriptjunkie in /dev/urandom, Vulnerabilities on September 19, 2012
I frequently get asked how to set up a test lab to practice hacking on… So I looked through some release timelines and oldversion.com postings to figure out which versions of your favorite browser, plugins, and PDF reader would be installed if you had up-to-date versions of each on January 1st of the past three years, and where you can get them from. Enjoy.
Fragerizer – profile-guided load-order disk optimizer
Posted by scriptjunkie in /dev/urandom on September 14, 2011
A full load of the Metasploit GUI with database entails accessing almost 10,000 objects on disk. Even if you defragment your hard drive, you still wait for the access time of the disk to seek and access each file.
It would be faster if each file and directory was laid out on disk in the order that it would be accessed to load more quickly. So I wrote fragerizer, a smallish utility to perform that arranging for you. And invented a new word:
Fragerize. v. To defragment and arrange files & directories sequentially on disk in order of use.
Original Source Forgery
Posted by scriptjunkie in /dev/urandom, webapps on September 8, 2011
If you were looking for vulnerabilities on a website, you might open up the original page source looking for commented-out code, javascript source, hidden forms, etc. If you suspected an XSS attack on your own site, chances are you might right-click on the page and view source to check for unwanted scripts. If you needed to register for CTP, hack this site, or read the snarky comments in the HTML of www.defcon.org, you would probably need to view the page source.
This is all based on your assumption that when you right-click on the page and select “View Source” the text you see is the HTML source that the server sent to your browser when it requested the URL in your address bar. Unfortunately if you assumed this, you would be wrong […]
Shells, terminals, and sudo mitm
Posted by scriptjunkie in /dev/urandom on April 14, 2011
In many situations, you can find yourself with a simple shell, able to read and write stdin/stdout, but some command that you are using requires a full terminal. Example: you got a netcat shell on a server or you’re writing a web application with popen() calls, etc. If you need to execute a command through […]
Screwing with Nmap
Posted by scriptjunkie in /dev/urandom on August 20, 2010
It is always interesting to me to see what defense can be put up against tools used by attackers/pen testers. I don’t believe there are any public exploits against Nmap (Secunia is not aware of any at least) and I doubt I could find a useful one against a basic scan. On the other hand, […]
Sessionthief
Posted by scriptjunkie in /dev/urandom on July 17, 2010
Another little project I put together a couple of years ago is sessionthief. When I need to quickly demonstrate the insecurity of open wireless networks, this is my first choice, as it has the ability to immediately hack into most websites another user on the same LAN is logged into. It performs HTTP session cloning […]
XSS, no really
Posted by scriptjunkie in /dev/urandom, Exploits, webapps on April 15, 2010
XSS tends to get the eyeroll treatment from security pros since a) it’s everywhere. 2 min of looking for an example on the GOP website, and tada: http://www.gopstore.com/cgi-bin/rnc/scan/st=db/co=yes/sf=prod_group/se=stick%3Cimg%20src=0%20onerror=%22alert%281%29%22%20%3Eer/op=eq/tf=description/ml=12/sp=1stickers.html b) your 8-year-old kid can find it after about 2 minutes of instruction c) it doesn’t give you a shell (directly) But it still works. And it […]
Security advice
Posted by scriptjunkie in /dev/urandom on March 21, 2010
Great post from rsnake; pointing out a Microsoft Research paper (So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users ) on how security advice often does more harm than good. http://ha.ckers.org/blog/20100317/effectiveness-of-user-training-and-security-products-in-general/ I have always disagreed with password policies. There is no gain to most strict password policies over […]