Re: Promiscuous interface hacks?

[Paul Schmehl <pauls () utdallas edu>]

Thanks Frank.  Both you and Matt have clarified the issues well.

--On Thursday, May 01, 2003 09:50:24 PM -0500 Frank Knobbe 
<fknobbe () knobbeits com> wrote:

> On Thu, 2003-05-01 at 17:42, Paul Schmehl wrote:
> > But once the bo is exploited, even if a root shell is obtained, how does
> > the attacker then "get to" that shell?  Since there's no IP associated
> > with  it, I'm having trouble understanding how the attacker could then
> > proceed to  exploit the box.
>
>
> hehe... yeah, if the box doesn't have an IP address on that interface,
> you would think that the attacker couldn't establish a session back to
> himself. But there are a couple scenarios that seems plausible:
>
> a) (The obvious one) The second NIC has an IP address for management of
> the box. This this box is allowed to connect to the Internet, then the
> attacker could establish a connection back to a waiting netcat or
> something. So make sure that box is isolated and only allow Internet
> access temporarily for rule updates etc.
>
> b) No outbound access on second NIC, or no second NIC present. The
> attacker, being able to launch code, could just assign an IP address to
> the interface which didn't have an IP address before. Finding a free
> address is trivial. The attacker, well or his code, just watches ARP
> traffic, figures out what network range it is in and grabs an unused
> address (similar to the detection LaBrea employs for finding unused
> IP's). A read-only cable or Ethernet tap work wonders here.
>
> c) This is one of my favorites because a lot of folks don't consider
> this one: First NIC is on a tap, second NIC on the internal network, but
> firewall does not allow it Internet access. Most likely DNS will work,
> so there is always the chance to create a tunnel using valid DNS
> queries. Attacker sends payload, IDS sniffs is, overflows, and code
> executes. That code does DNS queries against records within the
> attackers domain, and using the queries and results shovels data back
> and forth.
>
>
> There are all these possibilities.... but they are tricky. I bet you
> that there is other, lower hanging fruit, to compromise a network :)
> However, one should not dismiss IP-less devices as safe. A tap or RO
> cable is way more effective (try to find a hacker that can remotely hack
> a cable back together :)
>
> Cheers,
> Frank
>
>
> PS: Regarding your other email: No, I'm not aware of any white papers
> etc.



Paul Schmehl (pauls () utdallas edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users