by Rik Farrow
While I was explaining how attackers tunnel through firewalls, a student asked me about the use of HTTP. Didn't an attacker's ability to rely on HTTP being free to pass through a firewall mean that even a firewall that was controlling passage of traffic out of an internal network could not stop the attacker?
He was right. Firewalls can at best enforce that the protocol used is really HTTP, and perhaps block accesses to sites on a blacklist. But if an attacker decides to use HTTP for a back connection that runs a command shell, there is nothing to stop that attack from succeeding.
That train of thought slid quickly into thinking about Web Services. While Web Services have been designed to provide programmatic access to Web applications, they also open a path for client applications to receive and execute remote code. Web Services have quickly become the next great frontier in network programming, and has been intended from the start to tunnel through firewalls using HTTP and SOAP, the Simple Object Access Protocol.
The specifications for Web Services in existence today include support for authorization and authentication. But, the use of any security mechanism is merely optional. We are repeating the same mistakes we have made in the past by accepting yet another protocol where security is considered a hindrance rather than an essential component. And Microsoft with its .NET technology eagerly embraces Web Services.
When it comes to running a command shell on a system protected by a firewall, tunnels have become the exploiters' tool of choice. I described a tunnel that makes outgoing connections while someone is configuring Open Source Software back in my September 2002 column. Various Windows trojans, like SubSeven and Back Orifice 2K, also create outbound control connections. As a technique for providing remote control on a system protected by a firewall, tunnels have become de rigour.
SOAP began life in 1999 as a replacement for Microsoft's DCOM, itself a framework for remote code execution layered on top of COM. In an interview with Dr. Dobb's Journal (see Resources), Don Box explains that one of the problems with DCOM is that it could not work through firewalls. Then, as now, most firewall administrators block both outgoing and incoming access to the ports used by Microsoft's RPC (Remote Procedure Call) services, 137 UDP and TCP. SOAP uses HTTP instead, a protocol that slips freely out through most firewalls because it's primary use is not remote procedure calls, but requesting and receiving text and graphics.
HTTP does support remote code execution. Everytime you use a URI that specifies a script or program, you are invoking remote code. The arguments to this remote code get passed either within the URI itself (using HTTP GET) or within the body of the request (an HTTP POST). The results get returned to your Web browser usually as HTML, although Web browsers actually use plug-ins to process many binary formats, with audio and flash being one of the most common. Some Internet activists are supporting REST, essentially HTTP as it now exists, rather than see SOAP become widespread. But the barn doors have stood open for years now, and the horses are running loose.
And the current draft of the SOAP version 1.2 specification does not even mention the word 'security'.
SOAP can be viewed as a necessary evil. Box mentions that getting a new Internet protocol accepted is very difficult, and that was why HTTP was chosen. SOAP v1.2 also describes using SMTP as the transport protocol for SOAP. But SOAP opens up the Internet to applications which could be done using HTTP, although very inelegantly.
For example, Google has provided a SOAP API for performing searches. The SOAP API presents an interoperable interface that can be used programmatically, rather than through the medium of browser requests and HTTP server responses. A programmer could mimic a browser request easily enough, and then convert the response into something that could be mangled into the appropriate format, but SOAP means that the response already gets presented in a standard format.
SOAP specifies XML for formating requests and responses. XML has the advantage of being able to described any type of data, while perserving data structures that are part and parcel of objects. The XML envelope includes an identifier for the remote method that has been called, and the XML body contains the calling arguments or the results.
Before SOAP, firewalls could parse HTTP headers, and make access control decisions based on the contents of those headers. With SOAP, the access control decision will based not on the header contents, but upon parsing a much more complex XML schema that has become the body of an HTTP request or response. And XML is anything but simple. Someday in the not too distant future, a new security product niche will spring up for parsing XML in SOAP messages, similar to the way that email gets scanned for viruses and trojans today. The XML scanner will be looking for known patterns for malicious activity buried within SOAP requests or responses.
One could certainly argue that HTTP itself includes no provisions for security. SSL, created as an afterthought by Netscape, provides an encrypted tunnel for HTTP traffic that also serves to identify the server, and potentially the client. In a similar manner, IBM, Microsoft, and Verisign have proposed a method to support authentication and confidentiality of data within Web Services. Again, this is SSL for Web Services (WS) over SOAP. And like SSL, WS Security focuses upon secure transport of data. WS Security also supports the inclusion of certificates or tokens than can be used for authentication and authorization in a portable fashion if the application server handles it.
Programmers who write code for Web servers are responsible for the security of that code. In large part, this means that programmers must check any input received from a remote, potentially hostile user so that it completely matches what is expected and does not include metacharacters that might trick an interpreter or a buffer overflow that can exploit a program. Programmers working on backends to SOAP face these same issues as well, plus some new, more serious, security issues.
Besides opening up Web Services to a programmatic interface using RPC, SOAP also supports the use of mobile code. Imagine that instead of slogging through six pages to select a flight, confirm and pay for it, you could run an application that would guide you through the flight selection process using a single window? Or download a code module into your mobile phone that allowed you to make a directory search, then dial the number you selected? Or, that would make your mobile phone into a real extension of your desktop, rather than a sometimes connected accessory? These are some of the promises of mobile code that both Java and .NET address.
Java started out as a language and infrastructure for mobile code. As such, Java was designed to support the execution of code from untrusted sources from its very beginning. All code exists in an intermediate format, bytecode, that must be verified before it can be executed. Java bytecode is strongly typed and does not support pointers, which mandates strict control over access to data. Java bytecode runs within a virtual machine, and accesses to the underlying operating system, including resources such as files and network sockets, are controlled by policy. Java classes support not only signed code, but also encryption, authentication, and authorization.
.NET is Microsoft's new development framework. It encapsulates everything that Microsoft developers have done in the past, and extends the development environment to support Web Services. .NET includes its own support for mobile code in the form of the CLR (Common Language Runtime), similar to the Java virtual machine, and MSIL, the MS Intermediate Language instead of Java bytecode. Unlike Java bytecode, MSIL support goes well beyond C#, Microsoft's Java-like language, and embraces Visual Basic and C++ as well. Because neither Visual Basic or C++ are strongly typed, MSIL cannot provide the same guarantees for access control found in Java. Also, while Java prevents buffer overflows, catching buffer overflows that clobber the stack is a new compiler option in Visual Studio C++ that programmers must decide to use, losing some performance as a tradeoff.
In both Java and .NET, security also relies on the programmer who writes the code and the policy in force where the code will be run. Java provides a much stricter environment, where a class may query the local policy and see if a resource may be accessed. .NET includes a mechanism where a program container may request a particular policy, based on the source of the code, the code signer, and if the local system's policy includes that requested access, the access will be granted. .NET also includes specific support for roles, that is, access granted based on some form of login, so that a user would be allowed to access his or her own files, but not another user's files. The JAAS (Java Authentication and Authorization Service) supports concepts similar to .NET roles.
Both Java and .NET permit code to be serialized, that is, converted into a bytestream, transmitted using SOAP, and executed on a system that requested it. While digitally signing code is supposed to make this practice safer, Microsoft announced a buffer overflow in an ActiveX control November 2002 that had been signed by Microsoft, one that an attacker could trick a user of Internet Explorer or Outlook into downloading and executing (see MS-02-065). .NET MSIL does provide more protection than ActiveX, but will it really work?
Firewalls came into being as a method for protecting insecure or buggy network services from remote access. By dividing a network into an "inside" and an "outside", network administrators could defend internal servers from external attacks. Public servers remained exposed to attacks. And, over time, internal network clients, Web browsers as well as email clients that utilize the HTML rendering engine of Internet Explorer, also became the targets of attacks.
SOAP leaves some things unchanged. Your firewall will permit access to public Web servers that provide Web Services, and block access to internal servers. And internal clients will still be permitted to visit Web servers and read email. But, the paradigm changes here, as the emphasis changes from execution of remote methods on remote servers to include the execution of remote code on local clients. Execution of remote code on Internet Explorer is already well known as a very successful attack vector. Will the security features of .NET, or Java, mitigate this threat?
If programmers write secure code, and the policy that controls the access of that code is restrictive enough, then the future of SOAP and Web Services is also secure. Past experience tells us that virtual machines have had bugs, mobile code has bugs, and security policies have not been restrictive enough. Ask most any security consultant if he or she enables Java in their Web browser today, and the answer will be no. And .NET has weaker security than Java.
Web Services will not mean that you throw away your firewall. Your firewall will still be there, still blocking traffic--it's just that a lot more of that permitted traffic will be dangerous.
Dr. Dobb's interview with Don Box, one of the developers of SOAP: http://technetcast.ddj.com/tnc_play_stream.html?stream_id=416
Article that explains both the need for SOAP and how it works: http://www.xml.com/pub/a/2001/10/17/slippery-soap.html
Primer on SOAP version 1.2: http://www.w3.org/TR/2002/WD-soap12-part0-20020626/
An article about REST vs UDDI, SOAP, etc: http://www.xml.com/pub/a/2002/02/06/rest.html
Example of a remotely executable ActiveX control with a problem: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bull etin/MS02-065.asp
Web Security Services paper, co-authored by IBM, Microsoft and Verisign, considers the confidentiality and authenticity of single messages: http://www-106.ibm.com/developerworks/webservices/library/ws-secure/
IBM article about using Java 2 JAAS and an extension to it: http://www-106.ibm.com/developerworks/security/library/j-jaas/index.html?dwzone=security