Goonda.Org: Keep It Simple, Stupid.

Perl tip: URL Decode and Encode

goonda — Tue, 18 Mar 2008 03:22:31 GMT

Here's a quick perl tip on how to URL Decode and Encode:

To encode a string to be placed in a URL:


$string =~ s/([^A-Za-z0-9])/sprintf("%%%02X", ord($1))/seg;

To decode a URL-encoded string:


$string =~ s/\%([A-Fa-f0-9]{2})/pack('C', hex($1))/seg;

Bash Pitfalls

goonda — Mon, 17 Mar 2008 02:43:59 GMT

Found this great Wiki on Bash Pitfalls today which should help avoid common bash scripting errors.

Upgrading firmware on a Linksys WRT54GS to DD-WRT

goonda — Sun, 16 Mar 2008 22:20:58 GMT

Recently I upgraded my old linksys WRT54GS from the Linksys suppled firmware to the spiffy DD-WRT linux-based distribution so I could more effectively troubleshoot problems with my pain-in-the-ass cable modem service. Since Linksys has gotten purchased by a certain networking giant, each subsequent hardware revision of the WRT54G/WRT54GS series has gotten smaller and smaller amounts of RAM and Flash. The most plausible reason for crippling these $40-$50 dollar routers is that with an alternate firmware like DD-WRT, suddenly these cheap boxes are capable of much greater functionality like Quality-of-Service (QoS) bandwidth management, policy routing, IPv6 support, wireless captive portal, login access via SSH/telnet, third party packages, and much more. In other words, they might be able to start cannibalizing the revenue stream from their more expensive big brothers.

Luckily, the router I had was WRT54GS revision v1.1 which has a whopping 32M of RAM and 8M of flash which can run the DD-WRT standard distribution. Make sure to very carefully check the supported devices list to make sure your router is supported before you start, so you don't brick your router!!

Before beginning, make sure to review the DD-WRT Installation Wiki.

Upgrading to the DD-WRT Standard distribution dd-wrt.v23_sp2_standard.zip
was a two step process. When you unzip the zipfile, pay special attention to the file labeled 'hwsupport.txt' as it may contain special instructions for your hardware. In my case it stated:


3.) Linksys WRT54G/GS (any version) flashing notes:
---------------------------------------------------
-For upgrading from the original Linksys firmware, please use the generic mini version (dd-wrt.vXX_mini_generic.bin) and flash
 it from the web GUI interface.  After this first flashing you can change to any other distribution, if you want.
-For flashing via the web GUI interface, always use the included 'generic' binaries. The other Linksys router specific binarie
s are only meant for tftp upgrades.

This meant I had to go back and download the Mini distribution dd-wrt.v23_sp2_mini.zip
from the website and flash that first. The flashing process was uneventful, brought up the web interface from the standard linksys distribution and selected the mini distribution above. Flashing took a minute or two, and then rebooted into the DD-WRT mini distribution. The default login is root with a password of admin.

Initially the web interface would not come up although I could ping the router which caused me some fear I had bricked it. However after disconnecting the power cable while holding the reset button (See also DD-WRT Reset and Reboot ) did the trick and I was able to bring up the web interface.

Then I was able to select the standard DD-WRT distribution and using the same web process to upgrade. After the last reboot I was able to login to my new more capable router!

I've been having some fun playing with SNMP, Macupd, rflow, SSH, the flash filesystem (jffs2), and other items which will be subject of future blog entries. Happy hacking!

Brute force HTTP Basic authentication with authforce

goonda — Mon, 10 Mar 2008 23:54:47 GMT

Authforce is a very fast tool for brute forcing HTTP Basic Authentication protected URLs. In HTTP Basic authentication the username and password is Base64 encoded and passed along with the HTTP headers from the client to the HTTP server. This means that the credentials are passed over the network in plaintext and is vulnerable to eavesdropping by an attacker. Despite this weakness, it is still quite widely used - for example access to the default Tomcat manager page is protected by HTTP Basic by default.

When a client requests a HTTP Basic-protected resource, the web server will challenge with a HTTP 401 Authorization Required (See www.w3.org's page for a listing of all HTTP codes) which causes a username/password dialog to pop up in your browser. Now you've identified the target URL for authforce to run against.

Authforce needs a list of usernames, a list of passwords, and target URL to work. Here's an example:


authforce --verbose --beep --logfile=aftest --username-file=users --password-file=words http://192.168.1.100/tmp

authforce will show you the current username and password being tried in realtime. If it gets a match you will see something like this:


match [goonda:mysecretpass]

Note that authforce will work against both http and https URLs, however you will need to add the --no-ssl-fail option if the site uses self-signed certificates. Happy Hacking!

Setup an SSL tunnel with stunnel 3.x

goonda — Sat, 08 Mar 2008 01:29:28 GMT

Stunnel is a very handy utility for wrapping virtually any service in SSL. In a pentesting perspective its especially handy if you want to use a tool which only speaks HTTP (e.g. a perl LWP script which you are too lazy to make speak SSL, or want to make manual HTTP requests adhoc ;). We can setup a tunnel to our target SSL webserver, and have it bind to a local port we can use for access. NOTE: This only applies to stunnel version 3.x, 4.x uses an stunnel.conf file instead of command line switches.

For example, if our target webserver is called example.foo.com, with a webserver running SSL on port 443, we would run the following command to bind to a local high port e.g. 10666. If you attempted to bind to a local port below 1024, you would have to run this command as root:


stunnel -d localhost:10666 -c -r example.foo.com:443

To confirm that its working, first check the log (usually /var/log/messages, but /var/log/daemon.log on my system).


Mar  7 20:20:32 localhost stunnel[22933]: Using 'example.foo.com.10666' as tcpwrapper service name
Mar  7 20:20:32 localhost stunnel[22933]: stunnel 3.26 on i486-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.
9.8c 05 Sep 2006
Mar  7 20:20:32 localhost stunnel[22934]: FD_SETSIZE=1024, file ulimit=1024 -> 500 clients allowed

So now our stunnel daemon process is listening on localhost, port 10666, ready to service our requests! Lets try it out by doing a simple HEAD request on the target webserver:


user@host# nc localhost 10666
HEAD / HTTP/1.0

HTTP/1.1 403 Forbidden
Date: Sat, 08 Mar 2008 01:12:44 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1

Excellent! I have also run password crackers like hydra through stunnel without problems, so it can take a beating. Happy Hacking!

Archive pages on Linux and Wireless (802.11b) are now up!

goonda — Thu, 06 Mar 2008 03:06:34 GMT

I haven't updated my old Linux & Wireless (802.11b) pages in at least five years (2003) but somehow these wacky people on the Internet still want to read about my ancient experiments getting various wireless cards to work under linux. Your mileage may vary, and I don't vouch for that info anymore. Heck, these pages don't even talk about 802.11g or any linux distro newer than Redhat 9!

Please continue to check the Wireless section of this blog for new developments. I will be posting soon about DD-WRT on my linksys(es)!

In the meantime if you want to read about getting aironet, lucent, or prism2 cards to work under linux or the collection of links on wardriving, wep cracking, etc, check it out below at:

Goonda's Old Timey Wireless Shack

Y'all come back now, y'hear?

OpenBSD pf tip: Examining pf logs

goonda — Thu, 06 Mar 2008 00:21:57 GMT

OpenBSD's pf was ported to FreeBSD and made part of the base system in FreeBSD 5.3, which caused spontaneous combustion in the minds of firewall geeks everywhere. I don't want to start a flamewar, but prior to FreeBSD 5.3, pf was just about the only feature in OpenBSD that I was really jealous of as its probably the most advanced open-source firewall available.

Once enabled, if pf is configured to log, will use the pflog0 pseudo-device to log packets in libpcap format. This means that trusty tcpdump can be used to view your firewall logs in realtime, like so:


[root@phat /var/log]# tcpdump -n -tttt -e -i pflog0
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
2008-03-05 20:40:30.293906 rule 12/0(match): pass in on sis0: 192.168.226.140.24951 > 192.168.1.100.22: S 657096168:657096168(0) win 64512 
2008-03-05 20:40:30.322713 rule 13/0(match): pass out on sis0: 192.168.1.100.58585 > 192.168.1.1.53:  47450+[|domain]

If you wanted to read an existing pf logfile rather than in realtime, use the same arguments to tcpdump as you would normally use to read a pcap file. In this example, I'm specifically looking for blocked igmp traffic:


[root@phat /var/log]# tcpdump -n -tttt -e -r pflog.0 igmp|head -5
reading from file pflog.0, link-type PFLOG (OpenBSD pflog file)
2008-03-05 19:00:52.405159 rule 2/0(match): block in on sis0: 10.1.49.2 > 224.0.0.1: igmp query v2
2008-03-05 19:01:26.748751 rule 2/0(match): block in on sis0: 10.1.49.2 > 224.0.0.1: igmp query v2
2008-03-05 19:03:01.698925 rule 2/0(match): block in on sis0: 10.1.49.2 > 224.0.0.1: igmp query v2
2008-03-05 19:03:36.042609 rule 2/0(match): block in on sis0: 10.1.49.2 > 224.0.0.1: igmp query v2
2008-03-05 19:05:11.018437 rule 2/0(match): block in on sis0: 10.1.49.2 > 224.0.0.1: igmp query v2

How to prevent image hotlinking with mod_rewrite

goonda — Tue, 04 Mar 2008 17:29:15 GMT

mod_rewrite is a powerful module for Apache for performing URL rewriting on the fly. However sometimes if your regex kung-fu is not up to par, it can be a frustrating and hair-pulling exercise to figure out why your rewrite rules are not working. The solution is to add a couple logging lines into your httpd.conf or vhost stanza:


RewriteEngine On
RewriteLog "/var/log/apache/rewrite_log"
RewriteLogLevel 9
RewriteCond etc.

Once you've debugged your problem, its advisable to take these lines out as they can generate A LOT of logs. Another thing I noticed is that these RewriteLog directives only seem to work when placed in the main httpd.conf, not in .htaccess files despite "AllowOverride All".

I was trying to prevent hotlinking on this site. Basically that means someone who is linking directly to my images (and not to the page in which it is displayed). Essentially this amounts to bandwidth theft. To prevent this, I implemented the following mod_rewrite rules in .htaccess:


RewriteEngine on
RewriteCond %{REQUEST_FILENAME} \.(gif|jpg|js|css)$ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?goonda.org/.*$ [NC]
RewriteRule \.(gif|jpg|js|css)$ - [F]

This code prevents any non-blank referrer which does not originate from my website (goonda.org) to receive a 403 (Forbidden) message. Works great!

OpenSSL tip: How to simply encrypt a file

goonda — Tue, 04 Mar 2008 01:16:03 GMT

As part of a project at work recently, I had to figure out how to easily encrypt a file for one of our brain-dead developers. Luckily for me the excellent OpenSSL Toolkit was available on the Unix host. Here's how you do it:

To encrypt a file:

openssl enc -aes-256-cbc -salt -in file.txt -out file.enc

To base-64 encode it, simply add the -a switch (for 'ASCII'):

openssl enc -aes-256-cbc -a -salt -in file.txt -out file.enc

The encryption operation requires that you supply a passphrase.

To decrypt the same file:

openssl enc -d -aes-256-cbc -in file.enc

To decrypt base-64 version, you guessed it, add -a flag :

openssl enc -d -aes-256-cbc -a -in file.enc

The passphrase will be prompted for. You can also supply the passphrase on the command line using the -pass option, or read the passphrase from a file using -pass file:/path/to/file.

Neato. A lot more cool tips at the OpenSSL Command-Line HOWTO.

Sure beats reading the heinously long and complex man pages for openssl! Now we really need a good way to be able to do this for batch jobs *without* having to store the passphrase in cleartext.

cURL tip: How to do a simple HTTP POST

goonda — Tue, 04 Mar 2008 01:12:56 GMT

cURL is a very useful utility to perform HTTP/HTTPS operations from the command line. Many times during a web application pentest you need to send an HTTP POST to a login form (e.g. brute force a login to the site). Here's the very simple way to do it, assuming you the form parameters are called username and password.

curl -d "username=SOMEUSER&password=SOMEPASS" -k https://some.website.com/loginform.jsp

The "-d" indicates you are including data for a POST, the -k says ignore SSL certificate warnings from the remote site.

Using curl is really only good for doing quick spot checks, to do large scale brute forcing I'd recommend using THC Hydra, the super useful perl module libwww-perl aka LWP, or Nessus which has incorporated Hydra. On Windows, Brutus works.