Incident Response

Amex Developers Leave Debug Tool Open to the World, Including Attackers

Developers Leave Debug Tool Open for The World to Use, Including Attackers

Developers from American Express have made somewhat of a big mistake recently, leaving an administration panel for Web site debugging wide open for anyone to access, providing a potential tool and avenue for attackers to target AMEX customers. (Update: Amex appears to finally have closed access to the admin panel within the past hour, as of 11:15AM EST on Oct 6.)

<p style="text-align: center;"><strong><span>Developers Leave Debug Tool Open for The World to Use, Including Attackers</span></strong></p><p style="text-align: left;">Developers from <strong>American Express</strong> have made somewhat of a big mistake recently, leaving an administration panel for Web site debugging wide open for anyone to access, providing a potential tool and avenue for attackers to target AMEX customers. <em>(Update: Amex appears to finally have closed access to the admin panel within the past hour, as of 11:15AM EST on Oct 6.)</em></p>

Developers Leave Debug Tool Open for The World to Use, Including Attackers

Developers from American Express have made somewhat of a big mistake recently, leaving an administration panel for Web site debugging wide open for anyone to access, providing a potential tool and avenue for attackers to target AMEX customers. (Update: Amex appears to finally have closed access to the admin panel within the past hour, as of 11:15AM EST on Oct 6.)

According to Niklas Femerstrand, a developer who discovered the security gap and tipped SecurityWeek about the incident, “A little ‘oops’ that one of the developers left behind unprotected breaches many parts of American Express’ security in one hit. One might say that this mistake is a multikill.”

This oversight creates an opportunity for attackers to easily conduct XSS attacks, potentially creating a significant risk to customers. “Through cookie stealing, an attacker that is regularly sending phishing emails could instead send legitimate URLs to the AMEX website and harvest user accounts as the victims open the link,” Femerstrand told SecurityWeek via email.

“An attacker could inject a cookie stealer combined with jQuery’s .hide() and harvest cookies which can, ironically enough, be exploited by using the admin panel provided by sloppy American Express developers, Femerstrand wrote in a blog post outlining his discoveries.

Femerstrand illustrated a simple proof of concept that showed an XSS vulnerability in action.  

Because attackers could actually direct users to the legitimate AmericanExpress.com domain, anti-phishing technology is much less likely to identify phishing attacks.

The tool also provides access to unpublished content, something that could open the doors for competitors and customers to catch a glimpse of what may be coming to the site ahead of time.

Advertisement. Scroll to continue reading.

In addition to the site debug panel being exposed, the debug environment for Adobe Pulse has also been left open. Adobe Pulse is part of Omniture, the web analytics software that Adobe acquired.

What’s disturbing is that Femerstrand reached out to American Express over a day ago to let them know about the issue, yet the debugging environment is still wide open to the public as of the time of publishing this article. “When somebody voluntarily contacts a company and repeatedly mentions words like “security vulnerability” and “hacker” one would think the company would act as quickly as possible,” Femerstrand commented.

Femerstrand contacted American Express via Twitter on October 4th, tweeting to the company about the security hole. “@AmericanExpress Who can I contact regarding security vulnerabilities in your system? I’m not available through phone, physical mail or fax,” he tweeted.

“Understandably developers get sloppy around security implementations in debug features. Ironically, this becomes a direct threat in a case where a company’s developers don’t protect their debugging tools from the public. The debugging tool is vulnerable to XSS and it quickly becomes an issue when the debugging tools are called through unprotected GET parameters,” Femerstrand said.

Incidents like this show the need to instill security into organizations from the top down, as far down as customer service reps. This incident should have been escalated immediately and the exposure should have been closed off within hours, not days. 

It’s not clear how long this tool has been left open. We’ve contacted American Express for comment and will update accordingly when we recieve a response.

Femerstrand said he discovered the security issue accidentally. “A couple of weeks ago I ordered one of their cards and they sent me snail mail asking for completion through fax,” he told SecurityWeek. “Since I don’t own a fax machine and don’t know anyone that does, as far as I know, I browsed through their site looking for an e-mail address that I could send a PDF to. I looked at their robots.txt to see if I could find a sitemap as I seemed to get stuck in infinite loops of FAQ lists rather than contact forms.”

 

Related Column: Lessons from the Trenches on Implementing a Secure Development Lifecycle

Related Column: Implementing a Secure Development Lifecycle: The Importance of Executive Support

 

Update: An American Express spokesperson contacted SecurityWeek on Thursday afernoon in response to our inquiry. “We learned this morning that an internal test page created to update promotional offers was temporarily accessible on our US website,” the spokesperson said. “The page did not contain cardmember information such as card number, name or address. The page in question has been taken down. We are not aware of any information at this time that this vulnerability was used for malicious purposes but we are continuing to investigate.”

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version