« Anonymity and Security:BlackHat 2007 - Tactical Exploitation Thoughts »

Using CSA to Prevent JavaScript Hairpin Scanning

08/02/07

Permalink 06:00:05 pm, by Chad Sullivan, 381 words
Categories: Cisco Security Agent, General Security

Using CSA to Prevent JavaScript Hairpin Scanning

At BlackHat USA 2007, Jeremiah Grossman & Robert Hansen provided a revisited and repackaged view of last years BlackHat 2006 talk which this year is entitled, "Hacking Intranet Websites from the Outside (Take 2)—'Fun With and Without JavaScript Malware'". The talk was again focused on JavaScript and XSS related attack vectors and also included some new twists such as CSS. There is one particular point that was mentioned that I want to discuss: What if the system that happened to be running the malicious JavaScript (via browsing a website) were also connected to the corporate network via VPN?

Imagine a scenario where one of your co-workers is out of the office and connected via VPN (full or split tunnel) and happens to browse to the maliciously coded webpage. This script then begins to scan internal corporate resources and potentially compromise those resources or glean enough data for a future compromise. This scenario is obviously not one we would like to face as the potential impact is quite threatening.

How could we possibly protect against this without turning off JavaScript processing? One option is via the implementation of Cisco Security Agent (CSA) policies. In CSA 5.2, you now have the ability to match a system state and also enforce system policies based upon network interface activity and usage. In this case, we can build a set of rules that is enforced when we use our Virtual\Cisco Systems VPN Adapter interface with a specific IP range provided by our VPN concentrator IP pool. Once this interface is active, we can then tag any web browser that communicates to internal resources over this interface. Now that we know we have a tagged web browser communicating with resources that need to be protected, we can limit the communication this browser process ID (PID) has with the rest of the Internet. Applying simple network access control rules can deny or prompt the user when this communication occurs and force them to start a separate browser process for any external communication.

By identifying a browser that is communicating over a VPN tunnel to protected internal resources and then restricting this same browser process from communicate elsewhere on the Internet, we can ensure that JavaScript malware cannot take advantage of a hairpin scenario through the tunnel to the corporate network.

Priveon, Inc.

Today's complex security and networking solutions require a great deal of knowledge to successfully support and operate. Priveon uses the field experience of its expert staff to develop and maintain a positive reinforcement loop between business practices and to provide the latest information to our customers. The information posted here is supported by Priveon subject-matter experts.

Search

XML Feeds

Archives