IT Security Blog

In my copious amounts of spare time one of the things that I like to put thought into is where I believe the Threat Landscape is headed.  Even in just the last 10 years since the Melissa virus (yes, I know viruses extend quite a bit further back than that.  I'm just using this as a reference point) we've gone from mass mailing viruses to network worms that run through your network compromising any vulnerable host as quickly as it can to social engineering tricks that sometimes even make it difficult for the trained professional to tell whether something is real or fake. 

So, the question that I pose to myself is "What's Next?"  Taking even just the events of the last decade into account, where are we headed for the next few years?  Some of this is obviously hard to determine because that also involves being able to forecast what new technologies will be released, but we can start to make some assumptions based off of what is available today. 

Since this is a blog post, I'll try to keep this relatively brief.  Maybe it is something that I can submit as an article to some technology pub as a full byline article (Here's a free plug for the folks over at (IN)Secure Magazine, who just released Issue 22 today.  I like them and I've had the opportunity to write for them twice now) at some point soon.

Some things to think about:

-- The Insider Threat
Especially given the current economic conditions and the uneasiness around many offices around the country as to whether or not their companies will remain viable, organizations need to be ever cognizant of the data that is leaving their organization.  Given that the latest USB 3.0 spec that was released in November 2008 allows for data transfer speeds at about 5Gb per second sensitive, proprietary corporate data can be pulled off a company's network an onto a thumb drive faster than ever before.  Couple that with the number of disgruntled employees who either see the writing on the wall for their own jobs or who are upset at benefit and wage freezes/cutbacks, and you have a dangerous cocktail for data theft.  We need to make sure we are putting as much focus on protecting our sensitive assets from insiders who much more easily have access to proprietary data as we do keeping the external threats at bay.

-- VoIP
Voice over Internet Telephony technologies are being adopted at an ever increasing rate.  This is happening not only in the enterprise space, but in the consumer market.  Services like Vonage make it easier than ever for people to have portable phone numbers so that they can be easily reachable at local numbers by family members out of state.  VoIP implementations at organizations are also becoming ever popular as well.  As these technologies become more widely adopted we have started to see hints of what abuse of these tools might look like.  Throw away phone numbers used to make spam phone calls have started to become more common.  There are services available online which allow you to purchase throw away numbers in blocks.  Spammers and can use and abuse these numbers just like they do IP addresses now. 

Another thing to watch out for is the compromise of VoIP systems as vulnerabilities start coming out in larger quantities.  Threats like direct voicemail injection will become another method that cyber criminals will use in order to get advertisements delivered to end users.  As the social engineering used in these threats improves, they could easily be used to steal personal identities and corporate data. 

-- Mobile Malware
Let's face it.  The phones that we carry in our pockets are little personal computers.  Although they lack the computing power of the quad-core processors now becoming commonplace on personal computers, they are another "always connected" device that people always have turned on.  I think the only time that I turn mine off on a weekly basis is when we are doing our weekly recording of the Security Buzz podcast, and that is mainly because the GSM buzz wreaks havoc with the microphones (and our Executive Producer's headphones :) ).  As mobile phone manufacturers have opened up their APIs to developers to create third party applications, they will need to be ever diligent in their QA processes to make sure that applications don't get posted to their distribution channels that contain some form of malware or open up a trojan backdoor to the device.  The mobile phone industry is growing by leaps and bounds with the addition of new, better, more feature rich smartphones entering the market.  The smartphone market is too large of a target for cyber criminals to ignore, especially if you consider the value of the data that we are now storing on these devices.  Secure sandboxing of third party applications is a must, but that is only a start.  Only hundreds of mobile malware variants exist today (compared to the approximately 1 every 4 seconds that is released for PCs), but that number is slowly growing and as hackers pay more attention to how they can penetrate mobile devices, that number is sure to only increase.

-- Social Networking
Social networks provide an interesting shift in the information sharing game because the rules that typically govern what personal data people are willing to share seem to have gone out the window.  This has really opened the door for cyber criminals.  With the data that is now available online through the use of social media sites like Facebook, Myspace, and Twitter criminals can much more easily target attacks to specific individuals or groups of individuals using data made available via public profiles or geolocation tools that map your IP address to what town you live in (or near) so that they can deliver compelling content which direct you to malware infected downloads (ala the Waledac botnet).  The Web of Trust that exists between users on social networking sites is being actively exploited regularly by hackers looking to take advantage of the fact that users will click on whatever their friends send to them.  It's already been proven that people will click on links and open attachments from people they don't know so why would they judge more closely the content from those that they do.

-- Political Hacktivism
Recently cyber criminals have picked up the pace a bit with respect to using online resources like social networking sites to quickly spread political messages in order to help them spread propaganda and recruit people to fight for their cause.  Due to the sensitive nature of political issues and the passion that people have for them, social engineering techniques like creating highly controversial views on sensitive topics is something that cyber criminals will latch onto in order to get people to react quickly and irresponsibly to either open attachments or visit websites that they would normally scrutinize more closely. 


These are only a small sampling of what I believe we will be encountering as we move forward (I didn't even go into the increased prevalence of compromise of legitimate web sites, and the further use of file sharing services, and calendar spam!), but they are things that we will need to keep top of mind as we look toward what threats are coming down the road.  Hackers will go where the money is and the money is where the people are.  So, whether it is Twitter, MySpace, Facebook, email, instant messenger, or our phones, criminals will leverage whatever technology is available because in their eyes the goal is to make money regardless of the available technologies, and if one person can be the one to figure out how to exploit a technology for their own financial gain before the others they'll end up getting the lion's share of the notoriety as well as beat defense mechanisms to the punch.

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.

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". 

Today Microsoft will release two out of band patches: one to address a vulnerability in Internet Explorer that is rated as "critical" (which typically means that there are exploits available in the wild that predicate the need to have to release an update outside of the normal "Patch Tuesday" schedule which occurs on the second Tuesday of every month.  The second patch is rated as "moderate" by Microsoft and affects Visual Studio. 

It is recommended that any out of band patches released by Microsoft be tested before being deployed on any systems, particularly those critical to the function of your organization.  After the patch has been tested in your environment, deploy it is quickly and as responsibly as possible in order to minimize your window of exploitation.  Again, generally when out of band patches are released, exploits are already available in the wild.

For more information about the patches being released today see Microsoft's web site.  More information will be posted on the details of the vulnerabilities being patched after Microsoft releases the updates.


*** UPDATE 7/28/2009 12:00pm MST *** Microsoft has released the security updates and has named them MS09-034 and MS09-035.  MS09-034 is a cumulative update for Internet Explorer and MS09-035 is an update for the Visual Studio Active Template Library (ATL).  Both vulnerabilities allow for a remote hacker to execute arbitrary code on your system.  This includes the ability to install a backdoor or Trojan on your PC.  As stated before, please test and deploy these patches as soon as you can.

 

As news of the most recent Twitter breach spread and details of what was compromised started to come forth the question that was at the forefront of my mind was "Whatever happened to responsible disclosure?" where you notify the vulnerable party, give them ample time to fix the problem, and if any information is released publicly, it is done after the problem has been confirmed resolved by the vendor.

According to the article on TechCrunch that contains data that was stolen, they "spent much of the last 36 hours talking directly to Twitter about the right way to go about doing that" (where that = the right way to go about releasing the data).  Now I was certainly not privied to those discussions, but I have a hard time believing personally that those discussions involved Twitter saying "yes, please post the information, but just leave out the secret sauce bits."  I don't understand what criteria TechCrunch used such that they are now the governing authority over what is and is not confidential or why they feel they have a right to make that call to begin with.  I am disappointed that a purportedly reputable news organization would feel that they have such privilege. 

In a follow up post TechCrunch attempts to justify their actions by pointing to previous cases where they and another news organization had each taken it upon themselves to post sensitive information.  I guess that means that since there is a precedent for something happening that it somehow makes it right?  They also state within this article that they "break big stories."  Obviously, those that break the big stories get the big press, but let's not also forget that a certain level of responsibility is expected as well.  Saying that "others do it too" as justification for doing anything is just plain juvenile. 

Of course, let's not let the person who leaked the information to TechCrunch off the hook either as they are certainly culpable as well.  At this point nobody seems to know who that person is (at least not publicly).  This mystery person submitted the information with the expectation that it would get published.  Otherwise, why send it to a news organization to begin with.  They baited the hook and TechCrunch bit down hard. 
Whether TechCrunch will end up facing any legal action from Twitter remains to be seen.  Twitter might want to consider at least sending TechCrunch a thank you note for at least temporarily turning the stink-eye from this whole mess away from themselves as TechCrunch appears to be getting flamed worse than Twitter, who had the breach to begin with!

Funny how things work sometimes :)

It looks like the Hack du Jour, Twitter, has had another high profile data breach.

It seems like we have been around the block on this topic before on a couple of occasions, haven't we?

According to TechCrunch the cause of this most recent data breach isn't stolen Twitter account credentials because of ClickJacking exploits or people who have given up their logins because of look-alike Twitter application sites.  This exploit was far more elementary and one that Twitter could stand to learn a lesson from on their own account signup form: weak passwords.  According to the TechCrunch article, the password to some of Twitter's publicly facing servers was "password".  Maybe they thought that was too easy for people to guess and that nobody would actually try a password as simple as "password" ?  Either way, this is another example of how Twitter needs to take its own security and the security of its users much more seriously.  Strangely enough repeated lapses in judgment does not appear to have slowed their growth.

The portion of the MSNBC article that I linked to in the first paragraph that irked me the most was in the section titled "Dangers Highlighted" where the author states that "The techniques used by the hackers to obtain access to Twitter highlight the dangers of a broader trend promoted by Google Inc. and others toward storing more data online, instead of on computers under your control."  I couldn't disagree more with this statement.   The missteps by Twitter that have caused their recent compromises are not a result of a lack of standards or good security practices by cloud computing, SaaS, or other off-network service providers.  They are a result of Twitter's poor security practices and Twitter's alone. 

Any service provider, construction outfit, or home business who has their own network equipment needs to ensure that they have taken proper precautions to secure those devices.  That includes changing default passwords and identifiers (like SSIDs on wireless access points) all the way through to keeping those devices up to date on security patches and application updates.  These are not practices that are relevant to Cloud Computing providers alone.  To insinuate such in an effort to spread FUD against these types of services is downright irresponsible, in my opinion.  We're talking about best practices that need to be employed by everyone in all industries and form factors.  Perhaps if we did that instead of just talking about it and always looking to point the finger at someone when they make a mistake we would have less people to point fingers at.

Roger Thompson, Chief Research Officer at AVG Technologies, said in an article posted on Network World that the latest vulnerability in Microsoft's Video Controller ActiveX library could be the next Conficker. 

I very much disagree with that sentiment. 

Conficker was similar to the Slammer worm from back in 2003 where there was no overt action required on the part of any individual person to get infected.  You could get infected simply by being out of date on security patches.  The current Directshow exploit requires a user to visit a malicious web site (links to sites hosting the exploit code are currently being sent out in spam emails) to get infected.  Also, the user must be an admin on their computer to get infected by the Directshow exploit.  Most people do run in this mode, however so that won't be much of a hurdle to clear, but the requirement that a user must visit a web site hosting malicious code is a tactic that users are becoming more accustomed to avoiding. 

There are some similarities here that are worth pointing out, however.

For starters, there are claims that Microsoft knew about this vulnerability well in advance of exploit code being released for it, but neglected to patch it.  This makes sense considering Windows Vista and Internet Explorer 8 are not vulnerable to this exploit, but Windows XP and Internet Explorer 6 and 7 are.  This does beg the question though as to why Windows Vista is not vulnerable since it has been out for well longer than the exploit has supposedly been known by Microsoft.  This is similar to the Conficker situation because the MS08-067 vulnerability that allowed that worm to appear was also being exploited for about a month prior to Microsoft releasing an out of band patch for it.  Unfortunately, at that point the damage had already been done and regardless most of the machines that were infected with Conficker are running versions of Windows XP that had never installed a single Microsoft security update (see research at http://mtc.sri.com/Conficker).

Anyway, I digress from my point.  Although I do believe that the Directshow exploit is significant and that the out of band patch that Microsoft released to address it is absolutely the right thing for them to have done (as opposed to waiting for their typical Patch Tuesday release next week), I believe it is blowing the situation out of proportion to say that this will be the next Conficker.

Poisoning search results with content that leads unsuspecting users to spam or malware content is nothing new.  We've been seeing abuse of Google's PageRank system since early 2008 where spammers would artificially inflate the rankings of their spam web sites and send out email links which emulated the click of the "I'm Feeling Lucky" button on Google's search page to auto-redirect users through Google to fraudulent web sites. 

We are now seeing something similar with Twitter.  According to this post on Mashable's web site, spammers are using the accounts that they are setting up on the popular micro-blogging site to increase the ranking of certain topics so that they will appear in the list of Twitter's most popular topics and organically increase clickthroughs.  In some cases the sites that users are being directed to also can inject malware.

Be careful with these sites because as we have seen with some other Twitter exploits, the possibility exists that you could also have your account credentials stolen and used as another vehicle for distributing Twitter spam.  Twitter has been built to be easy for end users to use and interface with.  This methodology has been great to drive user adoption.  The unfortunate side effect that because of its popularity it has been an increasingly focused target for cyber criminals.

Be on the lookout this morning for a phishing scam floating around Facebook asking you to visit http://areps.at, a domain registered only a few days ago to someone named Andrew Morov out of Russia.  (UPDATE 5/21/2009 11:30am MST - According to this CNet article, the domain bests.at is also being used for this scam, registered to the same person as areps.at)

personname:     Andrey Morov
organization:   
street address: Schelkovskiy proezd d.11 korp.1 kv.3
postal code:    105425
city:           Moscow
country:        Russland
phone:          +74956211281
fax-no:         +74956211281
e-mail:         ******@nameclub.at
nic-hdl:        AM5009456-NICAT
changed:        20090515 15:23:43
source:         AT-DOM

Visiting this site will also infect your Facebook profile and cause messages to be sent to your friends inviting them to also visit.  Below is a screen shot illustrating the contents of the message you may receive from an infected friend.







If you do receive any of these, contact the person who sent it to you and ask them to change their password ASAP.  If you believe that you might have fallen victim to this scam, change your own profile password before whoever has hijacked your account changes it for you and locks you out of your own account!

Just as a general Public Service Announcement, if you are interested in Cross Site Scripting exploit news, and if you are not following @xssexploits on Twitter, do so (and of course follow @smasiello too :) ).

The reason that I mention that is, in addition to wanting to stay up to date on some of the latest XSS announcements, @xssexploits is also one of the first places that I was informed about the recently made public XSS vulnerabilties found on several McAfee web sites. 
So, why are these exploits of consequence?

One of the sites mentioned as being vulnerable to cross site scripting vulnerabilties is McAfee's Rebate and Promotion Center web site.  One of the fields that a user must populate when filling out the form to obtain a rebate is the date that you purchased one of McAfee's qualifying products in mmyydddd format.  By using a technique known as HTML code injection a user could get redirected to another (potentially malicious) McAfee look alike web site used for phishing unsuspecting user's sensitive information or a malware distribution site that looks like an official McAfee web site. 

Many security vulnerabilities are introduced by software not doing proper input checking.  Following a "whitelist model" where as part of the input checking code you specify the valid types of input as allowed (generally a small list) as opposed to identifying all of the input that is not allowed (a much larger list) is common practice.  In this case, it doesn't appear as if the form was doing any kind of input checking.  Why the form would allow HTML characters such as quotation marks, less than, and greater than symbols in a field that is clearly expecting only numerical input is only asking for trouble.

I am not trying to pick on McAfee here, but they are a prime example of the reality that if it can happen to a company where security is their business you would expect them to have a pretty keen eye towards security vulnerabilities within their own web site.  Back in January, CWE and SANS posted their list of the top 25 programming errors that occur most frequently within applications and Improper Input Validation is at the top of that list.  It tops the list because it is the most common flaw and because it is the easiest to exploit.  Improper input checking can be exploited with even the simplest of test cases which means that even your lowest level hacker who only knows the bare minimum about XSS and code injection could take advantage of this flaw. 

Protect your brand.  Protect your web site.  Protect your users.  Follow secure coding practices and incorporate a security mindset into the products and applications that you build.  You don't have to be a security company to think securely.

I wanted to take a moment to write about a topic that we discussed during the recording of Episode 29 of the Security Buzz podcast earlier today.  That topic is based off of a post found on DarkReading that discussed Microsoft's decision to release an update to disable the Autorun feature in Windows for USB drives in response to the variant of the Conficker worm which would spread via these devices.  The question at hand was whether or not this move is happening too little too late given Conficker's already large presence.

My opinion is that not only is the move too little too late, but it is also a completely irrelevant one for the main reason that according to the folks over at mtc.sri.com, who have posted in depth research as to how the Conficker worm operates, most of the machines that are infected with this worm are still running versions of the Windows XP operating system with Internet Explorer 6 installed on them.  This means that most of the machines infected are not one or two patch levels behind on their updates from Microsoft.  They are likely years behind and have never been patched, and may in fact be running the original version of Windows XP originally released in October 2001 and have never had a single security patch applied to them meaning that they are vulnerable to every Windows XP vulnerability ever patched.

USB drives, although an important infection avenue to consider (although in my opinion are more of a risk from a data leakage perspective than they are a malware distribution point), are still only a small portion of the infection problem.  Emails with attachments, malicious web sites and compromised legitimate web sites that distribute malware, and peer-to-peer downloads of pirated software with embedded trojans are all far more prevalent issues with respect to current worm and malware propagation than USB drives. 
Unfortunately, this move by Microsoft will do little to solve the Conficker problem or slow its' spread.  It also will not do much overall to prevent further malware propagation in the future because the machines that need to be cleaned up are not the ones that are following best practices by keeping up to date on security patches, running up to date antivirus, and defending in layers.  It's those that aren't are and continue to be the real problem.

The folks over at SecurityFocus have published yet another Adobe PDF Reader related vulnerability.  No exploits have been seen in the wild at this time taking advantage of this flaw, but unless patched quickly by Adobe will likely come in short order due to the prevalence of Acrobat Reader in the wild and the success of previous exploits. 

This is in no way an endorsement of this product, but if you are looking for an alternative to Adobe's PDF reader, consider looking into FoxIt Reader by FoxIt Software.  As with any software, it has its own vulnerabilities that have been patched, but since it isn't as widely used has not been as highly targeted as Adobe's products.  There are other alternatives available as well.  Consider looking into them if you frequently find yourself opening PDFs as part of your daily professional or personal responsibilities.

Just about anyone and everyone who is active on the internet is either using, has used, or at least has heard of Twitter, the micro-blogging service that grew in usage by 752% in 2008 and is poised to grow even more in 2009. 

As we know, where there are users, there are hackers.  Any technology that has grown in popularity at the speed of which Twitter has is certain to become a target for information and money stealing cyber criminals.  As such, Twitter has been the target of several application exploits over the last few months including a Samy-like exploit which would force users to follow you, multiple Clickjacking exploits, and two worms dubbed Mikeyy and Stalkdaily just this past weekend.
Funny enough, one of the things that is frequently part of the fallout of numerous security exploits is a drop in brand trust and user confidence.  So far, that fallout does not appear to have taken place with Twitter.  At least based on the reported numbers, Twitter's growth does not seem to have been hampered at all despite the numerous security flaws that have been patched over the past 8 months.  Perhaps this is because there hasn't been a serious incident of data theft or widespread malware infection as a result of one of these exploits.  Rest assured, those are coming!

So, what can we learn as a result of Twitter's recent security woes? 

I believe that one of the most important lessons to be learned from Twitter is the need to ensure security is being built into your product from the concept and design phases, not after the code has been consumed by the public.  This is true for online applications like Twitter as well as boxed software that you buy in the stores.  Don't let your customers be your test bed to identify security risks because you can bet that criminals will find them and exploit them before your customers do.  At that point you have put your customers at risk also.  It is far cheaper and less damaging to your corporate brand and reputation if security risks are identified up front, before any code is launched than to try to retrofit security into a live product.

Up to this point the vulnerabilities exposed on Twitter have largely been considered annoyances.  I was unable to find any reports of identity or financial theft as a result of a Twitter exploit, and again perhaps that is why they haven't been placed under the same microscope that Microsoft and Google have been.  Don't take these proof-of-concept quality threats lightly though as they could easily have been much more nefarious than they were.

Let's take the Mikeyy worm as a primary example.  One of the ways that Mikeyy would spread is by sending Tweets out under the accounts of infected users trying to lure their followers to visit the profile of another Twitter user that exploited a site flaw.  Once that page was visited the user's account was hijacked and Tweets would be sent out as them to their followers trying to trick them into clicking also.  Rinse and repeat.  In this instance the worm was merely spreading out across Twitter to anyone who was fooled into clicking the link presented in the Tweet.  What if this link was forwarding unsuspecting users out to a drive by malware site that installed malware like Storm or Conficker?  In a previous post we discussed how URL abbrevation services can potentially hide an underlying threat vector to redirect users to malware drive-by or phishing sites.  Granted, that example isn't one of a specific Twitter flaw, but it is just another thing that users of the popular service need to be on the lookout for.

In its short existence Twitter has almost single handedly revolutionized how we communicate (in 140 characters or less :) ) online.  Whether you are using Twitter to communicate with friends from school, family, or professionally to keep up on market trends or as another method to increase your brand awareness (a recent report by comScore said that more than 50% of Twitter users are between 25-54 with most users being on the upper end of that scale), Twitter has stormed onto the social media scene and has already become an important part of how people communicate online.  I use it myself.  As such, it creates another avenue by which we need to make sure we educate ourselves and our users about the potential for online threats.

According to a post on the Microsoft Malware Protection Center site last Friday, Conficker has a copycat cousin named Neeris that has been updated to exploit the same vulnerability that Conficker started targetting in September 2008. 

Neeris is not new on the scene and originally came to be known a couple of years ago by exploiting a different vulnerability, MS06-040 (patched in August 2006 by Microsoft), in the Windows Server service (Conficker also exploits this same service).  This latest Neeris update targets the same vulnerability as Conficker, MS08-067 in addition to MS06-040. 

From the Microsoft blog post, Neeris contains many of the same propagation methods as does Conficker such as spreading via removable drives.  Neeris is primarily an IRC based bot (a dying breed) that spreads via links sent in MSN Messenger instant messages to attempt initial infection.  Once a PC is compromised, it attempts to download the actual worm code via the HTTP protocol.  Once this happens, Neeris then attempts to locate other machines on the network to infect.
It was only a matter of time before the Conficker copycats would start showing up as riding on the coattails of previously successful malware is a fairly common tactic.  It is somewhat interesting that in this case there were not many updates made to the original malware, which made it easy to identify and stop by commercial AV software vendors.  In Microsoft's case, it was identified by generic signatures that they already had in place from the original Neeris launch.  This is another one of those situations though where if computers and servers had been kept up to date on patch levels from the beginning, this attack could have been mitigated.

I am guessing that most people are suffering from Conficker information overload today!  As such, it is very important to be able to separate the Conficker Facts from the FUD.  In case you have not yet seen it, I blogged last week about what I believe will (not) happen when the Conficker.C variant activates tomorrow, April 1st.  Up to this point we still have not yet seen anything that would lead me to believe anything contradictory to that statement.

I read a couple of places yesterday about a flaw in the C variant of the Conficker worm that identifies infected machines on your LAN differently than machines that are not infected.  According to Dan Kaminsky's blog, this flaw causes a function named NetpwPathCanonicalize() to work differently in the infected version than the version in either the patched or unpatched versions of the Windows OS.  This different behavior is what folks like McAfee, Nessus, Qualys, and others are using to key on to develop a scanner to identify infected hosts.

Although a tool is great to identify machines already infected with the Conficker worm, it is more important to emphasize and re-emphasize the importance of patching and multiple defense layers (from out in the cloud all the way down to the network endpoints) to mitigate these types of infections to begin with.  In the interim, if you believe that machines on your network may currently be infected with the latest Conficker variant download the proof of concept scanner and put together a quickly actionable plan to clean these machines up.

Word is spreading of a botnet called Psyb0t that is going around and compromising the home routers of people who have not changed the default login password on those devices.  According to published numbers around 80,000-100,000 Linksys and Netgear routers have been affected by Psyb0t.  It is important note there are a couple of criteria that must be met before your router can be exploited via Psyb0t.  First, the router must be a MIPS device (x86 devices are not vulnerable to Psyb0t).  Second, it has to be configured to be administered remotely (from the internet, not the local LAN), and third it needs to be using the default password that the device was originally configured with (a common insecure practice).

Although Psyb0t is the first botnet alleged to be exploiting home routers, the concept of compromising routers with default passwords is not a new one.  One of the things that I have the honor of doing as part of my job is a quarterly section for SC Magazine called the "Threat of the Month".  The piece that I submitted for their February 2009 issue was on the topic of "Drive By Pharming".  Essentially what drive by pharming entails is the compromise of home routers that have the "Remote Administration" port enabled so that you can modify their settings from the internet.  If the factory password is still set as the password used to login to the device it is trivial for an attacker to get in, modify your settings to point you to a malicious DNS server such that traffic to legitimate sites gets repointed to sites setup to phish passwords or inject malware.  That is only one possibility.  Another is that a new version of firmware could be uploaded to turn the device into a bot. 

At their core, these home routers are mini computers, susceptible to attack and infection if proper precautions are not made to protect them.  Default passwords for just about every router made are trivial to find on the internet.  In fact, there are sites setup, like routerpasswords.com, that allow you to select the manufacturer of the router and it will tell you the default password based on their known models.  Be sure to secure all layers of your home or business (plenty of SOHO businesses use standard Cable/DSL modems for their internet connectivity) network.  Never assume that this is being done by someone else or that it is someone else's responsibility.  The default settings on most of the gear that you will buy are setup such that initial access and administration of the device is easy (reduces support costs and angry customers).  From there it is up to you to make sure best practices are followed to keep your network and data secure from outside intrusion.

I have been starting to feel like I have hardly been in the office over the past month.  After attending MAAWG in San Francisco for a week in mid-February I was in town for a week and a half before going on an extended vacation/business trip to Orlando for InfoSec World 2009 and some time visiting my wife's family.  I am finally back in town and expect to be so for about the next month until RSA rolls around in late April so expect to see regular blog updates rolling out again.

I wanted to take a few minutes to talk about something that has kind of been bothering me lately.  It is something that I have been hearing more and more of in passing conversation as it relates to browser security, in particular between Firefox and Internet Explorer.  Similar to the debates that have been raging for a few years now between the "security" of Apple's OS X (and previous versions) as compared to Microsoft Windows are debates between how using Firefox is a more secure browser than Internet Explorer. 

Is it, really?  Or Is it just a matter of perception? 

At the end of the day, the level of security of any application installed on our computer is a combination of the vendor's ability to release timely updates to address new security issues, and the user's ability/willingness to install those updates.  The discussion about application security is completely irrelevant if user's do not install the updates that the vendor provides. 

Take this recent analysis of the Conficker worm/botnet as an example.  According to the report, more than 90% of the users who got infected with Conficker got infected while using Internet Explorer 6, the default browser that comes with Windows XP.  Windows XP is also the OS that has the highest concentration of infected Conficker users, but that is to be expected as it is currently the most deployed Windows OS version.  What this tells me is that many users who are running Internet Explorer 6 are not keeping it up to date with updates and patches.  This is also somewhat to be expected because the largest concentration of infections are in countries like China, Brazil, Russia, and India who also have some of the highest numbers of pirated copies of Windows in the world.  You could argue that this might not be the best example of browser security because Conficker is an exploit for an OS level vulnerability, but the reasoning is still sound in that if you aren't applying OS patches you likely aren't patching your browser either.  If you aren't familiar with the "insecurity iceberg" report, I would recommend it.  It is a good read as it outlines browser and plugin usage across many different data cross-sections to illustrate that browser security is about more than just the browser.  It also includes the many plugins that are available such as Adobe Flash, Java, Apple Quicktime, and Adobe PDF Reader. 

So, to go back to my original question, is Firefox really more secure than Internet Explorer?  In addition to my previous argument about patching, I believe this also comes down to an issue of perception.  For example, Firefox releases security updates more frequently than Internet Explorer.  Does that make it more secure or less secure?  Additionally, Firefox has a "nagware" type of feature where it regularly throws popups at you when a new version is available encouraging you to upgrade to the latest and greatest version of the browser.  This gives the impression to the user that they are being kept safer.  Second, Firefox has an active community of developers creating plugins for Firefox that help create additional security features on top of what the browser already provides.  Neither Firefox nor IE have any native protection against what is known as Clickjacking.  With Noscript, a plugin available for Mozilla based browsers like Firefox (et al), Clickjacking protection can be added.  IE currently has no protection available although it is being planned for IE 8.  Another security threat that I have written about previously is the danger that can be introduced by URL abbreviation services like TinyURL and SnipURL.  Firefox has a plugin that will allow users to preview where these abbreviated URLs will really take the user before they click the link.  URL abbreviation services are being used more and more by phishers and malware creators to trick users into clicking on legitimate looking links and redirecting them to malicious web sites.  So, there are security related addons that users can plug into their browsers if you know what the good, actively maintained ones are and know where to look, but this functionality isn't native to the browser and leaves the user with having yet even more software to have to update.

You could make analogies between the OS X and Windows debate here too.  Apple users claim they don't have the malware problem that Windows users have.  In sheer volume of released exploits, this is certainly true, however you are also dealing with a much smaller market share.  Is the reason that Firefox exploits haven't been more widely targeted that they just don't have the market share to support the effort on the part of cyber criminals? 

My point is that there are compelling arguments on both sides of the browser security war debate, but at the end of the day is onus is still on the user to make sure their software (includes both browser and plugins!) is patched regularly, and that they are employing additional security measures like anti-virus and outbound traffic blocking firewalls to reduce their risk.  More online threats are moving to the browser every day so having multiple layers of defenses in place at different points of the network remains your best method to minimize risk. 

Today, Adobe has released a patch to address several vulnerabilities within the Flash player (versions 10.0.12.36 and earlier) whereby a specially crafted SWF file could result in a buffer overflow that could allow an attacker to execute arbitrary code on the unpatched system.  These patches are to fix an input validation issue that could result in a denial of service, mitigate a couple of clickjacking issues, and a potential privilege escalation issue.

It was not clear from the advisory as to whether or not there is code in the wild currently exploiting any of these vulnerabilties (although I could not find any other announcements that would lead me to believe that exploit code exists).  I believe that this begs the question as to why a Flash Player update is being released in advance of any malicious code when verified exploit code is already in the wild for Acrobat and Acrobat reader?  I am all for releasing patches proactively, but I would like to see an explanation from Adobe as well as to why we still have to wait 2+ weeks for the Acrobat [Reader] updates.  I don't quite understand the prioritization here.

Adobe has released a security bulletin warning users of a new vulnerability found in both their Acrobat and Acrobat reader products for which an exploit is currently available in the wild.

According to a post by the folks over at shadowserver.org the exploit requires Javascript to implement so in the meantime it is recommended that you disable JavaScript in Adobe Acrobat and Adobe Reader in order to mitigate this vulnerability.

Adobe is aware of the problem and is said to be releasing an update to fix versions 9.x on March 11, 2009 with an update for 8.x versions shortly afterward followed later by 7.x updates. 

If you wish to signup for security alerts from Adobe on their products so that you can be alerted when new security advisories are posted you can do so here.

In an article posted today by SC Magazine Andre De Mino, founder and director of shadowserver.org warned that he expects exploitation of this vulnerability to be widespread based on users' frequent willingness to trust and open PDFs.  I would agree. 

One of the topics that we discussed during Episode 18 of the Security Buzz  podcast (and also reported other places, like here) was a reported design flaw (Microsoft said this was working as designed, albeit it was poor design) in the Windows 7 UAC that would not prompt for confirmation when the UAC notification settings were being changed.  This left the door open for malicious code to come in (proof of concept code is available online.  Buyer beware as this code WILL change your UAC settings, so be sure to change them back!) and change your UAC notification settings to never prompt for confirmation when system changes were being made.  So, not only would you no longer receive notifications going forward, but because of this design flaw you wouldn't be prompted before the initial change was made either. 

Microsoft had said that this feature would not be changed prior to the next release of Windows 7, but in the face of public scrutiny has decided to back down on that stance.  There are a lot of philosophical discussions as to whether or not UAC, originally introduced in Windows Vista, actually improves security at all.  If this feature is going to be the most in your face, user visible element of the operating system's security, they better darn well get it right.  In my opinion, this was a good move by Microsoft.

Following on the heels of last week's announcement of a trojan horse being installed as part of some pirated copies of iWork '09 for the Mac being distributed on peer-to-peer file sharing services comes another announcement that a trojan has also been identified in pirated versions of Adobe Photoshop CS4 for the Mac.

No word yet on whether the new Photoshop trojan was created by the same people who created the iWork trojan that was used to launch DDoS attacks. 

It is important to note that these trojans do not attempt to infect other computers, rather they stay resident on the local machine.  Since the trojans run as root, it is possible that once it has been installed it could be used to affect other applications.  Since these trojans also have a phone home component it could (not confirmed) be used for information theft as well.

Trojans being distributed via applications shared through peer-to-peer file sharing services are nothing new in the PC world, but have recently been garnering more attention for Macs as Apple's computers have been gaining market share.  The Mac fallacy of invulnerability is being challenged more frequently now.  It looks like Apple has finally gained enough penetration into the computer market that cyber criminals are targeting them and their users with more regularity.  This is a trend that will certainly continue especially if you consider the number of Mac users who have resisted purchasing security software in the past.

Yesterday, security experts from more than 30 United States and international cyber security organizations jointly released a list of the top 25 most dangerous programming errors that lead to security bugs and are enablers for cyber crime according to this article posted on sans.org.

Most security professionals speak to these coding standards fairly religiously, but the article points out something that I don't think we talk enough about.  That is, ingraining secure coding practices into software developers during their education at the high school and college levels.  As it stands now, software development courses taught at most schools (at least this is how it was when I was in high school and college, so if there is a more dedicated effort on secure coding practices now, please correct me!) focused on the results of the application (i.e. what is the output and does it match what was expected), but did not enforce proper boundary and input checking to ensure that the application could not potentially be compromised in a real world situation.  As a result, programmers entering the business world aren't used to coding for these exceptions which end up leading to applications that crash frequently when put in the hands of users.  As the article also mentions, if these best practices are part of how software developers are taught to code from the beginning businesses will receive the trickle down effect of having better applications released from version 1.0 which decreases the company's risk of a security breach and embarrassment.

If your organization is one that is responsible for developing software applications, be sure your coding standards also include ensuring that best secure coding practices are being followed.  Do not just do this for new application development.  Be sure to review your existing code base to incorporate these standards there as well.  You'll reduce the number of bugs that have to be fixed later as users uncover unhandled exception cases, and you'll improve the quality of your product overall.

It is a bit of a long read to get through all of the recommendations, but I would encourage you to take the time to read and evaluate how these best practices can be incorporated into your own software development processes if they are not already.  If you are an educator and teach classes on software development, look for ways to integrate these practices both into your teaching, but into how you do code evaluation.  If you are a software developer, start using these practices in your own coding and encourage your colleagues to do the same and make these part of your required coding standards before code is released into your "production" environments.

Security awareness concepts reach far beyond teaching users what they should and shouldn't click on and what web sites they should stay away from and where it is and is not safe to provide their personally identifiable information.  It also extends down to your company's SDLC and releasing rock-solid code. 

There has been quite a bit of press over the last day or two with respect to a design flaw with SSL that could allow an attacker to forge a security certificate such that it circumvents the built-in authentication methods within your browser.  This means that your browser could believe that a malicious, look-alike web site for your bank could authenticate to your browser as your real bank web site if this attack is carried out correctly.  See this story from CNET that has a graphical proof of concept example using Bank of America.

If you are not familiar with MD5, essentially it is a 128-bit hashing algorithm that is used by many security applications.  For example, an MD5 hash is commonly used as a checksum by system integrity validators (SIV) to ensure that key binaries on your system have not changed their default composition (if they have, this could indicate a trojan or rootkit has been installed on your system). 

MD5 checksums have been known for some time to not be completely secure as it is typically expressed as a 32-bit hexadecimal number.  This means that there are only a finite number (2^128) of potential hash possibilities.  This has been considered to be good enough for many applications, but with the power of today's clustered computing environments (also including botnets), it has been found that the time it takes to generate a targeted MD5 collision has been greatly reduced.  According to the CNET article, performing the initial forgery proof of concept took about 2 weeks on a cluster of 200 Playstation PS3s.  This kind of computing power is infinitesimal compared to most botnets.  Quite a few articles on the web (do a Google search for "md5 collision example" and some will yield source code) already discuss how easy it is to create an MD5 collision. 

Web site forgeries are only one example of how MD5 collisions can be used to circumvent security technologies.  My friend Adam O'Donnell from Cloudmark points out in a Twitter update that an MD5 collision could also be utilized to make malicious software look legitimate.  Take our SIV example from earlier.  If a malicious version of a binary was created with the same md5 checksum as its legitimate counterpart, your security checks may never identify that the original executable was modified if your PC were to get infected with some type of trojan or rootkit.  This could also cause AV companies to have to rethink how they do some of their own scanning methods also.

What all of this really highlights is the fact that MD5 is no longer a "good enough" (and in reality hasn't been, but that hasn't stopped people from using it) hashing algorithm if your intention is to create a hash that will be used as part of any kind of security/authentication system.  I agree with Paul Kocher's statements from the CNet article in that although this is certainly not one of the biggest security issues facing us right now.  Between all of the other application based attacks that exist, this one could be potentially very dangerous as it is another one of those that we have discussed that do not require elaborate social engineering to be carried out effectively (at least for web site forgeries) as the redirection to a malicious site can be carried out at the network level. 

This is not one of those types of attacks that is likely to occur on a large scale against many widely used web sites (like the Bank of America proof of concept) as it would likely get sniffed out very quickly, but if used for smaller, more localized attacks could prove to be effective. 

For the last two out of three months Microsoft has released an out-of-band patch to fix a critical vulnerability in one of its applications.  Today they are releasing an update to patch a critical vulnerability within Internet Explorer.  The patch addresses an XML handling bug within the browser that would allow an attacker to inject malware onto an unsuspecting user's computer merely by visiting a compromised web site.

Back in October Microsoft also released an out-of-band patch to address a vulnerability in the "Server" service which affected many versions of Windows XP and Windows Server 2003.  This new update is right on the heels of a record setting Patch Tuesday on December 9th where an incredible 28 patches were released with 23 of them carrying a "Critical" rating.

Since I have had a couple of people ask me the question, I figured it was appropriate to address the question here.  That question is "What does an out-of-band patch mean?"  In this context I am referring to an update that is released outside of Microsoft's typical update schedule.  The second Tuesday of every month is widely called "Patch Tuesday."  This is when Microsoft releases its software/application updates for the month.  Many of these patches are security related.  When a patch is released on a day other than Patch Tuesday, like today, it is then considered "out-of-band."

This is an especially critical vulnerability to patch as soon as possible as exploit code has been available and hackers have been taking advantage of this vulnerability for about a week now.  Typically following "Patch Tuesday" is another common term called "Exploit Wednesday" (which is likely when this exploit was released into the wild).  Exploit Wednesday is when new exploits are commonly released which either address new vulnerabilities brought about by the code that was patched or take advantage of existing code issues with the knowledge that Microsoft is typically slow to react to release a patch outside of its normally published schedule.

Test and deploy this patch immediately or encourage your users to use a different browser (such as Firefox or Chrome) until you can deploy the fix.

*** UPDATE 12/18/2008 9:15am MST *** More information here written by SC Magazine which re-emphasizes the importance of rapid patch testing and deployment due to the number of active exploits.

It looks like Apple has finally changed their tune as it relates to using security software on their PCs and is now telling their users to make sure they have antivirus software installed.  See article here.

This move was inevitable.  At some point Macs would gain enough market share for them to become more of a target for hackers and cyber criminals.  Most security researchers have been saying that for a long time, and I applaud Apple for finally coming to that realization also, even though it really should have been said some time ago.  Now the Mac users who have long been saying that they don't need to worry about malware "because they run a Mac" really don't have a leg to stand on as even the manufacturer of their computer has come out and contradicted that claim.

From a timing perspective this announcement comes at a good time as well.  As IT managers are working on their 2009 budgets, this is now something that they need to include as another line item to allocate money for early in the year.  If your Mac does not already have some kind of antivirus software installed, the time is now to get it.  Apple's personal computer market share continues to increase which means its prevalence as a target will also continue to rise.  Don't be left holding the bag either as a personal Mac user or as a corporate user.  Macbots are coming.  iPhones and iPods will not be far behind.

*** UPDATE 12/2/2008 4:42pm MST ***  So it looks like I need to recant a little bit.  If you look at Apple Knowledge Base Article 4454, you notice the last updated date of December 2, 2008.  This article was originally published back on June 8, 2007.  Unfortunately, the existence of this article hasn't changed most Mac user hubris in their invulnerability to malware because the fact of the matter remains that many Mac users still don't use antivirus software on their machines.  The time is still now to change that.  A widespread Mac virus could be a devastating event!

In the event that you were not aware, a new critical update (rated as Important on Vista and Server 2008, but critical for Windows XP, 2000, and Server 2003) has been released as an out of band patch from Microsoft. 

It is of utmost importance that this vulnerability be patched as soon as you are able to.  The primary reason for this patch being released outside of the typical Patch Tuesday schedule is in response to exploits available in the wild and the potential for damage as a result of becoming infected. 

The vulnerability being patched is a network level vulnerability.  This means that once one machine within the network becomes infected, it will immediately start looking for other vulnerable machines within the network to exploit.  As a result, this exploit could have SQL Slammer like implications.  The primary difference here is that SQL Slammer was an exploit of IIS, an individual application where this exploit is taking advantage of a vulnerability in the operating system which means that the potential attack surface is much larger.

In the past 24 hours our Threat Operations Center has seen over 100,000 emails with attached exploits that appear to be taking advantage of this vulnerability.  All instances that we have seen thus far have been in German so their viability in the United States is limited.  We are on the lookout for additional variants, and will report them as they are seen.

*** UPDATED 10/24/2008 1:06pm MDT *** Upon further review It appears that the German emails are not related to the Microsoft exploit.  We are currently researching whether there is an email delivery vector being used to deliver exploit code to take advantage of this vulnerability.  The German emails are actually a different piece of malicious code.  More information here.  This update is also to correct the brief mention that was made in this morning's edition of the Security Buzz podcast that there might be an email attack vector sending out exploits.  That does not CURRENTLY appear to be the case.

*** UPDATED 10/24/2008 2:20pm MDT *** Exploit code for yesterday's patched vulnerability is freely available via popular security sites like SecurityFocus.  Blocking RPC ports such as 135-139, and 445 at your firewalls will not mitigate this attack.  Now that exploit code is so easily available it is not out of the realm of possibility that attacks will come from many different angles, email included, looking to get into your network.  It is definitely advised that you test and deploy this patch ASAP. 

ClickJacking.  One of the newest and most talked about, yet at the same time one of the most secretive new buzz words in Internet Security.  Clickjacking is actually a rebrand of what was originally called "UI Redress".  I guess ClickJacking was considered a sexier term.

What is it? 

Don't get me wrong, the concept of ClickJacking is not new.  The term has been floating around for about a year now.  Jeremiah Grossman and Robert "RSnake" Hansen were supposed to give a talk about it at the OWASP NYC Appsec conference, but were asked by people at Adobe to not give the talk as the vulnerability affects one of their products.

Essentially what ClickJacking entails is using iframes and web page layers in DHTML such that you overlay a potentially malicious button (for example) on top of an existing legitimate web page button such that when a user clicks it they believe they are clicking the legitimate button instead of your malicious overlay.  This all happens transparently to the user.  At this point the users click on the button has been "ClickJacked"

Since ClickJacking does not require Javascript (as so many of today's other web based attacks do) using plugins like NoScript will not provide any relief.  In Firefox you can turn off iframes, but this is a global setting, not a per site setting.  So, if you turn off iframes in your Firefox config you've now disabled them for every web site, and there is no telling what you could break on how a web site is supposed to render if you do this. 

In case you are interested there is a fairly detailed write up here that defines the problem and why it is difficult to fix.  It also outlines some potential solutions, all of which have their positives and negatives.  It's fairly wordy so if you don't generally like to have to hack through the technical weeds of a problem you may not find it interesting.

ClickJacking is an interesting problem to address because right now so little is known on a wide scale about what the issue is and how to identify whether or not your application is being compromised.  Additionally, there are virtually no tools to assist web site designers to protect themselves.  I am sure that will change as more is learned about this type of attack, but typically those tools are developed well after the attack vector is being actively exploited.  It's too late then.  That's like installing the burglar alarm after your house has already been robbed.

Although it is nice that Adobe wants details withheld until they can patch the vulnerability within their own application, that does nothing for the other web site application developers who will be playing a serious game of catch up after the fact...

There has been a considerable increase in the use of comment and profile spam to promote pornographic or phishing sites in search engines. Today we discovered that the AARP’s website has been compromised by a two-pronged attack.

First, hackers found vulnerabilities in AARP.org’s user profile functionality, allowing them to post JavaScript redirect code and HREF links to porn sites. Second, hackers employ bots in a massive campaign to submit blog comments containing links to the hacked AARP.org user profiles.

This provides hackers with multiple benefits. Among them:

• Search engines rank sites based upon links from other sites. If a high-ranking site like the AARP (to which Google has assigned a Page Rank of 8/10) links to the hacker’s site, it increases the recipient site’s ranking and traffic.
• The bot-driven blog comment spam drives increased visibility of the hacked AARP profiles, driving higher traffic numbers and ranking to the AARP profile itself.
• Users who view the seemingly innocent AARP member profiles are automatically redirected to porn sites, and served up malware "anti-virus" applications to help them "fix" the problem.

Typically, most blog platforms do a fair job of limiting comment spam. Even so, a cursory check for inbound links to some of the hacked AARP.org profiles shows many blogs now have the AARP.org bot-submitted links in their comment areas.

As we’ve covered before, spam makes a lot of people a lot of money. Hackers have great incentive to find vulnerabilities in email systems as well as web-based content management platforms. They're also increasingly using SEO (search engine optimization) to help stack the odds in their favor. The possibility of being able to inexpensively market on such a massive scale means the threat will never completely go away.

Whether it’s your website or your email network, constant vigilance is necessary to keep your organization from getting egg on its face.

Just ask the AARP.

(Note: The above image is from a non JavaScript auto-redirecting post.)

According to information being posted by many news outlets the DNS cache poisoning vulnerability that we commented on back on July 9th, the window that researchers and network operators had hoped would be open to patch DNS servers until the Blackhat conference has closed.  Several examples of exploit code have been released out into the wild which show how to take advantage of this vulnerability and attacks have also been spotted in the wild (Thanks to Websense for providing some of the links). 

The folks working on the Metasploit Project were one of the first to jump on the bandwagon by making the exploit available via their freely available Metasploit application. 

So, if you have not yet updated your DNS servers, the time is now to test the patch and update your production servers.  Patches are available from all of the major vendors.  It was widely expected that once the details of the vulnerability were released, exploits would follow very quickly afterward. 

Many have bemoaned the fact that the details of this vulnerability were kept under wraps for so long while others viewed it as a commercial ploy for the Blackhat conference.  My personal opinion is that in the name of responsible disclosure this situation was handled with 100% professionalism and sensitivity as to the nature and severity of the problem.  Based on the amount of coordination that was required to get all of the vendors together, discuss the problem, and patch their applications, there was no way that this could have been done such that it would please everyone involved.  The overly vocal minority is trying to put a black eye on a process that worked as well as it possibly could given the number of stakeholders involved.  It is truly impressive to me that the details were not disclosed sooner. 

It cannot be said strongly enough.  Protect your users and your network.  This is not a problem you can ignore.

It was announced yesterday that a serious vulnerability exists in the DNS (Domain Name System) such that an attacker could take over a DNS server and corrupt it in such a way that legitimate traffic could be diverted to malicious web sites.

If you are not familiar with how DNS works, it essentially functions as an internet phone book (if you are interested in a more technical description with examples, click here).  The internet works on what are called Internet Protocol (IP) addresses, but in order to make the internet easier for users like you and me to use we are more familiar with using hostnames like yahoo.com, google.com, and cnn.com).  What DNS systems do is translate those hostnames to IP addresses so that (for example) Internet Explorer knows where to retrieve web page content from. 

So, how does this DNS vulnerability potentially affect you?

If your DNS server is compromised, the hacker could redirect legitimate web traffic (say, to bankofamerica.com) such that instead of your computer being directed to the IP address for the real bankofamerica.com web site, it could be directed to malicious, look-alike web site that is either hosting malware or is setup strictly for the purposes of capturing login credentials to be sold in the underground market. 

It is important to note that this vulnerability is related to the actual DNS protocol itself and is not specific to any particular DNS implementation.  It is also important to note that at this time there are no known exploits that are taking advantage of this vulnerability.  Technical details of the flaw will be released at the Black Hat Conference in Las Vegas on August 6th.  Once more specific details are released at Black Hat all bets are off so it is important that you test and deploy the patch that is specific to your  DNS implementation as soon as possible.
If you are interested in reading more about the information that has been released thus far, you can read the Executive Summary here.  You can also read the CERT Advisory that was released here.