Archive for October, 2011

Hushmail and the security misunderstanding

Thursday, October 20th, 2011

Let’s talk a bit about a very common topic which is widely discussed whenever secure communication is brought up: encrypted emails. People often wonder what the best way to talk securely is through email. Hushmail is a popular service, if you haven’t heard of it then look it up. The problem with Hushmail is that people believe that it’s secure. Searching for them on Twitter brings up tweets written by groups such as Anonymous and the recent Occupy Wall Street inspired subcultures. The problem with most Hushmail users is that they believe that they are secure, either because they have no idea of what they’re relying on or because they didn’t read what they’re told. Hushmail has, like the marketing genious it is, after all, never really claimed to be secure. At least not if you dig around a bit and actually read what they’re saying. You don’t have to be a rocket scientist to see a monetary interest in not printing such information directly in your face, but instead build a security facade with keyhole images all over the place. The problem is that people haven’t done their homework.

As we all know, and South Park beautifully illustrated in its “Human Centipad” episode, users don’t read user agreements. Ever. The time has come to do so. A snippet from Hushmail’s privacy policy reveals that:

“Hush restricts user information and has protocols that allow only specific employees to have access to the user database itself.”

Man, I love buzzwords… Continuing: “Hushmail does not put you above the law”:

“We are committed to the privacy of our users, and will absolutely not release user data without an order that is legally enforceable under the laws of British Columbia, Canada, which is the jurisdiction where our servers are located. In addition, we require that any such order refer specifically to the account for which data is required.

[snip]

That means that there is no guarantee that we will not be compelled, under an order enforceable under the laws of British Columbia, Canada, to treat a user named in an order differently, and compromise that user’s privacy.”

A trip down Hushmail’s memory lane reveals that it handed over 12 CDs of decrypted emails to the US authorities, but that’s not really worth going further into. Let’s just conclude that it’s entirely possible.

The moral of the story is that you’re trusting a service with your private communication which promises to not release any data to governments unless they explicitly ask for it through Canadian law as proxy. The same governments that already passed mass surveillance laws which are probably at least a tad reason of why you want to secure your digital communication to begin with. For all we know, they might already have politely asked Hushmail and similar services to install backdoors which they could use whenever. You lose, but please don’t forget to insert all your coins and play again.

robots.txt scanner proof of concept

Friday, October 7th, 2011

Due to the recent scandal of American Express listing their publicly available admin debug panel in their robots.txt file, here’s a sloppy proof of concept that can be used to find similar security issues.

Remember:

  • robots can ignore your /robots.txt. Especially malware robots that scan the web for security vulnerabilities, and email address harvesters used by spammers will pay no attention.
  • the /robots.txt file is a publicly available file. Anyone can see what sections of your server you don’t want robots to use.

http://www.robotstxt.org/robotstxt.html

Either way, a location such as /us/admin/ would be in any wordlist of interesting locations and you should always protect sensitive parts of your system with authorization requirements.

<?php
/**
 * Quick hack to determine HTTP status codes of locations listed in a host's
 * robots.txt file.
 * Author: Niklas Femerstrand, qnrq.se, 2011
 * License: http://sam.zoy.org/wtfpl/
 */

// Determine HTTP status code of $file on $host
function httpstatus($host, $file) {
   $fp = fsockopen($host,80,$errno,$errstr,30);
   $out = "GET /$file HTTP/1.1\r\n".
          "Host: $host\r\n".
          "Connection: Close\r\n\r\n";
   fwrite($fp,$out);
   $response = fgets($fp);
   return chop($response);
}

if (!$argv[1])
	die("usage: $ php robotscan.php <host>\n   eg: $ php robotscan.php www.google.com\n");

$host = preg_replace("/\/$/", "", $argv[1]);
$target_url = $argv[1] . "/robots.txt";

$filters = array("/[ ]?Allow:[ ]?/",
                 "/[ ]?Disallow:[ ]?/",
                 "/[ ]?Sitemap:.*/",
                 "/[ ]?Request-rate:.*/",
                 "/[ ]?Crawl-delay:.*/",
                 "/[ ]?Visit-time:.*/",
                 "/.*[$*].*/",
                 "/User-agent: .*/",
                 "/#+.*/");

echo "[+] Getting robots.txt content\n";

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "{$argv[1]}/robots.txt");
curl_setopt($ch, CURLOPT_RETURNTRANSFER,true);
$robots = curl_exec($ch);

if(!$robots)
{
	$httpStatus = httpstatus($host, "robots.txt");
	if(preg_match("/200 OK/", $httpStatus))
		die("[-] robots.txt exists but seems empty\n");
	else
		die("[-] {$httpStatus}\n");
}
elseif(preg_match("/([\<])([^\>]+)*([\>])/i", $robots))
	die("[-] robots.txt is incorrectly formatted (html?)\n");
else
{
	$robots = preg_replace($filters, "", $robots);
	$robots = preg_replace("/(^[\r\n]*|[\r\n]+)[\s\t]*[\r\n]+/", "\n", $robots);
	$arr = explode("\n", $robots);

	foreach($arr as $loc)
		printf("[+] %s: %s\n", "{$host}{$loc}: ", httpstatus($host, $loc));
}

0day Full disclosure: American Express

Wednesday, October 5th, 2011

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. At least all of the companies that I’ve been in touch with regarding security issues have. This time the experience streak changed drastically. To my great surprise American Express doesn’t allow anybody to contact them. Instead, you’re sent through their ten-year-old copyright noticed website’s first line support jungle to be attacked with questions ensuring that you’re a paying customer. If you’re not then you might as well not bother, unless you feel like speaking technical advanced 0day vulnerabilities with incompetent support personnel either through Twitter direct messages or phone. They will leave you no option of contacting them in a manner that circumvents any theoretical possibility they may have of boosting sales numbers.

The only acceptable contact methods that I found on their site were telephone, fax or physical mail to some typoed country called Swerige. I figured none of them were suitable for 0day reports and decided to turn to Twitter and ask for an e-mail address or some other modern protocol.

AMEX Tweet conversation

With the pesky, but relevantly necessary, introduction out of the way: let’s focus on the concrete security disclosure. 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. On https://www.americanexpress.com/us/admin/ you’ll find the following admin panel:

The left column is a list of, what the American Express developers call “heroes”, for the current period. (Most people call them “news”.) The list is downloadable as a CSV file and the contents are completely harmless:

"ID","Status","Type","Description","Path"
"10026","Inactive","In Development","NN105 - Brand - JD Power 5 Year Win Midas","/us/heroes/10026-Brand-JDPower5thYearMidas/hero.html"
"10025","Inactive","In Development","NN135 - Brand - Vente Privee","/us/heroes/10025-Brand-VentePrivee/hero.html"
"10022","Active","Prospect & Cardmember","NM280 - Travel - MIDAS Help Is On the Way","/us/heroes/10022-Travel-HelpIsOnTheWay/hero.html"
"10021","Active","Prospect & Cardmember","NM207 - Travel - Travel Pier Sept 2011","/us/heroes/10021-Travel-TravelPierSept2011/hero.html"
"10020","Active","Prospect & Cardmember","NL986 - Brand - JD Power 5 Year Win","/us/heroes/10020-Brand-JDPower5thYear/hero.html"
"10018","Active","Prospect & Cardmember","NL872 - OPEN - Business Rewards Gold","/us/heroes/10018-OPEN-BusinessRewardsGold/hero.html"
"10014","Active","Prospect & Cardmember","Brand - AMEX Facebook Sync","/us/heroes/10014-Brand-FacebookSync/hero.html"
"10012","Active","Prospect & Cardmember","Brand - AMEX Foursquare Sync","/us/heroes/10012-Brand-FoursquareSync/hero.html"
"10002","Active","Prospect & Cardmember","Mobile - AMEX Mobile Services","/us/heroes/10002-Mobile-MobileServices/hero.html"
"10024","Active","Cardmember","NN047 - Brand - Profile and Preferences","/us/heroes/10024-Brand-ProfileandPreferences/hero.html"
"10023","Active","Cardmember (PZN Only)","NM612 - OPEN - PZN Business Rewards Gold","/us/heroes/10023-OPEN-PznBusinessRewardsGold/hero.html"
"10017","Active","Cardmember (PZN Only)","NL766 - CCSG - MIDAS Platinum Benefits","/us/heroes/10017-CCSG-PlatinumBenefits/hero.html"
"10016","Active","Cardmember (PZN Only)","NL767 - OPEN - MIDAS Platinum Benefits","/us/heroes/10016-OPEN-PlatinumBenefits/hero.html"
"10019","Inactive","Expired","Brand - 911 Tribute Movement","/us/heroes/10019-Brand-911TributeMovement/hero.html"
"10015","Inactive","Expired","Entertainment - USOPEN Total Immersion","/us/heroes/10015-Entertainment-USOPENTotalImmersion/hero.html"
"10013","Inactive","Expired","Brand - AMEX Facebook Sync","/us/heroes/10013-Brand-FacebookSync/hero.html"
"10011","Inactive","Expired","OPEN - Big Break","/us/heroes/10011-Open-SmallBusiness/hero.html"
"10010","Inactive","Expired","Rewards-MillionPointContest","/us/heroes/10010-Rewards-MillionPointContest/hero.html"
"10009","Inactive","Expired","Entertainment - US OPEN Pre-Sale","/us/heroes/10009-Entertainment-USOPENPreSale/hero.html"
"10008","Inactive","Expired","Travel - Get Your Feet Wet","/us/heroes/10008-Travel-GetYourFeetWet/hero.html"
"10007","Inactive","Expired","Membership Rewards - Social Currency","/us/heroes/10007-Rewards-SocialCurrency/hero.html"
"10006","Inactive","Expired","Mobile - Million Downloads","/us/heroes/10006-Mobile-MillionDownloads/hero.html"
"10005","Inactive","Expired","Brand - US Homepage Launch","/us/heroes/10005-Brand-USHomepageLaunch/hero.html"
"10003","Inactive","Expired","Brand - AMEX Members Project","/us/heroes/10003-Brand-MembersProject/hero.html"
"10004","Inactive","Expired","Membership Rewards - Social Currency","/us/heroes/10004-Rewards-SocialCurrency/hero.html"
"10001","Inactive","Expired","NPL - Zync Homepage Promo","/us/heroes/10001-NPL-Zync/hero.html"
"20001","Inactive","Expired","Brand - JD Power & Associates 2010 (Prospect)","/us/heroes/20001-Brand-JDPower2010/hero.html"
"30001","Inactive","Expired","Brand - JD Power & Associates 2010 (Cardmember)","/us/heroes/30001-Brand-JDPower2010/hero.html"
"99001","Inactive","Expired","Animation Prototype","/us/heroes/99001-FPO-PowerOfMembership/hero.html"

The right column of the admin panel consists of what the developers call “cardmember cookies” and options for setting them with various parameters. The cookies are then used for viewing the heroes with various user permissions for debugging. A JavaScript comment gives an idea of how such an important thing as the admin debugging could be left wide open:

/* don't ask me how exactly, but this gets the main
domain froma  hostname; */

Adobe DigitalPulse v3 was also left behind fully accessible by anyone:

I must say their debug window impressed me. It’s a fancy little jQuery using div that I’m very sure that the developers enjoy using:

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. Proof of concept (read warning below): https://www.americanexpress.com/?debug=true&heroOverride=%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%27%68%61%78%27%29%3c%2f%73%63%72%69%70%74%3e

The debug window refreshes itself so injected code that doesn’t break the loop will execute infinitely. 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.

Let’s hope American Express resolve these issues ASAP :-)