Re: [Full-disclosure] SSL VPNs and security
Why do I keep reading that IPSec provides full network connectivity? SC Magazine just repeated this nonsense. It only does that if you have it configured that way. Even Microsoft's PPTP L2TP free stuff can be limited. And you can configure an SSL VPN to do likewise. Ray From: Q-Ball [EMAIL PROTECTED] To: Tim [EMAIL PROTECTED] CC: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] SSL VPNs and security Date: Tue, 13 Jun 2006 15:13:45 +1000 SSL VPNs have their legitimate place as does IPSec. Personally, I'd rather that travelling exec's who need to log on from a public Internet terminal, dont have full IP connectivity into the network, but maybe that's just me. Q-Ball On 6/10/06, Tim [EMAIL PROTECTED] wrote: That depends on whether the solution tries to solve single-sign-on problems as well. If the vendor is trying to handle SSO in such an environment, then they are probably using domain cookies. The problems are exactly the same as the ones Michal listed, plus some additional ones specific to domain cookies. Right, that does make it difficult. There's probably work arounds, but they may be browser-specific. Wildcard cookies, cookies set to other origins, or somehow setting document.domain back to the base domain after the initial page load might help, but some would probably present the same problem. The web was never designed for complex application development. At least, web standards aren't. Use a real VPN. cheers, tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
Sure traffic can be filtered, but the point is that the layer 7 connection is terminated at the network perimiter rather than the internatl network which is typically much less protected. On 6/14/06, Ray P [EMAIL PROTECTED] wrote: Why do I keep reading that IPSec provides full network connectivity? SCMagazine just repeated this nonsense.It only does that if you have it configured that way. Even Microsoft's PPTP L2TP free stuff can be limited. And you can configure an SSL VPN to do likewise.RayFrom: Q-Ball [EMAIL PROTECTED]To: Tim [EMAIL PROTECTED] CC: full-disclosure@lists.grok.org.ukSubject: Re: [Full-disclosure] SSL VPNs and securityDate: Tue, 13 Jun 2006 15:13:45 +1000SSL VPNs have their legitimate place as does IPSec. Personally, I'd rather that travelling exec's who need to log on from a public Internet terminal,dont have full IP connectivity into the network, but maybe that's just me.Q-BallOn 6/10/06, Tim [EMAIL PROTECTED] wrote: That depends on whether the solution tries to solve single-sign-on problems as well.If the vendor is trying to handle SSO in such an environment, then they are probably using domain cookies.The problems are exactly the same as the ones Michal listed, plus some additional ones specific to domain cookies. Right, that does make it difficult.There's probably work arounds, butthey may be browser-specific.Wildcard cookies, cookies set to otherorigins, or somehow setting document.domain back to the base domainafter the initial page load might help, but some would probably presentthe same problem.The web was never designed for complex application development.At least, web standards aren't.Use a real VPN.cheers,tim___Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ ___Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/___Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
SSL VPNs have their legitimate place as does IPSec. Personally, I'd rather that travelling exec's who need to log on from a public Internet terminal, dont have full IP connectivity into the network, but maybe that's just me. Q-BallOn 6/10/06, Tim [EMAIL PROTECTED] wrote: That depends on whether the solution tries to solve single-sign-on problems as well.If the vendor is trying to handle SSO in such an environment, then they are probably using domain cookies.The problems are exactly the same as the ones Michal listed, plus some additional ones specific to domain cookies.Right, that does make it difficult.There's probably work arounds, butthey may be browser-specific.Wildcard cookies, cookies set to other origins, or somehow setting document.domain back to the base domainafter the initial page load might help, but some would probably presentthe same problem.The web was never designed for complex application development.At least, web standards aren't.Use a real VPN.cheers,tim___Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
Hello MZ, I think SSL VPNs are a pretty lame idea in the first place, but for the specific problem you bring up, would the following design work around this? Set up a wildcard record, *.webvpn.example.org, pointing to the device. The device then maps all internal domain names or IP addresses to a unique hostname, such as: internalhost.webvpn.example.org, or 192-168-0-1.webvpn.example.org, etc. Wouldn't this properly segment different internal sites, such that an XSS in one wouldn't impact the other? If so, pay attention all SSL VPN vendors: it is your free idea for the week. tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
On 6/9/06, Tim [EMAIL PROTECTED] wrote: Set up a wildcard record, *.webvpn.example.org, pointing to the device. The device then maps all internal domain names or IP addresses to a unique hostname, such as: internalhost.webvpn.example.org, or 192-168-0-1.webvpn.example.org, etc. Wouldn't this properly segment different internal sites, such that an XSS in one wouldn't impact the other? If so, pay attention all SSL VPN vendors: it is your free idea for the week. That depends on whether the solution tries to solve single-sign-on problems as well. If the vendor is trying to handle SSO in such an environment, then they are probably using domain cookies. The problems are exactly the same as the ones Michal listed, plus some additional ones specific to domain cookies. - Brian ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
Set up a wildcard record, *.webvpn.example.org, pointing to the device. The device then maps all internal domain names or IP addresses to a unique hostname, such as: internalhost.webvpn.example.org, or 192-168-0-1.webvpn.example.org, etc. This has the side effect of making procurement of the SSL certificates *very* expensive. /mike. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
That depends on whether the solution tries to solve single-sign-on problems as well. If the vendor is trying to handle SSO in such an environment, then they are probably using domain cookies. The problems are exactly the same as the ones Michal listed, plus some additional ones specific to domain cookies. Right, that does make it difficult. There's probably work arounds, but they may be browser-specific. Wildcard cookies, cookies set to other origins, or somehow setting document.domain back to the base domain after the initial page load might help, but some would probably present the same problem. The web was never designed for complex application development. At least, web standards aren't. Use a real VPN. cheers, tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
Set up a wildcard record, *.webvpn.example.org, pointing to the device. The device then maps all internal domain names or IP addresses to a unique hostname, such as: internalhost.webvpn.example.org, or 192-168-0-1.webvpn.example.org, etc. This has the side effect of making procurement of the SSL certificates *very* expensive. SSL certificates are free. You just have to have enough knowledge to distribute your own CA certificate. For a VPN appliance, this should not be a problem at all, since only your trusted users should be accessing it. Even if you aren't competent enough to figure out how to distribute your own CA certificate, I believe there are such things as wildcard certificates. tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
SSL certificates are free. You just have to have enough knowledge to distribute your own CA certificate. For a VPN appliance, this should not be a problem at all, since only your trusted users should be accessing it. Even if you aren't competent enough to figure out how to distribute your own CA certificate, I believe there are such things as wildcard certificates. Great .. setup a SSL vpn, then tell your users it's okay to click yes on the untrusted certificate popup. Sure, it's trivial to create self-signed certs (or run a CA), but distributing your cert (or the CA cert) to all but a handful of clients is a logistical nightmare. If you're going to be installing stuff, might as well make that a IKE/IPSEC client and do it the right way to begin with. /mike. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
Sure, it's trivial to create self-signed certs (or run a CA), but distributing your cert (or the CA cert) to all but a handful of clients is a logistical nightmare. For company managed laptops, it is trivial to distribute via normal software distribution processes. For non-managed systems (which you shouldn't allow into your network via a VPN anyway), installing a CA cert is as simple as clicking on a link ONCE, and installing the cert. This cert can be distributed over a VeriSign secured SSL connection. Then when the website presents a page, it can dynamically sign certs for each domain. This stuff isn't really that hard. The tools that the industry has provided users just suck, that's all. If you're going to be installing stuff, might as well make that a IKE/IPSEC client and do it the right way to begin with. Well, I don't disagree with this one, but so many people who complain about certificate distribution have not thought through the ways it can happen. Even with a real VPN, you really should be using client certs anyway, which present the same distribution problems. These problems aren't made any easier by using a trustyworthy CA which charges you. The software you use is the biggest contributor to management headaches. tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
On 6/9/06, Tim [EMAIL PROTECTED] wrote: For non-managed systems (which you shouldn't allow into your network via a VPN anyway), installing a CA cert is as simple as clicking on a link ONCE, and installing the cert. This cert can be distributed over a VeriSign secured SSL connection. Are you referring to telling end-users to click Accept this certificate permanently box on the certificate warning pop-up? Or is there a software package out there that can do this without the warning pop-up? - Brian ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SSL VPNs and security
Are you referring to telling end-users to click Accept this certificate permanently box on the certificate warning pop-up? Or is there a software package out there that can do this without the warning pop-up? In Windoze, if you have a .cer file, and did the use fields correctly when you issued it, the cert will go into the right certificate store automagically. You'd just link to that file somewhere and tell people to right click, save to desktop, then double-click it there. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] SSL VPNs and security
Web VPN or SSL VPN is a term used to denote methods for accessing company's internal applications with a bare WWW browser, with the use of browser-based SSO authentication and SSL tunneling. As opposed to IPSec, no additional software or configuration is required, and hence, corporate users can use pretty much any computer they can put their hands on. [ Yes, this is a very bad idea, but often also a perceived business necessity. To counter the risk, some SSL VPN solutions may perform client-side security checks with the aid of an applet or control not marked as safe. This is, of course, a silly and bypassable design, and has a side effect of teaching the user to click yes on scripting safety prompts. But I digress... ] [ These solutions are sold, among others, by Juniper, Nortel, Nokia, Cisco. The following observations are based on Cisco Web VPN (and your mileage with this and other vendors may vary). In their most basic operating mode, SSL VPN systems simply act as a HTTPS authentication and authorization proxy that relies on session cookies, and a URI-based request rewriting and forwarding engine. Such a configuration enables the user to access any HTTP or HTTPS based Intranet applications; web-based clients for some other protocols are also sometimes included. [ With the help of various controls and applets again not marked as safe, SSL VPNs can also forward local TCP ports through that tunnel, if unsupported network protocols need to be used. ] A good example: let's say there's an user who wishes to access his corporate Outlook Web Access interface from a remote location. The usual URL for the intranet service is: http://owa/exchange/lcamtuf/inbox To access it over the Internet, that fellow needs to navigate to https://webvpn.foocorp.com/, enter his credentials, collect a session cookie, and then go to (or be redirected to) something along the lines of: https://webvpn.foocorp.com/http/0/owa/exchange/lcamtuf/inbox ...which, if the cookie validates, would be translated to the original URL and allowed to go through, with SSL VPN acting as a proxy. Commercial SSL VPNs are a fairly recent technology that has a considerable appeal to various corporations. Because of its novelty, however, in a typical setup it may be subject to several serious security flaws, unless very carefully designed. Possibly the most important problem is that web VPNs break the customary browser security model that relies on domain name separation for the purpose of restricting access to cookies and other objects. Browsers generally allow foo.com to interact with own cookies or windows, but prevent the site from accessing resources related to bar.com. Yet through SSL VPN, they all may look the same: https://webvpn.foocorp.com/http/0/foo.com/serious_work https://webvpn.foocorp.com/http/0/bar.com/fun_and_games Because of this design, all pages displayed through a Web VPN interface are lumped together. Whenever a page (or just a HTML fragment) that can be controlled by the attacker is displayed by *any* of the applications behind Web VPN, Javascript can access: - Web VPN session cookie, which can be then passed to the attacker. This is equivalent to the attacker obtaining access to all protected systems and compromising Web VPN altogether. The threat could be mitigated by associating the cookie with client's IP, but such an approach is not always implemented, and is impractical with AOL and the likes. - Application cookies set by other applications. If passed to the browser (as some SSL VPNs do), these cookies are separated by the use of path parameter alone, which does not necessarily establish a browser security domain boundary. This is equivalent to the attacker obtaining user credentials to these applications. Some commonly used corporate applications may indeed serve attacker-supplied contents, making these attacks virtually inherent to most SSL VPN deployments: - Various web mail systems, such as Outlook Web Access (OWA), may serve HTML attachments and other documents received from the Internet without providing an adequate browser warning. Although this is a security challenge by itself for all web mail interfaces (where there is a risk of stealing web mail session coookie), the access to all SSL VPN cookies make the impact far more serious. - Trivial cross-site scripting flaws in *any* available intranet application may compromise the entire SSL VPN. Because these applications are usually complex, aplenty, and all under-audited, existence of such bugs is pretty much a certainty. - Trivial cross-site scripting bug in SSL VPNs themselves may endanger the entire system. Impossible? Cisco SSL VPN has this: https://vpnhost/webvpn/dnserror.html?domain=ufoo/u (and yes, they seem to be aware of this, but have no specific timeline for fixing it - so I suppose it's OK to report
