Russ = Rogueware: Is nothing sacred?

You know you've hit the big time when...;-)
Alright, maybe not, but you still may have to step aside for my ego.
Wait, you already have to do that.
Fine. Never mind.
But this is kinda funny.

Full disclosure:
I use Google Alerts for my name (Russ McRee) and my domain (holisticinfosec).
I'll be quite honest and tell you that it's a combination of ego and paranoia.
I want to know when people say nice things (rare), when they talk smack (more likely), or when they're illegally reusing content (a constant).

Ok, so now you know I auto-Google myself (you should too), but here's where it gets new and exciting.



See the first entry above, i.e. "Russ"?
No good news there.
Looks like keyword abuse or a compromised site pointing to rogueware/scareware:
hxxp://www.tuckmall.com.tw/blog.php?blog=russ+mcree



Use caution as always if you choose to go there, fellow bug analysts.
MMPC calls the binary Trojan:Win32/Winwebsec.
The VirusTotal results include 10 detections out of 41 possible.

The rogueware site code is classic.



Multiple IFRAME offering dependent on user agent detection for the primary browser types.
If you're on a Mac you'll be redirected to some crap movie site; otherwise, you must be infected! Click here! Off to virusexamine.com or webexpertcheck.com with you...

Nice to know my name has become worthwhile enough to poison search results for...in Taiwan...on the 11,292,838 ranked site in the world...mixed in with pr0n and Justin Timberlake.
Oh yeah, the big time indeed.

Cheers, and Happy Holidays.
Russ

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Maltego is the 2009 Toolsmith Tool of the Year

Maltego: transform and correlate

December 2009's edition of the ISSA Journal's toolsmith discusses Maltego at length with specific attention to transforming RFI and scareware attributes.
Maltego is an open source intelligence and forensics application.
While researching and writing for December's article I fell completely for this tool.
It was a difficult decision having covered some brilliant and remarkable tools in 2009, but only one can come out on top.

The 2009 Toolsmith Tool of the Year is Maltego.
Congratulations to Andrew MacPherson and his team.

As an example, I used Maltego to analyze remote file include (RFI) attacks against my website and found it to be an extraordinary addition to my toolkit.
RFI attack URL strings often end with a common script name with a .txt or .gif extension.
I grabbed five such file names as most often seen in my logs from October:
zfxid1.txt
id1.txt
fx29id1.txt
idxx.txt
crespon1.txt
fxid1.txt
I fed these to Maltego and one of the URLS revealed showed results for a U.S. IP address, further showing that it had been flagged seven times for RFI attacks. This IP address has been identified as hijacked host/automated scanning drone due to the fact, that the host at this IP address has tried to injected a malicious script (RFI attack): http://www.ciasoftwares.com/fxid1.txt [show script].
Clicking the show script link then revealed that the script has a hash of a05dfd7cca7771a7565a154d65f05ea2 with all the attack details including script locations (RFI URLs), related IPs, and RFI script details. The figure below just begins to highlight how powerful Maltego really is.



The ISSA Journal December 2009 toolsmith article is here.
Again, congratulations to Maltego and Andrew MacPherson.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

REI: vulnerability remediation done wrong

Part 2 of 2 of Vulnerability remediation done *

It makes me sad to use REI as another example of the wrong way to manage vulnerability disclosure; I am a member who is fond of their stores and products. I will not name names or blather on about negligence.
Rather, I will let the facts simply speak for themselves.

1) On April 11th, 2008 (more than a year and a half ago), I reported a cross-site scripting vulnerability specific to the REI website search functionality. Via email I received a reply indicating that "I’ll have our team evaluate this." I had every reason to believe it would be resolved.

2) The issue completely fell off my radar thereafter until one evening I was checking old findings and noticed that the vulnerability remained on October 1, 2009.

3) Surprised, if not shocked, I tried an alternative approach. I called REI HQ and asked to speak with an appropriate party to report the issue again. I was transferred to a person who provided me with an email alias to which I could forward the issue. On October 6th, 2009, only when I requested a reply as confirmation, I received "I forwarded your information on to our Security team."

4) The issue again fell my radar until November 29th, 2009 when, once again, I noticed that the vulnerability remained (nearly two months since October 1). I was quite ticked off at this point and fired off a feisty email stating that if the issue was not resolved, or a timeline for resolution provided, within seven days that I'd publish the finding regardless.

5) Today, I checked again and found the vulnerability remediated. Had I received one reply to any email sent after October 5th? No, not one indication that a solution had been implemented.

Following are screen shot and video.
Think about what this issue might have meant to consumers while noting that yesterday was CyberMonday.



VIDEO

So, to be clear, the issue is fixed, but the response, and the amount of time taken to resolve the issue is beyond disappointing.
I'll leave it at that.
Comments, as always, are welcome.
Should someone from REI wish to offer insight or explanation I will gladly accept the comment or add it to the post.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Pligg pluggs holes: vulnerability remediation done right

Part 1 of 2 of Vulnerability remediation done *

Often, when I disclose web application vulnerabilities to Secunia, who in turn works with vendors to drive mitigation and remediation, we are met with vendors who don't reply, don't care, or don't fix.
Yet, once in a rare while a vendor chooses the righteous path.
Such is the case with Pligg.
Pligg posted a detailed, transparent, candid writeup regarding the disclosure and their response prior to the scheduled release date (12/2/09) for the advisory. In addition their new release (1.0.3) addressing the issues in now available.
As I am too often prone to complaining, I relish the opportunity to say "well done."
To Pligg, a hearty thank you; you are now amongst the standard bearing few who swiftly address vulnerabilities, do so with candor and transparency, and care about your user base.
When the advisories go live as scheduled tomorrow they will be found here and here.
Again to Pligg: well done.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Fun with fake Flash: an Abode update you don't want

Jericho of Attrition.org (support the Open Security Foundation!) recently asked the VIM mailing list a question: Adobe Flash - vuln or just "design"?
The question, inspired by Mike Bailey's work for Foreground Security, leads to healthy debate, including press and vendor response. But, ironically the same day I received the VIM mail, I was led to explore a slightly different perspective on Adobe Flash issues. Thus, your author doesn't intend to get in the middle of above proposed curmudgeonly discussion.

I am however inspired to be curmudgeonly; grumpy even.

The crux of this conversation is the fact that the oft updated Adobe Flash Player continuously proves to be social engineering attack vector fodder. This is by no means news, or likely a surprise to the 19 of you who read this blog, but I recently stumbled on a real gem in the wild and I thought I'd share.
Whilst defending the Intarwebs from evildoers, I spotted
hxxp://www.abodeplugin.com/flashpayer/thankyou/flashplayer.htm
Explore this site at your peril, the binary sure isn't Adobe's; nor is it any update you want to install.

First, the use of letter juxtaposition (Adobe to Abode) is a pretty smooth endeavor likely to be missed by happily unaware clickers.

Second, the faux page layout is built largely right from the source Abod...er, Adobe site.



This irony is not lost on me: this "update" page is so pure it includes JSON formatted addon offers from Adobe, including a free McAfee Security Scan. Woot! You're going to likely need one if you install plugin.exe.

Speaking of, plugin.exe is a Trojan-Downloader.Win32.Genome sample that would normally go grab additional ill-intended binaries. Runtime analysis showed some common behaviors, though this sample seemed rather neutered.
1) Spawned a process and created C:\WINDOWS\system32\services.exe
2) Made a call to 212.180.97.163 (hxxp://www.sofec.21s.fr/k70.htm), now resulting in a 404.
3) Strings output was amusing (highlights parsed):
Buffer overrun detected!
unable to initialize heap
unexpected heap error
HeapDestroy
HeapCreate
HeapReAlloc
HeapSize
show me the money!
Nice. Really?

Who knows what additional evilware once lurked at 212.180.97.163, but it wasn't likely removed by anyone thinking clearly. The site hosted there is in miserable shape, suffering from numerous issues including SQL injection, horribly managed Frontpage extensions, cross-site scripting, and more. Which is to say, "give any one species too much rope and they'll f**k it up" (Roger Waters from Amused to Death).





So what's the lesson?
Negligence begets opportunity.
Opportunity begets maliciousness.
Maliciousness begets victimization.
Simple, yet entirely preventable.

The above mentioned combination of bad web application security and common malware practices likely means that someone may not have a nice Thanksgiving and that makes me sad. I don't like to be sad.
So beware fake Flash updates and button up your crappy websites so jerkwater ne'er-do-well's have less opportunity, damn it!

I am thankful for my dear family and all 19 of you readers.
Pass the Tofurkey!

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Whitepaper Review - Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC

As part of a security team that cares deeply about the well being of Windows Live, I was extremely pleased to review a paper written by web application security specialists for whom I have deep respect.
Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC was written by a powerhouse team whose talent speaks for itself, including Casaba's Chris Weber; his Watcher was discussed in November's toolsmith.

First, I am an unabashed SDL fanboy. Any work that accentuates SDL principles is off to a great start in my book: security by default being paramount.
Second, of this paper's three subtopics (CSRF, open redirects, JSON hijacking), two (CSRF, open redirects) consistently count as pet peeves for me.
As for JSON hijacking, the best explanation available is also offered by one of the paper's authors, Phil Haack: JSON Hijacking.

"ASP.NET MVC provides a new Model-View-Controller framework on top of the existing ASP.NET 3.5 runtime. This framework enables developers to easily take advantage of the MVC architectural pattern to build Web applications."

When Windows Live moved to ASP.Net MVC it presented the opportunity to build mitigations into the framework that prevent developers from making accidental errors that could result in security flaws. Specifically, they targeted the three above mentioned web application security flaws – CSRF, open redirects, and JSON hijacking.

Highlights (thanks to Deepak Manohar):
CSRF is mitigated via ASP.Net MVC in that, by default, all HTTP requests are checked for a canary except for HTTP GET requests, or requests that developers specifically request not to be checked (keep an eye on those developers :-)).
"To defend a Web site against XSRF attacks, ASP.NET MVC provides AntiForgeryToken helpers. These consist of a ValidateAntiForgeryToken attribute, which the developer can attach to controller classes or methods, and the Html.AntiForgeryToken() method. The Windows Live team implemented a modified version of this approach."

To protect against open redirects, the Windows Live "could have added a new SafeRedirectResult class that checked the list of allowed Web sites and required all developers to use new class. However, a given developer might not know about this rule and might use the RedirectResult object manually. If this code was not caught by performing a code review and testing, it could result in a security bug. Thus, the team did not create a new class opting instead to change the behavior of the default class."

To protect against JSON hijacking, enter the WLXSecurityAttribute: "The WLXSecurity custom filter attribute is a class that implements the IActionFilter interface. This interface defines two methods called OnActionExecuting and OnActionExecuted. The OnActionExecuting method runs just before an action executes, and the OnActionExecuted method runs when the action has completed. OnActionExecuted is checked for an action result with a content type set to JSON or JavaScript; if matched, the result is checked to ensure that canary validation has been applied. The canary validation is typically included as part of the form post when using POST actions, but it can also be part of the query string."
Any action requiring canary checking where a canary is not provided with the request results in an exception: no data interchange for you!

Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC is a recommended read, specifically for those of you managing developers or aiding them in securing their code.

Give it a read, and by all means feel free to provide feedback via comments.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Pending book review: ModSecurity 2.5

Packt Publishing, a UK based publishing firm specializing in focused IT books, has asked me to review Magnus Mischel's ModSecurity 2.5.


Having recently discussed monitoring ModSecurity with OSSEC, I'm looking forward to reading this book.
I've been a ModSecurity fan since incorporating it in a secure server implementation, back when it was version 1.9.4 in 2006, as part of a paper written for OWASP.

Expected highlights include:
* Securing your system by knowing exactly how a hacker would break into it
* Writing rules in-depth and ModSecurity rule language elements such as variables, actions, and request phases
* Covers the common attacks in use on the Web; find the geographical location of an attacker and send alert emails when attacks are discovered
* Many real-life examples for better understanding

I'll give you a detailed, honest assessment of ModSecurity 2.5 in a few weeks.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Sucuri NBIM: website integrity monitoring for free

Here's a nice freebie you might like as part of your website monitoring arsenal.
I signed up with Sucuri for their NBIM (network based integrity monitoring) service to help keep an eye on holisticinfosec.org, and have been very satisfied with this free offering (sometimes you get more than what you pay for).
As an example, when my hosting provider updates the server, I know immediately via email.

EXAMPLE:

Modifications:
5,6c5,6
< Server: Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8k DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635
< X-Powered-By: PHP/5.2.9
---
> Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635
> X-Powered-By: PHP/5.2.11

---
This alert was generated by the Sucuri Network Integrity Monitor.

There's a nice dashboard, offering you history snapshots:



You'll also find a nice web information gathering tool called WIGS which grabs public information available about websites.

Check it out and see what you think.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Watcher: Spotting dubious webishness

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)

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

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

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

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

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

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

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

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

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

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

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

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

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)