In our scenario, we discovered a high-level vulnerability on the Web server. We will now attempt to exploit this vulnerability to gain unauthorized access to the system.To do this we’ll:
1. Upload the data we obtained during steps 1 and 2, information gath- ering and vulnerability assessment, into Core Impact (Impact).
2. Execute Impact’s Attack and Penetration Module to attack and exploit the Web server.
3. Leverage the Web server to gain access to the database.
Uploading Our Data
Upon launching and configuring a workspace within Impact, we’re presented with the window shown in Figure 6.10.This is the interface we’ll leverage to conduct our attack.
Here’s an explanation of the different parts of the Impact user interface, as explained in the Core Impact User Guide
1. The Modules panel Provides access to Impact modules. Modules are the actions, such as information gathering, attacking, sniffing, and so on, that we can perform on the network or against a host.
2. The Entity View panel Displays information about our targets. This panel initially contains only an entry for the local host (the machine on which Impact is running). As we attack and exploit sys- tems, they, too, are added to the Entity View panel.
3. The Executed Modules panel Displays information about each module or action that was performed during the penetration test. 4. The Executed Module Info panel Displays information about
the currently selected module or action in the Executed Modules panel.
5. The Quick Information panel Displays information about the currently selected item in the console. For example, if we select a module, the panel displays module documentation. If we select a host, the panel displays information about that host.
To upload our data into Impact we select the Modules Viewtab within the Modulespanel. We then expand the Import-Exportmodule. Figure 6.11 shows the available import-export options for Impact.
As shown in Figure 6.11, Impact has import modules for Nmap and Retina; the two tools we utilized during steps 1 and 2 of our penetration test. To streamline our penetration efforts we’ll upload the data we previously col- lected.To upload the data we simply click on the corresponding module and follow the instructions. Figure 6.12 depicts the Nmap interface.
Figure 6.11Impact Import-Export Module
Figure 6.12Impact Nmap Import Interface
We generate the Nmap file value referenced in Figure 6.12 by appending the –oX (<filename>) tag to the Nmap commands we executed earlier during the information-gathering phase. When we append these arguments, Nmap will output the results to an XML file.
Upon uploading the Nmap and Retina data into Impact, our Entity View panel is updated with the following:
■ The IP addresses of the Web and database servers
■ Open ports on both systems
■ Vulnerabilities discovered during the VA
Once we have both of these systems defined within the entity view, we can proceed to the attack and penetration phase of our test. Figure 6.13 reflects the updated entity view.
Figure 6.13Updated Entity View
Attack and Penetrate
Based on the vulnerabilities previously discovered, we know we must first exploit, or penetrate, the Web server if we hope to gain access to the cus- tomer records. We need to do this because there were no identified vulnera- bilities on the database server.
To exploit the Web server we could either selectively, or manually, run Impact exploits against the Web server, or we could leverage Impact’s Attack and Penetration Wizard to exploit the host.The Attack and Penetration
Wizard will compare the Web server’s vulnerabilities and open ports against exploit modules within Impact and attempt to automatically exploit the system.
To invoke the Attack and Penetration Wizard click on the RPT Viewtab within the Modulespanel and select Attack and Penetration. Upon doing so, Figure 6.14 appears.
Figure 6.14Attack and Penetration Wizard
Click Next, and the screen in Figure 6.15 appears. Here we define the system we want to attack; the Web server in our scenario.
In an effort to maintain system stability, we will not run any exploits that might render the system unavailable (see Figure 6.16).
Figure 6.16Exploit Selection
After clicking Next, we assume the remaining default settings and allow Impact to begin its attack on the Web server. We can follow the status of the attack by viewing the attack modules within the Executed Modules panel. Following the attack, we see that Impact is able to penetrate the Web server via the MSRPC UMPNPMGR exploit (see Figure 6.17), and loads a level 0 agent on the system. If we had our speakers on during the attack, we would have heard Impact announce “New Agent Deployed.”
Notice that Impact exploited the remote Web server via the MSRPC UMPNPMGR vulnerability and not via a DCOM-related one.This is because we configured Impact to stop its attack upon successfully deploying its first agent. Although we provided Impact with VA data, Impact attacked, or ran exploits against, the system based upon the Web server’s open ports and vulnerabilities.
N
OTEWithin Impact, a level 0 agent provides basic shell access to the remote system supporting a finite number of commands. A level 1 agent is an administrator or root equivalent agent that has the ability to do any- thing and everything on the remote system. Communication calls between the Impact operator and the level 1 agent are also secure, but they are not with a level 0 agent.
Having gained unauthorized access to the Web server, we now need to determine the context, or identity, under which we’re operating. By con- necting to the level 0 agent and launching a mini-shell, we execute the
whoami command to determine the identity we’ve assumed. Figure 6.18 high- lights the output of the whoami command.
The whoami command displays the identity of the logged-in user. In Figure 6.18, we’ve determined we’re operating under the context of
Authority\System; a Windows built-in administrative equivalent account. Via Impact, we’ve gained unauthorized administrative access to the Web server. We’ll now upgrade to a level 1 agent. Upgrading to a level 1 agent will pro- vide us with a rich mini-shell and allow us to execute command-line argu- ments as though we are at the Web server’s console. Figure 6.19 reflects an updated entity module containing the level 1 agent.
Figure 6.19Entity Module: Level 1 Agent
Having established a level 1 agent on the Web server, we now have several options regarding attacking the database server and ultimately gaining access to the customer records. We could:
■ Source attacks from the Web server Since the database supports the Web server, the firewall between the two systems may contain a more liberal set of firewall rules. If this were the case, we could repeat steps 1 and 2, information gathering and VA, sourcing these efforts from the Web server. Doing so may provide insight into vulnerabili- ties that were undetectable from our position within the network.
■ Install software on the Web server We could install a packet driver, remote control software, and so on. Doing so may allow us to discover credentials that are leveraged by the Web server to access the database.
■ Search the Web server for information We could search the Web server for information. Such a search may disclose proprietary company data or other sensitive data housed on the system, or enable us to access credentials to other resources.
Searching the Web Server for Information
Of the aforementioned options, searching the Web server for information is the easiest to conduct and the hardest to detect. If we installed a remote piece of software on the Web server, its antivirus program may detect and quaran- tine that software, and sound an alarm concerning this. Sourcing our penetra- tion efforts from the Web server is a viable option, but it requires that we restart our penetration efforts from scratch. Looking back at our System Information Table will provide further insight as to why this is the best option (see Table 6.5).
Table 6.5System Information Table
Operating Vulnerabilities/ # Host IP Address System Open Ports Severity
1 Web 10.192.144.54 Windows 135/tcp JetPhoto (Low)
2000 139/tcp DCOM 443/tcp (Medium) 445/tcp MSDTC (High) 1043/tcp TS (Low) 2105/tcp Norton (Low) 2301/tcp ICMP (Low) 3372/tcp 3389/tcp 49400/tcp Continued
Table 6.5 continuedSystem Information Table
Operating Vulnerabilities/ # Host IP Address System Open Ports Severity
2 Database 10.192.146.34 Windows 111/tcp Null Session
2000 135/tcp (Low) 139/tcp DCOM 445/tcp (Medium) 1433/tcp TS (Low) 3389/tcp ICMP (Low) 4125/tcp 4987/tcp 5555/tcp
In Table 6.5, we’ve highlighted two key attributes. On the Web server, we’ve highlighted the operating system and on the database we’ve highlighted the open port,TCP 1433.This tells us two things:
1. The Web server is more than likely running Microsoft Internet Information Server (IIS) 5.0. IIS 5.0 runs only on Windows 2000. 2. If we’re able to detect database credentials on the Web server, we can
use our position from within the network to connect to the database server for TCP 1433, the Microsoft SQL default port.
Discovering Web Services
Until now, we’ve discovered no information to validate that the Web server is indeed a Web server. Looking at Table 6.5, you can see that TCP port 80 is not referenced as an open port.This could be due to a variety of reasons. Considering that this is the client’s e-commerce Web server, it’s highly unlikely that the client changed the system’s default port; doing so would require the client to inform its customers as to what the new port is, and this simply doesn’t scale. More than likely the client has filtered the port, via its firewall, from its internal clients.To determine this we’ll leverage our Impact mini-shell and dump all of the TCP port 80 connections to the Web server (see Figure 6.20), to ascertain whether the server is indeed accepting Web connections. We’ll use the netstat command for this purpose;netstat is used to
display protocol statistics and current TCP/IP connections. From Figure 6.20, we can confirm that the Web server is indeed accepting TCP connections on port 80.
Figure 6.20Web Server Detection
We then confirm that the client is running IIS via the iisreset /status com- mand (see Figure 6.21), which is unique to IIS.
Having validated the existence of a Web server, it’s now time to unearth access credentials to the database.To do this we consider:
■ Both the Web and the database servers are running Windows 2000.
■ The Web server supports the client’s e-commerce initiatives.
■ Active Server Pages (ASP) is the primary method to support dynamic Web content on Windows 2000 and IIS.
■ Active data objects (ADO) and Object Linking and Embedding Data Base (OLE DB) are the predominant application program interfaces (APIs) used to connect to a database from a Web server.
Maintaining access to our mini-shell we search the Web server for all .asp files that contain “sqloledb.”These files contain access credentials to databases. Hopefully we’ll find at least one file that references the customer database. Figure 6.22 contains the output of our search.
Figure 6.22findstr Output
Well, well, well. Look at what we’ve found. Leveraging the findstrcom- mand within Windows we’re able to uncover a connection string and creden- tials to the customer database. Figure 6.23 highlights the output from Figure 6.22 that references the customer database.
Figure 6.23SQL Credentials
At this point, there’s no need to continue our attack from the Web server. Having garnered user credentials to the database and with the database,TCP 1433, being available to us from our attack position, we can simply connect to the database from our local machine.To connect to the database we’ll use Microsoft’s SQL Query Analyzer and the credentials from Figure 6.23. Upon connecting, we’re presented with the screen shown in Figure 6.24.
Figure 6.24Query Analyzer Connection
As we can see by viewing the available databases within Figure 6.24, the customer database represents the only user-created database; the rest of the databases are installed by default with Microsoft SQL. Expanding Customer we locate a table titled “creditcard.” Upon querying the creditcard table, selecting its 10 top records, we uncover customer data. Now it’s only a matter of joining the fields within the creditcard table and the rest of the tables within the customer database to assemble the complete customer record. At
this point, we have accomplished our objective. We have accessed customer records.The penetration test is over.
Vulnerability Assessment
versus a Penetration Test
After walking through a vulnerability assessment and a penetration test, we might think penetration tests are the way to go. Penetration tests do substantiate the vulnerabilities unearthed during an assessment. In some situations, penetra- tion tests are necessary. In others, they simply aren’t reasonable or practical.
Penetration tests are great for a small or targeted collection of assets; for example, network perimeters, third-party peering points, and internal financial or human resources systems. Unfortunately, penetration tests do not scale when we get into the hundreds, thousands, tens of thousands, and hundreds of thousands of systems which comprise major enterprise environments.
Comparatively speaking, vulnerability assessments do scale. Not only do they scale, but also they are cheaper in terms of both time and resources, and they give us a more exhaustive view of security liabilities across our enterprise.
Tips for Deciding between
Conducting a VA or a Penetration Test
If you are undecided as to whether to conduct a vulnerability assessment or a penetration test, here are some tips to help facilitate your decision.
You should conduct a vulnerability assessment when:
■ Time is a constraint Penetration tests can be very time con- suming, depending on the number of assets we are evaluating and the number of vulnerabilities that are present on any given host. Imagine how long a penetration test would take against 100 or perhaps 1,000 hosts. On most occasions, we’re not interested in whether a vulnera- bility can be exploited, for we may have compensating controls to mitigate the exploitation, but we would still like to know whether the vulnerability appears to exist.Though a vulnerability may not be exploitable today, this may not hold true for tomorrow. Many times vulnerabilities are re-released with new attack vectors allowing for
new conduits of exploitation.Think we’ve seen the last re-release of a Microsoft Remote Procedure Call (RPC) vulnerability?
■ Cost is an issue Not only do penetration tests require substantially more time, but they also cost more to conduct. In many instances, companies have to contract out penetration work, for they simply do not have the expertise on staff. Most organizations today, though, are fairly adept at conducting vulnerability assessments; especially given the number of VA products on the market.
■ Validating Want to know the success of that latest service pack push? Run a VA against the hosts in question. Systems often remain vulnerable after patches have been deployed, simply because the machines haven’t been rebooted. VAs are great at identifying this. Let’s compare our VA reports against the remediation team’s reports. We may find ourselves asking, “So, fellows, are we sure those
machines were patched?”
■ Trending How have we done at managing vulnerabilities across our enterprise today as compared to yesterday, last month, or perhaps last year? Sure, the number of vulnerabilities is increasing and the
window between disclosure and exploit is shrinking, but trending vulnerabilities across our enterprise can provide valuable insight into our organization’s remediation and change control processes.
You should conduct a penetration test when:
■ You have a limited number of assets Penetration tests are very practical against a small number of hosts—for example, the company’s financial or accounting systems. Where a vulnerability assessment attempts to identify all weaknesses, a penetration test simply seeks to exploit any one of the N number of vulnerabilities on a given system. Attempting to exploit all vulnerabilities is usually pointless. It doesn’t matter whether the front door or back window of our house is unlocked; a thief can effectively use either of these avenues as an entry point into our home.
■ Confirmation is needed We conduct a VA and find five high- level vulnerabilities on a system. Is that system truly vulnerable? Can an unauthorized entity compromise that system? The only true way to substantiate this is to conduct a penetration test. If we can leverage one of the identified vulnerabilities to gain access to the system, someone else can too.
■ You are fiscally flexible Penetration tests are typically outsourced to a company’s information technology (IT) provider, an external auditor, or a third party. Outsourcing the work validates the organiza- tion’s security posture, supports the company’s security program, and is required by most regulations. Outsourcing application development and support services may have their cost benefits, but outsourcing penetration testing can be quite expensive.
■ Time is not of the essence What takes longer, hacking five sys- tems or conducting a vulnerability assessment against those same five systems? Who said there was no such thing as a stupid question? Penetration tests depend on vulnerability information, so naturally, they take longer to conduct. If we want to confirm that the identi- fied vulnerabilities exist and time is on our side, penetration tests are the way to go.
Internal versus External
We can conduct vulnerability and penetration assessments either from within our network or external to it. An internal assessment will expose vulnerabili- ties that employees, contractors, third parties, or anyone else that has access to our internal network can exploit. An external assessment gives us a view of our security liabilities as seen by customers, competitors, business partners, and hackers.
To further distinguish internal and external assessments and the value proposition of each, let’s look at a typical network, as shown in Figure 6.25.
Figure 6.25A Typical Network
In Figure 6.25, as in most organizations, a firewall represents the first line of defense against outside threats. Some organizations also enable firewall capabilities on their edge, Internet router. Behind the firewall and before the corporate network resides the company’s DMZ; a hardened and semitrusted portion of the company’s network used to host Web, e-mail, and other Internet services. Behind the DMZ, separated by yet another firewall, resides the corporate network where end users and enterprise services live.