Online finance flaw: Ameriprise FAIL...again

Here we go again.
The cross-site scripting (XSS) issues on the Ameriprise advisor locator site were fixed, even if temporarily, back when Dan Goodin reported on the issue in August.
A little bird whispered in my ear the other day and told me a sad tale:
they're baaaaack.
Regression testing anyone?
Regression testing (from the Wikipedia entry recommends that:
"in most software development situations it is considered good practice that when a bug is located and fixed, a test that exposes the bug is recorded and regularly retested after subsequent changes to the program.
What a grand idea! Ensure that you don't reintroduce old flaws when you roll old code.
Really? I have to say it?
Apparently.



Dan & El Reg have covered the issue again given that, in order to have it fixed again, I had to ask him to ping the Ameriprise PR department.

*sigh*

BTW...the issue is fixed, for now. ;-)

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

DEF CON 17 CSRF Videos Remastered

Thanks to Adam Gerstein for reminding me to get off my butt and produce the Def Con 17 CSRF videos in a more streamable format.
Adobe Flash Player required; no, I won't pwn you.
If you'd like to see the whole presentation video, goofy as it may be, it's here.
Be forewarned, it's freaking huge and takes a fat pipe to pull it down in any reasonable amount of time.
The presentation slides are here.

The Dokeos CSRF PoC video is here.

The Linksys CSRF PoC video is here.

The osCommerce CSRF PoC video is here.
Note: Please don't use osCommerce, they still haven't fixed this and probably never will.

BONUS VIDEO (discussed but not shown at Def Con)
The Netgear CRSF PoC video is here (QuickTime and sorta crappy, sorry).

Enjoy.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

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

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

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

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

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

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

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

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

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

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

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

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

Figure 1


Figure 2


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

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

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

XSSing Bob: At least GoDaddy got this one right

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

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

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

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



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

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

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Single Packet Authorization: The Ghost in the Machine

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

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

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

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

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

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

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Book Review: ModSecurity 2.5

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

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

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

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

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

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

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)