Darren writes: >Hmmm. Not sure. Let me explain. If I somehow get an internal box with >an agent installed which makes connections outbound on port 80 and only >does so in response to a magic email message that I send, then it is >highly likely a proxy will dump it if it's not HTTP. Then again, if the >end is effectly an in.rshd, compiled with SSL, and *connects* to my rsh >process that listens on port 443 (again in response to a magic email), >then no magic proxy can determine if it's HTTP or anything else. Why have anything incoming at all? Why not have it open an outgoing connection every so often to a randomized list of URLs, and, if it gets back a .jpeg (or something that looks like one) strip off the .jpeg header, write it as a .exe file, and run it? Instant downloadable code that will punch past any firewall I know of (except my "ultimate firewall...") It could send data out as email, or in URLs over http. SSL would just cause suspicion. I remember a funny I heard about at a USENIX ages ago where someone had an application that (this was a desperate kludge!) used to manipulate /etc/utmp to encode data so it would go out on the LAN in rwho packets, thereby allowing them to do remote status checks on certain applications. It was the winner in one of the "worst abuses of UNIX" contests someone held (I came in 3rd with my hack of using wc on /dev/mem to get hardware RAM sizes for ULTRIX...) > > No, it's worse. The 'solution' is to disable any protocol > > that issues connections which are not immediately tied to > > an authentication that isn't performed by a computer. > >Is that sufficient ? Users are pretty dumb, after all. Well, the ultimate solution would be to disable all the users... mjr.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:00:15 PDT