Decryption of Wire-level Network Protocols for Forensic Inspection

Document Sample
Decryption of Wire-level Network Protocols for Forensic Inspection Powered By Docstoc
					     Decryption of Wire-level Network Protocols for Forensic
                           Inspection
                                                       Barry Irwin
                                              Computer Science Department
                                           Rhodes University, Grahamstown, 6140
                                                    B.Irwin@ru.ac.za


                                                                     Provision of Communication-related Information (RICPIC)
   Abstract—With the increased use of encrypted                      [5] Acts govern access to traffic, and the related use of
transport protocols, the problem of debugging and                    cryptography. Hence in order to comply wholly with these
monitoring the contents of these protocols has increased             acts, newer tools and methods are required.
in complexity. This work proposes the development of a                 Honey net data analysis is also an important part of
unified means of access to the plaintext, through the use            Forensics, and honey-pot operation with operators needing
of privileged access to the encryption keys, based on the            to be able to monitor communications quite clearly –
assumption that an administrator has legitimate access               something easy in the days when telnet was prevalent, but
to one side of a communication, and is thereby able to               near impossible with technologies like SSH. The ability to
gain access to the encryption tokens.                                be able to watch intruders without them being aware is of
                                                                     paramount importance. Stoll describes this ability to have
  Index Terms—Computer                Forensics,     Honeynets,      been pivotal in the investigations carried out (using
Encryption                                                           hardware intercepts rather than software systems as
                                                                     proposed in this paper) in the Cuckoo’s Egg [6].
                                                                       B. Current Solutions
                    I. INTRODUCTION
                                                                        Current operation requires either in-kernel modules such
T    HE increase in the use of cryptographic protocols such
     as Secure Shell (SSH) [1] and IPSEC [2] has lead to a
problem with traditional forensic and monitoring methods.
                                                                     as Sebek [7] or the termination of the encrypted tunnel on a
                                                                     front-end device (HTTPS and IPSEC) in order to gain
                                                                     access to plain-text traffic. This is not always suitable as it
Intrusion detection systems rely on being able to access the
                                                                     provides a compromise of the end-to-end security expected
data payloads of packets in transit in order to be able to
                                                                     by users of a service. It may also not be desirable to have
ascertain whether the payload is malicious. In addition
                                                                     plaintext traffic flowing within a network DMZ.
Systems Administrators have traditionally also made
                                                                        Tcpdump currently offers a method for decapsulating, and
extensive use of tools such as tcpdump for the monitoring
                                                                     decrypting IPSEC ESP (Encapsulated Security Payload) [8]
and debugging of network connections. While the existing
                                                                     traffic, through the provision of the encipherment key used
tools are ale to still monitor the flow of packets they are not
                                                                     by an administrator. Recovering the key used differs
able to perform any content inspection due to the encrypted
                                                                     depending on the operating system. Currently there are no
nature of the payload.
                                                                     solutions available for recovering traffic from SSH and TLS
  A. Need                                                            sessions without modification to the servers. There are a
   The increased prevalence of Virtual Private Networks              number of commercial products available which offer the
(VPN) connectivity and for non-VPN traffic the use of                ability to decrypt SSL encapsulated HTTP traffic through
encrypted transports such as SSH and Secure Sockets Layer            access to the private keys.
(SSL) have rendered many traditional network debugging
and monitoring tools useless due to the encryption used. All                        II. THE PROPOSED SOLUTION
these protocols have been engineered to be resistant to                 The proposed solution is to provide a means for reversing
attack and provide strong encryption and undergone public            the encryption on the protocols. This is to be achieved due
scrutiny. Legitimate users need access to the plaintext as           to the fact that one side of the network connection is
part of normal debugging and security monitoring                     assumed to be ‘friendly’ and terminated on equipment
procedures [3].                                                      owned by the organization. As such the administrator is able
   Access to this information may also be required by Law            to gain access to critical elements used in the encryption
enforcement, either for real-time wiretaps or for post               process. Currently three primary protocols have been
processing of captured data. In South Africa the Electronic          identified for analysis.
Communications and Transactions (ECT) [4] and
                                                                       A. IPSEC
Regulation of Interception of Communications and
                                                                       A tool needs to provide a means for extracting the
  This research is funded by a grant from the Rhodes University      specific encryption key and cryptographic algorithm for an
JRC, and the Center of Excellence in Distributed Multimedia in the   IPSEC traffic flow (SPI value) used for ESP traffic [8].
Rhodes University Department of Computer Science
This list needs to be periodically updated as keys are re-        administrators, honey-pot operators and forensic
negotiated. These keys can be used to decrypt the packet          investigators to access encrypted protocols in simple manner
payloads using standard symmetric cryptography. The               for further analysis and monitoring. A the same time these
process should be automated and as transparent as possible        tools should be reliant on privileged access to a system, and
to the user. The ideal is that the solution will be able to       be relatively undetectable – particularly in the case of
produce a libpcap compatible output stream in order that          modified servers so as not to alert potential intruders to the
any monitoring tools or Intrusion Detection systems be able       fact they are being monitored.
to process the traffic as per normal, with the highest level of
transparency possible. Currently session keys can only be                                 REFERENCES
recovered for one open source IPSEC stack                         [1] T Ylonen. “SSH---Secure login connections over the
implementations – the KAME stack for the BSD family of                 Internet”. In Proceedings of the Sixth USENIX
operating systems it is envisaged that the Free/SWAN stack             Security Symposium, pages 37-42, July 1996.
for Linux should be modifiable in a similar manner,               [2] S. Kent, R. Atkinson (1998, November) “Security
                                                                       Architecture for the Internet Protocol” IETF RFC 2401
  B. SSH
                                                                  [3] V. Corey, C. Peterman, S. Shearin, M. S. Greenberg
   In order to be compatible with both SSH version 1 [1]               and J. Van Bokkelen (2002 December) "Network
and version 2 [9] protocols, two options are available, the            Forensics Analysis". IEEE INTERNET COMPUTING
first is a man in the middle attack which could be trivially           pages 60-66
implemented using tools such as Dug Song’s dsniff [10]            [4] South African Government (2002)                  Electronic
package. However this can potentially be quite easily                  Communications and Transactions Act, No. 25 of 2002
detected, particularly in the case of a honey net where an        [5] South African Government (2002) Regulation of
intruder’s traffic needs to be monitored. The second option            Interception of Communications and Provision of
is to modify the SSH server in order to provide the                    Communication-related Information Act (No. 70 of
ephemeral symmetric encryption key that is agreed upon                 2002)
during the negotiation part of the SSH algorithm. This            [6] C. Stoll (1989) The Cuckoo's Egg. Pocket Books.
method also allows for the recovery of the key when SSH           [7] Honey net Project (2003, November) "Know Your
version 2 is used as a Diffie-Hellman exchange is used,                Enemy: Sebek - A kernel based data capture tool".
whereby the session key is not transmitted over the wire as            Available: http://www.honeynet.org/papers/sebek.pdf
in version 1 [11]. This is intended to either be logged to file   [8] S. Kent, R. Atkinson (1998, November) “IP
or a secure device, or used in real-time for the monitoring of         Encapsulating Security Payload (ESP)” IETF RFC
                                                                       2406
traffic flowing over the SSH connection. Sandstorm
                                                                  [9] T. Ylonen and C. Lonvick, Ed. (2004, June)
Communications’ NetIntercept product [12] has similar
                                                                       "SSH Protocol Architecture" IETF Draft. Available:
functionality to that proposed above implemented, but the              http://www.ietf.org/internet-drafts/draft-ietf-secsh-
details have not been disclosed                                        architecture-16.txt
  C. SSL                                                          [10] D. Song (2002) Dsniff Toolkit. Available:
                                                                       http://www.monkey.org/˜dugsong/dsniff.
   A similar approach to that for the SSH protocol will be
                                                                  [11] M Friedl, N Provos and W A. Simpson (2003, July)
implemented, where the session key can be recovered
                                                                       “Diffie-Hellman Group Exchange for the SSH
through the decryption of the session initiation traffic using
                                                                       Transport Layer Protocol” IETF Draft. Available:
a copy of the web server’s private key [13]. The session               http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-
key can then be used to decrypt the actual flow to produce             group-exchange-04.txt
plaintext. One potential problem is that SSL sessions are         [12] Sandstorm Enterprises “NetIntercept 2.0 White Paper”
generally relatively short-lived in nature in comparison to            Available:
SSH and IPSEC sessions which can typically last for hours.             http://www.sandstorm.net/downloads/netintercept/ni-2-
  D. OTHER PROTOCOLS                                                   0-whitepaper.pdf
                                                                  [13] E. Rescorla (2000, May) "HTTP Over TLS" IETF RFC
A number of other protocols such as SMTP and IMAP make                 2818
use of encryption through implementation of the TLS               [14] P. Hoffman (2002, February) "SMTP Service Extension
protocol [14,15.16]. While these have not currently been               for Secure SMTP over Transport Layer Security" IETF
investigated, they have not been discounted, and it is hoped           RFC 3207
to provide a generic means of decrypting these protocols in       [15] C. Newman (1999, June) "Using TLS with IMAP,
order for authorized parties to be able to analyze the traffic         POP3 and ACAP" IETF RFC 2595
flows in plaintext.                                               [16] S. Blake-Wilson, M. Nystrom, D. Hopwood, J.
                                                                       Mikkelsen and T. Wright (2003, June) "Transport
                      III. CONCLUSION                                  Layer Security (TLS) Extensions" IETF RFC 3546
   While this work is currently at a very early stage of
development, it is hoped that an automated method of              Barry Irwin obtained his MSc in Computer Science from
extracting relevant data for analysis can be developed. The       Rhodes University in 2001. He spent three years working as
perceived outcomes are a set of tools, and patched for the        head of Networks and Security for a multinational wireless
modification of system servers (where need be) to allow           operator before returning to Rhodes. He is currently
Intrusion Detection Systems, network and system                   reading for his Phd and has obtained CISSP certification.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:13
posted:2/18/2011
language:English
pages:2