toolsmith article on Adito SSL VPN now available

My toolsmith column in the March 2009 issue of the ISSA Journal is a comprehensive discussion on Adito, an open source, browser-based SSL VPN that, in essence, replaces SSL-Explorer.
It's a fantastic offering that is now enjoying enhanced development support and offers many of the feature you'd expect from a commercial SSL VPN solution.
Check it out at your earliest convenience.
Cheers.

del.icio.us | digg | Submit to Slashdot

New version of Audit Viewer enhances latest Memoryze

More good news for malware analysts and security practitioners alike.
Straight from Peter Silberman, further details on the new version of Audit Viewer, inclusive of lots of significant changes.
The new Audit Viewer, should be used in conjunction with the newly released Memoryze-1.3 (which offers Vista support (beta), dll injection detection, enumeration of PE imports/exports in memory, F-Response support, and a slew of bug fixes.

Pictured below is a screen shot of the newest feature, Memoryze Launcher. You can now control Memoryze from a GUI. You have all the options you normally would, but you don’t have to edit any XML! The launcher supports multiple jobs. After your jobs run, any XML will be auto-loaded into Audit Viewer for seamless integration. If you specify a MemoryDD, then the image file be auto set to the text box so you can go from acquisition to analysis.



But wait, there’s more! A process with an injected dll will now appear in red text:



You can view the imports/exports of the injected dll in the Memory Sections view (the red entries indicate that memory sections that contains a PE file):



Right click on the section:


Two new handle types are supported, specifically “Sections”, and “Semaphores.”

There is now also integrated Snort signature support in Audit Viewer.
If you convert MindSniffer-generated Snort signatures to python files you can match signatures to strings in any process audit. Peter spoke about this technique at Blackhat Federal.

If you haven't yet downloaded Memoryze, Audit Viewer, and MindSniffer, all I can say is "What are you waiting for?!"

Thanks for the update, Peter.

del.icio.us | digg | Submit to Slashdot

#8 of the Top Vulnerability Discoverers of 2008

When, towards the end of 2008, I noticed the total count of vulnerabilities I'd disclosed and posted climbing past 50, I didn't imagine the effort would merit ending up as 8th on the list of Top Vulnerability Discoverers of 2008, as determined by Gunter Ollmann of the IBM ISS Frequency X Blog.
I am both pleased and disconcerted to find myself on this list and wish to convey a few thoughts on the subject.
1) While I appreciate being on this list I must say that the caveat offered as part of Gunter's post is valid: "cross-site scripting vulnerabilities in a commercial shrink-wrapped application count for the same as a remote root vulnerability on a default Windows service."
My work has focused entirely on vulnerable web apps to date, and truly qualifies as low hanging fruit when compared to the findings of the likes of Luigi Auriemma. I am reminded of Wayne and Garth...I'm not worthy. My hat is off to Luigi, as it has been for quite awhile.
2) Gunter has, in the past, stated that he "wants companies to stop acknowledging an alias or pseudonym for any researcher that discloses a vulnerability - even if they came to you directly. “Use real names only,” he adds." Amen. The use of stupid, h@x0r nicknames lacks credibility and flies in the face of what I believe our core mission should be: find, advise, and promote repair of vulnerable software on behalf of users and consumers who may fall victim to its exploit. Disguising this mission in some self-perceived leetness-by-nomenclature denigrates the essence of this work. Courage, my friends...be true to yourselves and the cause.
3) Gunter has further indicated that he wants "software vendors to stop acknowledging companies and researchers who buy and sell security vulnerabilities." I must agree entirely here as well. I'd no sooner sell a vulnerability for profit than I would exploit it for personal gain.
4) Finally, the fact that, with relative easy, I discovered and reported what the Frequency X report indicates is 53 unique web application vulnerabilities in 2008 is really testament to what a sad state of affairs the development process is for so many of these vendors (not all, but many).
My plan for 2009, in addition to continuing this effort in earnest, is the promotion of the use of the Security Development Lifecycle (SDL). I believe that weaving the SDL mindset into software development is essential to preventing the flaws we vulnerability researches enjoy pointing out.
More to come, to be certain.
Cheers, and thank you, Gunter.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: Chase away flawed broker browser code

In my ongoing pursuit of flawed online finance offerings, I took advantage of a quick Google search to isolate some opportunities.
site:chase.com -www
The second result caught my eye immediately as it:
1) should likely be disallowed via robots.txt.
2) utilized SSL, indicating a certain "value".
3) indicates broker web access and thus must be "important".
At first glance the SunGard Broker Browser looks very 1997, and a quick review of source code yields references to Front Page 3.0 and Visual Studio 6.0.



A closer look quickly produced an immediate cross-site scripting flaw right at the user_ID parameter.
Making use of the indispensable Tamper Data add-on, I invoked the key question. How much risk to consumer and brand confidence do poorly coded or ancient apps represent?



The results answered the question aptly. Enhanced phishing opportunities, PCI violations, potential SOX considerations, possible data breach implications...the list is long.



JPMorgan Chase was immediately responsive, quick to repair the issue, and offered this:
"We welcome reports of potential security vulnerability because they help us in the crucial role of protecting our customer information. We quickly follow up on any reports, assess the situation and determine what action needs to be taken."

An excellent response to be sure, and I applaud it.
That said, I'd like to pose a few more questions, and if answered, I will post them here as an update or approve the comment if submitted that way.
1) Is this really how brokers gain access to JPMorgan Chase resources?
2) If so, will you be updating the application to bring in into this century?
3) May I humbly suggest a wee bit o' security through obscurity? Something as follows should suffice:
# Bugger off
User-agent: *
Disallow: /
4) There are indications of this being a test system. If so, does it really need to be exposed to the Internet?

As news of endless data breaches, economic collapse, failing consumer confidence, and inherent Wall Street greed prevail, an online finance flaw like this leaves me at a bit of a loss.
If access for brokers is broken and could lead to data compromise, what are the implications?
Many, I think, particularly under the premise of the above mentioned news.
I've read a recent well written argument that we haven't fully grasped the potential impact. From Laura Wilson's
Facing the Information Security Hole in 2009:
The unacknowledged threat to our homeland and financial security, consider the following.
"It is now widely acknowledged by security experts from the federal government on down that the problem of data security breaches will get worse as the financial debacle worsens and companies cut spending and workers."

My point is this. I discover online finance flaws, I report them, they get fixed. That's great, but what about those that remain undiscovered and are far more critical than the less concerning than the cross-site scripting examples I use to make my point (and stay out of jail ;-))?

We are faced with uncertain times. Better security for web applications and systems serving as financial industry resources can help mitigate some of that uncertainty.

del.icio.us | digg | Submit to Slashdot

Mandiant Memoryze is the 2008 Toolsmith Tool of the Year

Updated: 2/6/09 See update below.

I'm a tool geek, no doubt. You can't write a column like toolsmith and not be one.
I've been mighty excited about a number I've things I've written about in the last year, including PHP IDS, NetworkMiner, and the tools from the Integrity Project.
As much as I enjoy (even love) every tool I write about, they become like family ;-), I have reached a decision.
Mandiant Memoryze is the 2008 Toolsmith Tool of the Year.
The February 2009 toolsmith article on Mandiant Memoryze is here.
Incident handlers and malware analysts rejoice: Memoryze is simply indispensable.
Food, water, air, love, Memoryze...really.
I use it at least three times a week in my virtual analysis sandboxes and I know I haven't realized its full potential.
Here's an example without full specifics as it stems from a work related investigation.
Imagine a scenario where you've been given malicious software to analyze. Said software was purchased from a nefarious and anonymous source based on its ability to wreak havoc, and your mission is to see if there's any way to find out who the actual author is.
Solution: run the malicious software in your VM sandbox, fire up Memoryze as follows:
memoryze.exe -o -script AllAudits.Batch.xml -encoding none
Be sure strings is enabled in AllAudits.Batch.xml like this:
param name="strings"
value xsi:type="xsd:boolean" true
It'll write a mass of junk to your output directory, but there's gold to be found in there.
I scrubbed through the strings output from the malicious process under the assumption that maybe the wanker who developed it left something useful behind (they often do).
Sure enough, Visual Studio attributes and reference to his home (including his user name) directory on his Vista installation showed up in the memory extract.
I combined those findings with some trace identification elements from automated email received during the purchase to pull together the developers full name.

Put simply, as malware anaysis tools go, and incident handling tools for that matter, this is a must for your tool kit.

Keep an eye on the Mandiant blog and Peter Silberman's work and presentations, He wrote the above mentioned AllAudits.Batch.xml and discussed it on OpenRCE.

Update 2/6/09
Principal developer Jamie Butler will be teaching how to write your own memory analysis tool or at least know the right questions to ask before you buy one at Black Hat DC February 16-17 and will also be speaking with Peter at RSA in April about memory analysis and malware reversing.
Expect a new version of Audit Viewer to release in concert with their presentations at Black Hat DC.

Get to know Mandiant Memoryze, you will not be disappointed.

del.icio.us | digg | Submit to Slashdot

Moving holisticinfosec.org to a new hosting provider

Update 2/4/09: Holisticinfosec.org is up again, stable and comfortable in its new home.

A quick update regarding holisticinfosec.org.
I'm switching hosts from a nightmare situation to one I am hoping will bring the stability and security we all should be able to expect from a provider.
Stay tuned and thank you for your patience.
This blog will be unaffected by the process.
Russ