My Blackhat DC Paper, Slides, and Video are available

Posted by Tom Cross on February 08, 2010 at 1:26 PM EST.

Blackhat has posted my paper and presentation slides, as well as audio and video recordings of my talk on security weaknesses in Lawful Intercept, which I gave last week at Blackhat DC 2010. Click here to check them out, and please let me know if you have any observations or feedback on the research.

The Google Attacks

Posted by Tom Cross on January 15, 2010 at 2:18 PM EST.

There seems to be a great deal of confusion in the media about what vulnerabilities were used in the attacks reported by Google earlier this week. Some media reports attributed to iDefense indicate the use of an Adobe Acrobat vulnerability in the attacks. A SANS diary entry provides a detailed analysis of one of the samples. Later McAfee reported a new Internet Explorer vulnerability. McAfee stated that they saw no evidence of PDF based attacks, and Adobe later posted a blog entry stating that their software was not a vector.

I'm guessing that the confusion might be due to the fact that there is a wide range of sophisticated, targeted attacks going on all the time. I suspect that there have been attacks incorporating both vulnerabilities. Whether those attacks are a part of the same intelligence operation or different ones is really irrelevant. The fact is that networks need to be protected against both vulnerabilities.

For any of our customers concerned about either of these vectors (regardless of whether they are indeed related), we have obtained samples of the PDF attack mentioned by SANS and a sample of the page that serves the IE exploit mentioned by McAfee and we do indeed block both of them with blocking IPS signatures if we observe them in the clear on a network. Here is our alert on the PDF issue and our alert on the Microsoft issue.

The usual MO for these attacks involves spear phishing. Targets will receive an email that may appear to come from a reputable source with either a web link or an attachment that is relevant to that person. The people who send these emails have usually researched their targets well enough to know what sort of content they are likely to click on. For example, attacks a couple of years ago targeting Tibetan activists included an attachment which professed to have information about the political situation in Tibet. The attachment may be a PDF or office document that exploits a vulnerability in the respective software, but it may be as simple as an executable file or a CHM file. (It is not safe to open CHM files from untrusted sources as they are essentially like executable files, but many people don't know that.) Once the files are opened, malware is installed on the victim's machine - and the victim is placed under surveillance.

These kinds of attacks have been going on for many years. Although security software such as IPS and Anti-Virus can be helpful in mitigating these attacks, user education also needs to play a role. As Google's announcement has focused people's attention on the matter, now is the time to sit down with your users and talk to them about suspicious email attachments, files, and web links. This is particularly true for executives and people who work with sensitive intellectual property. We've seen strong internal education programs play a role in catching these attacks before they are successful.

It may also make sense to architect air gaps between extremely sensitive information systems and the global Internet. Back in 2006 when the Bureau of Industry and Security (BIS) was attacked by China then Undersecretary of Commerce Mark Foulon wrote: "It has become clear that Internet access in itself is a vulnerability that we cannot mitigate." As someone who spends most of his waking hours trying to make it possible for people to use the Internet safely, those words were frustrating to read, but it would be naive to dismiss them out of hand. Protecting your network against a foreign intelligence agency is a difficult challenge to say the least. Sometimes absolute assurances are necessary. BIS created an air gap between computers they were using for critical business and computers they were using for Internet access. In some cases, that might be a prudent choice, depending on the costs involved, the nature of the information you are working with, and the sophistication of the threats you are facing.

My talk at the upcoming Blackhat DC conference

Posted by Tom Cross on January 14, 2010 at 6:59 PM EST.

I'm giving a talk at Blackhat DC the first week of February and I thought I’d explain a bit about what I plan to cover. Many network equipment manufacturers have incorporated interfaces into Internet routers and switches that are designed to facilitate legally authorized wiretapping by law enforcement. If these interfaces are not well-protected there is a risk that they could be hijacked by third parties and used to perform surveillance without authorization. Because of this risk, the security of lawful intercept systems is of obvious public interest.

Cisco has published the core architecture of its lawful intercept technology in an Internet Draft and a number of public configuration guides. This is good for two reasons. First, it enables the general public to see and understand how wiretapping is performed with Cisco routers. Second, it allows the security community to peer-review their approach to protecting this interface from attack.

That peer-review is the basic purpose of my Blackhat talk and the associated paper. I plan to review Cisco’s architecture for lawful intercept and explain the approach a bad guy would take to getting access without authorization. I’ll identify several aspects of the design and implementation of the Lawful Intercept (LI) and Simple Network Management Protocol Version 3 (SNMPv3) protocols that can be exploited to gain access to the interface, and provide recommendations for mitigating those vulnerabilities in design, implementation, and deployment. 
 
There is a lot of discussion going on right now in policy circles about different approaches for ensuring the security and resiliency of various kinds of critical infrastructures. The public certainly has an interest in knowing that systems like electronic voting machines and lawful intercept interfaces are properly protected. I think a consensus exists within the security community that one the best ways to improve security is through peer-review of architectures and implementations.

Cisco did the right thing when they decided to publish their architecture for lawful intercept so that we can study it and peer-review it. Although I identify some weaknesses in my talk, at the end of the day, we can have greater confidence in Cisco’s approach because it’s a known quantity and because it has had the benefit of analysis like this. There is a lot of technology out there that the public depends on that is more difficult to peer-review, and those shadows are where our greatest vulnerabilities lie.

A New Years Resolution - Find out how your corporate domain name is managed.

Posted by Tom Cross on December 18, 2009 at 5:02 PM EST.

As you've probably already heard, Twitter was defaced last night by a group calling itself the "Iranian Cyber Army." Although website defacements are usually performed by activists who have no official sponsorship, TechCrunch is reporting rumors that this group is actually part of the Government of Iran. Was this an act of Cyberwar? I have no idea, but I do think it ought to serve as a wakeup call for every organization out there with a domain name.

According to media reports the attack more or less worked as follows:

First, members of the "Iranian Cyber Army" obtained access to an email account associated with the person responsible for managing Twitter's domain names. Twitter pays Dyn, Inc to host the DNS records for their domains. The attackers used the automated password recovery feature on Dyn's website to reset the password on Twitter's account. Once the attackers got into Dyn's web interface, it was trivial for them to point Twitter's domain names at the IP addresses of their own website, where they hosted their defacement message.

This is not the first time that DNS management websites on the Internet have fallen prey to attackers. Last December the DNS for payment processor CheckFree.com was redirected to a malicious website in the Ukraine. In that case the attackers logged into CheckFree's account at Network Solutions using the correct username and password, which were likely obtained through a phishing attack. 

The vast majority of domain names are registered by individuals or small organizations who run websites that don't get much traffic. DNS registrars and DNS hosting companies are set up to serve this market by providing extremely inexpensive registrations with easy to use management interfaces protected by simple usernames and passwords. The number of organizations out there with valuable domain names that serve large audiences or are connected with important business processes represent a tiny market by comparison. All too often, these important domain names end up getting managed through the exact same infrastructures and processes that are designed to handle people's personal vanity domains, when in fact they have dramatically different (and more expensive) needs, particularly from a security standpoint.

So, I have a New Years resolution for CIOs and CSOs: When everyone gets back to the office in January, sit down and find out how your domain names are managed.

Where are your domain names registered? How much are you paying for it? (Is your brand really worth just $9.95 a year?)

Who has access to change your DNS registration? Are those people trusted?

How do you authenticate to make changes to your DNS registration? Is that authentication system adequate? (Are you using passwords or certificates?)

What is the access recovery process for your DNS registration in the event that you loose your access credential? Is that recovery process secure?

Have you locked out registrar transfers for your domain?

Is your DNS Whois contact information up to date?

Are you carefully monitoring the email addresses associated with the Whois contact information for your domain? (If not, you might loose your domain if someone complains about the accuracy of your Whois contact information or claims (even fraudulently) that you are infringing upon their trademarks.)

How are you hosting your DNS records?

If you are hosting your DNS with a third party, you need to ask all the access control questions that you asked about your DNS registrar - Who has access, how do they have access, and what is the recovery process...

If you are hosting your own DNS, how are you managing the security of your DNS servers?

What DNS records are you publishing? What process exists within your organization to create a new DNS record within your domain and how do old DNS records get expired? Are those processes connected with other business controls that need to be invoked whenever your organization publishes information on the Internet?

Hopefully, your organization has looked at these questions carefully and has mature processes, but the fact is that these issues are frequently overlooked, and represent a significant and widespread vulnerability on the Internet today.

Reflecting on NTLM Reflection

Posted by Takehiro Takahashi on December 17, 2009 at 2:51 PM EST.

Since late 2008, Microsoft has been releasing updates for ‘NTLM reflection attack’ which allows an attacker to use a victim's NTLM credentials in order to gain access to the victim's shared resources. These updates correct programs’ behavior to use Microsoft’s protection mechanism against the reflection attack. Here is a quick list of applications fixed in last 12 months:

After reviewing MS08-076, we spent some time auditing other applications that support the NTLM authentication protocol, and discovered Mozilla Firefox, Opera and Google Chrome were all vulnerable to the reflection attack. As of 12/17/09, all three vendors have already released updates for their products, and a security advisory has been published from Mozilla.

Unfortunately, none of these patches, as pointed out by H D Moore, protects users from reflection attacks when multiple victims are involved (i.e. attacker’s server relays VictimA’s credential to VictimB). This happens because the scope Microsoft’s NTLM reflection attack protection is local only, and the NTLM protocol provides no provision for protecting users from the reflection attack. One can imagine any Active Directory based networks are seriously affected by this issue.

In this article we discuss the internals of NTLM authentication in detail in order to understand the full extent of the problem. For readers’ convenience, we refer to two types of reflection attacks as two-party reflection attack and multi-host reflection attack. In a two-party reflection attack, attacker uses a stolen credential against the same victim, where as in a multi-host reflection attack, the credential is forwarded to a host other than the original victim. Last but not least, IBM ISS customers have been protected against both types of reflection attack by NTLM_MultiProto_Reflection since April 14, 2009.

First, let us briefly provide a high-level overview of the NTLM protocol. NTLM is actually a suite of security protocols that offers authenticity, integrity, and confidentiality to users. While Kerberos has replaced NTLM as the default authentication protocol in an Active Directory based single sign-on scheme, NTLM is still widely used in many scenarios where a Kerberos server (Domain controller) is unavailable or unreachable (i.e. remote web authentication). Due to a number of security updates in the past, the following protocols, ordered in increasing security, exist in NTLM: Authentication: LM (LAN Manager), NTLM, and NTLMv2. Integrity and Confidentiality: NTLM Session Security and NTLM2 Session Security.  Regardless of the protocol used, NTLM authentication always establishes a session using three messages as illustrated in Figure 1. These messages are often referred to as Type 1 (negotiation), Type 2 (challenge), and Type 3 (authentication) messages. By default, Windows Vista/7 uses NTLMv2 authentication which achieves a higher level of security by computing an authentication token using HMAC-MD5 with both user and server challenge. Other versions of Windows such as 2000, XP, and 2003 use NTLM authentication which only uses server challenge. The protocol selection depends on Group Policy, or a registry key

HKLM\SYSTEM\CurrentControlSet\Control\LsaLmcompatibilityLevel) by both the server and client. Although NTLMv2 successfully protects Windows hosts from password brute-forcing with a rainbow table, it gives no protection from a reflection attack.

On the other hand, NTLM Session Security and NTLM2 Session Security uses a session key established during the authentication phase in order to provide data encryption and integrity check. Unfortunately, this additional security feature makes no contribution to preventing a reflection attack.

Let us also mention another popular authentication protocol, Kerberos. Kerberos is the most preferred choice for authentication due to its higher security and efficiency, and is used in all domain services by default. Since both client and server must be authenticated to a KDC (Active Directory server in most cases) in order to retrieve a session key, a reflection attack is not possible. The downside is that both parties must have access to the Kerberos server which is less likely for external users trying to authenticate to services such as Exchange OWA.  Microsoft also implements Negotiate which is a wrapping protocol for Kerberos and NTLM. It lets communicating parties use Kerberos by default, while allowing them to fall back to NTLM whenever necessary.  This protocol is recommended over NTLM by Microsoft.

Now, we turn to the internals of the NTLM authentication. A client implementing NTLM calls the following Win32 API repeatedly in order to generate NTLM blobs until the authentication finishes:

SECURITY_STATUS SEC_Entry InitializeSecurityContext(
 __in_opt     PCredHandle phCredential,
 __in_opt     PCtxtHandle phContext,
 __in_opt     SEC_CHAR *pszTargetName,
 __in         ULONG fContextReq,
 __in         ULONG Reserved1,
 __in         ULONG TargetDataRep,
 __in_opt     PSecBufferDesc pInput,
 __in         ULONG Reserved2,
 __inout_opt  PCtxtHandle phNewContext,
 __inout_opt  PSecBufferDesc pOutput,
 __out        PULONG pfContextAttr,
 __out_opt    PTimeStamp ptsExpiry
);

InitializeSecurityContext, implemented in secur32.dll, takes a server message as a user input (pInput), makes several Local Procedure Calls (LPC) to the Local Security Authority Subsystem Service (LSASS) to process authentication, and returns a client blob in pOutput. LSASS, whose executable name is known as lsass.exe, sets up a public LPC port (\LsaAuthenticationPort) and takes the first DWORD of LPC message as an index for undocumented functions. LpcAcquireCreds, LpcGetUserName, LpcLogonSessionData, and LpcLookupAccountName are examples of these functions. The LSASS is responsible for a variety of tasks such as retrieving/verifying users' credentials, keeping track of logon sessions, or digesting/generating authentication blobs. It also implements a local reflection attack protection by checking an incoming NTLM challenge against a splay-tree full of active challenges currently in use. If the LSASS sees a duplicate challenge, it returns an error. In other words, any client application which implements NTLM should use InitializeSecurityContext or the application is vulnerable to the reflection attack. Also, one must make sure that the third argument pszTargetName points to a proper service principal name (SPN) used to uniquely identify an instance of a service - the reflection attack protection is not enforced otherwise. For example, Opera was using a null pszTargetName when we first audited. Finally, these active challenges are not shared among network hosts, explaining why token forwarding in an Active Directory based network works.

The first call to InitializeSecurityContext produces a blob used in message 1 of Figure 1. The message merely declares the host/domain name of the client. The subsequent reply from the server has a blob which contains the server challenge, and is passed to the second call to InitializeSecurityContext. The LSASS validates the incoming messsage, extracts the challenge message, and generates a challenge response seen in message 5 of figure 1. The type of NTLM challenge response generated is based on GroupPolicy.

On the other hand, a server implementing NTLM calls the following Win32 API repeatedly in order to process user authentication:
SECURITY_STATUS SEC_Entry AcceptSecurityContext(
 __in     PCredHandle phCredential,
 __inout  PCtxtHandle phContext,
 __in     PSecBufferDesc pInput,
 __in     ULONG fContextReq,
 __in     ULONG TargetDataRep,
 __inout  PCtxtHandle phNewContext,
 __inout  PSecBufferDesc pOutput,
 __out    PULONG pfContextAttr,
 __out    PTimeStamp ptsTimeStamp
);

The function works very similar to InitializeSecurityContext - it takes a client message as user input (pInput), makes several LPCs to the LSASS, and returns a server blob in pOutput. The server challenge is checked against an active challenge table once the server receives the challenge response.

In conclusion, we have brought the following points to readers’ attention:
1) The two-party NTLM reflection attack can be prevented by using the API correctly
2) The multi-party NTLM reflection attack is still possible against any products

As of late 2009, NTLM remains a popular authentication protocol for many users, and the multi-party reflection attack problem continues to exist as a result. It is likely that the protocol needs another revision such as implementing a mechanism to verify the origin of NTLM messages (i.e. include an IP address of a sender hashed with a session key) in order to fully address the issue. Nevertheless, we would like to reiterate that IBM ISS customers have been protected from both types of reflection attack since April 14, 2009.

References
[1] Squirtle http://code.google.com/p/squirtle/
[2] Metasploit http://www.metasploit.com/
[3] http://blog.metasploit.com/2008/11/ms08-067-metasploit-and-smb-relay.html