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

Friday, July 22, 2011

APWG Survey and deja vu all over again

As a participant in the APWG IPC, and a contributing researcher, I was pleased to see Dave Piscitello's APWG Web Vulnerabilities Survey Results and Analysis get some press coverage as it went live in mid-June.
Rather than focus on the survey results (you can read those for yourself), I'd like to focus briefly on mitigation and concerns.
The Results and Analysis-compiled responses "suggest that web sites would benefit from broader implementation of preventative measures to mitigate known vulnerabilities and also from monitoring for anomalous behavior or suspicious traffic patterns that may indicate previously unseen or zero day attacks."
Given the broad scope of CMS platforms, forums, galleries, wikis, shopping carts, and others riding on top of the popular LAMP stack, the absence of such preventative measures and monitoring make for hacker nirvana.
Consider the problems shared servers introduce where vulnerabilities in any of the above-mentioned applications preloaded for on demand end-user deployment via cPanel (not to mention cPanel vulnerabilities) can lead to "game over."
Clearly there are challenges: resources, level of commitment to security by site operators, and hosting provider scrutiny to mention a few.
The problem is not new.
When pending Black Hat presentations are describing tools sets such as Diggity "that speed the process of finding security vulnerabilities via Google or Bing", or Embedded Web Servers Exposing Organizations To Attack, you know it's Groundhog Day. Great tool set (Diggity), but that we're still unfortunately talking about the ease with which hacker groups are finding "opportunities" is troubling to say the least.
When #3 on Kelly Jackson Higgins' list of suggestions to repel attackers states "eliminate SQL injection, XSS, other common website flaws" it's deja vu all over again.
The APWG Web Vulnerabilities Survey asked "What actions did you take to stop the attack?" Compiled answers resulted in data such as:
We patched or updated vulnerable software packages 21%
We had our developers fix our custom software 8%

While other results lean heavily towards security misconfiguration issues, there are still clear opportunities to improve SDL/SDLC practices.
As the survey report indicates, "This article barely scratches the surface of the intelligence the APWG IPC has accumulated from the Web Vulnerability Survey. A complete analysis of the survey results—with specific recommendations, remedies, and practices."
I'm in the midst of research focusing on the scanning and misconfiguration elements of Internet Background Radiation (IBR) using a variety of Web logs. This research still points back to the above mentioned problem space and suggestions, but will drive deeper into attacker and victim trends and traits. This work, coupled with earlier web application security research will feed the analysis paper pending publication by the APWG IPC.
My hope is to also present the IBR work at an upcoming security conference along with a paper or article.
Stay tuned.

Monday, July 18, 2011

Mark Russinovich presenting at ISSA Puget Sound

A quick note to any Seattle-area readers.
ISSA Puget Sound is proud to have Mark Russinovich as this month's speaker, presenting Zero Day Malware Cleaning with the Sysinternals Tools, Thursday, July 21st, 6:00 - 8:30 pm, Building E, 5600 148th Ave NE, Redmond, WA 98052 (Microsoft RedWest campus - max capacity (145))
This is an RSVP only event, please visit the ISSA Puget Sound website for all the details.
Mark will be offering both his recent books, Zero Day: A Novel and Windows Sysinternals Administrator's Reference for sale and will be signing them as well.
If you're in the area, please RSVP and attend this outstanding event and opportunity.

Monday, July 04, 2011

toolsmith: RIPS - PHP static code analyzer



In July's toolsmith I admit to the fact that I’ve often focused on run-time web application security assessment tools and paid absolutely no attention to static analysis tools.
For those of you in a similar boat, RIPS is a static source code analyzer for vulnerabilities in PHP. RIPS is written by Johannes Dahse who uses it when he audits PHP code, often during Capture The Flag contests.
To test RIPS in all it's glory, I compared its functionality to known finding from a vulnerability disclosure and advisory I posted for Linpha 1.3.4 in March 2009. Linpha 1.3.4 is a photo/image gallery (no longer supported or maintained) which exhibited cross-site request forgery (CSRF) and cross-site scripting (XSS) vulnerabilities during runtime analysis.
Specifically, input passed via GET to the imgid parameter is not properly sanitized by the image_resized_view.php script before being returned to the user. This vulnerability can be exploited to execute arbitrary HTML and JavaScript code in a user’s browser session in the context of an affected site.
To compare this finding to source code analysis with RIPS, I loaded
/var/www/linpha/actions/image_resized_view.php in the RIPS UI and clicked scan.
The results were immediate and clearly identified in source code the same vulnerability I’d discovered at run-time, as seen in Figure 1.


Figure 1

Note that RIPS tags the imgid parameter as vulnerable right out of the gate.
RIPS is becoming more and more feature-rich with each new release; while it's a work in progress, it’s already quite effective and Johannes is actively developing it. You'll enjoy code viewing and exploit creation functionality but one of my favorite new features is graphical representations of scanned files and includes with representation of “how files are connected to each other, what files accept sources (userinput) and what files have sensitive sinks or vulnerabilities” as seen in Figure 2.


Figure 2

Check out the RIPS article here, and download RIPS and Johannes' white paper here.

Cheers.

Thursday, June 30, 2011

You can't patch stupid...



The only thing this incredibly witty site is lacking is a McAfee Secure or Scanless PCI badge. ;-)

http://ismycreditcardstolen.com

Watching mailing lists debate if it's legit or not? Priceless...



In other breaking news, “There’s no device known to mankind that will prevent people from being idiots,” said Mark Rasch, director of network security and privacy consulting for Falls Church, Virginia-based Computer Sciences Corp. (CSC).
Woot! To the fuzzy, neural networks behind the keyboards, step back.

What would life be without users?

Cheers.

Friday, June 03, 2011

APT: anti-hype, reality checks, and resources

This post is my 200th for HolisticInfoSec, and I mark it with particular consideration for the topic, coupled with profound recognition of the process that lead to this discussion.
As a graduate student enrolled in the SANS Technology Institute's MSISE program, I recently completed the Joint Written Project requirement.
My partners and I were assigned the topic Assessing Outbound Traffic to Uncover Advanced Persistent Threat.
Of my partners, I hold the highest regard; participating in this project with Beth Binde and MAJ TJ O'Connor was quite simply one of the most rewarding efforts of my professional career. The seamless, efficient, tactful, and cooperative engagement practiced throughout the entire 30-day period allowed for completion of the assignment resulted in what we hope readers will consider a truly useful resource in the battle against APT.

Amongst positions taken for this paper is a simple premise: there are tactics that can be applied in the enterprise to detect and defend against APT that do not require expensive, over-hyped, buzzword-laden vendor solutions.
Think I'm kidding about buzzwords and hype?
Following are real conversations overheard in the aisles at (ironically) the RSA Conference.
1) What is the ROI on your SEM, and will it detect any APTs on my LAN?
2) Does the TCO justify spend for a SaaS/cloud solution; you know, an MSSP?
3) Wait, what about APT in the cloud? If I use a Saas-based SEM to manage events on my cloud-based services, will it still find APTs?
All opportunities for chastisement and disdain aside, commercial solutions clearly are an important part of the puzzle but are far from preemeninent as the only measure of detection and defense.

Instead, Assessing Outbound Traffic to Uncover Advanced Persistent Threat, proposes that:
"Advanced Persistent Threat (APT) exhibits discernible attributes or patterns that can be monitored by readily available, open source tools. Tools such as OSSEC, Snort, Splunk, Sguil, and Squert may allow early detection of APT behavior. The assumption is that attackers are regularly attempting to compromise enterprises, from basic service abuse to concerted, stealthy attempts to exfiltrate critical and high value data. However, it is vital to practice heightened operational awareness around critical data and assets, for example, card holder data, source code, and trade secrets. Segment and wrap critical data within the deeper protection of well monitored infrastructure (defense in depth). Small, incremental efforts, targeted at protecting high value data value (typically through smaller and protected network segments), provide far greater gains than broader, less focused efforts on lower value targets. In a similar vein, layered defensive tactics (multiple layers and means of defense) can prevent security breaches and, in addition, buy an organization time to detect and respond to an attack, reducing the consequences of a breach."

This perspective is shared by Jason Andress, in his ISSA Journal cover article, Advanced Persistent Threat Attacker Sophistication Continues to Grow?
Jason's article fortuitously hit the wire at almost exactly the same time our paper went live on the STI site, as if to lend its voice the arguement:
"This paper discusses what exactly APT is, whether or not it is a real threat, measures that can be implemented in order to mitigate these attacks, and why running out to buy the latest, greatest, and most expensive security appliance might not be the best use of resources."

You will find consistent themes, similarly cited references, and further useful resource material in Jason's excellent work. I look forward to seeing more of Jason's work in the ISSA Journal in the future.

In closing, from our paper:
"Even the best monitoring mindset and methodology may not guarantee discovery of the actual APT attack code. Instead, the power of more comprehensive analysis and correlation can discover behavior indicative of APT-related attacks and data exfiltration."

If APT worries you as much as it seemingly does everyone, give the papers a read, take from them what suits you, and employ the suggested tactics to help reduce attack vectors and increase situational awareness.

Cheers and good luck.

Thursday, June 02, 2011

toolsmith: Xplico

Those of you who make use of Network Forensic Analysis tools (NFAT) such as NetworkMiner or Netwitness Investigator will certainly appreciate Xplico.
June's toolsmith covers Xplico, a project released under GPL that decodes packet captures (PCAP), extracting the likes of email content (POP, IMAP, and SMTP protocols), all HTTP content, VoIP calls (SIP), IM chats, FTP, TFTP, and many others.
If you'd like a breakdown on the protocols you can grapple with check out the Xplico status page.
You can imagine how useful Xplico might be for policy enforcement (spot the pr0n), malware detection (spot the Renocide), or shredding IM traffic (spot the data leak).
Experimenting with Xplico is also a great chance to check out Pcapr, Web 2.0 for packets. ;-)
Xplico inlcudes a highly functional Web UI with great case and session management as seen in Figure 1.


Figure 1

With a resurgence of discussion of APT given the recent bad news for RSA, as well as all the FUD spawned by Sony's endless woes, I thought a quick dissection of an Aurora attack PCAP would be worth the price of admission for you (yep, free) as seen in Figure 2.


Figure 2

You'll note the beginning of a JavaScript snippet that has only the worst of intentions for your favorite version of Internet Explorer as tucked in an HTML page.
Copy all that mayhem to a text file (in a sandbox, please), then submit it to VirusTotal (already done for you here) and you'll note 26 of 42 detections including Exploit:JS/Elecom.D.
Want to carve off just that transaction? Select the pcap under Info from the Site page under the Web menu selction as seen in Figure 3.


Figure 3

Voila!
Ping me via russ at holisticinfosec dot org if you'd like a copy of the above mentioned Aurora PCAPs.

Also, stand by for more on APT detection in outbound traffic in the next day or two.

Your gonna like this tool, I guarantee it.
Check out the article here and Xplico here .

Cheers.

Thursday, May 26, 2011

Cyber Defense Challenge: Analogies

First, an apology. I've not been posting much; heads down on grad school work.

I recently had the opportunity to interview Alexei Czeskis, the captain of the University of Washington (UW) team who won this year's National Collegiate Cyber Defense Competition (CCDC).
During my discussion with Alexei I was immediately drawn to the fact that his approach and tactics closely mirror those of mature security incident response teams.
First, a quick break down on the CCDC:
"You have just been hired as the network and security administrators at a small company and will be taking administrative control of all information systems. You know very little about the network, what security level has been maintained, or what software has been installed. You have a limited time frame to familiarize yourself with the network and systems and to begin the security updates and patches before the red team starts actively attacking your company. In the midst of all the commotion, you have to keep up with the needs of the business and user demands while maintaining service level agreements for all critical Internet services. Welcome to the first day of the National Collegiate Cyber Defense Competition (CCDC)."
The CCDC process begins with regional contests wherein 100+ schools participate at the appropriate regional contest from January until the end of March.

The UW team has won the regional all four years it's participated.

That said, they had not achieved success at the national level due to what Alexei described as a lack of planning and strategy.
Analogy 1: You cannot be successful at incident response without standard operating procedures, defined roles, practice and drilling, as well common strategy.
Of the steps Alexei prescribed for his team in advance of the contest(s):
• Roles predefined
• Have a “three hour plan”: what are your first steps for identification of vulnerabilities, short term mitigations, and longer term remediation and hardening
• Practice in advance, ensure broad knowledge
• Define primary and secondary subject matter expert for each roll
• Define a true "captain" (officer)
• Team members concentrate on their individual domains

According to Alexei, maintaining order was key to winning.
Analogy 2: Incident "management" is essential. This role includes conflict resolution, and motivation.
Some of Alexei's key pointers:
1. It's important to know your players’ (incident responders’) weaknesses.
2. Identify those who can’t multitask or self-manage; some people need direction, some don’t.
3. Learn who needs help but won’t ask.
4. Human component is massive, know as much as you can in advance (of an incident)
5. One person managing is hugely important.
6. Keep morale up; team cohesion is the most important thing!
With six undergrads, an additional grad student, and Alexei as captain, the UW team managed to keep a very concerted, highly capable red team (military, penetration testing professionals) at bay.
As an example, we're talking about Air Force people who like to write their own Windows rootkits and wreak havoc on unsuspecting blue teams.
The CCDC always includes an interesting element, a "white" team if you will, to throw in administrative overhead, define use of social media, and introduce some real reliability elements.

New this year was a "cloud" component, executed via virtualization (lack of access, no IDS (span), and no firewall making it very difficult to defend).
Analogy 3: Incident response in the cloud is difficult! Cloud response includes requirements of components and features often well beyond your control.
Alexei and team learned some painful lessons quickly:
It’s easy to lock out of cloud machines (be gentle); don't enable the firewall but forget to add exception for yourselves.

Some closing points from our discussion.
Alexei would utilize these tactics if he were employed as a security incident manager.
He stressed avoiding big morale hits, and to "just worry about doing your best, not winning."
As a security incident manager, I can tell you with certainty that this is sound thinking and methodology.
It's not about winning, but it is about trying to be excellent in tactics and service.

Alexei and the UW team are clearly excellent: well done!

del.icio.us | digg | Submit to Slashdot

Wednesday, May 04, 2011

toolsmith: Security Onion


You, dear readers, all know I'm a tool dork.
Quite possibly, some of you may further think I'm a tool and/or a dork; we'll take that for granted. ;-)
When I write toolsmith each month, I end up immersing myself very deeply in the intended tool topic. My effort for May 2011 was no different; I went way down the rabbit hole with Doug Burks' Security Onion (SO).
Net result? Mad props.
Doug continues to enhance what is the most immediately useful Live CD/DVD available to NSM practitioners.
I'll let my conclusion from the article serve as impetus for your further reading and use of Security Onion:
"I’ll try to avoid flagrant gushing, but Security Onion employs a congregation of the most important tools available to security and network analysts that I’ve ever discussed. Attack and reconnaissance tools are important, but I am the ultimate blue-teamer at heart. I’ve said it before: “What you don’t see can hurt you.” You can see better with Security Onion and its well-implemented deployments of Snort/Suricata, SANCP, and Sguil/Squert. I will simply say that you can defend yourselves, and those you are charged with protecting, better with the likes of Security Onion."


Detect web attacks against actual SO infrastructure? Done.


Detect scans against reporting hosts via Emerging Threats sigs with instant correlation? Done.


Visualize related output with Squert and AfterGlow? Done!


Repeating from article again:
"Job well done, Doug. As an ISSA member I’m proud of your work and your contributions to our association and community.
Readers, take advantage of this noteworthy effort."


Ping me via email if you have questions (russ at holisticinfosec dot org).
Cheers.

del.icio.us | digg | Submit to Slashdot

Sunday, April 03, 2011

toolsmith: OpenVAS-4



Between writing this post and writing April's toolsmith a couple of weeks ago, I used OpenVAS-4, April's toolsmith topic, for a penetration testing engagement rather than the other freely available vulnerability scanner.
The project leads just released OpenVAS-4 in March and it offers some noteworty enhancements.
Between the highly functional web UI, the Greebone Security Assistant, and the impressive scan configuration methodology, I may be a convert.



OpenVAS-4 offers seriously strong report-fu; an essential part of successful engagement tooling.
I also find the ability to slave multiple OpenVAS Managers to one Manager to load balance and distrbute resource intensive scan tasks.






As part of recent testing I discovered a host running the Mongoose web server.



It's here we'll have some fun, a contest if you will, more of a guessing game than anything.
On what specific host type was Mongoose running?
Hint: Keep in mind that Mongoose is an "easy to use web server. It also can be used as embedded web server library to provide a web interface to applications."
First correct guess received via holisticinfosec at gmail dot com will receive an information security book of my choosing.


Check out OpenVAS; I think you'll be impressed.
Cheers.

Thursday, March 24, 2011

OWASP Top 10 Tools and Tactics @ InfoSec Resources



I've been a busy lad of late and haven't been keeping up on posts, but I have been turning out some work elsewhere.
If you haven't already taken note, checkout my second installment for InfoSec Resources, specifically OWASP Top 10 Tools and Tactics.
It even made #4 on Reddit under NetSec and was March 24th's Post of the Day on PenTestIT. ;-)

{excerpt}

Lesson 1:

Software will always have bugs and by extension, security vulnerabilities. Therefore, a practical goal for a secure software development lifecycle (SDLC) should be to reduce, not necessarily eliminate, the number of vulnerabilities introduced and the severity of those that remain.

Lesson 2:

Exploitation of just one website vulnerability is enough to significantly disrupt online business, cause data loss, shake customer confidence, and more. Therefore, the earlier vulnerabilities are identified and the faster they are remediated the shorter the window of opportunity for an attacker to maliciously exploit them.

The conclusion is therefore simple: reduction and remediation of web application security flaws will shrink the number of attack vectors and improve security posture. Ground breaking, right? No, it’s old news, “security posture” is a worn out buzz phrase, and if everyone was diligent about the above mentioned reduction and remediation, we’d likely not need a Top 10 list or a 12th Website Security Statistic Report (count on one). But hey, then we’d have to find different work, right?

Gifford Pinchot once said “Never bet on a race unless you are running in it.”

As solutions are always better than complaints, let’s discuss how to get in the race with some tooling options as we explore each of the Top 10.


{/excerpt}

You know I'm an SDLC fan, and an ardent supporter of OWASP. This article blends those passions along with some insight as to how I conduct web application vulnerability research.

Note: Over the next few months, I'll be drilling into to each of the OWASP Top Ten, exploring the specific vulnerability and the aforementioned tooling and tactics to aid in better discovery and mitigation.
Look forward to those followup articles at InfoSec Resources.


Hope you enjoy.
Cheers.

Sunday, March 06, 2011

Book Review: Python 2.6 Text Processing



Python is a powerful and dynamic programming language that is used in a wide variety of application domains such as web and internet development, databases access, desktop GUIs, scientific and numeric, education, network programming, software development, as well as games and 3D graphics.
As a security analyst I'm always interested in ways to better query vast quantities of text such as parsing web server logs for various signs of evil.
Jeff McNeil's Python 2.6 Text Processing Beginner's Guide from Packt Publishing struck me as useful resource with which to improve Python skills specific to text processing.
This book is intended for novice Python developers interested in processing text (me), and is laid out and written so as to be very supportive of this cause.
First published in December 2010, Python 2.6 Text Processing is organized via these conventions:
  • Time for action - inclusive of multiple instructions followed by extra detail and explanation (What just happened?)
  • Pop quiz - to help you test your understanding of methods just discussed
  • Have a go hero - practical challenges to put your learning to use
I appreciate the logical flow of the book, moving from basic concepts and IO handling, to strings services and standard library usage, to regular expressions, structure markup, encoding, and advanced output.
With my interest in web server log manipulation I found myself able to quickly embrace the concepts offered and make us of this book's code samples offered on the Packt Publishing website.
Anyone who operates a website and spends any time reviewing web logs is likely aware that a certain percentage of all traffic bound for their site is malicious, be it uniquely targeted or bot traffic crawling by looking for weak spots.
One such example is remote file include (RFI) attempts. I've been using a Perl script to parse my logs for such traffic but have wanted to use such analysis as an opportunity to learn Python and ultimately rewriting the scripts in Python. While I haven't gotten there yet, I am certain this book will aid me entirely.
Of additional use is the fact that Python 2.6 Text Processing offers additional resources such documentation APIs, community resources such as mailing lists and conferences, as well as discussion of Python 3 and what to expect in migrating.
Returning to the RFI analysis mentioned above, I used Python to pull interesting, related results out of my web logs.
While Chapter 2 of Python 2.6 Text Processing introduces a web server log parser, and builds on it through out the chapter, I was drawn to searching and indexing as described in Chapter 11 via the use of the Nucular libraries (no, not the Bush mispronunciation).
"Nucular is a system for creating full text indices for fielded data. It can be accessed via a Python API or via a suite of command line interfaces."
First, ensure that you've installed the SetupTools easy_install system via python ez_setup.py as discussed on page 23. Once installed issue easy_install nucular, and the libraries and related dependencies will be installed to the appropriate paths.
With some modifications to the provided code samples, I then created an index of three years worth of web logs from my site, and was able to query them as a single source for keywords indicative of RFI attacks. While I started with a simple linear search across multiple logs via text_scan.py as seen on page 302 I quickly learned why McNeil is proving the linear search method as laborious and ineffective, instead promoting the use of libraries such as Nucular, and he's right.
Overall, this book is an effective learning tool, though keep in mind that it's entirely Linux-centric. Syntax for those of you using Python on Windows is subject to nuances.
McNeil's done a solid job with Python 2.6 Text Processing Beginner's Guide; it's a verbose (sometimes he turns on the fire hose) but worthy read and a suggested purchase at $45 +/- direct from Packt, Amazon, or Barnes and Noble, earning 3.5 stars out of 5 (very good).
Give it a read and put those mad new Python skills to good use.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Wednesday, March 02, 2011

More on OSINT with FOCA 2.6 in toolsmith



“If ignorant both of your enemy and
yourself, you are certain to be in peril.” - Sun Tzu

I'm on a bit of an OSINT kick lately, and I nearly flipped out when I began to research FOCA for toolsmith, then realized the raw, unadulterated power I had yet to make use of.
Shame on me. Don't make the same mistake I did; download FOCA 2.6 pronto.
If you're a penetration tester, this is hands down one of the best reconnaissance tools I've ever imagined. Fear the FOCA indeed.
Really, fear it. You need to be careful with this tool. You can easily walk yourself right into potential legal concerns if you don't proceed with caution and permission.
Consider yourself duly warned.
FOCA is the product of the team at Informatica 64, including Alejandro Martin Bailon and Chema Alonso, who were helpful as I wrote this March's column.

FOCA (Fingerprinting Organizations with Collected Archives) 2.6 is an interesting tool that focuses heavily on document metadata extraction while incorporating other extreme search capabilities. Rather than depending on a variety of recon methods, FOCA will provide many related services for you.
The FOCA project leads have indicated that for more than the last year and a half FOCA has been a primary tool in their own engagements.


Definitely check out their DEF CON 18 presentation; it's truly entertaining and richly informative.

The metadata functionality as seen in Figure 1 speaks for itself.

Figure 1

If that's not enough for you, the advanced network reconnaissance and enumeration capabilities ought to seal the deal as seen in Figure 2.


Figure 2

There also an online version of FOCA.

The article can be found here.

Enjoy and be careful. ;-)

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Thursday, February 17, 2011

OSINT: large email address list imports with Maltego



Fans of OSINT are inevitably fans of Maltego; I count myself amongst the dedicated.
Given the recent HBGary debacle, you'll soon see where the following discussion may prove useful for discovery of relationships between entries in a large list of email addresses. Consider the prospect of grepping through the HBGary emails, culling out a list of unique entries, then transforming them as an entirety via Maltego to determine what other relationships may exist between entrants.

I've been hoping for some large list import functionality via Maltego local transforms, and Andrew at Paterva immediately provided upon request.
Imagine similar functionality as found in transforms discussed earlier where a CSV inclusive of IP addresses is imported (this older method was via Phrase entity pointed directly to the full path of the CSV), then unique IP address entities are populated to the Maltego UI workspace.
For our current scenario, Andrew has provided me (and thus you) with local transforms that will allow import of a CSV, now using EasyDialogs (Linux, Windows) inclusive of multiple email addresses, and populate them each as unique Email Address entities to the Maltego UI workspace.

Making sense?
I'll walk you through it.

First, ensure that you grab EasyDialogs as mentioned above and embed it properly with your Python interpreter.
Second, grab getEmailAddresses.py, the above mentioned local transform for email address list imports, and configure it for use with your Maltego instance.

Now, let's start with a googledork.
email addresses filetype:csv senator

The second hit yields a CSV of Virginia state delegates affiliated with the Hampton Roads Partnership.
Looks like fun.
NOTE: This is entirely benign OSINT, simply a good object model for validation of our new local transform.

After cleaning up the CSV to include only a column inclusive of the delegates email addresses, drag a Phrase entity onto the Maltego workspace; I named mine Virgina Delegates.
Right-click the Phrase entity, select Run Transforms, then Other Transforms, then getEmailAddresses. A pop-up window will appear (EasyDialogs) and ask you "Which file do you want to use?"
Give it the path (I used the shell extension CopyPath) to your CSV file and click OK.
Results will be populated as seen in Figure 1.


Figure 1

Highlight all the resulting Email Address entities that are now populated in the Maltego workspace, right-click the selection, choose Run Transforms, then Other Transforms, then To Website [using Search Engine]. It'll take a few minutes to run as there's some crawling to be done.

The Mining View of the results can be a bit of kluge as seen in Figure 2.


Figure 2

This transform is best viewed as Edge Weighted (Figure 3).


Figure 3

See the commonality regardless of view?
Both result sets point out the fact that one of the most significant relationships all these delegates share is...wait for it...the website for the firm owned by the person I can only imagine is...ta-da...their lobbyist!
Politics as usual. ;-)

Enjoy this transform, and stay tuned for more discussion of similar transforms.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Saturday, February 05, 2011

El Jefe: The Boss Will See You Now



The February 2011 edition of the ISSA Journal includes toolsmith on the topic of El Jefe 1.1.
The boss, the big kahuna, El Jefe requires his due. From the folks at Immunity, El Jefe is a solution that intercepts native Windows API process creation calls, allowing you to track, monitor, and correlate process creation events.
Going many steps beyond tracking simple process creation, El Jefe provides a microscopic view of the binaries that are run: SHA1, PID, flags, sorted chronologically with spawned offspring while click-able for instant analysis.
You'll enjoy centralized storage; data which can be queried from the Django-based web app.
Setup is quite straightforward, making use of El Jefe equally so.
I experimented various malware types including Bifrost and Zeus on victim VMs and results were immediate.
Strings references were quickly revealed via Binary Information as seen in Figure 1.


Figure 1

Captured client logging includes evidence of intrusion based on suspicious entropy as seen from a Zeus infected VM in Figure 2.


Figure 2

I enjoyed researching El Jefe's capabilities to no end.
Well done and thanks to Immunity's Justin Seitz.

The article is posted for you here.

Speaking of things Zeus related, I'm presenting Malware-Proof: Building Resistant Web Applications at the RSA 2011 eFraud Network Forum (invitation only). See you there if you happen to be a signed-up attendee.

Enjoy and cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Monday, January 31, 2011

2010 Toolsmith Tool of the Year: SIFT 2.0

As voted by you, the readers, the 2010 Toolsmith Tool of the Year is SIFT 2.0.
The SANS Investigative Forensic Toolkit (SIFT) Workstation Version 2.0, as discussed in May's ISSA Journal, is a Linux distribution that is preconfigured for forensic investigations. Created by Rob Lee for the SANS 508 track, SIFT 2.0 includes all the tools a forensic analyst/incident responder would require to conduct a thorough system investigation. I particularly favor it for memory analysis - grab a memory image from your victim system; pull it back to your SIFT VM and get down to business in no time flat.

Of 76 votes, SIFT 2.0 came in first with 24 votes (31.6%).
Rounding out the top five:
2) Firefox Addons for Security Practitioners with 20 votes (26.3%)
3) SamuraiWTF with 18 votes (23.7%)
4) NetWitness Investigator with 12 votes (15.8%)
5) Confessor and MOLE with 8 votes (10.5%)



On behalf of the ISSA Journal and I, congratulations to Rob Lee and his team!

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Monday, January 03, 2011

toolsmith: Armitage - Cyber Attack Management for Metasploit



Raphael Mudge's Armitage is the subject of January 2011's toolsmith in the ISSA Journal.
Armitage is a "cyber attack management" platform for Metasploit.
Depending on your background or the availability of commercial tools in your environment (Core, Canvas, etc.), your comfort with Metasploit likely varies
with the depth of your experience. Armitage1 is designed to help close some of the experience or comfort gaps, described by the developer as useful for “non-hackers”.
For use as a demonstration tool to elucidate vulnerabilities and their exploit to management or customers, Armitage is excellent.
Basic Armitage workflow (should be familiar to all pentesters):
Create a workspace, conduct or import scans, identify vulnerabilities, determine appropriate attacks, gain access, and further your presence in the environment.
I've always loved the premise of attack pivoting. Gain a foothold on one system, them jump off to another host or network. Armitage definitely supports such thinking. ;-)
Download Backtrack 4 R2, install Armitage, and see what you think. I enjoyed testing it for this article immensely; I believe you'll find it equally useful.
Download the article here.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Saturday, January 01, 2011

Help choose the 2010 Toolsmith Tool of the Year

Rather than choose the best of 2010 myself, I need your help choosing the 2010 Toolsmith Tool of the Year.
We covered a lot of excellent information security-related tools in 2010; which one did you believe was the best?
I appreciate you taking the time to make your choice here.
Results will be announced February 1, 2011.

Moving blog to HolisticInfoSec.io

toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...