RE: OT: the detection of illegal gateways

["John Lampe" <jwlampe () tenablesecurity com>]

If I'm understanding the problem, you have router A which connects to WAN ->
corporate network.  You have router B which is on the remote local network
which has internet connection.  So, users on that remote local network have
a default gateway to router B, correct?  And, if that's the case, then you
can do a number of things.  

1) query the local DHCP server on the local network
2) use a script to dump ipconfig /all of local network machines to see where
default gw, default DNS, etc. is pointed
3) run whois queries with your company name to see where someone may have
purchased an internet connection with company name
4) whois queries with @yourdomain.com to see who else might have registered
a block
5) talk with purchasing dept and give them 'keywords' that they can use to
look through purchases to see where an internet connection may have been
purchased with a corporate credit card
6) dump arp cache from router A to see if it has knowledge of any machines
with suspicious MAC addrs
7) if all internet traffic is supposed to pass through an internet firewall
or proxy, look for "lack of traffic" from IP blocks on your WAN.  Even a
regular windows machine sitting at rest is sending out queries to windows
update, NTP, DNS, etc.
8) DNS servers, who is sending queries to your recursive server and more
importantly, who isn't
9) etc. etc. etc. 

John


-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On
Behalf Of Adam Mooz
Sent: Wednesday, May 19, 2010 2:05 PM
To: Zack Payton
Cc: J Hein; pen-test () securityfocus com
Subject: Re: OT: the detection of illegal gateways

Jhein,

You could examine the TTL of packets returned in a traceroute map of your
network.  Essentially you do a traceroute to a computer inside the remote
office you're auditing, then do a ping to every hop returned in the
traceroute and examine the TTL.  If you find the TTL off by one then there
is a transparent network device inbetween the nodes on your traceroute.
This works because every device that touches but does not consume a packet
must reduce the TTL by one.  I'm a bit up on meds at the moment so here's an
example of what I mean:

1) traceroute to a computer deep within remote office A.
2) ping to every node returned from step 1.  Say you ping hopes 7A and 8A.
3) Examine the TTL of each packet.  If the TTL of 7A is 45 and the TTL of 8A
is 43, then there is a network device between 7A and 8A that's not showing
up on pings. 

The nice thing about this is it can easily be scripted, if a scan like this
doesn't already exist.  I suggest checking if the script exists in the NMAP
scripts, if the script isn't there then NMAP will have all the tools you
need.

-----------------------------------------------------------------
Adam Mooz
Adam.Mooz () gmail com
http://www.AdamMooz.com

On 2010-05-18, at 3:58 PM, Zack Payton wrote:

> Sorry, I hit send too early.
>
> Off the top I can think of several techniques that my be of use.
> I don't have any experience with IP Sonar so I'm of no help regarding
that.
> 1.  A simple way could be to use SNMP to poll all of your switches and
> look for OUI codes in the CAM tables of well known router product
> vendors.  This technique is not wholly reliable and is easy to
> deceive.
>
> 2.  Using differences in time stamps in the TCP headers and IP ID's it
> is possible to determine how many hosts are behind a firewall/router
> unless the firewall is really good at normalizing traffic.
>
> 3.  A really good way would be to do inline reverse TCP tracerouting
> to trace backward through existing TCP connections to the end hosts.
> Unfortunately, I'm not aware of any products that do this but you
> could probably whip something up using libnet or scapy.
>
> Just a couple of ideas for you.
> Z
>
> On Tue, May 18, 2010 at 3:53 PM, Zack Payton <zpayton () gmail com> wrote:
> > Off the top I can think of several techniques that may be of use.
> >
> > 1.  A simple
> >
> > On May 17, 2010, at 5:39 AM, J Hein <j.hein () ymail com> wrote:
> >
> > > hi all,
> > > this post might be somewhat off-topic, so please accept my apologies
> > > first.
> > >
> > > I have a somewhat difficult problem to crack - there is a large
corporate
> > > network which covers several Nordic countries, and unfortunately there
have
> > > been cases in the past where a device with routing capability has been
> > > plugged into the network (for creating a "faster" connection to the
internet
> > > for a branch office). Because this violates corporate policies and
creates
> > > "invisible" entry points to the internal network, I have been given a
task
> > > to find a suitable software for finding such kind of illegal routers.
> > >
> > > Are there any good products for detecting illegally installed boxes with
a
> > > routing capability? One of my fellow consultants suggested IP Sonar (by
> > > Lumeta) for this purpose which (as he claims) has been successfully used
by
> > > BT in the past. From the product description I've got an impression that
IP
> > > Sonar cleverly uses traceroute for detecting routers that illegally
exchange
> > > information between internal networks and the internet (so called
"network
> > > leaks").
> > >
> > > I understand that router detection is a complex issue, and in order to
> > > address this problem fully, one needs to analyze traffic that flows
through
> > > all key routers and switches in the whole corporate network.
Unfortunately,
> > > since the deployment of such monitoring system takes a lot of time, I'd
like
> > > to begin with a relatively simple solution which attempts to locate
network
> > > leaks by polling the network from few points only (like IP Sonar does,
using
> > > traceroute for that purpose).
> > >
> > > Can anyone recommend any such commercial or open source tools? (open
> > > source utilities would actually be my preference :)  Also, what is your
> > > experience with IP Sonar -- is it really a good stuff?
> > >
> > > Thanks in advance :)
> > > --
> > > jhein
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------
> > > This list is sponsored by: Information Assurance Certification Review
> > > Board
> > >
> > > Prove to peers and potential employers without a doubt that you can
> > > actually do a proper penetration test. IACRB CPT and CEPT certs require
a
> > > full practical examination in order to become certified.
> > >
> > > http://www.iacertification.org
> > > ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
> This list is sponsored by: Information Assurance Certification Review
Board
> Prove to peers and potential employers without a doubt that you can
actually do a proper penetration test. IACRB CPT and CEPT certs require a
full practical examination in order to become certified.
> http://www.iacertification.org
> ------------------------------------------------------------------------



------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board

Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT 
and CEPT certs require a full practical examination in order to become certified. 

http://www.iacertification.org
------------------------------------------------------------------------