Some ISP networks do not reset open TCP connections of customers that
were either cut-off by the ISP or cut off by self-initiation. While it is
responsibility of every person to terminate every open connection before
link termination, when the ISP initiates this, it cannot be guaranteed. A
customer who happens to resume a recycled dynamic IP can then read the
previous persons open sessions. With streaming mp3 radio services that work
on a per-pay basis, this can result in substantial monetary losses, not to
mention porn streaming. Further unencrypted email can be read and website
cookies can be assumed to continue private Web sessions.
>How-To-Repeat:
With a stateful firewall one can determine TCP traffic that has no
state registered with the firewall and if the TCP flags do not match SYN,
FIN, or RST, one can assume open connection and continue them. Interesting
things have been captured, including, IRC chat sessions, HTTP downloads and
POP3 sessions theoretically could also be continued. Software[1] written for
BSD Unix follows this advisory, that can re-assume open sessions.
>Fix:
After a dynamic customer terminates a broadband connection, network
access servers should terminate any TCP traffic with an RST reply, and give at
least a minute time for any retransmissions to be caught. If this is not
wanted by the network architect, perhaps a stateful firewall keeping states
for customers per session. This is not a good solution though because some
people do not want a firewall between their end-user connection and the open
Internet, their privacy from this should be accepted. Another security
programmer that I contacted, suggested that dynamic IP addresses perhaps be
more static with end-users, but I personally don't think this is a good
solution either as this puts the anonymity of end-users at stake, and goes
against the philosophy of anonymity that the forefathers of the Internet
thought out. On the consumers side one can protect themselves by only
using encrypted communications, as this makes reading of personal data
difficult.
Summary:
"Poorly designed services can be hijacked. As a result, we recommend that
every access server be redesigned."
*That*, of course, has its own set of problems. What happens when the
access server crashes and reboots, for example? What happens on campus
dorm networks where the "access server" is an Ethernet switch? There are
plenty of other attack vectors, including *active* attack vectors, which
do not rely on a malicious end user being assigned to a recycled IP. Yet
this "notice" pays no attention to these more likely attack vectors.
MY conclusion? "Poorly designed services can be hijacked. As a result,
the services in question should be fixed." If it is important, it ought
to be encrypted, for example.
This is really neither new nor shocking to anyone who has been working
with TCP/IP for any length of time.
... JG