Naming and Shaming the Plaintext Offenders

June 15, 2012
46 Comments

It was a fitting end to a week dominated by news of password breaches at major Internet companies. I’d sent a password reset request to a hosting provider I’ve used for years to host a file server online, and received an alarming response: The company sent me my password in plain text, all but advertising that they have zero regard for the security of their customers’ private information.

The site was used to store inconsequential files and images, but I cancelled my subscription nonetheless because the company’s response to my password reset request proved that they were storing my password without even making the weakest attempts at encrypting the information or storing it in a protected format.

Sadly, this practice appears to be quite common, particularly among low-cost hosting providers. I confronted the company, Hosting Metro, about its practices, but received no material response to my complaints aside from an automated “sorry to see you go” email.

I also submitted a redacted screen shot of the password reset email to plaintextoffenders.com, a site that regularly posts user-submitted images of password reset emails from companies that exhibit a complete lack of regard for customer password security. I would encourage all readers to do the same for any site that sends passwords in the clear.

Like many previous visitors to plaintextoffenders.com, I was surprised to see that the site’s search function does not work. The administrators of the forum seem to be aware of this, and have noted that visitors can search by company name via Google, by using the search convention “site:plaintextoffenders.com” followed by a Web site or company name. I would welcome the development of a browser plugin that uses a database of offending sites to warn users when they visit a site that practices unforgivably sloppy password security. Naming and shaming may be the only way to change this all-too-common practice.

Apple, Oracle Ship Java Security Updates

June 13, 2012
29 Comments

There must have been some rare planetary alignment yesterday, because the oddest thing happened: Apple and Oracle both shipped software updates for the same Java security flaws on the very same day.

I’ve taken Apple to task several times for its unacceptable delays in patching Java vulnerabilities. Oracle is the official producer of Java, but Apple maintains its own version, and it has consistently lagged months behind Oracle in fixing security bugs. This failure on Apple’s part finally caught up with Mac OS X users earlier this year and turned into a major embarrassment for Apple, when the Flashback malware infected more than 650,000 Mac systems using a vulnerability that Oracle (but not Apple) had patched roughly two months earlier.

Well, it seems that Apple learned a thing or two from that incident. The update Oracle released yesterday, Java 6 Update 33 and Java 7 Update 5, fixes at least 14 security flaws in the oft-attacked software that is installed on more than three billion devices worldwide. Apple’s Java update brings Java on the Mac to 1.6.0_33, and patches 11 of the 14 security vulnerabilities that Oracle fixed in Tuesday’s release. It’s unclear whether those other three flaws simply don’t exist in the Mac version of Java, but we’ll take progress where we can get it.

Regardless of which operating system you use, if you have Java installed, I would advise you to update it, neuter it or remove it as soon as possible. The reason I say this is that Java requires constant patching, and it appears to be the favorite target of attackers these days. Continue reading →

Advertisement

Who Is the ‘Festi’ Botmaster?

June 13, 2012
17 Comments

Pavel Vrublevsky, the co-founder of Russian payment processor ChronoPay, is set to appear before a judge this week in a criminal case in which he is accused of hiring a botmaster to attack a competitor. Prosecutors believe that the man Vrublevsky hired in that attack was the curator of the Festi botnet, a spam-spewing machine that also has been implicated in a number of high-profile denial-of-service assaults.

Igor Artimovich

Vrublevsky spent six months in prison last year for his alleged role in an attack against Assist, the company that was processing payments for Aeroflot, Russia’s largest airline. Aeroflot had opened its contract for processing payments to competitive bidding, and ChronoPay was competing against Assist and several other processors.

Investigators with the Russian Federal Security Service (FSB) last summer arrested a St. Petersburg man named Igor Artimovich in connection with the attacks. Artimovich — known in hacker circles by the handle “Engel” — confessed to having used his botnet to attack Assist after receiving instructions and payment from Vrublevsky.

As I wrote in last year’s piece, the allegations against Artimovich and Vrublevsky were supported by evidence collected by Russian computer forensics firm Group-IB, which assisted the FSB with the investigation. Group-IB presented detailed information on the malware and control servers used to control more than 10,000 infected PCs, and shared with investigators screen shots of the botnet control panel (pictured below) allegedly used to coordinate the DDoS attack against Assist.

Group-IB’s evidence suggested Artimovich had used a botnet he called Topol-Mailer to launch the attacks, but Topol-Mailer is more commonly known as Festi, one of the world’s largest and most active spam botnets. As detailed by researchers at NOD32 Antivirus makers ESET, Festi was built not just for spam, but to serve as a very powerful tool for launching distributed denial of service (DDoS) attacks, digital sieges which use hacked machines to flood targets with so much meaningless traffic that they can no longer accommodate legitimate visitors.

“Topol Mailer” botnet interface allegedly used by Artimovich.

Group-IB said Artimovich’s botnet was repeatedly used to attack several rogue pharmacy programs that were competing with Rx-Promotion, a rogue Internet pharmacy affiliate program long rumored to have been co-founded by Vrublevsky (security firm Dell SecureWorks chronicled those attacks last year).

Artimovich allegedly used the nickname Engel on Spamdot.biz, an online forum owned by the co-founders of SpamIt and GlavMed, sister rogue pharmacy operations that competed directly with Rx-promotion. In the screen shot below right, Engel can be seen communicating with Spamdot member and SpamIt affiliate “Docent.” That was the nickname used by Oleg Nikolaenko, a 24-year-old Russian man arrested in Las Vegas in Nov. 2010  charged with operating the Mega-D botnet. Continue reading →

Microsoft Patches 26 Flaws, Warns of Zero-Day Attack

June 12, 2012
30 Comments

Microsoft today released updates to plug at least 26 separate security holes in its Windows operating systems and related software. At the same time, Microsoft has issued a stopgap fix for a newly-discovered flaw that attackers are actively exploiting.

The security fixes are included in seven security patch bundles, three of which earned Microsoft’s most dire “critical” label, signifying that attackers can exploit them without any help on the part of the user.  Redmond patched vulnerabilities in Windows, Internet Explorer, Dynamics AX, Microsoft Lync (Microsoft’s enterprise instant message software), and the Microsoft .NET Framework.

Microsoft called out two patches as particularly important: the Internet Explorer bundle (MS12-037), which addresses 13 issues; and a critical flaw in the Windows remote desktop protocol (RDP). Updates are available for all supported versions of Windows, via Windows Update or Automatic Update. Continue reading →

Feds Arrest ‘Kurupt’ Carding Kingpin?

June 12, 2012
11 Comments

The Justice Department on Monday trumpeted the arrest of a Dutch man wanted for coordinating the theft of roughly 44,000 credit card numbers. The government hasn’t released many details about the accused, but data from a variety of sources indicates he may have run a large, recently-shuttered forum dedicated to cyber fraud, and that he actively hacked into and absconded with stolen card data taken from other fraud forums.

This much the government is saying: David Benjamin Schrooten, 21, appeared in Seattle federal court on Monday and pleaded not guilty to charges of bank fraud, access device fraud and conspiracy. Schrooten was accused of running Web sites that sold stolen credit card numbers in bulk. Authorities said Schrooten was extradited to the United States after being arrested in Romania, and that another man — 21-year-old Christopher A. Schroebel of Maryland — was an accomplice and also was charged.

kurupt.su, before it was taken offline.

The government also mentioned one other detail: Schrooten was allegedly known in the hacking community as “Fortezza.” This last detail caught my attention, because for several months members of the cybercrime underground have been inquiring about Fortezza’s whereabouts, and what would become of his hacker forum — an exclusive English language “carding” site aptly named Kurupt.su.

I, too, was wondering where Fortezza had gone. And then, quite recently, the two-year-old Kurupt.su disappeared as well.

Late last fall, I received an interesting invitation from Fortezza to chat online. At the time, he was administrator (or at least one of the administrators) of Kurupt,  which required new members to be referred by an existing member, and to be personally vouched for by four other members.

To this day, I don’t know why Fortezza reached out to me. He claimed to be “quitting the scene,” but spoke often about finishing a project with which he seemed obsessed: to hack and plunder all of the other carding forums. In any case, he had my attention: I had just finished reading Kevin Poulsen‘s excellent book Kingpin, the true story of a very bright but conflicted hacker who took over many of the major carding forums at the time, and consolidated them into one megaforum that he alone controlled. Fortezza sought to “prove” his claim by creating brand-new test accounts for me on several forums that also typically require new members to be vetted and vouched.

At the time, Fortezza was boasting about having just hoovered up a chunk of stolen credit and debit card accounts from Kurupt.ru, a similarly named carding forum. This action may have been the beginning of his downfall: It wasn’t long before the hackers at Kurupt.ru struck back, posting what they believed was Fortezza’s real-life identity. In October 2011, Fortezza announced he was changing his nickname to “Xakep” (Cyrillic for “hacker”), but apparently the U.S. government already had reason to believe that the Kurupt.ru admins were right on the money about Fortezza.

Continue reading →

How Companies Can Beef Up Password Security

June 11, 2012
111 Comments

Separate password breaches last week at LinkedIn, eHarmony and Last.fm exposed millions of credentials, and once again raised the question of whether any company can get password security right. To understand more about why companies keep making the same mistakes and what they might do differently to prevent future password debacles, I interviewed Thomas H. Ptacek, a security researcher with Matasano Security.

Ptacek is just one of several extremely smart researchers I’ve been speaking with about this topic. Below are some snippets from a conversation we had last week.

BK: I was just reading an article by Eric Chabrow, which pointed out that LinkedIn — a multi-billion dollar company that holds personal information on some of world’s most important executives — has neither a chief information officer nor a chief information security officer. Is it too much to ask for a company like this to take security seriously enough to do a better job protecting and securing their users’ passwords?

Ptacek: There is no correlation between how much money a company or service has or takes in — or whether it’s free or not free — and how good their password storage practices are. Nobody gets this right. I think it’s a problem of generalist developers writing password storage systems. They may be good developers, but they’re almost never security domain specialists. There are very few good developers who are also security domain specialists. So if you’re a smart and talented developer but not a security domain specialist, and you’ve got to put together a password storage system, even if it’s just MD5, to you that’s a space alien technology. That’s a cryptographic algorithm. You can tell your boss that’s a cryptographic hash. You feel good about the fact that you’re storing passwords in a cryptographic hash. But you have to be a domain expert to know that the term cryptographic hash doesn’t really mean much.

BK: Why doesn’t cryptographic hash mean much? Maybe LinkedIn shouldn’t have been using a plain old SHA-1 cryptographic hash function, but shouldn’t developers be seeking to secure their passwords with a solid cryptographic algorithm?

Ptacek: The basic mechanism by which SHA-1 passwords are cracked, or MD5 or SHA-512 — it doesn’t matter what algorithm you use — hasn’t changed since the  early 1990s. As soon as code to implement SHA-1 came out, it was also available to John the Ripper and other password cracking tools. It’s a really common misconception — including among security people — that the problem here is using SHA-1. It would not have mattered at all if they had used SHA-512, they would be no better off at all.

BK: I’ve heard people say, you know this probably would not have happened if LinkedIn and others had salted the passwords — or added some randomness to each of the passwords, thus forcing attackers to expend more resources to crack the password hashes. Do you agree with that?

Ptacek: That’s actually another misconception, the idea that the problem is that the passwords were unsalted. UNIX passwords, and they’ve been salted forever, since the 70s, and they have been cracked forever. The idea of a salt in your password is a 70s solution. Back in the 90s, when people broke into UNIX servers, they would steal the shadow password file and would crack that. Invariably when you lost the server, you lost the passwords on that server.

BK: Okay. So if the weakness isn’t with the strength of the cryptographic algorithm, and not with the lack of salt added to the hashed passwords, what’s the answer?

Ptacek: In LinkedIn’s case, and with many other sites, the problem is they’re using the wrong kind of algorithm. They use a cryptographic hash, when they need to use a password hash.

BK: I’ll bite: What’s the difference?

Ptacek:  The difference between a cryptographic hash and a password storage hash is that a cryptographic hash is designed to be very, very fast. And it has to be because it’s designed to be used in things like IP-sec.  On a packet-by-packet basis, every time a packet hits an Ethernet card, these are things that have to run fast enough to add no discernible latencies to traffic going through Internet routers and things like that. And so the core design goal for cryptographic hashes is to make them lightning fast.

Well, that’s the opposite of what you want with a password hash. You want a password hash to be very slow. The reason for that is a normal user logs in once or twice a day if that — maybe they mistype their password, and have to log in twice or whatever. But in most cases, there are very few interactions the normal user has with a web site with a password hash. Very little of the overhead in running a Web application comes from your password hashing. But if you think about what an attacker has to do, they have a file full of hashes, and they have to try zillions of password combinations against every one of those hashes. For them, if you make a password hash take longer, that’s murder on them.

So, if you use a modern password hash — even if you are hardware accelerated, even if you designed your own circuits to do password hashing, there are modern, secure password hashes that would take hundreds or thousands of years to test passwords on. Continue reading →

Critical Security Fixes for Adobe Flash Player

June 8, 2012
28 Comments

Adobe has released a critical update to its Flash Player software that fixes at least seven security vulnerabilities in the program. The new version also extends the background updater to Mac OS X users browsing the Web with Mozilla Firefox.

The update, Flash Player 11.3, plugs at least seven security holes in Flash Player and Adobe Air. The company warns that attackers could use these flaws to crash the applications and seize control over unpatched systems. Flash updates are available for Windows, Mac, Linux and Android systems. Adobe AIR patches are available for Windows, Mac and Android platforms. See the chart below for the latest, patched versions numbers for each platform.

Continue reading →

If You Use LinkedIn, Change Your Password

June 6, 2012
54 Comments

An archive reportedly containing the hashed passwords of more than six million LinkedIn accounts is circulating online. LinkedIn says it is still investigating the claims, but if you use LinkedIn, you may want to take a moment and change your password.

For those who wish to follow along, there are lengthy discussion threads on Reddit.com and ynewscombinator on the claimed password breach, which appears to have affected a small subset of LinkedIn’s user base of 140 million+ users. A number of my sources are now reporting having found their passwords in the archive.

A spokesperson at LinkedIn referred me to the company’s Twitter feed — @Linkedin — which states, “Our team continues to investigate, but we’re still unable to confirm that any security breach has occurred. Stay tuned.”

Update, 3:42 p.m. ET: LinkedIn just published a blog post acknowledging that “some of the passwords that were compromised correspond to LinkedIn accounts.” The company said affected members will find that their account passwords no longer work, and that these users will receive an email from LinkedIn with instructions on how to reset their passwords. LinkedIn cautions that there will not be any links in the emails, and that users should never change their passwords on any website by following a link in an email. LinkedIn also said affected users can expect to receive a second email “providing a bit more context on this situation and why they are being asked to change their passwords.”

Original post:

If you used your LinkedIn password at any other sites, you’ll want to change those passwords as well. For that matter, it’s a good idea to avoid sharing passwords between sites, at least those that hold potentially sensitive information about you.

For tips on choosing a good password, see this primer.

Also, my site is once again the target of a distributed denial of service (DDoS) attack. I am working on a more permanent solution to mitigating these attacks, but I mention this because several features of this site may not work as intended for the time being, such as voting on comments, RSS and the mobile version of this blog. Sorry for the inconvenience, folks.

Alleged Romanian Subway Hackers Were Lured to U.S.

June 6, 2012
25 Comments

The alleged ringleader of a Romanian hacker gang accused of breaking into and stealing payment card data from hundreds of Subway restaurants made news late last month when he was extradited to face charges in the United States. But perhaps the more interesting story is how his two alleged accomplices were lured here by undercover U.S. Secret Service agents, who promised to shower the men with love and riches.

Adrian-Tiberiu Oprea, 27, appeared in a New Hampshire federal court a week ago Tuesday, after being extradited from Constanta, Romania to face charges of hacking into the point-of-sale terminals at more than 150 Subway restaurants and at least 50 other retailers. Oprea was among four men indicted last year on charges of conspiracy to commit computer fraud, wire fraud and access device fraud.

Two of Oprea’s alleged accomplices arrived in Boston one day apart in August 2011, and were arrested immediately after stepping off of their respective flights. Previous news stories have noted their arrests and detentions in the United States, but all of the accounts I read neglected to mention one very interesting fact: Both men entered the country of their own volition.

I spoke last week with Michael Shklar, the public defender appointed to 27-year-old Iulian Dolan — the man authorities say helped Oprea sell credit and debit card accounts harvested in the break-ins. According to Shklar, U.S. Secret Service agents tricked his client into voluntarily visiting the United States by posing as representatives from a local resort and casino that was offering him a complimentary weekend getaway.

“My client was actually smart enough to say, ‘Oh, I don’t believe this. Why would you invite me to a weekend for free?’ And they basically told him, ‘Well, we know you gamble online, and we would like to comp you a weekend because it gives us a cosmopolitan feel.”

Shklar said his client apparently was taken in by the ruse, and thought he’d struck a rapport with the female casino employee who’d invited him. Dolan didn’t know it, but the Secret Service and the casino had set up a dedicated telephone line for the female “employee,” and gave her an email with the casino’s domain name. When a suspicious Dolan sought to verify her story, it checked out. The airline ticket itself was even purchased by the casino, in case Dolan checked on that detail as well.

Apparently convinced he was headed for a weekend of fun, Dolan packed a suitcase with three days’ worth of clothes — plus jewelry for his erstwhile casino friend — and hopped on a complimentary flight from Bucharest to Logan International Airport…where he was presented with complimentary silver bracelets.

“He arrived in the U.S. with some clothes, a cheap necklace, a little bit of money, and three very large boxes of grape-flavored Romanian condoms,” Shklar said. Continue reading →

Attackers Hit Weak Spots in 2-Factor Authentication

June 5, 2012
31 Comments

An attack late last week that compromised the personal and business Gmail accounts of Matthew Prince, chief executive of Web content delivery system CloudFlare, revealed a subtle but dangerous security flaw in the 2-factor authentication process used in Google Apps for business customers. Google has since fixed the glitch, but the incident offers a timely reminder that two-factor authentication schemes are only as secure as their weakest component.

In a blog post on Friday, Prince wrote about a complicated attack in which miscreants were able to access a customer’s account on CloudFlare and change the customer’s DNS records. The attack succeeded, Prince said, in part because the perpetrators exploited a weakness in Google’s account recovery process to hijack his CloudFlare.com email address, which runs on Google Apps.

A Google spokesperson confirmed that the company “fixed a flaw that, under very specific conditions, existed in the account recovery process for Google Apps for Business customers.”

“If an administrator account that was configured to send password reset instructions to a registered secondary email address was successfully recovered, 2-step verification would have been disabled in the process,” the company said. “This could have led to abuse if their secondary email account was compromised through some other means. We resolved the issue last week to prevent further abuse.”

Prince acknowledged that the attackers also leveraged the fact that his recovery email address — his personal Gmail account — was not taking advantage of Google’s free 2-factor authentication offering. Prince claims that the final stage of the attack succeeded because the miscreants were able to trick his mobile phone provider — AT&T — into forwarding his voicemail to another account.

In a phone interview Monday, Prince said he received a phone call at 11:39 a.m. on Friday from a phone number in Chico, Calif. Not knowing anyone from that area, he let the call go to voicemail. Two minutes later, he received a voicemail that was a recorded message from Google saying that his personal Gmail account password had been changed. Prince said he then initiated the account recovery process himself and changed his password back, and that the hacker(s) and he continued to ping pong for control over the Gmail account, exchanging control 10 times in 15 minutes.

“The calls were being forwarded, because phone calls still came to me,” Prince said. “I didn’t realize my voicemail had been compromised until that evening when someone called me and soon after got a text message saying, ‘Hey, something is weird with your voicemail.'”

Gmail constantly nags users to tie a mobile phone number to their account, ostensibly so that those who forget their passwords or get locked out can have an automated, out-of-band way to receive a password reset code (Google also gets another way to link real-life identities connected to cell phone records with Gmail accounts that may not be so obviously tied to a specific identity). The default method of sending a reset code is via text message, but users can also select to receive the prompt via a phone call from Google.

The trouble is, Gmail users who haven’t availed themselves of Google’s 2-factor authentication offering (Google calls it “2-step verification”) are most likely at the mercy of the security of their mobile provider. For example, AT&T users who have not assigned a PIN to their voicemail accounts are vulnerable to outsiders listening to their voice messages, simply by spoofing the caller ID so that it matches the target’s own phone number. Prince said his AT&T PIN was a completely random 24-digit combination (and here I thought I was paranoid with a 12-digit PIN).

“Working with Google we believe we have discovered the vulnerability that allowed the hacker to access my personal Gmail account, which was what began the chain of events,” Prince wrote in an update to the blog post about the attack. “It appears to have involved a breach of AT&T’s systems that compromised the out-of-band verification. The upshot is that if an attacker knows your phone number and your phone number is listed as a possible recovery method for your Google account then, at best, your Google account may only be as secure as your voicemail PIN.”

AT&T officials did not respond to requests for comment.

Continue reading →