Phishers are sending out fake messages from the Federal Trade Commission that drop malware onto the machines of users who click the malicious attachment.
In response, the FTC has issued a public warning to consumers not to open fraudulent emails made to look as though they come from its fraud department. The email says it’s from “firstname.lastname@example.org” and has the FTC seal. Click on the attachment and you’ll download malware designed to steal passwords and account numbers, the agency warned.
“It’s a treasure trove for identity theft,” David Torok of the FTC’s Bureau of Consumer Protection told the Reuters news service. “We’re concerned. The virus that’s attached to the email is particularly virulent.”
The agency doesn’t know how many people found the email in their inboxes, but Torok confirmed the agency has received hundreds if not thousands of calls and complaints.
Recipients of the email are advised to forward it to email@example.com, an FTC spam database used in its online fraud investigations.
I’m not surprised by court documents claiming that TJX blew it on nine of the 12 requirements of the PCI Data Security Standard (PCI DSS), which of course allowed hackers to break into its network and steal the credit card information of more than 94 million customers. PCI DSS auditors have been suggesting for months that TJX had failed on some of the core elements of the standard.
Several banking groups are suing the retail giant for all the money they were forced to spend re-issuing credit cards compromised in the security breach, and last week the plaintiffs filed a new batch of documents in Boston federal court claiming that, among other things, TJX violated PCI DSS by failing to properly secure its wireless network; failing to wall off parts of the network where sensitive data was stored from other parts of the network (popularly referred to as segmentation); and storing data that shouldn’t have been kept around in the first place.
That the latter issue was a factor in the breach is something PCI DSS auditors have been saying for some time.
Way back in March, Roger Nebel, director of strategic security for Washington D.C.-based FTI Consulting, said the breach offers some clear examples of the wrong way to treat sensitive data under the PCI DSS. At the very least, TJX violated the PCI DSS by storing unencrypted cardholder data, agreed James DeLuccia, an independent auditor based in Atlanta, Ga.
“Credit and debit card data is something the PCI Security Standards Council will be concerned about,” he predicted around the same time. “You’re not supposed to store that kind of data, and [TJX] had it online and unencrypted.”
The court documents also confirm another prediction the PCI DSS auditors made — that Visa and/or MasterCard would probably pelt TJX and its card processor with fines. According to one report on the court filings, Visa has already fined TJX’s card processor $880,000 and plans to collect more in the future.
When I interviewed the PCI DSS auditors for that March report, I got plenty of good advice on how retailers could avoid the same mistakes. The best advice, in my opinion, came from Joseph Krause, senior security engineer for Chicago-based AmbironTrustWave.
He said companies first have to get a fix on where customer data is on the network, where it travels and whether or not it’s encrypted.
“Understanding where the data is and where it goes is a challenge for some, but it’s a very important part of PCI DSS,” he said. “If you don’t know where your data is traveling and where it is stored, you can’t secure it.”
Krause also said companies also have to be sticklers for network monitoring. “Usually when we see an environment for the first time, we find they are deficient in this area,” he said. “Just being able to help them understand which logs they need to have a close eye on, on a daily basis,” is a lot of work.
Finally, companies need to understand that there’s no single product or service that can alleviate an enterprise’s PCI DSS compliance woes. Every business and every network is different, and PCI DSS controls must be tailored to an organization’s particular make-up.
“I tell clients it’s not an easy process and it is an educational experience,” he said. “The requirements for every company on the path to PCI compliance are quite different. There’s no one-size-fits-all approach.”
For more advice on how best to respond when your company is hit by data thieves, check out this story from last week’s data breach roundtable discussion at the Harvard Club in Boston.
And keep an eye on SearchSecurity.com this week for another analysis we’re putting together on lessons from the TJX data breach.
A couple weeks back, Windows expert Scott Dunn warned that the repair feature in Windows XP was knocked out of alignment when Microsoft silently deployed a batch of new support files for Windows Update (WU) in July and August. As a result, those who rely on XP’s repair function were unable to install 80 Microsoft patches.
It appears Microsoft’s Automatic Update services continue to do things without the permission of IT administrators, some of whom are venting about it in the blogosphere.
The latest report of auto update trouble comes from Dunn, associate editor of the Windows Secrets newsletter. In a new article on the Windows Secrets Web site, he reveals that installing Windows Live OneCare changes the settings of Automatic Updates without notifying users.
And so, he writes, “Windows has been mysteriously installing patches and rebooting itself, even though users had completely shut down the Automatic Updates function.”
Nate Clinton, a program manager with Microsoft’s product update team, denied in a recent blog entry that its software is to blame for the updates and reboots. “I want to stress that the Windows Update client does not change AU settings without user’s consent,” he wrote.
However, he continued, AU settings can be set or changed in the following scenarios:
–During the installation of Windows Vista, the user chooses one of the first two recommended options in the “Out of Box Experience” and elects to get updates automatically from Windows.
–The user goes to the Windows Update Control Panel and changes the AU setting manually.
— The user goes to Security Center in Windows Vista and changes the AU setting.
— The user chooses to opt in to Microsoft Update from the Microsoft Update Web site.
–The user chooses to opt in to Microsoft Update during the installation or the first run experience of another Microsoft application such as Office 2007.
Dunn did his own research and reported the following:
“My finding is that Windows Live OneCare silently changes the AU settings,” he wrote. “This explains at least some of the complaints that have been reported so far. Users could have installed OneCare — even a free-trial version — at any time in the recent past and been unaware of any changes until Automatic Updates forced a reboot in the wee hours.”
In repeated tests on Windows XP and Vista, Dunn said, he installed Windows Live OneCare and found that in every case, OneCare changed a machine’s Automatic Updates settings to fully automatic.
“It did so even when Automatic Updates had been completely disabled,” he wrote. “In Windows XP, this state is known as ‘Turn off Automatic Updates.’ In Vista, it’s called ‘Never check for updates.’ In no case did the OneCare installer give any indication that a machine’s Automatic Updates settings would be changed. Worse, OneCare silently enables Windows services that had been carefully disabled using Microsoft’s own configuration utilities.”
Clinton’s assertion that the trouble’s are user-initiated doesn’t sit well with some bloggers, including a writer in the The GTA Patriot blog.
“Microsoft says users just don’t realize that their machines are set to update,” the blogger wrote. “They think users are to blame! Is Microsoft completely incompetent or are they lying?”
For admins looking for away out of the current problem, Dunn offers some guidance:
“If you wish to use OneCare but you want updates to be installed only when you’re first notified, the only workaround is to install the program and then change Automatic Updates back to your preferred settings,” he says. “If you install OneCare when Windows is not likely to phone home, you should be able to change AU before any updates are automatically installed. (Installing OneCare at any time other than 3 a.m. should do the trick.)”
After OneCare is installed, Dunn says it doesn’t change the user’s Automatic Updates settings again, but it does peg the disabled Automatic Updates as an “urgent” matter in need of addressing. “In this situation,” Dunn says, “the OneCare icon in the taskbar tray turns a bright shade of red, which you may find annoying.”
He said an alternative workaround is to buy and use security software other than Microsoft’s.
While XP is affected by the trouble, this is also another complication for those trying to get their arms around Windows Vista. In my ongoing series on Vista deployment pain points, a recurring theme has been the compatibility issues suffered by those trying to deploy the OS en mass. But most of the trouble has involved Vista clashing with third-party products, including some security tools.
It’s ironic that in this case, the solution is to ditch Microsoft’s own security program in favor of third-party products.
Dunn does offer some helpful examples of security software admins can turn to.
He says he installed Symantec’s Norton 360 and Norton Internet Security, McAfee Internet Security Suite and the ZoneAlarm Internet Security Suite.
“The McAfee product and both of the two Norton products flagged Automatic Updates as a security problem if it was disabled, and provided ways to turn it back on, but none of them changed the setting,” he says. “The ZoneAlarm suite did not note a disabled copy of AU as a problem, nor did it change the setting. For now, it appears OneCare is the only security package changing users preferences without warning.”
Until Microsoft comes up with a better arrangement, avoiding OneCare appears to be the best bet.
About Security Blog Log: Senior News Writer Bill Brenner peruses security blogs each day to see what’s got the information security community buzzing. In this column he lists the weekly highlights. If you’d like to comment on the column or bring new security blogs to his attention, contact him at firstname.lastname@example.org.
It’s inevitable: Whenever there’s a disaster, online scammers try to exploit the situation. Randy Abrams, director of technical education at security software vendor Eset, said he received an email Wednesday that purported to offer news about the devastating wildfires in Southern California but turned out to be spam advertising Viagra.
Abrams fully expects there to be a deluge of email scams exploiting the fires. These emails will either have links or attachments that download malware onto a user’s machine or will pretend to be charitable organizations raising money for fire victims, he said in an interview.
“The Storm worm creators are good at manipulating current news,” he said. “Even though the Storm worm seems to be declining, it’s still affecting a significant number of PCs and this is the kind of headline that will get exploited.”
In a blog posting on Eset’s Web site Wednesday, Abrams warned users not to respond to emails soliciting donations, including those from legitimate charities such as the American Red Cross. Those wanting to donate should look up the phone number or Web site of the Red Cross rather than using any information in the email, he wrote.
Eset, which has its U.S. headquarters in San Diego, is assisting employees affected by the fires. Some employees have had to evacuate their homes, said Abrams, who works remotely in Seattle.
We’ve written quite a bit in the past about how many enterprises are ignoring the dangers of voice over IP (VoIP). While we doubt many enterprises are in the practice of using Vonage, as yet another example that VoIP and its protocols are easy to attack, it’s worth noting a Reuters report today that hackers have figured out how to intercept calls made on the Vonage VoIP service, according to Sipera Systems.
Here are the highlights in a press release from Sipera: “Sipera VIPER Lab determined the Vonage VoIP Motorola Phone Adapter (VT 2142-VD) and Vonage service implementations leave users vulnerable to a form of VoIP identity theft, allowing hackers to take over a user’s phone service with a ‘registration replay attack,’ then make and receive calls while impersonating the victim. Incomplete security practices, such as not encrypting traffic, open Vonage users to eavesdropping on private voice and video communications. Hackers can also send multiple SIP INVITE messages to a user, an Internet version of ‘ringing the phone off the hook’ which creates a DoS attack. Leveraging these vulnerabilities, remote attackers can also send malicious messages directly to Vonage users, subjecting them to spam, social engineering and VoIP scams.” Sipera also noted a similar vulnerability with European provider Globe7’s online account access system.
Let it serve as a reminder that, as our threats expert Ed Skoudis wrote recently, enterprises should proceed with caution on any and all VoIP implementations because of the many exploits in the wild. Since VoIP security still isn’t getting the attention it demands, it wouldn’t be surprising if enterprise VoIP attacks soon become more popular; Infonetics Research says half of small and two-thirds of large organizations in North America will be using VoIP products and services by 2010. Of course VoIP security is an area we’ll continue to watch closely.
Check out the excellent chronology of data breaches kept by the Privacy Rights Clearinghouse and you’ll notice that a massive chunk of those affected reside in academia. At a gathering of IT security and privacy professionals at the Harvard Club in Boston put on by Text 100 this morning, I heard some interesting examples of why the bad guys love the colleges and universities so much.
Catherine Allen, chairman and CEO of The Santa Fe Group, mentioned that the person responsible for a breach at the University of Missouri earlier this year had been caught, and that authorities learned that the culprit had some long-term plans for the 22,396 record compromised.
Allen explained that the thief was apparently planning to hang on to the data and wait for about a decade before using the stolen identities — when today’s students are more likely to be duly employed and earning steady income.
The lesson — Don’t be lulled into a false sense of security if your information was compromised a year ago and you haven’t become a victim of identity theft yet. Chances are the bad guys are just waiting a few years for you to start making some real money worth stealing.
Yesterday we reported that Adobe patched a critical flaw in its Adobe Reader and Acrobat programs. Now comes word that the bad guys are sending out malicious .pdf files that exploit the vulnerability. The SANS Internet Storm Center has a short and sweet summary of the .pdf threat:
“The vulnerability initially reported here http://isc.sans.org/diary.html?storyid=3406 and confirmed here (with workaround) http://isc.sans.org/diary.html?storyid=3477 and patched here http://isc.sans.org/diary.html?storyid=3531 now appears to have been spotted in the wild. The proof of concept code had been released, and a number of people have reported receiving the PDFs which exploit the vulnerability.”
Here’s some more analysis from the Symantec Security Response Center blog on a Trojan that’s embedded in these malicious .pdf files:
“We have discovered a new Trojan named Trojan.Pidief.A that actually exploits this vulnerability to compromise an unpatched computer. So far we have seen a fair number of emails containing this new Trojan in the wild. It is likely that Trojan.Pidief.A has been spammed out in targeted attacks on specific business organizations. The Trojan will most likely arrive through email with a subject such as ‘invoice,’ ‘statement’ or ‘bill’ of some description, and just containing the .pdf file.”
As for advice on what to do about it, I refer to these words of wisdom from the SANS ISC: “Please patch, apply the workarounds, and/or ensure you can detect and block the exploit.”
Colorado Rockies fans, who have been waiting for generations–or at least part of one generation–to see their team in the World Series, will have to wait another day to get tickets for the series after the team’s Web site buckled under the weight of what Rockies officials say was a deliberate attack on Monday. The team, which will play the Boston Red Sox in the World Series beginning Wednesday in Boston, began selling tickets for games three, four and five of the series at Coors Field in Denver Monday morning. However, fewer than 500 of the nearly 60,000 available tickets were actually sold before the ticketing system crashed while trying to handle a reported 8.5 million hits in about 90 minutes. Rockies officials said the failure was not because of the high volume of traffic, but rather because of what sounds like a DDoS attack.
“Thank you again for your patience tonight and for all our fans, again for their patience on what’s been a difficult day for them and for us also,” team spokesman Jay Alves said in a statement. “Our Web site, I can tell you, and ultimately our fans and our organization, were the victim of an external malicious attack on our Web site that shut down the system that prevented our fans from being able to purchase their World Series tickets.”
The team did not release any other details or give any reasons for its assertion that there was an attack on the site. The Rockies will try again to sell the tickets online on Tuesday, according to a story on Sports Illustrated’s site.
In this age of Web 2.0-based attacks, companies are turning to a variety of Web application security scanners to help them find and fix security holes. But according to a study conducted by independent security consultant Larry Suto, some of these scanners are overlooking quite a few vulnerabilities.
The report is accessible via the ha.ckers.org blog and looks at three tools in particular — NTOSpider, AppScan (IBM/Watchfire) and WebInspect (HP/Spi Dynamics). Of the three, he said:
— NTOSpider found 227 vulnerabilities with zero false positives.
— AppScan (IBM/Watchfire) found 27 vulnerabilities with five false positives.
— WebInspect (HP/Spi Dynamics) found 12 vulnerabilities with 13 false positives.
Now, to be fair, this is based on one man’s research and isn’t necessarily the ultimate verdict on how effective these tools are. I should also point out that the study was flagged by the vendor who fared best, NT OBJECTives Inc. CEO Matthew L. Cohen.
My purpose for flagging this is to get a discussion going among researchers and users alike as to which Web application scanning tools they use and which ones are the best or worse.
I want to pinpoint the common strengths and weaknesses of these tools and hopefully offer IT professionals some useful guidance as a result. This is a terribly important topic, given all the Web 2.0 threats we’ve been writing about of late.
So don’t be shy — let me know what you think.
Networks around the country are seeing evidence of what may be a coordinated attack on SSH servers. The folks at the Internet Storm Center have gotten a number of reports of activity that looks like it may be distributed attempts to brute-force various accounts on SSH servers. The attacks appear to be coming from a large number of IP addresses and target one victim server, ISC’s report says.
Today we had 4 separate reports of an increase in ssh bruteforce attacks. Two of those reports stated that they were seeing lots of source hosts against a single victim. The isc.sans.org port 22 graph supports this as there has been a large increase in the source hosts seen in ssh scans during this month.
Port 22 on both TCP and UDP is the default port for the SSH remote login protocol. Attacks on SSH servers usually grab administrators’ attention right away, as the service is used by admins and other power users to login securely to remote servers. So an attacker who succeeds in brute-forcing the login credentials on an SSH server would likely have high-level access to the other resources on the network. Some of the reports that the ISC is getting from its readers indicate that the machines attempting the logins may be compromised themselves, which could suggest that they are part of a botnet looking specifically for vulnerable SSH servers.