The WTF of the Week

Last week someone mentioned to me you can retrieve your Wireless SSID and Encryption key for the Verizon FIOS Actiontec router via the support menu of the TV guide. Somehow this did not surprise me and since the router is most likely sitting next to your TV, well physical access has been gained anyways.But it did get me curious on if Verizon allowed this functionality via the customers online account. Five minutes later...Well I'll just let these screen shots speak for themselves.

Now I could insert a rant here. But really what's the point? We all know this is just a bad idea. So remember to shred your bills or as I prefer put them to good use with the fire pit on a Saturday night.

 

Happy Hunting!

An Overdue Rant: The RSA Compromise

OK I haven't had a good rant in a while on the blog, so be warned, there may be some pent up rage in the paragraphs ahead. Read on at your risk.


I do not usually write posts on the latest compromise as I always feel there is enough coverage, speculation, and commentary from smarter people than I. There is a lot of speculation about the recently announced RSA breach both on the technical details of the compromise and on who may have been behind the attack. Yeah everyone is throwing three letter acronyms around again. The Digital Underground Podcast recently posted a great discussion on the technical side here and there as been some good posts on mitigation techniques.

The part I really have issue with is RSA's lack luster disclosure of this compromise. Some have suggested that they should be praised for publicly announcing the breach. I'm not sure when we set the bar so low. Since when is posting a written notification with vague details and little to no information on when and what was compromised and who is affected become acceptable?

A lot of organizations have paid a lot of money to increase the security of their information systems and data by purchasing the RSA SecureID solution. Don't forget even if your not a customer of RSA (Disclosure: I am not) it is still your family's data being protected by such solutions. In short, I find RSA's actions post compromise disgusting and inept.

While knowing the technical details of the compromise would benefit the security community by giving everyone an opportunity to learn where things went wrong, the reality is we will probably never know the details and this is OK with me. What needs to be done, on the part of RSA however, is to step up and fix where things went wrong, notify those clients affected, and offer them replacements or fixes for the technology they already purchased. Thus far the advice given by RSA is nothing more than best practice and common sense. I would like to think those implementing RSA's authentication solutions are probably already familiar with such administration controls.

To use a bad analogy. This is the equivalent of a new home owner hiring a Master Locksmith to replace all the locks in their new home with a more secure solution, only to have the locksmith keep a copy of the keys and tell the customer at a later date that the key has been stolen and the customer should go buy a bigger guard dog or better alarm system at their own expense. Would this be acceptable?

Not the greatest analogy but I did say their were more intelligent people than I posting about this didn't I?

The truth is, everyone gets owned at some time or another. It is the actions of the compromised organization during the aftermath that will distinguish it from other competitors. Asking other security solution providers to sign an NDA to learn more about the compromise is not looking out for the best interests of your customers.

/Rant

Updated June 01, 2011

It appears that there may have been several attacks against U.S. defense contractor's that leveraged information from the RSA compromise. Last Friday, Reuters reported that there was a breach at Lockheed Martin Corporation. On Monday, Wired reported that L-3 Communications had also been targeted and leaked memo suggested the attackers were using inside information on their SecureID system gained by the RSA hack. Today, Fox news is reporting a possible attack against Northrop Grumman. With all these reports flooding the internet it is difficult to know how much is based on fact but I did want to share a gem of a quote from the Wired report.

Asked if the RSA intruders did gain the ability to clone SecurID keyfobs, RSA spokeswoman Helen Stefen said, “That’s not something we had commented on and probably never will.”

Updated June 7, 2011

It appears RSA has updated their Open Letter to RSA SecurID Customers. The update provides verification of the Lockheed Martin attack and offers long awaited replacements of SecurID tokens, although for what appears to be a limited subset of SecurID customers. Thanks to Wim Remes for the heads up on the updated post.

Why Hackers make the Best IT Support Professionals

This is a thought that I have had brewing for some time and I will attempt to not rant too much.  Throughout my IT career, I have been watching many IT Support professionals immediately go for a quick fix to technology issues. This is not to say a quick fix isn’t always warranted. The constant barrage of support issues, end users broad siding you as you attempt to grab lunch, and evolving technology is indeed a challenge. I feel your pain. I've been there, I've done that, and I still do it on a daily basis. The beating support people take can cause even the most saintly to lose his/her patience.

However, I feel the trend of the quick fix, seems to be worsening. In InfoSec, the quick fix is often used in conjunction with FUD (fear, uncertainly, and doubt) to sell those magical products with blinking lights that are going to make the latest attack vectors just magically disappear. The problem with this concept is the same in all subsets of Information Technology, however. How many of us have told colleagues, friends, and family to reboot as a solution to an issue? How many of us have told them to do so more than once for the same issue? See the quick fix is not really a fix at all, it is procrastination.

I like to think that we as IT Professionals, whether desktop support, enterprise architects, coders, or InfoSec pursued our career because we all had the common love of technology. Many of us have the inquisitive nature that would rival any scientist. This makes us all brothers and sisters alike. The inquisitive nature that I felt when powering on my TI99-4A in 1981 is still with me today. This is why I chose this career.

Some of the most inquisitive people I have met while working in IT have been those who have self dubbed themselves "hackers". These are not the "hackers" the media would have you believe are hijacking your wireless and stealing your digital valuables. These are self proclaimed geeks who love computers. They are not always InfoSec professionals. They may work on a helpdesk, as a systems administrator, or at the local Radio Shack. They enjoy taking things apart and putting them back together in ways that improve the technology. See hackers understand the concepts of efficiency and availability.  These concepts are the foundation of supporting any business. It is what our employee’s pay us our salaries for, regardless of the subset of IT we may fall under.

Efficiency and availability is not about reboots and resets. It is about getting to the root of an issue, learning from it, and improving the system(s) from what you have learned. So take the time to understand the technology issues you come across. It can be fun and productive. If you are not feeling the love for your technology career of choice, then ask the hacker working at the local Radio Shack if he or she is willing to trade careers with you. I suspect they would jump at the chance.

What's in a Word?

So I am doing the post holiday vacation catch up with my email last night and I found several emails in my inbox referencing a Boston Globe article published yesterday. The article is titled Data Breaches Affect Million State Residents .

To summarize, the article briefly reviews the amount of data loss containing Personal Identifiable Information (PII) of Massachusetts residents reported since MGL Chapter 93H was put into effect in October 2007. I was happy to see some general media coverage of the 2007 law and the newer 201 CMR 17.00 law which is scheduled to become effective in March 2010. I quickly became annoyed however.

What struck me was a quote in the article from Barbara Anthony, Undersecretary of the Office of Consumer Affairs and Business Regulation.

“In 60 percent of the cases, the breaches were due to criminal acts,’’ said Anthony. “Forty percent were negligence.’’

<disclaimer>I am not an attorney nor do I play one on TV!</disclaimer>

I live and work in Massachusetts so I am familiar with both these laws. I have to say I have a real problem with this statement. Lets first look up the definition of the word negligence. It is after all a legal term which therein lies my issue with her statement.

From dictionary.com

–noun
3. Law. the failure to exercise that degree of care that, in the circumstances, the law requires for the protection of other persons or those interests of other persons that may be injuriously affected by the want of such care.

–adjective
4. Law. pertaining to or involving a civil action for compensation for damages filed by a person who claims to have suffered an injury or loss in an accident caused by another's negligence: a negligence suit; a large negligence award.

So if a criminal act was used to obtain data by way of an individual or company's neglect to adequately protect that data would that not be considered “negligence”? I would argue that most of the 807 cases reported by the Commonwealth of Massachusetts were probably caused by some form of negligence. If an employee of a company storing such data, copies the data to his/her laptop against company policy, and that laptop is stolen from the front seat of his/her vehicle, then that is a criminal act caused by negligence. If a company's System Administrator forgets to apply a security patch to a critical system prior to leaving for two weeks of vacation, the server is compromised, and the data is stolen, I would also consider that a criminal act resulting from negligence.

My point is I would like to know how the Commonwealth is differentiating between a criminal act and negligence since the later can often lead to the former. I believe their logic and consequently their statistics are flawed. Moreover, neither law seems to outline such terminology.

So why is this important? I believe companies should be held legally liable. The term negligence implies that I as a consumer residing in the Commonwealth of Massachusetts should be able to hold a company that is storing my Personal Identifiable Information liable in criminal and civil court if they have been negligent in protecting my data. Is that not the purpose of Law? Until then, I do not believe laws and regulations will have any substantial positive effect. They are just security theater.

On a related note, I found this great post on philosecurity.org blog waiting in my RSS reader last night;  Why Data Breaches Don't Get Reported.

Adobe's "0 Face"

As you may already know, Adobe acknowledged another public security vulnerability in their products on December 15, 2009. APSA09-07 affects all current and earlier versions of Adobe Acrobat and Reader with JavaScript enabled and is currently being exploited in the wild. There is no doubt Adobe products have been in the cross hairs of attackers over the past two years and Adobe's use of JavaScript seems to provide an easy opportunity for exploitation.

Upon reading the advisory, it was no surprise that disabling JavaScript was the mitigation. Many users in my environment do not use this functionality and it can easily be turned off via the Windows registry. The problem is it does not remain off. When opening an Adobe JavaScript enabled .pdf the user is presented with a prompt to re-enable JavaScript. To date Adobe does not provide any way to permanently disable JavaScript via the Adobe Reader preferences menu or the registry. We all know how useful warnings are for end users right? <insert self-signed ssl certificate here> But I'll save the use of a warning as a form of mitigation of badly thought up functionality for a later blog post.

<my rant>

So Adobe products are increasingly being targeted and although Adobe seems to have picked up the pace with their security stance, I have often questioned if they have enough internal resources to do anything but be reactive. Once again, a zero day leveraging JavaScript in an Adobe product is flying around and the patch for this vulnerability will not be available until January 12, 2010. In my opinion, this is unacceptable. Adobe seems to be struggling with putting out the fires and are not being preventative by fixing their code or providing systems administrators with the tools or patches they need to properly mitigate. I can personally tell you my corporate IDS and Antivirus have been lighting up like a Christmas tree (tis the season) with attacks using this exploit.

Soon after the advisory dropped, I listened to Dennis Fisher and Ryan Naraine interview Brad Arkin on the Digital Underground podcast. Brad Arkin is currently Director of Product Security and Privacy at Adobe and has held previous positions at Symantec and @stake. Now Brad seems like an intelligent guy and I applaud him for taking on such a challenge. I became annoyed while listening to the interview, however. Ryan Naraine repeatedly queried Brad during the podcast on what I have suspected for quite some time. Does Adobe have enough resources in place for dealing with the current trend of attacks targeting their products? Brad seemed to repeatedly side step the question. He attempted to explain the complexity of dealing with such vulnerabilities with such a large and diverse install base.

<disclaimer> While I may have no experience dealing with what Brad has stepped up to do, I do have a lot of experience mitigating vulnerabilities in the corporate environment and my opinions here are based on that experience. </disclaimer>

Now while I have no doubt that this is a challenge indeed, maybe Adobe needs to stop, glance around, and take a cue from the company that has the largest and most diverse install base I know of. That company would be Microsoft. While far from perfect, Microsoft seems to have made some significant advances with their security program over the last 5-6 years. When MS08-067 dropped in October 2008 (for those not familiar, that’s the vulnerability used by the Conficter variants), Microsoft did what any responsible software vendor should do. They released an Out-Of-Band patch!  So what gives Adobe?

I almost jumped out of my skin when Brad stated Adobe often needs to shift resources off of other security projects and research to handle an exploit such as this. So to answer Ryan’s question, I guess you do not have enough resources then? My point is if you have to shift all your resources to handle each and every fire and it still takes you a month to put out the fire, then you will never be preventative. Maybe I am being naive here but I don't believe so.

</my rant>

Ok so with my ranting out of the way, I did state that I thought Adobe was making improvements. One such improvement is their implementation of the JavaScript Blacklist Framework mentioned during the podcast. It is still reactive but it is at least something. Thank you to Dennis, Ryan, and Brad for bringing this to my attention. To quote Adobe’s tech note located here;

“The Adobe Reader and Acrobat JavaScript Blacklist Framework introduced in versions 9.2 and 8.1.7 provides granular control over the execution of specific JavaScript APIs. This mechanism allows selective blocking of vulnerable APIs so that you do not have to resort to disabling JavaScript altogether.”

Brad admitted during the interview that this is only effective for specific vulnerabilities and it may break legitimate uses of functionality in Adobe Acrobat and Reader. He further stated Adobe has many more improvements coming during 2010. I can only hope this includes some preventative improvements to their code base and internal resources dedicated to the current target on their back.

More can be found on using the blacklist framework to mitigate the vulnerability in APSA09-07 here.

For an entertaining and informative Adobe rant (that puts mine to shame) checkout the latest post on the Sourcefire VRT Team blog, entitled Matt's Guide to Vendor Response

Happy New Years to Everyone!

Update:

More reports of sophisticated Adobe exploits have been appearing this week. Some have little to no coverage by the AntiVirus vendors. I noted the following article describing Adobe's plans to begin testing a silent Adobe updater. Someone needs to tell Adobe an updater only works if you actually provide the update and explain to them the basics of enterprise change control.

Details of the attacks can be found here and here.

Another Update:

Adobe has release patches for the Acrobat/Reader vulnerability as well as another vulnerability in Illustrator.  The Advisories can be found here:

http://www.adobe.com/support/security/bulletins/apsb10-02.html
http://www.adobe.com/support/security/bulletins/apsb10-01.html

I also found a great ADM template for tuning Adobe Acrobat and Reader JavaScript settings on the Praetorian Prefect Blog. Again, just note that the user will be prompted with a warning when opening a .pdf containing JavaScript.

OK Last Update

The Sourcefire VRT team posted an excellent article this week on the using the Acrobat JavaScript Blacklist Framework on common exploited functions within Adobe Acrobat and Reader. An example taken from their post for Adobe Acrobat 9 would be as follows:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\9.0\FeatureLockDown\cJavaScriptPerms]"tBlackList"="Collab.getIcon|DocMedia.newPlayer|Util.printf|Spell.customDictionaryOpen|Doc.syncAnnotScan|Doc.getAnnots"

 Additionally, they provide benign Adobe Acrobat files using each of these functions to test with.

Didier Stevens also pointed out during a recent interview on PaulDotCom Security Weekly that the new version of Adobe Reader and Acrobat has changed the way it warns users that JavaScript is disabled. While not quite the administrative control I had hoped for, it is a slight improvement as it renders the .pdf regardless of the action taken by the user.

Don't be the Smelly Kid

Often I find security professionals and management treating security as a project or series of projects. While there may be security related projects within an organization, I would argue security as whole should not be treated as such. Securing ones environment does not have defined start dates, end dates, or even budget. It needs to be part of every information system project and baked in from the beginning. Security should be part of your regular scheduled maintenance and support structure. By treating security as one would treat personal hygiene, security becomes part of the daily routine. Lather, rinse, and repeat.

I have eluded in previous posts that security products, while sometimes helpful, can also cause more overhead and issues. Specifically, products designed to provide a "band aid" to improperly designed or implementation information systems would be the equivalent of splashing some cologne on everyday and not taking a shower. Eventually, there will not be enough cologne in the world to hide the stench. So don't be the smelly kid! Lather, rinse, and repeat.

The Detrimental Effects of Compliance Auditing on the Security of Small Business

Many argue that regulatory compliance with PCI, SOX, MA 201 CMR 17.00, and others help establish the minimum baseline for security in organizations. I think the point may be valid in organizations that initially had little to no security but I would argue that it has the opposite effect on a company that has the basics and beyond covered. To be specific, smaller companies which have one or two security professionals running the gambit from configuring Group Policy to writing Policies and Procedures are often already overwhelmed (note I fit into this category). Such professionals may quickly find themselves concentrating on out dated, incomplete regulations and laws rather than concentrating on reducing the risk of data loss by keeping up with current attack vectors, vulnerabilities, patches, and system logs.

I recently had a discussion with some colleagues on the subject of extending the compliance auditing of SAS providers to include data beyond financial or personal identifiable information. Initially it sounds like a valid and justifiable cause. But what is the end game? If it is mountains of one hundred page SAS70's with no regulation or law behind them, then it might be a worthy cause. But stacks of paper may show nothing about the security of the data being stored by the provider and will certainly distract from other effective methods of reducing risk. Honestly, if I could spend some time shooting the shit with the solution providers security team about current security trends and attack vectors, I would probably have a more accurate assessment of their ability to secure the data.

I am not suggesting we ignore current laws or regulations. We have an obligation to follow them. I am also not suggesting we do not review the hosted solutions outside vendors are providing for non-regulated data. I do believe that the review process should not mimic compliance audits, however. The time spent during the review process should match the amount of risk involved and assurance we achieve from the security review. If the security of such data is absolutely crucial, one might consider not storing the data there in the first place.

Lessons Learned: Vulnerability and Expectations Management

As an information security professional, a large portion of my work day is spent with vulnerability and patch management. So when I saw a security advisory addressing multiple vulnerabilities in both Symantec's Corporate Antivirus and Endpoint Security Solution products last June, I immediately investigated. You can read the security advisory here. I became concerned because other Vendors also use the Intel File Transfer service so I thought it be prudent to investigate.

I began looking around and noted that Tenable Network Solutions had a Nessus plugin. You can find the plugin here. So like any true geek with nothing to do on a Saturday evening, I began scanning. I was surprised at what I found.

The systems running the Intel File Transfer service from other vendors were not vulnerable but systems patched with Symantec 10.1 MR8 were still be vulnerable. The solution table in Symantec’s Advisory states that the issue with AMS2 was fixed in this version.

I contacted someone I knew at Tenable and asked for assistance in verifying the vulnerability. The plugin actually contains remote execution code but it is commented out by default. With instruction from Tenable I uncommented the cmd = "calc"; line in the NASL script and ran a nessusd -R to perform a reload of the Nessus Database. Sure enough, the next scan verified that cmd.exe would execute without authentication on the vulnerable machines.

So what gives? Is Symantec's advisory incorrect? Not entirely, although it may be misleading. This became a case of reading the fine print. Further down the advisory we find this information:

"AMS2 is installed by default with Symantec Antivirus Server 9.0. AMS2 is an optional component in Symantec Antivirus Server 10.0 or 10.1. These vulnerabilities will only impact systems if AMS has been installed."

And further down, under mitigation section:

"Reporting has replaced AMS2 as the recommended method of alerting. Symantec Endpoint Protection Central Quarantine Server 11.0 MR3 and later no longer include AMS2. Symantec recommends that customers who are still using AMS2 switch to Reporting to manage alerts in their environments. If the customer is unable to switch to reporting immediately then Symantec recommends that the customer either disables AMS2 as a temporary mitigation or completely uninstall AMS2."

All the systems vulnerable had all been upgraded from an earlier version of Symantec Antivirus Corporate Edition 9.X. During the remote upgrade process there seemed to be no way to specify if AMS2 was to be installed or not. Symantec support seemed unable to instruct me on how to remove or disable AMS2 from the affected systems and I have spent the last several months trying to get them to change the advisory so that the solution table listed at the top of the document noted this tidbit at the bottom. To say the least I have not been successful in this endeavor and feel a bit frustrated. Although the Sales Executive has been nice enough to try and sell me their Endpoint Protection v11 product and recommended I start with a fresh install.

If you do want to mitigate the vulnerability, I determined disabling the Intel File Transfer service works well and does not seem interfere with my configuration. I recommend you test this in your own environment however.

So Lessons Learned:

Read Security Advisories carefully.
Scanning is an important part of any vulnerability management plan.
Manage your expectations when dealing with vendors.

Updated December 29, 2009

Posted two updates on the release of the POC for this vulnerability and a report of the exploit being used in the wild by SANS ISC.

The OWASP Podcast Series

While working on my next blog post, I happened upon episode 27 of the OWASP (Open Web Application Security Project) podcast interview with Rafal Los. If you have not subscribed to the OWASP podcast let me recommend it now!

Rafal gets pretty fired up during the interview on the direction that web application development has headed. He notes the importance of simplicity when developing web applications and condemns complexity. His arguments are convincing and it is worth a listen. Unfortunately, I am not convinced that what needs to happen will ever happen but one can hope.

In episode 28, an interview Ross John Anderson, Ross discusses the axiom of functionality, scalability, and security. He proposes any information system cannot have more than two of these at a given time. Again the interview is worth a listen.

The Risk of Complexity

It is human nature to desire a shiny new technology based on marketing claims and feature promises. But many times during my career in information technology and security I have really questioned the “value add” of a particular solution or system. Will it really lower costs, improve employee performance, and facilitate collaboration? Will it provide the seamless interoperability between complex systems as advertised? Will it do all this and still provide stability and security? Or are we just attempting to throw complex technology at managerial, organizational, and performance issues as a fix?

Often, adding more complexity to technology will only make the issues associated with that technology more complex. These issues include security. Generally speaking, with more complexity comes less security. This is not necessarily because the ability to secure the technology does not exist but because it becomes out of reach due to resource limitations. These resource limitations include limitations in finances, time, and expertise. Complexity can increase the attack surface area of a network hence decreasing its security posture unless the proper training, planning, and defensive resources have been budgeted and obtained. Unfortunately, this is often not the case. Moreover, much of the technology used to secure and defend such solutions can increase the complexity of one’s information systems even further, potentially causing an endless loop of new features and defensive solutions.

Virtualization is a great example of this. The ability to virtualize operating systems, resources, and applications has many advantages in IT infrastructure and business. But the ease of virtualizing systems, combined with a lack of planning and available expertise in these products has the potential of creating an out of control scenario of misconfiguration and mismanagement. Proper change control, build procedures, code review, monitoring, disaster recovery planning, and documentation still need to be addressed. The security risk associated with virtualization needs to be assessed, managed, mitigated, and re-assessed on a regular basis. This can be a daunting task without the proper resources. Such resources may not have been factored in during the budgeting and planning process or may no longer exist during economic downturns.

I am not downplaying the incredible benefits of virtualization. I use virtualization too. However, much like any technology, it has its place and I don’t believe the “lets virtualize everything” mantra. The idiom of “don't put all your eggs in one basket” comes to mind. Doing so can be a serious mistake with dire consequences in assuring the confidentiality, integrity, and availability of data. I only use virtualization as an example, due to its prevalence in our industry and the complex baggage that often comes with it. There are dozens of other examples that could be used, but like most, I cite examples that I am familiar and comfortable with.

The recent compromise of Vaserv.com, a UK ISP, has been reported to affect over 100,000 hosted web sites which may never recover. Some have reported the attack was a result of vulnerability in the virtualization technology the web hosts were running on while others claim bad administrative practices are to blame. Some have questioned Vaserv’s disaster recovery and incident response procedures, or lack thereof. Most likely, it is a combination of these factors that contributed to this colossal failure. Was the complexity of the technology to blame? Was Vaserv.com naïve to think they could increase their profit margin by decreasing engineering and administrative costs through the use of virtualization? Or was the company putting all its “eggs in one basket” and ignoring the fundamentals of security?

These are only speculations on my part as I am, like most, not privy with the details of the compromise. The irony of this example is Vaserv.com was marketed as a low cost hosting solution. One may speculate that many companies and individuals chose their hosting services to save money only to incur a substantial financial loss associated with the incident. Some may feel I am simplifying the issue at hand but sometimes that is all that is needed.