HolisticInfoSec.org

Watcher: Spotting dubious webishness

2009-11-02T19:36:00.000-08:00

November's toolsmith features Watcher, a great passive security auditor from Chris Weber of Casaba Security, that detects web application security issues as well as operational configuration concerns. Watcher plugs neatly into Fiddler, an indispensable proxy that should be an inherent part of your web application assessment tool kit.
The toolsmith article covers using Watcher to detect "dubious" comments, unset HTTPOnly flags, open redirects, and bad cross domain flash policy, so I won't repeat myself here.
Watcher is also excellent for detecting likely XSS vulnerabilities, and will passively detect prospective parameters while you browse.
As an example, a visit to a site that shall remain anonymous only to those without fundamental Google skills results in Figure 1, seen by Watcher as it passively reviews a site with 37 different checks.

Figure 1

Note that Watcher spots what it declares is a potentially high severity user controllable HTML element attribute. Watcher further indicates that the fourth input tag value attribute is specific to the keyword variable. A quick "active" test by the author quickly validates Watcher's assumptions as seen in Figure 2.

Figure 2

Passive security auditing indeed; no effort required!
Results are easily exported as well.
Browse a client site while enjoying a good sandwich and coffee, dump the results, and build your work list as a preliminary recon step for your next penetration testing engagement.
Enjoy this excellent tool; use it in good stead.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

PILOT: Production in lieu of testing (AgoraCart FAIL)

2009-10-21T13:33:00.000-07:00

SUBTITLE: "I won't test, and you can't make me!"
SUBSUBTITLE: "I can't test what I obviously don't understand, and don't care to."

So often code goes live (or stays live) just as defined in this post's title: production in lieu of testing.
Put this thinking together with vendor/developers who clearly don't understand security risks, and you end up with a spectacular FUBAR.
First, a rhetorical question:
Why is testing (security and QA) so often neglected, overlooked, ignored, or poorly conducted?
The answers we've all heard:
We have to get product to market, we can't waste time.
We're so resource limited, we don't have enough time and people to test properly.
Second, what happens when a vendor/developer combines bad testing practices with carelessness?
Let's use AgoraCart as an example. I reported an AgoraCart CSRF vulnerability via Secunia, that is now live with an advisory.

NOTE: I am discussing this in full detail given that the vendor clearly indicated the issue as a "won't fix", or perhaps more succinctly, "no clear understanding of why to fix", as seen below.

Let me summarize the vendor's response; you tell me if it sounds like a pilot program under our above definition. ;-)

"...they'd also need to know the exact location according to this... plus it would have to have no other security measures installed. So it's very obscure and relies on being tricked form outside sources such as infiltration via PHP weaknesses etc, then the outside source would have to have the exact path AND still have a session active (which would only target one site). Too much "IF" in this one. I'm finding this bug too speculative and too dependent upon things found only in a lab.

The last time we had a bug like this come to our attention, it was the same scenario, but we had it verified to be the opposite of the claims. So I'm doubtful on this one unless we can actually verify it in a wild situation that is standard for implementation.

So I'll need more time to find this so we can fix it or show that it's minimal or whatever needs to be done. But so far we have been unsuccessful on our live servers and looking for others to do testing on."

Er, what? Really?
Oh boy.

I'll address these one by one.
1) "They'd also need to know the exact location".
Sure, that the nature of exploiting web application vulnerabilities. A little spidering, a snippet of tampering, play a little fuzz the parameter or pass the unchecked request and the game is afoot.
2) "plus it would have to have no other security measures installed."
Uh, no. If your web app doesn't prevent forced administrative requests made by the authenticated user on behalf of the attacker, no other security measures will prevent this attack.
3) "it's very obscure and relies on being tricked from outside sources such as infiltration via PHP weaknesses etc"
Man, it's getting thick now. The only trickery required here is that someone clicks a link in an email, or if the attack is GET based, simply visit a malicious GIF. Being tricked from outside sources such as infiltration via PHP weaknesses? That doesn't even make sense. Are you kidding me? The only weakness here can be found in your responses. Ask the CEO of StrongWebmail about being tricked from outside sources. He can tell you all about it.
4) "then the outside source would have to have the exact path AND still have a session active (which would only target one site)."
Yes, but again, PATH as you define it, is incredibly easy to determine. And social engineering never worked to exploit someone with an active session, right?
5) "I'm finding this bug too speculative and too dependent upon things found only in a lab."
I simply don't know what to say to this one. Wow.
5) "I'll need more time to find this so we can fix it or show that it's minimal or whatever needs to be done. But so far we have been unsuccessful on our live servers and looking for others to do testing on."
Come on, man, I sent you a clear cut example with source code via Secunia; they even added another one to try and help you understand.
IT WORKS ON ANY VERSION OF AGORACART...ANYTIME, ANYWHERE.

Here's how easy it is in a nutshell. The exceedingly simple PoC below will change htaccess settings for AgoraCart via CSRF, via POST request when a victim clicks a link for this page:

Secunia's example showed how to change the AgoraCart admin password.
Perhaps a video of a similar weakness in the osCommerce shopping cart may help convince AgoraCart to revisit this.
As shown at DEFCON, this video shows a CSRF vulnerability that leads to immediate credit card compromise via an admin account creation (one click, one account, done deal).
So if PoC code and multiple communications with clearly stated risks associated with this vulnerability aren't enough for AgoraCart, and a video explanation of the weakness in a similar product doesn't provide sufficient motive, I'm not sure what will do the trick.

Perhaps this lax attitude explains why BlueHost decided to drop AgoraCart all together. ;-)

FIRST TIME SALES QUESTION [5:36:33 PM]: Did you folks get rid of AgoraCart as a shared server offering?
Corbin [5:36:45 PM]: We did yes
FIRST TIME SALES QUESTION [5:37:47 PM]: Ok. Thanks. No worries, but any idea why?
Corbin [5:38:10 PM]: fewer then 5% of people were using it so we decided it was not worth keeping
FIRST TIME SALES QUESTION [5:38:28 PM]: Good call. Buggy anyway. Thanks, Corbin. G'nite

So that's it: no need to fix what no one uses. ;-)

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Adito now OpenVPN ALS

2009-10-18T08:27:00.000-07:00

SSL-Explorer --> Adito --> OpenVPN ALS

The Adito project, discussed often here and in toolsmith, is now OpenVPN ALS.
Back on April 23rd, Francis Dinha, CEO of OpenVPN Technologies, contacted me after reading my March 2009 toolsmith article on Adito and asked about working with the project to become part of OpenVPN. I connected Francis with Adito project developer Samuli Seppanen, they reached an agreement, and Adito is now OpenVPN ALS.

Francis recently indicated that he's in the process of hiring more developers and will assign a developer specifically to the ALS project. With more QA testing and improvement, OpenVPN Technologoies will soon consider OpenVPN ALS fully stable.

Download it today, give the project feedback, and look forward to further enhancements.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

MIR-ROR 1.2 to debut at Digitial Crimes Consortium 2009

2009-10-10T12:27:00.000-07:00

I'm pleased to announce that MIR-ROR 1.2 is now available.
This is noteworthy on the eve of the Digital Crimes Consortium 2009 on Microsoft campus in Redmond, WA this coming week, where I'll be discussing the The AntiMalware Lifecycle with Tareq Saade from the Microsoft Malware Protection Center (MMPC).
I'll be covering the incident response part of the life-cycle while Tareq will provide much insight on the anitvirus detection and signature creation process.
As part of my discussion on incident response in major enterprise data centers, I've included MIR-ROR, as it was created for just such a purpose. More succinctly, we use the tool we created, and I'll demonstrate specifics.
If you aren't aware of MIR-ROR: Motile Incident Response – Respond Objectively, Remediate MIR-ROR, it' a security incident response specialized, command-line script that calls specific Windows Sysinternals tools, as well as some other useful gems, to provide live capture data for investigation.
You can read the complete ISSA Journal article, MIR-ROR: Motile Incident Response – Respond Objectively, Remediate, here.

Three people made contributions to the MIR-ROR 1.2 release.
Much thanks to:
Javi Perojo, Jim Krev, and Chris Dalessandro

MIR-ROR 1.2 includes:
1) Improved directory and log naming
2) Writes EULA acceptance to registry, removes -accepteula switch from command strings
3) Logs MAC times to separate logs for target drive
4) Adds OpenPorts
5) Collects all event logs, tab separated, written to individual log files

If you intend to be at DCC 2009, please say hi.
I'll also be presenting security visualization methods at SecureWorld Expo Seattle later this month. If I don't see you at DCC, perhaps I'll see you at SecureWorld.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Using OSSEC to monitor ModSecurity and Wordpress

2009-09-30T13:29:00.000-07:00

As the October ISSA Journal begins to make the rounds, readers will note OSSEC as the topic of my toolsmith column.
The topic was chosen by Doug Burks of Security Onion as part of the Pick a Toolsmith Topic contest (we'll do it again).
As a result Doug won Zero Day Threat: The Shocking Truth of How Banks and Credit Bureaus Help Cyber Crooks Steal Your Money and Identity. Thanks again, Doug.
The article is available for all readers here.

While I discussed OSSEC as it pertains to Snort logs, PCI compliance, application (misuse) monitoring and auditing, as well as malware behavioral analysis, I spent very little time discussing the use of OSSEC with ModSecurity or Wordpress.
So here's where I magically tie it all together. ;-)
Given the title of the book Doug won, what's one way we might help prevent cyber crooks from stealing our money and identity?
Monitor our web applications, of course! With OSSEC. See how I did that?

OSSEC and mod_security

As an example, on an Ubuntu server running Apache generating mod_security audit logs, include the following in ossec.conf (var/ossec/etc):

OSSEC will then alert on mod_security events.
You'll need to tune and filter; you may receive quite a few alerts, but once optimized the results will be quite useful.

OSSEC and Wordpress

Using OSSEC HIDS with Wordpress is already nicely documented.

Highlights from OSSEC pages:
WPsyslog2 is a global log plugin for Wordpress that keeps track of all system events and writes them to syslog. It tracks events such as new posts, new profiles, new users, failed logins, logins, logouts, etc.
It also tracks the latest vulnerabilities and alerts if any of them are triggered, becoming very useful when integrated with a log analysis tool, such as OSSEC HIDS.

No matter what you wish to monitor, even if it's simple server well being, you'll find OSSEC indispensable. Making use of it as part of your web application security arsenal is a giant step in the right direction.

Feedback welcome, as always, via comments or email.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

CSRF attacks and forensic analysis

2009-09-20T22:08:00.000-07:00

Cross-site request forgery (CSRF) attacks exhibit an oft misunderstood yet immediate impact on the victim (not to mention the organization they work for) whose browser has just performed actions they did not intend, on behalf of the attacker.
Consider the critical infrastructure operator performing administrative actions via poorly coded web applications, who unknowingly falls victim to a spear phishing attack. The result is a CSRF-born attack utilized to create an administrative account on the vulnerable platform, granting the attacker complete control over a resource that might manage the likes of a nuclear power plant or a dam (pick your poison).

Enough of an impact statement for you?

There's another impact, generally less considered but no less important, resulting from CSRF attacks: they occur as attributable to the known good user, and in the context of an accepted browser session.
Thus, how is an investigator to fulfill her analytical duties once and if CSRF is deemed to be the likely attack vector?

I maintain two views relevant to this question.
The first is obvious. Vendors and developers should produce web applications that are not susceptible to CSRF attacks. Further, organizations, particularly those managing critical infrastructure and data with high business impact or personally identifiable information (PII), must conduct due diligence to ensure that products used to provide their service must be securely developed.

The second view places the responsibility squarely on the same organization to:
1) capture verbose and detailed web logs (especially the referrer)
2) stored and retained browser histories and/or internet proxy logs for administrators who use hardened, monitored workstations, ideally with little or no internet access
Strong, clarifying policies and procedures are recommended to ensure both 1 & 2 are successful efforts.

DETAILED DISCUSSION

Web logs
Following is an attempt to clarify the benefits of verbose logging on web servers as pertinent to CSRF attack analysis, particularly where potentially vulnerable web applications (all?) are served. The example is supported by the correlative browser history. I've anonymized all examples to protect the interests of applications that are still pending repair.

A known good request for an web application administrative function as seen in Apache logs might appear as seen in Figure 1.

Figure 1

As expected, the referrer is http://192.168.248.102/victimApp/?page=admin, a local host making a request via the appropriate functionality provided by the application as expected.

However, if an administrator has fallen victim to a spear phishing attempt intended to perform the same function via a CSRF attack, the log entry might appear as seen in Figure 2.

Figure 2

In Figure 2, although the source IP is the same as the known good request seen in Figure 1, it's clear that the request originated from an unexpected location, specifically http://badguy.com/poc/postCSRFvictimApp.html as seen in the referrer field.
Most attackers won't be so accommodating as to name their attack script something like postCSRFvictimApp.html, but the GET/POST should still stand out via the referrer field.

Browser history or proxy logs
Assuming time stamp matching and enforced browser history retention or proxy logging (major assumptions, I know), the log entries above can also be correlated. Consider the Firefox history summary seen in Figure 3.

Figure 3

The sequence of events shows the browser having made a request to badguy.com followed by the addition of a new user via the vulnerable web applications add user administrative function.

RECOMMENDATIONS

1) Enable the appropriate logging levels and format, and ensure that the referrer field is always captured.

For Apache servers consider the following log format:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog log/access_log combined

For IIS servers be sure to enable cs(Referer) logging via IIS Manager.
Please note that it is not enabled by default in IIS and that W3C Extended Log File Format is required.

2) Retain and monitor browser histories and/or internet proxy logs for administrators who conduct high impact administrative duties via web applications. Ideally, said administrators should use hardened, monitored workstations, with little or no internet access.

3) Provide enforced policies and procedures to ensure that 1 & 2 are undertaken successfully.

Feedback welcome, as always, via comments or email.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

OffVis 1.1 now available

2009-09-14T20:54:00.000-07:00

A quick update on OffVis as September's toolsmith on the same topic begins to arrive in ISSA Journal subscriber's mailboxes.
MSRC Engineering Security Research & Defense has released OffVis 1.1, along with a detailed and insightful video (best viewed with IE) on the OLESS Office legacy binary file format.
The new release includes bug fixes, enhancements, and additional detected CVEs.
Download OffVis 1.1, watch the video, and read the article if you spend any time analyzing Office malware.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Disclosure standards and why they're critical

2009-09-04T08:40:00.000-07:00

If you've read this blog over the last couple of years you've likely made note of the varying degrees of success I've had disclosing vulnerabilities.
You've seen the best of breed in AppRiver and SmarterTools.
You've also seen lessons in how to not handle disclosures in the likes of American Express and Ameriprise. I believe Ameriprise is Pwnie-worthy for Lamest Vendor Response given that Benjamin Pratt, Ameriprise’s vice president of public communications, said "There's no one at risk here." and that there are no plans to review any of the mechanisms the company may have in place to receive notifications from the public about website vulnerabilities. Wow. The Consumerist clarified those statements aptly with "we assume he means, "No one important on our side of things. Our customers can suck it."

I take disclosure very seriously. I believe it is a deep seated, inherent responsibility that rests squarely on the shoulders of vendors and site operators. Equally, disclosure must be responsible, even when efforts to advise the vendor have come up empty. To that end: ReportSecurityFlaws.com, the result of a recent interview I gave to by Ira Victor of the Data Security Podcast on the topic of mishandled disclosures. We decided on a joint project, thus ReportSecurityFlaws.com.

Report Security Flaws exists to increase awareness and responsiveness in Internet vendors and web site operators when they receive security-related disclosures.
It is our hope that all vendors/operators maintain an email alias that exists for the sole purpose of receiving disclosure notices from parties reporting noted security flaws on the vendor/operator’s web site.

Further, said email alias should be monitored by individuals with an understanding of web application security issues and business logic flaws, while maintaining a close working relationship with the site developers and operations engineers. This relationship should allow for the quick escalation of reported issues for mitigation and remediation.
Examples of such email alias might include:
security@domain.com
websecurity@domain.com
webreports@domain.com

Too often vendors and web site operators fail to manage the proper intake and escalation of reported security flaws, leading to lapses in web application security for days, weeks, and even months.

Report Security Flaws will provide resources and guidance for vendors and site operators facing such challenges, with the hope of improving internet security posture for vendor/operators and consumers alike.

If you, dear reader, have tried to no avail to drive a site operator/web vendor/cloud provider to fix flaws, and received no reply, let us know. ReportSecurityFlaws intends to serve as a public motivator to close such gaps and promote improved vendor response, complete with standards.

NOTE: ReportSecurityFlaws is not intended to out vendors who fail to fix. Rather, it is to use all means necessary to ensure they do fix, and promote better standards and practices.

With standards in mind, I've been participating in discussions regarding ISO/IEC 29147, which will hopefully be embraced globally as the ISO standard Security
techniques – Responsible vulnerability disclosure.
We also believe there is an opportunity for the PCI Council to incorporate stringent disclosure practices in the PCI DSS.

Disclosure can and must be handled properly. This week's reading included a remarkable and detailed public incident report from Apache to the compromise they'd suffered the week prior. This kind of transparent, open response does, as they clearly state, make the internet a better place. Well done, Apache.

Stay tuned for more....
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

toolsmith: OffVis 1.0 Beta - Office visualization tool

2009-09-01T14:15:00.000-07:00

My monthly toolsmith column in the September 2009 edition of the ISSA Journal features OffVis, a tool for detecting malicious Microsoft Office documents. This tool was created by MSRC's Engineering team, a group that spends a great deal of time looking for ways to detect exploitation of given vulnerabilities, in particular those that are Office-related.
Their efforts led to the creation of OffVis, starting in November 2008. First released in beta to MAPP participants, it has matured into a UI-based tool that analyzes a very specific set of vulnerabilities in order to better help defenders. MSRC Engineering’s work allows them to build detection logic, and then reuse it as part of ongoing analysis efforts.

Excerpt:
A typical targeted attack often includes an email sent to an intended victim with a malicious Excel document attached. When the victim opens the Excel document the following sequence might occur. First, it exploits a vulnerability to force Excel to run embedded shellcode. The shellcode then extracts an XOR’d, well-formed XLS file, and an EXE. The XLS opens in Excel, and the extracted EXE is executed which installsa backdoor as a service.9 This actual limited targeted attack resulted in Microsoft releasing KB 94756310 on January 15, 2008. The OffVis Excel parser includes detection logic for CVE-2008-0081,11 the National Vulnerability Database CVE released in accordance with KB 947563. We’ll look at a specific sample exploiting CVE-2008-0081 in Using OffVis.
Stepping through the exploit more specifically might appear as seen in Figure 2.

Figure 2

Typical exploit structure (Figure 3) ensures that everything is included in the document; please note that there can be variations including multiple shellcode stages, multiple Trojans, and obfuscation of both Trojan and the document.

For a much deeper dive into exploit structure, as well as disassembly and debugging techniques, see Bruce Dang’s topical Black Hat Japan 2008 presentation.

Figure 3

The article PDF is here.
Grab OffVis here.
Thanks to Dan, Kevin, Bruce, Robert, and Jonathan for the time and feedback that contributed to this month's article.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Amex II: Ameriprise mishandles disclosure too

2009-08-20T13:45:00.001-07:00

Yet another online finance flaw for your consideration.
Remember the American Express issue?
Apparently the negligence and ignorance of the parent has been inherited by the child.
It took me pinging Dan Goodin at The Register and asking him to shake Ameriprise out of their slumber to address the most commonplace, simple, web application bug of all: XSS. Really? Still?
Dan did a bang up job of the task at hand; it was fixed within hours. Ameriprise had ignored my multiple attempts to disclose over five months. Power of the press, eh?
The story is here.
I also owe Laura Wilson at Information Security Resources for alerting me to likely issues with Ameriprise.
I'm tired of having to say it. It's even gotten to the place where readers get pissed at me because I keep stressing the point. But I shouldn't have to.
Major financial providers should not be ignoring reports of common web application vulnerabilities sent in via all their available channels.
Major financial providers should be reviewing their web sites and their code at regular intervals, proactively preventing these issues.
Blah, blah, blah...you can't hack a server with XSS.
If you attended BlackHat or Defcon a few weeks ago, you may realize how much less relevant that argument is.
Check out the XAB, Firefox extensions, and evasion discussions.
You can be pwned through XSS.
Do I need to stress compliance again? Amex touts itself as a founding PCI partner, yet here we go again.
Vendors and developers need to get smarter, faster, and more responsive to security related notifications, particularly with regard to their websites.
To that end, keep an eye on the Data Security Podcast. Ira Victor and I have hatched a scheme to promote the use of proper disclosure handling by website operators such as major financial services providers. He'll also be posting podcasted discussions we've had regarding the disclosure issues, as well as the forensic challenges presented by CSRF attacks (another easily avoided, common web application vulnerability).
I'll also be talking about a pending ISO standard for disclosure that I hope will begin to drive enterprise adoption of improved disclosure handling.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Linux Magazine: Tools for Visualizing IDS Output

2009-08-14T22:34:00.000-07:00

The September 2009 issue (106) of Linux Magazine features a cover story I've written that I freely admit I'm very proud of. Tools for Visualizing IDS Output is an extensive, comparative study of malicious PCAPs as interpreted by the Snort IDS output versus the same PCAPs rendered by a variety of security data visualization tools. The Snort rules utilized are, of course, the quintessential ET rules from Matt Jonkman's EmergingThreats.net. This article exemplifies the power and beauty of two disciplines I've long favored: network security monitoring and security data visualization.

Excerpt:
The flood of raw data generated by intrusion detection systems (IDS) is often overwhelming 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. Certain analysis and detection tools use PCAP, the Packet Capture library, to capture traffic. Several PCAP-enabled applications are capable of saving the data collected during a listening session into a PCAP file, which is then read and analyzed with other tools. PCAP files offer a convenient means for preserving and replaying intrusion data. In this article, I'll use PCAPs to explore a few popular free visualization tools.For each scenario, I’ll show you how the
attack looks to the Snort intrusion detection system, then I’ll describe how the same incident would appear through a security visualization application.

The article gives DAVIX its rightful due, but also covers a tool to be included in the next DAVIX release called NetGrok. If you're not familiar with NetGrok, visit the site, download the tool and prepare to be amazed.

I'll be presenting this work and research at the Seattle Secureworld Expo on October 28th at 3pm. If you're in the area, hope to see you there.

This issue of Linux Magazine is on news stands now, grab a copy while you can. It includes Ubuntu and Kubuntu 9.04 on DVD so it's well worth the investment.

Grab NetGrok at your earliest convenience and let m know what you think.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

AppRiver: SaaS security provider sets standard for rapid response

2009-08-06T16:10:00.000-07:00

On July 28th I was happily catching up on my RSS feeds before getting ready to head of to Las Vegas for DEFCON when a Dark Reading headline caught my eye.
Tim Wilson's piece, After Years Of Struggle, SaaS Security Market Finally Catches Fire, drew me in for two reasons.
I'm a fan of certain SaaS Security products (SecureWorks), but I also like to pick on SaaS/cloud offerings for not shoring up their security as much as they should.
The second page of Tim's article described AppRiver, the "Messaging Experts" as one of some smaller service providers who have created a dizzying array of offerings to choose from.
That was more than enough impetus to go sniffing about, and sure enough, your basic, run-of-the-mill XSS vulnerabilities popped up almost immediately.

Before...

After...

Not likely an issue a SaaS security provider wants to leave unresolved, and here's where the story brightens up in an extraordinarily refreshing way.
If I tried, in my wildest imagination, I couldn't realize a better disclosure response than what follows as conducted by AppRiver AND SmarterTools.
Simply stunning.

Let me provide the exact time line for you:
1) July 28, 9:49pm: Received automated response from support at appriver.com after disclosing vulnerability via their online form.

2) July 28, 9:55pm: Received a human response from support team lead Nicky F. seeking more information "so we can look into this".
(SIX MINUTES AFTER MY DISCLOSURE)

3) July 28, 10:27pm: Received a phone call from Scott at AppRiver to make sure they clearly understand the issue for proper escalation.
(NOW SHAKING MY HEAD IN AMAZEMENT)

4) July 29, 6:35am: Received an email from Scottie, an AppRiver server engineer, seeking yet more details.

5) July 29, 8:51 & 8:59am: Received a voicemail and email from Scottie to let me know that one of the vulnerabilities I'd discovered was part of 3rd party (SmarterTools) code AppRiver was using to track support requests.
(MORE ON THIS IN A BIT)

6) July 29, 2:08pm: Received email from Steve M., AppRiver software architect, who stated that:
a) "We deployed anti-XSS code today as a fix and are using scanning tools and tests to analyze our other web applications to ensure nothing else has slipped through the cracks. We do employ secure coding practices in our development department and take these matters seriously. We appreciate your help and are going to use this as an opportunity to focus our development teams on the necessity and best practices of secure coding."
b) "Regarding XSS vulnerabilities you detected in the SmarterTrack application (the above mentioned 3rd party tracking app) from SmarterTools, one of our lead Engineers and myself called them this morning explaining the vulnerability and requesting an update to fix the problem. We also relayed to them that a security professional had discovered the vulnerability and would be contacting them to discuss it further."
(I AM NOW SPEECHLESS WATCHING APPRIVER HANDLE THIS DISCLOSURE)

NOTE: Less than 24 hours after my initial report, the vulnerabilities that AppRiver had direct ownership of were repaired.

7) July 29, 4:17pm: Received an email from Andrew W at SmarterTools (3rd party tracking app vendor) who stated "thank you for pointing this out to us... we will be releasing a build within the next week to resolve these issues."
(CLEARLY STATED INTENTIONS)

8) August 4, 8:02am: Received another email from Andrew W at SmarterTools who stated "we plan to release our next build tomrrow morning. (Wednesday GMT + 7) I will let you know as soon as it becomes available for download on our site."
(CLARIFYING EXACTLY WHAT THEY SAID THEY WERE GOING TO DO)

9) August 5, 9:37am: Received another email from Andrew W at SmarterTools stating that "a new version of SmarterTrack is now available via our website. (v 4.0.3504) This version includes a fix to the security issues you reported."
(DID EXACTLY WHAT THEY SAID THEY WERE GOING TO DO)

10) The resulting SmarterTools SmarterTrack vulnerability advisory was released yesterday on my Research pages: HIO-2009-0728

I must reiterate.
This is quite simply the new bar for response to vulnerability disclosures.
It is further amazing that such a process was followed by not one, but two vendors.
I am not a customer of either of these vendors but can clearly state this: if I required services offered by AppRiver and SmarterTools, I would sign up without hesitation.

AppRiver and SmarterTools, yours is the standard to be met by others. Should other vendors utilize even a modicum of your response and engagement process, the Internet at large would be a safer place.
Well done to you both.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

toolsmith: AIRT-Application for Incident Response Teams

2009-08-05T23:41:00.000-07:00

My monthly toolsmith column in the August 2009 edition of the ISSA Journal features AIRT.
"AIRT is a web-based application that has been designed and developed to support the day to day operations of a computer security incident response team. The application supports highly automated processing of incident reports and facilitates coordination of multiple incidents by a security operations center."
Kees Leune had pointed me to his excellent offering after I'd sent him MIR-ROR for his consideration.
Incident response teams will find this app very useful for case management.
The article PDF is here.
Thanks to Kees for all his time and feedback while I was writing this month's article.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

DEFCON 17 Presentation and Videos Now Available

2009-08-02T22:06:00.000-07:00

Mike and I presented CSRF: Yeah, It Still Works to a receptive DEFCON crowd, where we took specific platforms and vendors to task for failing to secure their offerings against cross-site request forgery (CSRF) attacks.

Dan Goodin from The Register did a nice write-up on the talk wherein he cleverly referred to some of the above mentioned as the Unholy Trinity. ;-) See if you can spot in the presentation slides why that reference is pretty funny.

For those of you who are interested in the talk but weren't able to attend, the presentation slides are here, and links to the associated videos are embedded in the appropriate slides. The videos are big AVI files so you'll be a lot happier downloading them.

I'll be following up on some very interesting questions that arose during Q&A after this talk, so stay tuned over the next few weeks for posts regarding sound token implementation, CSRF mitigation and Ruby, and the implications of CSRF attacks on forensic investigations.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

DEFCON preview: Netgear RP614 CSRF attack video

2009-07-30T14:29:00.000-07:00

To give you a sense of what Mike Bailey and I will be covering at defcon 17 this Saturday at 11am, I thought I'd give you a little taste courtesy of a Netgear RP614v4 router that suffers from cross-site request forgery (CSRF) vulnerabilities, as well as persistent cross-site scripting (XSS) issues.
See OSVDB advisory 54885 for further specifics. BTW, please support OSVDB!

The short version:
The Netgear RP614v4 web-based administration interface allows users to perform certain actions via HTTP requests without performing any validity checks to verify the requests. This can be exploited to perform administrative actions or conduct script insertion attacks e.g. when a logged-in administrator visits a malicious web site.
The sad truth of the matter is this, while I don't have access to the whole Netgear product line, the reuse the same firmware codebase across multiple devices.
Thus, in all likelihood, there are numerous Netgear devices vulnerable to this issue, if not all.
The same holds true with Linksys devices, which we'll cover in detail at DEFCON.

As you will see, the approach is simple, and too often effective.
1) Miscreant crafts email utilizing well proven social engineering methodology.
2) Victim follows orders and, while authenticated to vulnerable device, clicks on that damned link.
3) Vulnerable device does not perform any validity checks to verify the requests made via the attacker's web page lurking behind the link in the email.
4) Vulnerable device fails in whatever fashion it's told to.

As exhibited in the video I've created for your viewing pleasure, I force the admin session to enable remote management (disabled by default) and change the remote management access port to 6667 for old time's sake. If, as it so often is, the admin account is left to default password, game over. Or, in many cases, you can also force a password change via CSRF as well.
Any function the firmware provides can be forced via a victim admin's session; that which is exhibited here is but a single examplar.
Tokens, people...tokens!

The video, as promised:
Lo-fi (5.63 MB MP4)
Med-fi (53.9 MB WMV)
Hi-fi (73.4 MB AVI)

Hope to see you at DEFCON; please say hi if you're there on Saturday.
I'll be easily spotted in jeans and my white Certified Application Security Specialist (ASS) golf shirt.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

steekR security steenkS

2009-07-21T16:15:00.000-07:00

My RSS reader continues to provide me subject matter for analysis, and the recent F-Secure purchase of steekR, “Your Secured Online Space”, was no exception.
The purchase was described by El Reg as follows:

F-Secure grabs online storage firm in cloud security push
Steek's technology is designed to allow users to upload data from either PCs or mobile phones. Bordeaux-based Steek already partners with mobile telcos (including Virgin Media, SFR in France and SingTel), a factor which F-Secure hopes will increase its ability to sell Software as a Service (SaaS) technology packages through operators.

Oh boy, here we go again.
I want to create a new line of Bobbleheads for Cloud and SaaS. They’ll talk as well, bobbling and blathering the latest buzz words:
“We’ll give you the best ROI in the cloud!”
“Our SaaS offering relieves you of any responsibility, we’ll do it all!”
I digress.
I understand the business model, and F-Secure’s motives for the purchase; it’s hard to find fault there.
But as I’ve indicated time and time again, when you purchase or integrate another vendor’s offerings, you immediately inherit their shortcomings as well.

I propose a blamestorming session. I’d like to start with steekR.
steekR suffers from persistent cross-site scripting (XSS) flaws.
They further suffer from a complete inability to respond to responsible disclosures (multiple attempts over two weeks).
Thus, I struggle with their “Your Secured Online Space” claim. As in…not so much.
Imagine this scenario:
1) An attacker creates a steekR account.
2) The attacker embeds malicious JavaScript.
3) The attacker then shares steekR content in a manner that exposes it to any victim who errantly clicks through.
4) You receive email notification of the share and given your use of steekR (you and 2,405,935 other customers), you click the URL.
5) Your browser is directed to a steekR share with a malware-laden IFRAME embedded.
6) You’re pwned.

I'll walk you through it.

Here's the email...

Here's the URL in the email (no, I'm not trying to pwn you):
http://www.steekr.com/n/50-2/share/LNK32784a66232b7baaf/
Click My Documents in the left pane and you'll see the IFRAME in the right pane when you mouse over the folder.

Here's the result when you click said URL...

That IFRAME could easily be something nasty.
Similar scenarios can easily lead to data breach, account compromise; pick your poison.
Lest you forget, persistent XSS issues are far uglier than their reflected kin.

Lesson for companies like F-Secure on the venture integration path:
Review the acquisitions security-related practices, or lack thereof, and conduct a thorough assessment of the product driving the decision to purchase them.

Lesson for users of SaaS offerings:
Assume no privacy, and no guarantee of security. A trusted resource may not be trustworthy.

Steek and you might stumble. ;-)

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Pick a toolsmith topic

2009-07-19T22:49:00.000-07:00

I've decided to implement a new feature from time to time with regard to toolsmith, my monthly column in the ISSA Journal.
You, dear reader, are invited to propose topics. If I choose your topic, you will be mentioned in the column, and win an information security book of my choosing.
A few important guidelines.
1) It must be an information security tool I haven't already discussed. See the full list of those I have discussed here.
2) The tool must be information security related.
3) The tool must be free, and preferably open source.
4) Ideally, I prefer to try and focus on tools that aren't well known, with less exposure, in order to help them receive the attention they deserve.
Submit ideas at my contact page.
I look forward to hearing what might be of interest for you.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Pete Hoekstra = ID Ten T

2009-07-14T08:39:00.000-07:00

From a state that could definitely use congressional members with a bit more intellectual savvy comes Michigan's Pete Hoekstra.
Graham Cluley's blog states:
Hoekstra told The Washington Times' America's Morning News radio show that "it's time for America, South Korea, Japan and others to stand up to North Korea" by launching a retaliatory cyber attack or international sanctions.
Graham took Hoekstra to task for this moronic idea yesterday, before today's headlines quickly began to reveal the possibility that the attacks against S. Korea and the US may have actually originated in the UK. The simple reality is, maybe it did, maybe it didn't. The premise that one nation state should launch a cyber attack against another based on the presumise that they might be responsible for a DDoS attack is short-sighted to say the least.
Should we now cyber-bomb our British friends, Mr. Hoekstra? I believe, amongst other things, we and the Brits can agree that you are assuredly a daft git.
Dear readers, this is a man who recently Tweeted "Iranian Twitter activity similar to what we did in House last year when Republicans were shut down in the House."
Wow. Really?
For a good chuckle read Pete Hoekstra is a Meme.
I'm reminded of Ted Stevens' famous take on the Internet as a "series of tubes".

Pete's also running for Governor of Michigan.
Enjoy...

Thus, Pete Hoekstra is hereby awarded my second ID Ten C Award for foolishness above and beyond the call of duty.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

MIR-ROR updated, v1.1 now available

2009-07-09T19:57:00.000-07:00

MIR-ROR 1.1 is available on the CodePlex MIR-ROR site. This is a minor update to the MIR-ROR script including a repaired path declaration. We also removed a pause statement to promote improve WMI scripting with MIR-ROR.
MIR-ROR is a specialized, command-line script for incident response that makes use of the Windows Sysinternals tools, as well as some other useful tools. Further, you can easily enhance the script to your liking with whatever command line tool you require for response.

Thanks to Bryan Casper, Mike Maonde, Alex Alborzfard, Gene Morganti, Andreas Bunten, Harlan Carvey, and Rick Wanner for feedback after the initial release.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

ColdFusion, SaaS, and negligence

2009-07-07T11:41:00.000-07:00

Recent headlines have described news pertinent to ColdFusion-related vulnerabilities and hacks specifically targeting the FCKEditor text editing tool, and the CKFinder file management tool. There have been further indications of attackers uploading a ColdFusion web shell as often seen on vulnerable PHP platforms.

These discussions reminded me of two significant pet peeves.
1) ColdFusion error verbosity and how useful it is to attackers.
2) Negligent vendors who do absolutely nothing about security vulnerabilities they've been advised of; worse still, when the vendor is a SaaS provider.

Case in point: WebPublish CMS

I communicated with these folks at multiple intervals via email and telephone from February 20, 2009 until April 23, 2009. It took multiple efforts just to get through as my messages were manually interpreted as "potential SPAM". Trust me, my security advisory language does not trip SPAM filters and is most often easily and well received. Yet, after finally making a connection, I received the classic "we don't have the time and resources to address this issue any time soon." To which I replied with useful resources for mitigation and remediation. My last received communication stated "I will have a look and see if I can incorporate as much as I can." That was two and half months ago.
I think we can agree the tenets of responsible disclosure were followed, yes?
Thus, a seemingly capable, growing SaaS provider quite simply blew me off.

So be it. Here's my favorite example of something they should immediately fix: A cross-site scripting (XSS) vulnerability exhibited in the ColdFusion error page leading to significant information disclosure (ID) while indicating possible SQL injection (SQLi) vulnerabilities. Wow, really?

A screen shot complete with a wee bit 'o appsec humor courtesy of an IFRAME insertion:

Now take this absurdity to the next level.
As many a vendor is prone to doing, WebPublish CMS sites clearly state that "This site is powered by WebPublish".
How helpful.
Try intext:"powered by WebPublish" via Google.
Just a few results, yes?
We'll use a few for further analysis. What do they all have in common?
kellyprecision.ie
multiples.ie
netcommunications.ie
snapprinting.ie
webpublishcms.com
Yep, all the same IP, as in all on the same server.

Core application vulnerabilities in a primary service offering (SaaS) from one vendor, on one server, affecting hundreds if not thousands of clients.
See the problem?
Negligence, plain and simple.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Malzilla: Exploring scareware and drive-by malware

2009-07-01T11:59:00.000-07:00

Yesterday included a SANS ISC diary post regarding a tool list useful for de-obfuscation. Amongst the entries was Malzilla.
Fortuitous timing I say!
My toolsmith column for July's ISSA Journal is a complete analysis of Malzilla's capabilities.

Malzilla is best described as a useful program for use in exploring malicious pages, allowing you to choose your own User Agent and referrer and use proxies. While it downloads Web content, it does not render it, so it is not a browser. Think of it as WGET with a user interface and some very specific talents. In Using Malzilla, we’ll take a close look at rogue AV tactics and exploit sites in order to study the infection process utilized.

Lenny Zeltser contributed great feedback regarding Malzilla for this piece, thus furthering the tool's credibility.
Give the article a read and add Malzilla to your arsenal.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

ASS Cert Online Store is Hacker Safe

2009-06-23T18:37:00.000-07:00

Those of you aspiring to proudly display your recently acquired Application Security Specialist certifications can rest comfortable knowing that the CafePress ASS Cert Online Store is protected by McAfee Secure/Hacker Safe. This is wonderful news as it guarantees that your transaction is safe while you purchase your favorite ASS Cert products. The store is offering ASS Hats, Office Attire, ASS Gear, framed certificate tiles, and framed oath reminders for those of you who may forget:

I will maintain my status as a Certified Application Support Specialist as proof of my knowledge and experience.

While you're logged in, you can even make use of an added feature: an open redirect that allows you direct internet traffic to any destination of your choosing!
Check it out here.
Enjoy, and I expect to see all you Application Security Specialists to be wearing your ASS Hats when I see you at defcon.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

IT Infrastructure Threat Modeling Guide now available

2009-06-15T14:54:00.001-07:00

In April I discussed the IT Infrastructure Threat Modeling Guide (then in beta), a Solutions Accelerator I've written with the Solution Accelerators for Security and Compliance team.
The IT Infrastructure Threat Modeling Guide is now available for download via the Technet Library and the Download Center.

Networkworld's kind coverage of the guide's release provides additional insight.

Purpose of this Guide:
Provide an easy-to-understand method that enables IT professionals to develop threat models for their environments and prioritize their investments in IT infrastructure security.
IT infrastructure threat modeling should be incorporated into an organization's IT mindset as a matter of policy, much like any other part of the validation, implementation, and installation process. Threat modeling in the name of secure infrastructure should be performed throughout the technology implementation process, much like any other component that is measured for performance, usability, and availability.

This guide maps directly to SDL guidance and marries threat modeling infrastructure to a sound, existing framework.
This has been quite an effort and a valuable learning experience for me.
I'd like to thank the following for their contributions, leadership, and effort during this process:
Kelly Hengesteg, Steve Wacker, Karina Larson, Adam Shostack, Frank Simorjay, Jeff Sigman, Chase Carpenter, Sumit Parikh, and Shruti Kala.
To the numerous people who reviewed and provided feedback, thank you as well.

When you use a structured method as described in this guidance to develop threat models for your IT infrastructure, you identify and mitigate threats to your environment in an efficient and effective manner.
It is the intent and hope of this guidance that the benefits of choosing to develop a threat model portfolio for your IT infrastructure will be many, and that a holistic state of security becomes commonplace for those who undertake the process.

I look forward to your feedback as you read the IT Infrastructure Threat Modeling Guide and hope to learn of your success stories as you utilize it to enhance security in your associated environments.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Presenting at Defcon 17 with Mike Bailey

2009-06-09T22:23:00.000-07:00

In case you didn't know, CSRF still works. ;-)
Mike Bailey and I will be discussing this sad fact via CSRF: Yeah, It Still Works at DEFCON 17 at the end of July. We do hope to see you there!
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

eWeek hypes "secure" SaaS without checking the facts

2009-06-06T11:06:00.000-07:00

In an article called SaaS Proof Points, eWeek put on the blinders and jumped on the bandwagon declaring such SaaS wisdom as "not only have modern SAAS applications assuaged security concerns, but the SAAS model itself is seen by some as the most secure approach to handling data".
What!? Wow.
Add to that the well-intended declaration of SaaS neophyte Kimberly Rogers of Santander Consumer USA, while detailing her company's use of Service-now.com. Rogers, who had never worked with a SaaS-based application before, added that "security can be as tight as you want it to be." Noting such blind faith from a Service-now.com user I was motivated to take a closer look at the provider.
Kimberly, respectfully, you are making a dangerous assumption.
Putting on my bad guy hat for a second, if I can entice you to click a link in a targeted, specially crafted email (phishing), that in turn executes JavaScript in the context of Service-now.com (cross-site scripting) and returns the cookie you use for authentication to Service-now.com (credential theft), is it still reasonable to assume that "security can be as tight as you want it to be"?
I think not.
Service-now.com suffered from a cross-site scripting (XSS) vulnerability that allowed cookie theft and other XSS fun such as frame defacement.

Before XSS:

After XSS:

Please note that Service-now.com responded to my advisory and made repairs in a reasonable amount of time, all the while communicating admirably.
That said, if SaaS providers don't ratchet down hard on their basic web application security, silly yet valuable data spills such as described above will continue to prevail unabated.
If trade publications continue to publish hype rather than balanced facts I must assume that data breaches and provider shortcomings will continue to be commonplace as said providers won't be held to a higher standard.

When StrongWebmail fell so readily to an XSS vulnerability this past week (well done Lance, Mike, and Aviv), I simply shook my head in dismay. Are service providers so blind as to not consider the holistic security view before putting 10k on the line?
That was a rhetorical question.
Answer? Obviously.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)