On 24 October, bookseller Barnes & Noble issued a press release revealing that PIN pad devices at cash registers (also known as point-of-sale or POS terminals) in 63 stores had been tampered with. According to the release, the book chain, “upon detecting evidence of tampering, which was limited to one compromised PIN pad in each of the affected stores…discontinued use of all PIN pads in its nearly 700 stores nationwide.” A Wired article reports that Barnes & Noble discovered on or about 14 September that the card readers had been implanted with malware that allowed a group of cyberthieves to intercept credit and debit card data. The company kept the attack a secret at the urging of the FBI, which was investigating. Neither the company press release nor the Wired article indicate exactly how the hackers managed to infiltrate the bookseller’s payment system. But the Wired story points to a July presentation at the Black Hat security conference in Las Vegas, where researchers demonstrated one of several methods for installing malware onto POS terminals; the researchers exploited a vulnerability that would allow a hacker to surreptitiously change applications on the device or install new ones in order to capture card data. While Barnes & Noble is fixing the security hole, it is advising customers to let cashiers scan their cards using the ostensibly more secure readers embedded in the cash registers.

Apps Give Away the Keys to the Kingdom

If a chain is only as strong as its weakest link, then Google’s popular Android mobile gadgets can trace their susceptibility to manipulation by hackers to a significant vulnerability in a startling number of apps available from the Google Play app store. According to TechNewsWorld, researchers at the Leibniz University of Hannover and Philipps University of Marburg downloaded 13 500 popular free apps from Google Play in order to see just how many made proper use of the SSL or Transport Layer Security protocols. Of these, 1074 had SSL implementation flaws that that could be exploited via so-called man-in-the-Middle attacks. The researchers say they chose 100 of the problematic apps for more detailed exploration; for 41 of them, SSL setup problems let the team capture credit card and bank account information, as well as login credentials for Facebook, Twitter, Google, Yahoo, Microsoft Live ID, and e-mail accounts. According to TechNewsWorld, the vulnerable apps have been installed in 39.5 and 185 million phones and tablets. "For SSL/TLS to work properly, every component must be used the way it is designed," Chet Wisniewski, senior security advisor at SophosLabs, told LinuxInsider. "The flaws pointed out in this research result from application developers turning off or ignoring one part of the TLS specification. It turns out this is quite easy to do as an Android developer, and Google does not have a human review process for every application like Apple does for its App Store."

A Wolf In Google’s Clothing?

Wait. Before you reply to that e-mail or click any of the links contained in it, are you sure that it came from the person or the company noted in the message’s header? ZDNet reports that Google, Yahoo and Microsoft have all recently fixed a vulnerability in their email-signing mechanisms that made it possible for people to spoof messages using those companies’ domain names. The vulnerability, which related to the firms using RSA keys for e-mail that were shorter than 1024 bits long, was first discovered by mathematician Zachary Harris. According to Harris’ own account in Wired, he discovered the flaw after receiving a job offer from someone purporting to be a headhunter with Google. Harris, suspicious that the e-mail might have been a phishing expedition, dug into its header information. He noticed that the DomainKeys Identified Mail (DKIM) key that Google used was generating 512-bit keys. Harris told Wired that he thought the email was an elaborate pre-employment test to see if he would notice—and how he would react to—the security flaw. So he promptly cracked the key and sent e-mails to Google co-founders Sergey Brin and Larry Page, posing as each other, that directed them to Harris’ website. Harris says he never received a reply from them, but within 2 days, Google had bolstered its cryptographic key to 2048 bits. Harris told Wired that he noticed the same problem (512- or 768-bit lengths) with the DKIM keys used by PayPal, Yahoo, Amazon, eBay, Apple, Dell, LinkedIn, Twitter, SBCGlobal, US Bank, HP, Match.com and HSBC. Cybercriminals’ phishing schemes would be greatly enhanced if they were able to use these sites’ e-mail addresses in come-ons geared to getting people who aren’t as wary or as tech savvy as Harris to navigate to a site containing malicious code or to divulge personal information.

Phishing Using a Government Guise

In a separate but closely related story, ZDNet reports that for nearly a week, cybertricksters were able to send e-mails using addresses with the .gov top-level domain fraudulently affixed. They were able to make their come-ons appear legitimate after they exploited a vulnerability in a service provided to Internet users by the U.S. government. The US General Services Administration (GSA) administers a URL shortener so that US government, military, and other official links can be shortened to something ending in “1.USA.gov” or “Go.USA.gov.” The latter of these is available only to users an official government email address. But anyone can send e-mails with links, shortened by Bit.ly, to something in the style of 1.USA.gov. Though the shortened links only point to official U.S. government websites, some of those sites had been tampered with so that they automatically redirect the user to malicious sites without warning. After having been notified of the exploit, Bit.ly changed its policy with regard to U.S. government links: Even links to official US sites will get bit.ly addresses instead of 1.USA.gov addresses if they appear to be linking to an open redirect. Furthermore, says ZDNet, Bit.ly will warn users if the link appears suspicious.