A year and a day ago, in the article Radiohead knows more than Microsoft about security, I pointed out the failings of DRM and the licensing based business model. On the third of this month, TR regular Oz_Media made the point that:

MS can’t even secure their licensing system, yet alone the software that uses it.

In truth, the fact Microsoft is increasingly unable to secure its software license enforcement against circumvention isn’t really Microsoft’s fault. It’s out of the corporation’s hands, for all intents and purposes. Microsoft’s real failure is in failing to read the writing on the wall, and make plans that don’t require trying to secure the unsecurable.

The business model Microsoft uses for software like MS Windows and MS Office is, officially, dependent upon the assumption that the corporation can prevent people from using the software without explicit permission from Microsoft or one of its agents or partners. Ultimately, what this means for Microsoft’s current business model is that it relies on the assumption that it can somehow both provide customers with everything needed to run the software and, at the same time, prevent people from using the software for reasons that are not specific to any given copy of the software.

This approach mandates the use of what amounts to DRM software. In this case, because the “content” the vendor wishes to “protect” is itself software, the DRM is integrated with the content itself. There are some minor advantages to this approach over that employed by distributors of non-software content, such as music distributors:

• Because the DRM is integrated with the software, and because of the way people view software differently from music and other entertainment content, it is more acceptable to provide access keys separately from the content and DRM code itself. As a result, copies of the “protected” content do not actually contain the key needed to bypass protection.
• When dealing with a closed source software vendor like Microsoft, it has come to be an expected fact of life that one will end up with stuff installed on the system with which the user is not familiar, and that the user did not explicitly approve, even months after the software was initially installed. Software updates such as those provided by Microsoft Windows Update often make undeclared changes to the system, and people have grown used to assuming they’re wanted and needed changes — or, at least, unavoidable. When DRM software for something like a CD full of music does something like that, however, people recognize it for what it is.
• Because the “protected” content itself is software, the annoyance of having to install and run software that enforces that protection is not so great; users were planning to run software anyway.
• Content, in the non-software sense, is expected to be portable. Software itself is not. This is a somewhat reasonable expectation, because that content is simply data, and software is meant to parse and interpret that data to render it in a form that is meaningful to the user. The software itself, however, must be compatible with the foundation on which it is built, starting at the hardware level, moving up through the OS, and so on. Tying such content to a piece of DRM software ties that content to the DRM software’s compatibility limitations, which tends to annoy people who aren’t using the specific software foundations (i.e., the “platform”) assumed by the creators of the DRM software. This can make DRM functionality less acceptable for that content.

Just like more obvious uses of DRM, however, basing one’s business model off assumptions of the inviolability of DRM code embedded in “protected” software is a losing proposition. Even though your license key for MS Windows is printed on a piece of paper rather than embedded in the software, even though it is expected and generally accepted that a closed source commercial OS will install things on your computer without your explicit permission or knowledge and will probably “phone home” occasionally, even though there is no additional software installation step distinct from access to the “content” you want, and even though the portability expectations are lower, you still have the basic problem that it’s difficult to keep people from “misusing” the license key system.

Inviolable technological enforcement is essentially impossible, in fact, because to allow a user to get access to your software, you have to give that user the means to access it. If that user, either deliberately or without understanding what he or she is doing, decides to violate license terms, that means of access — in the case of how Microsoft implements enforcement, a license key — is no longer restricted to the authorized user. If your intent is also to keep the user from using the software in particular, unauthorized ways, your problem is compounded, because everything needed to violate such restrictions is in the user’s hands. If it wasn’t, he or she wouldn’t even be able to use it the way you intended it to be used in the first place, and you’d have a very difficult time selling software.

Software can be kept secure, but the definition of “secure” in each case must essentially be the definition selected by the software’s administrative user. Unless Microsoft gives up any pretense of selling software to consumers, and starts merely renting out or selling user accounts on software Microsoft employees will manage as administrative users, there is simply no way for Microsoft to achieve inviolable technological license enforcement. If it does so, it will only have the behavior of its employees to police (and, of course, vulnerabilities in the software itself).

The upshot is that license security is simply not enforceable the same way software security is. As a result, the fact Microsoft cannot keep its licensing model secure does not necessarily reflect poorly on its ability to secure its software. If there is blame to be laid at Microsoft’s feet for poor software security related to poor licensing security, it is because Microsoft diverts resources from ensuring software security (an important goal) to chase after license security (an impossible goal).

Of course, it may be that inviolable technological license enforcement is not what Microsoft really wants at this time. Many have hypothesized that piracy is an integral part of Microsoft’s marketing plan, dominating much of the market by any means necessary and trying to maximize revenue once the market is sewn up by selectively enforcing licensing via legal, rather than technological, means. That, however, is a discussion for another day.

————————————————————————————————

As evidenced by cases of mega data breaches of late, properly securing portable computers is problematic even for bigger organizations. In addition, the advent of low cost laptops and netbooks has resulted in a proliferation of such devices as consumers flock to them. The inevitable result is that these users will demand to be allowed to use these machines to access work-related data and networked systems. Indeed, shipments of laptops have already overtaken that of traditional desktops, further increasing the urgency of this issue.

There is no doubt that some very fancy - and expensive - enterprise-grade solutions exist. But in a time of economic uncertainty, the pertinent question has to do with how a corporation can quickly and easily enhance the security of these personal laptops with a limited budget.

I look at a few easy-to-deploy hardware-based solutions here.

Full disk encryption with Trusted Platform Module

One obvious solution for a company sourcing for new laptops would be to specifically request hardware with full disk encryption (FDE) hard disks that are secured by an on-board Trusted Platform Module (TPM) chip. The combination of hardware-based encryption coupled with a hardware-anchored authentication mechanism makes it an unbeatable combination in terms of security.

It must be pointed out though, that FDE does nothing to mitigate the risk represented by service personnel with temporary access to a system. This is best exemplified by the case of Hong Kong-based actor Edison Chan who had service personnel pinch a whole bunch of scandalous photos showing him being intimate with various actresses when his personal laptop was sent in for servicing. The scandal cut short his acting career in Hong Kong. As such, any FDE-related only makes sense if servicing is done by in-house IT personnel.

However, I must say that it is not all that likely for the security administrator to be fortuitous enough to encounter this “perfect” combination of hardware in a laptop at this point in time, which moves us to the next option.

FDE hard disk drive

Recent developments have seen a major vendor shipping its third generation of FDE hard disk drives that are also sold directly to consumers. The newest Seagate Momentus FDE is unique in that it comes in two modes: one is targeted at the enterprise with a firmware that works with special management software, such as McAfee’s ePO to configure and manage drives.

On the other end, there is a BIOS mode, where a BIOS-level password is used to authenticate the user before the computer is started. This opens the door for organizations to easily retrofit Momentus drives into existing laptops. The obvious advantage here is that the encryption is OS-independent, with the hard disk drive writing at full speed.

As such, if budget permits, swapping out the standard hard disk drive in laptops with Seagate’s Momentus FDE in BIOS-level protection mode makes perfect sense. In the case of budgetary constraints, or where users are not agreeable to such a move though, the next hardware-based solution would be to get users to rely on encrypted flash drives.

Encrypted flash drives

A more moderate and less invasive approach here would be to issue out personal flash drives with an on-board authentication and encryption. What it means is that all data on these flash drives are encrypted on-the-fly as they are copied in. They will only be “unlocked” and made accessible upon furnishing the correct password.

Now, encrypted flash drives have been around for a while. The IronKey might be one such option for your consideration, though similar devices are now widely available on the market. It is important to note that many cheaper variants might not actually offer hardware-based encryption, or have blatant gaps in their authentication mechanism that effectively nullify their security mechanism.

Obviously, user training will be required, especially since the drive capacities for such specialized flash drives are still relatively low at between 4GB to 8GB.  However, I believe it will be relatively easy to train even novice users to recognize that only data on the encrypted flash drive should be considered secure. Another added advantage would be that users will become more conscious of following backup procedures as well, making it the best compromise between options.

——————————————————————————————————————-

The need to secure DNS has never been greater. Attacks against DNS cache integrity, including entire zone references, are an easy way for criminals to redirect your unsuspecting users to malicious sites. The IETF and others are working on a set of security extensions to protect the integrity of DNS information as it is shared across the Web. However, these extensions, known as DNSSec, are far from globally accepted, and it will probably be years before they are implemented for all DNS transactions.

So what can you do today to protect your users? Quite a bit, actually. But before we get to the DNS security checklist developed by the U.S. National Institute of Standards and Technology (NIST), it’s important to understand the role DNSSec will play in the future and why its implementation is an important part of global Internet security.

In this article I review how DNS works and I define DNS cache poisoning. In the next article, I describe DNSSec, how it will eventually provide protection from malicious redirection, and what you can do until DNSSec becomes a reality.

DNS review

The DNS (Domain Name System) is a critical component of not only the Internet, but also internal network operation. It uses distributed repositories to convert human-friendly addresses to IP addresses. For example, converting the domain name google.com to 64.233.187.99 or mail.google.com to 64.233.183.17. Routers need the numeric version to make sure packets make it to the right network segment, no matter where it might exist.

Figure 1 depicts the IP address resolution process when the target system and DNS server are both internal. In this example, a workstation must establish a session with a server in Farpoint.company.com. In order for a workstation to implement DNS, it must be running a DNS Client or Client Resolver. The resolver initiates the following process, resulting in the conversion of the domain name to an IP address (Microsoft TechNet, 2008).

Figure 1

Step 1: The resolver checks the resolver cache in the workstation’s memory to see if it contains an entry for Farpoint.company.com. The entry would be present if the workstation had resolved the name to an IP address since the last time it was powered on, and the Time to Live of the entry had not been exceeded. In this example, no entry is found.

Step 2: Having found no entry in the resolver cache, the resolver sends a resolution query to the internal DNS server.

Step 3: When the DNS server receives the query, it first checks to see if it can authoritatively answer a query about resources in company.com. If it can, the server performs a lookup in its internal zone table. In this case, it finds a host Resource Record (RR) that includes the IP address for Farpoint.company.com.
Step 4: The IP address of Farpoint.company.com is returned to the resolver.

Step 5: The resolved domain name and IP address are placed into the resolver cache. Figure 2 is an actual listing of the contents of a workstation resolver DNS cache.

Figure 2

In the previous example, the target server was located within the requestor’s network. But what if the target device is located somewhere on the Internet? In that case, the process is somewhat different. Please refer to Figure 3 as we step through this second DNS resolution process.

Figure 3

Step 1: The resolver checks the resolver cache in the workstation’s memory to see if it contains an entry for Farpoint.companyA.com.

Step 2: Having found no entry in the resolver cache, the resolver sends a resolution request to the internal DNS server.

Step 3: When the DNS server receives the request, it first checks to see if it’s authoritative. In this case, it isn’t authoritative for companyA.com. The next action it takes is to check its local cache to see if an entry for Farpoint.companyA.com exists. It doesn’t. So in Step 4 the internal DNS server begins the process of iteratively querying external DNS servers until it either resolves the domain name or it reaches a point at which it’s clear that the domain name entry doesn’t exist.

Step 4: A request is sent to one of the Internet root name servers. The root server returns the address of a server authoritative for the .COM TLD (Top Level Domain).

Step 5: A request is sent to the authoritative server for .COM. The address of a DNS server authoritative for the companyA.com domain is returned.

Step 6: A request is sent to the authoritative server for companyA.com. The IP address of Farpoint.companyA.com is returned.

Step 7: The IP address for Farpoint is returned to the client resolver.

Step 8: An entry is made in the resolver cache, and a session is initiated with Farpoint.companyA.com.

This process, from the client resolver perspective, is known as a recursive query.

A summary of DNS cache poisoning issues

When attackers want a DNS server to hand out IP addresses to their servers, they must use some method of replacing valid addresses on the caching server with their own. There are few controls to ensure the integrity of a query response, that it came from a server authorized to provide resolution information. Once the attacker’s information is written to a caching server or to a resolver’s cache, DNS cache is said to be poisoned. A more detailed description of one way this might happen is found in DNS Cache Poisoning: Definition and Prevention. Another method, recently disclosed by Dan Kaminsky, is described in An Illustrated Guide to the Kaminsky DNS Vulnerability.

One method developed to help prevent cache poisoning is randomization of the transaction ID. Each DNS query is assigned an ID. Randomizing this value makes an attacker’s job a little harder. Current DNS solutions support this feature, but Kaminsky demonstrated that it isn’t enough to provide reasonable and appropriate protection.

Adding query source port randomization to transaction ID randomization is a good way to increase an attack’s work factor. Instead of an attacker knowing only the transaction ID, he or she also has to know the port from which the transaction was sent. A securely configured DNS server using the most current iteration of BIND, for example, could randomize the port used instead of settling on port 53.

Although this is a big step forward, there are still many DNS servers not using this feature, putting systems querying them at risk. And even if all DNS servers on the Internet used a combination of transaction ID randomization and source port randomization, this should be considered an interim solution at best. The entropy provided is not sufficient to dissuade a tenacious attacker.

The final word

In the next post, we’ll look at what international organizations are doing to strengthen DNS integrity via DNSSec. Since DNSSec is still far from globally deployed, we’ll step through the NIST checklist for securely deploying DNS services without it.

Worried about security issues? Who isn’t? Delivered each Tuesday, TechRepublic’s IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

In March 2008, Josh Buchbinder published proof of concept exploit code for an SMB relay attack vulnerability in Microsoft’s implementation of the Server Message Block protocol. Since that time, a number of security testing tools have become capable of exploiting this vulnerability. According to Microsoft, “Public tools, including a Metasploit module, are able to perform this attack.” The result is that for several years now it has been possible to exploit this vulnerability entirely via code written by other people and freely available on the Internet.

The vulnerability was discovered even before March 2007, though. Christien Rioux announced discovery of this flaw in the Microsoft implementation of SMB at DEFCON in 2000. That means this flaw was first discovered and announced at least 8.25 years ago.

Microsoft finally released a patch for the vulnerability two days ago.

I think this is a good time for some reminders about what constitutes good security practice for software vendors. First of all, you should probably refresh your memory with my article from last month, 5 characteristics of security policy I can trust. In it, I pointed out the following characteristics of good security policy:

1. Full Disclosure
2. Open Development
3. Open Formats
4. Privacy Friendly
5. (Good) Vulnerability Management

On that last subject — good vulnerability management — I have written a few other articles that are relevant:

1. There’s more to security than counting vulnerabilities: The number of discovered vulnerabilities alone provides no useful information about the security of the software. A far more useful metric, if you must select one in a vacuum, would be how the developer responds to vulnerability discovery. The SMB vulnerability that took Microsoft more than eight years to patch is a pretty good indicator that Microsoft is a pretty poor choice for a vendor to trust.
2. Why there’s no such thing as a trusted brand: Corporations are not people. They do not have anything approaching an intrinsic, individual character. The only characteristics that are essentially unchanging in a given corporation are the characteristics that are necessarily intrinsic to all corporations, by their very nature. Everything else can change — and that means no corporation is really “trustworthy”. Don’t place your trust in the vendor. Demand proof. Sometimes, “proof” means “source code”, and if you can’t compile the source yourself, but are only allowed to read source code that someone assures you is the same as what was used to produce a binary that is handed to you separately, you still haven’t really seen proof of anything meaningful.
3. The truth about viruses: Large, corporate software vendors tend to have policies that are optimized for the security of a revenue stream, and not for the security of the customer’s data. An entire class of vulnerabilities, in the form of those primarily of use to viruses, is ignored and left unpatched by vendors like Microsoft. It is simply assumed that the slack will be taken up by antivirus vendors. Take heed of this behavior in a corporation, and realize what it means; given the opportunity, that vendor will ignore a vulnerability rather than fix it.
4. Obscurity is not security: Pretending something doesn’t exist doesn’t make it safe from malicious security crackers. If security researchers can discover a vulnerability, so can unsavory individuals who actually want to use an exploit for personal gain or to wreak havoc, rather than just using it to demonstrate a vulnerability that should be fixed.
5. How should we handle security notifications?: When you get notification of a vulnerability in your software, thank the person who discovered it. Fix the bug. Whatever you do, don’t punish people for giving you information that can help, unless you actually want to be the absolute last person to find out about vulnerabilities in your software in the future. Let your users know about the vulnerability, especially if you won’t be able to fix it quickly, so they can take steps to protect themselves.

This vulnerability is no minor, inconsequential issue. It can be leveraged to take control of a machine without knowing the password. According to the Microsoft Security Bulletin for this issue:

The vulnerability could allow remote code execution on affected systems. An attacker who successfully exploited this vulnerability could install programs; view, change, or delete data; or create new accounts with full user rights.

If nothing else, at least take this piece of advice if you’re a software vendor:

Don’t wait more than eight years to fix a vulnerability that allows someone to remotely gain control of the entire system without even knowing or cracking the password. That’s just irresponsible.

Note: Thanks to Sterling Camden, of TR’s own IT Consultant Weblog, for the inspiration to write this article.

Worried about security issues? Who isn’t? Delivered each Tuesday, TechRepublic’s IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

——————————————————————————————————————- 

Chrome has it.  IE8 and Firefox 3.1 have it.  So what does it mean to forensics investigators?  I’m talking about private browsing–the ability to visit sites, conduct research, or participate in illegal/unethical activities without leaving tell-tale signs behind. 

Recent interest in this capability, sparked by privacy enhancements touted by Mozilla, Google, and Microsoft, prompted me to take a closer look at what this might mean to my forensics investigations.  As usual, the impact on reconstructing questionable behavior depends on the browser used and the skills of both the problem employee and the investigator.

The need for private browsing

Some common reasons given for private browsing include:

• Researching a medical condition
• Shopping from a home PC for a surprise gift or vacation
• Planning a surprise birthday party

However, most family members aren’t going to know how to get around methods already provided by browsers—deleting cookies, cache content, and other session information written to disk.  So these are rather weak arguments for stronger browsing privacy.

A more appropriate reason might be deleting anything written to disk which might be used to track Internet use or other behavior.  This is already an available configuration, at some level, in all major browsers.

The problem with these reasons for eliminating all evidence of systems use is they are often a smoke screen for nefarious or illegal activities, including:

• Cheating on a spouse
• Theft of sensitive information
• Visiting child porn sites
• Participation in questionable organizations

I’m all for personal privacy, but let’s be honest about why many pine for these capabilities.  They want to be able to live secret lives via the Web.  And this is nobody’s business if the actions are not illegal or harmful to others, and they take place on home PCs.  However, when these actions move to company-owned systems, they become potential forensics problems.

Private Browsing Capabilities in IE and Firefox

Microsoft and Mozilla seem to be taking different approaches to private browsing.  Firefox 3.0 had the capability to delete session information when closing the browser.  This isn’t perfect, allowing disk recovery tools access to information, but it works for most reasons people give for privacy.  It looks like Microsoft is simply trying to play catch-up with IE8. 

Tests run against Microsoft’s InPrivateBrowsing feature, however, were successful in retrieving browsing history and other information about user activities.  (See IE8’s ‘privacy’ mode leaks your private data, PC Advisor, 29 August 2008.)  Unless tightened up in the final release, InPrivateBrowsing will protect against ordinary user searches but not from someone committed to retrieving user activity.

According to the Mozilla Wiki, Firefox 3.1 will take a different approach based on the premise that “The purpose of private browsing is to put Firefox into a temporary state where no information about the user’s browsing session is stored locally” (Private Browsing, Mozilla Wiki).  According to Firefox 3.1 functional specifications, the following browser functions will be prohibited from writing to disk when in private mode:

• Cache service
• Cookies service
• Permissions manager
• SSL certificate exception manager
• History service
• Form/Search bar auto-complete history manager
• Download manager
• Login manager
• Content specific preferences manager
• Session restore service
• Error console service

Instead of writing this information to disk, it will be stored in memory and deleted when private browsing ends.

What this means for forensics

The time of easy access to evidence of unwanted activity on company systems is drawing to a close.  Browser privacy capabilities and user awareness of what needs to be done to hide their actions are improving.  Even if the browsers don’t effectively remove all evidence of questionable activity, there are plenty of utilities that do.  The resourceful criminal or reprobate already knows about them and is probably skilled in their use. 

When conducting research for this article, I was unable to find a spot solution for by-passing browser privacy on an end-point device as part of an approved investigation.  However, private browsing only affects the end-user device.  Unencrypted traffic passing over a company’s network is still a good source of digital evidence.  This capability, coupled with device or web filter configurations preventing unauthorized SSL connections, provides still provides reasonable privacy with visibility into questionable activities on company infrastructure.

 Loading …

In February this year, I listed five basic email security tips that everyone should employ. The following is a list of five more good pieces of email security advice:

1. Turn off automated addressing features. As communication software accumulates more and more automated convenience features, we’ll see more and more cases of accidentally selecting the wrong recipients. A prime example is Microsoft Outlook’s “dreaded auto-fill feature“, where it is all too easy to accidentally select a recipient adjacent to your intended recipient in the drop-down list. This can be particularly problematic when discussing private matters such as business secrets.
2. Use BCC when sending to multiple recipients. It’s a bad idea, from a security perspective, to share email addresses with people who have no need for them. It is also rude to share someone’s email address with strangers without permission. Every time you send out an email to multiple recipients with all the recipients’ names in the To: or CC: fields, you’re sharing all those email addresses with all the recipients. Email addresses that are not explicitly meant to be shared with the entire world should, in emails addressed to multiple recipients, be specified in the BCC: field — because each person will then be able to see that he or she is a recipient, but will not be able to see the email addresses of anyone else in the BCC: field.
3. Save emails only in a safe place. No amount of encryption for sent emails will protect your privacy effectively if, after receiving and decrypting an email, you then store it in plain text on a machine to which other people have access. Sarah Palin found out the hard way that Webmail providers don’t do as good a job of ensuring stored email privacy as we might like, and many users’ personal computers are not exactly set up with security in mind, as in the case of someone whose MS Windows home directory is set up as a CIFS share with a weak password.
4. Only use private accounts for private emails. Any email you share with the world is likely to get targeted by spammers — both for purposes of sending mail to it and spoofing that email address in the From: field of the email headers. The more spammers and phishers spoof your email address that way, the more likely your email address is to end up on spam blocker blacklists used by ISPs and lazy mail server sysadmins, and the more likely you are to have problems with your emails not getting to their intended recipients.
5. Double-check the recipient, every time — especially on mailing lists. Accidentally replying directly to someone who sent an email to a mailing list, when you meant to reply to the list, isn’t a huge security issue. It can be kind of inconvenient, though, especially when you might never notice your email didn’t actually get to the mailing list. The converse, however, can be a real problem: if you accidentally send something to the list that was intended strictly for a specific individual, you may end up publicly saying something embarrassing or, worse, accidentally divulging secrets to hundreds of people you don’t even know.

These tips are more related to the ways that users break their own security, rather than protecting oneself against the predations of malicious security crackers. Security can be violated through careless acts more easily than by outside forces. Don’t be your own biggest security concern.

——————————————————————————————————————-

We’re continuously bombarded by statistics showing insider activities as an organization’s biggest threat.  Vendors ply marketing of insider exploit detection tools and other security products, ostensibly to protect our organizations from their employees.  However, proactive detection and intervention processes to identify potential employee security risks and prevent them from becoming security incidents are usually ignored. 

In this post, I step through behavior characteristics usually present before an employee intentionally causes a security breach.  I use research conducted to assess why convicted spies violated national security protocols including,

• Exploring the Mind of the Spy, Dr. Mike Gelles, Naval Criminal Investigative Service
• Reporting Improper, Unreliable, & Suspicious Behavior, Employee’s Guide to Security Responsibilities, Texas A&M Research Foundation
• Security and Suitability Issues, Employee’s Guide to Security Responsibilities, Texas A&M Research Foundation
• People Who Made a Difference, Texas A&M Research Foundation

Although most of us aren’t protecting national defense secrets, I believe the reasons our employees “go rogue” are very similar to why spies betray our trust.

Why employees decide to do the wrong thing

Most of the employees who I personally found violating security policy were at one time valued employees.  They earned the trust of their peers and their managers.  But in every case, there was a trigger that caused an already borderline employee to cross the border.  Could we have prevented these security incidents?  Would intervention have prevented information compromise or system loss?  Could the employee have been helped in a way that prevented an incident?  The answer to all these questions is maybe.

Dr. Mike Gelles researched convicted spies to understand what made them commit treason.  They had all undergone background investigations, were granted security clearances, and, for a time, performed as expected.  Gelles found three conditions which explained why they betrayed their country: presence of a character weakness, a precipitating crisis, and lack of intervention.

No one trait by itself is typically enough to trigger unwanted behavior.  Rather, it is a collection of conditions and character issues which cause an otherwise reliable person to intentionally compromise security.

 (from Security and Suitability Issues)

Character weakness
According to Gelles, a personality or character weakness is “A pattern of behavior that is poorly adapted to the circumstances in which it occurs.”  This behavior, often observable by co-workers, leads to difficulties at work, problems with relationships, and periodic emotional shifts.  The two most common weaknesses observed are anti-social personality and narcissism.

Anti-social in this context does not refer to someone who avoids contact with others.  Rather, it describes a character flaw resulting in rejection of social norms and rules.  Anti-social behavior may lead to a person being unable to develop strong loyalties.

Narcissism results in unwarranted feelings of self-importance.  A person with this character trait is unable to accept failure or criticism.  He or she might accept social rules or norms, but feels he or she is above them. 

A character weakness by itself is usually not enough to cause a person to do the wrong thing. 

Precipitating crisis
Crises come in many forms.  An economic downturn can result in career uncertainty.  Financial problems can apply significant pressure on employees and their families.  Office politics, perception of mistreatment, or a belief that a person is not getting what he or she deserves can also push an employee toward the wrong side of the line dividing acceptable and criminal behavior.

Lack of intervention
Employees about to go rogue often exhibit behavior observable by co-workers.  Examples include (Security and Suitability Issues),

• Appearing intoxicated at work
• Sleeping at the desk
• Unexplained, repeated absences on Monday or Friday
• Actual or threatened use of force or violence
• Pattern of disregard for rules and regulations
• Spouse or child abuse or neglect
• Attempts to enlist others in illegal or questionable activity
• Drug abuse
• Pattern of significant change from past behavior, especially relating to increased nervousness or anxiety, unexplained depression, hyperactivity, decline in performance or work habits, deterioration of personal hygiene, increased friction in relationships with co-workers, isolating oneself by rejecting any social interaction
• Expression of bizarre thoughts, perceptions, or expectations
• Pattern of lying and deception of co-workers or supervisors
• Talk of or attempt to harm oneself
• Argumentative or insulting behavior toward work associates or family to the extent that this has generated workplace discussion or has disrupted the workplace environment
• Writing bad checks
• Failure to make child support payments
• Attempting to circumvent or defeat security or auditing systems, without prior authorization from the system administrator, other than as part of a legitimate system testing or security research

The problem is that co-workers and managers either don’t recognize the signs or are unwilling to get involved.  If employees learn to identify and report predictive behavior, steps can be taken to prevent possible security incidents.    

Preventing rogue behavior

Most organizations have controls in place to detect or prevent unwanted behavior.  But as we know, no control or set of controls is 100 percent effective, especially when the attacker is an authorized user of our information resources.  We also know that prevention is much better than trying to detect, contain, and recover from an incident.  So, how can we prevent employees from doing bad things?

The most effective means of identifying a potential employee security threat is employee education and participation.  Train your employees to look for suspicious or questionable behavior.  Provide a means to report this behavior and allow anonymity.  Employee understanding of danger signals and a willingness to report them is your best insider threat control.
 

(from Security and Suitability Issues)

The paper, People Who Made a Difference, contains several examples of how government employees helped identify security risks, including the following:

A co-worker reported in 1986 that Michael H. Allen was spending excessive time at the photocopier in their office. This report led to investigation by the Naval Investigative Service. A hidden camera was installed near the photocopier in Allen’s office. The resulting videotape showed Allen copying documents and hiding them in his pocket.

Allen was a retired Navy Senior Chief Radioman working at the Cubi Point Naval Air Station in the Philippines. He confessed to passing classified information to Philippine Intelligence in an effort to promote his local business interests. He was found guilty of ten counts of espionage.

It also contains examples of what happens when employees either look the other way or don’t think about what they see.

Army Warrant Officer James W. Hall, III was sentenced to 40 years in prison for spying for both the former East Germany and Soviet Union from 1982 to 1988. He compromised U.S. and NATO plans for the defense of Western Europe. After his arrest, Hall said there were many indicators visible to those around him that he was involved in questionable activity.

Hall sometimes spent up to two hours of his workday reproducing classified documents to provide to the Soviets and East Germans. Concerned that he was not putting in his regular duty time, he consistently worked late to complete his regular assignments. Using his illegal income, Hall paid cash for a brand new Volvo and a new truck. He also made a large down payment on a home and took flying lessons. He is said to have given his military colleagues at least six conflicting stories to explain his lavish life style, but Hall’s co-workers never reported any of his unusual activities. After returning from Germany to the U.S., he traveled to Vienna, Austria, to meet with his Soviet handler.

Once an employee is identified as having an issue, and before he or she actually commits a crime, intervention might be the answer.  Encouraging an employee to make use of services, like an Employee Assistance Program, might help him or her get the counseling or other help necessary to deal with personal or family crises.  Often, employees suffering from common psychological conditions, such as depression, receive the help they need.  They gradually find their way back from the brink, you get to keep a valuable member of your workforce, and your information assets remain safe.

The final word

Yes, employees are an organization’s biggest security threat.  But they are also its greatest defense against employees who might cross over to the dark side.  Make sure your employee security awareness training includes information about detecting and reporting suspicious behavior. 

————————————————————————————————

Just two updates for October’s Patch Tuesday

System administrators still reeling from last month’s bumper Patch Tuesday will be glad to know that they can rest easier this month. For the month of October, Microsoft will be releasing only two updates, with one rated as “critical” and the other as “important.”

Organizations are advised to exercise vigilance in patching the critical flaw, as it involves a vulnerability in Windows XML Core Services 3.0, used extensively by Windows to manipulate XML data. Consequently, affected versions of the operating system range from Windows 2000, XP, Server 2003, Vista, and Server 2008. In addition, this flaw is also present in XML Core Services 4.0 and 6.0, although this is viewed as less critical.

In a written statement, Don Leatham of Lumension Security (formerly PatchLink) urged IT administrators to patch this vulnerability. Leatham noted that, left unaddressed, the flaw could compromise the integrity of a company’s sensitive information — due to the fact that this vulnerability impacts a broad range of Microsoft platforms.

The second bulletin is related to the same XML issue, though specific to Office 2003 and Office SharePoint Server. Still, it could still result in a remote code execution flaw, and hence should not be taken lightly.

Flaws targeting Acrobat spotted in-the-wild

Days after initial announcements of a serious Adobe Reader flaw, working exploits were spotted in the wild. The exploit in this case leverages on CVE-2008-2992 by means of a crafted format string argument to execute arbitrary code. The delivery mechanism is by means of a malformed PDF file.

Bojan Zdrnja over at SANS Internet Storm Center highlighted a sample that was sent to him by one of his readers:

Unfortunately, Wayne [the reader] is right - these PDF documents exploit the JavaScript buffer overflow vulnerability. This is not surprising, though, as a fully working PoC has been recently published as well, but it’s interesting to see that the attackers modified the PoC a little bit, probably in order to evade anti-virus detection.

Zdrnja also noted that none of the AV products detected his malicious PDF sample — not really surprising given how new it is.

At this point, Adobe has updated Adobe Reader 8.1.2 and Acrobat 8.1.2 to address the vulnerabilities. Given the popularity of the PDF file format, and the ease of delivery via e-mail, it is more important than ever to ensure that patching and upgrading are promptly executed.

Adobe eliminates Cold Fusion vulnerability

Adobe has issued a security fix for its ColdFusion. The patch eliminates a vulnerability that allows attackers to circumvent existing restrictions on a server operating in a shared hosting environment.

According to Adobe, ColdFuson 8.0, 8.0.1 as well as ColdFusion MX 7.0.2 are affected. You can check out the Adobe security bulletin here for patch instructions.

Security researchers to demonstrate WPA packet injection

German Security researcher Erik Tews and co-researcher Martin Beck have found a way to break the Temporal Key Integrity Protocol (TKIP) key used by the Wi-Fi Protected Access (WPA) encryption standard. At next week’s PacSec 2008 security conference in Tokyo, the duo will give a presentation on this titled, “Gone in 900 Seconds: Some Crypto Issues with WPA.” They will also leverage on their findings to demonstrate data injection into the WPA traffic between a router and a laptop.

The precise method to achieve the data injection has yet to be made public, though it is known that it involves breaking the Temporal Key Integrity Protocol (TKIP) key of the Wi-Fi Protected Access (WPA). This was achieved by tricking a WPA router to disgorge large amount of data, coupled with a “mathematical breakthrough” to crack TKIP without using a dictionary attack. To be clear, the team has not managed to crack the actual encryption keys used to secure data in WPA, so WPA appears to remain secure at this junction.

Moving ahead, the obvious solution at this point would be to change to the WPA2 encryption scheme, which uses the more robust Advanced Encryption Scheme (AES) encryption instead of TKIP.

Are you using wireless in your organization? Are you using WPA or WPA2 at this point?

Feel free to discuss the various security events here.

Graphical user interfaces environments are complex things, these days. It can take thousands, even millions, of lines of code to write the software for a basic GUI environment. Consider a rich desktop environment on Ubuntu, for instance — arguably the most popular Linux distribution. The X Window System, in the form of X.Org, is around two million lines of code. The GNOME desktop environment, installed atop X.Org, adds another thirteen million on top of that, give or take. Adding Compiz Fusion to that would hardly have any effect on the overall complexity of the software projects used to construct your GUI environment; it’s only about two hundred thousand lines of code.

Fifteen million lines of code is a lot, of course. Using X.Org is no trivial thing, in terms of how big a commitment to the total complexity of software installed on your computer. It’s also a rough necessity, if you want a modern GUI environment running on your Unix-like system. Of course, at the other extreme from high weight desktop environments like GNOME are things like dwm, which boasts fewer than 2000 lines of C — but you still need the X Window System to run it, making the total something like 13 million and two thousand.

All of this starts to look like small potatoes next to some other GUI environments, however. Certain commercial OSes have even bigger, more complex projects tied to their GUI environments, such as the Aqua environment for Apple MacOS X or Aero Glass for MS Windows Vista. It isn’t so easy to provide estimates of project size for these, because in each case the software is closed source, and its source code is jealously guarded by its respective corporate vendor, but the source for such GUI environments can be reasonably expected to run in the tens of millions of lines of code.

Complexity, unfortunately, is the enemy of security. Every time you increase the complexity of a system, you increase the opportunity for something to go wrong in its design. The more lines of code in your system, the more opportunities there are to introduce bugs when developing the system; the more bugs there are, the more opportunities you have for bugs that introduce security vulnerabilities. As phrased in the Source lines of code article at Wikipedia, under the SLOC and relation to security faults heading:

A number of experts have claimed a relationship between the number of lines of code in a program and the number of bugs that it contains. This relationship is not simple, since the number of errors per line of code varies greatly according to the language used, the type of quality assurance processes, and level of testing, but it does appear to exist. More importantly, the number of bugs in a program has been directly related to the number of security faults that are likely to be found in the program.

This has had a number of important implications for system security and these can be seen reflected in operating system design. Firstly, more complex systems are likely to be more insecure simply due to the greater number of lines of code needed to develop them. For this reason, security focused systems such as OpenBSD grow much more slowly than other systems such as Windows and Linux. A second idea, taken up in both OpenBSD and many Linux variants, is that separating code into different sections which run with different security environments (with or without special privileges, for example) ensures that the most security critical segments are small and carefully audited.

Bugs are not the sole source of software security vulnerabilities, however. Conscious architectural design decisions can also lead to security issues. Introducing a bug in the form of a buffer overrun can produce an arbitrary code execution vulnerability, but so can a decision to allow shell scripts “owned” by the administrative user to be executed SUID when they’re world-writable. That’s why Unix systems usually disallow execution of shell scripts that are SUID root.

Enno Boland, one of the contributing developers at suckless.org (the guys who develop the aforementioned wmii), suggests that the X Window System is poorly designed, and I tend to agree. Oh, I know creating and maintaining the underlying framework for an entire modern GUI environment is not an easy task, and I’m sure that at this point in my life I’m not competent to do a better job than the X.Org project, but that doesn’t change the fact that there are some poor design decisions at work there, and that it appears to lack the kind of engineering discipline one might desire from a project of such widespread impact.

The X Window System, like the Aqua and Aero Glass GUI environments, tries to do too many things within one unified package. This creates significant complexity, which in turn masks security issues and other bugs as well as creating ample opportunity for poor architectural decisions to creep in. It does do at least one thing right that most other modern GUI systems don’t, however; it separates concerns between the underlying windowing system and the actual interface components in the form of a window manager. This helps to keep each segment simpler by reducing coupling, providing stable APIs, and offering the opportunity to minimize the complexity of the window manager component separately from the windowing system component itself. X.Org is still about thirteen million lines of code, though.

The suck less philosophy, suckless.org’s approach to programming excellence, has this to say about secure development:

Code complexity is the mother of bloated, hard to use, and totally inconsistent software. With complex code, problems are solved in suboptimal ways, valuable resources are endlessly tied up, performance slows to a halt, and vulnerabilities become a commonplace. The only solution is to scrap the entire project and rewrite it from scratch.

Such sentiments are expressed about software projects such as Microsoft Windows all the time. Unix and Linux users, especially, seem fond of the notion that the only way to fix problems endemic to MS Windows is to scrap the entire code base and start over. Early reports from the Windows 7 project seemed to indicate that was happening to some extent, but it is beginning to look like that was an erroneous picture of what is going on. It’s easy to understand why Microsoft would resist such a drastic measure: after all, the full benefits of a complete rewrite are lost if you only make the same mistakes the second time that you did the first, and if you don’t make the same mistakes with a complete rewrite of something like MS Windows, you break all backward compatibility and end up with something that, if you were to be perfectly honest about it, couldn’t even be called “Windows”.

The suggestion that perhaps the X Window System should get the same treatment people recommend for MS Windows is far more rare. In fact, even in Enno Boland’s public complaint about the “(un)-unixy” design of the X Window System, I don’t see any explicit call for a complete rewrite and replacement of a windowing system framework for Unix. In the long run, however, that may be exactly what we need if we want to drastically improve the security of the average Unix-like system desktop.

——————————————————————————————————————-

When most people think of physical security, of locking computers or other sensitive information away from unauthorized access, they think of door locks. One of the most common types of door locks is still key and pin tumbler. But how secure are these systems? Is a single locked door considered reasonable and appropriate security? Based on current research, the answer to the first question is increasingly negative. The answer to the second has always been in question.

What is a key and pin tumbler lock?

At its most basic design, a pin tumbler lock, as shown in Figure 1, relies on a system of pins to either prevent or allow a plug to rotate within a lock cylinder. When a key is inserted, the bottom pins are raised to the shear line and the plug is able to rotate (Laxton, Wang, and Savage, 2008, p. 2).

Figure 1

The keys used are cut using a bitting code. The key and pin tumbler system relies on two assumptions.

1. No unauthorized people know the bitting code for a specific lock
2. Keys are kept secure, and if lost, the locks are replaced

Problems with physical key access control

There are two problems with relying on the physical security of keys. The first has been a problem since key locks were invented; keys are lost or stolen. Sometimes keys are only “temporarily mislaid.” However, even if a key is in the wrong hands for even a short time, several methods exist to duplicate it, including, such as impressioning. A manual key decoder, as shown in Figure 2, can also use a key to obtain the bitting code for a key/lock pair (Laxton, Wang, and Savage, 2008, p. 2). Other approaches like, lock bumping and lock picking exploit weaknesses in lock design.

The problem with these methods is access. Access to either the key or the lock is necessary, putting the attacker at risk and raising the work factor. But now a criminal might not need actual access to a key, or its lock, to duplicate it.

Figure 2

Sneakey

Research recently published by Benjamin Laxton, Kai Wang, and Stefan Savage (the team) demonstrates the possibility of duplicating a key using a digital image. Using the same approach as implemented with manual key decoders, an attacker can derive bitting codes from digital images obtained with cameras strategically placed outside the normal physical operating area of the key’s owner. In other words, the attacker does not need to gain physical access to the facility or to the key to make a duplicate key.

The research focused on two common household key types: the Kwikset KW-1 and the Shlage SC-1. It’s necessary to at least know the blank used to create the key. Applying the bitting code to the wrong blank doesn’t get an attacker very far.
To test long distance image capture as a means to obtain key characteristics, the team used a C5 spotting scope, Teleview PowerMate 4X Tele-extender, and Cannon 40D Digital SLR camera. The setup, which weighed about 16 pounds, is shown in Figure 3.

Figure 3

The team took photos of keys from 35, 65, and 100 feet to test the process. A proof-of-concept photo, taken at 165 feet, is shown in Figure 4.

Figure 4

Once the team obtained a key image, they followed the following steps to arrive at a key that would fit into the corresponding lock:

1. Measurements on the reference key image are taken and the pixel/mm ratio for that image is computed. This step only needs to be done once for each key blank of interest.
2. A digital image of a target key is acquired.
3. The user specifies point locations in the target key image that match those in the reference key image.
4. Using the point locations, the homography that maps the target key onto the reference key is computed.
5. Using the known pixel/mm ratio and the mm dimensions for the distance to first cut and inter-cut distance, the expected locations of each cut point along the key shaft are deterministically located.
6. A heuristic search for the depth of each key-bit can be carried out automatically or refined with user input.
7. Given the cut depth measurements for the target key in mm the key bitting code is given by matching the mm measurements to the published manufacturers specification for cut depths (e.g., a Kwikset “1” cut is 0.329 inches from the base of the key blade).

The results were interesting. At 35 feet, the key image was properly decoded 4 out of 4 times. At 65 feet, 3 out of 4 attempts were successful. At 100 feet, the team was able to cut the right key 2 times out of 4. Details about this research are found in the team’s findings paper.

So do key pin tumbler locks provide reasonable and appropriate security?

A single locked door has never been enough to protect sensitive data or critical systems. An effective physical security design includes multiple obstacles an attacker must overcome. These include:

• Fences
• Motion and sound sensors
• Cameras
• Alarms
• Guards
• Multiple locked doorways
• Employee awareness of piggy-backing, social engineering, or other common methods of circumventing physical controls

Putting aside the “single door” vulnerability, requiring employees to maintain keys is a bad idea. They are commonly lost or stolen with no notice to management. Even when management is informed, the cost of replacing affected locks is often too expensive or too much trouble.

Use of centrally managed cipher locks, biometric entry systems, or a hybrid solution is the best way to implement locks as part of an overall physical security strategy. Codes are easily changed when employees leave the company, and access via the employee’s biometric signature is quickly disabled. Linking a centralized management system to an account provisioning solution can automate this process, based on information entered into the HR database.

The final word

Will an attacker take a picture of your keys lying on your desk any time soon? Probably not. But the threat exists. More important, however, are the physical access opportunities provided criminals when a well-designed, layered, physical security strategy is not implemented. This includes training employees to question the presence in secure areas of anyone they don’t recognize.

Worried about security issues? Who isn’t? Delivered each Tuesday, TechRepublic’s IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!