full-disclosure - Juggling with packets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <44ABD298.8080804@baartt.com>
Date: Wed Jul  5 15:54:27 2006
From: baartt at baartt.com (Bartlomiej Szymanski)
Subject: Juggling with packets

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