00111: TCP/IP Fork
(17 May 1998) Concept by Pat Adams and Ryan Day Copyright 1998 Digital DarknessIntroduction
While doing penetration testing on a Citrix Winframe server, we set up a ethernet sniffer, which for those that don't know, monitors traffic on a network, allowing you to view the data transfered back and forth between two systems. The problem with sniffing is the way the data is transmitted. It may or may not be transmitted in clear text. If not in clear text, one would have to decode the data. This is what our Citrix Winframe Cracking idea was all about, but the problem with this is that EVERY system would have to have the same process done. The TCP/IP Fork would solve that problem. Using the idea of the l0pht's Netcat program, which binds to a port and allows total control of all data in and out of that port. Using such a program, the data can be blocked, let through, changed, or maybe even sent to two different computers.
Sending it to two different computers is the basis of the TCP/IP Fork. The user of the Fork would set up a computer using the same programs as the target computer, slightly modified, and set up the TCP/IP Fork on the server that the target is communicating with. The Fork would send all data originating from the server to both the target and duplicate machine, thus recreating the session on the duplicate machine. The duplicate machine could not affect the session, but everything that happens would be recorded there. Also, incoming data from the duplicate machine would require blocking to avoid disruption in the case of a server sending pings and such to make sure the connection is still active.
What it Means
Even encrypted communications might be vulnerable to attacks such as this. If the server and the client are not careful about how the key for encryption is agreed upon, another computer receiving the same data would have the same key, thus allowing it to listen in on the session.
While doing penetration testing on a Citrix Winframe server, we set up a ethernet sniffer, which for those that don't know, monitors traffic on a network, allowing you to view the data transfered back and forth between two systems. The problem with sniffing is the way the data is transmitted. It may or may not be transmitted in clear text. If not in clear text, one would have to decode the data. This is what our Citrix Winframe Cracking idea was all about, but the problem with this is that EVERY system would have to have the same process done. The TCP/IP Fork would solve that problem. Using the idea of the l0pht's Netcat program, which binds to a port and allows total control of all data in and out of that port. Using such a program, the data can be blocked, let through, changed, or maybe even sent to two different computers.
Sending it to two different computers is the basis of the TCP/IP Fork. The user of the Fork would set up a computer using the same programs as the target computer, slightly modified, and set up the TCP/IP Fork on the server that the target is communicating with. The Fork would send all data originating from the server to both the target and duplicate machine, thus recreating the session on the duplicate machine. The duplicate machine could not affect the session, but everything that happens would be recorded there. Also, incoming data from the duplicate machine would require blocking to avoid disruption in the case of a server sending pings and such to make sure the connection is still active.
What it Means
Even encrypted communications might be vulnerable to attacks such as this. If the server and the client are not careful about how the key for encryption is agreed upon, another computer receiving the same data would have the same key, thus allowing it to listen in on the session.
Back Next
