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)

Suricata in toolsmith: meet the meerkat

Rather than fan the Suricata versus Snort flames (you're both great kids and I love you equally) I'm opting for Swiss-like neutrality and simply invite you to explore Suricata at length.
See Victor Julien's post on the matter as he sums it up succinctly.
While I've always been a Snort user, I've also long been an ardent supporter of Matt Jonkman's Emerging Threats. Given his logical progression towards the Open Information Security Foundation (OISF), a "non-profit foundation organized to build a next generation IDS/IPS engine", I felt deeply obligated to cover Suricata in toolsmith.

Suricata: An Introduction is my effort to oblige.

While this article is painfully introductory, it should whet your appetite.
Suricata, as the "product" of OISF, is compelling on different fronts.

1) Intent: "OISF’s primary goal is to remain on the leading edge of open source IDS/IPS development, community needs and objectives."
As such, Suricata "is not intended to just replace or emulate the existing tools in the industry, but will bring new ideas and technologies to the field."
Committing to community needs and objectives, much as Emerging Threats has, is noble and valuable.

2) Scale: My testing on a dual core box matches Victor's assessment.
"Is Suricata faster than Snort on a single core cycle for cycle, tick for tick? No. But we scale. We’ve had reports of running on a 32 core box and scaling to use all cores. There Suricata is much faster."
I believe performance at scale is essential/vital/critical to IDS/IPS success in this burgeoning age of all things cloud and virtual (think complexity, and mondo network traffic). Groundbreaking thinking on my part, I know. ;-)
Consider that an unnamed military body has tested Suricata versus Snort on a large scale platform (24 processors and 128GB of RAM) and saw a very clear 6-fold speed increase over a tuned Snort implementation on the same platform.

3) HTP Library: In a context similar to all things cloud (online services), effective HTTP normalization and parsing is mighty important. Ivan Ristic's HTP Library endeavors to provide "very advanced processing of HTTP streams for Suricata."

4) Features: I'll let the comparison chart speak for itself.



Performance geeks will definitely want to explore the use of PF_RING and leveraging CUDA-capable hardware. The article clarifies these a bit more.

5) Same rules (Snort-based): Need I say more?

These should be ample reasons for you to give Suricata a really close look.
Deploy it.
Give it every opportunity to prove itself side by side with your current IDS/IPS solution.
Keep an eye on the project site, and get involved.
Start by downloading 1.0.1 here.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Verizon Data Breach Report & OWASP Top 10's #6

The fact that Computerworld's Jeremy Kirk just reported that data breaches are often caused by configuration errors (as noted in Verizon's latest data breach report) should come as no surprise, yet I'm left shaking my head in continued disbelief at this issue's prevalence.

Per Jeremy, as summarized from the report:
"Verizon said it found that a surprising and "even shocking" trend is continuing: There are fewer attacks that focus on a software vulnerabilities than attacks that focus on configuration weaknesses or sloppy coding of an application."

Now we now why security misconfiguration is new to the OWASP Top 10 as of 2010, holding the #6 position.
Consider Figure 1 as ripped right from the OWASP Top 10 doc.


Figure 1

Can we agree that data breach qualifies as a "business impact"?

A recent example of classic security misconfiguration includes the design flaw in WordPress that, by default, allowed users to set up permissions that let anyone read their blog's wp-config.php configuration file; WordPress stores the bloggers' credentials in plain text (also OWASP Top 10 A9).
An attacker could create a scanner to locate all configuration files containing incorrect permissions, read database credentials, and compromise all found.


Figure 2

So easily avoided.

OWASP's recommendations include:
1. A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Dev, QA, and production environments should all be configured the same. This process should be automated to minimize the effort required to setup a new secure environment.
2. A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment.
3. A strong network architecture that provides good separation and security between components. Consider running automated scans periodically to help you detect future misconfiguration or missing patches.

Make it so!

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

ISSA Members: Connect regarding IR in cloud & complex environments

If you're an ISSA member please feel free to join the conversation on ISSA Connect regarding incident response challenges in highly complex, massive network volume, and/or cloud environments.
This discussion sets up a presentation I'll be giving at the ISSA International Conference on September 17, 2010 in Atlanta. Hope to see you there.
I have recommendations regarding tooling and methodology that I'll be sharing at the conference, but I'm really interested in hearing about your experiences under similar circumstances. What's worked for you and what hasn't?
Folks working for sizable online service providers, ISPs, cloud or SaaS providers, and have had some noteworthy technical challenges or experiences, you're the folks I'd like to hear from.
If your not an ISSA member feel free to comment here or email me (russ at holisticinfosec dot org).

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Messenger Abuser Malware Tactics

A common trend I see in both research and job duties is the use of instant messaging services to propagate malware.
"OMG, Russ," you say, "groundbreaking!" I know, I know.
This is all about tactics and trends.
Pushing malware through URLs sent over instant messaging should surprise no one who spends anytime in the infosec space, but once in awhile I spot persistent methods that are, if nothing else, relentless in their pursuit of victims.
You know the vector. A URL pops up in the IM client, victim clicks, off to the races.

With the vast popularity of social networking services, one obvious trait includes Facebook-oriented nomenclature where a URL and attacker domain might include the likes of hxxp://www.facebook.otsima.com/facebook_gallery.php?img=DSC004075208450.JPG.
"Look, Ma! It's from my Facebook friend! It's gotta be safe!" Uh-huh.
What's been interesting lately has been the number of executables that are named as image files; most often JPG as seen above.
Said sample above is Backdoor.Win32.Gootkit.

Another one following this pattern lately was found at hxxp://www.e-egypt.net/watch.php?=FOTO3436812.JPG.
A recent sweep for the string as part of this analysis found it referenced in the following:
hxxp://www.fuckyoutube.org/watch.php?=FOTO3436812.JPG (suspended)
hxxp://www.imagewhat.com/pictures/watch.php?=FOTO3436812.JPG (suspended)
Inevitably, they're served from a hacked server too, as seen on e-egypt.net; when explored at it's root offers Figure 1.


Figure 1

The binary disguised (thinly) as FOTO3436812.JPG is an unspectacular IRC bot with a tenacious master, given the numerous URL variants pointing to the same sample.
A quick run through ye olde sandbox produces a PCAP and behavioral analysis that indicates classic IRC behavior; again, very typical stuff known in some circles as the LolBot. But the bad guy (or so it seems) was nice enough to leave his "Facebook badge" on the server that the initially executed package calls home to for additional downloads. One directory jump up from where said additional download resides and you have Figure 2 (anonymized to protect the miscreant).


Figure 2

Nice, nothing like putting a face with your malware. ;-)

How about the endless VBTrojan malware served up with a bit of Brazilian (calls home to 200.98.197.93) spice via the file name MsnWebcawOnFiles1634.com (see the trend?):
http://msnfiles-webshow.serveftp.com
http://webmsn-fileshowrum.serveftp.com
http://webcawmsn-showrum.serveftp.com
The strings references include "desconhecido" ("unknown" or "strange" in Portuguese) and C:\Arquivos de programas. ;-) Beware the arquivos!

My favorite of late has been this one pushed behind a TinyURL.
This one was pretty good and there's very little detection for the binary yet.
The shortened version:
hxxp://www.tinyurl.com/DSC488398JPG (I love the DSC nomenclature like it just came off a phone or digital camera).
Redirect is to hxxp://03161b8.netsolhost.com/index.html, but the catch here is that index.html is actually the binary.
I have to say, I hadn't seen that one used before in this context. The trickery is improving.
But alas, it's still just an IRC bot:
NICK new[USA|XP]8092826
USER s "" "lol" :s
:001 irc.priv8irc9.com
Remember I mentioned the LolBot above with regard to a different sample?
Give it a few days. Once the detection is up to speed for this variant I'm reasonably certain we'll see it classified as Lol/Buzus/Panadol.
I'll take bets: the hash for index.html is 2B4B55CE4A991DBD9600246C7F9E080D.
We'll see if my neanderthal-like ability to spot trends holds water. ;-)

Like I said, what's old is new again. But maybe, just maybe, you learned something useful reading this far.

Sorry it's been a few weeks...busy, busy.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

CSRF flaws that pack a punch

Note: These findings were responsibly disclosed and vendor updates have been issued.
See the eBbox Platform advisory here and the Snare advisory here.

A year after DEFCON 17, cross-site request forgery (still one of my favorite bugs) continues to present itself in some mighty interesting places.
I've already talked about it in the likes of wireless routers, UPS units, and a variety of web apps.
But it gets more sketchy when the vulnerable application gives up the keys to the castle via CSRF.
I don't mean just admin rights to the app, I mean compromise leading to control of the OS or platform itself.
Before I go into detail please know that both vendors in question responded instantly, provided fix time-lines, and met them precisely with corrective updates.
Two cases in point, keeping in mind that CSRF is often referred to as the one-click attack.
First, eBox Platform.
eBox Platform describes itself as a catchall that can act as a Gateway, Infrastructure Manager, Unified Threat Manager, Office Server, Unified Communication Server or a combination of them. One single, easy-to-use platform to manage all your network services.
Er, or one really broad attack surface.
Give away all that power to one tiny code snippet.


Figure 1

Failure to tokenize requests to the application means successful compromise with one errant victim click. Sending a halt order as seen in Figure is but a pittance as any request submitted via the browser-driven web management interface can be maliciously manipulated.
Preventing this attack clearly should be prioritized by developers; CSRF is number six in the OWASP Top 10 for a reason.

Next on our list: Snare from InterSect Alliance.
From their website: Snare for provides front end filtering, remote control, and remote distribution for audit log and event log data.
One agent to rule them all; one CRSF bug to rule all agents.
Meh.
Even though the web app for the Snare client can be configured with a password and localhost restrictions, an attacker need only convince a victim to click a link; it's simple GET request CSRF to finish the job.
http://192.168.248.231:6161/setremote?str_RestrictIP=192.168.248.235&dw_Password=on&str_Password=password&dw_PortChange=on&dw_WebPort=84
This request resets the password and the port, restricts IP access as well (in case you couldn't tell ;-)) and, as an example, via Snare for Windows, allowing the attacker to dump local users, domain users, registry, etc. On the likes of an AIX system add "remote control, and remote distribution for AIX audit data, interfacing with the underlying AIX audit subsystem as a custom stream object."
Scary.

eBox has issued the following fixes:
The problem can be corrected by upgrading your system to the
following package versions:

eBox Platform 1.4:
ebox 1.4.7-0ubuntu1~ppa1~hardy1
libebox 1.4.5-0ubuntu1~ppa1~hardy1
ebox-remoteservices 1.4.7-0ubuntu1~ppa1~hardy1

Snare has issued the following fixes:
SnareWindows - 3.1.8
SnareWindowsVista - 1.1.5
SnareAIX - 1.5.1
SnareIrix - 1.4.1
SnareSolaris - 3.2.4
EpilogWindows - 1.5.4
EpilogUNIX - 1.3

Typical recommendations apply.
For system owners, be on the lookout for vulnerabilities of this nature as you make use of convenient web-based system management interfaces such as eBox and Snare.

For vendors, make use of SDL or SDLC methods, and mitigate these risks in advance of release.

Convenience and efficiency are critical to success in enterprise computing environments, but with great power comes great responsibility. ;-)
Cheers.

ADMIN Magazine article: Splendid Splunk

Approximately twice a year I write for Linux Magazine; I've covered nUbuntu, Adeona, and Security Visualization in previous articles.
When the editor asked me to participate in a system administration special edition I was intrigued as the edition was to be OS agnostic and include Linux, Windows, OpenSolaris, and others.
I didn't have to think for more than a minute to come up with a good security topic for system administrators.
Any of you readers work in hybrid operating environments where you're inevitably challenged to unify event monitoring and correlation with disparate systems?
I for one can answer that question in teh affirmative and am always seeking ways to answer that challenge.
Merging security and operational mindsets is essential when unifying events in hybrid environments and I have found Splunk to be incredibly useful as part of the effort.
Note: I wrote this article with no influence or feedback from Splunk (they'll learn of it here too) to avoid bias.
Splendid Splunk: Unifying Events with Splunk is the result of much testing and research to prove out methodology I've only implemented in part prior.
For security events, when an enterprise may not have budget for SEM/SIEM, the likes of Splunk fills the gap admirably. Yes, it's a commercial tool, but one can do a great deal with the community version to confirm my findings.

An excerpt:

Systems administrators, security engineers, and analysts share a common challenge in typical enterprise environments. Rare is the data center in which only one operating system is in use, or only one version of the same operating system. Monitoring and managing system events and security events across such hybrid environments is no small feat...choices need to be made when unifying events in a hybrid environment. For example, perhaps you have more of one operating system flavor than another in your environment. Or, perhaps you prefer one operating system over another.
No matter what your system counts, preferences, or comfort zones, Splunk can serve you well...to monitor your systems you can choose to use various channels in concert or exclusively:
• Both host types can also run Splunk as a light-forwarding agent.
• Windows and *nix hosts can also be monitored with Snare agents.
• Windows and *nix hosts can be monitored with OSSEC agents.
• Network devices can send syslog output directly to the Splunk server.
Depending on granularity, performance, and primary business driver, you can opt for some or all of the above. Personally, I tend to favor a combination of the Splunk light-forwarding method in concert with OSSEC agents, and syslog for network devices...

I cover methodology, installation, forwarding, Snare, OSSEC, searches dashboards, and alerting.
While there's a book's worth of Splunk use to write about, the article is intended to help you get a good running start.

ADMIN Magazine is available via subscription (quarterly with DVDs), single issue purchases online, or at magazine stands in the likes Barnes and Noble.

If the article is ever posted to the web by the publisher I'll update this post and let you know.
That said, the publication is well worth the coin as it covers network security, system management, troubleshooting, performance tuning, virtualization, and cloud computing.
Happy reading; let me know if you have questions.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Book Review: ModSecurity Handbook

In January I reviewed Magnus Mischel's ModSecurity 2.5.
While Magnus' work is admirable, I'd be remiss in my duties were I not to review Ivan Ristic's ModSecurity Handbook.
Published as the inaugural offering from Ristic's own Feisty Duck publishing, the ModSecurity Handbook is an important read for ModSecurity fans and new users alike. Need I remind you, Ristic developed ModSecurity, the original web application firewall, in 2002 and remains involved in the project to this day.
This book is a living entity as it is continually updated digitally; your purchase includes 1 year of digital updates. Ristic also wants to know what you think and will incorporate updates and feedback if relevant.

While the ModSecurity Handbook covers v2.5 and beyond, Ristic's is "the only ModSecurity book on the market that provides comprehensive coverage of all features, including those features that are only available in the development repository."
ModSecurity Handbook offers detailed technical guidance and is rules-centric in its approach including configuration, writing, rules sets, and Lua. Your purchase even includes a digital-only ModSecurity Rule Writing Workshop.

Chapter 10 is dedicated to performance as proper tuning is essential to success with ModSecurity without web application performance degradation.
That said, the highlight of this excellent read for your reviewer was Chapter 8, covering Persistent Storage.
ModSecurity persistent storage is, for all intents and purposes, a free-form database that helps you:
• Track IP address and session activity, attack, and anomaly scores
• Track user behavior over a long period of time
• Monitor for session issues including hijacking, inactivity timeouts and absolute life span
• Detect denial of service and brute force attacks
• Implement periodic alerting

Following the applied persistence model, I found periodic alerting most interesting and useful. From pg. 126, "Periodic alerting is a technique useful in the cases when it is enough to see one alert about a particular situation, and when further events would only create clutter. You can implement periodic alerting to work once per IP address, session, URL, or even an entire application."
This is the ModSecurity equivalent of a Snort IDS rule header pass action useful when internal vulnerability scanners might cause an excess of alerts.
ModSecurity rules that perform passive vulnerability scanning might detect traces of vulnerabilities in output, and alert on them. Periodic alerting would thus only alert once when configured accordingly.
As an example, perhaps you are aware of minor issues that are important to be aware of, but do not require an alert on every web server hit.
Making use of the GLOBAL collection, ModSecurity Handbook's example would translate the scenario above by following a chained rule match and defining a variable, thus telling you if an alert has fired in a previously. The presence of the variable indicates that an alert shouldn’t fire again for a rule-defined period of time. In concert with expiration and counter resets it is ensured that a rule will warn you only once in a your preferred period of time but still log as you see fit too.
Useful, right?

ModSecurity Handbook, in concert with Ristic's Apache Security, are must reads for web application security administrators and architects, but will not leave those who need step-by-step instructions at a loss.
Trust me when I say, all you need to harden your web presence with ModSecurity is at your fingertips with the ModSecurity Handbook.

Cheers and happy reading.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Web Security Tools²: skipfish and iScanner

June's toolsmith in the ISSA Journal covers skipfish and iScanner.

Skipfish and iScanner, albeit quite different, are both definite additions for your toolkits.
Reduction of web application security flaws as well as the identification and removal of obfuscated malcode are important ongoing processes as part of your proactive and reactive defensive measures.

Skipfish is an “active web application security reconnaissance tool that prepares an interactive sitemap for the targeted site by carrying out a recursive crawl and dictionary-based probes.”

iScanner is a Ruby-based tool that “detects and removes malicious code and webpages malware from your website with automated ease. iScanner will not only show you the infected files from your server but it’s also able to clean these files by removing the malware code from the infected files.”

The article awaits your review here.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

CSRF: Six Degrees of Kevin Beaver (or at least his printer)

Perhaps you followed the CSRF debate between RSnake and Kevin Beaver last month.
While I fall well on Robert's side of the tracks, Kevin made some interesting points.
I may take issue with some of them (ok, almost all of them) but Robert took him to task, and I'm pretty sure Kevin has done his penance ;-), so no need to beat that dead horse.
Except that scanner comment. Scanners <> CSRF detection; it's a largely manual check, and it actually does exist significantly more often than you might think (pretty much everywhere). Watch your Tamper Data or Burp sessions for requests made without tokens/formkeys/canaries, etc. and you'll soon know what I mean. There is no "high-quality vulnerability scanner" that will solve the CSRF challenge for you.

No matter your view or perspective, CSRF is pervasive, annoying to fix, and still lurking everywhere; it can be used to pwnzor your printer, your APC UPS, your website's shopping cart or CMS, or any other damned thing you expose to the Intarwebs that fails to check "exposure to unintended requests."
What value these targets? Depends on your motive.
Stealing printer resources? Probably not. ;-)
But a CSRF attack against a website operator who's using the likes of osCommerce, Zen Cart, or eclime (15 million+ at last check) and is foolish enough to be using one of them to manage credit card data? Game over.

Heck, CSRF vulns are so widespread that we could rate number 5 on the OWASP Top 10 like a video game...Rated E for Everyone, just like your Mom. Ohhh!

When I popped my new HP Photosmart C4700 on my home network and changed the admin password via CSRF with twenty second's worth of HTML, it all came to a head.
How do you patch that?
Vendors like HP and APC, who are extremely responsive to disclosures, no matter how low hanging the fruit, still can't easily update their software and expect all customers to apply the fix.
Then there all the vendors who do nothing (you know who you are).
Good code and responsible vendors are paramount, but so too is consumer awareness and understanding of risk.
What if a properly targeted "one click" attack turns off the power outlets on a UPS device with a hospital's ICU servers connected to it?
Is life in the balance?
Our "mysterious" web bug changes the nature of that very question.
Overly dramatic, sure, but you get the point.
Who'd be to blame under those circumstances?

So what's the solution (write secure code)?
I recognize that I'm asking more questions than providing answers (write secure code), but I'm at a loss as to how to solve poor coding practices easily (write secure code). Perhaps you, dear reader, have some ideas (write secure code).

Maybe RSnake should just CSRF Kevin Beaver's printer, force it to print a bunch of copies of OWASP's Development Guide, and we'll call it good. ;-)

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Memory forensics with SIFT 2.0, Volatility, and PTK

May's toolsmith takes a close look at SIFT 2.0, the forensics workstation associated with the SANS 508 track.



SIFT 2.0 is best utilized as a VM via your preferred version of VMWare but can also be installed as a permanent standalone workstation.
I spend much of time touting memory analysis as a key component of incident response and forensics, and SIFT 2.0 offers two of the most capable memory analysis offerings available: Volatility and PTK. As I say in the article, I don't do either tool the justice it deserves but it should whet your appetite. I owe both Volatility and PTK their own write-ups, if not the MoonSols Memory Toolkit as well.
Regardless, SIFT 2.0 is extremely practical for forensic processing and case management. Assuming you have a decent storage footprint, you can opt to keep a unique virtual instance of SIFT for each case your handling.
For this article I used SIFT with Volatility and PTK to dig more deeply into a victim memory image of a Banload-infected host.
You'll quickly see how to get right to the bottom of an incident using only memory analysis.
The article is here.

Cheers and and enjoy.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

I am a narcissistic vulnerability pimp

The Verizon Business Security Blog has drawn the line in the sand of the kitty litter box they're apparently playing in, labeling those who irresponsibly disclose "information that makes things less secure" as narcissistic vulnerability pimps.
Wow.
Time to pull those iPhone wannabes from betwixt the Verizon lily whites and dial 1-866-GET-CLUE.
I love it when risk "experts" start sounding off about that of which they know nothing.
As members of the Verizon Risk Intelligence group, clearly an oxymoron, Wade Baker and Dave Kennedy must be the same guys who describe risk level in the cloud as .4.
What?
Here's a secret.
Vulnerability disclosure is, as Robert Graham says, rude at its core.
"Hey Mr. Vendor, your code sucks, fix it."
But what about when Mr. Vendor decides to blow off the security researcher who tried on numerous occasions, via numerous channels to disclose a vulnerability?
So when that security researcher goes public after vendor FAIL, he's now a narcissistic vulnerability pimp?
Is Charlie Miller a security researcher or a narcissistic vulnerability pimp?

Attrition.org (d2d) recently summed this conundrum up succinctly:
"So what is actually responsible or ethical? The lines are blurred quite a bit. The "responsible" method is also the "painful", "expensive", and often "ineffective" method that gets little resolved for exponentially more work, time and money. Is all that waste not irresponsible? What about all of the other organizations unknowingly affected by things I've found, organizations who never got a heads-up, no less a patch, because my attempts at "responsible" disclosure failed?"

No matter how you define it, disclosure drives vendors to repair code they would otherwise neglect and leave vulnerable for the real criminals to exploit.
Yes, risk may be elevated in the time period between disclosure and repair, as well as repair and patch deployment. But if researchers wait on the likes of Oracle to fix their kluges, nothing would ever get fixed.

Dan Goodin says in his writeup, "as the recent Pwn2Own contest made abundantly clear, software makers can't be counted on to secure their products, at least not on their own."
Dan clearly be styling some bling of his own.

I at Holisticinfosec.org do hereby resolve to faithfully ignore Verizon Risk Intelligence dreck forthwith.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Moral Hazard: URL shorteners must improve malware prevention

Suffice it to say that my job duties include trying to help reduce malicious URLs being transmitted over Windows Live Messenger.
As you can likely imagine, URL shorteners (TinyURL, Bit.ly, etc.) give me conniptions.
Blocking the root domain is not feasible as the majority of URL shortener use is not malicious.
Can you say "whack-a-mole"?
Bit.ly, as an example, claims to be scanning URLs for malware, but with 40 million plus shortened URLs a day, they are definitely missing their share of malware-lade URLs.
TinyURL suffers from the same challenges; even though they have a strict Terms of Use, endless malicious URLs are shortened via TinyURL who seems to only employ a reactive prevention model (report it and they'll remove it).
Thus, topping the list of URLs being passed via Messenger on any given day is often the likes of tinyurl.com/y6v689z.
Click and a Russian free web host offers you fotos16.com, a Trojan-Downloader.Win32.Banload variant.
What's old is new again (first detected in 2006), but no less effective when coupled with simple social engineering. Simply, the Banload Trojan downloads other Trojans and aims to steal your banking credentials.
The victim receives an IM, often from a trusted contact, that evokes Facebook content: "Hey, check out my latest Facebook pics!" No shocker there, someone targeting popular Internet resources as part of their attack methodology? Groundbreaking.
But you know what? It works over and over and over again.
All day long.
Until the cows come home.
So what does our shortened URL with a social networking lure get us?
All sorts of bonus goodies.
This sample helped remind me of how much I love NetworkMiner.
Thrash my trusty Windows XP VM, capture the network traffic, and voila, we quickly learn all we need to know.
Our Banload friend got busy in the 80 seconds I let it run in my home lab environment.
14 sessions, 23 DNS queries, 11 file downloads, and three authenticated (credentials captured as they are passed in the clear) SMTP exchanges with Brazilian free mail hosts.
Gotta have somewhere to send all those stolen credentials right?



Soapbox time.
I liken the failure of URL shortening providers to better protect users from malware to a moral hazard.
A moral hazard is "the lack of any incentive to guard against a risk when you are protected against it (as by insurance)."
A strongly worded Terms of Use does not indemnify the likes of Bit.ly, TinyURL, and others.
Too many people are getting pwnzored.
Better efforts to prevent malicious abuse of URL shortening services must ensue.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Dradis: Effective Information Sharing for Pentest Teams

April's toolsmith covers Dradis.
Dradis is a self-contained web application that provides a centralized repository for information acquired during testing in order to work completed and pending.
The Dradis project lead, Daniel Martín Gómez contends (and I agree) that failure to share “information available in an effective way will result in exploitation opportunities lost and the overlapping of efforts.”
Testing teams face multiple challenges specific to information sharing, including a variety of output types from all the tools utilized.
Testers gather results in different ways.
Each team generates different reports, and so on.
Dradis is designed to address these challenges and does so effectively.
Check it out at your earliest convenience.

The article awaits your review here.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Malware behavior analysis: studying PCAPs with Maltego local transforms

In recent months I've made regular use of Maltego during security data visualization efforts specific to investigations and analysis.
While Maltego includes numerous highly useful entities and transforms, it does not currently feature the ability to directly manipulate native PCAP files.
This is not entirely uncommon amongst other tools, particularly those specific to visualization; often such tools consume CSV files.

With thanks to Andrew MacPherson of Paterva for creating these for me upon request for recent presentations, I'm pleased to share with you Maltego local transforms that will render CSVs created from PCAP files. Simple, but extremely useful.

I'll take you step by step through the process, starting with creating CSVs from PCAPs.
For those of you already comfortable with PCAP to CSV conversion and/or using local transforms with Maltego, here are the pyCSV transforms:

GetSourceClients.py
GetDestinationClients.py

All others, read on.
Raffael Marty's AfterGlow (version 1.6 just released) includes tcpdump2csv.pl which uses tcpdump/windump to read a PCAP file and parse it into parametrized CSV output.

Windows users, assuming that Perl is installed and all files and scripts reside in the same directory, execute:
windump -vttttnnelr example.pcap | perl tcpdump2csv.pl "sip dip dport" > example.csv.

Linux users:
tcpdump -vttttnnelr example.pcap | tcpdump2csv.pl "sip dip dport" > example.csv

To integrate the pyCSV local transforms with your Maltego instance:
1. Click Tools, then Manage Transforms.
2. Click New Local Transforms.
3. Define the Display name as the name of the local transform. Example: GetSourceClients
4. Each transform must map to an entity. Do so as follows for
each transform as you create it:
getSourceClients to Phrase
getDestinationClients to IP Address
5. Click Next.
6. The Command field should point to Python binary (C:\Python25\python.exe on Windows, /usr/bin/python
on Ubuntu 9.10).
7. The Parameters field should refer only to the transform name. Example: GetSourceClients.py
8. Work Directory should be the complete path to the directory where you keep the Nmap local transform Python scripts (suggest C:\localTransforms\pyCSV for Windows users).
9. Finish, then Save.



You'll also need a copy MaltegoTransform.py in your local transforms directory (included with the Maltego python lib during installation).

During a recent Zeus bot investigation, I used GetSourceClients.py and GetDestinationClients.py as follows:

1) Convert zeus.pcap, captured during malware analysis in a virtual ennvironment,
to zeus.csv: tcpdump -vttttnnelr zeus.pcap | tcpdump2csv.pl "sip dip dport" > zeus.csv

2) Drag a Phrase entity into the Maltego workspace, and using CopyPath, pasted the full path to the zeus.csv into the Phrase entity.

3) Right-clicked the Phrase entity, chose All, then getSourceClients.



4) Right-clicked the IP entity created for my infected host, chose All, then getDestinationClients.



5) Egress traffic to a likely malicious host immediately jumped out of the Maltego workspace at me. I right-clicked (after removing the port reference in the IP entity label) and selected AllTransforms.



6) Maltego's results were swift and validated my immediate assumption. 115.100.250.105 is a malicious Chinese (omg, really?) Zeus C&C server. Nice.
Highlighting a Website entity then choosing Detail View will tell you everything you need to know.



"Size matters not. Look at me. Judge me by my size, do you? Hmm? Hmm. And well you should not. For my ally is Maltego, and a powerful ally it is."

Yoda's right. ;-)

If you have any questions or would like saved transforms, PCAPs, or binary samples, ping me at russ at holisticinfosec dot org.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Presentations available: RSA, ISACA, and Agora

It's been a busy month of presentations including RSA Conference 2010, ISACA Puget Sound, and the Agora.
The Agora is a "successful strategic association that meets quarterly to bring together the pacific Northwest's top information systems security professionals and technical experts, as well as officers from the private sector, public agencies, local, state and federal government and law enforcement."
At RSA and Agora I discussed tactics intended to compare security data visualization to strictly textual output generated by IDS/IPS. These discussions included details on AfterGlow, Rumint, NetGrok, and Maltego.
At the ISACA Puget Sound chapter meeting I covered securing the company web presence (common security threats to your web presence and what you can do about it). This talk included details specific to the OWASP Top 10 and the CWE/SANS Top 25.
The RSA presentation is here.
The ISACA presentation is here.
The Agora presentation is available upon request (russ at holisticinfosec dot org).

There are PCAPS, scripts, and binary samples discussed in all of these presentations. Should you wish copies of any or all, please contact me.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

#6 of the Top Vulnerability Discoverers of 2009

As I was last year, I am again pleased to report that the vulnerabilities I've been happily and responsibly disclosing and posting have resulted in 6th place on the list of Top Vulnerability Discoverers of 2009. Thanks to Scott Moore of the IBM ISS Frequency X Blog who compiled the list for 2009.
I remain both pleased and disconcerted to find myself on this list and wish to convey a few thoughts on the subject.

1) First, a reminder that my work has focused entirely on vulnerable web apps and pales in comparison to the likes of others named on both the all-time list and the list for 2009. Congratulations and well done to you all.

2) My efforts resulted in what the Frequency X post indicates is 48 unique web application vulnerabilities in 2009. This again serves as a stark reminder of what a challenged state of affairs the development process is for so many web application vendors. May the SDL and its ilk prevail.

3) I will continue my discovery and reporting efforts with the intention of somehow making a dent in the statistics (unrealistic, I know). I focused heavily on cross-site request forgery (CSRF) issues in 2009 and was not surprised to find that the average number of days for CSRF vulnerabilities to be resolved increased by 37 days to 93 days.



The above figure can be found on page 7 of the 8th Edition of WhiteHat's Website Security Statistics Report.
I believe, as the report states, that much of the reason CSRF issues linger unabated is that "no one at the organization knows about, understands, or respects the issue."
I can tell you from personal experience, I heard this many times in 2009.
It should therefore surprise no one that CSRF is number four on the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors.
Hopefully, each application discovered and reported as vulnerable to this issue leads to a downward statistical trend in the likes of the WhiteHat report.

I look forward to continued discussions of these issues with you, dear readers, and hope we can make a difference.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

RSA: Visualizing the Zeus attack against government and military

In keeping with my presentation this Friday at RSA, I managed to time my toolsmith topic to correlate precisely; specifically, visualizing the recent Zeus attack against government and military. For the article I discuss NetGrok and AfterGlow; for the RSA presentation I'll be more focused on NetGrok and Maltego as the present more readily for a live audience. Now that "advanced persistent threat" or APT is the latest buzz word/acronym/phrase we can reminisce that good old Zeus was amongst the best and brightest of early APT adopters. ;-)

From the RSA presentation abstract:
The flood of raw data generated by intrusion detection systems (IDS) is often 0verwhelming for security specialists, and telltale signs of intrusion are sometimes overlooked in all the noise. Security visualization tools provide an easy, intuitive
means for sorting through the dizzying data and spotting patterns that might indicate intrusion…the presentation will focus on specific tools and methodology to aid you in establishing security data visualization practices in your environment.

From the article:
I’ll accentuate this theme as the crux of our toolsmith discussion this month while discussing NetGrok and After-Glow and additionally introduce timely sample analysis of the targeted Zeus bot attacks in early February against U.S. government institutions.

See how that all pulls together? ;-)
The article is here.
The RSA presentation is in Orange Room 306 at 10:10 on Friday, March 5.
If you're attending RSA, I hope to see you there.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Financials and the need for software regression testing

SearchFinancialSecurity.com just published my article regarding Financials and the need for software regression testing.
This article cites Ameriprise as an example of a financial services provider who would benefit from improved regression testing and version control.

This article was actually written prior to the recent SQL bug I discussed involving Ameriprise, and is made even more interesting by discussion of a possible small, unrelated Ameriprise data breach in New Hampshire.

I truly hope Ameriprise takes a close look at the suggestions offered and moves towards enhancing security practices on behalf of their consumers.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Online finance flaw: Ameriprise III - please make it stop

NOTE: This issue was disclosed responsibly and repaired accordingly.

"Now what?", you're probably saying. Ameriprise again? Yep.
I really wasn't trying this time. Really.
There I was, just sitting in the man cave, happily writing an article on version control and regression testing.
As the Ameriprise cross-site scripting (XSS) vulnerabilities from August 2009 and January 2010 were in scope for the article topic, due diligence required me to go back and make sure the issue hadn't re-resurfaced. ;-)
I accidentally submitted the JavaScript test payload to the wrong parameter.
What do you think happened next?
Nothing good.
I reduced the test string down to a single tic to validate the simplicity of the shortcoming; same result.



At the least, this is ridiculous information disclosure, if not leaning heavily towards a SQL injection vulnerability.
As we learned the last two times we discussed Ameriprise, the only way to report security vulnerabilities is via their PR department, specifically to Benjamin Pratt, VP of Public Communications.
Alrighty then, issue reported and quickly fixed this time (same day)...until some developer rolls back to an old code branch or turns on debugging again.

We all know the ColdFusion is insanely verbose, particularly when in left in debugging mode, but come now...really?
I really didn't want to know the exact SQL query and trigonometry required to locate an Ameriprise advisor.
Although, after all this, I can comfortably say I won't be seeking an Ameriprise advisor anyway.

Please Mr. Pratt, tell your web application developers to make it stop.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Directory traversal as a reconnaissance tool

Like most of you, I find malicious or fraudulent online advertisers annoying to say the least.
My typical response, upon receipt of rogue AV pop-ups, or redirects to clearly fraudulent sites, is to "closely scrutinize" the perpetrating site.
This effort often bears fruit as is evident in the following analysis.

My interest was recently peaked when being made aware of a number of related sites committing abuse against a variety of brands; all quite clearly in violation of copyrights and trademarks.
An example, for your consideration: messenger-download.info
After a little exploration it was quickly determined that these cretins seek only to con victims out of credit card data with the promise of illegal downloads for a fee.
Apparently these dbags have been at it for awhile.
They make it look like you're going to receive access to a legitimate offering then they suck you in to freedownloadzone.com.
This, of course, pissed me off, so...off to the races.
A poke here, a tickle there, and voila.../etc/passwd.



This Centos server, running Apache 2.2.3 (very dated), complete with craptastic PHP code, is a textbook lesson in how to not run a web server.
Includes, anyone?



What's lovely about grabbing /etc/passwd with directory traversal (file path traversal, if you prefer) is the discovery of all the additional abusive URLs in play on this same server. Additionally you'll note more than a few culprits, learned to be based in the Phillipines after running their user names through Maltego.
Here's a text dump of the raw /etc/passwd grab.

A little regex parsing produced 256 +/- URLs, all pointing back to freedownloadzone.com, and all GoDaddy domains (shocking!).
Rather than post all the URLs here, for brevity, please refer to the text file.

Lesson to be learned for the bad guys: secure development practices apply to you as well, or the whitehats may come knocking.

A parting thought for freedownloadzone.com, and it's shadow org, helpmedownload.com.
By the way, you have XSS issues too: http://bit.ly/cT2P8F

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

toolsmith: Firefox Addons for the Security-minded

Few websites are safe from a hearty probe when I come by for a visit, and I'd be remiss if I didn't share some of my favorite Firefox add-ons utilized as part of said probing.
I opted to do just this as the topic for February's toolsmith, and focused on the expected standards (NoScript, FoxyProxy Standard, BetterPrivacy, and Torbutton) as well as some of my less known favorites.

PassiveRecon
Justin Morehouse’s PassiveRecon will let you dig up everything you ever wanted to know about a given site you may be browsing or analyzing.

WorldIP
WorldIP from WIPmania.com is very cool and very useful.
It provides everything you could every need to know or trace with regard to IP addresses and geolocation.

Groundspeed
I saved the best for last; a new powerhouse in my web app sec arsenal.
Felipe Moreno-Strauch’s Groundspeed, a newer add-on “that allows security testers to manipulate the application user interface to eliminate annoying limitations and client-side controls that interfere with the web application penetration tests.”
And this it does well. ;-)

The article is live for your reading pleasure here.

Cheers and enjoy.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Online finance flaw: Ameriprise FAIL...again

Here we go again.
The cross-site scripting (XSS) issues on the Ameriprise advisor locator site were fixed, even if temporarily, back when Dan Goodin reported on the issue in August.
A little bird whispered in my ear the other day and told me a sad tale:
they're baaaaack.
Regression testing anyone?
Regression testing (from the Wikipedia entry recommends that:
"in most software development situations it is considered good practice that when a bug is located and fixed, a test that exposes the bug is recorded and regularly retested after subsequent changes to the program.
What a grand idea! Ensure that you don't reintroduce old flaws when you roll old code.
Really? I have to say it?
Apparently.



Dan & El Reg have covered the issue again given that, in order to have it fixed again, I had to ask him to ping the Ameriprise PR department.

*sigh*

BTW...the issue is fixed, for now. ;-)

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

DEF CON 17 CSRF Videos Remastered

Thanks to Adam Gerstein for reminding me to get off my butt and produce the Def Con 17 CSRF videos in a more streamable format.
Adobe Flash Player required; no, I won't pwn you.
If you'd like to see the whole presentation video, goofy as it may be, it's here.
Be forewarned, it's freaking huge and takes a fat pipe to pull it down in any reasonable amount of time.
The presentation slides are here.

The Dokeos CSRF PoC video is here.

The Linksys CSRF PoC video is here.

The osCommerce CSRF PoC video is here.
Note: Please don't use osCommerce, they still haven't fixed this and probably never will.

BONUS VIDEO (discussed but not shown at Def Con)
The Netgear CRSF PoC video is here (QuickTime and sorta crappy, sorry).

Enjoy.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)