[Snort-users] Promiscuous interface hacks?

Paul Schmehl pauls at ...6838...
Fri May 2 07:20:10 EDT 2003

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

--On Thursday, May 01, 2003 09:50:24 PM -0500 Frank Knobbe 
<fknobbe at ...652...> 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 at ...6838...)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member

More information about the Snort-users mailing list