Monday, December 27, 2010

A Database Error Occured!!

I was asked to look at a site to see if there was any malicious content on the site but found none. However, it was vulnerable to XSS but I was looking for something additional. I decided to input data into the form field a little at a time and finally was able to get the site to "break." By inserting thousands of characters into the form field the application returned "A Database Error Occurred." Contained in the error message was the select statement:

"INSERT INTO `table`(`first_name`, `gender`, `id`, `content`) VALUES('0123456789............X100????', '......', '.....', '.....')

Just goes to show that trying to send a large amount of chars through a form field is a great way to see how things are handled by the application.

Wednesday, December 8, 2010

RE: Stupid iptables

So, something I need to remember about iptables is that you ALWAYS have to ACCEPT traffic on a port BEFORE you do anything with it. Example.
If you want to have vnc port 5902 to be forwarded to a nat'ed machine on port 5901 you will have to do the following:
iptables -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5901 -j ACCEPT
ONLY AFTER you have ACCEPTed the traffic can you then forward the traffic
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3389 -j DNAT --to-destination 192.168.122.2:3389
Again, don't forget to ACCEPT traffic before you forward it on.

Wednesday, December 1, 2010

Stupid iptables

So, come to find out you are not supposed to restart iptables after making a change. When you make a change in iptables you should issue the following command as root in order to have the changes take effect:

iptables-restore < /etc/sysconfig/iptables

Of course, the location of the iptables may vary from one system to another. The above was done on a centos system and is basically the equivalent of reloading the config files in apache.