Until recently, IT directors didn't have to give much thought to application security or intrusion prevention software and services. Viruses originated outside the LAN, and since Internet Explorer, Outlook, Adobe Acrobat Reader or AOL Instant Messenger lived behind a firewall, it was easy to jump to the conclusion that they were clean. Internal threats were pretty much limited to disgruntled employees and social engineers. This meant that application security policies were at the bottom of a long to-do list.
Like everything else in the world of Internet security, that has changed. Prior to 2003, attacks against client-side vulnerabilities were rare: a few thousand among the 50 million alerts that SecureWorks analysts process every month. But by the end of 2003 the client-side activity had spiked to two million and has not abated. IT directors today realize that a firewall is not a substitute for effective intrusion prevention software and services to provide adequate application security.
There are three reasons for the spike in client-side attacks. Traditionally, network defenses have been focused on protecting the server rather than application security. Not to be thwarted, hackers simply found less-protected routes into the LAN — routes that would require intrusion prevention software and services to protect, which the average corporate security practices don't yet address. Second, exploiting client-side vulnerabilities is not at all difficult. Third is the pervasive, but mistaken, belief that a stateful firewall can prevent these attacks.
How hackers exploit client-side applications
Put yourself in the shoes of a hacker who wants access to a site. Your first assumption is that there is a firewall in place. This is a fairly safe bet, considering firewalls are the state of the practice for Internet security.
Figure 1: Stateful firewall connections allow ingress traffic.
Your second assumption is that the firewall allows certain protocols to pass. These protocols are based on the services the site uses: electronic mail (POP, IMAP, SMTP), world wide web (HTTP), domain name service (DNS), and others. Sites with these services use client software. Therefore they have vulnerabilities.
Your third assumption is that the firewall policy allows traffic to clients that have initiated a connection. This is known as a stateful firewall (see Figure 1).
To reach your target, you (as the hacker) must trick the firewall into allowing your traffic. Since responding to a client request is the only inbound path, you need a way to get the client to initiate that request. What better mechanism than luring the client to a web site you control?
The moment the target connects to this web site it is infected by malicious code, and voila-the code makes the return trip through the firewall without a hitch. The malicious content can be embedded in anything that is executed by the browser, such as web pages, ActiveX controls, or Adobe Acrobat PDF files (see Figure 2).
Figure 2: A hacker can get through a firewall by tricking the target into visiting an infected web page.
Another path
Figure 3: Instant messaging also offers hackers a way through a firewall.
There is an even easier way to exploit client-side vulnerabilities. Internet Explorer and Outlook share the same ActiveX control (vulnerable application code) to display HTML pages. This means that an attacker can email HTML with embedded malicious code exploiting the vulnerability.
Client-side vulnerabilities also can be found in several PDF readers and instant messenger messages. Figure 3 illustrates how a hacker can use instant messaging to get inside a network.
If a stateful firewall can't stop client-side exploitation, what will?
Client-side vulnerabilities are insidious because not only are firewalls helpless against them, but eliminating servers completely (outsourcing everything to a third party) can't solve the problem either. Any computer with an Internet connection has client applications, and is therefore vulnerable.
Neither intrusion detection nor deep-packet firewall inspection can stop attacks against client applications. The most reliable defense is intrusion prevention (see Figure 4). An intrusion prevention system will identify and block attacks on client-side vulnerabilities.
Figure 4: Intrusion prevention stops exploits against client-side vulnerabilities.
Intrusion prevention stops attacks on client-side vulnerabilities
Intrusion prevention not only identifies inbound attacks, it stops them. Intrusion prevention can work on known attacks as well as many unknown attacks. Coupled with good tools for alerting and security experts that can understand and react to the alerts, intrusion prevention can be extremely effective in combating threats.
SecureWorks provides technology for intrusion prevention and combating other network security threats. We combine this with a world-class Security Operations Center, providing around the clock monitoring to detect and stop attacks.
About the author
Jon Ramsey is an information security expert with SecureWorks in Atlanta, GA. Ramsey has 10 years of hands-on experience at every level: system administrator, software engineer, analyst, security penetration specialist and senior engineer. Prior to joining SecureWorks, Ramsey was a member of the Computer Emergency Response Team (CERT), and worked for Siemens International and the University of Pittsburgh. Ramsey has a Master's degree in software engineering from Carnegie Mellon University and a BS in computer science from the University of Pittsburgh. He is a member of IEEE and the Association for Computing Machinery (ACM). He can be reached at [email protected].
Glossary
Client-side application: an application that sends a request via a network. Server application: an application that sends a response to a request via a network.
Stateful Firewall: a firewall that maintain connection negotiation and state between a client and server.
Vulnerability: a feature of application code that exhibits unintended consequences such as compromising the availability, integrity or confidentiality of information.