The new weakest links

Kevin Johnson doesn't strike you as someone who could break into your network and wreak havoc with your organization's data. He looks like a friendly guy, a jovial family man quick to crack a joke. But don't be fooled. No matter how many precautions you take or how closely you monitor your equipment, he can get inside.Luckily, Johnson, of the security consulting firm Intelguardians, is not a malicious hacker. He is a penetration tester, a security professional whom organizations pay to break into their networks to expose weaknesses. He always finds some.Johnson is also an instructor at the SANS Institute, a cooperative research and education program that offers in-depth information security training to information technology professionals. For five days in January, Johnson led Security 542.1, 'Web Application Pen-Testing In-Depth,' in New Orleans. There, in front of a class of 20 IT professionals, he walked through the process he uses to gain entry into a Web application and revealed some tricks, at least those not too sensitive to talk about. More important, he revealed the mind-set of the attacker.It's a mind-set all security professionals should know. If you think that Web application security is just something your Web development team should worry about, think again. Web applications are the weakest links in the enterprise today. They can actually be the first foothold in an attack on internal networks and systems, especially those systems with more sensitive data.And the remedy involves more than patching all the systems and watching for vulnerabilities. It also involves knowing how an attacker thinks ' how he or she will use anything to gain a foothold and, once in the enterprise, exploit that for further access.'Usually it is very, very quick to find one major vulnerability,' Johnson said. And all it takes is one vulnerability, and a lot of subsequent legwork, to crack open the whole system.Each week in its Security Alert e-mail letter, SANS summarizes the number of vulnerabilities found, or weaknesses in programs that outside parties can use to gain control of the machine the software runs on. In the past few years, the organization has seen a shift in vulnerabilities. As operating systems have slowly become hardened, attackers have set their sights on Web applications, which, thanks to legions of developers not trained in program engineering, tend to have no shortage of security holes. More than half of the vulnerabilities SANS lists week after week tend, on average, to be in Web applications.The function of a Web application is fairly simple: The user deploys a Web browser to send requests to a server. The server might be a simple Web server offering up static Web pages, running Apache or Microsoft Internet Information Server. Or it could be assembling pages on the fly, using scripting languages such as PHP or Microsoft Active Server Pages. Beyond Web pages, servers can also offer entire applications via a browser. These are called application servers, or servers that execute the business logic, and prepare the information requested, or submitted, by the user. The Web pages or other data elements tend to be stored in back-end databases.What unifies all of those components is that most run on what are called stateless protocols, most notably HTTP, which defines a set number of requests that a client can make of a server, such as calling up a Web page or posting some information.What makes a protocol stateless is that transactions via the Web do not enjoy a dedicated connection between the server and the client ' the server sees each request as new. To keep track of users, developers have come up with a number of tricks, such as placing cookies on the client computer or encoding identifying information in the Web address returned to the client. Even hidden fields in the Web page can identify the user.More in-depth sessions require some form of authentication on both sides. At the most simple, user authentication works by having the user supply a password to the server to use a Web application. Applications that require greater levels of security, such as those involving financial transactions, use digital certificates. The two most prominent forms of this secure HTTP ' Secure Sockets Layer and Transport Layer Security ' use that technique. Both protocols encrypt messages between two parties and check with a third party to ensure that the certificates verify the stated identities of both parties.This is the landscape that attackers see, Johnson said. And they find vulnerabilities in each location.About six weeks ago, Sen. Barack Obama's (D-Ill.) presidential campaign got a cruel reminder of what can go wrong when a Web site is not secured correctly. Using a form that allowed visitors to submit comments, someone injected code that would redirect users to the Web site of Obama's rival, Sen. Hillary Clinton (D-N.Y.). According to the Internet security watch firm Netcraft (GCN GCN.com/1096), the site was vulnerable because it did not filter the data that could be submitted through the form, allowing someone to inject a script that would redirect users' browsers to another site.This new server browser landscape provides a number of fresh ways to penetrate systems, including SQL injection, cross site scripting (XSS) and, most recently, cross-site request forgery (CSRF).In SQL injection, the attacker uses Web forms to learn more about the underlying database. In each submission field of a Web site, the attacker will try various Structured Query Language commands to see how the server will respond. The idea is to embed a command in a query in such a way that it actually gets executed by the database system.Administrators can limit the types of characters that can be entered into a Web form, though many Web sites have no restrictions. The easiest way to tell if filtering is taking place is by typing a commonly used SQL delimiter ' such as ' ` ' ' into the query field and see what comes back. The response can be telling: If you get SQL error codes in return, it might mean that no filtering is taking place.A variation of SQL injection is blind SQL injection. This is a technique to thwart those systems administrators who have gotten wise to SQL injection and set their systems to stop sending error messages. Johnson said not sending error messages can give administrators a false sense of security because it still allows attackers to input SQL statements. The trick for attackers is to issue commands and see what commands come back.XSS, another method of attack, works by tricking a user's browser into running malicious code on a vulnerable site by hiding the code within a Web page. This can be done by, for example, hiding it in a comments form or embedding it in a link sent in an e-mail message. On the server side, finding a vulnerable client involves looking for one that will execute script (usually JavaScript) when it is inputted via a form.An attacker who uses XSS effectively can actually take control of the user's browser.CSRF is a more recent attack vector. It uses an existing trusted relationship between a server and a client ' involving, for instance, a client that has logged in to a support Web console or one that has recently visited an online bank and still has a session cookie that has not expired. If the client could somehow execute malicious script ' again perhaps buried in a Web page comments section ' that code would execute on the targeted site, with full privileges as granted by the session cookie.Many of those attacks might seem tedious to explore and execute, but Johnson reminded the group to keep in mind the persistence of attackers. Using these and other methods in conjunction with careful observations of the target's behavior can result in successful penetration.'I send commands into the application in using my browser,' Johnson said. 'I break out of the application using SQL injection, and I'm able to launch commands on an internal serve.'Likewise, if you can control a user's browser via some form of XSS and that user is behind a firewall in an internal network, then, with the right information, you can access other resources, Johnson said.'Using JavaScript, I can take control of your browser and have your browser do things for me'[such as] surf and retrieve content from internal servers,' he said.To get to this level of penetration, however, an attacker will need to know far more about the target than which vulnerabilities exist on the public-facing servers. What are the user accounts? What software and hardware are being run? How are the components linked?'You should need to know who your target is, as specifically as possible,' Johnson said.This is the step most often missed by hobbyist hackers, or script kiddies ' the kind of attackers who rely on programs to do the dirty work. And yet it is the most vital step of all, Johnson said. It involves collecting all the mundane information about a site that can be had.An attacker who is casing your site can glean a surprising amount of information just from public sources. First stop is the WhoIs repository of registered domain names and associated contacts. Another is the target's Web site. Press releases can provide details about a system implementation, such as when an agency signs a contract for an integrator. Job postings offer clues about what systems are supported and what gaps the agency is experiencing.A look around the Web in other places can help attackers, too. They can search on various technical mailing lists and newsgroups. For example, a systems administrator or programmer looking for assistance could ask a technical question in a public forum and even provide a set of configuration files ' all which could help an attacker understand what lies behind the firewall.Search engines are another useful resource. Hacker Johnny Long keeps a list of search strings that can reveal sensitive system information through simple Web searches (GCN.com/1091), such as user names, passwords, sensitive directories and files.Attackers could look at the servers themselves. The NSLookup (on Windows) and Dig (on Linux) can return the IP numbers for a given domain name. With the IP numbers in place, an attacker can then scan the ports using a program such as Nmap. Most intrusion-detection systems watch for port scanning, but the usual Web server gets so many scans that they are routinely ignored.Alternately, an attacker could peruse the site and use a packet sniffer such as Wireshark to intercept packets, which can offer even more details about internal servers.Knowing details of the operating system allows an attacker to look for vulnerabilities specific to that operating system.User names are the first step in getting fuller access via user accounts. Using public e-mail, an attacker can guess the format of the e-mail accounts. A hacker can verify if a user name is valid by entering it in a log-in system using a deliberately bogus password. Sometimes there will be subtle differences between a response to a log-in that has a wrong password and a response to a nonexistent user name. Sometimes the difference will be glaringly obvious ' a 'this password is incorrect' versus 'user not found' response.Most log-in software is smarter than that, but there are subtle ways of getting that bit of information. The response time, for instance, can be telling. If the user name is incorrect, it can take 1 second for the system to respond. If the user name is correct but the password is wrong, it could take the system 2 seconds to respond. It's a tell, in poker-speak.No single vulnerability will allow complete and unfettered access to an organization's network. The attack process is cyclical, Johnson said. An attacker who finds a vulnerability that puts him or her on a Web server can then start from scratch to find any vulnerabilities from that location. This is called gaining a foothold. The idea is to find another vulnerability that will allow deeper access to the network.Software programs can automate most of the steps described above. Tools such as Burp Suite and Web Scarab can automate the process of casing a database. If you have or can obtain a Google application programming interface key, Google searches can also be automated through programs such as SiteDigger and Wikto.A number of tools bundle vulnerabilities and exploits together, allowing the user to scan a site for what software it runs and then check it against a list of vulnerabilities. Metasploit is a free program, and Core Security offers a commercial product for qualified customers. Both programs can find the vulnerabilities in a site, gain access and hand it to the user.But the attacker still must do the heavy lifting. The process starts by identifying a Web application and carefully mapping it, noting all its characteristics and configurations. From there, some footholds or easy vulnerabilities will be found. 'We use these footholds to pivot' around to find other vulnerabilities,' Johnson said.Like a computer adventure game, clues to the next step can be hard to find at first. 'I've seen applications that I thought were good, but then I realized there was this one little thing I never checked out, and I check it out and it is as if the entire Web application falls apart around me,' Johnson said.At the end of the week in New Orleans, he ran through a scenario based on a composite of real-life examples in which those practices and many more he discussed during the week could be coordinated into a targeted attack, one taking no longer than a few weeks to complete.In the scenario, an organization hires a penetration tester to hack its Web site to find out if one of its partners could use the site to attack another partner. The organization's public- facing Web site has links to each of its partners. It also has a sign-up system for partners, who must be approved by the organization.The tester does Google searches on the organization and finds the IP numbers, then spiders the site and builds a site map. At first glance, the site looks pretty well locked down, with no major vulnerabilities evident.There is one small oversight, though. The signup page does not have an XSS filter. As a result, the tester can inject code as part of the sign-up. When the administrator gets around to approving the sign-up application, the XSS script takes control of the administrator's browser. That is what Johnson calls the pivot point.'The minute the [administrator] viewed the sign-up, it launched the code and [the tester] had control' of the administrator's browser.With control of the administrator's browser, the tester can log in and take a look around the internal network. There, the tester finds another server, one that allows partners to post comments. The tester posts a comment with more buried XSS code aimed at compromising a partner machine. The tester then waits for a partner employee to load the comment page.'The minute it reports in, [the tester] can scan ports, run vulnerability assessments.[The tester] has pretty much unlimited control of the partner's network,' Johnson said.'Web applications are everywhere,' he added. 'It's easy to find developers. It's hard to find smart [security-minded] developers. We have a problem, and we need to fix it.'