OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
[Full-disclosure] Juggling with packets

From: Bartlomiej Szymanski (baarttbaartt.com)
Date: Wed Jul 05 2006 - 09:54:16 CDT


Hello,

I was trying to realize in practice the part (Class B data storage: disk
queue) W. Purczynski and M. Zalewski described in juggling_with_packets.txt.

"An example attack scenario:

   1. The user builds a list of SMTP servers (perhaps ones that provide
      a reasonable expectation of being beyond the reach of his foes),

   2. The user blocks (with block/drop, not reject) all incoming
      connections to his port 25.

   3. For each server, the attacker has to confirm its delivery timeouts
      and the IP from which the server connects back while trying to
      return a bounce. This is done by sending an appropriate probe to
      an address local to the server (or requesting a DSN notification
      for a valid address) and checking how long the server tries to
      connect back before giving up. The server does not have to be an
      open relay.

   4. After confirming targets, the attacker starts sending data at
      a pace chosen so that the process is spread evenly over the
      period of one week. The data should be divided so that there
      is one chunk per each server. Every chunk is sent to a separate
      server to immediately generate a bounce back to the sender.

   5. The process of maintaining the data boils down to accepting
      an incoming connection and receiving the return at most a week
      from the initial submission, just before the entry is about
      to be removed from the queue. This is done by allowing this
      particular server to go thru the firewall. Immediately after
      receiving a chunk, it is relayed back.

   6. To access any portion of data, the attacker has to look up which
      MTA is holding this specific block, then allow this IP to connect
      and deliver the bounce. There are three possible scenarios:

      - If the remote MTA supports ETRN command, the delivery can be
        induced immediately,

      - If the remote MTA was in the middle of a three-minute run in
        attempt to connect to a local system (keeps retrying thanks to
        the fact its SYN packets are dropped, not rejected with RST+ACK),
        the connection can be established in a matter of seconds,

      - Otherwise, it is necessary to wait between 5 minutes and
        an hour, depending on queue settings."

Did anyone actually acomplished this goal? Any luck?
I need to realize this scenario attack, because I need it to my Master
Thesis.
If you have any suggestions, just email me.

Regards,
Bartek Szymanski

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/