Secure Tomorrow

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 [feed link no longer valid as of 1/09]. 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

Kevin Blanchard site maintenance

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.

Kevin Blanchard NSA, social networking

* 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

Kevin Blanchard SSL, SSL VPN, VPN, Web VPN

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.

Kevin Blanchard encryption, instant message

vnunet.com has an article running right now about China’s new law regarding email servers. An interesting and scary looking into the tight hand China uses to control it’s people and “it’s internet”.

“China has introduced regulations that make it illegal to run an email server without a license. The new rules, which came into force two weeks ago, mean that most companies running their own email servers in China are now breaking the law.”

Full Article

Kevin Blanchard China, email, Microsoft Office

According to Tim Callan at Verisign:

VeriSign reports that many public-facing Web sites continue to implement an older and less secure version of VeriSign’s popular security mark. Because the old VeriSign site seals were created and distributed prior to the rise of phishing, they did not contain the full set of anti-spoofing measures available in the newest version of the VeriSign Secured Seal. For the protection of online consumers, VeriSign is in the process of phasing out its old-architecture seals and moving forward with support only for the newest version of the VeriSign Secured Seal. Old-version seals are in a round, “gold or silver medallion” shape and call their verification page from https://digitalid.verisign.com. Latest-version seals contain the black VeriSign check mark in a red circle and the words VeriSign Secured and call their verification page from https://seal.verisign.com. All Web sites employing one or more VeriSign SSL Certificates in their validity period are entitled to display the VeriSign Secured Seal to improve site visitor confidence and increase visitor propensity to complete transactions. These customers can download the latest version of the VeriSign Secured Seal free of charge at http://www.verisign.com/seal.

Kevin Blanchard SSL, VeriSign

Not much more to say about it. If you use it, you are probably as excited as I am. If you don’t… then go download it. It’s a valuable tool that should be in any security engineers arsenal.

Related links:
Documentation: http://www.insecure.org/nmap/docs.html
Download: http://www.insecure.org/nmap/download.html
Release Announcement: http://www.insecure.org/stf/Nmap-4.00-Release.html

Kevin Blanchard network security, Nmap, system security, website security

SANS diary had a neat little trick posted a couple weeks back. For those of you who use Nmap quite a bit or as part of their day to day at work, here’s a tip that might help make your work week a bit more bearable. You are aware of the XML output from Nmap but what the heck do you do with it? Perl has a module that just might help you out called NMAP::Parser. This might make your job analyzing or reacting to your findings a bit easier. If you still aren’t 100% clear on how you might use it, here is more information along with an example.

Kevin Blanchard network security, Nmap, system security, website security

There is a great article over at ranum.com discussing what the author views as the six dumbest ideas in computer security. Many of the ideas are ones others have brought up in the past but cost or reduction of usability seem to win over security. A quick but educational read.

Kevin Blanchard

Hot off the SANS presses.

An exploit for MS05-017 (that place-holder “0″ in front of the 17 inspires confidence, doesn’t it?) is now available as part of the Metasploit Framework, so if you aren’t patched… well, why aren’t you?

MS05-017 (Vulnerability in Message Queuing Could Allow Code Execution / CAN-2005-0059 / KB892944) was part of Microsoft’s April 2005 release and more information can be found here;. I’ve not had a chance to test this yet, but H.D. is pretty amazing, so I don’t have much question that it works.

Kevin Blanchard Metasploit, Microsoft