In the present article, we will walk through the creation and installation of our victim machine, a virtual instance of Metasploitable2, and then configure our first lab network: a completely virtual internal network inside VirtualBox. We'll place the Metasploitable2 victim machine and the Kali attack machine on the virtual network, and conclude by showing one way to begin exploring and exploiting Metasploitable's various vulnerabilities with Kali, and then provide some resources for further study.
On that note, it must be stated at the outset that Metasploitable is an intentionally insecure machine, with a ridiculous number of vulnerabilities. It should never be exposed to the internet, or to an untrusted network. This is why we will connect it to a completely virtual network, one that cannot even be accessed by the host machine that is running VirtualBox.
Installing Metasploitable2 in VirtualBox
There are number of subtle differences between creating a Metasploitable virtual machine and creating a virtual instance of an everyday operating system such as Kali in VirtualBox, as wel shall see. Metasploitable2 is a prepackaged system intended for security testing and practicing common exploit techniques. Once the machine is set up, it does not require any updates or further configuration as was the case with Kali.
The first step, of course, is to download a copy of the Metasploitable2. Metasploitable2 was developed by Rapid7, the IT security group that created the Metasploit Framework, "a tool for developing and executing exploit code against a remote target machine," as noted at Wikipedia. The Metasploit Framework, as you may know, is also bundled in Kali, and the intentionally vulnerable Metasploitable2 system was created to provide a way to test the sorts of exploits that can be launched from Metasploit, among other tools.
You can download Metasploitable2 from Rapid7, but it is also available from other sources such as SourceForge. Once you've downloaded the file, unzip it, and place it wherever you prefer. I keep all my virtual machine .iso files and the like in a dedicated folder.
In the Metasploitable2 download, you'll notice a few differences from your Kali download. For Kali, we used the .iso disk image file to install the system on the machine. There is no .iso file for Metasploitable2. Instead we are instead going to install the Metasploitable.vmdk file, which stands for virtual machine disk format.
Start up VirtualBox and click "New" to begin setup of the victim system. Name the new virtual machine, select its type and version. I've just used the defaults here: Ubuntu, 32 bit. Click "Next".
Since we will not be using the Metasploitable system directly, but rather only interacting with it as a target, we can lower the amount of RAM we allocate for it. I've chosen 384 MB as the initial setting. After you get it up and running, you might find that you can reduce it even further. In my experience, response times begin to noticeably lag around 256MB of RAM. Click "Next".
We do not need to create a virtual hard drive for Metasploitable. Instead the .vmdk file will act as a virtual hard drive itself. Select "Use an existing virtual hard drive file", then click the file-browser icon, navigate to your Metasploitable download files, and select the .vmdk file. Click "Create".
The newly created instance should now appear in your VirtualBox interface. Notice I have grouped my kali1 instance and my Metasploitable2 instances inside a folder labeled 'lab'. Grouping becomes very helpful once you have more than a couple virtual machines set up.
Now we need to tweak a couple settings for our Metasploitalbe virtual machine. Open the Settings window. I uncheck 'Floppy' in the boot order under the System menu, though this is not very important. In the Network settings, you'll notice that the default is the same as it was for Kali: there is a single network adapter enabled with NAT, natural address translation.
We're going to change NAT to an internal VirtualBox network. In the "Attached to" drop down menu, change adapter one by attaching it to "Internal Network". You can also name your new virtual network. The default name is 'intnet'. I'm going to call mine 'labnet'. Click OK.
on_internal_network_11.png)
We're not quite ready to fire up our victim system just yet. Or at least, I'm not, because I've chosen a new name for my internal network. My experience with internal networks in VirtualBox has been a bit inconsistent. I clearly recall that the first time I used an internal network, it just worked and no further config was necessary. On another computer, I later found that the default internal network 'intnet' had to be configured as you would any custom internal network. If you fire up your Metasploitable virtual machine, log in and find that you have a functioning ip address, you're all set and can skip the following section. Otherwise, read on.
Configuring the VirtualBox Internal Network
I have to now enable the VirtualBox internal network 'labnet' to which I've just attached my Metasploitable virtual machine. If we take a look at the VirtualBox user manual section on Internal Networking, we read:
Unless you configure the (virtual) network cards in the guest operating systems that are participating in the internal network to use static IP addresses, you may want to use the DHCP server that is built into VirtualBox to manage IP addresses for the internal network. Please see Section 8.35, “VBoxManage dhcpserver†for details.Rather than set up static ip addresses for our virtual machines on the virtual internal network, let's set up the virtual dhcp server. Reading through the VirtualBox user manual section on managing the dhcp server, we can conclude that running the following command in a terminal on the host computer will appropriately configure the internal labnet network.
VBoxManage dhcpserver add --netname labnet --ip 192.168.1.1 --netmask 255.255.255.0 --lowerip 192.168.1.2 --upperip 192.168.1.255 --enableWhat's going on here? Let's parse this command.
- There is the command for the VirtualBox dhcp server: VBoxManage dhcpserver
- We want to create a new network, therefore: add
- We indicate the name of the new network: --netname labnet
- We specify the ip address of the dhcp server itself: --ip 192.168.1.1
- We specify the subnet or netmask: --netmask 255.255.255.0
- We specify the lower ip address for the server: --lowerip 192.168.1.2
- We specify the upper ip address for the server --upperip 192.168.1.254
- Finally, we enable the network so it starts any time a machine on the network is started: --enable
Run ip addr or ifconfig to confirm that the system has been given an ip address and make a note of it. The victim is prepped. Did I mention? Metasploitable is an intentionally insecure machine, with a ridiculous number of vulnerabilities. It should never be exposed to the internet, or to an insecure network!
Now let's put our attack machine on the internal network. Network adapters can be changed in this manner even if the machine is running, though in my experience, this can also lead to minor glitches in the functioning of the VM, so I usually shut down if I'm going to change network settings for a VM.
Select your Kali instance in the VirtualBox application interface, click Settings, go to the Network settings. Change the adapter from Bridged to Internal Network, and select the name of your newly created internal network. I also "Allow All" in promiscuous mode under the advanced settings, as this allows the Kali network interface to detect any and all packets to and from the other virtual machine (as well as the host computer, if it were able to connect to the same network). Click OK.
Start up Kali and log in if the machine is not running. Check ip addr or ifconfig to make sure you have gotten an ip address from the virtual dchp server. If so, you're all good! Open up the Ice Weasel browser that comes bundled with Kali. In the address bar, enter the ip address of your Metasploitable instance. When the page loads, you should see the web interface that is pre-configred on the Metasploitable virtual machine. It comes packaged with 5 different websites/webapps that are intentionally insecure: TWiki, phpMyAdmin, Mutillidae, DVWA, WebDAV:
At this point, you now have a virtual internal lab network running on your host computer, and two virtual machines running on that network: your Kali attack machine and your Metasploitable victim machine. Remember, this network is completely internal to VirtualBox. Your virtual machines cannot communicate with the host computer over this network and the host computer cannot communicate with the virtual machines over this network. They are isolated.
Exploring Metasploitable's Vulnerabilities
Now the real fun begins! The first thing you might do here is passive network monitoring to see what kind of packets, if any, the victim machine is sending out over the network. Fire up Wireshark inside Kali, and start a capture on the appropriate interface for the lab network. (See part two of this series on how to configure Wireshark for live capture.)
From the packet capture, you'll soon notice that Metasploitable sends out workstation and workgroup announcements every couple of minutes for services that are running on it. If you inspect those packets more closely, you'll find that those packets contain a good deal of information about the host machine sending them, as well as about the services running on it.
An an exercise, confirm by inspecting the packets you've captured that Metasploitable is: 1) a workstation, 2) a server, 3) a print queue server, 4) a Xenix server, 5) an NT Workstation, 6) an NT Server, and 7) a Master Browser. You can doubly confirm that the machine is running such services by browsing its shares over the network in the file manager. But where can we find the network login credentials to view the shares?
Now that we have some idea of what we're dealing with, let's conduct a few port scans of the victim system to see what vulnerabilities that might expose. Let's just go through some of the various default scan types built in to Zenmap to see what they bring to light.
A ping scan reveals that the host is up. A quick scan identifies 18 open ports, among them the reserved ports for ftp, ssh, telnet, smtp, htttp, mysql and so on. A regular scan identifies 23 open ports. An intense scan also reveals 23 open ports, but it also provides operating system and version information, along with more detailed information about the services running on the various ports. For example, it notes that anonymous ftp login is allowed on port 21, identifies the SSH server's hostkey fingerprint, and so on. Run the more intensive scans to see what else you can find.
As an exercise, analyze the command options used in the various Zenmap scans to determine why those particular scans revealed that particular information.
It is worth noting here that a couple leads for tracking down Metasploitable's network login credentials are provided already in the simple quick scan. However, it is indicative of the system's complete insecurity that these leads make the question of determining the network login credentials moot. Can you identify any such lead and why it moots our earlier question?
If you've followed along this far, you're probably asking yourself: what's next? (That is, if you haven't jumped ahead already.) Well, you now have a fully functioning virtual hacking lab outfitted with one of the most powerful attack systems and one of the most vulnerable victim systems around. It's time to start exploring some of the more involved tools bundled in Kali and see what other kinds of weaknesses you can identify and exploit in the various services running on the victim machine, including in the five websites and applications running on the system. That, however, is beyond the scope of the present article, but here are some resources to help get started:
- Metasploit Unleashed, an introduction the Metasploit Framework
- Burp Suite's introductory tutorial documentation
- OWASP-ZAP, the OWASP Zed Attack Proxy Project website
That concludes the present article. In part four of the series, we'll set up an external local area network and demonstrate how it is possible to steal login credentials from a victim machine logging in to a compromised router. As always, questions, comments, suggestions and criticism are welcome below.
Source:http://blog.agupieware.com/2014/10/hack-lab-part-3-installing-victim.html
Tidak ada komentar:
Posting Komentar