Hopefully, you have been able to complete your testing before reading this portion of the chapter. It will contain examples and at least one method for an initial approach to breach the security of the virtual AspenMLC Development Lab running on our own network or machine. If your documentation or methodology to obtain the initial goal is different, than that is described within; it does not mean it is wrong, just different. With practice, penetration testers will develop their own methods, are tailored to their skill set and knowledge base.
The scope of this particular test can be clearly defined by reading the scenario objective and background information:
- We have 4 hours to test a virtual environment that has been made to emulate what our client wishes to eventually use in production.
- The only user we are aware of is the administrator who has contracted us on behalf of the fictional AspenMLC Research and Development Corporation.
- The information contained on this network is completely harmless to the corporation. There is no special need to keep things encrypted or to be cautious with third-party services.
- We are to completely compromise as many machines as we can, and we can use the Kioptrix machine as an assist for a pivot point as we conduct our testing.
- We may use any technique known to us including social engineering, exploitation, denial of service, and so on. The sky is the limit. This includes, planting an executable file to emulate a client infection to egress out of the environment.
- None of the data or information on these systems is contradicts any laws that we know of, state or federal. As the network is for educational purposes, only we can do whatever we like with it.
- All systems on the network will be open source-based.
With these items in mind, it should become apparent that the challenge here will come with the limited time factor. There are a significant number of machines; therefore, the identification of the weakest machines is very important in this type of test. If there are several people on our team, we could propose that we use several testers with very specific tasks that can be run in parallel to make the most of the limited 4-hour testing time (the admin refuses to pay for more than four hours at our standard rate, which is based on a maximum of three testers taking part in the testing).
Although the "why" is clearly laid out for us in this instance, we should not become complacent. It helps testers and the business alike to understand what the real goal of your testing is, and allows you to focus on aligning your testing and reporting with accomplishing this goal.
In this case, the administrator has clearly stated that vulnerability analysis tools have already been used against this network, and he has addressed the issues with the exception of those that the business has considered acceptable. This will vary from business to business, based on the risk appetite of the corporation or individuals you are dealing with. Understanding the risk appetite may assist in determining the "why" as well. Perhaps you are only testing the environment, just to prove to the business unit that they can remain confident that it will take an attacker more than four hours to compromise their network, which just happens to be how long it takes their security teams to locate any strange activities occurring in their environment.
The administrator has clearly stated that there will be a direct monetary impact if any of their critical data were to be collected by malicious intruders. The scientists who work at the corporation are not technically savvy and will be using rudimentary solutions to technical problems. It is safe to say they will be storing unencrypted test files that are shared by multiple users on a file server that contain the critical data. The "why" in this case is a fear that a lot of money will be lost; consequently, there is a need for someone to assure the business that the administrator's suggested security configuration will be sufficient to prevent this event from happening.
This most critical document must be clearly written and well defined. We now have all of the information we need to develop the Rules of Engagement document; before any testing occurs, it must be presented and agreed upon.
The Rules of Engagement must detail the scope, systems, network addresses, and what you are and are not allowed to do during testing. Regardless of the template or look and feel you decide upon, the document you create to meet the challenge should have at minimum the following information:
- The date the Rules of Engagement was created: 01/02/2020.
- The names and contact information of your company and that of any testers that will be directly involved in testing: Kevin Cardwell.
- A summary of the request: We are to completely compromise as many machines as possible, both by emulating the Internet connection that will exist in the production environment and via internal testing techniques.
- A quick description of what a penetration test is (the following has been taken from Chapter 1, Penetration Testing Essentials, in this book): Penetration testing allows the business to understand if the mitigation strategies employed are actually working as expected; it essentially takes the guesswork out of the equation. The penetration tester will be expected to emulate the actions that an attacker would attempt and will be challenged with proving that they were able to compromise the critical systems targeted. This allows the business to understand if the security controls in place are working as intended and if there are any areas that need to be improved.
- The type of testing that will be performed: Full compromise penetration test with no restrictions other than timeframe.
- Limitations: A 4-hour timeframe.
- Clearly defined goal of the penetration test: Completely compromise the site machines that reside in the network segments within 2 hours.
- IP Ranges:
192.168.10.0/24,192.168.20.0/24,192.168.25.0/24,192.168.50.0/24,192.168.101.0/24, and192.168.175.0/24. - Data handling: Data has been stated to be for testing only and thus not to be considered or treated as confidential in any manner.
- How will any data found to be in possible violation of state or federal laws be handled: Proper authorities will be notified prior to the business or its entity.
- List of AspenMLC Development contacts and their phone numbers, and so on: John Dow.
- Signatures of pertinent officers of the company needed: AspenMLC Development CISO, CIO, or other officer in charge. Unless he can prove otherwise, the administrator does not have sufficient authority to allow you to test the assets of the AspenMLC Development Corporation.
With the Rules of Engagement out of the way, we can take a look at the network diagram and develop a plan of attack. Let's review the network layout that was provided to us by the administrator. This is shown in the following screenshot:
In this white box test, we were provided with the network architecture to make up for the fact that we are testing a mock environment and are limited by a strict timeframe. We need to determine if the router will let us through from segment across segment. Our initial plan is as follows:
- Perform a vulnerability scan on the
VMnet2firewalls and gateway. We know about it, so we may as well take advantage of it! Do the same to all systems listed on this diagram. - Perform a network and vulnerability scan against all the virtual switches.
- We want to see if we can reach the other segments from the
VMnet2switch, and we will perform a network and vulnerability scan against those as well. - If we cannot reach any of the networks, we will perform a web application scan against the machines that are running web applications and see if there are any web application vulnerabilities we can take advantage of.
This most basic of plans will suffice in getting us started. The information we gather from these steps should be sufficient to move us on to the next steps. Who knows, maybe the administrator was right and the setup is actually secure (not very likely in this case!).
We begin by executing the first step in our action plan and scan the devices using the tools of our choice. In this case, I decided to use MagicTree. It allows me to run the queries from within the app and has the ability to generate reports on-the-fly.
Load up MagicTree and create a new node as we did in Chapter 1, Penetration Testing Essentials; run an Nmap scan against any of the networks that are available from the available subnets. If everything was configured properly, you should only be able to see the VMnet1, VMnet2, VMnet3, and VMnet9 switches.
When reviewing the data, we find that there are some interesting services running on these systems that should be reviewed. Let's run a quick vulnerability scan against them to save time. We will use OpenVas to perform the vulnerability scan. OpenVas is included in Kali.
After realizing that the scans will take too long and would put us over the 4-hour mark, we determine to move on to the next phase in our test plan and quickly determine that the installed software is reasonably updated with the exception of the intentionally vulnerable machines. By looking at the website, we also notice that it is a standard install of the latest version of WordPress. When reviewing the site closely, we notice a contact e-mail address. We add this e-mail address to our MagicTree notes. There is a good chance the e-mail name jdow is also used as a network logon. If this is the case, we have half of the puzzle solved. There may be a chance we can brute-force John's SSH password.
There are a number of tools for attempting this, and we will leave that as a homework exercise for determining if this is possible.
One additional technique we might want to attempt is the process of testing the egress filtering of the site. We can do this with a number of methods that attempt to connect across the different segments outbound from the different segments. Additionally, we can create an HTML file and simulate a user clicking on a link that might connect to our ports outbound across the different switches. To configure this, you can do the following:
- An
<img>image tag will assume HTTP and may use other ports:<img src=http://192.168.25.20/noimage.gif />assumes port80<img src=http://192.168.25.20:8888/null.gif />assumes alternate port set
- Internet Explorer can connect to many other ports, but has to be configured or tricked:
<img src=ftp://192.168.25.10:110/noimage.gif /><img src=http://192.168.25.10:1024/noimage.gif />
- In the previous bullet, the first
<img>is using ftp to connect to port110, and then the second<img>is using http to connect to1024 - IE can be also be tricked into connecting to low ports with HTTP by launching a new pop-up window, as shown here:
<script> window.open("http://192.168.25.20:123/noimage","Window1", "menubar=no,width=30,height=60,toolbar=no"); </script>
Another method to egress out of the environment through a filter is to set the LPORT to a port that was identified from the egress busting code. Additionally, HD Moore, who created Metasploit, has another method to proxy outbound traffic; to use this method, enter the following:
setg Proxies SOCKS4:127.0.0.1:3306 setg LPORT 45567 setg PAYLOAD bsd/x86/shell/bind_tcp (change this to the shell as required for the target)
These commands will set the global variables for your proxy and also for your preferred payload. We choose our default local port to be 45567. The original message can be found at https://dev.metasploit.com/pipermail/framework/2010-January/005675.html.