IT Security Blog

Proof of concept code has been made available online to take advantage of a newly reported IIS vulnerability that exists on both IIS 5 and IIS 6 that will allow a hacker to take advantage of a web server and give them System level access.

The IIS vulnerability exists in their FTP server in a directory with write access which means that the FTP server must both be turned on and a user (anonymous users also included) must be able to write to a directory in order to exploit the hole. 

The suggested workaround until a patch can be released is to turn off write access to the FTP server. 

Most IIS installations are not vulnerable to this exploit due to the nature of the configuration required to take advantage of it, however it will affect enough of them where it is cause for concern.  Take the necessary precautions to review your IIS web server configuration.  With proof of concept code available online, it will only be a short matter of time before malicious exploits are making their rounds.

*** UPDATE 9/1/2009 9:00pm MDT *** Microsoft has acknowledged the IIS FTP 0-day via the bulletin posted here.  Microsoft is still determining whether or not it will release an out of band patch and does not currently believe that there are any malicious exploits in the wild taking advantage of the vulnerability.

According to this ThreatPost article the main web site for apache.org was hacked earlier today through an SSH key compromise where the intruder was able to gain root access to Apache's server.  The current apache.org site has been redirected to one of its European mirrors while the other server has been taken offline.

While on the machine the attacker was able to replace the ssh (Secure Shell) client and server applications with versions that would log the usernames and passwords of those who were to access that machine.

Although the Apache folks believe that they identified and remediated the vulnerability quickly, and that no software available on the site was compromised, if you have recently downloaded software from the Apache web site, you might want to take a cynical approach and remove and reinstall the software from the uncompromised site that Apache has up now. 

Information is still slowly coming out about this story, and we will likely know more in the coming days.  It is important to note at this point that although Apache believes that they identified and fixed the problem quickly, the possibility remains until we hear otherwise that this server may have been compromised by hackers for some time and that many software downloads had potentially been affected if any publicly available software was modified. 

My advice: Be over-protective.  Keep a close eye on the traffic coming in and going out of your network to look for anything suspicious.  With over 50% of the web server installations worldwide, Apache is a potential high-value target for criminals as any infected software downloads could lead to backdoors in systems that install binaries with embedded trojans.

On Friday morning (like every Friday) we will be taping the next episode of the Security Buzz podcast, and we are looking for your security questions that you would like to see answered.

Please contact us at securitybuzz AT mxlogic DOT com with your questions or thoughts and we'll try to cover them during the next or upcoming tapings of the show. 

Thanks for listening to us on the Security Buzz podcast.  We hope that you find the show both enjoyable and educational!

Byron Acohido of the USA Today poses a question that we have been battling for a long time in his latest piece on GSM conversation eavesdropping.  That question is how much time is enough time to give a vendor to patch an issue before the vulnerability becomes public knowledge? 

The debate rages as to who is should be the one to set the time frame for responsible disclosure?  Should the person who identified and reported the vulnerability to the vendor also be the one to determine that timeframe?  That sounds a bit like extortion to me.  "Fix this problem by the time I say you should have it fixed by else we'll expose you to the world"  seems an awful like someone who is sitting more toward the "black" end of the white/black hat spectrum. 

Should the vendor be the one to control that timeframe based on their knowledge of the risk factors (i.e. how exploitable is this problem?, Is it already being exploited?, What is the potential for damage if it were to be exploited?, How will it affect our market position, amongst other criteria) and other defined priorities?  Should they be held accountable for patching known flaws regardless of these factors due to their fear of being taken to task by the person who found the bug? 

In Byron's article, he specifically mentions a campaign by Karsten Nohl, who is threatening to expose a longstanding flaw in the encryption method used on GSM phones that will allow eavesdropping of conversations to take place.  Nohl mentions in the article that this is already being exploited widely, but is also calling upon the community of hackers to crack the encryption method.  If it is already being exploited (meaning that proof of concept code exists), why is he calling on the community do it?  Isn't that somewhat reinventing the wheel?  I didn't quite follow this path in Byron's article. 

So, what's the point to all of this?  On one side we have "grey hat" (in my opinion this designation is silly.  Grey hat is just a candy-coated way of saying "black hat", but wanting to appear as if you have the public's best interests in mind) hackers who feel like they are the superheroes of the security community by holding threat of humiliation over the heads of companies who don't fix software flaws on their timeframe (Nohl suggests that the flaw he threatens to expose has existed for 15 years.  I am not sure how many of us are truly in the position to either confirm or refute that claim).  One the other we have companies who may have good intentions to fix vulnerabilities, but clearly perform their own internal risk assessments first based on a number of criteria, only a few of which I mentioned earlier. 

In my opinion, the answer to the question "how long should a vendor have to fix a reported vulnerability?" lies with the vendor and with the vendor alone.  Certain factors may cause a company to shift those priorities and release a patch outside of their regular software release cycles or the flaw might be something that doesn't get fixed until the next major software release.  Either way, if you really have the common good (as opposed to your own inflated ego) in mind, you'll let the vendor responsible for fixing the bug do so on a timetable that is acceptable to both them and their customers.  If their customers aren't happy with whatever that timeframe is, don't worry, they'll complain loudly (customers do that :) ) and the vendor will be forced to shift their priorities accordingly.  The process self-regulates that way and leaves the over inflated egos out of it.

Obviously there are many opinions on both sides of the fence on this issue.  So, let's have them!  Feel free to drop me a note at sam AT mxlogic.com or on Twitter as "@smasiello". 

What should we expect from the threat landscape next month?  Here are some highlights from the MX Logic September Threat Forecast that will be posted Wednesday morning:

As we head into September, we anticipate spam levels to remain at all time highs, accounting for more than 9 out of 10 emails sent.  Hackers continue to look for new ways to exploit email and Web for personal gain.  With the web of trust that users generally have with the people they are connected to on social networking sites, we expect to see an increase in spam and malware disguised as legitimate messages from someone the recipient knows.  In addition, as the U.S. healthcare reform debate continues to heat up, there’s a strong chance we’ll begin to see forms of political ‘hacktivism’ impacting the performance and availability of popular social networking sites.

Key findings from August include:

·       Overall spam volume (total number of spam messages) slowed slightly, however spam levels (percentage of spam versus all email) inched up to 94.9 percent of all email sent.

·       The United States continues to hold a slim lead over Brazil with respect to being the country that produces the most spam. 

·       Healthcare remained the most prevalent category of spam.

·       Fake UPS or DHL invoices remain the most popular theme to use with malware  attached directly to email. In fact, this tactic made up 4 of the top 5 malicious email campaigns

 

See the full report: http://www.mxlogic.com/threatforecast/

 

Windows IT Magazine is asking IT pros, DBAs, and developers what they think the best products and services are and so are we. If you have two minutes we’d really appreciate your vote for The 2009 Community Choice Awards in the Best Cloud Computing/SaaS Product or Service category. For some unknown reason MX Logic’s Email and Web Security Solutions aren’t even listed as a choice to vote for. (Given than we have 5 million users worldwide, I’m a bit dumbfounded as to why we weren’t included...) So, we’re asking our readers and partners to let them know about our SaaS offerings by voting and listing MX Logic’s Email and Web Security Solutions in the section titled “Other” in the Best Cloud Computing/SaaS Product or Service category. Thanks and we appreciate your support.

Vote for The 2009 Community Choice Awards:
http://www.surveymonkey.com/s.aspx?sm=8koDpFvpDvDy3ZZZGP9O4Q_3d_3d

Our Threat Operations Center has recently noticed a new type of phishing campaign attempting to phish login credentials to Yahoo!'s Local Search Marketing tool.  This is similar to the Google Adwords phishing campaign that we reported back in May 2008 attempting to obtain login credentials to Google's Adwords site from customers.  In this instance the email that is being sent is spoofing a from address @yahoo-inc.com (Yahoo's internal email domain) and trying to convince the user that their account is about to be suspended.  Sounds like just about every other phishing campaign, right?

The phish reads as follows:

Dear Advertiser,

We just want to remind you that, on August 25, 2009, your Local Sponsored Search account will be discontinued. You will be upgraded to a new Sponsored Search account with geo-targeting and other great new features.

Please note the following: In order for us to upgrade your account you need to verify your user/password of your account. Please remember to input your Sponsored Search user and password correctly NOT your email and password.

Please visit the following link to verify your account:
hxxp://onlinemarketingyahoo.com/adui/signin/loadSignin.htm

Sincerely,

Your Partners at Yahoo! Search Marketing Copyright 2009 Yahoo!, Inc. All rights reserved.


Note the generic nature of the introduction, which should generally be one of your first tipoffs that the email is not authentic.  If you have a personal relationship with a company and they wanted to send you an important email communication they would use your real name.  Also note the missing period between "onlinemarketing" and "yahoo" in the URL.  If you weren't looking closely, this could be easily missed by someone reading the email (even if it were present, the actual URL for Yahoo!'s Local Advertising tool is "searchmarketing.yahoo.com", not onlinemarketing,yahoo.com.  This point might also be missed by the casual recipient.

The potential audience being targeted by this email is somewhat limited because it will only make sense to those who are customers of this Yahoo product.  That rarely seems to stop most spammers.

Wow!  It certainly hasn't felt like 3 weeks since I last posted. 

In case you haven't heard, on July 30th McAfee has announced its intentions to purchase MX Logic.  It all went down while I was at the Blackhat Conference in Las Vegas so I have to admit that I felt somewhat disconnected from everything while the initial excitement was happening at the office.  That changed quickly when I returned though as my staff had (understandably) lots of questions about what the future holds for the company and for them personally.  I feel like the initial FUD, however has turned to excitement as the reality has set in that this acquisition opens up a whole new world of possibilities, particularly as it relates to my Threat Operations team.  McAfee has a ton of threat research data that I personally can't wait for my team to be able to both integrate with and also share.  Just thinking about the possibilities makes me feel like a kid in a candy store.  I think my team can really make a positive contribution not only to the business unit with McAfee that we are about to become a part of, but to the organization-at-large.

All that being said, there has been a lot of work going on internally for the McAfee onboarding process as well.  I know that it has certainly kept management hopping while we have tried to keep our teams focused on business as usual.  It's important that everyone internally focus on advancing what has gotten us to this wonderful point, and that is executing on the plans that we already have in motion.  So far the people at McAfee that I have had an opportunity to interface with have been very welcoming and excited to have us coming onboard.  I can report that from my personal and my team's vantage point, the feeling is mutual. 

Here's to a prosperous, ongoing relationship!