Slashdot Mirror

Heise Security reports that a 'team of researchers from Bonn University and RWTH Aachen University have analysed the notorious Storm Worm botnet, and concluded it certainly isn't as invulnerable as it once seemed. Quite the reverse, for in theory it can be rapidly eliminated using software developed and at least partially disclosed by Georg Wicherski, Tillmann Werner, Felix Leder and Mark Schlösser. However it seems in practice the elimination process would fall foul of the law.'

An anonymous reader writes "The age-old full disclosure debate has been raging again, this time in no other place than at the foundations of the open-source flagship GNU/Linux operating system: within the Linux kernel itself. It beggars belief, but even Linux creator, Linus Torvalds, has advocated against the sort of openness on which Linux has thrived, arguing that security fixes to the kernel should be obscured in changelogs, saying 'If it's not a very public security issue already, I don't want a simple "git log + grep" to help find it.' Unfortunately, it's not kernel exploit writers who need to grep the changelog in order to find kernel vulnerabilities. On the contrary, it's downstream distributors who rely on changelog information in order to decide when to patch the kernels of their distributions, in order to keep their users safe."

An anonymous reader writes "Apparently Microsoft still hasn't learned that counting vendor acknowledged vulnerabilities isn't a good way to establish the security of an OS. As an analysis of Microsoft's claims on Full Disclosure shows, we see that the methodology used was badly flawed. A bug in Firefox (not to mention emacs), counts as a flaw for Linux, while IE bugs get ignored on Vista's chart. Then we see that vulnerabilities aren't vulnerabilities when they're security-challenged features such as Vista's Teredo. Also, there's far too little consideration given to severity, given that it stoops to counting even extra access restrictions on a file in OSX to have something to show. In short, the original Microsoft analysis was good PR and poor research."

Continent1106 writes "Hacker Michal Zalewski has ratcheted up his ongoing assault on Web browser security models, releasing details on serious flaws in fully patched versions of IE6, IE7 and Firefox 2.0. The vulnerabilities could cause cookie stealing, page hijacking, memory corruption, code execution, and URL bar spoofing attacks." Here is Zalewski's post to Full Disclosure.

Frequent Slashdot contributor Bennett Haselton gives the full-disclosure treatment to the widely known and surprisingly simple technique for finding treasure-troves of credit card numbers online. He points out how the credit-card companies could plug this hole at trivial expense, saving themselves untold millions in losses from bogus transactions, and saving their customers some serious hassles. Read on for Bennet's article.
Some "script kiddie" tricks still work after all: Take the first 8 digits of a standard 16-digit credit card number. Search for them on Google in "nnnn nnnn" form. Since the 8-digit prefix of a given card number is often shared with many other cards, about 1/4 of credit card numbers in my random test, turned up pages that included other credit card numbers, and about 1 in 10 turned up a "treasure trove" of card numbers that were exposed through someone's sloppily written Web app. If the numbers were displayed along with people's names and phone numbers, sometimes I would call the users to tell them that I'd found their cards on the Internet, and many of them said that the cards were still active and that this was the first they'd heard that the numbers had been compromised.

Now, before this gets a lot of people mad, let me say that at first I was planning on holding off writing about this for months if necessary, to give the credit card companies time to do something about it. In other words, I actually had the presumptuousness to think that I had been the first one to discover it, but only because the credit card numbers that I found were still active. (If the trick had been widely known, I reasoned, surely the credit card companies would have found any credit card numbers listed in Google before I did, and gotten them cancelled.) Then I found that the trick had been publicized about three years earlier in a C-Net article by Robert Lemos and was probably widely known even before that. (The article stops just short of describing the actual technique, but one reader posted the full details in a follow-up comment.) Another article from that year in CRM Daily describes an even more efficient trick: Googling for number ranges like 4060000000000000..4060999999999999 to find Visa card numbers beginning with "4060". Google has now blocked that trick, so that trying that as a Google search leads to an error page. But the basic technique of Googling for working credit card numbers, apparently still works. In other words, credit card companies have apparently known about this technique for at least three years, probably longer, and presumably have hoped it would continue being swept under the rug.

At this point, I think the right thing to do is to shine a light on the problem and insist that they fix it as soon as possible. It may result in a short-term spike in people using this technique, but if it results in the problem being fixed, then the total number of fraud incidents will probably be less in the long run.

It would be simple for companies like Visa, MasterCard, and Discover to take a list of the most common 8-digit prefixes, query for them every day on Google, and de-activate any new credit card numbers that were found that way. (American Express cards are apparently not vulnerable to this trick, because when their 15-digit card numbers are written with spaces, they are usually written in the format "3xxx xxxxxx xxxxx", and Googling for the first 10 digits as "3xxx xxxxxx" didn't yield anything in my random test of ten AmEx numbers. But this is still their problem too, since the searches that turn up "treasure troves" of card numbers usually include AmEx numbers as well.) A Perl programmer could write a script in one afternoon that could run through all the known 8-digit prefixes, parse the search results, and pick out any URLs that weren't listed as matches the day before. From there, the search results would have to be reviewed by a human, in order to spot any situations where one credit card number was exposed at one URL, and a slight variation on the same URL (such as varying an order ID number) would expose other credit card numbers as well, which was the case with several of the hits that I found. Simple, but time-consuming with so many different 8-digit prefixes -- but every minute of effort expended on tracking down and canceling leaked credit card numbers, would save time and grief later by preventing the numbers from being used by criminals. If it would save them time in the long run and help prevent fraud, then why don't they do this?

It's considered good etiquette among security researchers, when finding a new security hole, to give the affected companies a chance to fix the issue before publicizing it. When I first contacted the credit card companies and described exactly how the exploit worked and how to block it, after getting a polite "We can't comment" from each one, I figured I'd give them a few months to get a system in place that could find leaked cards on a daily basis and de-activate them before they could be used. But then I found the C-Net article from 2004, and figured that if the card companies hadn't taken action in three years, it was fair game to publicize the trick in order to increase the pressure on them to plug the gap. Of course, it's not the card companies' fault that these card numbers are leaked onto the Web; it's the fault of the merchants that allowed them to get leaked. But the credit card companies are the only ones who are in a position to do something about it.

I did try the "Good Samaritan" approach, calling the credit card companies when I found one of their customers' card numbers on the Web. For each of the four major card companies, I called their security departments and reported two of the cards that I had found compromised, and then a week later, called the cardholders themselves to see if the card companies had notified them. Surprisingly, of the four companies, American Express was the only one whose customers in this experiment, when I called them a week later, said that AmEx had contacted them and told them to change their numbers. But even if all four credit card companies were more proactive about acting on reports of leaked numbers, the problems with scaling this approach are that (a) I usually had to wait on hold for a few minutes with each company and then spell out each card number that I'd found, which doesn't scale for a large number of stolen card numbers, and (b) if lots of people started doing this, then the credit card companies would be inundated with duplicate reports about the "low-hanging fruit", card numbers with common prefixes that appear near the top of some Google search result. Both problems could be avoided if the card companies simply ran their own script that queried Google and brought up a list of any indexed card numbers, whereupon an employee could copy and paste the numbers into an interface that would flag the cards instantly.

Google does have a feature where you can request the removal of pages that contain credit card numbers and other personal data such as Social Security Numbers. Any pages that I found containing credit card data, I submitted for removal, and Google did handle each removal request within two days. But this doesn't guard against the possibility that someone might have found the credit card information before it was removed, and of course it doesn't mean that other search engines like Alta Vista (remember Alta Vista?) might not have indexed the same pages. Running a sample of 8-digit prefix searches on Alta Vista, I found about as many credit cards as I found through Google, including some pages that were not in the Google index (maybe Google never indexed them, or maybe they had removed them already). So removing a page from any engine's search results is more like covering up a symptom of a problem than fixing the problem itself, which is the fact that the card number was leaked to the Web in the first place.

If nothing else, this is another reminder of how terrible the security model is for credit card numbers as a token of payment -- one universal piece of information shared with every merchant, that can be used for unlimited unauthorized charges if it gets compromised, until someone notices. About the only desirable property of credit card numbers from a security point of view is that they can be changed, and most of your existing recurring billing relationships will carry over, but even that is a hassle. Several credit card companies do provide the ability to generate single-use credit card numbers, each one authorized only for a limited purchase amount. The problem with that is that as any security analyst will tell you, if it takes even one extra step, most people won't bother -- as long as all-purpose credit card numbers are the default, that's what most people will use. Perhaps incidents like this will push people towards more 21st-century-aware styles of payment (like PayPal, but without all the horror stories), where you can pay a bill through a system that debits your card or your bank account, without sharing all your information with the merchant.

But in the short term, as long as credit card numbers are still with us, the card companies should make more proactive efforts to find and deactivate the ones that have been leaked on the Internet. If the card numbers are found to be leaked by a clumsy Web interface on one company's site, then that company should be chastised by the card companies that issued them a merchant account. If the numbers are found together in a list posted on some third-party forum, then the companies can cross-reference the charge history against each card in the list, to narrow down which merchant may have been responsible for the leak. I'm sure the card companies do something like this already when they find a list of leaked cards; what they don't seem to be doing is acting aggressively enough to find the leaked numbers in the first place.

Maybe the real moral is not the insecurity of credit card numbers, but the value of transparency and online community relations. If MasterCard had been a hip company like Wikia, some volunteer probably would have discovered this attack very early, and another volunteer would have written an open-source tool to find and deactivate leaked MasterCard numbers automatically, and the problem would have been solved ten years ago. In fact many tech companies, if you report a security problem to them, will thank you and fix it immediately, and some of them will even offer you cash if you find any more, like Netscape used to do with their $1,000 Bugs Bounty program. We get so used to big companies having obvious holes in their security practices and answering every question about security with a flat "No comment", that we forget it doesn't have to be that way -- transparency is not just trendy, it works. After years of having bug hunters poke at the Netscape browser, the security may not have been perfect, but it didn't have any security holes that were as simple and obvious as to be analogous to finding credit card numbers on Google.

Several readers wrote in with a CNET report that raises novel free-speech questions. MySpace asked GoDaddy to pull the plug on Seclists.org, a site run by Fyodor Vaskovich, the father of nmap. The site hosts a quarter million pages of mailing-list archives and the like. MySpace did not obtain a court order or, apparently, compose a DMCA takedown notice: it simply asked GoDaddy to remove a site that happened to archive a list of thousands of MySpace usernames and passwords, and GoDaddy complied. Fyodor says the takedown happened without prior notice. The site was unavailable for about seven hours until he found out what was happening and removed the offending posting. The CNET article concludes: "When asked if GoDaddy would remove the registration for a news site like CNET News.com, if a reader posted illegal information in a discussion forum and editors could not be immediately reached over a holiday, Jones replied: 'I don't know... It's a case-by-case basis.'"

TheViewFromTheGround writes "Fyodor of nmap fame has released a top 100 list of network security tools, based on a poll of the nmap-hackers list, each with a handy synopsis and useful information about source-code availablity and OS-compatibility. The last version of this survey was published in 2003."

spafbnerf writes "Fyodor, author of the open-source network scanning tool Nmap, posted a story to the nmap-hackers list about having received a number of subpoenas from the FBI this year, demanding webserver log data, none of which produced anything, either because they sought old information that had already been deleted from his logs, or because the subpoenas were improperly served. In every case the request was narrowly crafted, usually directed at finding out who visited the site in a very short window of time, such as a five minute period. Fyodor writes: "If they see that an attacker ran the command "wget http://download.insecure.org/nmap/dist/nmap-3.77.t gz" from a compromised host, they assume that she might have obtained that URL by visiting the Nmap download page from her home computer"." Update: 11/25 20:21 GMT by T : Reader kv9 adds a link to Kevin Poulson's story at SecurityFocus.