[Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect Paine Bone

Thu Aug 12 02:24:38 GMT 2004

Source of trace
The trace in question is from a Windows 2000 server running IIS 5.0 and
has current patches as of this printing.  The server is running SSL and
resides in my DMZ.  This server has ports 80 and 443 open to the
Internet through the firewall.

Detect was generated by

The trace in question is actually an error in the Windows System Log
(the error is as it appears in my log with the exception of the computer
name which has been sanitized):

Event Type:   Error

Event Source: Schannel

Event Category:      None

Event ID:     36874

Date:         7/17/2004

Time:         8:14:01 AM

User:         N/A

Computer:     WEBSERVER

Description:

An SSL connection request was received from a remote client application,
but none of the cipher suites supported by the client application are
supported by the server. The SSL connection request has failed.

There were 24 instances of this error within a 5 day period.  The
majority of the events happened on the last 4 days with only 1 event
happening on the first day.  A search of my web logs for these dates and
times revealed no unusual traffic and no traffic at all during some of
the instances of the error.  All of the errors are identical in my
System Log.  

Probability the source address was spoofed

Unfortunately, I do not have the IP of the offending host.  Everything
must be inferred from the System Log and the data available on the web.
One thing I took away from the SANS Conference was that inference is a
normal part of Intrusion Detection.  I do not know if this came from a
spoofed address based on the information I have.

Description of attack

This particular exploit takes advantage of a flaw in the Microsoft
Private Communication Technology (PCT).  In an unpatched system,
Microsoft PCT fails to properly validate message inputs.  This
vulnerability may allow a remote attacker to compromise the affected
machine.  This vulnerability only exists in Microsoft web servers with
Secure Sockets Layer (SSL) enabled according to US-CERT.

Microsoft refers it's customers to http://cve.mitre.org
<http://cve.mitre.org/>  for more information about this vulnerability.
Microsoft also refers to this as an exploit that will allow an attacker
to remotely execute code.  Microsoft's Tech Net bulletin gave me pause
with the following statement regarding this vulnerability: "A buffer
overrun vulnerability exists in the Private Communications Transport
(PCT) protocol, which is part of the Microsoft Secure Sockets Layer
(SSL) library. Only systems that have SSL enabled, and in some cases
Windows 2000 domain controllers, are vulnerable. An attacker who
successfully exploited this vulnerability could take complete control of
an affected system."

PCT was created by Microsoft and Visa International as an alternative to
SSL 2.0.  With the complete dominance of SSL 3.0, PCT is no longer
needed and is disabled by default on Windows 2003.  However, PCT is
enabled on any NT 4 or Windows 2000 machine running SSL.  An item of
concern to me in the Microsoft bulletin is the portion claiming that
some Windows 2000 domain controllers are vulnerable.

Attack mechanism

The attack mechanism in this case is a crafted request for the target
server running SSL.  Someone must actively craft a packet to attempt
this attack.  I could find no evidence of any tools or utilities
designed to exploit the PCT vulnerability.  I tend to think this attack
was automated because I cannot imagine a live person attempting to hack
the same machine this many times once it is clear that the vulnerability
is not going to work.

Correlations

I used information on Microsoft Technet
(http://www.microsoft.com/technet) to find Microsoft Security Bulletin
MS04-011 related to this vulnerability.  Information on this exploit is
also available on US-CERT (http://kb.cert.org/vuls/id/586540) and is
listed as Vulnerability Note VU#586540.  This exploit is a candidate for
the CVE (http://cve.mitre.org <http://cve.mitre.org/> ) and is listed as
CAN-2003-0719.

Evidence of active targeting

This attack happened repeatedly over a 5 day period.  The exploit that
was attempted can only be run on IIS servers running SSL.  I believe
this attacker (automated or human) found a machine that met the criteria
for this vulnerability and they were probing to find out if the proper
patches had been applied.

Severity

Severity is calculated using the formula below.  Values are placed on
each item with a scale of 1(lowest) to 5(highest):

            (Target's Criticality + Attack Lethality) - (System defense
+ Network defense)

Criticality

This is an attack on production servers that run SSL.  SSL tends to be
installed on some of my more important web servers.  I am very concerned
about this activity.

4

Lethality

Happily, this machine was patched at the time of the attacks.  This was
not a problem on my web server, but it is something I will be looking
out for in the future.

2

System

The system is patched against this attack

1

Network

The network is properly configured to allow traffic for port 433 through
to this machine.  However, this traffic will be more closely watched in
the future

2

( 4 + 2 ) - ( 1 + 2 ) = Severity of 3

Defensive recommendation

Security Focus recommends installing Microsoft Windows 2000 Service Pack
4 (SP4) to eliminate the vulnerability on Windows 2000 web servers.  A
quick check of all web servers on my network confirms that SP4 has been
deployed to all web servers in production and development.

Fortunately this server is patched for the vulnerability and was not at
risk for this exploit.  I was unable to find any other log of these
events on my network.  I am guessing that the traffic sent to the server
was not something my web server interpreted as loggable traffic.  My
firewall was not logging traffic to this host during the time of this
error.  Also, I did not have a HIDS installed on this system at the time
of the attack.  This left me totally vulnerable to this attack if my
Windows machines had not been patched and if we were not checking our
logs on a regular basis.  The addition of a HIDS to this box is in the
near future so that we can catch this type of behavior that does not
show up in our regular logs.

PCT can be manually disabled through a registry hack.  It appears that
the Microsoft Security Bulletin has been updated a couple of times to
address issues with later patches.  Rather than hard code the
instructions from Microsoft into this paper, I am going to provide the
URL in case they make more updates in the future.  If you would like to
disable PCT, please see the information at:
http://www.microsoft.com/security/incident/pctdisable.mspx 

Another (albeit more drastic) way to defend against this attack is to
install UNIX web servers.  This solution would also defend against Nimda
and numerous other vulnerabilities specific to Microsoft.

Multiple Choice Test Question

The default Microsoft Windows services on a web server should be

A)    Enabled at all times in case you need them

B)     Turned off unless they are explicitly needed for the service you
are providing.

C)    Turned on or off based on requests from client machines

D)    There is no need to use Windows services on a web server.

The answer is B. Services should be turned off unless they are needed
for the service you are providing.  Having services that you don't need
(such as PCT) running in the background may give attackers more avenues
to explore for gaining access to your machine.

References

Roberts, Paul, "Microsoft Hole Spawns Real Attacks, False Alarm"
InfoWorld, April 2004

URL:
http://www.infoworld.com/article/04/04/28/HNmsholespawnsattacks_1.html

Sourcefire Advisories, April 21, 2004

URL: http://www.sourcefire.com/advisories/sa042104.html 

US-CERT, Vulnerability Note VU#586540

URL: http://www.kb.cert.org/vuls/id/586540

Microsoft TechNet, Microsoft Security Bulletin MS04-011

URL: http://www.microsoft.com/technet/security/bulletin/ms04-011.mspx