Monday, August 29, 2011

Phorum Phixes Phast

I was paying a visit to the FreeBSD Diary reading Dan Langille's post grep, sed, and awk for fun and profit (a great read, worthy of your time) when my Spidey sense kicked in.
Specific to log messaging he'd created for captcha failures, Dan mentioned that "these messages are created by some custom code I have added to Phorum."
Oh...Phorum, CMS/BBS/forum/gallery software I'd not seen before.
I installed Phorum 5.2.16 in my test environment, ran it through my normal web application security testing regimen, and found a run-of-the-mill cross-site scripting (XSS) bug. There's no real story there, just another vuln in a realm where they are commonplace.
What is not commonplace in this tale though is the incredibly responsive, timely, and transparent nature with which the Phorum project's Thomas Seifert addressed this vulnerability. I truly appreciate devs and teams like this. He even kindly tolerated my completely misreading the Github commit's additions and deletions.

August 22nd - XSS vuln advisory submitted to security@phorum.org. Yay! They have a security alias, and they read what's submitted to it. :-)

August 25th - Thomas replies and says "Thanks for your report.
We fixed the issue in the git repository, https://github.com/Phorum/Core/commit/c1423ebfff91218a4c1b31047d6baf855603cc91, and will push out a new release in the next 2 days." Sweet, not only is the project responsive and transparent, they're open with their source and change management.

August 26th - Thomas replies again, Phorum 5.2.17 is live. "Release is out:
http://www.phorum.org/phorum5/read.php?64,149490,149490#msg-149490." Outstanding! And a day early than the suggested release window. Advisory published.

One need only read the changelog to see the level of dedication and commitment Thomas and team afford their project.

Nothing else to say but bloody well done. Thank you, Thomas and the Phorum team. More smiles and less middle finger make for happier security grunts.

Cheers.

Sunday, August 28, 2011

ASP.NET vs. ASP.NET.MVC & security considerations



I just read a recent Dr. Dobb's article, as posted in Information Week and online, that provides perspective regarding moving from ASP.NET to ASP.NET.MVC.
Some quick highlights from the article to frame this discussion.
First, ASP.NET.MVC applies the "Model-View-Controller (MVC) to ASP.NET. The MVC pattern, which is frequently used in the design of web sites, aims to separate data, business logic, and the presentation to the user. The challenge in many cases is keeping business logic out of the presentation layer; and careful design based on MVC greatly reduces the prospect of this intermingling."
Second, the various perspectives.

ASP.NET.MVC upside:
"ASP.NET MVC is technically superior to ASP.NET Web Forms because, having been released five years later, it addresses the business and technology changes that have occurred during the intervening period — testability, separation of concerns, ease of modification, and so on."

The ASP.NET.MVC vs ASP.NET middle ground:
"When it comes to the core function, however, there is nearly no difference."

The ASP.NET.MVC downside:
"ASP.NET MVC has greater startup costs. And in some applications, ASP.NET MVC is a substantial turnaround from ASP.NET Web Forms."

I have no take on these positions either way; they all seem reasonable, but the topic triggered dormant thoughts for me bringing back to mind some interesting work from a couple of years ago.

The Dr. Dobb's M-Dev article, while clearly operating from the perspective of development and deployment, does not discuss some of the innate security features available to ASP.NET.MVC users that I think help give it an edge.

Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC is a November 2009 paper that I've already discussed and is well worthy of another read in this context.
I'll use this opportunity to simply remind readers of ASP.NET.MVC's security-centric features, including available tutorials.

1) Preventing Open Redirection Attacks
Open redirection (CWE-601) is easily prevented with ASP.NET.MVC 3 (code can be added with some modification to ASP.NET MVC 1.0 and 2 applications).
In short, the ASP.NET MVC 3 LogOn action code has been changed to validate the returnUrl parameter by calling a new method in the System.Web.Mvc.Url helper class named IsLocalUrl(). This ASP.NET.MVC tutorial is drawn from Jon Galloway's blog.

2) Prevent CSRF
From the Windows Live paper:
"To defend a Web site against XSRF attacks, ASP.NET MVC provides AntiForgeryToken helpers. These consist of a ValidateAntiForgeryToken attribute, which the developer can attach to controller classes or methods, and the Html.AntiForgeryToken() method."

3) JSON hijacking
Casaba contributed to the Windows Live paper. From their blog:
"For JSON hijacking, they ensure that the JSON result included a canary check by default. This prevented developers from being able to return JSON without a canary, thus preventing JSON hijacking."
Much like the CSRF mitigation, the canary check comes through again.
The Windows Live method defined a custom ASP.NET MVC Action Filter attribute to define the HTTP verbs they would accept and ensure that each action required the use of a canary.

It's also a straightforward process to prevent JavaScript injection & cross-site scripting (XSS) in the ASP.NET.MVC View or Controller via HTML.Encode where you:
a) HTML encode any data entered by website users when you redisplay the data in a view
b) HTML encode the data just before you submit the data to the database
See Stephen Walther's tutorial for more.

In summary, in addition to ASP.NET.MVC's development and functionality features, perhaps these security-centric features may help you decide to make the move to ASP.NET.MVC.

Cheers.


Wednesday, August 03, 2011

toolsmith: PacketFence - Open Source NAC



Reprinted with permission for the author only from the August 2011 ISSA Journal

Introduction

An old boss of mine always found a way to blame the vast majority of security-related problems on “the fuzzy neural network behind the keyboard.” Yep, users; what would our lives be without them? There are a plethora of ways, methods, and manner with which to protect your critical assets and networks from said users, amongst them Network Access Control or NAC. A variety of commercial NAC solutions are offered; you may also have heard or read discussions regarding the nuance between Cisco’s Network Admission Control and Microsoft’s Network Access Protection. As such solutions are proprietary and have costs associated with them, we’ll steer clear of any debate and discuss an outstanding free and open source (FOSS) solution, as is the toolsmith norm.

PacketFence is a fully supported (tiered support, bronze to platinum, is available, as well as consultation hours or full deployment services) NAC system that is in use in financial, education, engineering, and manufacturing sectors, to mention a few. It’s used right here in my own backyard at Seattle Pacific University and is considered a trusted and indispensable resource. PacketFence sports a robust feature set including a captive-portal for registration and remediation, centralized wired and wireless management, 802.1x support, Layer-2 isolation of problematic devices, as well as integration with both Snort IDS and Nessus.
PacketFence is supported and maintained by Inverse, a Montreal-based firm. PacketFence development is helmed by Olivier Bilodeau, Inverse’s System Architect.
Olivier provided with an update on PacketFence news and developments as I prepared for this article.
As his is an open source company generating its revenue via services, the PacketFence roadmap is strongly influenced by customer demand and as such sometimes moves in different direction than the public roadmap.

Expect the following in the next major release, 3.0 (likely mid-August):
  • Completely re-designed Captive Portal
  • Guest API that, with little effort, allows a lot of different guest management workflows (email confirmation, self-registration, pre-registration, SMS confirmation, hotel-style code generation, etc.)
According to Olivier, the Guest API has been in the making for more than a year in a separate
branch and now they think it's ready to be merged in for the pending 3.0 release.
Inverse has also been working on other features that may or may not make it to 3.0 including:
  • Ability to run PacketFence in out-of-band and inline mode at the same time
  • Pushing ACLs/Roles per device/user on the edge. This would allow for more granular control over who has access to what, without VLAN management overhead, and enforced at the edge instead of at the firewall. They are also experimenting with applying QoS the same way.
  • Integration with RADIUS Accounting to track bandwidth consumption per user and potentially enforce bandwidth usage restrictions
Olivier wants to reinforce that all the development is conducted in the open, released under the GPL, and committed directly to public repositories so all the features mentioned above are available (although at varying degrees of completion). Snapshots are built nightly directly from the trunk branch and several tests are run on it to make sure it meets a certain quality. This makes it very easy to preview upcoming PacketFence features in a staging environment or a VM.
Inverse maintains PacketFence installations where there are more than a thousand switches and even more access points, including several customers who crossed the '25,000 devices handled by PacketFence' line in the last two years or so. As such, Olivier strongly affirms that PacketFence competes with big brand commercial offerings both in cost, features, and scalability.
In addition to keeping an eye on PacketFence.org, you’re encouraged to subscribe to the PacketFence Twitter feed to stay abreast updates on what they’re are working on: @packetfence
Finally, if you’re going to be in Las Vegas for Defcon 19, be sure to check out Olivier’s presentation, PacketFence, The Open Source NAC: What We've Done in the Last Two Years.

Installation/Configuration

First, PacketFence is supported by rich documentation; I’ll only cover some details that were directly applicable to my experience setting it up in the toolsmith lab.
Core to a sound PacketFence installation is a supported switch. Refer to the PacketFence version 2.2.1 Network Devices Configuration Guide for device specifics. I used a Cisco Catalyst 3548 XL for this effort but said switch is rather dated. The Catalyst 3548 XL does not support 802.1X, the preferred port-based Network Access Control method, so I was limited to MAC detection/isolation and was not able to push PacketFence nearly to the extent I would have liked to.
Inverse includes a VMWare appliance, aptly named ZEN (Zero Effort NAC), perfect for folks wishing to assess a fully installed and preconfigured version of PacketFence 2.2.1 when on a tight timeline. Again, there is a PacketFence ZEN version 2.2.1 Installation Guide to support your efforts in full.
Note: the ZEN VMWare appliance version of PacketFence requires a 64-bit capable system.
For those of planning dedicated installations, the recommended distributions are RHEL 5 or CentOS 5 for which Inverse offers a yum repository.
If you intend to investigate PacketFence via the ZEN appliance, you’ll need to configure your supported switch as follows:
  • VLAN 1 - management VLAN
  • VLAN 2 - registration VLAN (unregistered devices will be put in this VLAN)
  • VLAN 3 - isolation VLAN (isolated devices will be put in this VLAN)
  • VLAN 4 - MAC detection VLAN (empty VLAN: no DHCP, no routing, no nothing)
  • VLAN 5 - guest VLAN
  • VLAN 10 - “regular” VLAN

Refer to the IP and subnet table on page 7 of the ZEN Installation Guide for network configurations per VLAN; DHCP and DNS services are provided by PacketFence ZEN.
I set the switch up with an IP address of 10.0.10.2 and on interface f0/48 I defined the port as a dot1q trunk (several VLANs on the port) with VLAN 1 as the native (untagged) VLAN as required for the PacketFence (PacketFence) ZEN host.

This is easily done on a Cisco switch as follows:
enable
conf term
int fa0/48
switchport trunk encapsulation dot1q
switchport mode trunk
end (Cntrl Z)


The ZEN VM appliance is preconfigured to match interfaces to VLANs, just be sure they’re all set to bridged under VM --> Settings --> Network Adapter.

If all is configured properly, and your Zen VM appliance is connected to the do1q trunk interface, you should be able to browse to https://192.168.1.10:1443 and make use of the PacketFence UI.
Note: You’ll discover a slight mismatch between the PacketFence ZEN guide and the network configuration guide where the network configuration guide describes the PacketFence host IP as 192.168.1.5. If you’re going with the ZEN installation guidance and using the ZEN VM, the PacketFence VM appliance IP is 192.168.1.10.

The PacketFence work flow exemplifies a network “perfect world” in my opinion. A host that joins the network does so in a (limited capacity (no Internet or access) via MAC detection (VLAN4) and is then shunted to registration (VLAN2). Upon successful registration a host continues either as a guest (VLAN5) or an approved system for normal access (VLAN10).
Figure 1 offers a node view including all the unregistered hosts identified by my test instance of PacketFence.


Figure 1 - PacketFence Nodes

PacketFence includes a database of known fingerprints and user-agents for ready system identification, and will flag unknowns as seen in Status --> Reports. PacketFence ironically flagged my Barnes & Noble Nook as seen in Figure 2, most likely because I blew the proprietary B & N OS away and loaded it with CyanogenMod 7.1.0 RC1 (Android 2.3.4), which rocks, by the way.


Figure 2 - PacketFence flags hacked Nook fingerprint as unknown


Out of the gate, PacketFence also detected my normal DHCP service and flagged mine as rogue, tagging it as in violation as seen right in the PacketFence Status view depicted in Figure 3.
Legitimate DHCP servers can be added to the pf.conf file preventing alarms for these servers.
DHCP is also run in Registration and Isolation VLANs but it’s recommended that users to manage their own DHCP servers for the Normal VLANs.


Figure 3 - PacketFence Status

As a security wonk my favorite PacketFence features are, of course, security-related:
  1. Detection of abnormal network activity (Snort) where PacketFence defines alerting and suppression coupled with administratively configurable actions
  2. Proactive vulnerability scans (Nessus) conducted during registration, as scheduled, or on an adhoc basis
  3. Isolation for hosts in violation and remediation through a captive portal including logic that distributed the appropriate counsel for violators including banned devices (“You have been detected using a device that has been explicitly disallowed by your network administrator.”) and malware (“Your system has been found to be infected with malware. Due to the threat this infection poses for other systems on the network, network connectivity has been disabled until corrective action is taken.”)
Unregistered and/or unmitigated hosts remain in splendid isolation, life is good.
Once a host is registered it can be added to a category; I arbitrarily defined Trusted Hosts via Nodes --> Categories.
PacketFence offers extensive reporting with output to CSV and the UI, enhance by extensive filtering.
Figure 4 shows by registered host with details.


Figure 4 - Registered Host Report

As you build out and experiment, be sure to take a close look at Configuration settings. You can define/modify interfaces, networks, switches, and fine tune the language included in messages distributed to violators trapped in the captive portal.

In Conclusion

PacketFence is an outstanding offering and my only regret is not being able to commit more time to testing or push its feature set. It left me feeling nostalgic for the days when I was a network systems administrator configuring devices and network security on a regular basis.
Don’t limit your thinking specific to PacketFence; while it’s a great solution for small/medium business, it really can handle the enterprise as well.
Remember the documentation is extensive. Make use of it to get fully wrapped around ALL of PacketFence’s capabilities, then test and deploy.
PacketFence is definitely one of my candidates for Tool of the Year.
Ping me via email if you have questions (russ at holisticinfosec dot org).
Cheers…until next month.

Acknowledgements


Olivier Bilodeau, Inverse System Architect, PacketFence project lead