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

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

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

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

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

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

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

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

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

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

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

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

Figure 1


Figure 2


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

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

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

XSSing Bob: At least GoDaddy got this one right

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

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

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

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



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

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

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Single Packet Authorization: The Ghost in the Machine

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

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

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

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

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

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

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Book Review: ModSecurity 2.5

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

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

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

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

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

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

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

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)