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)

Drilling into web application flaws & HIPAA: the root of the issue

Herein we merge dental hygiene with development hygiene. ;-)

I recently changed dentists, and after my fist visit (successful and pleasant) I soon received follow up email from Demandforce D3 on behalf of my new dentist. Said email pointed me to an application feature that included the ability to set my email preferences for future contact as well as additional functionality.
I'll present the $64,000 questions right up front.
My understanding of website HIPAA requirements adhere to the following statement from Einstein Medical:
"Since practice web sites provide for email correspondence from potential or current patients that may contain protected health information, practice web sites must be HIPAA compliant."
"HIPAA requires health care providers to implement secure networks for the transmission of all private health information, including information contained in email correspondence."

For information transmission to be considered secure, three elements are necessary:

1) Authentication – identification of the senders/receivers of the information (i.e. must have a unique username)

If I can XSS a HIPAA protected site and can steal the auth cookie, is authentication sound?

2) Non-repudiation – verification that the senders/receivers of the information are who they say they are (i.e. must use a password)

If I can CSRF a HIPAA protected site is non-repudiation guaranteed?

3) Integrity – verification that information cannot be tampered with in transit (i.e. the information is sent through a network that cannot be easily “hacked” or “broken into”)

Both XSS and CSRF are, in essence, tampering when used to an attackers advantage; thus integrity is in question.

As I reviewed the Demandforce D3 application I was immediately struck by what appeared to be flawed dentistry...er, development, and discovered an input cavity in dire need of filling. I know, I know...stick to your day job, Russ.
Fine, screen shots below for your consideration.

While considering the above mentioned authentication, non-repudiation, and integrity bullet points above, please take note of the cookie in Figure 1 and complete XSS defacement in Figure 2, which could just as easily be a fake logon page.

Figure 1


Figure 2


Thinking the best path to Demandforce D3 would be through my new dentist, I contacted the office manger, who immediately forwarded my email to Demandforce D3.
Demandforce D3 quickly remediated the issues, quietly but successfully.

So I ask you, compliance experts, what of web application security flaws and HIPAA?
Are my interpretations accurate or am I just another pretty smile with no substance?
I look forward to your feedback, comments welcome.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

XSSing Bob: At least GoDaddy got this one right

Fair warning: This posting has a social agenda, born of my views, and will likely spark discussion. Flame all you want, but no anonymous comments accepted for this one.

I'll come right out and say it. I'm not a GoDaddy fan...at all.
I've long shared Fyodor's perspective (NoDaddy.com) and as a SecLists/nmap loyalist must swear my fealty.
And don't get me wrong, I appreciate beautiful women as much as the next guy, but they're people, not things. The level of objectification that Bob Parsons and GoDaddy have maintained during their relentless ad campaign (ramping up again for football season) is sadly archaic, exploitative, and not in keeping with a modern mindset I've hoped would be embraced more broadly.

I know I am in the minority. This is simply my opinion; I'm sure that vast majority of men who read this blog will fervently disagree with me. So be it, I honor your choices, may this free country remain ever so.

But I hate it. Women aren't objects. Believe me, I've been guilty of thinking and acting otherwise, but damn it, I'm trying. In my world women are wives and daughters, peers and managers, teachers and friends; all worthy of respect.
So when the latest GoDaddy ad harshed my football mellow this past weekend during the defensive debacle that was the Packers/Cardinals game, I found myself pissed.
Ask McAfee, neglectful credit card companies, and lame online providers what happens when I get pissed.
Yep, I got all huffy and went looking for web application issues to use to further my point.
Bobparsons.me coughed up easy fodder in short order.



Then my conscience got the best of me, and I reported the issue immediately via privacy at bobparsons.me.
I always take this step with low expectations, but was rewarded with a rapid and thoughtful response.
I reported the issue at 1910 hours, 11 January and received a call from the CISO himself, Neil Warner, who left me a VM indicating that the issue had been received, validated, and repaired by the security and development teams, all before 1200 12 January; less than 24 hours. Impressive to say the least.

So, while I heartily disagree with GoDaddy marketing tactics and shake my head when I read the endless stream of horror stories on NoDaddy, I must applaud Neil and his team for a job well done. He even used the term "human IDS." ;-)
Nicely done, Neil, nicely done.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Single Packet Authorization: The Ghost in the Machine

The first toolsmith of 2010 discusses one of my favorite concepts: single packet authorization (SPA).
In Single Packet Authorization: The Ghost in the Machine you'll discover the advantages of Michael Rash's (Cipherdyne) SPA with fwknop over Port Knocking:
1. SPA requires only a single encrypted packet in order to communicate various pieces of information, including desired access through a firewall policy and/or complete commands to execute on the target system.
2. fwknop keeps iptables in a "default drop" stance, thus protecting services such as OpenSSH with an additional layer of security, making exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult.
3. With fwknop deployed, port scanners looking for sshd won’t find it; it makes no difference if a 0-day vulnerability exists or not.
4. The authorization server passively monitors authorization packets via libcap; there is no "server" connection in the traditional sense.
5. Access to a protected service is only granted after a valid encrypted and non-replayed packet is received from an fwknop client.
6. SPA can utilize asymmetric ciphers for encryption.
7. SPA packets are non-replayable.
8. SPA cannot be broken by trivial sequence busting attacks.
9. SPA only sends a single packet over the network; IDS will not interpret it as a port scan.
10. SPA is much faster because it only sends a single packet.

For this toolsmith I took Michael's concept of an SPA ghost service up a notch to show just how low and slow we can fly:
Imagine you’re part of a highly secretive pen testing team working on site with a major corporate client. The client is surprisingly secure, monitors well, and locks outbound traffic to http and pop3. They proxy and content monitor http traffic as part of data leak prevention, so anything you do over port 80 is likely to be noticed. Further, they block the vast majority of web addresses, limiting access to just a few approved sites. All said and done, you’ll get nowhere over port 80. However, traffic bound for port 110 is surprisingly not monitored due to an oversight. Helpful, but you still need to be very stealthy.
You’ve managed to sneak into their datacenter and deploy your workstation, but to further your foothold you need a customized Python script that didn’t make it in your toolkit when you deployed to the client site. Your handler back at your office can present the file to you via a one-shot NetCat connection like this:

( cat PSKpredict.py; ) | nc -q 1 -l -p 6543

Your handler set the NetCat listener to an uncommon port (6543) and has left the firewall closed. Remember, you’re a highly paranoid and hopefully stealthy organization. He has, however, allowed fwknop to open that port via access.conf (PERMIT_CLIENT_PORTS: Y;) when properly authenticated to.
Now you can bind fwknop to port 110 to sneak out of the client network and grab the file we need on the server back in the Batcave.

SPA with fwknop has unlimited potential as far as I'm concerned, and Michael's pending code revisions will likely only improve it further.

Read the whole article here, and be sure to visit cipherdyne.org.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Book Review: ModSecurity 2.5

As promised in November, following is a review of Magnus Mischel's ModSecurity 2.5 from Packt Publishing.

ModSecurity 2.5 covers the latest release of ModSecurity, "a web application firewall deployed to establish an external security layer that increases security, detects, and prevents attacks before they reach web applications. With over 70% of all attacks now carried out over the web application level, organizations need every help they can get in making their systems secure."
- ModSecurity makes full HTTP transaction logging possible, allowing complete requests and responses to be logged.
- ModSecurity can monitor the HTTP traffic in real time in order to detect attacks.
- ModSecurity can also act immediately to prevent attacks from reaching your web applications.
- ModSecurity includes a flexible rule engine and can be deployed embedded or as a reverse proxy.

Covering ModSecurity 2.5 comprehensively and intelligibly is no small feat, and Mischel has achieved the goal. His style is concise yet clear, technical but not overly verbose, and well organized.
As "complete guides" go ModSecurity 2.5 meets the standard.
All the expected content is present, from installation to configuration, audit logging to chroot jails, blocking and protection, Mischel is thorough and takes due care to be precise and accurate.

I have already recommended this book to a vendor in dire need of improved protection for their web application. I'll give you one guess regarding why they said "We can't use ModSecurity." Yep, performance. To which I said, "Yeah, but how's your performance with the terrible code you've written and the resulting SQL injection attack that took your site apart?"
All of which takes us to my favored highlight of ModSecurity 2.5; specifically an entire chapter dedicated to performance. This was a great decision of Mischel's part. Performance is an important variable when utilizing ModSecurity and Mischel covers the fundamentals. He recommends using httperf and establishing a baseline without rules loaded. Response time, memory usage, and CPU usage are key. Once you've gathered necessary metrics, the same testing pattern with rules loaded will give you all the data you need to optimize. Mischel offers optimization concepts including memory consumption, bypassing static content inspection (think image files, JavaScript, and binary downloads), and using the @pm and @pmFromFile phrase matching operators (new in ModSecurity 2.5) to significantly speed up tasks normally left to regex matching (think 200 times faster).

My criticisms of this book are editorial in nature; there is one truly egregious editing flaw and another odd decision.
First, the page heading for the entirety of Chapter 5 (Virtual Patching) reads as Chapter 9. That's an error that a high school newspaper editor would catch and is simply unforgivable.
Additionally, where Mischel discusses writing rules at great length in Chapter 2, I would have chosen to immediately follow with the REMO (Rule Editor for ModSecurity) content as Chapter 3 rather than sticking it in Chapter 8.

Magnus Mischel's ModSecurity 2.5 is a worthy read and a recommended purchase, and earns 3.5 stars out of 5 (very good).
As the Web Application Security Consortium releases WASC Threat Classification v2.0, there is much to consider in the way of web application threats; ModSecurity 2.5 will certainly contribute to your protection arsenal.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)