Moving to a new domain

I will be starting the transfer of this blog over to it's new home at Secure Tomorrow. I will be moving it over to the new domain tonight and it will [hopefully] get a face lift in the coming weeks. For those of you who read this blog via RSS, please update your news readers to point to http://www.securetomorrow.org/atom.xml. For those who read this blog through Live Journal syndication, you do not have to do anything. Hopefully the transition will be as painless as possible. If you have any problems feel free to leave a comment in the blog and I will address it.

kb

Big brother is at it again, and again

It seems your friendly neighborhood eye in the sky [the NSA] has made it into the news not once but twice in the past month or so.

Recently New Scientist Tech had an article about how the Pentagon's National Security Agency is setting its sights on social networking websites. Now to others already in the security field, this is a "well duuuh" moment. The best piece of advice I ever heard someone give to a friend who had recently discovered the "internet" was "don't put anything on the internet you don't want everyone in the world to know." Truer words were never spoken. Now I am not saying secure data is impossible over the internet. I mean if that was the case, guys like me would be out of a job,lol. But... for your average user of social networking sites, it's a fair assumption that it's out in the open and more then likely, people are putting information about themselves, their wild weekends, etc without realizing the full scope of their actions. As I said, if you are already in the security or privacy mindset it's a "well duuuhh" statement. To most users, they just don't think that way. I am hoping with blogs like mine and others like myself that we can help educate average users and hopefully put them more in a mindset where they think before they post. Whether it be the government, a hacker, or maybe that creepy guy from the bar you refused to give your number to, do you really want them having access to everything you post on your myspace page? Most people put that information up assuming that the only one who would be interested in that info would be other friends or [insert average 16 year old girl myspace user] *giggle* that cute boy from home room with the dreamy eyes. You get the idea. I think it's up to all of us to help educate these people and remind them to think twice before posting personal information on these sites. Read over the article, it's a good read.

New Scientist Tech also had another article. Last month, people were amazed (well some people *snicker*) when it was revealed that the NSA has been collecting records of domestic and business phone calls since shortly after the terrorist attacks of 11 September 2001. I will not go into detail too much on this one. The article sums it up nicely, plus it starts walking that line between keeping this blog technical and not discussing topics relating to any particular political view. This is more of a "discuss with friends" or a topic to let marinate in your head a bit and draw your own conclusions. I will mention that the NSA has been collecting this info WITHOUT (WIRETAP) WARRANTS, a step deemed necessary after 9/11 by some. In fact, some in the current administration seem to think that this should become more of a standard as they feel current wiretap laws are insufficient in this post 9/11 America. Where do we draw the line? Decide for yourself.

Article Repost: "SSL VPNs and security"

* Thanks go out to Michal Zalewski for a well written article and giving me permission to repost it here.


SSL VPNs and security
Michal Zalewski (lcamtuf dione ids pl)
Original Article URL: http://www.securityfocus.com/archive/1/436479/30/0/threaded

"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:///webvpn/dnserror.html?domain=foo
(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 it; hi Larry Seltzer).

[ The possibility of allowing Internet access through Web VPN is something I wouldn't even consider here. ]

Additional problems may arise when SSL VPN gateway IP is added to "trusted zone" for the purpose of making certain intranet applications work the way they worked locally at the office.

Yes, these problems are hardly new, and can be mitigated with some very careful design, and some vendors may be doing it properly - but I think that the following needs to be said:

- SSL VPNs may easily turn negligible and common security issues such as XSS into a considerable corporation-wide threat; and preventing this is hard.

- Most SSL VPNs may be "secure by design" only in fairly unrealistic situations or limited uses.

- Unless the vendor takes the effort to precisely and honestly explain how they mitigate these specific threats, it is safe to assume they might be not doing it properly (or not doing it at all).

Since these issues are generally not seriously discussed by vendors in assessments of their products (say, http://www.cisco.com/web/about/security/intelligence/05_08_SSL-VPN-Secur
ity.html), I would assume that extreme caution needs to be exercised.

Flame on.

Regards,
/mz

Encrypting your Instant Messages

As some of my readers know I am a big proponent of encryption. Well I mean who isn't ;-) But I feel too many times people overlook the use of it or don't take the minimal steps to use it when it takes little effort and keeps [possibly] sensitive information away from hackers or others snooping your network connection. I came across a blog post by a peer of mine that offers a nice little write up about setting up encryption on your instant message client. It's worth a read and encrypted instant messaging is something everyone should get into the habit of doing.