Security Bytes

February 24, 2009  4:30 PM

Adobe zero-day threat limited so dont panic

Robert Westervelt Robert Westervelt Profile: Robert Westervelt

The sky is not falling.

Shadowserver Foundation volunteers Steven Adair and Matt Richard sounded the alarm about an Adobe JavaScript zero-day flaw last week. They should be commended for their volunteer work. There’s no doubting the importance of researchers calling out flaws so vendors can quickly fix their products. Adobe responded and will issue a patch by March 11.

Just as some places have a law against shouting “fire” in a crowded theater, those responsible for issuing warnings and protecting customers need to take heed. Those who write about flaws should be clearly explaining the threat level so readers can assess the risks. Too many times the threat is clouded making risk assessment extremely difficult.

First, there’s a workaround to the Adobe zero-day — disable JavaScript. Yes, that’s easier said than done since it could break critical applications at some businesses.

Second, the threat is minimal — extremely minimal. Security vendors that track these threats are not releasing infection estimates. Hmm. I wonder why? Kevin Haley, director of security response at Symantec told me the attacks began appearing in the wild in Japan. They have been spreading slowly for several reasons. The attack has been largely unsuccessful. The malicious Adobe file is spreading in an email message that can be detected as malicious and filtered out. And the message being sent is detected as spam in most cases. The threat can also spread if a user visits a website hosting a malicious PDF file. This can be mitigated by disabling Internet Explorer from auto-opening PDF files.

If your firm can’t handle the increased risk, Sourcefire released a homebrew patch for Adobe 9 users. There’s no guarantee the patch will block an attack. But if your users are using common sense and opening Adobe files from only trusted users and other protections are in place, the risk of infection should be minimal until Adobe issues an update plugging the hole.

There’s no doubt the risk level increases over time when new variants exploiting the code show up in the wild.

Is this a good time to mention Foxit Reader or other alternative PDF readers?

UPDATE:…….Danish vulnerability clearinghouse Secunia says disabling Javascript will not prevent exploitation:
Over the last couple of days, we have seen many sources recommend users to disable support for JavaScript in Adobe Reader/Acrobat to prevent exploitation. While this does prevent many of the currently seen exploits from successfully executing arbitrary code (as they rely on JavaScript), it does not protect against the actual vulnerability.

February 3, 2009  9:30 PM

Security-Bytes blog added to IT Knowledge Exchange

Robert Westervelt Robert Westervelt Profile: Robert Westervelt

The editorial team will continue to post regularly on some of the latest information security issues. Our aim has been to provide news analysis as events unfold. We’ve moved to IT Knowledge Exchange to take advantage of some new blog features as well as the community features IT Knowledge Exchange offers.

To highlight the most popular topics, we’ve added a Tag Cloud rather than a list of bland categories. The Tag Cloud is dynamic, so the more a tag is used, the larger and darker it will appear.

You’ll also notice we’ve integrated more of our related editorial content in the right sidebar. If you’re on a post about a specific topic be sure to browse the links in the right sidebar.

The number of bookmarking tools has increased from four to forty-three. If you enjoy a post, please be sure to share it with friends and colleagues.

Above each post is the SearchSecurity navigation bar. Clicking Home or the logo will bring you to the home page.

At the top of the page you’ll see a row of tabs. You can click the IT Blogs tab to find dozens of technology blogs, both user-generated and TechTarget editorial blogs. You can even request your own blog and start sharing your expertise with your peers.

There is also a tab labeled IT Answers. This is where you can ask your own IT question and have it seen by thousands of IT Knowledge Exchange members. So be sure to pose your own question, browse thousands of answers or help out a fellow IT pro by answering a question.

January 27, 2009  5:51 PM

Microsoft Conficker/Downadup infections still not a major threat

Robert Westervelt Robert Westervelt Profile: Robert Westervelt

I had an excellent briefing with the folks at TippingPoint about Conficker and they gave me access to their ThreatLinQ, a service that helps TippingPoint IPS customers proactively configure their systems. I’ll be writing about Conficker in a news story tomorrow. ThreatLinQ is essentially a portal that shows global threat data caught in TippingPoint’s DVLabs’ IPS filters. It can rank threats on a global scale and threats by country. It also shows how other TippingPoint customers are using their IPS and what is being blocked by default.

Security researcher Derek Brown of TippingPoint’s DVLabs, explained to me that while Conficker/Downadup has spread to an estimated 10 million machines, it reached its peak on Jan. 10. It’s an interesting worm because it can propagate either by exploiting the Microsoft RPC flaw, patched in October with MS08-067, or it can spread via USB sticks and other removable storage devices.

Ten million infections is a lot of computers, but I repeat what I said in an earlier post that most infections have taken place in countries where it took longer to deploy MS08-067. Places where pirated software is rampant; where machines are more likely to go unpatched. TippingPoint’s ThreatLinQ supports this.

Attempts to attack the Microsoft RPC vulnerability ranks No. 5 of all threat’s globally, according to the TippingPoint data. It’s well behind the MS-SQL: Slammer-Sapphire Worm which was picked up globally more than 32 million times in TippingPoint’s honeypots. Slammer ranks No. 1. Conficker was detected about a half a million times, according to the real-time data.

In China, where Symantec ranked Conficker infections the highest, Microsoft RPC attacks ranked ninth, according to the TippingPoint data. In the United States, attacks attempting to exploit the Microsoft flaw didn’t even rank in the top 10.

Conficker is also relatively easy to disinfect using any number of tools including Microsoft’s Malicious Software Removal Tool.

Conficker still fascinates security researchers. It’s got a built in password cracker. Once infecting a machine it seeks out other IP addresses to try to continue to spread. It can spread on shared drives. It also relays location information to the author.

Let me be clear: Derek Brown of TippingPoint’s DV Labs did not downplay the worm. The damage the fledgling botnet inflicts is still unknown. Once the attacker delivers the payload to the infected machines we’ll begin to measure the extent of Conficker’s destruction.

January 21, 2009  5:47 PM

Conficker, Downadup worm hype? Get the facts

Robert Westervelt Robert Westervelt Profile: Robert Westervelt


Update 1/23: Microsoft has released a blog post explaining everything you need to know about Conficker/Downadup. The bottom line: Ensure that MS08-067 is installed on all machines in the environment, use up-to-date antivirus, ensure you have strong passwords for user accounts, consider disabling AutoPlay.

Security vendors from across the spectrum have warned that a stingy worm has been successfully exploiting a hole in Microsoft Windows server service. Known as Conficker or Downadup, the worm spreads by exploiting a remote procedure call (RPC) vulnerability.

The flaw was patched by Microsoft in October. The MS08-067 update was meant to stop the worm in its tracks. Many patching vendors say organizations apparently have been slow to deploy the update.

But that may not be the case. Symantec released data explaining which countries have had the highest worm infection rates. North America does not even rank in the top 10 countries infected by the worm. It has spread in countries where software pirating is rampant. Bootlegged versions of Microsoft Windows won’t receive the latest security updates. Is it a coincidence that the highest infection rates are in China, Russia, Argentina, Taiwan and Brazil? (In that order) China and Russia have been at the top of the list of software pirating countries for years.

So first don’t panic. If you’re running antivirus and it’s up-to-date, you’re probably fine. Second, ensure that the MS08-067 update has been deployed. If it hasn’t deploy it and then do a thorough review of your patch management processes. This patch should have been deployed months ago.

In its latest round of updates, Microsoft security experts addressed the spread of the worm and how people can check to see if their machines are infected. Microsoft advises customers to scan the machine with up-to-date antivirus. The worm also blocks access to a large number of security websites listed by Microsoft.

Also, Microsoft said its Malicious Software Removal Tool completely cleans the registry elements related to the worm.

What’s all the fascination among security researchers about Conficker/Downadup? It’s not necessarily who’s infected, but how they are being infected. As Derek Brown, of TippingPoint’s DVLabs points out, the worm is an example of advanced malicious software coding. Conficker/Downadup can self-propagate by guessing a person’s weak password or it can spread by simply being passed along on someone’s portable storage device. It disables several system services and security products and then signals to its host that it is ready to download additional instructions.

January 19, 2009  7:56 PM

SANS Log Management Survey is looking for the ROI

Neil Roiter Profile: NBRoiter

Good information security requires…good information.

That’s why logs are so important and why so many regulatory and industry directives require companies to not only gather but monitor, read and analyze them.

By the same token, if we’re going to get this log management thing right, we need to share our experiences and pain points with each other and the vendors who want to make their log management products more responsive to our needs, so we, in turn, will keep giving them money.

So, if you have not yet taken the fifth annual SANS Log Management Survey, please take a few minutes. The survey will be up through January. Obviously, the more respondents SANS gets, the more reliable the results.  The findings will be released at SANS WhatWorks Log Management and Analysis Summit to be held in Washington April 6-7.

The survey has evolved as organizations experience with log management has evolved, said Stephen Northcutt, SANS CEO. Compliance is now well established as a driver for developing and improving log management programs and deploying automated tools. In fact, the 2008 report showed that compliance was only the second highest reason for collecting log data, behind detection and analysis of security and performance incidents.

With this year’s survey, SANS wants to emphasize getting full value to leverage log management for security and operations.

“The biggest thing in the survey that’s new and different is looking for the ROI,” Northcutt said. “We’re trying to see what the biz case for this is; the compliance case is established.  Two years you had to go to the CFO and say, look, I need 200,000 bucks.  Here are the findings of the audit report. So, you spent the money and now you’re saying, ‘Gosh, what can I DO with this?'”

January 15, 2009  7:32 PM

Should states lead the charge for secure application development?

Neil Roiter Profile: NBRoiter

I’m not a big fan of states’ rights, which made a lot more sense in 1791 than they do today (Why should one state’s misdemeanor be another state’s felony? Why is a gay couple married in one state and unmarried when they drive over the state line?).

My 18-year-old son wonders why I vote Republican and sound so much like a Democrat. I guess it’s because I like standards but don’t like government spending a lot of money on what it thinks will improve people.

I also share Gary McGraw’s skepticism about Top 10 lists Software [In]security: Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work.

So it’s hardly surprising I have mixed feelings about New York state’s plan to use the freshly minted CWE/SANS Top 25 Dangerous Programming Errors list, as a key requirement of its procurement enforcement requirements for software developers.

But while we can quibble over the value of this list or that list, what I do like is that it is incorporated as a component of the Application Security Procurement Language, drafted by New York CISO William Pelgrin and posted on the SANS website. The critical point is that if and when the procurement requirement is adopted, developers of custom software will be held accountable. They’ll be required to demonstrate that security is a core element of their application development lifecycle, from coding thru final pen testing if they want to do business with New York.

What gives me pause, though, is that we’re likely to see a cascade of initiatives in many states, a la the breach disclosure laws that followed California SB 1386 and what we will no doubt see in the wake of the new Nevada and Massachusetts data protection laws. I’d rather see federal standards that can be applied across state borders. The states step into the, ahem, breach, because the feds are slow and/or reluctant to act. California enacted 1386 more than five years ago, and something like 42 states, the District of Columbia and Puerto Rico have followed suit, while a variety of bills have been introduced, debated and left to wither in Congress.

Companies doing business with customers in more than one state (that is, almost everyone except Sam’s Hardware over on Sycamore Street, that Sam III runs since Sam, Jr. retired 20 years after he took over from Sam, Sr.) have had to develop policies and procedures that fit the most stringent of these laws–and they’re relatively straightforward.

What happens when we start to see a smorgasbord of data protection laws (consider that Massachusetts law, which is to go into effect in May is far more demanding than Nevada’s). And secure software development? Now that’s complex. Will one state adopt the SANS guidelines and another, perhaps, insist on incorporating the secure development lifecycle directive being drafted by NIST? Will one state require developers to expunge the SANS 25, another the OWASP Top 10, and yet another an assortment from among the 700 or so errors that can leave code vulnerable?

So, applause to all who try to put teeth into security. Now if it wasn’t like pulling teeth to get everyone pulling together.

January 13, 2009  11:51 AM

Phishing attack uses pop-up message on bank sites

Robert Westervelt Robert Westervelt Profile: Robert Westervelt

PhishingResearchers at security vendor Trusteer have discovered a new phishing method that forces pop-up login messages to appear on legitimate banking websites.

The messages trick users into giving up passwords, account numbers and other sensitive information. Sometimes the messages appear after they have logged into an online banking or other financial website, Trusteer said.

Trusteer issued an advisory on their find. The technique is called Session Phishing, and is used after attackers inject malicious code into major browsers.

Trusteer CTO Amit Klein said the method makes phishing attacks more likely to be successful because they try to trick people after they have logged into a legitimate website. Klein said the major browser makers have been notified.

I can see how the phishing attack can easily trick people. Trusteer said the pop-up window sometimes requests the user to retype their username and password because the session has expired. How many times have you had that happen? It sometimes also asks users to complete a customer satisfaction survey or participate in a promotion. I typically stay away from those and so should you.

Two researchers recently wrote a report outlining how phishers are failing to make a ton of money. The report, which we wrote about last week, said there were too many phishers driving down the price cybercriminals pay for stolen information. There’s varying opinions on this report and some are immediately doubting it because it came from Microsoft Research. More on that in another post.

January 2, 2009  12:17 PM

Fear and loathing in the Intertubes

David Schneier David Schneier Profile: David Schneier

One of the peculiar properties of the security research community is the reflexive reactions of some of its members to new work by other researchers. In most cases, researchers tend to compliment one another when they’ve produced something new. But there always seems to be a small subset of researchers who race to be the first one to point out that, regardless of the scope or originality of the work, it is: A. nothing new, B. not as severe as it looks, C. easily defended against, or D. all of the above.

The news this week about the MD5 SSL attack from Alex Sotirov, Jake Applebaum and friends brought out the knives in a sadly predictable way. The team was very careful to point out at every opportunity that its work was based heavily on the previous work done on MD5 collisions by a group of Chinese researchers in 2004, and the further work done by several European researchers in 2007. (In fact, the team that produced the 2007 work, which showed the much stronger likelihood of MD5 collisions, also worked with Sotirov and Applebaum.) The latest research simply extended the earlier work and took advantage of some advances in computing power and technology to take it a couple of steps farther than the previous research could go. But for whatever reason, that wasn’t good enough for some people.

I’ve never really understood this impulse to knock down other people’s work in order to try and look smarter yourself. How does that follow? In other news, there are a number of really well-done and readable analyses of the MD5 attack out there, starting with Eric Rescorla’s. He lays out the attack in layman’s terms and describes exactly what new contributions Sotirov and his team made. Nate Lawson also wrote a very useful description of the attack:

The attack is interesting since they take advantage of more than one flaw in a CA. First, they find a CA that still uses MD5 for signing certs. MD5 has been broken for years, and no CA should have been doing this. Next, they prepared an innocent-looking cert request containing the “magic values” necessary to cause an MD5 collision. They were able to do this because of a second flaw. The CA in question used an incrementing serial number instead of a random one. Since the serial is part of the signed data, it is a cheap way to get some randomness. This would have thwarted this particular attack until a pre-image vulnerability was found in MD5. Don’t count on this for security! MD4 fell to a second pre-image attack a few years after the first collision attacks, and attacks only get better over time.

Helpful, cogent analysis of the problem and its mitigating factors without bravado and sniping. What a concept.

December 30, 2008  1:05 PM

Behind the MD5 attack

David Schneier David Schneier Profile: David Schneier

When the researchers who produced the elegant MD5 attack I wrote about this morning realized the severity of what they had found, they took two highly unusual steps. First, they consulted with lawyers from the Electronic Frontier Foundation, describing their findings and voicing their concerns about the potential legal ramifications. The researchers were afraid that if the certificate authorities found out about their work and its implications for the security of their digital certificates, the CAs would move to stop the their talk at the 25C3 conference today in Berlin, at the very least, and perhaps sue them for good measure.

Second, the group approached Microsoft and Mozilla, the two dominant browser vendors, and  explained that they had a serious browser security issue they’d like to share. But first, they needed some assurances from the two vendors that they wouldn’t share what they heard with the CAs before the researchers were ready to announce their findings. So they asked Microsoft and Mozilla officials to sign non-disclosure agreements. It was a 180-degree reversal from the way that these things normally work.

In most cases, researchers who approach a vendor with a security problem are asked by the vendor to keep quiet about the vulnerability until a patch is ready. But in this instance, the researchers held the upper hand and chose not to even tell the vendors what the issue was until they had the signed NDAs in hand. Alex Sotirov, one of the researchers involved in the project, said that it took some negotiations to get Microsoft officials to agree to the NDA, but they eventually signed on. As did Mozilla.

During their presentation on Tuesday, the researchers said they were hopeful that other researchers would follow their lead. And Dino Dai Zovi, a researcher who was not part of the project but who was briefed on the team’s work, agreed. “A letter from a lawyer is usually enough to stop any researcher,” he said. “But showing up with your own lawyer changes the balance of power.”

December 22, 2008  2:28 PM

Nokia to sell security business to Check Point

David Schneier David Schneier Profile: David Schneier

In a move that has been anticipated for some time, Nokia on Monday said it has an agreement in place to sell its security business. What did come as a surprise was the identity of the buyer: Check Point. The two companies have been working together for years, with Nokia deploying Check Point’s software on its own security appliances. The terms of the agreement were not disclosed, though Nokia said it expects the deal to be finalized by the end of March.

“As a pioneer in security appliances, the Nokia security appliance business has been an important strategic partner for Check Point and has helped us achieve early leadership in the security appliance market,” said Gil Shwed, Chairman and CEO at Check Point. “Adding Nokia’s security appliance portfolio into Check Point’s broad range of security solutions is the natural conclusion of our long collaboration, and will assure a smooth path forward for our mutual customers.”

Check Point and Nokia have long provided customers with a range of best-of-breed security solutions, proven in high-performance, mission critical environments.  Nokia’s security appliance business provides purpose-built security platforms optimized for Check Point Firewall, virtual private network (VPN) and unified threat management (UTM) software.

Nokia’s main focus for years has been its mobile handset business, and its security unit has always been something of an odd fit. It’s an enterprise business in the midst of a company that does most of its work selling consumer handsets. Now, with Check Point taking the reins, Nokia will be free to focus on that business, while Check Point can bring the appliances in-house and have an extra revenue stream.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: