Default credentials
Most hacking uses fairly parochial attack vectors, exploiting human rather than machine programming.
If you’re ever in need of an inspiring book, we at LXF Towers can recommend Richard Feynman’s The Pleasure of Finding Things Out.
Feynman’s notes on quantum physics remain a great source of information on the topic, but this book is a lighthearted insight into Feynman’s boundless curiosity. While working on the Manhattan Project, the book describes how he developed an interest in safe cracking. Apart from guessing combinations using personal information (birthdays of family members in particular) and realising that even high-ranking officers leave combinations written down, he discovered techniques for reducing the number of combinations that need to be checked. For one thing, only a fraction of combinations could be dates, so even without biographical information the search space could be reduced. For another, clunky mechanical safes were analogue and came with margins of error, so only one number in five needed to be checked.
His most shocking realisation, however, came when he met the man who had cracked a heavy-duty safe belonging to a decorated general. Asking him his secret, the man told him that these things ship with factory defaults, and that most people don’t change these.
And, just as it was in the 1940s, so it is today. There are a huge number of routers online that you can log in to with credentials such as admin:admin, or Raspberry Pis that still use the default pi:raspberry combination. As Internet of Things devices become popular, this problem becomes even bigger – such things tend to get plugged in and forgotten about, with owners unaware that they make an ideal beachhead from which to launch attacks against home networks.
Open source software is pretty good at avoiding the default credential trap. No Linux distro would ship with such an atrocity, and most software that you install on Linux demands you come up with your own password.
Lists of default usernames and passwords for particular devices are widely available, and the Shodan search engine (for IOT devices and servers) will find the control panels of webcams, backup appliances and even SCADA systems that attackers can try their luck with. Shodan can search for hosts serving RTSP (real-time streaming protocol) traffic on port 554, which would give any security camera hacker a lengthy list of targets.
The whole culture of shipping things with default passwords needs to change, but so too must consumers’ mindsets. It’s no great technological feat to have a device prompt for a password on first boot (or after a factory reset), but that’s a whole extra step that irks users. There’s a terrible misconception that being behind an IPV4 router at home prevents access to your devices (until ports are explicitly forwarded by NAT), but this is not strictly true. Programs running on your LAN can use UPNP to convince the router to do NAT, and the router itself may be vulnerable to exploitation from the outside. There’s IPV6 in principle makes accessing devices inside your network from the internet at large even easier – although in practice most home routers will prevent this.
One of the best ways to learn about exploits is to find a vulnerable system and attack it. Unfortunately, unless you own that system this approach is also very probably illegal. So don’t do that. You can craft your own vulnerable system. It’s pretty easy to get hold of a Windows XP virtual machine (and also perfectly legal – you can extract such a thing from XP Mode for Windows 7 installer at www.microsoft. com/en-us/download/details.aspx?id=8002) or an old Ubuntu ISO, but it’s at best time consuming and at worst annoying to find suitably old software to install on it and set it up in a vulnerable way.
Fortunately the good people at Rapid 7 have done all the work for you and condensed it all into a virtual machine (VM) called Metasploitable. Now in its third incarnation, it’s actually two VMS – one based on Ubuntu 14.04 and one based on Windows Server 2008.
Setting up Metasploitable is pretty straightforward as long as you have about 65GB of disk space. The installation uses Vagrant to set up two Virtualbox boxes, so you’ll need those two tools installed in order to progress. That can be done on Ubuntu with a simple
$ sudo apt install vagrant virtualbox
Vagrant and Virtualbox by default store their images in your home directory, so if this is on a partition with not much space it’s a good idea to tell them to put their bits elsewhere. For Vagrant (which by default uses
~/vagrant.d), we should set an environment variable:
$ export Vagrant_home=/path/to/vagrant.d
It’s a good idea to add this line to ~/.bash_profile too, so that this continues to be used after a reboot.
For Virtualbox you can set the default storage location by going to File>preferences>default Machine Folder. If you run out of space in the next step, the installation tends to clear up after itself so you can free up space and try again. Create a directory and download the
Vagrantfile from Rapid7: $ mkdir metasploitable $ cd metasploitable $ wget https://raw.githubusercontent.com/rapid7/ metasploitable3/master/vagrantfile
Then let Vagrant work its magic with:
$ vagrant up
The install should merrily chug along, eating a bunch of your precious space. When it finishes, if you fire up
Virtualbox you’ll see that two new VMS have been set up and running. These are set up to use 2GB of memory each, so you may wish to shut one of them down if you’re machine starts to act up. You can do this either from Virtualbox or by running vagrant halt ub1404 or vagrant halt win2k8 . If you have only 4GB of RAM you should consider upgrading before trying to go further.
You can access the machines directly with Virtualbox, but it’s more fun (and more like what you’d do if you were attacking a remote machine) to probe the services they’re running from a different machine. The setup script is careful to set up the virtual network interfaces in such a way as to keep vulnerable VMS accessible only to the host machine, in the interests of safety. In order to access them, you’ll need their IP addresses.
There are multiple interfaces on the Ubuntu VM, but the one we’re interested in (eth1) has been helpfully hardcoded in the Vagrantfile – it’s 172.28.128.3 (addresses beginning with 172 are reserved so this won’t interfere with anything). The username and password for the Windows VM are both vagrant (the same credentials work on the Ubuntu VM if you really want). Once you’re logged in open a Command Prompt on Windows and type ipconfig /all and look for a similar 172.som.eth.ing address. The Windows VM will use DHCP to get an address from Virtualbox, and if you start it and then start the Ubuntu VM it’s possible they’ll both end up with the same address. It is something to be aware of in future. To avoid it we’d recommend just attacking one vulnerable VM at a time.
Before we can begin the reconnaissance of our vulnerable VM, we need to set up our pen-testing environment. There are a number of ways we could do this. The simplest would be to add the required tools to the host. Or we can set up another virtual machine and install the tools there – we’re going to do just that. Since we have thoughtfully provided the Kali Linux Light ISO on the disc, we can use this in our VM.
As Kali Light doesn’t include any tools by default, we’ll need to add them manually. If you’d rather just add the tools to your host environment (and you’re using something Debian-based) the method is the same. We could use the Kali ISO as a live disc inside the VM, but it will be smoother and less memory intensive if we install it. If memory is tight, go to the VM’S settings, and reduce the memory (System> Motherboard) to 1GB.