Hacking for Fun and (Not) Profit

Thanks to a handful of commands I'd typed into the terminal window on my loaner Linux laptop, I'd managed to take over a remote Windows machine. While giggling fiendishly the entire time, I'd also added a user account for myself and remotely rebooted that computer.
I was hacking, or rather, proto-hacking, and it was a tremendous rush.
I've always considered myself a bit of a technology geek on top of an infosec journalist. I administer my own network and I like to write my own scripts and small applications. I like taking apart hardware and installing custom firmware on devices. But I've never really known how to take these skills and put them together to remotely take over a computer. I knew how to use some of the tools but I used them as a defender to protect my network. I did not know how to put the skills together to actually break in. Until now.
"One person's penetration tester is another's hacker," Mike Belton, a team lead for penetration testing company Rapid7's Assessment Services group, told our little Hacker 101 class in New York. The same tools the network administrators use to scan their networks to identify problems and malicious activity are the same ones hackers use to gain illegal access to data and computers.
"You don't have to cause damage to be a hacker," Belton reminded us.
Hacker 101: LinuxEach one of us in Belton's class had a laptop running Kali Linux, a Linux distribution designed specifically for penetration testing, and was connected to a network containing a mix of vulnerable Windows and Linux machines. Belton showed us how to use Wireshark, nmap, a few other command line tools, and Metasploit, the penetration testing suite managed by Rapid7.
We "found" a Linux machine with a mis-configured NFS file-sharing service. We exploited the flaw to copy our own SSH key to the remote Linux machine so that we could log in as root. Even though we didn't have the root password, we were able to access a user's home directory because NFS was misconfigured, and that was all we needed.
There is a lesson to be learned here. Hackers don't need to brute force the root password if administrators and users leave holes like that wide open.
I poked around and read messages in the inbox, learned that TikiWiki was installed, and found a password file hiding in the backups directory. I know this was a VM carefully created with vulnerabilities and mistakes, but it was still pretty eye-opening (and entertaining!) looking at random directories and realizing how much information a person can gather just by being curious.
In a real-world scenario, I could have used that password file buried in the backups directory to gain access to the Web server or other sensitive machines. I could have looked at the TikiWiki configuration file for the database password.
Hacker 101: Windows XPBelton also showed us how to use Metasploit to remotely exploit a Windows XP machine. From our previous reconnaissance activities, we knew the IP address of the Windows machines we could target. We configured Metasploit to look for a remote code execution vulnerability which existed in Windows 2000, XP, and 2003 Server, as well as in Windows Vista and Windows Server 2008 (CVE-2008-4250). Even though Microsoft had patched the flaw in 2008 (MS08-067), Belton said he still sees machines with this vulnerability when testing client networks.
Metasploit makes the entire experience feel like child's play. With the target computer set and a payload selected, we just typed the word "exploit" to launch the attack. I had this mental image of a catapult flying across with a flaming fireball and slamming into the castle walls.
"You've exploited an old XP VM and have an active meterpreter shell," Belton said. I wished we had sound effects to go with this exercise. We either needed a Batman-style "Pow" or canned applause, I am not sure which.
We took screenshots of the Windows box, and I rebooted the machine (something a true hacker wouldn't do, since the goal is to be stealthy). We also created user accounts on the Windows Domain Controller with administrator privileges. At this point, it was a snap to just open a remote desktop session and log in with our new accounts, and do whatever we wanted.
Tools Used for Good or BadThe tools themselves aren't bad. I use them as a network administrator and tester pretty regularly. It's the motivations of the person using them that can be suspect. And after this exercise, I kind of understand the "hacking for lulz" mindset hacking pranksters Lulz Security espoused a few years ago when they went on their destructive spree. I was disappointed when we were told classtime was up. I was just getting started!
"You don't have to know as much [as you used to have to] to do as much damage," Belton said. The tools make it easy, but you still need to know enough (or be able to search online) to understand what you are seeing on the screen.
The hacker mindset is not the technical knowledge, but rather the willingness to poke around. It's not enough to say my computer doesn't have sensitive data, so anyone who breaks in can't cause damage. The person coming in is nosy enough to see what else I've done, what other computers I am mapped to, or what files I have deleted. It's the information that requires digging that's going to be my downfall, and that's exactly what these folks are curious enough to look for.
This is why we need to be better with our defenses.
Lesson Learned
I went home and found that while my Windows XP machine was fully patched, I apparently had a Windows 2003 server with the same RCE vulnerability that we had played with in class. Oops. I'd never updated that machine because it's been years since I had done anything with it, despite having it up and running on my network. I won't be making that mistake again.
The same rules apply: we need to keep up with software patches and updates. Use VPNs whenever we are on public wireless networks. Make sure we configure applications and services correctly, such as changing default passwords and turning off services we aren't using.
Happy defending!