Re: Restricted IP access to running services

[natron <natron () invisibledenizen org>]

In some situations, it's possible to do, but it's such a pain and
provides such a little amount of information for the effort required,
it's only applicable in very unique situations.

You can utilize nmap's idle scan technique if you have want to see
what a given IP address has access to.  For example, if you gain
access to a DMZ and want to know if any of the hosts in the DMZ have
access to a particular port on a host inside the network, you could
use idle scan.  This will only work if there is a host at the IP
address you want to test, and only if its traffic is low and/or
predictable.

Or, again in the DMZ scenario, you could rapidly change your static IP
address to new addresses in the subnet to see if any unused IPs allow
greater access than the IP address you have already compromised.  Or,
you could utilize ARP poisoning to MITM a legitimate host.  If not
careful, you could take down a valid host inside the DMZ.. potentially
having a large impact to your client.

So it is theoretically possible, but it will always be a niche process
that only has value in rare circumstances.

n


On Fri, Nov 21, 2008 at 7:45 AM, Shenk, Jerry A
<jshenk () decommunications com> wrote:
> In short - you can't.  From a strictly blind pen-testing standpoint,
> there is no way to enumerate all instances where a specific IP address
> is allowed access to a specific TCP service....in fact, I don't see how
> you could even be effective enough to have it be worth trying unless you
> are in the path of the traffic.  If you are in the path of the traffic,
> then of course you have different options.  Note that I added TCP to
> your question....if it's UDP, that's different 'cuz there is no SYN/ACK
> stuff to worry about.
>
> Same goes for exploiting the open port from an IP address that you don't
> have access to...basically, you can't.  Ok, you can try to guess
> sequence numbers and inject an exploit but you've got one, two....MAYBE
> 3 packets....and that's if you have predictable sequence numbers and you
> can't even know that 'cuz you can't see the traffic...unless you do have
> access to some other port on that box.  The problem is getting the
> traffic back to you...you're talking about interactive access with a
> web-based front-end to a firewall by spoofing traffic...that's not going
> to work.  Maybe you get access to a router in front of the box that
> you're attacking and maybe you can tunnel the traffic to the "allowed
> IP" back to you...in theory, a GRE tunnel should allow this.  I've never
> done this...would be a fun one to work on someday in the lab.
>
> Another remote option would be to use the routing options in the TCP
> packet to put yourself in the path of the traffic.    But, once
> again...there are so many routers that block that type of traffic that I
> doubt that will work anymore either.  I've heard people talk about doing
> that and if you can, you could get yourself an interactive access to
> that firewall GUI you want.
>
>
>
> -----Original Message-----
> From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
> On Behalf Of arvind doraiswamy
> Sent: Thursday, November 20, 2008 10:26 PM
> To: pen-test () securityfocus com
> Subject: Restricted IP access to running services
>
> Hey Guys,
> I'm quite sure a lot of people here have come across a Port open BUT
> Restricted to IP's scenario whenever you'll have pen tested. This
> could be the case with potentially any running service -
> HTTP/HTTPS/FTP/SMTP relay to name a few.
>
> My question is - What are the methods you use to enumerate exact IP
> addresses that you think are allowed access? Once you do that how do
> you use them? Here are my thoughts:
>
> --- Apart from directly asking the client about which IP's he's given
> access (which isn't going to be fruitful at all IMO) the only bet at
> finding out is to browse the web/social engineer/spider the website
> for contacts and social engineer your way into getting a list of
> clients/IP addresses(if you're lucky)
>
> What if you don't succeed here? Are there any other techniques you
> use? Apart from trying to get lucky with a scanner on some other
> exposed service and work your way backward from there to the blocked
> service.
>
> Then again, what if you do succeed? Assume you enumerate say; 3 IP
> addresses that are allowed to access that HTTP firewall administrative
> page over the Internet. How do you exploit this behavior?
> --- Do you just change your IP address to that public IP address and
> start trying to gain access? This again is not easy - On a dialup/any
> other dynamic IP allocator you're going to be assigned one IP from
> their pool and cant change it else you get dropped.
> --- Behind a FW/Router/Proxy scenario you would have to NAT your
> private IP to that public IP
> --- VMWare is an option too in bridged mode
> --- Maybe Hping by spoofing source addresses and creating customized
> packets to access the remote "filtered" service (though this can be
> painful)
>
> That's all I could think of off the top of my head. What would you do?
> Its a question which has bugged me for a while now as to why just IP
> restrictions are not considered good enough(this isn't the main
> question :) )
>
> Cheers
> Arvind
>
> ------------------------------------------------------------------------
> This list is sponsored by: Cenzic
>
> Security Trends Report from Cenzic
> Stay Ahead of the Hacker Curve!
> Get the latest Q2 2008 Trends Report now
>
> www.cenzic.com/landing/trends-report
> ------------------------------------------------------------------------
>
>
> **DISCLAIMER
> This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which 
> they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the 
> intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the 
> message. If you have received this communication in error, please notify the sender and delete this e-mail message. 
> The contents do not represent the opinion of D&E except to the extent that it relates to their official business.
>
> ------------------------------------------------------------------------
> This list is sponsored by: Cenzic
>
> Security Trends Report from Cenzic
> Stay Ahead of the Hacker Curve!
> Get the latest Q2 2008 Trends Report now
>
> www.cenzic.com/landing/trends-report
> ------------------------------------------------------------------------

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Security Trends Report from Cenzic
Stay Ahead of the Hacker Curve!
Get the latest Q2 2008 Trends Report now

www.cenzic.com/landing/trends-report
------------------------------------------------------------------------