Re: [Full-Disclosure] idea (quite a bit off-topic, but....)
From: Dave Howe (DaveHowe_at_cmn.sharp-uk.co.uk)
Date: 09/21/03
- Previous message: Larry Vaden: "Re: [Full-Disclosure] Snort and SourceFire Compromised"
- In reply to: D B: "RE: [Full-Disclosure] idea"
- Next in thread: martin f krafft: "[Full-Disclosure] Re: idea"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: "Email List: Full Disclosure" <full-disclosure@lists.netsys.com> Date: Sun, 21 Sep 2003 15:12:44 +0100
D B wrote:
> what the port hopping tries to achieve is making it
> even more difficult to sniff because one cant just
> sniff a certain port.... with a random range u have to
> suck in garbage data and this increases the time it
> takes to reassemble if it is even possible
No, it is functionally equivilent to just opening a single connection.
assuming tcp, all you would need to do under your protocol would be to
note the initial (ssl) control connection, then capture *all* traffic
between the two nodes that just opened a "spread spectrum" connection.
Possibly more interesting would be a spoofed source variant; you connect
and assert a file size and name, plus a random "address"; you obtain a
unique id and symmetric key.
then, break your unencrypted file up into 'n' blocks, number them with a
prefix, and postfix the unique id.
at random intervals, pick a random block from your pool, generate a random
new address, and prefix the block with that. now encrypt the whole thing
with the symmetric key you got from the server, and send it UDP to a fixed
port on the server (or even ICMP) - but *from* a spoofed IP address
matching the one you asserted to the server earlier
More than one person can have the same expected source ip - the server
will decrypt the block with each symmetric key it has for that source ip
in turn, and if none give the matching unique id, discard the packet.
(collisions would be fairly low anyhow, even in a DOS attack; there are
after all 2^32 possible ip addresses)
After a random number of packets, reconnect with ssl, assert the unique id
*and* filename, and the reply will be the last block it received and
successfully processed (if a packet goes missing, that will allow you to
resend it or them)
Note the ssl connections there would be backtraceable, even if the data
isn't - and sending a big flood of UDP/ICMP packets (even via relays)
interwoven with direct SSL connnections would look pretty suspious if they
monitored *Your* connection. Of course you could generate cover traffic
(send vaguely random blocks to a file asserted as "/dev/null") but it
would be nicer if the SSL link were the one with a high degree of cover
traffic.
consider instead of a dedicated server, running the SSL channel as a
simple php or perl script on a functional webserver - then host a free
https webmail service; the control channel traffic would be lost in the
noise of several thousand web freeloaders all checking their webmail
accounts, and of course uploaders would have valid email accounts there
too (as checking them would be their cover traffic)
add a better reason for UDP packets (like some sort of IM client) and you
have a functional "service to the community" server, whose covert traffic
is hard to distinguish from (and lost in) legitimate traffic to the same
ports.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
- Previous message: Larry Vaden: "Re: [Full-Disclosure] Snort and SourceFire Compromised"
- In reply to: D B: "RE: [Full-Disclosure] idea"
- Next in thread: martin f krafft: "[Full-Disclosure] Re: idea"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
