Update 2/6/09:
The March 2009 issue of toolsmith in the ISSA Journal will feature a complete review of Adito, including installation and usage. Expect the article to go live around 3/1/09.
In February 2006 I discussed SSL-Explorer, a project that is no longer supported.
It does however have new life in a project called Adito.
Much as SSL-Explorer was described, Adito is an open-source, browser-based SSL VPN solution. It's a remote access solution that provides users and businesses alike with a means of securely accessing network resources from outside the network perimeter using only a standard web browser.
Further:
Adito was forked from SSL-Explorer 1.0.0-rc17 for several reasons:
- To keep the already robust and functional open source codebase from decaying
- To reform SSL-Explorer (now Adito) from one company's product and a brand into a true community project
- To add new, exciting functionality
- To integrate existing functionality (e.g. sslexplorer-pam) into the program without the need to maintain it out of the source tree
This project shows updates as recently as December 19, 2008, and is in need of a developer so I'm hopeful maintenance and project enhancement will continue in earnest.
Give Adito a good look and let me know what you think; I may cover it in toolsmith.
del.icio.us | digg | Submit to Slashdot
Russ McRee's HolisticInfoSec™ includes articles and research, as well as feedback and an occasional rant. HolisticInfoSec™ promotes standards, simplicity, tooling and efficiency in achieving holistic information security.
Monday, December 29, 2008
Monday, December 22, 2008
Online finance flaw: Visa responds quickly to reported vulnerabilities
The American Express online flaw I discussed last week led to two interesting sidebars.
First, a rather strong media response resulted with coverage in The Register, BetaNews, and Dark Reading, amongst others.
Second, aside from all the variant hunters, I received a number of interesting finds from friend-of-the-cause Mike Bailey over at skeptikal.org.
He'd been inspired by the fact that the PoC I issued for the AmEx bug included an IFRAME insertion pointing to Visa.com. Inspiration led to discovery (and whole lot less work for me) and immediate issues were noted in a few Visa sites.
To be fair, http://usa.visa.com itself appears to be sound; both Mike and I gave it a cursory glance and nothing popped up (XSS pun).
The same could not be said for http://empresarial.visa.com.
No need to rehash all the problems XSS issues in major credit card company sites might cause (PCI compliance, phishing, customer abuse, etc.); earlier posts speak for themselves.
As always, I reported the vulns per my terms of engagement.
Here's where the rather unexpected occurred.
I first reported the issues on December 17th at 1322 hours PST.
They were fixed no later than December 18th at 1916 hours PST.
In essence, Visa executed a 24 hour turn around for mitigation and repair.
Now, I have no doubt variant hunters will likely go digging about for other vulnerabilities, and if Visa hasn't issued global repairs, they might find some.
But, what's key here is how quickly Visa responded. I must admit, after the debacle born of the AmEx issue, I wondered if I'd be asked to report the vulns through Visa's PR department, a method recommended by AmEx to report vulns to them. ;-)
Not only was my disclosure responded to in a very timely fashion, I received the following feedback:
"We appreciate you bringing this situation to our attention. Visa takes security matters very seriously. All impacted pages have been taken down while we remediate the XSS coding. As always, feel free to report any future abuses to: abuse@visa.com."
Hard to argue with that.
My impression (unsubstantiated) is that the vulnerable sites were the product of a 3rd party development team, serving Spanish speaking customers, given the fact that the vulnerable code was PHP, not typical of English language Visa properties.
For posterity's sake one of the vulns appeared as follows. There were other similar issues with different variables, different sub-domains, and partner sites, but you get the point.
XSS in empresarial.visa.com/por/glossario.php:
I'd like to issue a "well done" to Visa and those who responded so quickly.
I can only hope that pending disclosures to all the other credit card vendors, banks, and brokerages in the Online Finance Flaws pipeline are handled as quickly and openly.
Thanks again to Mike Bailey (mckt) for his contributions to the cause. You'll see more of his work in future posts.
del.icio.us | digg | Submit to Slashdot
First, a rather strong media response resulted with coverage in The Register, BetaNews, and Dark Reading, amongst others.
Second, aside from all the variant hunters, I received a number of interesting finds from friend-of-the-cause Mike Bailey over at skeptikal.org.
He'd been inspired by the fact that the PoC I issued for the AmEx bug included an IFRAME insertion pointing to Visa.com. Inspiration led to discovery (and whole lot less work for me) and immediate issues were noted in a few Visa sites.
To be fair, http://usa.visa.com itself appears to be sound; both Mike and I gave it a cursory glance and nothing popped up (XSS pun).
The same could not be said for http://empresarial.visa.com.
No need to rehash all the problems XSS issues in major credit card company sites might cause (PCI compliance, phishing, customer abuse, etc.); earlier posts speak for themselves.
As always, I reported the vulns per my terms of engagement.
Here's where the rather unexpected occurred.
I first reported the issues on December 17th at 1322 hours PST.
They were fixed no later than December 18th at 1916 hours PST.
In essence, Visa executed a 24 hour turn around for mitigation and repair.
Now, I have no doubt variant hunters will likely go digging about for other vulnerabilities, and if Visa hasn't issued global repairs, they might find some.
But, what's key here is how quickly Visa responded. I must admit, after the debacle born of the AmEx issue, I wondered if I'd be asked to report the vulns through Visa's PR department, a method recommended by AmEx to report vulns to them. ;-)
Not only was my disclosure responded to in a very timely fashion, I received the following feedback:
"We appreciate you bringing this situation to our attention. Visa takes security matters very seriously. All impacted pages have been taken down while we remediate the XSS coding. As always, feel free to report any future abuses to: abuse@visa.com."
Hard to argue with that.
My impression (unsubstantiated) is that the vulnerable sites were the product of a 3rd party development team, serving Spanish speaking customers, given the fact that the vulnerable code was PHP, not typical of English language Visa properties.
For posterity's sake one of the vulns appeared as follows. There were other similar issues with different variables, different sub-domains, and partner sites, but you get the point.
XSS in empresarial.visa.com/por/glossario.php:
I'd like to issue a "well done" to Visa and those who responded so quickly.
I can only hope that pending disclosures to all the other credit card vendors, banks, and brokerages in the Online Finance Flaws pipeline are handled as quickly and openly.
Thanks again to Mike Bailey (mckt) for his contributions to the cause. You'll see more of his work in future posts.
del.icio.us | digg | Submit to Slashdot
Tuesday, December 16, 2008
So...you can hack a server with XSS?
It's been awhile since I've updated you, dear reader, regarding matters concerning McAfee Secure.
You may recall I met with Joe Pierini and Kirk Lawrence of McAfee Secure in August, and received an update regarding the still pending "McAfee Secure Standard" in October.
Sadly, both Joe and Kirk have left McAfee, in pursuit of better opportunities, leaving our McAfee Secure crusade in lurch. I'll be updating you on the Standard (allegedly, now being released in January), and other proposed improvements to the McAfee Secure offering in days to come. I have been informed that there are people at McAfee willing to carry on the work that Joe and Kirk started.
Now, that said, an update from Joe Pierini. You may recall the numerous times I, and many others, have heckled Joe for his Pwnie award winning statement "Cross-site scripting can't be used to hack a server."
Joe has surprised me at more than one interval; first, attending the Pwnie Awards ceremony at BlackHat 2008, and later, agreeing to fly to Seattle to meet with me and discuss considering significant changes and improvements in the McAfee Secure program.
What I've learned of Joe is that he is technically capable, a worthy web application security assessor and pen tester in his own right, and someone who prefers "breaking things" in the trenches, as opposed to promoting brands as an SE.
Having had numerous conversations with Joe since August, I believe this: the debate sparked by his now infamous "can't hack a server with XSS" statement came down to semantics and context. To be fair, the act of dropping javascript strings behind a vulnerable GET parameter is not a server hack per se, particularly if not utilized in a hybrid attack.
But enough from me; Joe explains just such a hybrid approach quite elegantly in a letter I recently received from him. It is reprinted here with his permission, and I appreciate the opportunity to share it.
Russ,
As you know, I left McAfee Secure in early December to join a security firm in San Jose as a Security Consultant. We provide PCI assurance services related to Merchants, Financial Institutions, Processors and Service Providers. As soon as I complete the PCI Security Standards Council's Qualified Security Assessor (QSA) training course, I will be assuming the responsibilities as a QSA but in the mean time I am performing penetration tests for clients needing to meet the PCI 11.3 requirements.
In one of my first engagements, I came upon a situation where there were no critical vulnerabilities and a few minor issues including XSS and a couple of Exchange mail servers with an open relay misconfiguration. These findings are sufficient with which to take a merchant out of PCI compliance but they lack the drama and urgency of more serious vulnerabilities like SQL Injection. My infamous, award winning catch phrase, “You can’t hack a server with it”, came back to haunt me. While you and I have agreed this is technically true, the the 11.3 penetration tests I was conducting are intended to exploit vulnerabilities. What I needed was an attack scenario that would get their attention and demonstrate the risk of having XSS in the web site.
The mail servers would only allow mail relaying to email addresses within the domain. They would provide the perfect delivery mechanism for the attack. A remote web server could be configured to host the attack pages for XSS Shell. This application ( http://labs.portcullis.co.uk/application/xssshell/) makes use of concepts first presented by XSS Proxy over 3 years ago: persistent, bi-directional communication with a client machine using XSS. The XSS Shell makes it possible to log keystrokes, steal the clipboard, execute arbitrary javascript and more. I don't need to hack the server with it, I could attack the entire company.
First, I could craft an email pretending to be from the web development team asking for help in testing a new piece of functionality in the website. I could then embed an HTML link in the page directing them to their own website, albeit with an attack exploiting the XSS weakness in their web site appended to it. Because the company users would receive an email with all the right headers from their own mail server and directing them to a site they own and inherently trusted, the click through rate would be extremely high and I could collect the session and clip board content from dozens of users. If my instinct was correct, I wouldn't need to upload arbitrary javascript because I would have enough to prove my point: XSS is dangerous and poses an immediate risk.
It’s not just about the servers or the clients, XSS can leave the entire company vulnerable to attack.
Best Regards,
--
Joseph Pierini | CISSP, CISM
Best regards indeed. Thank you, Joe.
del.icio.us | digg | Submit to Slashdot
You may recall I met with Joe Pierini and Kirk Lawrence of McAfee Secure in August, and received an update regarding the still pending "McAfee Secure Standard" in October.
Sadly, both Joe and Kirk have left McAfee, in pursuit of better opportunities, leaving our McAfee Secure crusade in lurch. I'll be updating you on the Standard (allegedly, now being released in January), and other proposed improvements to the McAfee Secure offering in days to come. I have been informed that there are people at McAfee willing to carry on the work that Joe and Kirk started.
Now, that said, an update from Joe Pierini. You may recall the numerous times I, and many others, have heckled Joe for his Pwnie award winning statement "Cross-site scripting can't be used to hack a server."
Joe has surprised me at more than one interval; first, attending the Pwnie Awards ceremony at BlackHat 2008, and later, agreeing to fly to Seattle to meet with me and discuss considering significant changes and improvements in the McAfee Secure program.
What I've learned of Joe is that he is technically capable, a worthy web application security assessor and pen tester in his own right, and someone who prefers "breaking things" in the trenches, as opposed to promoting brands as an SE.
Having had numerous conversations with Joe since August, I believe this: the debate sparked by his now infamous "can't hack a server with XSS" statement came down to semantics and context. To be fair, the act of dropping javascript strings behind a vulnerable GET parameter is not a server hack per se, particularly if not utilized in a hybrid attack.
But enough from me; Joe explains just such a hybrid approach quite elegantly in a letter I recently received from him. It is reprinted here with his permission, and I appreciate the opportunity to share it.
Russ,
As you know, I left McAfee Secure in early December to join a security firm in San Jose as a Security Consultant. We provide PCI assurance services related to Merchants, Financial Institutions, Processors and Service Providers. As soon as I complete the PCI Security Standards Council's Qualified Security Assessor (QSA) training course, I will be assuming the responsibilities as a QSA but in the mean time I am performing penetration tests for clients needing to meet the PCI 11.3 requirements.
In one of my first engagements, I came upon a situation where there were no critical vulnerabilities and a few minor issues including XSS and a couple of Exchange mail servers with an open relay misconfiguration. These findings are sufficient with which to take a merchant out of PCI compliance but they lack the drama and urgency of more serious vulnerabilities like SQL Injection. My infamous, award winning catch phrase, “You can’t hack a server with it”, came back to haunt me. While you and I have agreed this is technically true, the the 11.3 penetration tests I was conducting are intended to exploit vulnerabilities. What I needed was an attack scenario that would get their attention and demonstrate the risk of having XSS in the web site.
The mail servers would only allow mail relaying to email addresses within the domain. They would provide the perfect delivery mechanism for the attack. A remote web server could be configured to host the attack pages for XSS Shell. This application ( http://labs.portcullis.co.uk/application/xssshell/) makes use of concepts first presented by XSS Proxy over 3 years ago: persistent, bi-directional communication with a client machine using XSS. The XSS Shell makes it possible to log keystrokes, steal the clipboard, execute arbitrary javascript and more. I don't need to hack the server with it, I could attack the entire company.
First, I could craft an email pretending to be from the web development team asking for help in testing a new piece of functionality in the website. I could then embed an HTML link in the page directing them to their own website, albeit with an attack exploiting the XSS weakness in their web site appended to it. Because the company users would receive an email with all the right headers from their own mail server and directing them to a site they own and inherently trusted, the click through rate would be extremely high and I could collect the session and clip board content from dozens of users. If my instinct was correct, I wouldn't need to upload arbitrary javascript because I would have enough to prove my point: XSS is dangerous and poses an immediate risk.
It’s not just about the servers or the clients, XSS can leave the entire company vulnerable to attack.
Best Regards,
--
Joseph Pierini | CISSP, CISM
Best regards indeed. Thank you, Joe.
del.icio.us | digg | Submit to Slashdot
Monday, December 15, 2008
Online finance flaw: American Express XSS
Updated again 12/19/08 (see end of post)
Our third entrant in the Online Finance Flaws series is one that truly perturbs me.
American Express came to my attention when setting up an online access account I was prompted to REDUCE the amount of characters in my password to eight or less. What?!
Luckily, my partner in alerting you to the absurd, Rafal Los, covered this issue nicely in May.
Of course, prompted by my irritation, I challenged myself to see what other truly inane security "features" American Express might be offering.
Here's where the trouble begins.
I kid you not, thirty seconds later, I found a new cross-site scripting (XSS) vulnerability right off the American Express primary search script (not one of three already posted on XSSed.com).
Three minutes later , in the TMI department, I discovered a most informative 500 error page exception indicating that American Express uses the Vignette CMS product via Apache and IBM's WebSphere.
Before I validate these findings please allow me to point you to the American Express data security page.
Key language includes:
"American Express is proud to be a founding member of the PCI Security Standards Council. The Council is designed to manage the ongoing evolution of the PCI Data Security Standard and to foster its broad adoption industry-wide. Through our participation with the Council, American Express continues our commitment to diligently pursue all aspects of data security."
Let me spell this out for you.
A founding member of the PCI Security Standards Council is itself in violation of PCI DSS 6.5.4.
This does little for my faith in American Express "data security", or the PCI Security Standards Council for that matter.
Finally, as always, I followed my terms of engagement in reporting these findings to American Express and was ignored by everyone including a director in their information security organization.
A video of both issues is here.
Should you prefer screen shots...an American Express XSS cookie grab:
Or the phishing warning:
Finally, my favorite, an IFRAME insertion of the VISA web site. Oops!
Oh yes, the 500 error, if you're still with me:
Is it wrong of me to expect more of credit card companies with claims to founding the PCI Security Standards Council? I think not.
Please contact American Express and register your own complaint. This is simply unacceptable.
Update 1100 hours 12/17/08:
American Express has made repairs regarding the XSS vulnerability, and has replied to Dan at The Register.
Additionally, this Computerworld article is just too silly and timely to not share in the context of our discussion. May the irony amuse you as much as it did me.
Update 2015 hours 12/19/08:
Repairs as indicated 12/17 now proven to be "repair" as variants galore arise.
Dan G. at The Register exposes research from at least two sources proving once again that one-off repairs are worthless when compared to a global approach.
Makes me wonder what this means for AmEx's stock.
Well done, fellow researchers. Well done.
del.icio.us | digg | Submit to Slashdot
Our third entrant in the Online Finance Flaws series is one that truly perturbs me.
American Express came to my attention when setting up an online access account I was prompted to REDUCE the amount of characters in my password to eight or less. What?!
Luckily, my partner in alerting you to the absurd, Rafal Los, covered this issue nicely in May.
Of course, prompted by my irritation, I challenged myself to see what other truly inane security "features" American Express might be offering.
Here's where the trouble begins.
I kid you not, thirty seconds later, I found a new cross-site scripting (XSS) vulnerability right off the American Express primary search script (not one of three already posted on XSSed.com).
Three minutes later , in the TMI department, I discovered a most informative 500 error page exception indicating that American Express uses the Vignette CMS product via Apache and IBM's WebSphere.
Before I validate these findings please allow me to point you to the American Express data security page.
Key language includes:
"American Express is proud to be a founding member of the PCI Security Standards Council. The Council is designed to manage the ongoing evolution of the PCI Data Security Standard and to foster its broad adoption industry-wide. Through our participation with the Council, American Express continues our commitment to diligently pursue all aspects of data security."
Let me spell this out for you.
A founding member of the PCI Security Standards Council is itself in violation of PCI DSS 6.5.4.
This does little for my faith in American Express "data security", or the PCI Security Standards Council for that matter.
Finally, as always, I followed my terms of engagement in reporting these findings to American Express and was ignored by everyone including a director in their information security organization.
A video of both issues is here.
Should you prefer screen shots...an American Express XSS cookie grab:
Or the phishing warning:
Finally, my favorite, an IFRAME insertion of the VISA web site. Oops!
Oh yes, the 500 error, if you're still with me:
Is it wrong of me to expect more of credit card companies with claims to founding the PCI Security Standards Council? I think not.
Please contact American Express and register your own complaint. This is simply unacceptable.
Update 1100 hours 12/17/08:
American Express has made repairs regarding the XSS vulnerability, and has replied to Dan at The Register.
Additionally, this Computerworld article is just too silly and timely to not share in the context of our discussion. May the irony amuse you as much as it did me.
Update 2015 hours 12/19/08:
Repairs as indicated 12/17 now proven to be "repair" as variants galore arise.
Dan G. at The Register exposes research from at least two sources proving once again that one-off repairs are worthless when compared to a global approach.
Makes me wonder what this means for AmEx's stock.
Well done, fellow researchers. Well done.
del.icio.us | digg | Submit to Slashdot
Tuesday, December 09, 2008
Online finance flaw: U.S. Bank & National City Bank XSS and more
Updated 12/24/08 (see end of post)
In this, our second entry in the series Online Finance Flaws, I call to your attention a report from Javelin Strategy & Research, the Banking Identity Safety Scorecard.
According to the MarketWatch writeup on the report, it "measures 25 leading U.S. financial institutions' customer-facing identity fraud capabilities. The Javelin model measures Prevention, Detection and Resolution(TM) features to track performance throughout the fraud cycle."
While I don't have the $1500 handy to purchase rights to read the complete report, it appears to be a comprehensive, well intended, ongoing effort.
Key questions asked by Javelin include:
1) Which financial institutions rank highest against Javelin’s customer-facing Prevention, Detection and Resolution™ criteria?
2) What type of account protection capabilities should banks and credit unions implement now to increase customer safety through Prevention, Detection and Resolution™?
3) Which customer safety features will most differentiate financial institutions in the future?
In answer to #1, the report lists its Top 5 indicating that Bank of America once again earned top overall honors, demonstrating excellence in its efforts to partner with customers against a crime that uniquely targets both the financial institution and the consumer. National City Bank (acquired by PNC) and Wells Fargo shared second position with equivalent scores followed closely by US Bank and Wachovia.
I'll answer #2 & #3 below.
I'll ask some further questions first, however.
Do we agree that web application security should and does play a critical role in what Javelin refers to as Prevention, Detection and Resolution™?
Do we agree that cross-site scripting (XSS), cross-site request forgery (CSRF), information disclosure, and SQL injection (SQLi) are all flaws that should not exist in a bank site on Javelin's Top 5?
Do we agree that XSS issues make for golden phishing opportunities for the inherently malicious, and again, should not exist in bank sites on Javelin's Top 5 with regard to a Banking Identity Safety Scorecard?
Before I discuss the flaws, be aware that I followed my terms of engagement with both of the following banks, and was largely ignored with either no reply or very vague, inconclusive brush-offs.
It is my hope that you, dear reader, will contact the following institutions, as I have, on behalf of the consumers they are obligated to protect, in the hope that they will make timely repairs.
And here, as I am prone to saying, is where the trouble begins.
U.S. Bank is vulnerable to XSS at their logon page.
National City Bank is vulnerable to XSS and information disclosure, as well as potential CSRF and potential SQLi, in a Cold Fusion (gasp!) app that runs a subdomain; specifically insights.nationalcity.com.
While the potential National City Bank vulns don't necessarily give a malicious attacker a ton to work with, given that it's an isolated app running a subdomain, the XSS issue is still useful in obvious ways.
I am particularly saddened by the XSS issue on the U.S. Bank site given the history of exploitation of just opportunities. See what I call the Italian Bank Job, and the article I wrote, Anatomy of an XSS Attack, inspired by the Italian caper.
Note that, as indicated in the Netcraft article on the Italian bank issue, SSL "security" is a moot point. Any script execution in the context of the U.S. Bank site occurs "protected" by SSL. As Netcraft says, "any SSL certificate associated with the site - included Extended Validation certificates - would display a padlock icon and apparently assure the user that the injected login form is genuine."
The National City Bank issues appear as follows.
XSS:
Information disclosure and potential SQLi both appear in the grossly verbose, overly helpful Cold Fusion error:
As a technical evangelist for online consumer well-being, and an information security practitioner, I'm here to tell you: these vulnerablities are indicative of behavior unbecoming of secure online banking; particularly as applied to two of the five "top-ranked banks who partner with customers to protect against identity fraud."
To answer #2 and #3 from above: build secure web applications.
U.S. Bank and National City Bank, I ask you to resolve these issues soon, on behalf of customers in your care.
Update 12/24/08:
U.S. Bank has notified me that they've repaired the vulnerable login code. Additionally, they've asked that I remove the video PoC, a request I choose to honor in deference to their open communication during the remediation period.
I've heard nothing from National City Bank. That said, while the initially reported issues appear to have been resolved, the resulting error message is still sloppy and overly informative (typical of Cold Fusion left unchecked).
del.icio.us | digg | Submit to Slashdot
In this, our second entry in the series Online Finance Flaws, I call to your attention a report from Javelin Strategy & Research, the Banking Identity Safety Scorecard.
According to the MarketWatch writeup on the report, it "measures 25 leading U.S. financial institutions' customer-facing identity fraud capabilities. The Javelin model measures Prevention, Detection and Resolution(TM) features to track performance throughout the fraud cycle."
While I don't have the $1500 handy to purchase rights to read the complete report, it appears to be a comprehensive, well intended, ongoing effort.
Key questions asked by Javelin include:
1) Which financial institutions rank highest against Javelin’s customer-facing Prevention, Detection and Resolution™ criteria?
2) What type of account protection capabilities should banks and credit unions implement now to increase customer safety through Prevention, Detection and Resolution™?
3) Which customer safety features will most differentiate financial institutions in the future?
In answer to #1, the report lists its Top 5 indicating that Bank of America once again earned top overall honors, demonstrating excellence in its efforts to partner with customers against a crime that uniquely targets both the financial institution and the consumer. National City Bank (acquired by PNC) and Wells Fargo shared second position with equivalent scores followed closely by US Bank and Wachovia.
I'll answer #2 & #3 below.
I'll ask some further questions first, however.
Do we agree that web application security should and does play a critical role in what Javelin refers to as Prevention, Detection and Resolution™?
Do we agree that cross-site scripting (XSS), cross-site request forgery (CSRF), information disclosure, and SQL injection (SQLi) are all flaws that should not exist in a bank site on Javelin's Top 5?
Do we agree that XSS issues make for golden phishing opportunities for the inherently malicious, and again, should not exist in bank sites on Javelin's Top 5 with regard to a Banking Identity Safety Scorecard?
Before I discuss the flaws, be aware that I followed my terms of engagement with both of the following banks, and was largely ignored with either no reply or very vague, inconclusive brush-offs.
It is my hope that you, dear reader, will contact the following institutions, as I have, on behalf of the consumers they are obligated to protect, in the hope that they will make timely repairs.
And here, as I am prone to saying, is where the trouble begins.
U.S. Bank is vulnerable to XSS at their logon page.
National City Bank is vulnerable to XSS and information disclosure, as well as potential CSRF and potential SQLi, in a Cold Fusion (gasp!) app that runs a subdomain; specifically insights.nationalcity.com.
While the potential National City Bank vulns don't necessarily give a malicious attacker a ton to work with, given that it's an isolated app running a subdomain, the XSS issue is still useful in obvious ways.
I am particularly saddened by the XSS issue on the U.S. Bank site given the history of exploitation of just opportunities. See what I call the Italian Bank Job, and the article I wrote, Anatomy of an XSS Attack, inspired by the Italian caper.
Note that, as indicated in the Netcraft article on the Italian bank issue, SSL "security" is a moot point. Any script execution in the context of the U.S. Bank site occurs "protected" by SSL. As Netcraft says, "any SSL certificate associated with the site - included Extended Validation certificates - would display a padlock icon and apparently assure the user that the injected login form is genuine."
The National City Bank issues appear as follows.
XSS:
Information disclosure and potential SQLi both appear in the grossly verbose, overly helpful Cold Fusion error:
As a technical evangelist for online consumer well-being, and an information security practitioner, I'm here to tell you: these vulnerablities are indicative of behavior unbecoming of secure online banking; particularly as applied to two of the five "top-ranked banks who partner with customers to protect against identity fraud."
To answer #2 and #3 from above: build secure web applications.
U.S. Bank and National City Bank, I ask you to resolve these issues soon, on behalf of customers in your care.
Update 12/24/08:
U.S. Bank has notified me that they've repaired the vulnerable login code. Additionally, they've asked that I remove the video PoC, a request I choose to honor in deference to their open communication during the remediation period.
I've heard nothing from National City Bank. That said, while the initially reported issues appear to have been resolved, the resulting error message is still sloppy and overly informative (typical of Cold Fusion left unchecked).
del.icio.us | digg | Submit to Slashdot
Wednesday, December 03, 2008
Online Finance Flaw: TIAA-CREF XSS & Potential CSRF
Update 12/4/08: TIAA-CREF has made appropriate repairs, and is no longer vulnerable to common XSS in the search.jsp script. I applaud their responsiveness.
Before discussing a TIAA-CREF security flaw, allow me to clarify my "terms of engagement".
Prior to offering analysis of any security flaws in online financial services, be assured I have engaged the service provider and offered what I believe to a reasonable amount of time to remedy this issue. Specifically, a minimum of two weeks and three unique contact attempts are made. Should the vendor offer a timeline in which the issue will be resolved, so long as it is not months or years, I will wait until they are ready to deploy the fix, then discuss the vulnerability. If I am not in receipt of a reply other than generic customer service replies, I will follow the two week standard, then discuss the issue.
TIAA-CREF, or the Teachers Insurance and Annuity Association - College Retirement Equities Fund, is a respected, widely utilized provider of numerous financial products and services. The TIAA-CREF site is ranked 26,148 on Alexa.com at the time of this writing.
I'll first direct you to the TIAA-CREF Security page, where they discuss the expected elements like identity theft, spoofing, tips, and my favorite, phishing.
Here's where the trouble begins. Obviously, most phishing occurs when some miscreant creates a fake page and attempts to lure victims via email.
The severity of phishing risks are greatly increased by the introduction of a cross-site scripting (XSS) vulnerability in a site that is of high value to phishing attackers.
With such a vulnerability available, the prospect of success for a phisher are much higher given that the malicious URL they would craft could include the actual target domain, rather than a faked misrepresentation. A simple script insertion at the vulnerable variable would then allow the attacker to redirect victims to a maliciously crafted logon page in the context of the vulnerable site.
Sad side note: when you search security at the TIAA-CREF site, the above mentioned Security page is not returned in the results as I write this.
However, the resulting search URL serves as the starting point for our discussion of the flaw:
http://www.tiaa-cref.org/explore/portlets/search.jsp?query=security&strtfrm=1&totpresults=75&srchtype=4&sc=1&frmsite=0
The vast majority of non-search input variables on the TIAA-CREF site offer reasonable XSS protections, likely a blacklist method that redirects you to the following language when common XSS strings are noted, particularly where it counts at logon pages.
Due to the presence of characters known to be used in Cross Site Scripting attacks, access is forbidden. This web site does not allow Urls which might include embedded HTML tags.
Unfortunately, this methodology was not deployed globally, and thus the following online finance flaw.
All input variables used in TIAA-CREF's search.jsp script are vulnerable to XSS.
Utilized by an attacker, this could have a much more significant impact on TIAA-CREF customers who fall victim to a now more convincing social engineering effort.
Here's the site before script insertion:
Here's the site after script insertion:
Further, certain parts of the site, including the Trust Company logon page, show potential signs of cross-site request forgery (CSRF) in that they accept updates via GET or allow submittal with the referrer stripped.
Lessons learned:
1) Don't assume all is well even though a site may offer examples of how attentive they are to security.
2) Never log on to an online financial service offering (or anything else for that matter) via a link sent to you in an email. Period.
3) Take all steps at your disposal to ensure you are logging in to and transacting with the actual site you intended to utilize. Don't depend on security badges and SSL certificates as your sole means of confirmation.
4) If you note something of concern at a site you utilize, advise them immediately and demand repair or clarification until you're satisfied.
Please feel free to send feedback to TIAA-CREF as I have per my "terms of engagement" above. Hopefully they'll resolve this issue soon, on behalf of customers in their care.
Up next in our series, two of the top five banks mentioned in Javelin Strategy & Research's Banking Identity Safety Scorecard are vulnerable to similar issues.
del.icio.us | digg | Submit to Slashdot
Before discussing a TIAA-CREF security flaw, allow me to clarify my "terms of engagement".
Prior to offering analysis of any security flaws in online financial services, be assured I have engaged the service provider and offered what I believe to a reasonable amount of time to remedy this issue. Specifically, a minimum of two weeks and three unique contact attempts are made. Should the vendor offer a timeline in which the issue will be resolved, so long as it is not months or years, I will wait until they are ready to deploy the fix, then discuss the vulnerability. If I am not in receipt of a reply other than generic customer service replies, I will follow the two week standard, then discuss the issue.
TIAA-CREF, or the Teachers Insurance and Annuity Association - College Retirement Equities Fund, is a respected, widely utilized provider of numerous financial products and services. The TIAA-CREF site is ranked 26,148 on Alexa.com at the time of this writing.
I'll first direct you to the TIAA-CREF Security page, where they discuss the expected elements like identity theft, spoofing, tips, and my favorite, phishing.
Here's where the trouble begins. Obviously, most phishing occurs when some miscreant creates a fake page and attempts to lure victims via email.
The severity of phishing risks are greatly increased by the introduction of a cross-site scripting (XSS) vulnerability in a site that is of high value to phishing attackers.
With such a vulnerability available, the prospect of success for a phisher are much higher given that the malicious URL they would craft could include the actual target domain, rather than a faked misrepresentation. A simple script insertion at the vulnerable variable would then allow the attacker to redirect victims to a maliciously crafted logon page in the context of the vulnerable site.
Sad side note: when you search security at the TIAA-CREF site, the above mentioned Security page is not returned in the results as I write this.
However, the resulting search URL serves as the starting point for our discussion of the flaw:
http://www.tiaa-cref.org/explore/portlets/search.jsp?query=security&strtfrm=1&totpresults=75&srchtype=4&sc=1&frmsite=0
The vast majority of non-search input variables on the TIAA-CREF site offer reasonable XSS protections, likely a blacklist method that redirects you to the following language when common XSS strings are noted, particularly where it counts at logon pages.
Due to the presence of characters known to be used in Cross Site Scripting attacks, access is forbidden. This web site does not allow Urls which might include embedded HTML tags.
Unfortunately, this methodology was not deployed globally, and thus the following online finance flaw.
All input variables used in TIAA-CREF's search.jsp script are vulnerable to XSS.
Utilized by an attacker, this could have a much more significant impact on TIAA-CREF customers who fall victim to a now more convincing social engineering effort.
Here's the site before script insertion:
Here's the site after script insertion:
Further, certain parts of the site, including the Trust Company logon page, show potential signs of cross-site request forgery (CSRF) in that they accept updates via GET or allow submittal with the referrer stripped.
Lessons learned:
1) Don't assume all is well even though a site may offer examples of how attentive they are to security.
2) Never log on to an online financial service offering (or anything else for that matter) via a link sent to you in an email. Period.
3) Take all steps at your disposal to ensure you are logging in to and transacting with the actual site you intended to utilize. Don't depend on security badges and SSL certificates as your sole means of confirmation.
4) If you note something of concern at a site you utilize, advise them immediately and demand repair or clarification until you're satisfied.
Please feel free to send feedback to TIAA-CREF as I have per my "terms of engagement" above. Hopefully they'll resolve this issue soon, on behalf of customers in their care.
Up next in our series, two of the top five banks mentioned in Javelin Strategy & Research's Banking Identity Safety Scorecard are vulnerable to similar issues.
del.icio.us | digg | Submit to Slashdot
Tuesday, December 02, 2008
Actns/Swif.T virus found in YouTube videos
TOOLS FOR FLASH ANALYSIS
Update 13:35 PDT: False positive finding from CA triggering on System.security.allowDomain("*").
Regardless, these two sites are indispensable for their quick analytic capability.
Seeing System.security.allowDomain("*") as problematic in not necessarily wrong as it often indicates malicious content.
Breaking news regarding malicious Flash popping up from YouTube is starting to break all over the Internet.
CrunchGear has a bit of a write-up on it.
Rather than sound off about what will become old news quickly, I'd like to point you to resources I use to analyze (or have the analysis done for me, to be more concise) malicious Flash or JavaScript.
I grabbed the evil .swf in question from the URL below via command-line on my trusty Ubuntu box:
wget hxxp://www.youtube.com/v/O7tB1pYSNuE&rel=1
I then fed l.swf to Adops Tools and Wepawet.
The results from each analysis are below for your review.
Note System.security.allowDomain("*").
Not good. ;-)
Adops Tools Results
Wepawet Results
Use in good faith, but always be careful grabbing the evil .swf.
del.icio.us | digg | Submit to Slashdot
Update 13:35 PDT: False positive finding from CA triggering on System.security.allowDomain("*").
Regardless, these two sites are indispensable for their quick analytic capability.
Seeing System.security.allowDomain("*") as problematic in not necessarily wrong as it often indicates malicious content.
Breaking news regarding malicious Flash popping up from YouTube is starting to break all over the Internet.
CrunchGear has a bit of a write-up on it.
Rather than sound off about what will become old news quickly, I'd like to point you to resources I use to analyze (or have the analysis done for me, to be more concise) malicious Flash or JavaScript.
I grabbed the evil .swf in question from the URL below via command-line on my trusty Ubuntu box:
wget hxxp://www.youtube.com/v/O7tB1pYSNuE&rel=1
I then fed l.swf to Adops Tools and Wepawet.
The results from each analysis are below for your review.
Note System.security.allowDomain("*").
Not good. ;-)
Adops Tools Results
Wepawet Results
Use in good faith, but always be careful grabbing the evil .swf.
del.icio.us | digg | Submit to Slashdot
Monday, December 01, 2008
Safe Keeping: Article on TrueCrypt in Information Security
My article, Safe Keeping, regarding TrueCrypt, is now available in Information Security magazine.
TrueCrypt is an open source laptop encryption alternative for your organization.
This article also includes a sidebar on Adeona, an open source system for tracking the location of your lost or stolen laptop that does not rely on a proprietary, central service.
I humbly suggest that you consider using both should you lack commercial solutions.
Cheers.
del.icio.us | digg | Submit to Slashdot
Saturday, November 29, 2008
Online Finance Flaws: An Awareness Campaign
Here begins a series regarding web application security inadequacies in online financial service offerings. The services to be discussed will include banks, credit unions, credit card companies, and others. As the economy struggles profoundly, and much of the blame points at the financial sector, I believe it important to point out the false sense of security so many brand-name financial services wrongly instill in their customers.
Often this sense of security is coupled with a typical "security badge" provider, helping drive conversions rather than security, as we will also legitimize how often the badge providers miss the mark on their promises.
Accountability in loan making decisions and practices might have prevented the sub-prime market collapse and the subsequent credit crunch that has hogtied our economy.
Accountability with regard to web application security while providing online financial services is now all the more important as cybercrime will continue to increase at a pace proportionate to economic woes.
Each post relevant to this campaign will include Online Finance Flaw in its title for tracking purposes.
Look forward to surprising flaws in financial services brands you'll recognize.
Perhaps, the more attention we draw to services that should place security above all else, the more likely it is they'll commit to improving their security posture.
Feel free to comment or contribute; we'll begin in a day or two.
Often this sense of security is coupled with a typical "security badge" provider, helping drive conversions rather than security, as we will also legitimize how often the badge providers miss the mark on their promises.
Accountability in loan making decisions and practices might have prevented the sub-prime market collapse and the subsequent credit crunch that has hogtied our economy.
Accountability with regard to web application security while providing online financial services is now all the more important as cybercrime will continue to increase at a pace proportionate to economic woes.
Each post relevant to this campaign will include Online Finance Flaw in its title for tracking purposes.
Look forward to surprising flaws in financial services brands you'll recognize.
Perhaps, the more attention we draw to services that should place security above all else, the more likely it is they'll commit to improving their security posture.
Feel free to comment or contribute; we'll begin in a day or two.
Tuesday, November 18, 2008
Mamma.com: Insider trading and XSS
Mamma.com's got issues other than Mark Cuban's insider trading allegations. As a point of reference for this conversation, Mamma.com is ranked 4064 on Alexa as of today.
I won't profess to following Mr. Cuban's public life and the occasional antics. Obviously, he's a colorful and popular figure; certainly in Dallas, if not nationally.
What follows is not a judgment of Mr. Cuban or his pending legal challenges. I'm sure the process will play itself out accordingly.
A quick summary and some reference material:
The SEC has filed insider trading charges against Mr. Cuban. "According to the SEC, Cuban dumped 600,000 shares, or all of his 6.3% stake, in the search engine Mamma.com (The Mother of All Search Engines), in June 2004 after learning about private financing that the company was proposing. By selling, he avoided losing $750,000, the SEC alleges."
The whole issue for Mr. Cuban was PIPE financing because it's "dilutive to existing shareholders’ stakes."
That's the long and the short of the current issue, and again, not my real interest here, with the exception of the bet I made with myself regarding the probable web application security posture of mamma.com.
All this talk about a popular site immediately sets off the little bell in my head (I hear it a lot).
"What's wrong with the site?" is always the first question I ask myself.
I was not disappointed.
Mamma.com exhibits the following issues:
1) XSS vulnerability in the utfout variable.
2) XSS vulnerability in the qtype variable.
3) XSS vulnerability in their Mammajobs site at the pid variable. This one's weirder still; if you drop an IFRAME in, it simply redirects to any URL you include in the IFRAME string.
4) The prospect of CSRF (rather pointless here given that its just a search engine, but but still defies best practices) appears likely given that mamma.com blindly accepts updates via GET and POST with no sign of a formkey (canary) in sight.
I figured it best to stop there, and have submitted all these to Copernic (the Momma parent company).
I am however truly disappointed that an enterprise as ambitious and motivated as Momma/Copernic seems to have thrown the baby out with the bath water when it comes to web application security.
With regard to Mark Cuban dumping his shares: maybe he was afraid of getting pwned. ;-) All kidding aside, it's a shame that the whimsical and pessimistic thoughts regarding web site security that bounce around in my head inevitably bear themselves out.
del.icio.us | digg | Submit to Slashdot
I won't profess to following Mr. Cuban's public life and the occasional antics. Obviously, he's a colorful and popular figure; certainly in Dallas, if not nationally.
What follows is not a judgment of Mr. Cuban or his pending legal challenges. I'm sure the process will play itself out accordingly.
A quick summary and some reference material:
The SEC has filed insider trading charges against Mr. Cuban. "According to the SEC, Cuban dumped 600,000 shares, or all of his 6.3% stake, in the search engine Mamma.com (The Mother of All Search Engines), in June 2004 after learning about private financing that the company was proposing. By selling, he avoided losing $750,000, the SEC alleges."
The whole issue for Mr. Cuban was PIPE financing because it's "dilutive to existing shareholders’ stakes."
That's the long and the short of the current issue, and again, not my real interest here, with the exception of the bet I made with myself regarding the probable web application security posture of mamma.com.
All this talk about a popular site immediately sets off the little bell in my head (I hear it a lot).
"What's wrong with the site?" is always the first question I ask myself.
I was not disappointed.
Mamma.com exhibits the following issues:
1) XSS vulnerability in the utfout variable.
2) XSS vulnerability in the qtype variable.
3) XSS vulnerability in their Mammajobs site at the pid variable. This one's weirder still; if you drop an IFRAME in, it simply redirects to any URL you include in the IFRAME string.
4) The prospect of CSRF (rather pointless here given that its just a search engine, but but still defies best practices) appears likely given that mamma.com blindly accepts updates via GET and POST with no sign of a formkey (canary) in sight.
I figured it best to stop there, and have submitted all these to Copernic (the Momma parent company).
I am however truly disappointed that an enterprise as ambitious and motivated as Momma/Copernic seems to have thrown the baby out with the bath water when it comes to web application security.
With regard to Mark Cuban dumping his shares: maybe he was afraid of getting pwned. ;-) All kidding aside, it's a shame that the whimsical and pessimistic thoughts regarding web site security that bounce around in my head inevitably bear themselves out.
del.icio.us | digg | Submit to Slashdot
Wednesday, November 12, 2008
XSS Comedy III: Tax Cheats with Small Equipment
As part of an ongoing series, if I may I, the third in a series on the absurd, inane, and perhaps even funny. Lest you forget: the first and second in the series.
I don't know about you, but I enjoy occasionally watching offerings like the History Channel, AMC, or the Military Channel. I'm a 40ish, white male and as such I likely fit the general demographic as perceived by the marketing geniuses who buy the late evening advertising blocks on these channels.
That does NOT mean that I cheat on my taxes and thus need the services of a plethora of scam artists selling tax relief. Nor does it mean that I have any interest in "enhancement" opportunities like Enzyte or ExtenZe.
I just love people who choose to skip out on a primary obligation of citizenship that most of us choose to meet, and expect to magically turn $100,000 in tax debt into $999. Then there are the "businesses" who exploit these folks and willingly convince them of their "success" via the power of advertising, at which point my patience just snaps, as it did last night.
Thus, part one of this rant is a mighty bugger off to all the "tax relief" companies. To their patrons, may I suggest simply paying taxes like the rest of us?
Here's an XSS vulnerability in the Freedom Financial Network, "as seen on TV", designed to express precisely how I feel:
http://www.freedomfinancialnetwork.com/tax_debt.php?pid=ffn+go&key=%22%3E%3Cmarquee%3E%3Ch1%3ENOTHING_IS_FREE!%3C%2Fh1%3E%3C%2Fmarquee%3E
If and when they fix this issue, here's the video for posterity.
Part two of this rant will get you more bang for your buck, and I'm not talking enhancement.
Thanks to my utter disdain for the endlessly annoying advertising I went to the ExtenZe site to see what might be broken which immediately led me to discover an entire platform vulnerability in the ColdFusion application built by Internet Direct Response (IDR), the wankers who proudly bring you Maxoderm, Vivaxa, Vazomyne, Smoke Away, and Hydroxydrene; all such reputable products, and all repetitively wearing me out via DirectTV. At the ExtenZe site I spotted a variable that seemed worthy of building a Googledork from, and I soon discovered that it was a consistent variable in most of the sites pimping this crap; specifically, microppcsite. You can follow all the search results back to our friends at IDR.
A little experimentation and I quickly discovered that the similar microppcterm variable was vulnerable to entertaining XSS exploitation so I started with:
http://www.extenzeforlife.com/?microppcsite=googleµppcterm=%22%3E%3Cmarquee%3E%3Ch1%3EToo_short,_Morningwood?%3C%2Fh1%3E%3C%2Fmarquee%3E&gclid=CJ3T2NXH8JYCFQQCagod7xyBrA
Pick your poison, it works on most IDR gems.
http://www.enzyte-male-enhancement.com/google/?microppcsite=googleµppcterm=%22%3E%3Cmarquee%3E%3Ch1%3EBob_just_wants_your_money.%3C%2Fh1%3E%3C%2Fmarquee%3E
Again, a video, should IDR choose to fix their app.
And now, the grand prize for pathetic: The ExtenZe site is McAfee Secure.
I couldn't make this stuff up if I tried.
You thought www stood for world wide web. Try wee willy wankers. *sigh*
del.icio.us | digg | Submit to Slashdot
I don't know about you, but I enjoy occasionally watching offerings like the History Channel, AMC, or the Military Channel. I'm a 40ish, white male and as such I likely fit the general demographic as perceived by the marketing geniuses who buy the late evening advertising blocks on these channels.
That does NOT mean that I cheat on my taxes and thus need the services of a plethora of scam artists selling tax relief. Nor does it mean that I have any interest in "enhancement" opportunities like Enzyte or ExtenZe.
I just love people who choose to skip out on a primary obligation of citizenship that most of us choose to meet, and expect to magically turn $100,000 in tax debt into $999. Then there are the "businesses" who exploit these folks and willingly convince them of their "success" via the power of advertising, at which point my patience just snaps, as it did last night.
Thus, part one of this rant is a mighty bugger off to all the "tax relief" companies. To their patrons, may I suggest simply paying taxes like the rest of us?
Here's an XSS vulnerability in the Freedom Financial Network, "as seen on TV", designed to express precisely how I feel:
http://www.freedomfinancialnetwork.com/tax_debt.php?pid=ffn+go&key=%22%3E%3Cmarquee%3E%3Ch1%3ENOTHING_IS_FREE!%3C%2Fh1%3E%3C%2Fmarquee%3E
If and when they fix this issue, here's the video for posterity.
Part two of this rant will get you more bang for your buck, and I'm not talking enhancement.
Thanks to my utter disdain for the endlessly annoying advertising I went to the ExtenZe site to see what might be broken which immediately led me to discover an entire platform vulnerability in the ColdFusion application built by Internet Direct Response (IDR), the wankers who proudly bring you Maxoderm, Vivaxa, Vazomyne, Smoke Away, and Hydroxydrene; all such reputable products, and all repetitively wearing me out via DirectTV. At the ExtenZe site I spotted a variable that seemed worthy of building a Googledork from, and I soon discovered that it was a consistent variable in most of the sites pimping this crap; specifically, microppcsite. You can follow all the search results back to our friends at IDR.
A little experimentation and I quickly discovered that the similar microppcterm variable was vulnerable to entertaining XSS exploitation so I started with:
http://www.extenzeforlife.com/?microppcsite=googleµppcterm=%22%3E%3Cmarquee%3E%3Ch1%3EToo_short,_Morningwood?%3C%2Fh1%3E%3C%2Fmarquee%3E&gclid=CJ3T2NXH8JYCFQQCagod7xyBrA
Pick your poison, it works on most IDR gems.
http://www.enzyte-male-enhancement.com/google/?microppcsite=googleµppcterm=%22%3E%3Cmarquee%3E%3Ch1%3EBob_just_wants_your_money.%3C%2Fh1%3E%3C%2Fmarquee%3E
Again, a video, should IDR choose to fix their app.
And now, the grand prize for pathetic: The ExtenZe site is McAfee Secure.
I couldn't make this stuff up if I tried.
You thought www stood for world wide web. Try wee willy wankers. *sigh*
del.icio.us | digg | Submit to Slashdot
Tuesday, November 11, 2008
Vulnerabilities quickly mitigated by security-conscious vendors
As you are likely aware, I spend a fair bit of time heckling those I believe deserving due to their shortcomings with regard to protecting online consumers.
I do, however, continue to seek opportunities to shed positive light as well, and recent responses from a number of vendor/developers warrant an opportunity to do just that.
In the last 30 days, I've discovered vulnerabilities in products from four different vendors, and advised them all immediately upon discovery. Usually, that's where the story ends, as sadly, my repeated requests for action are often ignored. The last 30 days have proven to be entirely different, with swift responses and action from ALL vendors to whom I reported vulnerabilities. In all cases I received replies within 24 hours or less, and patches/fixes/updates were typically released within 24-72 additional hours. These are exemplary responses, and reflect why I choose to conduct vulnerability research. I believe we, as web application professionals (both developers and security practitioners), are beholden to the greater public and must endeavor to protect the online safety of the Internet consumer.
To each of these vendors/developers I'd like to issue a hearty "well done" and issue public kudos for their diligence and security consciousness, on behalf of consumers and website operators.
To Lukas of PlanetLuc, Jasper and Eric of Infrae/Silva, Alexander of CompactCMS, and Peter from ActiveCampaign may I say that your efforts are greatly appreciated. Where too few choose to do the right thing, your responses leave us with the perception of caring and integrity.
Thank you.
del.icio.us | digg | Submit to Slashdot
I do, however, continue to seek opportunities to shed positive light as well, and recent responses from a number of vendor/developers warrant an opportunity to do just that.
In the last 30 days, I've discovered vulnerabilities in products from four different vendors, and advised them all immediately upon discovery. Usually, that's where the story ends, as sadly, my repeated requests for action are often ignored. The last 30 days have proven to be entirely different, with swift responses and action from ALL vendors to whom I reported vulnerabilities. In all cases I received replies within 24 hours or less, and patches/fixes/updates were typically released within 24-72 additional hours. These are exemplary responses, and reflect why I choose to conduct vulnerability research. I believe we, as web application professionals (both developers and security practitioners), are beholden to the greater public and must endeavor to protect the online safety of the Internet consumer.
To each of these vendors/developers I'd like to issue a hearty "well done" and issue public kudos for their diligence and security consciousness, on behalf of consumers and website operators.
To Lukas of PlanetLuc, Jasper and Eric of Infrae/Silva, Alexander of CompactCMS, and Peter from ActiveCampaign may I say that your efforts are greatly appreciated. Where too few choose to do the right thing, your responses leave us with the perception of caring and integrity.
Thank you.
del.icio.us | digg | Submit to Slashdot
Tuesday, October 28, 2008
Ticketmaster/Paciolan XSS: Thanks, but I'll buy at the stadium
Update: Just checked, and although I was never contacted by anyone from Ticketmaster/Paciolan, this vulnerability appears mitigated as of 11/6/08.
As if the extra Ticketmaster fees weren't enough, how about the prospect of your PII being stolen because they forgot to perform proper due diligence via a web application security assessment on recent acquisition Paciolan?
Consider the following Google search results. The server referenced therein hosts an "integrated ticketing system that enables venues to manage their own tickets."
Rutgers, University of Washington, Army, Air Force, Navy, Baylor, Notre Dame, even the American Museum of Natural History; all sell their tickets online through the Ticketmaster/Paciolan offering.
And they're all vulnerable as a result.
I've made multiple attempts to notify these folks, and have been ignored, so time for a scolding as my Gran used to say.
It's been awhile since I've brought video to bear and while I've nothing against the Arkansas Razorbacks, I had to utilize someone's instance of this service to prove my point, so away we go.
By the way, I just love the Verisign Secured badge (it's not going to help here).
Here's the full URL:
http://ev12.evenue.net/cgi-bin/ncommerce3/SEGetEventList?groupCode=FB&linkID=arkansas&shopperContext=&caller=&appCode=&RSRC=TM&RDAT=FB08SPLASH
The shopperContext (how ironic) variable is the parameter with issues. Mind you, this holds true for any university or venue using this service.
For your viewing pleasure, the video.
Yes, they take your credit card information, and conduct the ticket purchase transaction. If you've read my blog, you know by now the risks inherent to cross-site scripting vulnerabilities under circumstances like these. Verisign SSL certs are nice, but won't help the consumer if the web app is vulnerable.
Thanks, but I'll buy my tickets at the stadium. ;-)
Should Ticketmaster/Paciolan fix this issue, I'll update the post accordingly.
del.icio.us | digg | Submit to Slashdot
As if the extra Ticketmaster fees weren't enough, how about the prospect of your PII being stolen because they forgot to perform proper due diligence via a web application security assessment on recent acquisition Paciolan?
Consider the following Google search results. The server referenced therein hosts an "integrated ticketing system that enables venues to manage their own tickets."
Rutgers, University of Washington, Army, Air Force, Navy, Baylor, Notre Dame, even the American Museum of Natural History; all sell their tickets online through the Ticketmaster/Paciolan offering.
And they're all vulnerable as a result.
I've made multiple attempts to notify these folks, and have been ignored, so time for a scolding as my Gran used to say.
It's been awhile since I've brought video to bear and while I've nothing against the Arkansas Razorbacks, I had to utilize someone's instance of this service to prove my point, so away we go.
By the way, I just love the Verisign Secured badge (it's not going to help here).
Here's the full URL:
http://ev12.evenue.net/cgi-bin/ncommerce3/SEGetEventList?groupCode=FB&linkID=arkansas&shopperContext=&caller=&appCode=&RSRC=TM&RDAT=FB08SPLASH
The shopperContext (how ironic) variable is the parameter with issues. Mind you, this holds true for any university or venue using this service.
For your viewing pleasure, the video.
Yes, they take your credit card information, and conduct the ticket purchase transaction. If you've read my blog, you know by now the risks inherent to cross-site scripting vulnerabilities under circumstances like these. Verisign SSL certs are nice, but won't help the consumer if the web app is vulnerable.
Thanks, but I'll buy my tickets at the stadium. ;-)
Should Ticketmaster/Paciolan fix this issue, I'll update the post accordingly.
del.icio.us | digg | Submit to Slashdot
Thursday, October 16, 2008
Open Redirects and Common Weakness Enumeration
Hopefully, you're more than familiar with CVE (Common Vulnerabilities and Exposures), but perhaps you're less familiar with CWE (Common Weaknesses Enumeration). Both are significant efforts, international in scope, and the excellent products of The MITRE Corporation, sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security.
Approximately six months ago I was discussing open redirect vulnerabilities with Steven Christey of MITRE, who mentioned that that CWE entry for open redirects was sparse and dated, with little reference material. In particular, he pointed out the lack of defining papers. I accepted this information as a challenge and produced an article that was published in (IN)SECURE Issue 17. Soon after Issue 17 went live, I also took note of an excellent academic paper specific to the topic of open redirect vulnerabilities; Shue, Kalafut and Gupta's Exploitable Redirects on the Web: Identification, Prevalence, and Defense. Complete with these two papers as references, as well as two current CVE identifiers for popular web applications suffering from open redirect vulnerabilities (discovered by yours truly), CVE-2008-2052 & 2951, CWE-601: URL Redirection to Untrusted Site (aka 'Open Redirect') is now current and complete.
As open redirects are undoubtedly one of my biggest pet peeves, I am pleased to no end. Hopefully CWE-601 will help drive more application vendors and site operators to put an end to this easily mitigated vulnerability.
CWE:
"International in scope and free for public use, CWE™ provides a unified, measurable set of software weaknesses that is enabling more effective discussion, description, selection, and use of software security tools and services that can find these weaknesses in source code and operational systems as well as better understanding and management of software weaknesses related to architecture and design."
del.icio.us | digg | Submit to Slashdot
Approximately six months ago I was discussing open redirect vulnerabilities with Steven Christey of MITRE, who mentioned that that CWE entry for open redirects was sparse and dated, with little reference material. In particular, he pointed out the lack of defining papers. I accepted this information as a challenge and produced an article that was published in (IN)SECURE Issue 17. Soon after Issue 17 went live, I also took note of an excellent academic paper specific to the topic of open redirect vulnerabilities; Shue, Kalafut and Gupta's Exploitable Redirects on the Web: Identification, Prevalence, and Defense. Complete with these two papers as references, as well as two current CVE identifiers for popular web applications suffering from open redirect vulnerabilities (discovered by yours truly), CVE-2008-2052 & 2951, CWE-601: URL Redirection to Untrusted Site (aka 'Open Redirect') is now current and complete.
As open redirects are undoubtedly one of my biggest pet peeves, I am pleased to no end. Hopefully CWE-601 will help drive more application vendors and site operators to put an end to this easily mitigated vulnerability.
CWE:
"International in scope and free for public use, CWE™ provides a unified, measurable set of software weaknesses that is enabling more effective discussion, description, selection, and use of software security tools and services that can find these weaknesses in source code and operational systems as well as better understanding and management of software weaknesses related to architecture and design."
del.icio.us | digg | Submit to Slashdot
Friday, October 10, 2008
Expanding Response: Deeper Analysis for Incident Handlers
To achieve my GCIH Gold, I recently completed a paper called Expanding Response: Deeper Analysis for Incident Handlers, now available in the SANS Reading Room. The premise was to further expand on the topics discussed in my Malware analysis tools post. This paper includes tools discussed at various times in my toolsmith column in the ISSA Journal, and includes details on Argus, HeX, NSM-Console, and NetworkMiner.
Abstract:
"The perspective embraced for this discussion is that of an analyst who is working a process to determine the exact nature of malicious software on his network. He is in receipt of the above mentioned .exe and .pcap files and seeks to further his understanding with the use of less typical tools. She begins the process with the network capture, and then takes a closer look at the binary to see what can be learned and what the impacts of an outbreak on her network might be."
del.icio.us | digg | Submit to Slashdot
Abstract:
"The perspective embraced for this discussion is that of an analyst who is working a process to determine the exact nature of malicious software on his network. He is in receipt of the above mentioned .exe and .pcap files and seeks to further his understanding with the use of less typical tools. She begins the process with the network capture, and then takes a closer look at the binary to see what can be learned and what the impacts of an outbreak on her network might be."
del.icio.us | digg | Submit to Slashdot
Tuesday, October 07, 2008
The McAfee Secure Standard: Sort Of
I need your help.
I am in receipt of the McAfee Secure Standard, drafted to transparently describe the McAfee Secure service, as promised during my meeting with Joe Pierini and Kirk Lawrence of McAfee some weeks ago. I admit my attitude has soured since last I discussed it here, as the Standard is not yet ready for public release (I last said 2-3 weeks and that was five weeks ago), but bear with me. I can't publish exact quotes from the Standard, as I've promised not to, but let me give you insight on the upside, then the downside.
The upside includes all the transparency we'd hoped for. You'll read the McAfee Secure Standard and know exactly where they stand with regard as to what can be expected of the McAfee Secure Service. My discussions with Joe Pierini have been productive and respectful; he means well, and I believe he will try to drive the greater McAfee leadership to officially incorporate suggestions made in this blog.
I have even had the pleasure of reading a Researcher/Finder Policy that very succinctly describes what researchers can expect when they submit vulnerabilities found in McAfee Secure sites. That's all good stuff and to be applauded.
Now for the downside.
The McAfee Secure Standard will draw a clear distinction between "enterprise" customers and all the Ma & Pa websites who have so loved McAfee Secure / ScanAlert Hacker Safe for conversions.
The most glaring and painful distinction for me is this. While enterprise customers will have a clearly defined time line in which to remediate script injection vulnerabilities like XSS and open redirects, before losing their McAfee Secure badge, the Ma & Pa sites will have absolutely no requirement to fix their XSS issues. XSS vulnerabilities and the McAfee Secure badge will remain consistent on all those sites that care more about "convincing" their customers that they're secure with a McAfee Secure badge; a badge that, by its own pending standard, will contradict what we know to be truly secure.
My views are clear. I have made every effort to convince McAfee that this stance is counter intuitive to good web application security standards. I believe that, in their own way, they are listening. So here's your chance.
1) Is transparency enough?
2) Is holding only enterprise customers accountable acceptable?
3) Should ALL McAfee Secure customers be expected to fix their vulnerabilities, even if on different timelines?
4) What else do you want McAfee to hear, in the form of constructive feedback only?
I will publish all well written, thoughtful comments here. Let's keep it positive and see if we can help convince McAfee that script injection vulnerabilities and McAfee Secure can't exist in the same physical space. Like matter and anti-matter. ;-)
The floor is yours...
del.icio.us | digg | Submit to Slashdot
I am in receipt of the McAfee Secure Standard, drafted to transparently describe the McAfee Secure service, as promised during my meeting with Joe Pierini and Kirk Lawrence of McAfee some weeks ago. I admit my attitude has soured since last I discussed it here, as the Standard is not yet ready for public release (I last said 2-3 weeks and that was five weeks ago), but bear with me. I can't publish exact quotes from the Standard, as I've promised not to, but let me give you insight on the upside, then the downside.
The upside includes all the transparency we'd hoped for. You'll read the McAfee Secure Standard and know exactly where they stand with regard as to what can be expected of the McAfee Secure Service. My discussions with Joe Pierini have been productive and respectful; he means well, and I believe he will try to drive the greater McAfee leadership to officially incorporate suggestions made in this blog.
I have even had the pleasure of reading a Researcher/Finder Policy that very succinctly describes what researchers can expect when they submit vulnerabilities found in McAfee Secure sites. That's all good stuff and to be applauded.
Now for the downside.
The McAfee Secure Standard will draw a clear distinction between "enterprise" customers and all the Ma & Pa websites who have so loved McAfee Secure / ScanAlert Hacker Safe for conversions.
The most glaring and painful distinction for me is this. While enterprise customers will have a clearly defined time line in which to remediate script injection vulnerabilities like XSS and open redirects, before losing their McAfee Secure badge, the Ma & Pa sites will have absolutely no requirement to fix their XSS issues. XSS vulnerabilities and the McAfee Secure badge will remain consistent on all those sites that care more about "convincing" their customers that they're secure with a McAfee Secure badge; a badge that, by its own pending standard, will contradict what we know to be truly secure.
My views are clear. I have made every effort to convince McAfee that this stance is counter intuitive to good web application security standards. I believe that, in their own way, they are listening. So here's your chance.
1) Is transparency enough?
2) Is holding only enterprise customers accountable acceptable?
3) Should ALL McAfee Secure customers be expected to fix their vulnerabilities, even if on different timelines?
4) What else do you want McAfee to hear, in the form of constructive feedback only?
I will publish all well written, thoughtful comments here. Let's keep it positive and see if we can help convince McAfee that script injection vulnerabilities and McAfee Secure can't exist in the same physical space. Like matter and anti-matter. ;-)
The floor is yours...
del.icio.us | digg | Submit to Slashdot
Wednesday, October 01, 2008
FileAdvisor: software file search engine
Troy Larson sent me a heads up on Bit9's FileAdvisor, a service they describe as "a comprehensive catalog of executables, drivers, and patches found in commercial Windows applications and software packages. Malware and other unauthorized software that affects Windows computers is also indexed."
I immediately checked the FileAdvisor db for malware results as well non-Windows binaries and was pleasantly surprised with immediate and comprehensive results. You do have to register, but I was further impressed with the fact that they offered the option for a short or full registration.
This appears to be worthy of a bookmark in your incident handler/malware researcher/forensic investigator toolkit.
del.icio.us | digg
I immediately checked the FileAdvisor db for malware results as well non-Windows binaries and was pleasantly surprised with immediate and comprehensive results. You do have to register, but I was further impressed with the fact that they offered the option for a short or full registration.
This appears to be worthy of a bookmark in your incident handler/malware researcher/forensic investigator toolkit.
del.icio.us | digg
Friday, September 26, 2008
Hype Alert: Internet Shopping Carts Are Secure
My blog reader fed me a nugget today that set off my hype monitor, specifically a post entitled Internet Shopping Carts are Secure.
OMG...really?
To be fair, I realize the author is speaking from the eCommerce perspective, rather than that of an information security practitioner, but here's where the trouble begins:
"Shopping cart service providers have developed secure ecommerce shopping cart solutions for any business owner looking to enhance their current online store, or create a new one. Some ecommerce shopping cart solution providers are even receiving PABP (Payment Application Best Practice) certification which supports PCI compliance requirements for all businesses accepting credit card payments online."
This may be true in part, but it is by no means an all-inclusive claim. Shopping carts continue to be sieve-like, even when apparently reviewed per PCI standards.
Allow me to elaborate.
We'll kick off our hype eliminating effort with a simple Google dork: inurl:"cart.cfm" (picking on ColdFusion again, but man, they make it easy)
GM Parts Direct: Your Shopping Cart jumped right out at me for a number of reasons.
First, I sensed XSS vulns lurking like a Geiger counter senses radiation. Sound effect for edification. :-)
Second, the page contained one of the growing number of aforementioned conversion-driving website security seals.
Tick, tick, click...the Gieger counter is getting louder.
Trustwave claims that the site operator "is enrolled in Trustwave's Trusted Commerce™ program to validate compliance with the Payment Card Industry Data Security Standard (PCI DSS) mandated by all the major credit card associations including: American Express, Diners Club, Discover, JCB, MasterCard Worldwide, Visa, Inc. and Visa Europe."
Methinks that Trustwave's Trusted Commerce program is missing a few fundamental security checks. Remember, XSS in PCI regulated sites, according to the PCI DSS, indicates that a site is not compliant (see section 6.5.4) if vulnerable to XSS.
Uh-oh.
All it takes is a fake login page, as opposed to our friends at XSSED.com, and...well, you get the point.
Simply, this is one of an endless number of shopping cart not secure, and not PCI compliant. For shame. You need only browse the Holisticinfosec.org Advisories page to find multiple ecommerce platforms and shopping carts that are missing the mark. Trust me, these are a fraction of the problem.
ecommerce<>security
ecommerce<>SDL
ecommerce<>PCI
website security seal<>security
russ=frustrated
Sigh.
del.icio.us | digg
OMG...really?
To be fair, I realize the author is speaking from the eCommerce perspective, rather than that of an information security practitioner, but here's where the trouble begins:
"Shopping cart service providers have developed secure ecommerce shopping cart solutions for any business owner looking to enhance their current online store, or create a new one. Some ecommerce shopping cart solution providers are even receiving PABP (Payment Application Best Practice) certification which supports PCI compliance requirements for all businesses accepting credit card payments online."
This may be true in part, but it is by no means an all-inclusive claim. Shopping carts continue to be sieve-like, even when apparently reviewed per PCI standards.
Allow me to elaborate.
We'll kick off our hype eliminating effort with a simple Google dork: inurl:"cart.cfm" (picking on ColdFusion again, but man, they make it easy)
GM Parts Direct: Your Shopping Cart jumped right out at me for a number of reasons.
First, I sensed XSS vulns lurking like a Geiger counter senses radiation. Sound effect for edification. :-)
Second, the page contained one of the growing number of aforementioned conversion-driving website security seals.
Tick, tick, click...the Gieger counter is getting louder.
Trustwave claims that the site operator "is enrolled in Trustwave's Trusted Commerce™ program to validate compliance with the Payment Card Industry Data Security Standard (PCI DSS) mandated by all the major credit card associations including: American Express, Diners Club, Discover, JCB, MasterCard Worldwide, Visa, Inc. and Visa Europe."
Methinks that Trustwave's Trusted Commerce program is missing a few fundamental security checks. Remember, XSS in PCI regulated sites, according to the PCI DSS, indicates that a site is not compliant (see section 6.5.4) if vulnerable to XSS.
Uh-oh.
All it takes is a fake login page, as opposed to our friends at XSSED.com, and...well, you get the point.
Simply, this is one of an endless number of shopping cart not secure, and not PCI compliant. For shame. You need only browse the Holisticinfosec.org Advisories page to find multiple ecommerce platforms and shopping carts that are missing the mark. Trust me, these are a fraction of the problem.
ecommerce<>security
ecommerce<>SDL
ecommerce<>PCI
website security seal<>security
russ=frustrated
Sigh.
del.icio.us | digg
Sunday, September 21, 2008
XSF & XSS: Double your pleasure, double your fun
If you've read this blog, or those of my peers, you're likely quite familiar with cross-site scripting, and the problems associated with open redirect vulnerabilities. A vulnerability you may be less familiar with is cross-site framing, which largely couples the best of both above-mentioned vulnerabilities.
What then, if there's a cross-site framing vulnerability coupled with cross-site scripting in the content offered by the frame? All sorts of problems come to mind: phishing, malware, credential theft; all arguably twice removed from the attacker's source, tucked away in the context of two victim sites.
First, I'll discuss the original XSS issue that led to this finding.
Recently, I was investigating a flawed parameter in Openhire, a career posting vendor used by major companies like Crate&Barrel, Eileen Fisher, Enterprise, Benjamin Moore, Scottrade, and Getty Images.
Most of these sites simply link to the Openhire offering that hosts job postings on their behalf which, in turn, has been crafted to look like the referring site.
As an example, here's Scottrade's employment page hosted by Openhire.
http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?version=1&company_id=15624
Standard stuff, looks nicely like the Scottrade site, so everything's cool, right?
Wrong? What if someone hosting a service on your behalf suffers a security gap?
You're only as strong as your weakest link!
Here's the posting for an Application Security Engineer (funny, eh?) at Scottrade as hosted on their behalf by Openhire:
http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=976367&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters%3B%3B%3BInformation%20Technology%3B%3B%3BSecurity&startflag=3&CFID=66851845&CFTOKEN=29a95-d12594d4-47d9-49e8-9067-1091bdf68e80
Now here the same job posting spewing massive cookie data:
http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3
Screen shot offered below, as the code above will likely be repaired very soon by Openhire. I notified them this past Thursday.
It's bad enough when there's an application security hole in code someone else is hosting on your behalf, but what if your method of displaying said code is also at risk? Enter the Getty Images Jobs page.
http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=careeropps&startflag=0&company_id=15531&version=2&CFID=12265212&CFTOKEN=60213778
Watch what happens when you pull the Openhire code. Can you say self-replicating frame loop from hell (in Firefox)? Trust me your browser will crash if you leave this running too long. This will likely be fixed soon, so if the URL doesn't work, the screen shot exemplifies the issue.
http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html
What if, instead of Openhire's Getty Images page, or nothing at all (which obviously creates its own issue), we drop in an arbitrary URL?
Yep, you guessed it.
http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://www.xssed.com/news/26/Cross-site_framed/
Now, bringing it all home for double the pleasure, double the fun, what if we coupled the original Openhire cross-site scripting vuln with Getty Images' cross-site frame vuln?
It hurts twice as much, in my book.
http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3
The lessons learned:
1) Ensure your partners are writing secure code on you behalf.
2) Ensure that the code you utilize to incorporate said partner's code is also well written. ;-)
Double the headache, double the dumb.
del.icio.us | digg
What then, if there's a cross-site framing vulnerability coupled with cross-site scripting in the content offered by the frame? All sorts of problems come to mind: phishing, malware, credential theft; all arguably twice removed from the attacker's source, tucked away in the context of two victim sites.
First, I'll discuss the original XSS issue that led to this finding.
Recently, I was investigating a flawed parameter in Openhire, a career posting vendor used by major companies like Crate&Barrel, Eileen Fisher, Enterprise, Benjamin Moore, Scottrade, and Getty Images.
Most of these sites simply link to the Openhire offering that hosts job postings on their behalf which, in turn, has been crafted to look like the referring site.
As an example, here's Scottrade's employment page hosted by Openhire.
http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?version=1&company_id=15624
Standard stuff, looks nicely like the Scottrade site, so everything's cool, right?
Wrong? What if someone hosting a service on your behalf suffers a security gap?
You're only as strong as your weakest link!
Here's the posting for an Application Security Engineer (funny, eh?) at Scottrade as hosted on their behalf by Openhire:
http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=976367&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters%3B%3B%3BInformation%20Technology%3B%3B%3BSecurity&startflag=3&CFID=66851845&CFTOKEN=29a95-d12594d4-47d9-49e8-9067-1091bdf68e80
Now here the same job posting spewing massive cookie data:
http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3
Screen shot offered below, as the code above will likely be repaired very soon by Openhire. I notified them this past Thursday.
It's bad enough when there's an application security hole in code someone else is hosting on your behalf, but what if your method of displaying said code is also at risk? Enter the Getty Images Jobs page.
http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=careeropps&startflag=0&company_id=15531&version=2&CFID=12265212&CFTOKEN=60213778
Watch what happens when you pull the Openhire code. Can you say self-replicating frame loop from hell (in Firefox)? Trust me your browser will crash if you leave this running too long. This will likely be fixed soon, so if the URL doesn't work, the screen shot exemplifies the issue.
http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html
What if, instead of Openhire's Getty Images page, or nothing at all (which obviously creates its own issue), we drop in an arbitrary URL?
Yep, you guessed it.
http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://www.xssed.com/news/26/Cross-site_framed/
Now, bringing it all home for double the pleasure, double the fun, what if we coupled the original Openhire cross-site scripting vuln with Getty Images' cross-site frame vuln?
It hurts twice as much, in my book.
http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3
The lessons learned:
1) Ensure your partners are writing secure code on you behalf.
2) Ensure that the code you utilize to incorporate said partner's code is also well written. ;-)
Double the headache, double the dumb.
del.icio.us | digg
Monday, September 15, 2008
EstDomains & Intercage: A Perfect Couple in Crime
If you track malware issues as readily as I do, you're likely aware of the failings of clownpacks like EstDomains and their hosting buddies Atrivo/Intercage. You need only follow Sunbelt's take on the topic, or search Emergingthreats to come up to speed.
Yesterday, EstDomains posted the most inept, ridiculous response ever issued to the endless and worthy criticism, largely leveled by Brian Krebs at the Washington Post.
Not only can't these morons from EstDomains write, they're either so deeply clueless or flagrantly malicious (likely both), it's beyond laughable. This section sums it up best:
"The company also has a reliable ally in its battle against malware in a face of Intercage, Inc which provides company with the hosting services of the highest quality. But the outstanding performance of hosting services is not the sole reason why EstDomains, Inc appreciates this partnership so greatly. Intercage, Inc generously provides EstDomains, Inc specialists with reports regarding discovered malware vehicles. As the main database for additional domain name management services is located in Intercage Data Center, EstDomains, Inc has the perfect opportunity to get notifications of the slightest mark of malware presence in the shortest time and take measures in advance."
What? Really?
Again, aside from the absolute butchery of the language, did they just say "The company also has a reliable ally in its battle against malware in a face of Intercage, Inc which provides company with the hosting services of the highest quality."? SIGH...yes, they did.
Allow me to exemplify just how ridiculous a claim that is.
Following is content from a packet capture I took during a recent Storm worm analysis.
Using the ip2asn module included in NSM-console availabe in HeX, we find:
27595 | 216.255.189.211 | INTERCAGE - InterCage, Inc.
Using Etherape, also included in HeX, we see:
Using Eric Hjelmvik's NetworkMiner, we see:
See the recurring theme? Intercage, EstDomain's "reliable ally in its battle against malware".
Nice work, guys...keep it up.
I'm submitting this to The Daily WTF as we speak.
del.icio.us | digg
Yesterday, EstDomains posted the most inept, ridiculous response ever issued to the endless and worthy criticism, largely leveled by Brian Krebs at the Washington Post.
Not only can't these morons from EstDomains write, they're either so deeply clueless or flagrantly malicious (likely both), it's beyond laughable. This section sums it up best:
"The company also has a reliable ally in its battle against malware in a face of Intercage, Inc which provides company with the hosting services of the highest quality. But the outstanding performance of hosting services is not the sole reason why EstDomains, Inc appreciates this partnership so greatly. Intercage, Inc generously provides EstDomains, Inc specialists with reports regarding discovered malware vehicles. As the main database for additional domain name management services is located in Intercage Data Center, EstDomains, Inc has the perfect opportunity to get notifications of the slightest mark of malware presence in the shortest time and take measures in advance."
What? Really?
Again, aside from the absolute butchery of the language, did they just say "The company also has a reliable ally in its battle against malware in a face of Intercage, Inc which provides company with the hosting services of the highest quality."? SIGH...yes, they did.
Allow me to exemplify just how ridiculous a claim that is.
Following is content from a packet capture I took during a recent Storm worm analysis.
Using the ip2asn module included in NSM-console availabe in HeX, we find:
27595 | 216.255.189.211 | INTERCAGE - InterCage, Inc.
Using Etherape, also included in HeX, we see:
Using Eric Hjelmvik's NetworkMiner, we see:
See the recurring theme? Intercage, EstDomain's "reliable ally in its battle against malware".
Nice work, guys...keep it up.
I'm submitting this to The Daily WTF as we speak.
del.icio.us | digg
Tuesday, September 02, 2008
XSS fortune cookie
Forgive me in advance for an extremely bad joke, if you can even call it that, but I just can't help it.
Here's how to get an XSS fortune cookie:
1) Ask the mighty Google oracle who might be able to tell you your fortune.
http://www.google.com/search?hl=en&q=tell+my+fortune&btnG=Search&lr=lang_en
2) Select one of the sponsored links; in this case I chose SpritualExperts.com.
3) Pick a variable. I settled for banid.
4) Ask it if it has a cookie for you.
http://www.spiritualexperts.com/psychic_reading/psychic_reading.asp?banid=%22%3E%3CSCRIPT%3Ealert%28document%2Ecookie%29%3C%2FSCRIPT%3E
Voila...an XSS fortune cookie. Sorry. Really, I am.
The webmaster has been advised...play nice.
Screenshot for after they fix the issue.
del.icio.us | digg
Here's how to get an XSS fortune cookie:
1) Ask the mighty Google oracle who might be able to tell you your fortune.
http://www.google.com/search?hl=en&q=tell+my+fortune&btnG=Search&lr=lang_en
2) Select one of the sponsored links; in this case I chose SpritualExperts.com.
3) Pick a variable. I settled for banid.
4) Ask it if it has a cookie for you.
http://www.spiritualexperts.com/psychic_reading/psychic_reading.asp?banid=%22%3E%3CSCRIPT%3Ealert%28document%2Ecookie%29%3C%2FSCRIPT%3E
Voila...an XSS fortune cookie. Sorry. Really, I am.
The webmaster has been advised...play nice.
Screenshot for after they fix the issue.
del.icio.us | digg
Saturday, August 30, 2008
McIrony: An unexpected response from McAfee
Irony: incongruity between what might be expected and what actually occurs.
Right before Black Hat, I put together what I believed was a pretty strong arguement against McAfee Secure - Hacker Safe, at a level heretofore unexplored. I believe it was more damaging than anything I've said to date, and as such, presented potential risk for me. So I ran it by some friends before publishing it. Then a most extraordinary thing happened. I had a long chat with Nate McFeters, who described an awakening he'd recently experienced. He shared with me the belief that a better approach to potentially negative security research might be to try to create a positive outcome, and worry less about press cycles or exposure, the 15 minutes of fame if you will. He pointed to people like Mark Dowd as an example of people who conduct crushingly good research, and steer clear of the petty, ego driven bulls**t.
There I sat, repose like the thinking man, frozen for minutes. "Nate", I said, "I think you're right."
What do I aspire to as an information security professional; more readership or street cred than the next guy, or the respect of my peers for contributing to the greater good? Attention, press cycles, 15 minutes...it all has its allure, trust me on this.
But at the end of the day, I really do want to contribute to the greater good.
So I did something different. I sent my findings to McAfee and offered them an opportunity to respond, rather than publish first, ask questions later.
Here's the real kicker.
They responded.
I had a three hour lunch this past Thursday with two gentlemen from McAfee, who flew up from the Bay Area to Seattle to have a face to face with me. This, all by itself, speaks volumes to me. In addition to meeting with Kirk Lawrence, the new Director of Product Management for McAfee Secure, there I sat with, of all people, Joe Pierini, the very guy who has suffered more than his share of abuse, up to and including the Pwnie. As I have been a direct contributor and participant in heckling Joe, you can imagine our meeting could have been uncomfortable. It was not.
I have had expectations of McAfee and Scan Alert that to date have not been met, or my (your) perception has been that they have not been met.
This meeting was designed as an opportunity to voice some of these expectations, and see if McAfee, in turn, believed there was any merit to them.
Surprisingly, at least as spoken, we weren't all that far apart.
While, as a naive idealist, I believe that security should come before conversions, I am also grounded enough of a realize that the most attainable goal can be a marriage of both. This premise frames my expectations of McAfee.
Can they not be more of a "thought leader" for all the Ma & Pa websites who rely on McAfee Secure, first for a higher conversion rate, then security?
Can they not hold merchants to a higher standard, without alienating them and losing business?
Can they not embrace the security research community in a fashion that McAfee, the security community, the merchants, and consumers can all benefit from?
Can they not be more transparent in their approach, providing more details and feedback about their methods, their findings, and their vision?
I know McAfee Secure - Hacker Safe scans can find vulnerabilities.
I know they report the vulnerabilities to merchants.
What happens thereafter is where things begin to break down.
Can the scan engine be improved to find more vulns? Sure. That's really not that big a deal; technology can always be improved.
But, regarding holding merchants to a higher standard; therein is the whole point of this debate.
Anyone can throw a badge on a site.
But what happens when the site proves vulnerable is the key. I'll be candid here: I don't give a damn about the merchant at that point; it's the consumer who is at risk and needs something better from McAfee and their peers.
So, here begins a different approach. I know that making changes at a company the size of McAfee can be likened to the three miles it takes to turn around an aircraft carrier. I'm willing to work with them, and allow for a positive outcome.
I have been told that, in two or three weeks, we can expect a published standard, that clearly defines exactly what the McAfee Secure product offering adheres to, inclusive of their expectations for merchant remediation timelines, potential badge downgrades for unresolved vulnerabilities, and hopefully even a more clear stance on XSS.
I have been told that I will have the opportunity to discuss this standard, and invite feedback. Any standard is better than no standard.
I have also been told that this is just the beginning of changes that will lead to more of what I have hoped for in my expectations, over the next 6 months or so.
I am hopeful that we can take McAfee at their word, and even if slowly, see a positive outcome.
del.icio.us | digg
Right before Black Hat, I put together what I believed was a pretty strong arguement against McAfee Secure - Hacker Safe, at a level heretofore unexplored. I believe it was more damaging than anything I've said to date, and as such, presented potential risk for me. So I ran it by some friends before publishing it. Then a most extraordinary thing happened. I had a long chat with Nate McFeters, who described an awakening he'd recently experienced. He shared with me the belief that a better approach to potentially negative security research might be to try to create a positive outcome, and worry less about press cycles or exposure, the 15 minutes of fame if you will. He pointed to people like Mark Dowd as an example of people who conduct crushingly good research, and steer clear of the petty, ego driven bulls**t.
There I sat, repose like the thinking man, frozen for minutes. "Nate", I said, "I think you're right."
What do I aspire to as an information security professional; more readership or street cred than the next guy, or the respect of my peers for contributing to the greater good? Attention, press cycles, 15 minutes...it all has its allure, trust me on this.
But at the end of the day, I really do want to contribute to the greater good.
So I did something different. I sent my findings to McAfee and offered them an opportunity to respond, rather than publish first, ask questions later.
Here's the real kicker.
They responded.
I had a three hour lunch this past Thursday with two gentlemen from McAfee, who flew up from the Bay Area to Seattle to have a face to face with me. This, all by itself, speaks volumes to me. In addition to meeting with Kirk Lawrence, the new Director of Product Management for McAfee Secure, there I sat with, of all people, Joe Pierini, the very guy who has suffered more than his share of abuse, up to and including the Pwnie. As I have been a direct contributor and participant in heckling Joe, you can imagine our meeting could have been uncomfortable. It was not.
I have had expectations of McAfee and Scan Alert that to date have not been met, or my (your) perception has been that they have not been met.
This meeting was designed as an opportunity to voice some of these expectations, and see if McAfee, in turn, believed there was any merit to them.
Surprisingly, at least as spoken, we weren't all that far apart.
While, as a naive idealist, I believe that security should come before conversions, I am also grounded enough of a realize that the most attainable goal can be a marriage of both. This premise frames my expectations of McAfee.
Can they not be more of a "thought leader" for all the Ma & Pa websites who rely on McAfee Secure, first for a higher conversion rate, then security?
Can they not hold merchants to a higher standard, without alienating them and losing business?
Can they not embrace the security research community in a fashion that McAfee, the security community, the merchants, and consumers can all benefit from?
Can they not be more transparent in their approach, providing more details and feedback about their methods, their findings, and their vision?
I know McAfee Secure - Hacker Safe scans can find vulnerabilities.
I know they report the vulnerabilities to merchants.
What happens thereafter is where things begin to break down.
Can the scan engine be improved to find more vulns? Sure. That's really not that big a deal; technology can always be improved.
But, regarding holding merchants to a higher standard; therein is the whole point of this debate.
Anyone can throw a badge on a site.
But what happens when the site proves vulnerable is the key. I'll be candid here: I don't give a damn about the merchant at that point; it's the consumer who is at risk and needs something better from McAfee and their peers.
So, here begins a different approach. I know that making changes at a company the size of McAfee can be likened to the three miles it takes to turn around an aircraft carrier. I'm willing to work with them, and allow for a positive outcome.
I have been told that, in two or three weeks, we can expect a published standard, that clearly defines exactly what the McAfee Secure product offering adheres to, inclusive of their expectations for merchant remediation timelines, potential badge downgrades for unresolved vulnerabilities, and hopefully even a more clear stance on XSS.
I have been told that I will have the opportunity to discuss this standard, and invite feedback. Any standard is better than no standard.
I have also been told that this is just the beginning of changes that will lead to more of what I have hoped for in my expectations, over the next 6 months or so.
I am hopeful that we can take McAfee at their word, and even if slowly, see a positive outcome.
del.icio.us | digg
Subscribe to:
Posts (Atom)
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ... -
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
When, in October and November 's toolsmith posts, I redefined DFIR under the premise of D eeper F unctionality for I nvestigators in R ...
