Archive for December, 2008

The case (for/against) filtering subscriber to subscriber network traffic

Wednesday, December 31st, 2008

Part of my job is to help customers decide when and where it’s appropriate to deploy firewalls and other security devices in their networks. One point that has come up in discussion with my colleagues has been whether or not it is a good design principle to filter peer to peer traffic in service provider networks. Let me first clarify what I mean by service provider networks. I am referring to networks that are specifically designed to provide connectivity for subscribers, either to the Internet, to private intranets, or to each other. The owner of this network (the service provider) is essentially providing ‘pipes’ for his customers. Service providers earn money by creating and meeting service level agreements (SLA) with subscribers that guarantee bandwidth and availability to customers.

I define subscriber to subscriber traffic filtering as a network design which explicitly prohibits the exchange of packets directly between subscribers without first passing those packets through a firewall or access control lists. An example of this type of network is a typical cable or DSL service network provider where subscriber packets are filtered through a network access server (NAS) prior to being forwarded to their destinations. A metro Ethernet network is an example of a network that does NOT perform peer to peer traffic filtering (metro Ethernet provides layer 2 connectivity between subscribers).

From a pure service provider business perspective, you care little about the types of traffic that subscribers exchange as long as you are able to meet the SLAs that you have established. If the traffic that is exchanged happens to contain malicious information (viruses, malware etc.), the service provider isn’t really going to care as the type of traffic exchanged doesn’t affect their ability to provide service to subscribers.

From a subscriber perspective, you care a lot about whether or not your home/business network is subjected to malicious traffic originating from your outside network connection. However, you also care about having the freedom to use your outside network connection as a raw pipe and being able to exchange any kind of network traffic with anybody that you can connect to (especially home users who use BitTorrent and other P2P protocols).

From a regulatory perspective, as a service provider you care about meeting the legal requirements to provide service in the regions you operate in order to avoid penalties etc. Certain governments impose restrictions on the types of traffic that network users are allowed to exchange (China being a prime example with strict requirements on which websites can be viewed by Chinese residents).

As can be seen from these 3 different perspectives, the need to implement filtering controls to restrict subscriber to subscriber traffic is not immediately evident. From a security threat perspective, most service provider networks are designed to provide clean seperation of bearer data (subscriber traffic) and control/management data used by the provider to run their network. So the risk of subscribers actually accessing the service provider’s infrastructure is quite low. A slightly more obvious security threat is the risk of being non-compliant to regulatory requirements. In this case, the risk of non-compliance can be quite high depending on each country’s regulations.

In conclusion, when considering whether or not to implement peer to peer traffic filtering and whether or not the lack of this filtering is a security risk, consider the network design and the regulatory requirements governing the network operation. You may be surprised to find that there is in fact little to no security risks to the service provider by NOT performing peer to peer traffic filtering.

An Introduction to Protocol Fuzzing

Tuesday, December 30th, 2008

I have been considering running a basic level of protocol fuzzing on some known/unknown services for some recent projects. These are mostly penetration tests, but with particularly locked down or limited points of entry. I look at fuzzing as a way to both demonstrate more value in the penetration test and to potentially find new holes in an environment where known vulnerabilities don’t work or don’t exist.

Fuzz testing” or “Fuzzing” is the process of taking an expected input or output and mux’ing it up with unexpected data. It began as a software testing method, but is now commonly used to detect potential security problems. It’s easiest to understand protocol fuzzing when testing Web applications:

In a typical web application login process you submit a username and password over the network. Fuzzing this communication would likely involve replacing a normal username/password pair with random data of random (and often long) lengths, but might also involve changing other HTTP response data.

The goal is to discover checks in the services programming which don’t parse the data they receive correctly. Under typical expected conditions they work fine, but in the process of fuzzing you try and discover conditions under which they do not work fine. These can lead to the discovery of new buffer overflows, cross site scripting, and other vulnerabilities.

There are a lot of fuzzing tools and frameworks out there, most of them targeting the web application space (I’ll be dedicating a later post to these). Here are a few which can be used in arbitrary protocol fuzzing:

  • ProxyFuzz – A python based proxy which will will randomly change the contents of either side of a communication stream.
  • Taof – A python based GUI proxy with a somewhat easy to use interface to select which parts of a communication are fuzzed. It can also bind itself to a locally running process to better determine when a process is having issues with fuzzed data.

There are many advantages to fuzzing:

  • You can discover interesting vulnerabilities without having a clear understanding of a protocol
  • Fuzzing can operate at all levels of the OSI model. Most fuzzers are built at the application, network, and transport levels, but fuzzing principles can work on any level.
  • Applicable to both the server and client ends of a protocol.
  • Many of the vulnerabilities discovered through fuzzing are buffer overflows and can lead to the execution of arbitrary machine code.

And several disadvantages:

  • If you don’t have much knowledge of the protocol structure, it becomes a more or less a brute-force approach.
  • Encrypted protocols are difficult to fuzz. Most fuzzer’s operate as intermediary or proxy applications and would need to either decrypt communications on the fly or have the client program’s cooperation in mux’ing the traffic.
  • As an automated method of attack, there is often a lot of work involved in finding out what exactly went wrong when an anomaly is detected and how to exploit it in a controlled manner.

Fuzzing is a big topic and an area I’ll be exploring more later.

Secure Password Management

Saturday, December 20th, 2008

Following up on my post about passwords and physical security, I’d like to discuss a couple suggestions for secure password management.  This primarily applies to the unfortunate (but common) case where a team is sharing common logins and passwords.  We see this a lot with internal teams, especially in lab and development environments.

A few months ago I saw a good blog post by Joel Spolsky, where he suggested using a combination of Dropbox and Password Safe as a secure password management tool.  For those unfamiliar with it, Dropbox is an Amazon Cloud-based service that essentially acts as a network-based hard disk that can be synced across multiple machines.  Local copies of files are retained on the user’s machine and changes are synced with the main file server and distributed to the user’s other machines with the Dropbox client installed.

It’s a great tool and I would recommend it to anyone – and when used with Password Safe (install your encrypted password file on the dropbox-synced folder), it’s an effortless and secure method for an individual user to manage their passwords.

In an enterprise level IT environment, however, it’s probably not the best choice.  I can’t think of any responsible administrator who’d consider turning over a password list to an untrusted 3rd party, as anonymous or as encrypted as it may be.  It’s just not worth the risk.

The alternative, then, is to leverage a similar method using more secure means.  Our team uses a NAS device, which is an ideal and cost-effective candidate for similar functionality.  If your IT organization has large-scale production file servers which are regularly backed up and maintaned, that would be an even better candidate.

The missing piece in this suggestion is file synchronization – a killer feature of Dropbox.  There are a few different ways to take handle this – either using one of the many file synchronization tools, or a versioning system such as CVS or Subversion.  The choice is yours, but allowing the user to maintain a local copy of the folder is a critical component – because what happens if the file server goes down and the user forgets a shared password?

A careful security administrator will keep these circumstances in mind and plan for them accordingly.  Don’t be “that guy” who assumes his file servers will be up 100% of the time!  That’s what security is all about – hoping for the best, yet planning for the worst.

Password Policy, Physical Security, and Keeping the Cat in the Bag

Friday, December 19th, 2008

Password policy is one of the most frustrating subjects for any IT or Security administrator.  You’re stuck in a “Damned if you do, damned if you don’t” situation, where no matter what you do the users will complain.  Something that I like to keep in mind when considering password policies is the careful balance between security and usability.

On one hand, there are fairly well-established best practices regarding password policies.  Non-dictionary words, 8-15 characters, etc.  SANS has a great (if a little strict) password policy document here which is a great starting point for any security administrator.

On the other hand, users have a hard time remembering complicated passwords, especially ones that are frequently rotated.  A well-enforced password policy won’t let users choose their name, dictionary-based words, or any other ‘easy’ passwords, so the user is stuck with having to remember a complicated acrostic, or a random string of characters.  And what do users tend to do in this situation?  Write down the password.

So, what’s wrong with this practice?  Nothing!  It’s even been advocated by various security gurus for years.  But you need adequate physical controls around the password list.  That’s the rub – in a large IT organization,  how does one protect from users carrying around scraps of paper?  Adding a further layer of complication, what about the case of shared logins and passwords?  The problem can become overwhelming quickly.

In an IT environment where Role-Based Access Controls (RBAC) are implemented, I would be inclined to not explicitly discourage users from writing down their individual passwords – because we’re all pretty good at physically controlling pieces of paper (money, anyone?).  I may encourage the use of a tool such as Password Safe,  but there’s only so much that you can do to control the behavior of the users.

Where common usernames and passwords are shared between many people (a tragic case!), the problem of password management becomes much trickier.  I’ve seen systems with multiple versions of a common password list, with each user having their own copy.  I’ve seen password lists distributed betweeen a dozen users via unencrypted email.  I’ve seen printed sheets of passwords “hidden” underneath the keyboard of a common workstation.  I’ve seen post-it-notes on monitors.  All of these situations are terrible, but in reality, they’re also unavoidable.  The best an administrator control for is to provide adequate physical controls; limiting access to the password lists.  It would take a very highly-motivated attacker to get past a security guard, keycarded doors, and a staff that’s advised to pay attention to unrecognized people in the building – and your security response policy should take into account the situation of a password breach and have plans for rapidly shutting down access and rotating shared passwords.

In summary, there’s only so much that you can do to control the behavior of users, especially when asking them to remember complicated passwords.  I would advocate RBAC authenticating against a common directory server in all possible circumstances, so that a breached username and password can be compartmentalized, protecting against damage.  If that’s not possible, educating the users about controlling access to their passwords, and providing for adequate physical controls is about the best you can do.  And as always, having a response policy that takes into account the circumstances of a password breach is critical.  IT has evolved to the point where users are getting comfortable with the strictness of password policies, but as an administrator or security professional, it’s important to consider the vulnerabilities and to keep in mind the careful balance of usability and security.

Security and Persona Development

Friday, December 19th, 2008

I have recently been exposed to some projects which have used “personas” for the development of new products and services. I’ve heard of their use in design (as in product and user-based design) before and been impressed at how they focus design towards the goal of satisfying an eventual end-user need. I can’t help but wonder if the “persona tool” can be used to help security solutions better meet an end-user need and help the overal useability of security.

Personas are basically character profiles meant to represent the personality and use-case of an end-user of a product or service. Wikipedia has a good summary:

A user persona is a representation of the goals and behavior of a real group of users. In most cases, personas are synthesized from data collected from interviews with users. They are captured in 1–2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to make the persona a realistic character. For each product, more than one persona is usually created, but one persona should always be the primary focus for the design.

I can see them being useful in security for visualizing how users will interact with security solutions and use them in “real life.” For example a persona could help someone develop a password policy that not only has strong security requirements but will forsee how user’s will interact and use it.

This is a topic I’ll definately be exploring further. I would like to develop a framework for developing and applying persona’s to the creation of security controls and policies. Seems like it could have a definate impact on how “usable” security solutions are.

Welcome!

Sunday, December 14th, 2008

The Securism Blog is focused on exploring the ever-changing topic of computer and information security. Our goal is to explore relevant topics in a way which both informs and contributes to the on-going discussion of security and its various applications in society.

We are security professionals and enthusiasts who are interested in expanding our own understanding of security and providing commentary on developments in the security world. Please see the about page for more information regarding the Securism Blog or the authors page for information about Securism authors.

The format of this blog will evolve over time. We hope you find it interesting, useful, and informative and we look forward to your comments and discussions.

Thanks, and enjoy!