Category Archives: Code

Code of course.

Cool Perl prompt

#!/usr/bin/env perl

do
  {
     print "perl#: ";
     chop($_ = <>);
     eval($_);
  }
while ($_ ne "exit")

There are times when I get an itching to start writing perl programs and tonight was no exception. I was curious as to how perl handled exceptions and so forth. After doing some reading on line I found a merely 9 lines of code that will serve you as an interactive perl prompt (think typing in python without any arguments.. and you’ll understand what I’m saying, or just give this piece of code a try yourself.)

http://feyd.ldc.usb.ve/docs/perl/practical-perl/www.cs.cf.ac.uk/Dave/PERL/node114.html

mysqldict.py

After taking a few months to dilly about with python and learn the ins and outs of it to a certain extent, I decided to write a program that does dictionary attacks on mysql.

Plain text:
http://zitstif.no-ip.org/mysqldict.txt

Tar archive:
http://zitstif.no-ip.org/mysqldict.tar
MD5Sum: f0e07ca29cc783c6c27f3829f579d37e

The beauty of this program, is that it actually does a test on the remote host and tells you whether or not that the remote host allows remote MySql authentication.

Here’s a quick peek of mysqldict.py in action used inside of a bash shell script (IP addresses hidden of course):

:~/for i in $(httplast | egrep -v "${WANIP}|127.0.0.1|192.168."  | awk '{print $1}' | sort | uniq); do nc -z -w1 ${i} 3306; if [[ "$?" == "0" ]]; then ./mysqldict.py -t ${i}; fi; done
mysqldict.py:
Port 3306 on 115.##.##.#1 appears to be open..
A connection has been made and here are the results of the test:
This host does not allow remote administration on MySQL
mysqldict.py:
Port 3306 on 62.##.##.#1 appears to be open..
A connection has been made and here are the results of the test:
This host is open to MySQL dictionary attacks!
mysqldict.py:
Port 3306 on 66.##.##.#1 appears to be open..
A connection has been made and here are the results of the test:
This host is open to MySQL dictionary attacks!

If you’re wondering what the command ‘httplast’ is, let me explain. I’m too lazy to type out: cat /var/log/apache2/access.log , so I created an alias to do handle this for me.

The tool itself, I feel is pretty self explanatory, but if you have any questions feel free to leave a comment or shoot me an e-mail.

SSH2, How I love Thee

A while ago, I read an article regarding SSH2 and an insecurity that it possessed. Being a person who depends on SSH2, I was highly intrigued about this insecurity.

The insecurity involves with the handling of credentials in memory when a client is connecting to an openssh server. When the client is authenticating to the server, on the server side, the password in memory is in clear text. So, this attack is merely a local one. For one to worry about this attack, they would have to have their openssh server compromised and the would attacker run the shell script that I wrote.

I’m not taking credit for the discovery of this flaw. I merely wrote a program to automate the capture of the ssh client’s credentials. Once I find the discoverer of the flaw, I will post it. Keep in mind that this program isn’t perfect, but it does work.

Here’s the program in plain text:
http://zitstif.no-ip.org/capturessh2.txt

Here’s the program in a tar file:
http://zitstif.no-ip.org/capturessh2.tar

MD5sum: f9ebfe85ff73641f06625a8c21261d4f

#Tested to work on SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
#Tested to work on SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
#Tested to work on OpenSSH 5.2 (protocol 2.0) Fedora 11

If you want to test this on your ssh server, first log into your ssh server and then execute the script with sudo.

Then posing as the victim yourself, login to the same ssh server and do your usual business and then log out.

In the attacker’s console, you will see the victim’s user name and password that the used to authenticate in the ssh server.

Also a quick side note, I’m reminded of a pretty nasty attack on ssh clients that can be performed with Ettercap. It’s known as a downgrade attack. Essentially, instead of the client authenticating through the Protocol 2.0 version of SSH, the attacker modifies the traffic in transmit and downgrades it to Protocol 1.0, which is susceptible to password sniffing via Ettercap.

Here’s a link to a tutorial on how to perform this attack:
http://openmaniak.com/ettercap_filter.php

This attack only affects servers that allow ssh 1.0 authentication, ergo it’s not a very high level of threat.

ipchicken.py

If you are one of the very very few to remember a shell script that I wrote a while back that let’s you know your WAN IP address from the command line (ipchicken), I wrote a replacement for it in python. I hope this is useful to you:

ipchicken.py

#!/usr/bin/env python
import re
import urllib
import socket
import sys

#Test that ipchicken.com is up#
var = socket.socket()
try:
        var.connect(('www.ipchicken.com', 80))
        var.close()
except socket.error:
        var.close()
        print "www.iphicken.com seems to be down.."
        sys.exit(1)

var = urllib.urlopen('http://www.ipchicken.com')
var = str(var.readlines())

reg = "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"

for ip in re.findall(reg, var):
        print """Your WAN IP address is: %s \nBrought to you by www.ipchicken.com""" % ip
sys.exit(0)

Also, the beauty behind this, is that all you need is python and it should work on any operating system that supports python.

Of course, if you have dog for Linux, then you can get the same affect with just a quick one liner:

dog http://www.ipchicken.com | egrep -wo "[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}"

http://www.google.com/search?hl=en&source=hp&q=dog+is+better+than+cat+linux&aq=f&oq=&aqi=

Raising Elephants Is So Utterly Boring

“Raising Elephants Is So Utterly Boring”

This is a simple mnemonic for remembering the sequence of keys to press when things go a mess under Linux.

http://en.wikipedia.org/wiki/Magic_SysRq_key

I just recently used the SysRq key on my laptop, which had frozen after I applied some updates through the update manager. Under the condition that I had not known this key combination, I would have had to resort to a hard restart which is harmful to computer hardware and especially file systems.

When my system froze after it had completed its boot sequence, I held FN + ALT + SysRq and then pressed “R E I S U B”. After pressing this key sequence, my system safely restarted.

Here’s a simple shell script to enable the sysrq key for you. (It’s not perfect, but it will get the job done.) Keep in mind that you need to be root when doing this.

#!/bin/bash 

if [[ ! "$(cat /proc/sys/kernel/sysrq)" -eq "1" ]];
 then
      echo "Would you like to enable the SysRq key? (yes|no)";
      read answer;
         if [[  "$(echo ${answer} | egrep 'Y|y')" ]];
          then
              echo "Enabling sysrq..."
              echo "1" > /proc/sys/kernel/sysrq;
          else
               echo "Exiting!";
               exit 0;
         fi
 else
    echo "The sysrq is enabled!";
    exit 0;
fi

I want to thank a friend from Florida who had informed me of this wonderful and useful key.