> I don't see what point data leakage in mbuf's and ethernet frames makes.
> That "other" data isn't going to be interpreted by anything, so you may
> as well be tunnelling data some easier way. Not to mention that if
Not tunnels. Consider the case when you have stuff inside your firewall
box (network A) and a listener outside on network B (who maybe has broken
an external unprotected customer box deliberately outside the firewall).
Now broadcasts and potentially other traffic going from internal users to
the network A interface of the firewall box includes potentially useful data
(rip broadcasts, telnets in from dumber configurations, ftp upload passwords).
If you cause a regular stream of acks back to you with no data you get
stuff on the external ethernet seeing things like
[EthernetHeader][IP header][TCP header][Trailing junk...]
Where trailing junk occasionally contains stuff like
"USER foo"
"PASS bletch"
or conversations with things like a TIS proxy.
Causing a regular stream of return acks is easiest done by botching a kernel
to have a 5 second keepalive timer and keepalives off by default. Then just
open a mail connection to the target server with keepalives on. From
this guys description he didnt have no connections to this box, he had
web on it - dumb move to start with, cgi binaries belong as far from your
network as possible). After a lot of listening and logging on that external
ethernet you will pick stuff up
It is a very limited attack that only works if
1. The firewall has a port you can connect too - most do, even if its
forwarding mail. Worse mailers dont generally log anything special for a long
apparently timing out session.
2. You can listen on the external (ie insecure side) ethernet. That
means being close, or being able to penetrate a machine outside the firewall
on the same lan. The moment you pass one more further router the trailing
data is often lost (not always, some ether<->ether stuff keeps the same padding
with the packet).
3. You have the [right/wrong depending on view] OS on the firewall, and
to some extent the right cards. Some of the Linux drivers also can leak in
this way but others don't. For any OS you'd want to test this.
4. The services you can pick up data for internally are accessible
through the firewall. (And in advanced cases by feeding users across the
firewall trojans). FTP is one where its commonly not set up with two
ftp daemons one doing anonymous only and with the wu.ftpd bugs fixed, the
other being the user upload one that isnt available from the external side.
If the services you can pick up off the internal network are not remotely
accessible at all then knowing the passwords shouldn't help an attacker.
Alan
|
|
