Archive for November, 2009

Windows Security: Part 4

One of the most important security-related functions in an operating system is system auditing and logging. Having audit log entries to inspect is essential in establishing accountability for individual users as well as for system administrators. Log entries are also extremely helpful in incident investigations—log entries often reveal who did what and when, helping incident response team members reconstruct events related to actual and attempted security breaches.

Recent Windows operating systems have Event Logging embodied in a number of logs, of which the System Log, Security Log, and Application Log are the most basic and essential for security. The System Log logs system-related events such as errors, warnings, and a variety of other information related to the operation of the system and network-related events. Although not specifically designed to provide security information, this log can provide important clues about what happened when denial of service and other types attacks have occurred, when a perpetrator has tried to install malicious code, and when other security-related events have transpired. Depending on the particular Event Categories that are enabled, the Security Log captures data about successful and failed logins, access to files and directories, changes in policy, privilege use, the processes that have started and stopped, and other extremely useful information. The Application Log provides information about how applications are running, including any errors that may have occurred. Double clicking on an entry in any of these three types of logs produces more detailed information, something that I have often found to be quite helpful in investigations of suspicious events. Other logs such as the Internet Explorer Log, Directory Service Log (on Domain Controllers) and DNS Server Log (on DNS servers) can also be quite useful.

Windows Event Logging has improved considerably since this type of logging first appeared in Windows NT. Explanations of some event codes have since Windows 2000 was released been available in the Event Viewer. Several Event Categories in Security Logging have since Windows XP was released been enabled by default. Windows operating systems since Windows Server 2003 list the source IP address of every logged event in the Security Log. But alas, some logging-related features that are routinely available in competing operating systems are still not available in Windows systems. Most bothersome to me is that fact that there is no built-in mechanism to transport log entries to a central server. It is possible to configure FTP or a similar protocol to push or put log entries to a server, but doing so is not inefficient compared to syslog facilities in Unix and Linux systems. It is also not very satisfactory for near real-time log entry analysis, because it is necessary to schedule FTP transfers at discrete intervals in time. In contrast, syslog continuously sends selected log data to any desired destination as soon right after each log entry is created. Real-time log data are required for event correlation purposes, however.

An alternative is to install agents such as Snare by Intersect Alliance to transport log entries as syslog output. Agents introduce a new set of problems, however, because they consume resources in already-too-fat clients. Additionally, these agents are not 100 percent accurate in the data they send, something that can easily invalidate forensics analysis efforts.

The day of having to inspect individual system log entities is long past us. We need central log data repositories and event correlation to spare us from an otherwise overwhelming and ultimately, financially costly task. To truly be useful, therefore, Windows systems need to be able to send Event Log information in near real time information to wherever analysis and correlation of them will occur, e.g., a Security Information and Event Management (SIEM) tool. Hopefully, some Windows operating system of the future will contain this important functionality.

Categories: Uncategorized Tags:

Windows Security: Part 3

Active Directory (AD) is a set of Lightweight Directory Access Protocol (LDAP)-based directory services designed primarily to enable Windows users, applications and processes to be able to locate services and objects. Ever since AD was first introduced when Windows 2000 was released, Microsoft has highly touted its virtues almost incessantly. After all, not only does AD solve the problem of finding something in today’s too often gargantuan network environments, but it serves as a kind of backbone for security in Windows products, both servers and clients alike. AD offers Group Policy Objects (GPOs) that enables system and security administrators to choose security settings (e.g., password minimum length, Event Log settings, and much more), which if embodied within Domain GPOs apply across an entire Windows domain. AD also does much more—so much that I could write a 20-page blog posting that might possibly bore you to death, so I won’t.

Microsoft was correct in claiming that AD is a big step up from the way Windows security used to work (e.g., in Windows NT). At the same time, however, AD is no panacea from a security prospective because AD is so complex. Consider, for example, the way Group Policy works. AD consists of many hundreds of objects, each of which generally has multiple attributes or properties. Each of these objects and object attributes has permissions and ownerships. If any one of these is inappropriate (e.g., Authenticated Users are able to change an object or property), the potential for subversion of a critical AD function or possibly AD itself skyrockets. Fortunately, default installations of AD-capable versions of Windows operating systems have had good permissions and ownerships, but accidental mistakes in changing them to bad settings from a security perspective are a real possibility.

Another complication that AD causes is Group Policy confusion. GPOs can be linked at any of four levels: Organizational Units (OUs), Domains, Sites and Local. If there are different GPOs linked to different levels, rules determine which has precedence, i.e., which particular GPO will prevail. If different GPOs are linked to OUs, Domains, Sites and the local computer and if a Site-linked policy has the No Override setting enabled, then that Policy will prevail. On the other hand, if there is no Site-linked GPO but there is a Domain-linked GPO, that policy will prevail if it has the No Override setting enabled. When GPOs are linked to OUs as well as child and grandchild OUs, the policy linked to the GPO that is lowest in the OU hierarchy will prevail unless a policy linked to a higher-level OU has the No Override setting enabled. And within any of the four GPO levels, a Domain Administrator and Enterprise Administrator can select from multiple GPOs (if they exist) to determine which will have precedence. The craziness of all these rules has resulted in many an error or oversight that has resulted in negative consequences such as system administrators thinking that certain security settings were in place when they were in fact not. The confusion and frustration surrounding GPOs motivated Microsoft to develop and include several free tools such as the Resultant Set of Policy (RSOP) Tool that allows administrators to query for information from WXP, WS2003/8, Vista and Windows 7 systems to find what policies have been applied and the order in which the policies have been applied. Although these tools have helped many administrators, they constitute an extra “thing” that administrators have to learn how to use and run. Making GPO precedence rules much more straightforward would have been much better.

Finally, migrating users, groups and policies to a new domain is anything but easy. Reacting to the pain within its customer community, Microsoft again developed and distributed free tools such as the Active Direction Migration Tool (ADMT) to facilitate doing this task, but despite Microsoft’s good intentions, these tools go only so far in solving the problem. Commercial tools that do a better job are available, but why should someone have to buy and pay maintenance fees for a function that Unix and Linux administrators can do easily without any additional tool?

Please do not get me wrong—I like AD. The alternative, using Windows workgroups, is frightening. But AD still has a long way to go before it becomes what system and security administrators really need. Microsoft—I hope you are listening.

Categories: Uncategorized Tags:

Windows Security: Part 2

Vulnerabilities in Microsoft’s implementation of the Server Message Block (SMB) protocol, the protocol behind Windows shares, have plagued Windows systems security for years. SMB is a strange protocol, and (not surprisingly) its strangeness and the many identified vulnerabilities in it go hand-in-hand. Consider how SMB works:

1. A client sends a Session Request Block to an SMB server (a server that shares files). This request includes the names of the client and server.
2. In response to the client’s request, the server forms a TCP connection on TCP port 445 in recent Windows operating systems and on TCP port 139 in older ones. The server does not verify the IP address of the client!
3. The client sends the server a list of all the SMB “dialects” it supports. Dialects are versions of SMB.
4. The server chooses the highest (most recent) dialect that is common to it and the client and sends a dialect list in which the one to use is shown.
5. The client sends a session setup request that contains a header that includes information such as the user ID, password, domain name, version of operating system, and some additional information.
6. The server responds by sending a token that includes the same kinds of information that was in the session startup request, but this time pertinent to the server. Also included is the type of file system that the server has.
7. The server selects the specific connection point (i.e., on the hard drive) and informs the client accordingly.
8. The client connects at the designated connection point (called the “Tree ID”) and sends a 2-byte SMB header to the server to verify to the server that the connection request was successful.
9. A simple kind of echo mechanism keeps the share connection alive until the client disconnects.

Many vulnerabilities in Microsoft’s implementation of this eccentric protocol have been identified over the years. A client can, for example, easily spoof an identity other than its own. A server can also be flooded with random requests during the negotiation process with the client to the point that it crashes. Forged SMB packets containing illegal values can cause an SMB server to crash or freeze. A set of related vulnerabilities allow unauthorized code to be remotely executed on an SMB server, e.g., when a specially crafted SMB packet is sent to the server. SMB clients and servers are also vulnerable to a number of buffer overflow attacks. A good example is a boundary error in the SMB client code when SMB “Trans” and “Trans2” commands are being processed. A malicious SMB server can cause a buffer overflow by sending specially crafted transaction response information to a vulnerable client. And these are just a few of the many vulnerabilities that have been found.

Microsoft has been commendable in providing patches for most of the SMB-related vulnerabilities that have been found. Additionally, Microsoft developed Server Message Block Version 2 (SMBv2) in an attempt not only to improve the performance of its SMB protocol, but also to address security weaknesses in earlier versions of this protocol. Interestingly, however, some of the most serious vulnerabilities found to date are in this new version of this protocol.

Microsoft’s SMB protocol is not the only file access protocol that is riddled with vulnerabilities. SAMBA, another version of SMB used in Unix and Linux environments, also has more than its fair share of vulnerabilities, as also does the Network File System (NFS), which is used primarily in Unix and Linux systems. What is troubling about Microsoft’s SMB protocol, however, is that it has been around for a long time and has in theory been subjected to intensive security scrutiny because of Microsoft’s Trusted Computing Initiative (TCI), yet new, critical vulnerabilities in this protocol seem to surface regularly. Clearly, Microsoft would do well to approach security weaknesses in this protocol with a higher priority.

Categories: Uncategorized Tags:

Windows Security: Part 1

Windows 7 has been released to the public a little over three weeks ago, and although various advertisements tout the virtues of this new operating system, there appears to be not much of a reaction within the user community. My purpose in saying this is not to run down Windows 7. In fact, it appears to be a very good operating. (But then again, compared to Vista, what wouldn’t be good?)


The virtues of Windows 7 aside, there appears to be a continued use of but waning interest in Windows operating systems in general. I remember when Windows NT was first released. There was a kind of electric “buzz” within the user community. Tech “ragsheets” soon were filled with news about this then new operating system. New magazines such as what was then called Windows NT Magazine appeared and quickly picked up thousands of subscribers. The world of desktop computing quickly switched from Novell NetWare to Windows NT. To some degree, the same was true of both Windows 2000 and Windows XP. Bill Gates seemed to own the world, and the world was excited about what was happening.

Anticipating that the at-the-time Windows revolution would create the need for security courses on Windows operating systems, I decided to create a multi-day course on Windows NT security. Doing this was anything but an easy task, partially because Microsoft did not at the time make sufficient information about NT security available (although since then this vendor has done a great job in supplying such information). But frankly, I also did not know much about Windows, let alone security in Windows operating systems, and what I found out about these operating systems seemed very strange to me. Why, for example, were there settings in the Registry that were redundant with settings in c:\%systemroot%\system32, allowing for multiple ways for perpetrators and malware to change these settings without authorization? (By the way, I have still not figured this issue out—if you know, please tell me.)

I finally got my Windows NT course together and began teaching it. Demand was amazingly high, and I started to realize that I may have been able to quit my job and just teach Windows NT courses to make a living, although I never did so. I taught for both SANS and the Computer Security Institute (CSI), as well as for others, and I remember one time in 1998 that I had approximately 300 attendees in a two-day Windows NT security course that I taught at a SANS conference in San Diego. I could not even begin to make out the faces of attendees way back in the last rows.

About four years later I developed a course in Windows 2000 security. Windows 2000 was revolutionary in that it was the first operating system with Active Directory (AD), and much of security was (and still is) built around AD. Windows 2000 also introduced many new and highly useful features, many of them security-related, and interest in Windows 2000 and Windows 2000 security continued to be high, as evidenced by good attendance at the courses on this subject that I taught at the time.

SANS and I went separate directions in 2002, but this organization continued to offer a course (complete with certification, yet!) on Windows 2000 security and later (because by then there were several different Windows operating systems) just Windows security. I assume that there were many attendees of this course; but one thing I distinctly noticed was that the demand for the Windows 2000 security course I taught for CSI at that time started to subside. I developed and taught courses on Windows XP security and later Windows Server 2003 security and the trend continued—fewer people were signing up for the course. The last Windows Server 2003 security course I taught had only nine attendees. The same must have been true for the SANS Windows security course, because I notice that at many SANS events, this course is no longer taught.

Like anything else, one something that was originally radically new first surfaces, it is “hot,” but then the excitement starts to die. Additionally, if a system administrator knows how to lock down version n – 1 of a Windows operating system, much of that knowledge will apply to version n, in large part (but not completely) precluding the need to go to training on how to secure version n. Additionally, Vista (which represents a horrible miscalculation on Microsoft’s part) substantially dampened enthusiasm related to Windows operating systems.

The proverbial baton of excitement has been passed to Linux, especially to the Debian flavor(and, in particular, the Ubuntu flavor of Debian), but the majority of users still use Windows. Which vendor still sells the most operating systems? Microsoft, of course. Windows operating systems are going to be with us for a long time. Microsoft (but not necessarily other operating system vendors) will continue to make a fortune off of operating systems as well as the many useful applications and other products that this software giant makes. But don’t expect anybody to be all that excited about them any more—not even if nice new technology like Windows 7 surfaces.

Categories: Uncategorized Tags:

Google Is Setting the Pace for Cloud Security

Google, the chief evangelist of that awful “C word,” has been experiencing some cloud (the “C word”) services-based incidents. Not too long ago, a software flaw in Google Docs resulted in the files of certain users to be obtained by others to whom access was not authorized. Earlier this week the Electronic Privacy Information Center (EPIC) filed a complaint Tuesday with the FTC, asking that the Federal Trade Commission conduct an investigation into possible privacy protection letdowns in Google’s cloud computing services. Gmail hosted e-mail services, Google Docs, and Google’s Picasa photo sharing service are the best-known of these services.
As I have said many times before, Google deserves much of the credit for advancing IT technology to new heights. At the same time, I wonder if Google executives are aware of the extent of dangers inherent in cloud services. Google has not fared all that badly so far, but the potential for worse things to come concerning security incidents appears to be very high.

Google recently has come up with a rather unusual new solution for privacy protection issues—a privacy dashboard designed to protect customers better by offering more transparency to what others can find out about them as well as control over their personal information. This dashboard shows Google account settings and whether links to management pages for such accounts result in information being publicly available. I went to a gmail group account that I share with a few friends and looked at the Google dashboard information for this account. I saw almost nothing of real relevance or interest, but then again, this might simply indicate that little information is associated with the account, something that I suspect is true. Still, I have a hard time imagining that this dashboard would be all that helpful to users worried that their personal information might leak to the public. At the same time, however, something is better than nothing when it comes to information.

For better or worse, Google, the leader in cloud security, is also setting the pace for cloud security. Simply speaking, cloud security is a relatively new issue. Google needs to assert its leadership in the cloud arena by going farther than it has–by developing, testing and implementing effective security mechanisms in cloud computing. The Google Dashboard is a good start, but cloud security requires much more.

Categories: Uncategorized Tags:

The “New” SSL Vulnerability

New vulnerabilities in operating systems and applications are being discovered at an ever increasing rate. Some are serious, whereas others are not, but a discovery of an extremely serious vulnerability, such as one that can cause unauthorized remote and privileged access to a myriad of hosts, is not all that frequent. A new vulnerability in the secure sockets layer (SSL) protocol that was announced last week is notably contrary to this trend.
The new SSL vulnerability can be exploited through a man-in-the-middle (MITH) attack despite that fact that a host and application are secure and that information transmitted between a client and a server is encrypted. Servers such as Web servers, mail servers, databases, and others in shared hosting environments are the target. All the attacker must do to exploit this vulnerability is to insert text into traffic going between a client and a server when the session is being renegotiated (as frequently happens in SSL sessions), leading to malicious fragmentation of SSL transactions (explained shortly). Positioned as a MITH between the client and server, perpetrators can inject malicious commands of their choice into the traffic going between them. SSL 3.0 and higher and all versions of the transport layer security protocol (TLS), a follow-on version of SSL that is backward compatible with SSL, are affected.
Fragmentation in SSL is a normal and important part of sending and receiving data. It involves breaking the data into discrete blocks for management purposes The data can (optionally) next be compressed (if SSL is so configured), and then a message authentication code (MAC) is applied for the sake of data integrity. Afterwards the data are encrypted, a header is attached, and finally the data are sent in a TCP segment. When the data reach the destination host they are decrypted, checked for integrity, decompressed, and reassembled, and finally sent to the client or server.
This SSL vulnerability is extremely serious because if affects just about every browser. Consequently, nearly every computer in the world is vulnerable. Browser vendors are working frantically to produce a patch or workaround for this vulnerability.
I put the word “new” in the title of this posting in quotes because this vulnerability is really anything but new. Various sources indicate that the black hat community has known about it for at least one year. Part of the white hat community, including the ICASI and IETF organizations, has been aware of it for at least two months. These organizations launched a project named Project Mogul to develop a solution. Although they agreed to keep quiet about it, last week one member of this project posted information about it on his blog site. The media quickly found this posting and disseminated the information it contained.
Understandably, the information security community has a very serious concern about the potential for widespread exploitation of this vulnerability. Despite banks and other organizations having fixed all known vulnerabilities, they have been falling victim to mysterious attacks designed to steal financial and other data. I strongly suspect perpetrators have been widely exploiting this “new” vulnerability in these attacks. And given that many organizations will not install patches and workarounds that will in time be available for browsers, attacks of this nature are bound to successfully continue for a long time.
The moral of this story is not very comforting. You can do all the right things for security, but nevertheless fall victim to attacks because of vulnerabilities of which nobody in the white hat community is aware. Clearly, the bad guys have the upper hand. All we really can do is to do the best we can and then hope.

Categories: Uncategorized Tags:

Infosec Cutbacks in the SMB Arena

McAfee recently conducted a information security survey of 100 small and medium-sized companies in nine countries. Seventy-one percent of the respondents said that they believed that a data extrusion incident could result in their companies going out of business, yet three-quarters of those surveyed reported their that information security budgets had been reduced or frozen. Twenty percent of the respondents said that their companies had suffered a data extrusion incident within the last year and that the average cost of security incidents was $41,000. Finally, two-thirds of the survey participants reported that they devoted fewer than three hours each week to information security-related activity. Read more…

Categories: Uncategorized Tags:

War Whatever

Last week a few managers within Emagined Security, myself included, were discussing possible new consulting services that our company might offer. Although we currently offer wardriving services, I suggested that we also move into the area of warchalking. Then our CEO, David Sockol, did a little Googling and came up with all kinds of wireless war—- terms. Let’s take a look at them:
The most general war—- related term is netstumbling, which means “running into” a wireless network by receiving signals from the network, generally by using either a laptop that has a wireless network card or a Personal Digital Assistant (PDA). .However, a Pringle’s can and a metal coat hanger have also been used as antennas in netstumbling many times, and they work remarkably well. To the best of my knowledge, Howard Fuchs of Germany still holds the record for non-government spy agency-related netstumbling with a distance of 75 miles! (Howard was arrested by the German police afterwards, but then charges against him were dropped later.) Ministumbling is the same as netstumbling, except that in the latter only very casual, non-systematic attempts to discover wireless networks are made. Read more…

Categories: Uncategorized Tags: