full-disclosure - Unusable Security [was: Re: DLL hijacking with Autorun on a USB drive], also proxy in the middle detection / destruction

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]

Date: Tue, 31 Aug 2010 23:14:30 -0700
From: coderman <coderman@...il.com>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Unusable Security [was: Re: DLL hijacking with
 Autorun on a USB drive], also proxy in the middle detection / destruction

On Tue, Aug 31, 2010 at 4:26 PM, coderman <coderman@...il.com> wrote:
> ... it would have been nice to
> collect stats from the get go. then he might have shown only a 99.72%
> success rate.

on this subject, transparent MITM tools like MALLLLORYYY!!!!!!!!!!*
and friends often succumb to resource exhaustion attacks. i've been
looking for something to accomplish the following while requiring the
least amount of resources on the host. (the point is to leverage as
little of your resources to exhaust the resources of the transparent
monkey in the middle.) unfortunately this kills any NAT router in your
egress path but who needs those anyway?

ideally these packet generators would be layers on top of scapy,
another indispensable utility:

attached to a raw ethernet / datagram device i need:
a. lightweight TCP state machine for connection tracking / file
descriptor exhaustion
b. lightweight SSL/TLS state machine and weak key generation for SSL
session exhaustion

how small can you get per TCP connection overhead sufficient to
maintain state assuming fixed pool of client IPs to random
destinations?
64bytes / conn?  16bytes? less?

how small can you get per TCP+SSL connection overhead sufficient to
maintain state assuming fixed pool of client IPs to random
destinations and server side certificates? (weak keys, key derivation
functions, other memory conserving implementation tricks encouraged :)
0.25kB/sess.?  <48B/sess?

* kudos guys; i like this tool. a little tweaking to protocol/base.py
for full s2c response buffering, de-chunking, mangling and it works
nicely for a wide range of needs. ++

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