VPN services thru firewall was: Gauntlet & NTLM

[Craig Brozefsky <craig () onshore com>]

On Mon, 13 Oct 1997, Linwood Ferguson wrote:

> > Craig Brozefsky <craig () onshore com> wrote:
> > <elided>
>
> Let me put it in perspective however.  Our alternative to this is people
> who come in via dialup NT RAS (to the inside of the firewall), or people
> who telnet through the TIS tn gateway and then log into some internal 
> system with clear text passwords.  I don't offer either of these as 
> examples of great security, just what-is; so what I'm looking for is 
> something that is somehow better: either cheaper, more secure, better
> performance, or ideally all three.  I'm also looking for something 
> implementable in our situation -- which is stapped for resources and time.

This is my concern also.  I'm more interested in directing the 
conversation towards technological solutions to this problem, not product 
solutions.  I hope you don't mind if I delete alot of the stuff below to 
save time, and summarize my concerns and the possible exploits I see 
opened up via your firewall configuration.  I would like us to focus our 
attention not on trashing PPTP, but perhaps on coming up with ways to 
cheaply give secure acces to our mobile and remote users over the 
Internet TCP/IP backbone.

> Here's how we were looking at it, I guess.  Microsoft offers this as 
> "secure" and says it is safe to connect directly.  TIS says there are no
> additional vulnerabilities introduced by opening this hole, only whatever
> ones might be in the NT server that it connects to.  

I disagree with both companies, or at least the representatives you 
discussed this issue with.  PPTP as it stands in the draft standard far 
from adequatly addreses major security issues.  The L2TP draft and the 
security extensions as described by the IETF PPPEXT working group does 
address some of the security issues I had brought up, primarily key 
regeneration and two way authentication.  I do not have intimate knowledge 
of MSs implementation and I wonder if someone could tell me which aspects 
of the L2TP sec extensions, if any, it implements.  

Also, the opening of hole which regulates based on protocol number is IMO 
problematic because it allows not only covert channels in and out from 
the NT machine to outside hosts, but it also assumes that the IP stack on 
that machie will handle those packets correctly, something we have seen 
NT have problems with.  Outside of the OS which is running on your LNS I 
still believe that the control and management of such connections should
take place at the firewall.

Perhaps a better solution would be using the firewall as the LNS (the 
machine terminating PPTP connections).  That way your data can be 
encrypted right up to the external interface of the firewall, unwrapped 
and passed thru the stack just like any other packet, thus allowing your 
filtering rules to take effect.  This is much like how TIS does their 
VPNs.  You also will not be opening a network level hole to your 
internal netwrok, (ie your permit protocol 47 to any port on NT host).

> Is NT as secure as a
> TIS customized BSD?  No, probably not.  Does it introduce new
> vulnerabilities by allowing it inside?  Probably.  But does it introduce
> more than allowing RAS dialup inside?  Than our current internet access
> over telnet?  I do not know, but it _seems_ a step up, if not a step
> all the way to the top of the "secure" ladder.

It does.  MITM attacks on your RAS dialups are much more difficult, and 
require usurping telco equipment (having your dialin lines forwarded to 
attackers modems).  Sounds extroidinary, but I've seen the results.  PPTP 
does offer benefits to those coming into your network from other dialups 
across the internet, but it is also much easier to use a MITM attack 
unless utilizing the extensions described in the draft-ietf-ppext-sec 
document.

The telnet access is just plain funny unless your using OTP system or 
something.  I suggest possibly ssh.

For application specific purposes, I have used a SLL based proxy software 
which forwards a connection from one machine to another encrypted in 
between.  The software was written in Anguilla so we were able to arrange 
for an international distribution with full strength crypto. It required 
no modifications to the application to incorporate this security.

> What would help greatly in our understanding of this is someone who could
> say "here is a specific example of how this breaks", like a known way to 
> attack it (+/- encryption key lenth, see below).  Do I trust Microsoft
> completely?  Of course not.  But it seems a step up, and 
> saves lots of money to boot, and gets rid of lots of modem issues as 
> icing on the cake (let the ISP's worry about that).  So it is very 
> attractive. 

Break what? PPTP? L2TP? L2TP with which security extensions? Denial of 
service or eavsedrop?

> I don't mean to sound argumentative, but as a non-expert, I have had 
> several people tell me I've opened a hole, but not one showed me that 
> anything could drive through it.  Can it?

They explained to you the risks of opening that hole, what more do you 
want? Sploitz?  Yes, things can drive thru there, covert channels in and 
out of the network assuming the NT box is compromised, or the user 
information it authenticates with becomes compromised.  Depending on MSs 
implementation (I wish I could find some in depth docus on it anyone? 
anyone?) denial of service attacks are feasable.  If they only implement 
the PPTP draft as it stands MITM and denial of service attacks are 
definetly possible.

> OK, help me out here.  The last part sounds much more of a concern.
> Assuming we "trust" the NT, that does not mean we trust all other inside
> systems, in fact those systems are rather light in their defenses on some
> fronts.  Does this mean there is someway to send GRE packets through the
> firewall to another system (despite the forwarding directing it
> specifically to the NT?).  Or that the NT might forward the packets 
> elsewhere?

I do not know enough about NT's handling of GRE encapsulated payloads to 
give a conclusive yes or no answer on wether it can be exploited.  The 
GRE draft does provide mechanisms for the forwarding of payload data once 
it reaches it's destination (RFC1701 sect. "Forwarding of GRE Packets".  
This could be used to encapsulate IP packets and bounce them off this now 
exposed NT machine.  It depends on how NT handles GRE, and wether it 
only handles those GRE packets which are setup by a PPTP control channel 
and have a PPP payload rather than a IP payload.

> Help me out here.  Let's assume someone does actually intercept the
> stream, and cares to take the trouble to decrypt it.  Is there something 
> they can do with that data to compromise our network?

Uhm, see the data.

> Or have they simply intercepted a terminal session from one of our  remote
> users?  If the latter -- I don't want to say 'who cares', but anyone going
> to that much trouble can get it much easier.  We're not a bank or NSA, and 
> the lamest attempts at a bit of social engineering would get them much
> further and more interesting stuff than seeing some e-mail from home.

Not all of us deal with such relaxed situations, not to imply that it 
means your l4m3 or s0m3thing, just that some information is worth more 
than others.  Eavesdropping on sessions that a user assumes are secure 
leads to several problems, passwords being entered across them, sensitive 
data being revealed...

> Now I am much worried if something in that stream gives ready access
> to IP connectivity to the inside.

Why just IP connectivity?  I don't need to have IP connectivity to your 
network to grab data or to penetrate further inside.  I guess if you 
assume that only those people with IP specific exploits and tools that 
only work over na IP connection re going to mess with then your stance is 
alright.

> However -- my understanding (which I have not pursued) is that Mircosoft
> offers USA users a 128 bit version.  Do they not?

Not according to the documentation I saw, could someone clarify this?

> Thanks again for your feedback.  I hope you don't mind my questioning 
> specifics of why you think it is more vulnerable. 

Not at all.


Craig Brozefsky              craig () onshore com
onShore Inc.                 http://www.onshore.com/~craig
Development Team             p_priority=PFUN+(p_work/4)+(2*p_cash)
I hear my inside, the mechanized hum of another world - Steely Dan