3rd Party Applications Open Holes Too!

For years, we’ve heard the ire of security professionals worldwide over the vulnerabilities of the Microsoft Operating Systems.  Many touted Linux or even Macintosh as the answer.  Unfortunately, there is scant support for these operating systems in the way of desktop applications in particular.  This kept many businesses from making such a move. 

The answer from a security perspective was to keep the OS religiously patched, and run bloated up-to-date desktop anti-virus programs.  However, the one thing that is often overlooked in this approach is 3rd party applications.

I, for one, install at least the following applications without fail on every new desktop I build or rebuild:

• Adobe Reader
• Adobe Shockwave
• Adobe Flash Player
• Jave Runtime Environment
• Microsoft Media Player
• Quicktime Player

I’m sure there are many other IT professionals that do the same.  Unfortunately, these often get overlooked when it comes to patching.  There is no simple “Automatic Updates Service” that can be enabled for many of these like there is in MS Windows. 

What many don’t realize is that new vulnerabilities are discovered in these applications just as frequently (if not more so) as there are in Windows.  In many cases, these vulnerabilities can be exploited far easier than many Windows updates.  In addition, many are more dangerous in that they are usually targeted to specific businesses.  Imagine an exploit that a criminal could run by spamming a corporation with a PDF attachment.  This PDF attachment would then execute custom code that could then install backdoor applications for a hacker to use.  Trade secrets or private information?  Not anymore….

Next, there are the inappropriately patched systems.  For example, how many people realize that simply upgrading the Java Runtime Environment does not necessarily close the holes the old version created?  Did you know that you have to actually manually uninstall the old versions of Java?  By default Java’s installer does not do this thereby leaving the exploitable code on your system.

This is why patch management systems are so crucial for companies.  I’m sure when you lock the doors at night, you also close the shipping doors, the windows, and any other points of entry.  Likewise, you should be closing the points of entry into your data infrastructures as well.  If you can’t close them, for one reason or another, you should at least be aware of these points of entry and make efforts to minimize the risk your exposing your business to.

Spend an Hour Now…Earn Double That Later!

As I’ve been traveling the country lately, I’ve been learning more and more about how the PCI-DSS requirements are affecting businesses.  There does still seem to be quite a bit of mis-informatin as well as a lot of questions.  As a result, I’ve been changing the focus a bit.

I really do think companies should spend more time in training on PCI.  There is no better training, in my opinion, than that provided by auditors who have actually been in the field conducting audits.  By investing in training, staff and management can get a better understanding of security implications, the audit process, and why the PCI requirements are so important.  As a bonus, doing so will also aid in meeting PCI-DSS requirement 12.6 - “Implement a formal security awareness program to make all employees aware of the importance of cardholder data security.”  This training should be provided to everyone in the company, not just a select few.  I’ve found that companies that take this approach get better cooperation from their employees and have an easier time making it through the audit.

Next, management should get involved regularly in user groups and public forums.  Myself, and many other auditors like me, frequently respond to posts on sites such as the PCI Knowledge Base.  The beauty of these public forums is that others can benefit from similar inquiries.  In addition, we’ve all seen how different auditors have different points of view on various topics.  This unfortunately feeds some of the misinformation.  Public forums, like the PCI Knowledge Base, can help combat that as auditors will discuss their reasonings behind their points of view and challenge one another in hopes of coming to a more unified/educated approach.

I know time is valuable, but spending a few hours now on these suggestions will offer great returns in both the security of your data and offering a more pleasant experience during your audits.

Clarifications on WPA/TKIP Vulnerabilities

Recently, a research paper published from Japanese academics demonstrated a newer, faster, and more reliable way to crack wireless networks that use WPA/TKIP protocols.  In the best case, such a network can be compromised in less than 1 minute now.

So, what does this mean?  First, we need to understand what WPA/TKIP is.  Essentially, WPA/TKIP is a method of securing wireless networks.  Wifi Protected Access/Temporal Key Integrity Protocol (WPA/TKIP) was created to fix shortcomings of an early form of wireless encryption known as WEP (Wired Equivalent Privacy).   Just as the name applies, WEP was designed to simulate an equivalent form of protection that would be found on any wired network.  As we know, WEP failed miserably, and today such networks can be compromised by anyone with even the most basic understanding of computers with simple applications that are readily available online.   As a result of these weaknesses of WEP, TKIP was created.

Until recently, TKIP has been a viable alternative to WEP.  Then, in November of 2008, Martin Beck and Erik Tews discovered an attack against TKIP.  Essentially, they found an exploitable hole that exploited WPA/TKIP installations that also implemented IEEE802.11e (or Quality of Service) features.  Together, with their fellow students and the aircrack-ng team, they revealed how to send bogus data to an unsuspecting WiFi client on a WPA/TKIP network.   However, since this attack does not reveal the actual key, and since exploits were “minimal” this did not gain much public attention.  Examples of attacks that could be exploited using Beck and Tews’ attack would be ARP poisoning causing confusion in routing traffic and Denial-of-Service attacks that would lock out all clients from a wireless network.

What was overlooked though is the fact that it showed that there are real flaws in TKIP.  And, as is the case in wireless networking and security, it’s only a matter of time before others start expounding upon this research and come up with other ingenious ways of exploitation.  For example, not even a year after this another group of students (Finn Michael Halvorsen and Olav Haugen) from the Norwegian University of Science and Technology Department of Telematics released another cryptanalysis of TKIP.  There thesis and source code for modifications to aircrack-ng’s tools can be found here.  Essentially, they expounded upon Beck and Tews’ earlier study and determined ways of exploiting the network beyond ARP poisoning and DoS attacks.  Examples include:

DHCP DNS Attack:  Basically, in this attack a victim client would accept a packet from the hacker that would allow the attacker to respond to DNS queries with fake DNS replies; thus, forcing an unwitting victim to visit unintended websites or other network locations.  From there, further attacks could be attempted.

NAT Traversal Attack:  In this example, an attacker could inject a fake packet to the client that appears to originate from an external IP address at a specific port.  The victim machine would then respond to this request forcing the route to establish a NAT mapping between the internal computer and external ports and IP addresses.  The external machine will now be able to send traffic directly to the internal victim client on the open port in the firewall.  This could then for instance be used to exploit some unpatched vulnerability at the client or reveal Internet IP address of the network which would be useful in other scenarios as well.

Even still, many did not take this seriously.   The answer many gave to counter the above was to simply disable the QoS features on wireless networks or make other simple “modifications” to their setup to combat and prevent the attacks outlined above.  Well, now Japanese students Toshihiro Ohigashi and Masakatu Morii of Hiroshima University and Kobe University discovered an even more efficient means of attacking TKIP and published their findings here.  The Beck-Tews attack would normally take about 12-15 minutes to exploit and also required QoS to be implemented on the wireless network thereby limiting the scope of attacks and what could be targeted.  These new discoveries, however, allow attackers to exploit all TKIP implementations much faster.

You can easily imagine how the new findings will allow future researchers, academia, and hackers to go beyond the attacks outlined above.  It’s only now a matter of time before further compromises and attacks are discovered that could take even further advantage of networks that have implemented TKIP across their enterprise.  With this knowledge, I hope it is understood that TKIP should not be used further on wireless networks that need to be secured.  There are still technologies such as WPA2/AES that have not been compromised and are readily available on commercial grade wireless access points and equipment.   If you haven’t done so already, make the switch.

Security Steps for Compliance Purposes? Why Not Just for the Sake of Security?

All too often I hear businesses ask the question, “What do I need to do to be compliant with XYZ regulation?”.    When I hear this, I know right off the bat, this company is in for a rough road ahead of them.  The goal of proper network security precautions should not be to meet a compliance or regulatory requirement, but instead to secure your data.  If businesses took common precautions to protecting data, they would find themselves in compliance for most regulations, industry requirements, PCI, and even tort laws.

For gicks and kiggles, let’s take a look at requirements for PCI-DSS, GLBA, SOX, HIPAA, FACT Act, PIPEDA, and EU Privacy (EU Data Protection and E-Privacy Directives) to just name a few.   These alphabet soups stand for:

PCI (Payment Card Industry Data Security Standards)  - Basically defines a set of rules, procedures, and policies that must be followed for companies across the globe that accept credit cards.

GLBA (Gramm Leach Bliley Act) - Establishes a set of Safeguards and Privacy Rules for financial institutions and those that provide financing options for their clients.

SOX (Sarbanes Oxley) - Contains 11 titles that describe specific mandates and requirements for financial reporting.  Applies to publicly traded companies.

HIPAA (Health Insurance Portability and Accountability Act) - Applies to companies involved in the health care industry and how to handle personal health information data.

FACT Act (Fair and Accurate Credit Transactions Act of 2003) - Basically contains provisions to help reduce identity theft.

PIPEDA (Personal Information Protection and Electronic Documents Act) - Think GLBA for businesses that operate in Canada.

EU Privacy (EU Data Protection and E-Privacy Directives) - Europe is quite a bit different from the US.  In Europe, privacy is a fundamental human right.   The general rule is to not allow the collection of private data unless permitted to by law.

Right off the bat, people think, “Man, that’s a lot of regulatory requirements”.  Especially when you look at companies that operate in many states and countries.  The fact of the matter is, many of the requirements overlap.

I tried to create a list of some of the most common security precautions that should be taken from a  high level perspective across the above alphabet soup.  Admittedly, there are a number of details missing.  I then cross referenced these and tried to find some of the overlap.   Because many regulations are not very explicit there could be arguements made either way as to whether or not a particular step should be implied and taken.  The basic goal of this chart is to illustrate the overlap.  In addition, to point out that as new laws and regulations are enacted, if you look at security holistically, you will find yourself ahead of the game and not only better securing your data but also meeting existing and future requirements.  It’s a large chart, so you may have to click here to see it all.

Security Steps and Associated Regulation

Of course, many probably also have questions about which of the above apply to them.  Again, another basic chart is below.  Again,  it’s a large chart, so you may have to click here to see it all. If you are in doubt, you can always contact me or one of our consultants at Nuspire.

What Regulations Apply to What Companies

So, I urge you to not look at security steps for the purpose of meeting a compliance issue.  If that’s your goal, you are missing the point.  You will also find yourself going through process after process over and over again every time a new regulation or requirement affects you.  This reactive approach to security can get very costly and cause a lot of unnecessary grief.