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
Thursday, May 26, 2011
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
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)
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.
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.
Wednesday, December 01, 2010
toolsmith: SamuraiWTF

December's toolsmith covers SamuraiWTF.
I'll repeat myself as stated in the article:
SamuraiWTF rocks, plain and simple.
It’d be my 2010 Toolsmith Tool of the Year but alas, I am letting you, dear reader, make that “Tool of the Year” decision for 2010 (poll details to follow as 2010 draws to a close).
SamuraiWTF is a LiveCD Linux release designed to serve you for your web pen-testing needs. Kevin Johnson of Secure Ideas and Justin Searle of InGuardians included what they believe are the best of the open source and free tools that focus on testing and attacking websites, selections based on the tools they use as part of their job duties. SamuraiWTF includes tools useful in all four steps of a web pen-test:
• Reconnaissance – Fierce domain scanner, Maltego (be sure to check out the Shodan Maltego add-on)
• Mapping – WebScarab, ratproxy
• Discovery – w3af and burp
• Exploitation – BeEF, AJAXShell
The article walks through using SamuraiWTF for each phase, but as always, I had the most fun exemplifying exploit methodology with BeEF.
Browser zombies rule! ;-)

If you seek to learn a ton about web application security testing, or consolidate all the tools you’ll likely need on one system, SamuraiWTF is for you.
As Kevin indicated for the article, you can use SamuraiWTF as your base install, then enhance with Burp Suite Pro if you happen to be a commercial Burp user.
Stay tuned for the SamuraiWTF 1.0 release, and contribute to the project if so motivated.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Thursday, November 11, 2010
CSRF mitigation: 4images Gallery's comprehensive approach
Once in awhile, in my quest to break (and promote fixing of) every web application I encounter, I have email discussions with some excellent people who reach out to me after the initial advisory during a coordinated disclosure.
Such was the case with Kai S. of Dots United GmbH, the team who develops the 4images Gallery.
Just a day or two after he'd been contacted by Secunia, whom I submit my vulnerability findings to for disclosure coordination, I heard directly from Kai. He asked me to provide more detail with regard to the finding indicating that 4images Gallery accepted "HTTP requests without performing any validity checks to verify the request", better known as cross-site request forgery (CSRF).
After replying with my proof of concept and some resource material, Kai replied that he would "forward this to our developers so we can release a fixed version".
On October 27 Dots United released a fix for all versions up to and including 1.7.8.
On November 10, the 4images Gallery team released version 1.7.9 inclusive of global CSRF mitigation.
In addition to a deserved "Well done!" for excellent communication as well as a timely fix turnaround, I'd like to applaud their direct approach to the fix, seemingly based on OWASP recommendations. Should all web application developers take a similar path, we'd likely see a reduction in CSRF vulnerability statistics.
Let me walk you through some of the 4images Gallery CSRF mitgation methods.
The core of the protection is includes/csrf_utils.php; CSRF protection is enabled by default.
As created by csrf_utils.php, generate a random MD5-derived token:

Return said token to the form as follows:

Then when some jerk like me comes along and throws something nasty at an admin...

...the attacker is thwarted by a unique, random token.

Add to the above-mentioned functionality the fact that the 4images devs allow you to take advanced control of CSRF protection via the config.php file. You can manage the default bit or maintain granular control of frontend/backend protection, token expiration, CSRF protection variable naming, and even XHTML vs. HTML.

I appreciate the efforts undertaken by Kai and the Dots United team in response to this vulnerability, and look forward to other development teams/vendors hopefully taking a similar tack.
Happy sailing. ;-)
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Such was the case with Kai S. of Dots United GmbH, the team who develops the 4images Gallery.
Just a day or two after he'd been contacted by Secunia, whom I submit my vulnerability findings to for disclosure coordination, I heard directly from Kai. He asked me to provide more detail with regard to the finding indicating that 4images Gallery accepted "HTTP requests without performing any validity checks to verify the request", better known as cross-site request forgery (CSRF).
After replying with my proof of concept and some resource material, Kai replied that he would "forward this to our developers so we can release a fixed version".
On October 27 Dots United released a fix for all versions up to and including 1.7.8.
On November 10, the 4images Gallery team released version 1.7.9 inclusive of global CSRF mitigation.
In addition to a deserved "Well done!" for excellent communication as well as a timely fix turnaround, I'd like to applaud their direct approach to the fix, seemingly based on OWASP recommendations. Should all web application developers take a similar path, we'd likely see a reduction in CSRF vulnerability statistics.
Let me walk you through some of the 4images Gallery CSRF mitgation methods.
The core of the protection is includes/csrf_utils.php; CSRF protection is enabled by default.
As created by csrf_utils.php, generate a random MD5-derived token:

Return said token to the form as follows:

Then when some jerk like me comes along and throws something nasty at an admin...

...the attacker is thwarted by a unique, random token.

Add to the above-mentioned functionality the fact that the 4images devs allow you to take advanced control of CSRF protection via the config.php file. You can manage the default bit or maintain granular control of frontend/backend protection, token expiration, CSRF protection variable naming, and even XHTML vs. HTML.

I appreciate the efforts undertaken by Kai and the Dots United team in response to this vulnerability, and look forward to other development teams/vendors hopefully taking a similar tack.
Happy sailing. ;-)
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Tuesday, November 02, 2010
toolsmith: Confessor & Mole for IR & security analysis
As November 2010's toolsmith kicks off the fifth year of the column for the ISSA Journal, I am proud to use it as an opportunity to announce the official release of Bryan Casper's Confessor and Kris Thomas' MOLE.
I discussed these tools at ISSA International in September and again at SecureWorld Expo Seattle, and after a slight delay to clarify licensing (they're released under the Microsoft Public License (Ms-PL), both tools are available for you on CodePlex.
These tools were born of needing better utilities for incident response and security analysis in complex, massive cloud-like environments.
If you'd like a copy of the above-mentioned presentation, please contact me and I'll send it to you.
As described in the article, Bryan's Confessor answers the challenge of collecting system logs and attributes on hundreds or even thousands of systems at the same time, utilizing the same tools as MIR-ROR, but deploying them in an enterprise capable manner.
Note: Since the article's release Confessor has been updated to pass domain credentials via the UI and process host names as well as IP addresses.
Kris' MOLE was spawned improve on a method I’d been utilizing to cull malware from malicious URLs sent across Windows Live Messenger. Where I’d been using a specific wget string at the command-line Kris built MOLE (Malicious Online Link Engine) as a wrapper for wget that includes many additionally useful features.
We find these tools incredibly useful and are very pleased to be able to release them for public consumption as freely available and open source.
The article is here, Confessor is here, and MOLE is here.
Please ping me if you have questions; we look forward to your feedback.
Comments welcome here or via email.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
I discussed these tools at ISSA International in September and again at SecureWorld Expo Seattle, and after a slight delay to clarify licensing (they're released under the Microsoft Public License (Ms-PL), both tools are available for you on CodePlex.
These tools were born of needing better utilities for incident response and security analysis in complex, massive cloud-like environments.
If you'd like a copy of the above-mentioned presentation, please contact me and I'll send it to you.
As described in the article, Bryan's Confessor answers the challenge of collecting system logs and attributes on hundreds or even thousands of systems at the same time, utilizing the same tools as MIR-ROR, but deploying them in an enterprise capable manner.
Note: Since the article's release Confessor has been updated to pass domain credentials via the UI and process host names as well as IP addresses.
Kris' MOLE was spawned improve on a method I’d been utilizing to cull malware from malicious URLs sent across Windows Live Messenger. Where I’d been using a specific wget string at the command-line Kris built MOLE (Malicious Online Link Engine) as a wrapper for wget that includes many additionally useful features.
We find these tools incredibly useful and are very pleased to be able to release them for public consumption as freely available and open source.
The article is here, Confessor is here, and MOLE is here.
Please ping me if you have questions; we look forward to your feedback.
Comments welcome here or via email.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Tuesday, October 19, 2010
Checking for user-agent header SQL injection vulns
As I analyze various web applications in the name of fun or fortune, I am sometimes treated to those little reminders that result in a "doh!".
Such was the case when I was assessing the latest release of the Avactis Shopping Cart.
I'd just installed the latest free version (1.9.1). Typically, after finding a flaw in an vendor's offering, I sign up for their new release notices, and had recently received one from Avactis.
When last I'd visited said shopping cart I'd spotted a couple of XSS bugs in the checkout.php script for version 1.8.1 and earlier. I admit that at the time I did not do as robust review of the application as I might now; in all likelihood the following bug was present when the XSS bugs were disclosed in September 2008.
With a fresh version installed thanks to the reminder, I fired up Firefox with Tamper Data, and started poking around. With Tamper Data, as we've discussed before, any web form input parameters/variables are subject to your manipulation.
I habitually work from the right side of the Tamper Data UI wherein POST parameters reveal themselves.
There I sat, happily walking through the app, when the bell went off.
"Hey, Russ, don't forget to fuzz the header values too!"
Cross-site scripting and SQL injection specific to cookie values is certainly not unheard of but you may need to refer to a checklist to always remember to probe them for vulnerabilities.
In my case, this was even more true of the user-agent string value.
Not all apps are written to capture the user-agent data, but you can easily understand why shopping cart providers would make use of such information.
What's the point? Remember to investigate the user-agent header for issues too.
It can be a simple as appending a single tic on the end of the user-agent string and submitting it, as seen in Figure 1.

Figure 1
The results were immediate and revealing. In case you wondered what my typical user-agent entry looks like, Figure 2 will enlighten.

You can see that we've caught the query executed by /var/www/avactis/avactis-system/modules/reports/report-collectors/report_data_visitors_stat_collector.php, specifically SELECT_WEB_ROBOT_ID, and the result.
Which, in turn, clearly justifies the rapid and responsive patch provided by the vendor. I submitted the finding to Secunia on October 10th and the vendor posted the patch on October 12th; Secunia Advisory SA41764 was released as q result on October 14th.
A hearty "Well done!" to the Avactis team for that turnaround.
A quick diff of report_data_visitors_stat_collector.php from version 1.9.1 build 8356 as installed on October 9th and the patched version downloaded today is seen in Figure 3.

Figure 3
The tale is quickly told, and it's a good move by the Avactis dev team.
Begone ye damned addslashes()!
Note that the dev yanked use of the addslashes function on lines 49, 157, 238, and 318; addslashes() is a subject to circumvention, mysql_real_escape_string() is recommended.
See how much we can learn when remembering to be more thorough?
I must say, if I hadn't recently renewed my status as a certified Application Security Specialist, I might have missed this vulnerability altogether.
And I definitely would have missed out on the additional benefits such as photo opportunities with app sec glitterati (taken at the recent BlueHat). ;-)

Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Such was the case when I was assessing the latest release of the Avactis Shopping Cart.
I'd just installed the latest free version (1.9.1). Typically, after finding a flaw in an vendor's offering, I sign up for their new release notices, and had recently received one from Avactis.
When last I'd visited said shopping cart I'd spotted a couple of XSS bugs in the checkout.php script for version 1.8.1 and earlier. I admit that at the time I did not do as robust review of the application as I might now; in all likelihood the following bug was present when the XSS bugs were disclosed in September 2008.
With a fresh version installed thanks to the reminder, I fired up Firefox with Tamper Data, and started poking around. With Tamper Data, as we've discussed before, any web form input parameters/variables are subject to your manipulation.
I habitually work from the right side of the Tamper Data UI wherein POST parameters reveal themselves.
There I sat, happily walking through the app, when the bell went off.
"Hey, Russ, don't forget to fuzz the header values too!"
Cross-site scripting and SQL injection specific to cookie values is certainly not unheard of but you may need to refer to a checklist to always remember to probe them for vulnerabilities.
In my case, this was even more true of the user-agent string value.
Not all apps are written to capture the user-agent data, but you can easily understand why shopping cart providers would make use of such information.
What's the point? Remember to investigate the user-agent header for issues too.
It can be a simple as appending a single tic on the end of the user-agent string and submitting it, as seen in Figure 1.

Figure 1
The results were immediate and revealing. In case you wondered what my typical user-agent entry looks like, Figure 2 will enlighten.

You can see that we've caught the query executed by /var/www/avactis/avactis-system/modules/reports/report-collectors/report_data_visitors_stat_collector.php, specifically SELECT_WEB_ROBOT_ID, and the result.
Which, in turn, clearly justifies the rapid and responsive patch provided by the vendor. I submitted the finding to Secunia on October 10th and the vendor posted the patch on October 12th; Secunia Advisory SA41764 was released as q result on October 14th.
A hearty "Well done!" to the Avactis team for that turnaround.
A quick diff of report_data_visitors_stat_collector.php from version 1.9.1 build 8356 as installed on October 9th and the patched version downloaded today is seen in Figure 3.

Figure 3
The tale is quickly told, and it's a good move by the Avactis dev team.
Begone ye damned addslashes()!
Note that the dev yanked use of the addslashes function on lines 49, 157, 238, and 318; addslashes() is a subject to circumvention, mysql_real_escape_string() is recommended.
See how much we can learn when remembering to be more thorough?
I must say, if I hadn't recently renewed my status as a certified Application Security Specialist, I might have missed this vulnerability altogether.
And I definitely would have missed out on the additional benefits such as photo opportunities with app sec glitterati (taken at the recent BlueHat). ;-)

Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Saturday, October 09, 2010
toolsmith: The NirSoft Collection

As I mention in this month's toolsmith, I am often reminded of all the tools I have not yet written about but have used on numerous occasions or even forgotten about. Such is the case with the NirSoft tools, particularly those found on the Windows side of the Helix distribution under IR.
Five NirSoft tools resurfaced for me well worthy of toolsmith mention as well as a place in the jumpkit.
Incident handler Kris Thomas used CurrPorts during a PCI DSS-related incident response drill we were conducting and promptly located the fake malicious process I’d seeded on a server as part of the drill.
Light-bulb moment: October's ISSA Journal toolsmith: The Nirsoft Collection is written to help you prevent one of those "doh!" moments. "Oh yeah, I'd forgotten all about that tool."
I'll simply rehash visual results of various tests I conducted for October's article.
Figure 1 is a CurrPorts screen shot taken before infection of the test VM with Backdoor.Win32.Agent.adqt (MD5: 6DBA44B457414593A858A3520A2F2278).

Figure 1
Figure 2 is the same view post-infection with the addition of bonus IPNetInfo results.

Figure 2
OpenedFilesView is exactly what it says it is, open or locked files on a given Windows system.
Figure 3 is an OpenedFilesView snapshot before infection with Backdoor.Win32.Poison.apec (MD5: CB702C3319A27E792B84846D3D6C61AD).

Figure 3
Figure 4 represents OpenedFilesView perspective post-infection where you'll note that the malicious binary has invoked Internet Explorer as we see changes to index.
dat. A quick review of C:\Documents and Settings\...\Cookies\ shows two cookies written to the system dated 9/26/10 for globo.com. Again, a bit of search engine research via site:threatexpert.com globo.com will reveal endless hits on various malicious behavior associated with globo.com, with particular emphasis on Brazilian malware.

Figure 4
Like it's fellow OpenedFilesView, WhatInStartup couldn't be more precise in its naming if it tried. Yep, it identifies what auto-loads when the system starts; always a good place to look for malicious basterds [sic].
Figure 5 is a WhatInStartup baseline screen-shot.

Figure 5
Figure 6 shows WhatInStartup results after a rogua AV (Security Essentials 2010...annoying!) infection; specifically, Trojan.Win32.FraudPack.amgz (MD5: 59C0E80D7F9705D10DA91E01B2763E9A)

Figure 6
Last but not least, NirCmd. This tool is interesting not overtly security-centric but good for pulling up registry entries or killing processes particularly when explorer.exe is hung.
Example: nircmd.exe regedit “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run”
The article is available here, the tools and others are here.
Use these oldies but goodies in good stead.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Saturday, September 18, 2010
CSRF on the increase per two reports
As I've spent almost all of my research time this past year focusing on finding and disclosing (coordinated) CSRF vulnerabilities, it was with some amusement that I read CSRF Vulnerabilities Rise, Overall Vulnerability Disclosures Dip from Kelly Jackson Higgins last week.
Therein she states that "overall, the number of vulnerability disclosures for the year is gradually declining to around 4,500 from nearly 7,000 last year, with the exception of CSRF, which had 155 vulnerabilities as of the first half of the year." This article is ultimately referring to TippingPoint DV Lab's Top Risks report.
Wolfgang Kandek, CTO at Qualys, follows with "CSRF is difficult ... and complex."
I must respectfully disagree, it's really not, but I'll discuss that in a minute.
I was pleased to run into Jeremiah Grossman at the ISSA International Conference last week, and he stated that CSRF has moved up on the imminently pending 10th WhiteHat Security Statistics Report. He was careful to pointy out however that its not because sites are more vulnerable to CSRF; rather, WhiteHat Security customers are more interested in having the issue reported combined with better Sentinel detection.
The point about better detection on WhiteHat's part ties back to my disagreement over the claim that CSRF is difficult and complex.
Exploiting CSRF is really not complicated at all, but it has been historically difficult to discover via automated scanning (sorry, Kevin ;-). There are nuances that require fairly significant manual interaction with a potentially vulnerable application; enumeration and parameter reconnaissance is required, followed by building forms specific to various POST requests. Consider Tamper Data your bff for this effort. Most importantly, noting the lack of a token/formkey/canary is generally the first, best step to determining CSRF vulnerability with targeted manipulation thereafter.
Of the 155 CSRF disclosures mentioned in Kelly's article for the first half of 2010, 14 are advisories I submitted through Secunia and are widely varied in their scope.
You'll note the expected vulnerable CMS platforms, but you'll also find HP printers, server logging agents, system management interfaces, and web mail providers.
My point is this, CSRF is not hard to find, is easy to exploit, and often remains unrepaired in web applications long after the other OWASP Top 10 biggies have been fixed.
Token up, people!
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Therein she states that "overall, the number of vulnerability disclosures for the year is gradually declining to around 4,500 from nearly 7,000 last year, with the exception of CSRF, which had 155 vulnerabilities as of the first half of the year." This article is ultimately referring to TippingPoint DV Lab's Top Risks report.
Wolfgang Kandek, CTO at Qualys, follows with "CSRF is difficult ... and complex."
I must respectfully disagree, it's really not, but I'll discuss that in a minute.
I was pleased to run into Jeremiah Grossman at the ISSA International Conference last week, and he stated that CSRF has moved up on the imminently pending 10th WhiteHat Security Statistics Report. He was careful to pointy out however that its not because sites are more vulnerable to CSRF; rather, WhiteHat Security customers are more interested in having the issue reported combined with better Sentinel detection.
The point about better detection on WhiteHat's part ties back to my disagreement over the claim that CSRF is difficult and complex.
Exploiting CSRF is really not complicated at all, but it has been historically difficult to discover via automated scanning (sorry, Kevin ;-). There are nuances that require fairly significant manual interaction with a potentially vulnerable application; enumeration and parameter reconnaissance is required, followed by building forms specific to various POST requests. Consider Tamper Data your bff for this effort. Most importantly, noting the lack of a token/formkey/canary is generally the first, best step to determining CSRF vulnerability with targeted manipulation thereafter.
Of the 155 CSRF disclosures mentioned in Kelly's article for the first half of 2010, 14 are advisories I submitted through Secunia and are widely varied in their scope.
You'll note the expected vulnerable CMS platforms, but you'll also find HP printers, server logging agents, system management interfaces, and web mail providers.
My point is this, CSRF is not hard to find, is easy to exploit, and often remains unrepaired in web applications long after the other OWASP Top 10 biggies have been fixed.
Token up, people!
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Sunday, September 05, 2010
Everybody Loves REMnux
A quick read of the SANS Forensics blog, courtesy of Gregory Pendergast, and you'll get a feel for all the positive feedback for Lenny Zeltser's REMnux.
Lenny has dedicated himself to furthering the malware reverse engineering cause, both as a teacher and analyst; his SANS courses are popular for good reason.
September's toolsmith covers REMnux and offers some detail specific to its use.
One area I often use REMnux for is malicious Flash analysis.
Evil Flash, distributed in particular via online advertising platforms, is a constant concern for online providers. Suffice it to say that my team has encountered such problem children more than once. ;-)
As an example, an older sample (MD5: 525445764564B34070CF2F9DCC6C2DAA) makes for a great test case. You can grab the sample for your own testing at OffensiveComputing.net.
Imagine you've grabbed the sample via wget from your REMnux VM, after proxy-based analysis of the malicious URL.
A simple check for interesting results might be the likes of
flasm 525445764564b34070cf2f9dcc6c2daa.swf, which would result in a .flm file named identically for SWF file analyzed. Figure 1 shows the concatenated results.

Figure 1
While flasm is convenient, the preferred method would be
swfdump -Ddu 525445764564b34070cf2f9dcc6c2daa.swf
The -D switch provides full (everything) output, the -d switch prints the hex output, and -u shows the Tag IDs.
Figure 2 offers the results.

Figure 2
Note that that the DEFINEBUTTON2 config for Tag ID 4 grabs an URL then issues the ActionScript FSCommand:exec to execute arquivo.scr (never a good thing).
Tag ID 4 was conveniently named "bot" by its creator; why bother hiding, right?
With a modicum of effort, maliciousness confirmed, you're ready to take action: report the malicious SWF to the provider, or remove it you are the provider.
You'll enjoy REMnux; it's an excellent collection of useful tools gathered in a simple but functional distro.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Lenny has dedicated himself to furthering the malware reverse engineering cause, both as a teacher and analyst; his SANS courses are popular for good reason.
September's toolsmith covers REMnux and offers some detail specific to its use.
One area I often use REMnux for is malicious Flash analysis.
Evil Flash, distributed in particular via online advertising platforms, is a constant concern for online providers. Suffice it to say that my team has encountered such problem children more than once. ;-)
As an example, an older sample (MD5: 525445764564B34070CF2F9DCC6C2DAA) makes for a great test case. You can grab the sample for your own testing at OffensiveComputing.net.
Imagine you've grabbed the sample via wget from your REMnux VM, after proxy-based analysis of the malicious URL.
A simple check for interesting results might be the likes of
flasm 525445764564b34070cf2f9dcc6c2daa.swf, which would result in a .flm file named identically for SWF file analyzed. Figure 1 shows the concatenated results.

Figure 1
While flasm is convenient, the preferred method would be
swfdump -Ddu 525445764564b34070cf2f9dcc6c2daa.swf
The -D switch provides full (everything) output, the -d switch prints the hex output, and -u shows the Tag IDs.
Figure 2 offers the results.

Figure 2
Note that that the DEFINEBUTTON2 config for Tag ID 4 grabs an URL then issues the ActionScript FSCommand:exec to execute arquivo.scr (never a good thing).
Tag ID 4 was conveniently named "bot" by its creator; why bother hiding, right?
With a modicum of effort, maliciousness confirmed, you're ready to take action: report the malicious SWF to the provider, or remove it you are the provider.
You'll enjoy REMnux; it's an excellent collection of useful tools gathered in a simple but functional distro.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Sunday, August 22, 2010
Is Zeus an APT, or v3?
I've given a few presentations this past year regarding security visualization where I have implied for all intents and purposes that Zeus (or Zbot) can be considered part of the advanced persistent threat (APT) picture.
As I prepared for the most recent presentation to the ISSA Puget Sound chapter meeting I contemplated the premise of Zeus-as-APT a bit further, and also found myself amused by the implication that there was now a Zeus v3.
Let me first debunk the v3 claims.
The Zeus hype over the last few weeks has been off the charts given a brilliant marketing campaign from M86 who, in their latest white paper, have gone so far as to refer to certain Zeus variants as Zeus v3.
Quite simply, I disagree.
The M86 white paper states that "Zbot/Zeus v3 version is an evolved mutation of Zbot 2. Unlike the older version, this one focused specifically on online banking."
If this is the basis for declaring the samples analyzed for this white paper as v3 I must cry foul.
As an example, Figure 1 includes content from a Zeus v1 (yes v1, not even v2) config file that clearly targets online banking, specifically Wells Fargo. The MD5 hash for this sample is 3cfc97f88e7b24d3ceecd4ba7054e138 if you wish to confirm for yourself.

Figure 1
The Zeus version transition from v1 to v2 was born of the inclusion of code signing, advanced encryption methods, and licensing (one install per registered user, please). Either way Zeus has long targeted online banking and does not warrant new version nomenclature on this premise alone. I'll grant that mutations and variations are rapid amongst Zeus samples, with particular goal of avoiding detection, but in my opinion it's still the same v2 code-base.
While a bit more difficult to de-obfuscate, a recent Zeus v2 sample showed clear signs of classic Zeus behavior and targeted a mass of online banking offerings.
Figure 2 offers a small subset of targeted institutions pulled directly from the config file.
The MD5 hash for this sample is d86ba734b30c650b091dd39e7707872c and you can pull the sample for your own analysis from ZeuS Tracker.
Figure 2
As per the "Is Zeus an APT?" question, I have mixed feelings here.
I've recently read two excellent discussions on the matter that offer slightly different perspectives.
In Dr. Eric Cole's Advanced Persistent Threat: The Insider Threat, posted to Dark Reading on Aug 16th, he is very precise in his definition of APT:
"The entry point with many attacks is focusing on convincing a user to click on a link. However, once the APT breaks into a system, it is very sophisticated in what it does and how it works. Signature analysis will be ineffective in protecting against it. Advanced attacks are always changing, recompiling on the fly, and utilizing encryption to avoid detection."
Gary Hoglund's The shadowy world of the advanced persistent threat and botnets, posted to SC Magazine on July 15 offers a slightly different take:
"…botnets traditionally were not associated with state-sponsored attacks (sometimes called advanced persistent threats, or APT). While that characterization may have worked five years ago, it is completely outmoded for today's threat landscape. Botnets have evolved to become generic remote-access frameworks."
Dr. Cole further states that "stealth and being covert are the main goals of today's attacks. APT's goal is to look as close {if not identical} to legitimate traffic. The difference is so minor that many security devices cannot differentiate between them."
Zeus clearly communicates via "legitimate traffic", isn't noisy, and goes to great lengths to disguise itself.
Hoglund also points out that Zeus "has a plugin architecture, so any capability is possible. The base source code of Zeus readily is available, and attackers can easily customize the system for any purpose. There are hundreds of custom variations of Zeus in operation today.”
Following the sound logic from both of these gentlemen, Zeus is a bot used for APT-like attacks. While it may not often be used in very narrow, highly specific attacks (not to say that it isn't), it is certainly used in a very targeted fashion.
Attackers simply drop the C&C mechanism on hacked web server (see Figure 3), target a specific victim set, and collect data until shutdown, where after the move on.

This morning's RSS headlines included a most troubling reference from TrendMicro detailing Zeus being utilized for a deeply nefarious and specific purpose: targeting US military personnel bank accounts.
While this may be a broad victim audience, it's still targeted specifically to Bank of America Military banking users.
So is Zeus an APT? If not, it certainly partially qualifies; call it pseudo-APT.
Let me know what you think, of both the Zeus-as-APT debate as well as the M86-driven Zeus v3 ambiguity. Comments welcome.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
As I prepared for the most recent presentation to the ISSA Puget Sound chapter meeting I contemplated the premise of Zeus-as-APT a bit further, and also found myself amused by the implication that there was now a Zeus v3.
Let me first debunk the v3 claims.
The Zeus hype over the last few weeks has been off the charts given a brilliant marketing campaign from M86 who, in their latest white paper, have gone so far as to refer to certain Zeus variants as Zeus v3.
Quite simply, I disagree.
The M86 white paper states that "Zbot/Zeus v3 version is an evolved mutation of Zbot 2. Unlike the older version, this one focused specifically on online banking."
If this is the basis for declaring the samples analyzed for this white paper as v3 I must cry foul.
As an example, Figure 1 includes content from a Zeus v1 (yes v1, not even v2) config file that clearly targets online banking, specifically Wells Fargo. The MD5 hash for this sample is 3cfc97f88e7b24d3ceecd4ba7054e138 if you wish to confirm for yourself.

Figure 1
The Zeus version transition from v1 to v2 was born of the inclusion of code signing, advanced encryption methods, and licensing (one install per registered user, please). Either way Zeus has long targeted online banking and does not warrant new version nomenclature on this premise alone. I'll grant that mutations and variations are rapid amongst Zeus samples, with particular goal of avoiding detection, but in my opinion it's still the same v2 code-base.
While a bit more difficult to de-obfuscate, a recent Zeus v2 sample showed clear signs of classic Zeus behavior and targeted a mass of online banking offerings.
Figure 2 offers a small subset of targeted institutions pulled directly from the config file.
The MD5 hash for this sample is d86ba734b30c650b091dd39e7707872c and you can pull the sample for your own analysis from ZeuS Tracker.
Figure 2
As per the "Is Zeus an APT?" question, I have mixed feelings here.
I've recently read two excellent discussions on the matter that offer slightly different perspectives.
In Dr. Eric Cole's Advanced Persistent Threat: The Insider Threat, posted to Dark Reading on Aug 16th, he is very precise in his definition of APT:
"The entry point with many attacks is focusing on convincing a user to click on a link. However, once the APT breaks into a system, it is very sophisticated in what it does and how it works. Signature analysis will be ineffective in protecting against it. Advanced attacks are always changing, recompiling on the fly, and utilizing encryption to avoid detection."
Gary Hoglund's The shadowy world of the advanced persistent threat and botnets, posted to SC Magazine on July 15 offers a slightly different take:
"…botnets traditionally were not associated with state-sponsored attacks (sometimes called advanced persistent threats, or APT). While that characterization may have worked five years ago, it is completely outmoded for today's threat landscape. Botnets have evolved to become generic remote-access frameworks."
Dr. Cole further states that "stealth and being covert are the main goals of today's attacks. APT's goal is to look as close {if not identical} to legitimate traffic. The difference is so minor that many security devices cannot differentiate between them."
Zeus clearly communicates via "legitimate traffic", isn't noisy, and goes to great lengths to disguise itself.
Hoglund also points out that Zeus "has a plugin architecture, so any capability is possible. The base source code of Zeus readily is available, and attackers can easily customize the system for any purpose. There are hundreds of custom variations of Zeus in operation today.”
Following the sound logic from both of these gentlemen, Zeus is a bot used for APT-like attacks. While it may not often be used in very narrow, highly specific attacks (not to say that it isn't), it is certainly used in a very targeted fashion.
Attackers simply drop the C&C mechanism on hacked web server (see Figure 3), target a specific victim set, and collect data until shutdown, where after the move on.
This morning's RSS headlines included a most troubling reference from TrendMicro detailing Zeus being utilized for a deeply nefarious and specific purpose: targeting US military personnel bank accounts.
While this may be a broad victim audience, it's still targeted specifically to Bank of America Military banking users.
So is Zeus an APT? If not, it certainly partially qualifies; call it pseudo-APT.
Let me know what you think, of both the Zeus-as-APT debate as well as the M86-driven Zeus v3 ambiguity. Comments welcome.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Subscribe to:
Posts (Atom)
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...
-
toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...
-
When, in October and November 's toolsmith posts, I redefined DFIR under the premise of D eeper F unctionality for I nvestigators in R ...
-
You can have data without information, but you cannot have information without data. ~Daniel Keys Moran Here we resume our discussion of ...