This auxiliary module for Metasploit does a simple HTTP GET or POST and returns the result, be it a file and error - whatever!

Get it here: Metasploit Simple HTTP

Rename the file to .rb and install in the aux directory of your Metasploit installation.

If you need a PUT example, Carnal0wnage has a good module on his blog.

Paros is a great little tool, however it can leave traces of its use due to an altered User-Agent header. (Adding Paros/x.x.x at the end of the UA, where x is the version). This can lead to problems some of which, including this fix, are detailed at Security Ripcord and Armor.

To remove this download the source and edit line 80 of Constant.java from

public static final String USER_AGENT = PROGRAM_NAME + “/” + PROGRAM_VERSION;

to

public static final String USER_AGENT = “”;

and recompile.

This should remove the obvious traces!

I received my PinSentry from a certain UK High Street bank today, and so far I don’t see where it’s going. This device, produced by Gemalto (http://www.gemalto.com//press/archives/2007/04-18-2007-Barclays.pdf) allows two factor authentication using a customers ‘Chip and Pin’ card.

This doesn’t really change anything as the numbers generated by the device (at least in identify mode) can be created one by one offline, written down and then later used sequentially. I’ve seen enough people with pin numbers on Post-It’s attached to their cards to know that it won’t be long before the notes also contains PinSentry numbers. FaultyFlipper has some good discussion of peoples feelings towards the devices as well as the reasons it may have been introduced.

I’ve had a quick look at the numbers generated, and they seem to follow a sequential pattern of random increments. A very quick phase-space analysis of one hundred numbers from the device shows no discernable patterns, but more numbers are needed to carry this out thoroughly.

If anyone is interested in sample output from the device, I can supply the numbers I have used for testing. Likewise if you’d like to supply me with some numbers (and not any personal details) let me know.

Facebook stops automatic e-mail harvesting, by saving each e-mail address on a profile as an image. It is possible to read some of the images with a certain level of acuracy, but the effort required just isn’t worth using OCR alone.

Using some fuzzy matching, its possible to get a rough list of addresses for a domain, but manual verification is needed for each address found.

The scripts below can be used to train GOCR on facebook images, and can then attempt to pick addresses matching a certain domain from a directory of images.

The scripts are Training Script here and Matching Script here. You’ll need GOCR installed, String::Approx, and the ability to ignore silly Perl.

First download a selection of Facebook E-Mail images, we’ll use these with the training script to give GOCR something to go on.

Then run the matching script on the images you wish to convert, it’ll do some fuzzy matching if you give it domain to look for.

If I can improve this, I’ll try and automate it all a little more and work out some stats.

A Linksys WRT54G provides a cheap and easy linux platform in a small package. I use the DD-WRT firmware available from www.dd-wrt.com. It also provides an easy way of enabling IPv6 access to your network

To enable IPv6 you first need to create an account with a tunnel provider such as SiXXs. A guide to doing this can be found at the Sixxs site. This gives you a remote endpoint for your IPv6 in IPv4 tunnel.

Once the account is setup enable IPv6 on the router via the “IPv6 Support” option under Administration, and then the Management tab.

The following script added to the routers startup config will start the tunnel when the router is rebooted.

ip tunnel add sixxs mode sit local aaa.aaa.aaa.aaa remote bbb.bbb.bbb.bbb
ip link set sixxs up
ip link set mtu 1280 dev sixxs
ip tunnel change sixxs ttl 64
ip -6 addr add 2051:4bd1:2002:9b::2/64 dev sixxs
ip -6 ro add default via 2001:4bd0:2000:9b::1 dev sixxs

aaa.aaa.aaa.aaa - A local, externally accesible IPv4 address.
bbb.bbb.bbb.bbb - The IPv4 address of the pop to connect to.

2051:4bd1:2002:9b::2/64 - Local IPv6 address.
2051:4bd1:2002:9b::1/64 - Remote IPv6 address.

Once the tunnel has been working for a week. SiXXs will allow you to assign a subnet to it that you can distribute using Radvd.

The Where-Fi data has been uploaded, and a pre-alpha, version is available at http://www.remoteroot.net/wifi.

You’ve been warned, its buggy.

More updates soon.

We’ve been gathering more data for the Where-fi service, in under three hours of driving around a sub-section of Reading we have 2000 plus access points.

This broke the architecture we had for displaying them, so it’s currently down.

A Linksys WRT54G provides a cheap and easy Linux platform in a small physical package. I use the DD-WRT firmware available from www.dd-wrt.com.

Dynamic Network Address Translation maps several internal addresses to a single external address. All connections appear to come from that address. It is desirable sometimes to have static NAT where several external addresses that are forwarded to internal hosts.

For example:

195.167.182.123 -> 10.0.0.1
195.167.182.124 -> 10.0.0.2
195.167.182.125 -> 10.0.0.x

It may be useful to have a “catch all” address that other addresses can be translated to, this is shown in the last line of the example above.

Firstly add the external aliases to the external interface of the WRT54G, which is vlan1.

ifconfig vlan1:1 195.167.182.124 netmask 255.255.255.248 broadcast 195.167.182.127
ifconfig vlan1:2 195.167.182.125 netmask 255.255.255.248 broadcast 195.167.182.127

The catch all address is already specified as the routers external address.

The following IPTables commands will add NAT for these addresses, and ensure all other traffic is translated to the main address.

# Default accept all.
iptables -P OUTPUT ACCEPT
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT

# Clear all chains.
cat /proc/net/ip_tables_names | while read table; do
iptables -t $table -L -n | while read c chain rest; do
if test “X$c” = “XChain” ; then
iptables -t $table -F $chain
fi
done
iptables -t $table -X
done

# Reset counters.
iptables -Z

# Allow new connections, to and from the router.
iptables -A INPUT -i lo -m state –state NEW -j ACCEPT
iptables -A OUTPUT -o lo -m state –state NEW -j ACCEPT
# Allow established and related connections.
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

# Nat mapping for 195.167.182.123 -> 10.0.0.1
iptables -t nat -I PREROUTING -i vlan1 -d 195.167.182.123 -j DNAT –to-destination 10.0.0.1
iptables -t nat -I POSTROUTING -o vlan1 -s 10.0.0.1 -j SNAT –to-source 195.167.182.123

# Nat mapping for 195.167.182.124 -> 10.0.0.2
iptables -t nat -I PREROUTING -i vlan1 -d 195.167.182.1241 -j DNAT –to-destination 10.0.0.2
iptables -t nat -I POSTROUTING -o vlan1 -s 10.0.0.2 -j SNAT –to-source 195.167.182.124

# NAT all other connections.
iptables -t nat -A POSTROUTING -o vlan1 -s 10.0.0.0/24 -j MASQUERADE

# Fix mss.
iptables -t mangle -A POSTROUTING -p tcp –tcp-flags SYN,RST SYN -m tcpmss –mss 1421:65535 -j TCPMSS –clamp-ms

IPTables is very efficient with a small to medium number of rules, once the number of rules increases, packet latency can increase across the firewall interfaces, as every new connection has to be checked against every rule.

Using custom chains within IPTables, can improve the efficiency and overall throughput of the firewall.

A good firewall design is important! Using the principle of Block All, Allow Some

As well as the standard INPUT, FORWARD and OUTPUT chains in IPTables it is very useful to add your own. Custom chains also allow selective tracking and logging of traffic flows.

For example:
# Make a new chain called “dropandlog”
iptables -N dropandlog

# Configure the chain.

# Limit how many log entries to make, and log.
iptables -A dropandlog -m limit –limit 15/minute -j LOG –log-prefix Firewall:

# Drop the packets passed to this chain.
iptables -A dropandlog -j DROP

Now any rules which have a jump (-j) target of dropandlog will pass the matched traffic to the chain.

For example:

iptables -A INPUT -p tcp –dport 22 -j dropandlog

This rule sends any packets on the default ssh port, coming in on the input chain to the chain dropandlog. They will be shown in the logfile with the prefix “Firewall:”.

Using separate chains cuts down the amount of rules traffic has to pass through and so improves firewall efficiency.

For example the following script:

iptables -A INPUT -p tcp ! –syn -m state –state NEW -j drop

iptables -A INPUT -p tcp –tcp-flags ALL FIN,URG,PSH -j drop
iptables -A INPUT -p tcp –tcp-flags ALL ALL -j drop
iptables -A INPUT -p tcp –tcp-flags ALL NONE -j drop
iptables -A INPUT -p tcp –tcp-flags SYN,RST SYN,RST -j drop
iptables -A INPUT -p tcp –tcp-flags SYN,FIN SYN,FIN -j drop

These rules only match TCP traffic. However all UDP and ICMP traffic will also be forced to go through each rule, slowing them down. It is much more efficient therefore to refactor this to use protocol specific chains.

#New chain tcpfilter.
iptables -N tcpfilter

# Rules for chain tcpfilter.
iptables -A tcpfilter -p tcp ! –syn -m state –state NEW -j drop
iptables -A tcpfilter -p tcp –tcp-flags ALL FIN,URG,PSH -j drop
iptables -A tcpfilter -p tcp –tcp-flags ALL ALL -j drop
iptables -A tcpfilter -p tcp –tcp-flags ALL NONE -j drop
iptables -A tcpfilter -p tcp –tcp-flags SYN,RST SYN,RST -j drop
iptables -A tcpfilter -p tcp –tcp-flags SYN,FIN SYN,FIN -j drop

# Redirect all tcp traffic to tcpfilter
iptables -A INPUT -p tcp -j tcpfilter

This type of chain can be replicated for each protocol, or for different traffic Each traffic type can then make its way through the firewall, in the most efficient way possible.

I’m currently using the DD-WRT firmware on this platform, however these instructions should work for other firmware which contains IPTables as well.

Instructions for upgrading your router to DD-WRT can be found at James Stephens Blog or on the DD-WRT wiki under Installation.

A lot of the rules are generic and with a little tweaking can be applied to other platforms.

It is important to note that unlike a standard Linux router, with interfaces labelled as eth0, eth1 etc, the WRT54G has a single switch split into Virtual LANS.

• vlan1 is the WAN interface.
• vlan0 is the LAN interface(s).
• eth1 is the Wireless interface.
• br0 is a bridge comprising of eth1 and vlan0

Any external address applied to the router through the web-interface is applied to vlan1, the internal address is applied to br0, and is therefore available to all internal clients.

Before designing IPTables rules it is useful to examine the diagrams here, and understand where traffic flows in relation to the interfaces above.

Traffic heading in or out of the router, for example to it’s external address or internal address will hit the input and output chains.

Traffic which is destined for other hosts, such as those defined by the static NAT rules explained here, will pass through the forward chain of the router.

I’ve covered using custom chains to achieve greater efficiency and carry out multiple tasks previously.

Firstly on the router we need to clear the chains that are set-up by the web interface. James Stephens provides a good way to do this in his example scripts which are on his site at http://www.sns.ias.edu/~jns.

# Set default policies to ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT

# Flush all tables and chains.
cat /proc/net/ip_tables_names | while read table; do
iptables -t $table -L -n | while read c chain rest; do
if test “X$c” = “XChain” ; then
iptables -t $table -F $chain
fi
done
iptables -t $table -X
done

# Zero counters.
iptables -Z

This allows us to start with a fresh IPTables set-up, allowing the script to be run at any time, not just on start up.

Now add these rules:

# Allow all loopback traffic
iptables -A INPUT -i lo -m state –state NEW -j ACCEPT
iptables -A OUTPUT -o lo -m state –state NEW -j ACCEPT

# Allow all ESTABLISHED and RELATED traffic
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

# Allow all LAN traffic to router
iptables -A INPUT -i br0 -s $LANIP -m state –state NEW -j ACCEPT

# Allow all traffic from router to ANY
iptables -A OUTPUT -m state –state NEW -j ACCEPT

# Allow all traffic from LAN to ANY
iptables -A FORWARD -s $LANIP -m state –state NEW -j ACCEPT

This allows connections that are already in progress when the script is run, as well as accepting new connections. We also allow traffic from the LAN interface to reach the router and allow the router to talk to other systems.

Finally we need to enable IP Forwarding to allow routing to continue, and tighten out default policies.

# Tighten Default policies.
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP

# enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

This gives a blank slate to build on. I recommend adding some of the general security IPTables rules I’ve posted here, or looking at my example scripts.