The Security Skeptic

Shortly after 911, airline passengers were expected to provide positive identification at a security checkpoint before proceeding to a departure gate. At the gate, passengers again showed positive identification at the departure gate before boarding the aircraft. Today, travelers are rarely asked to show IDs at departure gates. Most travelers would agree that this is a small blessing, one less inconvenience to cope with while tolerating air travel (I use tolerate intentionally because I know of no one who enjoys flying these days).

Let's consider the risk that authenticating only at the perimeter introduces to air travel security. Two individuals, Bob and Dick, depart from the same originating city with different destinations After showing positive identification and proceeding through the security checkpoint, Bob and Dick meet and exchange boarding passes. The probability that Bob or Dick will be challenged for identification is small, so Bob can now traveling to Dick's destination and Dick to Bob's. Under the current implementation, proving one's identity at a security perimeter makes it trivial to evade an important authorization policy; specifically, individuals are expected to travel according to their itinerary.

As my partner Lisa Phifer observed when I shared this observation, the boarding pass is treated as a very primitive form of security token, one that is weakly bound to an identity. My problem is that, weak or no, this token nonetheless provides the holder with an authorization to board an aircraft without proof of identity. Specifically, it can be exploited to allow an impersonator board any flight for which he can obtain (without incident) and credibly spoof the party identified by a boarding pass, and this seems pretty easy.

The airline identification policy is an example of perimeter authentication. We find examples of a similarly exploitable Internet security policies among organizations that connect remote offices to a main office using an IPsec site to site tunnel via security gateways (firewalls). In many configurations, the remote and main office security gateways perform mutual authentication using IKE. The IPsec security associations used to accommodate remote office access often base allow/deny policies traffic from remote sites on the IP addresses used at the remote site. An IP address is easily spoofed by an attacker who gains access to a LAN or WLAN at a remote office. That attacker now has the equivalent of an identity authenticated at the perimeter (the remote office security gateway) and a boarding pass (the spoofed IP address), and can thus connect to a server that the IPsec SA allows from the spoofed IP address.

Absent user level authentication that is additionally performed at the individual servers, this is an inherently weak and exploitable policy and should be avoided.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID631 by Dave Piscitello  

Today's workforce requires access to whatever applications they need to conduct business, transparently, from any location, when convenient and necessary, using any device, over any network. As I explain in this July 2005 BCR Magazine article, shifting from "tightly controlled" requires going beyond traditional remote access VPN solutions.

Archived at http://www.securityskeptic.com/arc20050801.htm#BlogID442 by Dave Piscitello  

I recorded a webinar for Aventail Corporation on Friday the 13^th. The recording went well in spite of the less than fortuitous date. The first broadcast of the webinar is May 24, 2005, 2:00 pm US Eastern Time. If you are interested, you can register at eSecureLive.

I intend to follow up with an "opinion piece" article on this topic early this summer.

Archived at http://www.securityskeptic.com/arc20050501.htm#BlogID405 by Dave Piscitello  

NISCC reported several vulnerabilities in IPsec's encapsulating security payload implementations. When a CBC mode encryption is used for confidentiality without a companion message integrity check, attackers can use bit-flipping techniques to modify the destination IP address, IP options, and IP PROTOcol field of the ESP payload (the encapsulated IP packet); worse, they can result in the result in the complete decryption of encapsulated IP packet. For a full description ,see CVE CAN-2005-0039.

Bit flipping attacks against CBC encryption algorithms are not new. Bruce Schneier and Mudge disclosed a similar vulnerability in Microsoft's early PPTP implementation of MPPE. Cisco has a very good and readable description of the well-known bit-flipping attacking against the IEEE 802.11 ICV to derive a key stream: IEEE 802.11 has since replaced WEP with successively more robust integrity checks in WPA and WPA2.

See a pattern here?

We know certain confidentiality algorithms don't protect individual bytes against modification. This is one reason we use message integrity checks.

Is the sky falling? No, because we know the answer is "always use the strongest *set* of security parameters available when configuring IPsec security associations". If you always insist on both the strongest confidentiality algorithm *and* strongest integrity algorithm, and you complement these with the strongest authentication, key refreshing, and perfect forward secrecy, you shouldn't have to worry about bit-flipping attacks, or (practically speaking) most any attack against your "cipher set" (oh, that's an SSL term, sorry!)

Organizations who create IPsec SAs that don't include a signed hash are like automobile drivers and passengers who assume air bags will protect them and so choose to sit on their seat belts rather than buckle them. They are ignoring a simple measure and an excellent opportunity to reduce their risk. Cars come with seat belts and airbags. You don't have to use both, but your chances of a close encounter of the windshield kind are greater if you choose to sit on your seat belt rather than buckle up.

Archived at http://www.securityskeptic.com/arc20050501.htm#BlogID400 by Dave Piscitello  

My white paper, Next Generation Secure Application Access, is available in pdf here. This work for hire for Aventail Corporation examines past and current secure remote access; identifies objectives still not satisfied by existing solutions; and explains how Aventail's Smart SSL VPN meet the objectives I define.

Archived at http://www.securityskeptic.com/arc20050501.htm#BlogID396 by Dave Piscitello  

A firewall-wizards mailing list colleague made note of a recently released NTA Monitor white paper on VPN deployment that reported three key results: (1) 90% of remote access VPN systems have exploitable vulnerabilities; (2) new security flaws have been identified, and (3) VPN deployments generally fail to implement best security practices.

(1) doesn't surprise me. VPNs are software. Software development, even in many security products, is not meeting secure code development standards. Sadly, VPNs were and remain susceptible because they have all the trappings of a "haste-to-market" product: major paradigm shifts in user access (teleworkers, wireless mobility, public broadband); broad competition for a lion's share of a lucrative market opportunity resulting from these shifts; and a technology that was very easily (mis)represented as a panacea to a user community overly influenced by FUD. Honestly, given the hype surrounding VPNs, and the money at stake, is it really any wonder that users perceived VPN systems to be invulnerable?

(2) ought to be "old news". Folks involved with VPNs, particularly IPsec, have known about user enumeration and offline password cracking for a while. Aggressive Mode IKE is a flawed standard. IKE extensions like XAUTH pile one flaw onto another. Anyone who monitors a firewall log can't help but notice the consistently high frequency of IKE probes. A let's not overlook what's not stated here: if you begin by using a user account or email address as a user ID for remote access at a machine level, and persist in using easily remembered passwords, have you really made the best possible choice for identity and authentication?

(3) is an accurate conclusion to draw concerning security in general, and it's not exclusive to VPNs. Security practices are lax, and folks ought to test more frequently, with quality tools. Is this really a press-release quality conclusion, or an attempt at garnering 15 minutes of fame?

My gripe with NTA Monitor's report isn't that what they conclude is wrong, but that they

paint such a misleading and self-serving picture. It's not like VPNs are creating more security holes in networks than existed when people were using telnet/ftp and other plaintext protocols over not-to-be trusted links. It's not the fault of VPN technology that people choose to use email addresses and guessable user names and crappy passwords - these ended up in standards because too few organizations want to make an effort to use a better identity and authentication method. Unfortunately, people make bad choices then wonder why they get blindsided.

Kevin Sheldrake accurately and succinctly summed up what I believe is the 90% case of the real situation:

I don't doubt that a badly configured VPN is insecure and that statistics can claim how many are probably insecure, but I do think that the focus is incorrectly directed at the VPN technology and not at the users/admins/consultants/whoever.

Use certificates. Don't use Aggressive Mode. Patch the software. Don't spread FUD unless you have to. ;)

The other 10%? Fix the standards, clean up the code.

Archived at http://www.securityskeptic.com/arc20050201.htm#BlogID360 by Dave Piscitello  

The term SSL VPN was adopted in the late 1990s by vendors who needed to distinguish secure access by the authenticating and encrypting protocol they used. Your solution was proprietary, SSH-, SSL-, or IPsec-based, hence SSL VPN. Today the term is dreadfully constraining and is more confusing than helpful in describing what SSL VPNs are and do. More...

Archived at http://www.securityskeptic.com/arc20040801.htm#BlogID296 by Dave Piscitello  

From the Ethereal-Users mail list...

Subject:

[Ethereal-users] DECRYPTING IPSEC / ESP PACKETS

Message body:

Hi,

does anybody know, how to decrypt ISPEC / ESP Packets to see the real packets ?

Later, someone commented, "Use TCPDUMP -E". Yes, you can use TCPDUMP with this option, if you've compiled with cryptography enabled and you know the shared secret key for ESP. The man page for TCPDUMP also adds, "The option is only for debugging purposes, and the use of this option with truly 'secret' key is discouraged."

Somehow, I don't think this is the answer the original poster wanted to hear...

Archived at http://www.securityskeptic.com/arc20040801.htm#BlogID292 by Dave Piscitello  

Virtual Private Networking is passè. More accurately, what we considered when we began designing and deploying VPNs nearly a decade ago - protocols enabling authenticated, encrypted tunnels to transport authenticated data - has become less important, a mere part of the picture instead of the whole. Questions like "Which protocol is best?" and "Which encryption should I use?", are now less relevant than, "How can I satisfy my application access and security requirements?", and "Do I really want this device connected to my network?"

This is A Good Thing, and typically the consequence of practical deployment experience. Watching The History Channel's 10 Days to D-Day, I pondered how little has changed with regard to how technology evolves, and how often we can do better with small adjustments instead of wholesale re-engineering.

Consider the ingenuity demonstrated by the Allies when they encountered hedgerows in the Bocage, France. The first waves of tanks were easily destroyed by German anti-tank weapons as they exposed their thinly armored undercarriages while attempting to climb over the hedgerows. Several strategies were considered:

1. Attempt to modify undercarriage armor on thousands of Shermans in the field;

2. blast through the hedgerows using explosives;

3. use bulldozers.

(1), a classic standards body approach, involves all sorts of recalculations to minimize the impact of the added weight to the tank's overall performance. It fails to consider the impact of delay on the installed base. It reminds me of IKEv2.

(2), a brute-force or administrative fiat approach, overlooks the small matter of how noisy explosions tend to disclose troop locations, and reminds me of policy definitionwithout an impact analysis. I could be cruel here and say it also fails to consider an exit strategy, but I won't...

(3) is very practical, but the Allied war machine was implemented to crank out many more Shermans than bulldozers. Re-tooling the war machine makes less sense here than (1) since ultimately, we'd need a lot more tanks than bulldozers.

The solution? The Allies turned Shermans in the field into bulldozers using railroad tracks. This field modification was refined so that the "rhinoceros" Shermans mowed through the hedgerows with an improvised cutter.

I'm tempted to draw an analogy between rhinoceros Shermans and the evolution and adoption of SSL for secure remote access. SSL was in the field. It was readily available. It could be easily adapted to satisfy secure access in a much shorter timeframe than an IKE redesign and field upgrade. Folks in the field who understood the problems and needs jury-rigged a secure access alternative that could get the job done quickly.

Someone could make the argument that improving IKE is the appropriate long-term solution since an IP level VPN protects application and transport payloads. Improving the undercarriage armor of a Sherman in 1944 could arguably have been the right, long-term course as well.

Archived at http://www.securityskeptic.com/arc20040601.htm#BlogID262 by Dave Piscitello  

My article, Re-emergence of SSL VPNs, was selected by IT Business Edge as among "the 10 most useful insights to have recently hit the Web on VPNs, intrusion detection and other hot security issues."

IT Business Edge also lists VPNs: Tunnel Visions as the #1 article on the list, written by my brilliant partner, Lisa Phifer.

This is one of the few times I imagine, "gee, if only we had more than two employees..."

I've copied my article from its blog entry to a separate web page..

Archived at http://www.securityskeptic.com/arc20031201.htm#BlogID177 by Dave Piscitello  

When I publish an article about a security technology, I'm sometimes contacted by capital investment firms. They all ask the same questions, and it's obvious they are data mining in hopes of identifying a technology segment where they have the best chance of making a killing on an early investment, with of course, the lowest risk.

I recently was asked about SSL VPNs, having written a BCR column in April 2003 on this subject. I won't identify the investor, but I'm happy to share the exchange with you:

1. Is an SSL VPN a "point product" that can/should be sourced separately, or

   Yes, I think SSL VPN appliances, as they are shipped today, are point products. Vendors in this space have to incorporate other functionality - load balancing, transaction acceleration, perhaps application protection - to survive and grow a market share. It's pretty certain that the big firewall and switch/router players will incorporate SSL as yet another protocol for remote access. F5 just bought uRoam. Nokia will probably integrate ssl and firewall product lines. Cisco will buy *someone*.

2. Should it be part of IDS, Firewall, or other network security applications?

   I think there will always be a tension between incorporating everything into one appliance/system and having multiple security systems. It's hard to do IDS in one place - intrusion and DDOS prevention might become part of most firewalls, but then, isn't that what firewalls are supposed to do?

   Here's an example of the "integrated vs. standalone" conundrum. My opinion (you asked) is that remote access is something you may *concentrate* in a large organization or outsource to a managed service provider, so an VPN RA concentrator has a market on which to survive/thrive as a separate product. Look at Nortel's Contivity switch for IPsec RA. In my opinion, I wouldn't use it as my Internet firewall, and doesn't do IDS or intrusion prevention, but it will garner a good share of the market because it does one thing very well. OTOH, CheckPoint will maintain a big chunk of the market for everyone who thinks "one box is all I should need". Folks will run IPsec RA on CheckPoint firewalls (and hence use an integrated solution).

   IMO, the question isn't "should SSL VPN be incorporated into firewalls", but "when will..."

3. Who would be considered SSL market leaders? The up-and-coming players in the market? Of the dozen or so SSL players you name, which do you think can thrive independently?

   I'm not a big fan of Gartner, but here's their widely heralded and criticized Magic Quadrant. Let me be clear that I don't put much stock in this kind of analysis.

   I think Aventail has the experience to do well in this market, however, I must tell you that I've worked with and for Aventail for many years, so my insight into what they do (well) is considerable compared to other SSL VPN players. I designed an SSL VPN with their software for DuPont 4 years ago and it supports tens of thousands of users today. And that was with a software-based product, not their appliance. Neoteris is supposed to be very good but I haven't tinkered with it. SafeWeb seems savvy,and a lot like Neoteris. Rainbow has a good integrated two-factor authentication and SSL product. Whale is a very top end enterprise (expensive and powerful) solution. Lots of others are "who knows?"

4. Likewise, of the dozen SSL players you name, who do you think will likely be consolidated? Who do you see as likely consolidators?

   I honestly can't say. I spend time looking at technology not quarterly reports and SEC filings. You might want to talk with Michael Suby at Stratecast Partners.

   Archived at http://www.securityskeptic.com/arc20030901.htm#BlogID113 by Dave Piscitello  

Originally written for Networld+Interop 2003 Las Vegas Preview

For years, organizations have sought to secure private communication over the Internet using Virtual Private Networks based on IP Security (IPsec VPNs). The process has proven more time- and resource-consuming than expected, but at this point, many organizations, large and small, have succeeded in connecting together their office and campus networks, and even their business partner's networks, using secure IPsec tunnels over the Internet.

An IPsec site-to-site solution addresses only part of the secure communication imperative, largely because an increasingly large part of every organization's workforce has become mobile. To complement site-to-site VPNs, most companies need some form of secure client access. And this is where IPsec VPN deployment has hit the proverbial wall. Every IPsec remote access deployment must overcome a number of major issues. The first is IP addressing, which is encumbered by the commonplace use of network address translation: IPsec and NAT simply won't work in every situation. The second problem many companies face is how to support an installed authentication infrastructure - for example, token-based or any challenge-response authentication - that is not supported in the IPsec standards: numerous interim solutions exist, but none are supported broadly across the IPsec vendor base.

IPsec remote access requires 3rd party client software. The administrative challenges organizations with large populations of users face when they become responsible for managing IPsec client software and configuration for their own users are considerable. They become impractical when organizations try to extend secure access to business partners, supply-chain and customer desktops.

As the name suggests, IPsec creates an IP- or network- level tunnel (connection). This means that every remotely connected user is directly connected to what an organization considers an internal or protected LAN. Every resource on this protected LAN is now potentially available to the user, and also vulnerable to misuse and attack from the user's computer. Often, organizations that are successful in deploying IPsec remote access find themselves encumbered with overly complicated security policies that must be configured to restrict user access.

After years of struggling with these issues, many organizations have come to reconsider their requirements for remote and extranet access. Many organizations want to provide users with access to specific applications and they do not want the addressing issues and the exposure of a full network connection to accomplish this objective. They want a clientless VPN, one that doesn't require additional (IPsec) software to manage on client computers. And they want flexibility in their selection of stronger authentication methods.

Secure Sockets Layer (SSL) is an apparent win-win for secure access (remote and extranet). Users are familiar with the browser interface. SSL is built into every web browser, and thus requires no additional client installation and minimal configuration. SSL operates above IP, so NAT and other IP addressing matters are transparent to the user. SSL-based encrypted tunnels provide sufficiently strong encryption for the purposes most organizations have. Moreover, most organizations have already accumulated years of experience running SSL on their E-commerce and extranet sites, with a variety of authentication methods.

A veritable armada of security appliance vendors (Array Networks, Aspelle, Aventail CheckPoint, Neoteris, Netilla, NetSilica, Nortel, Rainbow Technologies SafeWeb, URoam, and Whale Communications) hopes to play the trump card in the high-stakes market for secure remote access: return on investment. SSL VPNs are simpler to deploy, and demonstrably less expensive to implement and operate.

Archived at http://www.securityskeptic.com/arc20030501.htm#BlogID35 by Dave Piscitello  

Simplifying Secure Remote Access: SSL VPNs

Business Communications Review, April 2003

Dave Piscitello and Lisa Phifer take a look at the business drivers motivating a new surge in SSL VPN products in the April issue of BCR Magazine.

Archived at http://www.securityskeptic.com/arc20030401.htm#BlogID11 by Dave Piscitello  

IPsec is tightly coupled with L2TP in Windows NT and 2000: True or False?

With some effort, you may succeed in configuring an IPsec security policy through Windows 2000 and XP (Professional, at least) local policy editor that lets you operate IPsec without L2TP to your firewall or IPsec security gateway.

Download a description of how you can do this with a Linksys router at ftp://ftp.linksys.com/pdf/befsx41ug.pdf, and use this as a guide. Have an Ethernet protocol analyzer that parses IKE and IPsec handy...

Archived at http://www.securityskeptic.com/arc20030401.htm#BlogID29 by Dave Piscitello  

I've been following a thread about cracking PSKs on the penetration test list (pen-test) at SecurityFocus.com.

A response to the original post attempted to defend the IETF's honor, and stated "The IPSec Working Group has understood and acknowledged this attack avenue, but has deemed that this is an "acceptable risk".

The same individual indicated "The most exposed users are those who use IPSec to connect to internal resources across a hostile network (for example, a sales person visiting a customer)."

Um... isn't this *exactly* the population that uses AG mode?

Archived at http://www.securityskeptic.com/arc20030401.htm#BlogID14 by Dave Piscitello  

Pre-shared keys, like passwords, is a very weak form of authentication. AG Mode doesn't protect the hash of the PSK by encrypting it, and so this method of authentication is vulnerable to attack. A paper by Michael Thumann and Enno Rey provides a very readable "anatomy" of this form of attack. For whatever (unjustifiable) reasons, the IKE and IPsec standards permit the exchange of the hash of PSKs when Aggressive Mode is used during the Internet Key Exchange (IKE, phase 1) - in fact, the IETF acknowledges the attack and deems it an "acceptable" risk.

Archived at http://www.securityskeptic.com/arc20030401.htm#BlogID12 by Dave Piscitello