The only way we could think of getting our hands on the communication was to write a small set of scripts to trick the client and encapsulate the communication inside HTTP requests that we could then manipulate using standard proxy tools such as burp.

Although the information and scripts described in this post are focussed on intercepting a XML communication, the same principles apply to man in the middle any ASCII protocol such as smtp, ftp or pop.

update: slides available here

The first step is to trick the client to connect to our local box instead of connecting to the remote server, this is done by adjusting the hosts file.

A ruby script will sit in the middle of the communication and will be able to intercept and modify messages sent and received by the client:-

Once this is done, our attack will need three elements:

• the xmitm script.
• an external web proxy tool.
• a dummy web server.

The script will intercept the connection and send the data to the proxy. We need the dummy server (the body of the response will be the body of the request) to close the loop with the proxy (I will add some nice graphs to clarify this soon).

The original XML message is encapsulated in an HTTP request and passed through the proxy. The user can inspect and modify the message using a standard web proxy tool. The request is then forwared to a dummy *echo* web server that replies with the same payload that was requested. The script can extract the modified payload and forward it to the server.

The same process is applied to incoming messages.

Below is the main body of the script (you can also grab the code):-

# create a server that accepts connections from the client
server = TCPServer.new($local_host, $local_port)

while(local = server.accept ) do
  # everytime we accept a connection for the client, we open a connection
  # with the server to stablish the dialog.
  remote = TCPSocket.new($remote_host, $remote_port)
  
  # if one of the ends of the communication closes the socket, we
  # toggle this flag
  alive = true
    
  while alive do
    # see the explanation below
    result = select([local, remote], nil, nil)
  
    if result != nil then
      for socket in result[0]

        # detect if one end of the connection is closed and
        # close the other end
        if (socket.eof?)
          local.close
          remote.close
          alive = false
          break
        end
        
        # read the information that one peer wants to send to the other
        data = socket.gets($eom)

        # encapsulate the data into an HTTP proxy request
        res = Net::HTTP.new($proxy_host, $proxy_port).start do |http| 
          req = Net::HTTP::Post.new("http://#{$dummyhttp_host}:#{$dummyhttp_port}/")
          req.body= data
          http.request(req)
        end

        modified_data = res.body.chomp

        # send the modified data to the other end of the connection        
        if (socket == local)
          remote.puts(modified_data)
        else
          local.puts(modified_data)
        end
        socket.flush
      end
    end
  end
end

What the script does can be summarized in the following steps:

1. Create a TCP server, listening on the port the client is expecting.
2. For each connection accepted:
   • Open a connection with the remote server.
   • Wait until one end of the communication (first the client, then the server, then the client, etc.) has something to transmit.
   • Grab the XML message.
   • Put that message as a payload of a new Net::HTTP::Post request.
   • Send the request to the external web proxy.
   • Grab the body of the response given by the proxy (already modified by the user using the external proxy).
   • Send the modified request to the other end of the line.

The most interesting piece of the code is the one regarding Kernel#select function that waits for data to become available from input/output devices.

A note regarding the specifics of the protocol we were dealing with, each peer ends its messages using a special character (a NULL byte), that caracter is defined in the $eom variable and the script keeps reading the socket until that end of message character is read.

The last piece of the puzzle is the dummy HTTP server. I coded two flavours: a ruby version and a java version (not yet available for download based on the SingleFileHTTPServer example). You can pick your choice. Here is the ruby one:-

require 'webrick'

include WEBrick

# create the server, no output, disable logging
s = HTTPServer.new(
  :Port => 2000,
  :Logger => Log.new(nil, BasicLog::FATAL),
  :AccessLog => []  )

# the *echo* functionality
s.mount_proc("/") do |req, res|
  res.body = req.body
  res['Content-Type'] = req['Content-Type']
end

# clean tear down
trap('INT') { s.shutdown }

s.start

And this completes the XML protocol man-in-the-middle DIY kit. Hope you find it useful.

The robots exclusion standard or robots.txt protocol is a convention to prevent cooperating web spiders and other web robots from accessing all or part of a website. The information specifying the parts that should not be accessed is specified in a file called robots.txt in the top-level directory of the website.

Here is a script that checks for the presence of the file in a list of hosts (you can download the source code). Two main parts can be distinguished: command line parsing and file download.

You can call the script in two different ways. Either you do not specify the protocol (and HTTP will be used):-

./robots.sh <host1> <host2> ...

Or you specify the protocol with:

./robots.sh  -p [http|https] <host1> <host2> ...

Let’s see how this is done:

PROTO=( http https )
HTTP=${PROTO[0]}
FILE=/tmp/robots.txt

# command line parsing
if [ "-p" == $1 ]
then
  for bar in ${PROTO[*]}
  do
    if [ $bar == $2 ];
    then
      HTTP=$2
      HOSTS=${*:3}
    fi
  done
else
  HOSTS=$*
fi

We check if the first argument is “-p” in which case, the next argument should be one of the allowed values (those in $PROTO array). If that is the case, we strip the first two parameters and put everything else in the $HOSTS variable. At the end of the code above, $HTTP will contain either http or https and $HOSTS will consist of a list of hosts whose robots.txt file existance we want to verify.

Once we know what protocol are we using and the list of targets, the only thing left is to try to download the robots.txt file of each server:-

for foo in $HOSTS; do
  echo "================"
  echo "Server: $foo ($HTTP)"
  CODE=`wget -O $FILE $HTTP://$foo/robots.txt 2>&1 | grep HTTP | head -1 | awk '{print $6}'`
  echo "Code: $CODE"
  if [ "200" == $CODE ]
  then
    echo "Contents:"
    echo "----------------"
    cat $FILE
    rm $FILE
    echo "----------------"
  fi
done

If the response code is 200 OK we cat the file to standard output. Otherwise we just move on to the next target of the list. The only tricky bit of the previous code is:

wget -O $FILE $HTTP://$foo/robots.txt 2>&1 | grep HTTP | head -1 | awk '{print $6}'

Where we try to download the file saving it to the location specified by $FILE. In order to get the HTTP error code we redirect standard error to standard output using 2>&1.

One last word, it is acknowledged that the script does not follow HTTP redirects, but if the server replies with a redirect this means that effectively, no robots.txt file is present.

To store the information of our comic strips we will be using YAML:

The YAML library serializes and deserializes Ruby object trees to and from and external, readable, plain-text format.

In the config file (rcomic.yaml) every comic strip definition will have the following appearance:

xkcd:
  desc: A webcomic of romance, sarcasm, math, and language.
  host: www.xkcd.com
  path: /
  rexp: <img\ssrc=\"(.*comics.*?)\".*?>

You need a key word that will be used to refer to the strip and a set of configuration parameters, the host name, the path inside the server and a regular expression to identify the desired image.

In order to add a new strip, you only need to append a block like the one above to your configuration file.

Three steps are performed in the script: command line parsing, HTTP connection and download of the page, image download and display. In order to know what strip are we working on, first we need to load the configuration file as show:-

#load configuration
config = YAML.load_file('rcomic.yaml')

Then some simple logic determines if the requested strip (the first argument provided) is configured in the .yaml file. If no reference to the key word is found in the YAML file, a help message is displayed. Otherwise, we carry on with the next steps:

# prepare an HTTP connection
http = Net::HTTP.new($host)
# get the page
response = http.get($path)

# scan for the image
img = response.body.scan($rexp).first.first
file = File.basename(img)

First we request the page and then we apply the regular expression to the body of the HTML returned. The img variable will contain the full URL to the image (i.e. http://imgs.xkcd.com/comics/gyroscopes.png) and the file will contain only the file name (i.e. gyroscopes.png).

With this information is dead easy to download and display the images:

# download (if not already downloaded)
unless File.exist?("/tmp/#{file}")
  `wget -O /tmp/#{file} #{img}`
end

# display
`display /tmp/#{file}`

As a side note, we will only download the file if the file is not already present in our /tmp/ folder.

Happy comics

#!/bin/bash

###
### IPTables config file
### Based on the rules compiled by Ranjit San aka 'the grasshopper'
### Created 2007-09-14 by Daniel Martin Gomez <etd[-at-]nomejortu.com>
### Revision 1
###

###
### define variables
###

### path to iptables 
IPT=/sbin/iptables

### This contains a list of approved Debian sites to get software updates.
DEBIAN_SITES=('194.109.137.218' '212.219.56.139' '212.219.56.133' '212.219.56.134' '212.219.56.135' '212.219.56.138')

### This contains the authorised DNS servers configured in /etc/resolv.conf. 
DNS_SERVERS=('') 

### This is a list of external IPs that you want to allow ssh access from.
OTHER_GATEWAYS=('') 

### This is a list of hosts authorised to try ICMP probes to check if the
### server is running. This could be your ISP's IPs
CONTROL_GATEWAYS=('')

### Types of ICMP probes to allow from the previous servers
ICMP_TYPES=('echo-reply' 'destination-unreachable' 'echo-request' 'ttl-exceeded')


#### NTP servers for time synch
NTP_SERVERS=('')

### ------------------------------------------------- do not change below this line

###
### INPUT
###

### will flush the chains or all rules one by one. Therefore all new rules will be created. 
$IPT -F 

### allows inbound packets to be processed
$IPT -P INPUT ACCEPT

### drops packets so that they can not come through one interface and flow out of another. 
$IPT -P FORWARD DROP 

### This allows outbound packets to be processed
$IPT -P OUTPUT ACCEPT


### allows ICMP types (defined above) for hosts in the control list 
for IP in ${CONTROL_GATEWAYS[@]}; do
	for ICMP in ${ICMP_TYPES[@]}; do
		$IPT -A INPUT -s $IP -p icmp --icmp-type $ICMP -j ACCEPT 
	done
done

### this accepts connections for http and https access from anywhere
$IPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
$IPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

### this allows remote administration using ssh from your other gateways.
for IP in ${OTHER_GATEWAYS[@]}; do 
    $IPT -A INPUT -s $IP -p tcp -m tcp --dport 22 -j ACCEPT
done


### this allows packets to start a new connection or allows packets that are
### already associated with a connection, required for stateful inspection.
$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

### this allows NTP traffic from NTP server
for NTP in ${NTP_SERVERS[@]}; do 
    $IPT -A INPUT -s $NTP -p udp -m udp --sport 123 -j ACCEPT
done

### we are about to drop everything else, so first log the discarded traffic
### just in case we want to know what *they* are trying.
$IPT -A INPUT -j LOG

### this drops any traffic that does not match to the INPUT rules
$IPT -A INPUT -j DROP 



###
### OUTPUT
###

### Allows traffic to authorised DNS servers
for IP in ${DNS_SERVERS[@]}; do 
    $IPT -A OUTPUT -d $IP -p udp -m udp --dport 53 -j ACCEPT
done

### Allows http traffic to debain sites for software updates. 
### Initial config rule
for IP in ${DEBIAN_SITES[@]}; do 
    $IPT -A OUTPUT -d $IP -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
done

### this allows packets to start a new connection or allows packets that are
### already associated with a connection, required for stateful inspection. 
$IPT -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 

### this allows NTP traffic to the NTP servers
for NTP in ${NTP_SERVERS[@]}; do 
    $IPT -A OUTPUT -d $NTP -p udp -m udp --dport 123 -j ACCEPT
done

### this logs all OUTPUT traffic that does not match the rules before it beign
### dropped.
$IPT -A OUTPUT -j LOG 

### this drops any traffic that does not match to the OUTPUT rules
$IPT -A OUTPUT -j DROP

Just two things to add: First, do not forget to set your own values for the variables DNS_SERVERS, OTHER_GATEWAYS, CONTROL_GATEWAYS and NTP_SERVERS. And second, if you want your kung-fu up and ready after boot you may need to issue the following:-

cd /etc/init.d/
wget http://weblog.nomejortu.com/data/code/bash/firewall.sh
chmod +x firewall.sh
update-rc.d firewall.sh defaults

If you ever want to remove it from the boot sequence just issue:-

update-rc.d -f firewall.sh remove

Pinky: Gee, Brain, what are we going to do tonight?
Brain: The same thing we do every night, try to take over the world!

Have you ever wanted to have the ability to send commands to your box using email? Use RubyBot, the brand new plugin-driven ruby script that makes the task of taking over the world a bit easier!

Goals of the project:

• We want to have a script that can be used directly by the MTA (much in the way procmail works).
• We want to deal with the internals of email format as less as possible.
• Flexibility is an issue! We want to be able to do all sorts of things.
• We want to have some feedback/output from our commands

But first, stand and relax, there is lots of stuff comming in this post, so maybe it is a good idea to download the code and have a look at it before we start.

MTAs can usually be configured to pass received messages to certain applications. The internals of how this mechanism works is out of the scope of this post. However, as an example, let’s see how qmail uses the .qmail files to do it. The following .qmail file will pipe the contents of all the incoming mail to our script:

|./rubybot.rb

The first thing thatour script needs to do is to get the piped message. In ruby we do this by reading the contents of the standar input:

#0: get email from standard input
email = ''
while gets
  email << $_
end

The previous code will store in the email variable the contents of the email. Instead of trying to parse the email with regular expressions we are going to use the ActionMailer package of the Ruby on Rails (RoR) framework.

What is ActionMailer?
Action Mailer is a framework for designing email-service layers.

Sounds like ideal, does it? In order to use the package we will need to include it and also to create a class that extends the ActionMailer::Base, here is the code:

require 'rubygems'
require_gem 'actionmailer'

#wrapper of RoR ActionMailer
class RubyBot < ActionMailer::Base
  def receive(email)
    return email
  end
end

Now we can convert the raw email string into a ruby object with the following call:

msg = RubyBot.receive(email)

We can send signals such as msg.subject or msg.parts to the object to query the email’s information.

Before continuing with the rest of the script a word should be said regarding logging and configuration. After all, our RubyBot is quick-and-dirty script so for configuration we will use a hash at the begining of the file:

#--------------------------------------- config
$options = {
  :myself => 'rubybot[_at_]nomejortu.com',
  :admin => 'etd[_at_]nomejortu.com',
  :subject => '[rubybot] notificacion:',
  :plugins_dir => './rbplugins',
  :pluginopt => { 
    :tmpdir => './tmp',
    :logger => nil
  }
}
#--------------------------------------- /config

All options are self explanatory except maybe two:

• :plugins_dir will contain all of our plugins.
• :pluginopt contains the options that we will be passing to the plugins (mainly an object for logging and a temporary directory).

For logging we are going to use ruby’s standard Logger and we are going to store it’s output in a log file under the :plugins_dir directory. This is the code that initializes the logger:

logfile = $options[:plugins_dir]+'/msg.log'
File.rm_f(logfile) if File.exist?(logfile)
log = Logger.new(logfile)

log.level = Logger::DEBUG
$options[:pluginopt][:logger] = log

We are saving the name of the file for the last bit of the script where we attach the log file to the notification that RubyBot sends to the administrator. Also we are saving a reference to the logger in the configuration hash so we can pass it to out plugins.

Our script will use the subject line to decide which plugin should handle the request. The dispatching algorithm is show below:

#2rd process the command (from email's subject)
module_name = msg.subject.split[0]
module_file = $options[:plugins_dir] + '/' + module_name + '.rb'
if (FileTest.exists?(module_file))
  log.info{ "valid plugin found: #{module_name}" }
  begin
    load module_file
    plugin = Kernel.const_get(module_name.capitalize + 'Plugin').new
    output = plugin.process(msg, $options[:pluginopt])
  rescue
    log.error{ "error while processing command: #{$!}" }
    log.debug{ $!.backtrace.join("\n") }
    output = "error while processing command: #{$!}"
  end
else
  log.error {"module not found in plugins dir (#{$options[:plugins_dir]})"}
end

A few things are going on in the previous piece of code. First we split the subject of the email and we take the first word as a module name. Then we try to determine if a file called module_name.rb exists in the plugin directory. An error is logged if the file is not found. However, if we find the file we try to load the file and create an instance of the module:

load module_file
plugin = Kernel.const_get(module_name.capitalize + 'Plugin').new

For example, if our message’s subject is “simple” te previous lines will try to instantiate a copy of SimplePlugin from the file ./rbplugins/simple.rb. If something goes wrong we capture and log the exception, otherwise we send the .process signal to the plugin passing the email and the options as arguments.

All RubyBot’s plugins should include the Plugin module as defined in ./rbplugins/plugin.rb. The module has five methods and I will not give details of all of them here for the sake of clarity in the post. However, a brief description follows (MIME stands for Multipurpose Internet Mail Extensions):-

• part_filename: returns the filename that we should use for a given part in a MIME multipar messages.
• ext: given a MIME type the method returns a file extension.
• save: saves all the attachments of the email into a given folder.
• clear: given a folder, deletes it’s contents.

The last and most interesting method is process. It will perform three operations: first save all the email’s attachments to the temporary folder, then process the body of the message looking for commands and finally delete the attachments from the temporary folder.

Depending on whether the email received is multipart or not a slightly different approach is needed to get the requested commands:

#process the body, 1 command per line
    if (@msg.parts.empty?)
      commands = @msg.body.split(/\n/)
    else
      commands = @msg.parts[0].body.split(/\n/)
    end

Now we have an array that contains all the commands. The processing cycle goes as follows:

commands.each do |cmdline|
      args = cmdline.split
      if (self.respond_to?(args[0]))
        begin
          @log.info( 'plugin' ) { "[#{args[0]}] processed by #{args[0]} plugin. " }
          out << self.send(args[0], args[1,args.size-1])
        rescue
          @log.error('plugin') { "error while processing command: #{$!}" }
          @log.debug('plugin') { $!.backtrace.join("\n") }
          out << "error while processing command: #{$!}"
        end
      else
        @log.error('plugin') { "undefined command: #{args[0]}" }
        out << '<command not found / no output from command>'
      end
    end

Appart from the error handling the interesting calls are two: self.respond_to? and self.send. With the first one we check whether the plugin implements the requested command and with the second one we delegate the execution of the command to the implementation.

Following our previous example let’s say that we receive the following email:

Subject: simple
[...]
echo hello world
echo good bye

RubyBot will parse the Subject line and will load and instantiate SimplePlugin. Then a process signal will be sent to the plugin. Since our example has no attachments, the process method (of the Plugin module) will just walk through the commands checking if we have implemented echo in SimplePlugin module. Provided that SimpleCode is defined as follows (in ./rbplugins/simple.rb):

require 'rbplugins/plugin'

class SimplePlugin
  include Plugin
  def echo(args)  
    return "good to go: #{args.join('|')}"
  end
end

The output of the commands issued above would be:

good to go: hello|world
good to go: good|bye

To comply with our last goal we need to add an extra method to the RubyBot class. The method notification will be used at the end of the script to send us a notification with all the details of the procession of our commands.

class RubyBot < ActionMailer::Base
[...]
  def notification(msg, out, log)
    recipients $options[:admin]
    subject "#{$options[:subject]} #{msg.subject}"
    from $options[:myself]
    
    commands = 'empty'
    if (msg.parts.empty?)
      commands = msg.body
    else
      commands = msg.parts[0].body
    end

    body =<<EOF
    ------------------------------------
    Se ha recibido el mensaje anterior
    From: #{msg.from}
    Subject: #{msg.subject}
    Date: #{msg.date}
    Body:
      #{commands}
    Output: 
      #{out} 
    ------------------------------------
EOF
      
    part :content_type => 'text/plain', :body => body

    attachment :content_type => 'text/plain', :body => File.readlines(log).join("\n")
  end
end

The method creates a new email message with the recipient and subject specified by the options of the plugin. Then it creates a body for the email consisting of information regarding the received commands and at last attaches the log file created during the processing of the commands.

The last call of our script will be RubyBot.deliver_notification(msg, output, logfile). ActionMailer’s deliver_something will first call something, that should return an email object, and then will attempt to send the email to the specified recipients.

And that was all for today…

Pinky: Why? What are we going to do tomorrow night?
Brain: The same thing we do every night, Pinky. Try to take over the world!

After some research I found a set of scripts that actually do what I want (credit goes to Heiner Steven). The bad news is that this is not a full-bash solution. The scripts use the metasend command to send files as MIME atachments.

This is a easy two-step process. First, you need to install the metamail (this is the name of the Debian GNU/Linux package) in your box. Then grab this two scripts (sendfile, getmimetype). The first one does the call to metasend. From it’s usage information:

usage: sendfile [-f] [-s subject] [-m mimetype] recipient file ...
    -f:  force sending of mail even for invalid recipients
    -s:  subject of the mail message
    -m:  mime-type (i.e. "application/octet-stream")

Multiple files may be specified. If no mimetype was given,
it is determined via a call to "getmimetype".

And you are ready to go.

#!/bin/bash

for foo in `ps aux | grep $1 | awk '{print $2}'`;  do kill -9 $foo; done

Just run: matar <program name> and that’s it. They are all gone.

If your machine answers ICMP Timestamp messages an attacker can learn the date which is set on your machine. This may help him to defeat all your time based authentication protocols.

Here is the code of a script that can be used to check if a remote host listens Timestamp requests:

# Check if the script is being run as root exit if it is not.
if [ "$UID" -ne "0" ]
then
  echo "[ERROR] This script must be run as root"
  exit 1
fi

for foo in $*; do 
  echo -n "$foo "
  output=`hping3 -c 3 --icmp-ts $foo 2>/dev/null | grep "ICMP timestamp" | wc -l`
  if (( output > 0  ))
  then
    echo "reacts to ICMP timestamp."
  else
    echo "doesn't react."
  fi
done

First we need to check that root is the one running the script because otherwise we won’t be able to craft ICMP packages. For this task we will be using hping (i.e: hping3 package in Debian GNU/Linux).

The script just sends three (-c 3) ICMP Timestamps (--icmp-ts) to each of the hosts feeded in the command line. We grep the output of hping3 looking for the magic string “ICMP timestamp“, and if found, we print a success message.

You have to use the bash function ${foo//string1/string2}. Check the Advanced Bash-Scripting Guide for a complete list of string manipulating functions.

for foo in *; do mv "$foo" ${foo// /_}; done

This is an easy one. Although you can perform background auto change from KDE control center, it may be usefull to have a script to do the task. You can use this script to create a link in your desktop to change the background image when you want.

The KDE applications can be controlled by scripts via the DCOP mechanism. From the Wikipedia:

DCOP, which stands for Desktop COmmunication Protocol, is a light-weight interprocess and software componentry communication system. The main point of this system is to allow applications to interoperate, and to share complex tasks. Essentially, DCOP is a ‘remote control’ system, which allows an application or a script to enlist the help of other applications. It is built on top of the X Window System’s Inter-Client Exchange protocol.

Let’s begin with the script, here is the code:

#!/bin/bash
dcop kdesktop KBackgroundIface changeWallpaper

Now, you have to create a list of backgrounds using KDE’s control center. First open kcontrol, browse to Appearance & Themes > Background and select Slide Show. Click on Settings

Just create the list, and the script is ready to go.