Metasploitable 4

First Post|Previous Post

In my previous post, I found and used a backdoor to gain access to the Metasploitable instance. This involved querying it FTP service to learn the server software type and version, then launching an exploit specific to that setup. Today, and I'm continuing to follow the same text, I'll attempt some ARP (Address Resolution Protocol) spoofing. I mentioned ARP briefly in an earlier post, but I didn't describe in any length.

ARP is part of a network's addressing protocols. Specifically, it correlates ip addresses with MAC addresses.

• MAC addresses (Media Access Control) are specific to a device. A smartphone has a MAC address, as does a desktop computer, a tablet, and a laptop. MAC addresses are unique, are generally permanently attached to their device, and provide (limited) information about the device. The leading characters of the address, for instance, are specific to the device's manufacturer. These are similar to people's names. MAC addresses take the form of six pairs of hexadecimal digits, each pair separated by a hyphen, e.g.: 06-b3-47-fc-1d-28; or by a colon: 06:b3:47:fc:1d:28.
• Ip addresses (Internet Protocol) are addresses on a network. To send and receive internet traffic, a device must have an address on a network, much as a person must have a postal address to receive mail. Similar to a mailing address, a device might move from one address to another through the course of a day - I might receive postal mail at home and at work, for instance. Unlike mailing addresses, ip addresses are transitory: once I disconnect from a network, it's as if I've permanently moved: I lose the ip address that I had on that network. Ip addresses (ipv4, technically; ipv6 addresses are distinct but similar) take the form of four triplets of decimal numbers, each triplet separated by periods. Leading zeroes are not shown: 142.250.64.78 rather than 142.250.064.078. Most addresses are public, meaning they are used for location on the internet, but three sets are reserved for use on local networks; these are known as private ip addresses:
  • Private ip addresses are restricted to local networks. No private ip address will appear as a location on the internet. Similarly, no public ip address will ever appear on a local network
  • Since private ip addresses are never locations on the internet, they can (and do) repeat from one network to the next. As I sit and write on my computer, my computer has a private ip address on my home network: 192.168.1.32. My home network has a public ip address that all of my devices share via a router: 123.456.789.65. I send data to blogger.com at 142.251.35.169, where a router sends my data to a device on their network, whose private ip address I never know. That device sends data back to my network router at 123.456.789.65. My router then routes the data for my computer to my computer at 192.168.1.32. At the same time, my smartphone is on my home network at 192.168.1.58. It connects to my bank at 23.219.82.203 (not my bank, actually, or maybe it is), where a router sends my data to a device on their network, whose private ip address I again never know. The bank sends data back to my router at 123.456.789.65, and my router routes that data to my smartphone at 198.162.1.58.
  • Throughout this, I never know (or need to know) the private ip addresses of the devices at blogger or Wells Fargo, nor do they ever know (or need to know) the private ip addresses of my devices. To communicate, all we need are each other's public ip addresses; we rely on our routers to route the incoming data to its final destination at our private ip addresses. Thus, our public ip addresses are our publicly shared addresses; while our private ip addresses are not shared, and have no use outside our local network: a little secret between our device and our router.

The transitory nature of private ip addresses means that every time I join a network, I have to get a new address, even if it's a network I've been on before. It also means that my router needs to maintain a list of which device (MAC address) is at which location (ip address) on the local network, or LAN (Local Area Network). Building and maintaining this list is done via ARP. Each time a device joins a LAN, it broadcasts a message out: "I've joined this network, this is my MAC address, I need a private ip address." The router replies, giving its (the router's) private ip address and assigning an ip address to the device. The router also adds an entry to its ARP table, listing the MAC address as residing at the private ip address the router just assigned. The device stores this info, enabling it to send all future traffic specifically to the router, rather than broadcasting it to the entire network. Over time, as devices continue to add to the LAN, the router builds a complete table of its LAN. Devices can come and go on a network, so from time to time a router may check whether a device is still connected by asking who is at a particular ip address. If the device is still there, it will reply with its MAC, otherwise the router will drop the entry from its table.

All of this works very well, but it was never designed for security. When a device joins a network, it broadcasts its initial 'I need an address' message out to everyone on the network. As designed, the router responds, while all other devices ignore the message, but there's nothing to prevent a threat actor from jumping into the mix. Similarly, when a router asks if a device is at a particular ip address, that is also broadcast to everyone, creating another opportunity for chaos. Finally, the tables are ephemeral, subject to and requiring frequent revision, and all ARP messages are accepted as truthful, without any check for validity.

All of this makes ARP tables a good target for a man-in-the-middle attack, where a threat actor intercepts all messages between two points that should be directly connected. In this case, the threat actor can tell a victim's device that they are the router, and can tell the router that they are the victim's device: the victim's device sends all traffic to the threat actor, while the router sends all traffic meant for the victim to the threat actor. The threat actor can then manipulate or read the data before passing it along to its intended recipient, or not pass it along at all. This is done via ARP spoofing, which will be the topic of my next post.

Metasploitable 3

In my last post, I found that much of the software on the target is dated 2003, but in poking around a bit more, I found a 2010 entry on TWiki. More data.

The book (Ethical Hacking, link leads to publisher) next suggests using an FTP hack on a backdoor in Metasploitable, but this feels too artificial, since it relies on the knowledge of the presence of a specific version of the vsFTPd software. Specifically, vsFTPd version 2.3.4 includes a malicious backdoor that was added during development (these things happen, though vulnerabilities are more often accidental). VsFTPd is intended to be a secure ftp server, and is the default ftp server on many Linux distributions. Thus, there's a good chance that some version of it is present on Metasploitable, and perhaps I can use netcat to learn more:

nc 192.168.1.102 21

This directs a connection to Metasploitable on port 21, the control port for FTP. (FTP is peculiar in that it uses two ports, 20 & 21. Data is sent on 20, while control function are sent on 21. Most protocols use a single port for both functions.) I receive a reply:

220 (vsFTPd 2.3.4)

220 is a response code indicating that the server is ready to interact with a new client, and now I have the server software and its version. Thus armed, I know I can use the backdoor described above. The full exploit sends a login username ending in :), a smiley face, then any password. The smiley face username negates the need for the software to check the validity of the password (though it still asks for one, and something must be provided), and opens a connection on port 6200.

Here, I've explored the bare minimum needed to make the connection. At first I included a colon after user, leading the ftp server to reject my entry (Please login with USER and PASS.). Providing a username with the necessary smiley and then hitting return (i.e. trying to bypass a password at my end) doesn't work, either. Not shown, I also tried providing a blank password (pass, then hitting enter), and a username of only a smiley face, neither of which work. But providing a username with a smiley at its end and a random password lets me in, as advertised. Opening another terminal window (so as not to break the connection established in the original window), I use netcat again to open a connection on port 6200. Note that my Kali box can't identify who the Metasploitable box is: unknown host; but the connection is there and I'm logged in as the root user. From here, I can edit or delete files, change user access, shutdown or reboot the machine, plant new listeners; I have the keys to the kingdom.

Edit: 12/28/2023: typos

Metasploitable 2: Reconnaisance

In my last post, I set up Metasploitable as a virtual machine on the same LAN as my Kali Linux box and determined the it's (the Metasploitable instance's) ip address using netdiscover. I didn't mention how I logged into Metasploitable, but the info is provided on the login screen: both username and password are msfadmin.

Armed with the ip address of the Metasploitable instance, why not take a look? This is as easy as entering the ip address into the address bar of a web browser, or actually, not quite that easy, since the browser automatically adds an https:// prefix, causing the browser to get lost and fail to connect. Manually deleting the prefix enables the connection:

Note the warning not to expose this instance to an insecure network. This is a vulnerable machine. Also note, if you're following along at home, that the ip address of my Metasploitable instance may not be the same as yours - check my previous post for two methods of determining the address of your instance.

Now that I'm on the Metasploitable machine, let's take a look around and do some reconnaissance. Starting at the top, clicking on the TWiki link leads to several more lnks: a license, a readme, documentation, all of which bear dates from 2003 - this software may be seriously out of date. On the todo list, now, is looking for exploits concerning TWiki.

I also find a list of users - usernames, most likely, and a link to the user registration page. Five users are listed, and I wonder how strong their passwords are? Names, emails, usernames, good stuff in plain view; even a list of admin usernames.

Another link leads to a phpMyAdmin page, which I may be able to gain entry to. There is also a DVWA login page, and a link to /dav, which indicates that it's running Apache version 2.2.8, long since out of date.

Only a few minutes of reconnaissance has provided me with several avenues of attack: two login pages, a list of usernames, and an out-of-date Apache setup. Where to begin?

Next post

First Hack: Metasploitable

Metasploitable (https://sourceforge.net/projects/metasploitable/) is a Linux instance that has been designed to be hacked - it has intentionally built-in vulnerabilities. Since it is known to be vulnerable, prudence requires running it in a walled garden. In my case, I'm running it behind the pfsense firewall I set up in my last post. Doing so is easy enough: once I download and extract the instance, I set it's network connections to the internal LAN I created when setting up pfsense. I've connected my Debian instance to the same LAN, and we're off. Metasploitable is named after Metasploit, (https://www.metasploit.com/ a pen testing framework.

Now that both instances (the attack box and the target) are on the same, sheltered network, my next task is to find the target, using my attack box. One option is nmap, a rugged, versatile, loud tool initially designed for mapping networks as part of routine maintenance. At a minimum, nmap requires an ip address or network for it to map. Though chances are high that I'm on the 192.168.1 network, assumptions will get me nowhere so I quickly run ifconfig to determine my network.

It turns out that I am on the 192.168.1.x network, so nmap would be:

sudo nmap -sn 192.168.1.0/24

In this case, I can use nmap, since I'm the only one on the network, but nmap isn't exactly stealthy. As set up, it's using ARP requests (I discuss ARP here), blasting them out to every possible address in the 192.168.1.0-255 network range and listening for replies. Anyone else on the network who might be listening will hear this traffic, and since it's not a common benign pattern, it should raise a flag: someone's scanning your network. There are other ways to use nmap - I could send pings, for instance, but they're also noisy.

Another option is netdiscover. Netdiscover also sends out ARP requests by default (or ICMP, for non-local networks), but it can also be set to passively scan for ARP traffic and assemble a map of the network from that. Since ARP traffic is broadcasted (i.e. sent to all devices on a network), simply listening for long enough is likely to yield a near-complete or complete picture of the network, and since I'm just listening, the activity is much stealthier.

The syntax for an active scan, limited to this network, is sudo netdiscover -r 192.168.1.0/24. A passive scan is sudo netdiscover -p. Note the lack of addresses on the passive scan, as we're simply listening to whatever floats past.

On a passive scan, I don't catch anything while my metasploitable instance sits idle, but when I ask it to ping Google's DNS server, I get a result. Actually, I get two:

Address 102 is Metasploitable, as I previously determined by using ifconfig from that machine. Normally, I wouldn't be able to perform this type of check, but here I can. Address 1 is my host machine - the machine I use to host my Kali box, pfsense, and Metasploitable.

Next post EDIT: 2023-12-23: fix typos, distinguish between Metasploitable and Metasploit

Home lab setup: 2

In my last post, I downloaded an ISO image of the pfSense firewall, adapting instructions written for VirtualBox to apply to my VMWare setup. I left off with the software running, but no ip address for the WAN, as seen at right.The menu gives an option to set an interface ip address - option 2. From here, I'm given the option to set the ip address via DHCP. ipv4 and ipv6 are separate options. Selecting 'no' to DHCP enables entering an ip address manually. Selecting 'yes' for ipv4 and 'no' for ipv6 does - nothing. Oops - it was already setup that way, so, no change. Googling a solution means finding pfSense setup directions; pfSense has their own page, it's the top hit, and I start there (https://www.pfsense.org/getting-started/).

I immediately realize that I've forgotten something pretty basic. When I downloaded the image, I never checked its integrity. If the file corrupted in download, I could chase error messages till Kingdom come and never solve anything, and in fact an integrity check should have been the first thing I did after downloading. The command is straightforward enough. I'm running a Windows host, and in the command prompt I enter certutil -hashfile [filename here] SHA256 (substituting the downloaded file's name, and without the square brackets). Hooray, the hash matches, so I know I'm working with an intact download.

Taking another look at the instructions, and looking at the settings for pfSense, and looking at the settings for my Kali box, I see that historically, I've used NAT for my outbound connections. Changing the WAN setting to NAT and rebooting pfSense does lead it to load up with an address for its WAN socket: I also note that previously, the loading process used to hang on "Configuring WAN interface" for over a minute; now this process only takes a few seconds. However, there is not yet a connection between machines on the LAN and the outside world. With my Kali and my Raven boxes on the internal LAN, I can reach one from the other, but attempting to reach the internet fails: I can't navigate to outside websites on a browser in Kali, nor can I ping the Google DNS server (8.8.8.8 - "ping: connect: Network is unreachable")

The solution, after starting several false hares and a few unhelpful google searches, was to reset pfsense to factory defaults and set the external network to NAT. "Well, nothing else has worked. Let's see what happens if I reset to factory default."

Setting up a home lab

A colleague suggested books by no starch press (https://nostarch.com/) as a good resource. I picked up two volumes, including Ethical Hacking by Daniel G Graham (ISBN: 978-1-7185-0187-4). Thew first section of this book is about setting up a home lab for practice.

Dr Graham gives instructions for setting up a lab using VirtualBox. In my bootcamp, I used VMWare. I don't remember the precise reasons, but I did try out both VirtualBox and VMWare, and was able to get VMWare started easier. Once it was up and running, there was no reason then to troubleshoot VirtualBox any further. Now my choice is to troubleshoot VirtualBox so as to be able to setup my lab like Dr Graham's, or try to adapt his instructions to VMWare. I think there's more to be learned by adapting his instructions, so that's the route I'm taking.

The first thing I learned was that if I was going to be running a vulnerable machine, I should probably place an additional firewall between it and the rest of the world. I actually have two firewalls: my ISP provides one with its router, and I use PiHole; so this will place three(!) firewalls around my vulnerable machines. In truth, I'm half convinced that this is overkill, but I don't think it will slow things down enough to matter, and I'd like the experience of setting up this additional firewall. Also, I expect it will simplify some of Dr Graham's later exercises, and as steep as I do like the learning curve, at a certain point you're looking at a funicular, which is self-defeating.

Dr Graham recommends the pfSense firewall, downloaded from their website (https://www.pfsense.org/). The download is straightforward, a zipped file that extracts to a .iso (disk image) file. You select your architecture (64-bit or Netgate; there's theoretically also a 32-bit option according to the help text on mouse-over, but that may be a legacy help text) and your (USB or iso), then download. Once you've unzipped the image, it's available to install: open the File menu on VMWare and select "New Virtual machine". A wizard launches - I used the Typical install option, then directed the wizard to the extracted iso. Strangely, I couldn't click on the image to select it, but by navigating to the folder then entering the filename manually, the install seems to have worked.

The default memory assigned by the wizard is 256MB. Dr Graham suggests a setting of 1024MB, which is changed via a vertical slider during setup. Alternately, you can change it later by right-clicking the machine's tab and selecting "Settings' form the resulting menu.

The network settings were the first real change. pfSense needs to connect to the internet and to a LAN - it's positioned between the internet and the machines on the LAN, in order to police the traffic passing between the two. This requires two network connections, and while the VirtualBox setup looks to have four network adapters out of the box, VMWare only provides one. In that same settings menu that I referenced last paragraph, though, on the Hardware tab, there's a button near the bottom of the window labeled "Add...", and clicking that gives the opportunity to add another network interface. this now gives me the two interfaces, one of which I set to Bridged (Automatic), and the other of which I set to LAN Segment:

• Bridged (Automatic) provides a direct connection to the physical network - this is the connection to the internet (and any threat actors) - the area outside the firewall.
• LAN Segment provides a connection to a local area network (LAN), the area inside the firewall. Initially, there are no LAN segments available, but adding one is easily managed through the LAN Segments button. Click 'Add' on the resulting mini window. I named my LAN 'Internal LAN' to keep it consistent with Dr Graham's design, and connected the Network Adapter 2 to this LAN Segment.

Thus configured, pfSense can be started up. There is an agreement to accept, then you can install the software. And about here is where I ran into my first puzzle.

Dr Graham now directs you to reboot pfSense, and then to note that pfSense redirects to the same copyright and distribution notices as before, since the machine is still booting form the original iso download. He directs you to Settings --> Storage, then select the iso file and click "Remove Attachment." I didn't find exactly that in VMWare, but on the Hardware tab of the Settings window, there is a CD/DVD (IDE) line, which when opened reveals checkboxes for "Connected" and "Connect at power on". For the connection, there is the downloaded, extracted iso file - looks like the same thing, right?

Well, I deselected the checkboxes, disconnecting the file, and restarted pfSense. And it didn't work. Foolishly, I didn't write down the error. The obvious soluiton was to reselect those checkboxes, which I did, but on restarting pfSense, it got stuck in a boot loop: rebooting and rebooting and rebooting.

Google is your friend, they say, and a quick web search on "pfsense stuck in boot loop" showed me that I was hardly the first person to face this scenario. The second hit was a Reddit post that included directions for fixing it (the first post looks to be a blog giving the same advice). I ran the appropriate command until there were no errors and successfully rebooted into the expected menu:

There is still one problem, which is that the WAN entry is blank, when it should be filled in. That is for tomorrow night.

Next Post

Firewall failures ground Southwest Airlines

CNN (and many others) are reporting a ground stop of Southwest Airlines flights, initiated by the FAA at the request of the the airline after "a vendor-supplied firewall went down and connection to some operational data was unexpectedly lost," according to spokesman Dan Landson (quoted from [5]). Many news articles remind readers of the airlines meltdown last December, when they cancelled nearly 17,000 flights over 10 days.[1,2,3] Southwest was not alone in cancelling flights then; the initial challenge was winter weather. However they were noteworthy in the reason and magnitude of their disruption, which was blamed in part on outdated crew scheduling software.[4]

Both of these failures are cybersecurity issues. I've mentioned the CIA triad before:

• Confidentiality: Data should access should be limited to those parties who are authorized to access it
• Integrity: Data integrity should be maintained; data should be complete and correct
• Accessibility: Data should remain accessible to those parties who are authorized to access it

Both cases represent failures of Accessibility: data that Southwest needed to meet its business goals was not accessible. In December, outdated software meant that the airline didn't know where its flight crews were. In some cases, personnel had to phone in their locations because they couldn't notify the airline electronically.[5] The airline used in-house software to manage its crews.[6] While doing so may enable a finely tailored result, it also means that they must be entirely self-reliant for any maintenance, expansion, upgrades, and security for that software - no one else uses it, no one else is familiar with it to offer insight. New employees enter entirely naive to the software, and have to learn it form the ground up. Legally, there may be more liability in providing their own software rather than outsourcing to a professional. Thus, though there may be short-term financial gains in in-house development, the aggregate picture becomes murky.

Today, the culprit appears to involve off-the-shelf software. Where the culpability lies is not yet clear, though. Setting up and maintaining the software may have been part of Southwest's responsibility. For the moment, we'll have to wait and see.

Sources:

1. Ivanova, Irina, "More than 2,000 Southwest Airlines flights delayed after temporary ground stop" CBS News (cbsnews.com). Accessed 4/18/2023 at https://www.cbsnews.com/news/southwest-flights-grounded-over-computer-issue/

2. Josephs, Leslie, "More than half of Southwest Airlines flights delayed after technology problem paused departures" CNBC (cnbc.com). Accessed 4/18/2023 at https://www.cnbc.com/2023/04/18/southwest-airlines-departures-pause.html

3. Baio, Ariana, "FAA briefly grounds all Southwest Airlines flights nationwide" Independent (independent.co.uk). Accessed 4/18/2023 at https://www.independent.co.uk/news/world/americas/southwest-airlines-ground-stop-faa-b2321980.html

4. Koeng, David, "US investigating December flight cancellations at Southwest" Independent (independent.co.uk). Accessed 4/18/2023 at https://www.independent.co.uk/news/ap-southwest-airlines-dot-dallas-b2269417.html

5. Wallace, Gregory et. al. "Hundreds of Southwest Airlines flights are delayed after FAA lifts nationwide ground stop" CNN (cnn.com). Accessed 4/18/2023 at https://www.cnn.com/travel/article/southwest-airlines-flight-delays/index.html

6. Arnold, Kyle, and Natalie Walters, "Holiday meltdown exposes Southwest Airlines’ technology woes" Dallas Morning News, The. Accessed 4/18/2023 at https://www.dallasnews.com/business/airlines/2022/12/29/holiday-meltdown-exposes-southwest-airlines-technology-woes/

Design for security

I recently got a new keyboard. My checkboxes were:

• ergonomic
• wireless, and sharing a dongle with my wireless ergonomic mouse
• full-sized, including number pad; arrow key cluster, and the cluster of keys for delete, home, and page-up, page down
• easy-type keys, which probably has an official name that I don't know. These are keys that don't havce to be pushed deeply into the keyboard to register, and can tollerate a certain amount of sideways push - they're buttons, really, more than keys

I ended up getting the Logitech K860. I've had it for a few weeks, so I'm still in the learning curve for the keyboard layout (I've had several ergonomic keyboards over the years, and each has it's keys layed out differently), but one feature stands out. I's the key at the top right, which features a lock symbol, and when pressed, it locks the computer, putitng up the lock screen and requiring me to enter my password if I want to resume using the computer. A year ago, I doubt I would have thought about this key, or ever used it, but I completed a cybersecurity bootcamp in the second half of 2023 and one of the many things I learned was the value of security habits. Being in the habit of locking my computer every time I step away from it closes one avenue of attack against my computer and my network, since no one else can sneak on to my computer during the several minutes that elapse between my last keystroke or mouse movement and when the computer automatically locks.

At home, the liklihood of a threat actor sneaking onto my machine is limited. However, I do recal a colleague of mine whose cat managed to blast her resume out onto a listserve by leaping up onto the keyboard and striking just the right set of keys. Security is about more than just protection against threat actors, and as much as I love my cats, I don't see benefit in giving them free reign over my keyboard.

At work, it's a different situation, of course, and for a several months I had been using a different wireless keyboard there, Logitech's K350. This keyboard also has a lock key, in the same location as the K860. This keyboard belonged to me, however, and was only intended as a stopgap, so when my department got me a new keyboard it came home. And then the value of that lock key really struck me, because my new keyboard doesn't have that key. I had developed the habit of hitting that key every time I stood up from my desk, but now I had to either use [CTRL] + [ALT] + [DELETE], then [ENTER]. or use the mouse to engage the start menu, then select user options, then select lock.

In truth, the extra time and effort is not large. But if you've ever seen someone toss recycling into the garbage can they're standing next to rather than crossing to the recyling bin three steps away, you know that many people are going to take the easiest route. Having a single button to press to lock the computer, and having that button be in a corner (you don't have to hunt for it), is about as easy as you can get. If we want our community members to lock their computers when they leave them unattended (and as security professionals, we do), the few extra dollars for a keyboard that does this is money well spent.

Don't advertise the IP address of your devices

Earlier today, I snapped the photo above. Clearly seen, on the side of the camera, is the camera's ip address (I've obscured the last two octets). Note also that this is not a private ip - the address that a device uses on a network - but a public ip: the camera appears to be connected to the internet directly. Assuming that the address is correct, I see a few issues here worth mentioning.

1. Anything on the internet is directy in the line of fire to attackers. Though the camera might have a username and password to protect it, we could add an additional layer of security by moving the camera behind the firewall of a network. Then, an attacker would first have to penetrate the firewall before they could address the username and password security. Placing the camera on the internet denies it of a layer of security. Granted, there are times when this is necessary or beneficial (e.g. traffic cams and raptor cams) but a security camera should probably have security.
2. Since this camera was installed in this way, I'm led to wonder about the security posture of the rest of this facility. Just on this camera, is the security still running on the default settings? There look to be manufacturer stickers on the bottom of the camera - if I could determine the make and model, a Google search might reveal the default username and password. More generally, have there been other flaws in creating the local network? In other words, the setup here advertises a loose security posture, inviting a hacker to take a stab at breaking in. It's a little like parking a car in a bad neighborhood with the doors locked but the key in the ignition.
3. Alternately, perhaps the address shown is not the address of the camera, but the address that the camera conncets to (the address of the security company, for instance). IN this case, the label may have been placed to enable the camera to be set up properly. In this case, the address is likely to be firewall protected, but there's still no reason to publically display it - keep that info need-to-know.

Least Privilege

One easy security practice is that of least-privilege. This is the concept that a user should be provided with as much in the way of privileges as they need to do their job, but no more. In a bank, for instance, the groundskeeper shouldn't have access to the vault.

Though the benefits to this may be obvious, they're still worthy of mention:

The most obvious benefit is that without access to the vault, the groundskeeper can't steal from the vault. But if the groundskeeper can't access the vault, this also means that someone posing as the groundskeeper can't steal from the vault, either. Think of how many heist movies involve stolen credentials; if the stolen credentials don't provide access to the loot, the thief is still empty-handed.

Similarly, can't enter the vault accidentally when looking for the bathroom, then damage something inside or leave it unlocked, nor can they enter it out of curiosity and do the same.

There are also benefits in the event of a break-in. If the groundskeeper doesn't have access to the vault, they are much easier to eliminate from the list of suspects, simplifying the investigation and speeding recovery.

A sub-concept is the idea of one user having multiple accounts, each account with differing privileges. The root or administrator account of a computer holds the keys to the kingdom. There are times when a user requires that level of access, such as when installing software, but using that level of access all the time creates a problem. If I'm in my root-level account and download a virus, I can inadvertantly install and execute that virus. If I'm using an account that isn't allowed to install software, though, this may prevet the virus's installation. Also, the amount of damage I can do is limited by the amount of access I have, whether that damage is accidental or intentional.

Root accounts in linux often include reminders of their elevated risk, sich as a skull symbol as part of the command prompt. This is good, but I think there's a benefit to going further. If the account is uncomfortable to use, the user is encouraged to complete their work and get out as soon as possible. The root account on my Windows machine has a red color scheme, with the eye of Sauraon as the wallpaper - I know I'm in the root account, and I don't linger.

Capture the Flag: Raven, part 2

First Post (Last Post)

Last time, I left off during Open-Source Intelligence (OSINT), having looked through most of Raven’s website, found their blog, edited my /etc/hosts file to enable their blog to properly load, and finally loaded up their blog in my web browser. There is another page to the website: Contact. This page looks to have been left unchanged from the template used in creating the site, as it includes contact info specific to Bangladesh, including two phone numbers and a physical address. There is also a Google Maps display that didn’t properly load until I had clicked on it a few times, and a form to submit data. Opening up Burp Suite, I discovered that the form submits to the site’s ip on port 80 via POST request. Allowing my submission to go through revealed that there is no obvious outcome from submitting the form.

So far, there are two obvious avenues of attack: the WordPress blog and the outdated server software. Note that Wordpress isn’t inherently unsafe. Rather, it’s often misconfigured in an unsafe manner.

There may be more to find. So far, I’ve limited my nmap scan to ports 80 and 443. Running it against other ports might yield further information and/or confirm what I’ve already found. I’m also allowing BurpSuite to crawl the site, having set guardrails on it to not scan anything outside of my target’s ip. From this, I found the image library. Here I found several flags (i.e. national flags), probably used for setting the user’s language or location. I note that the first flag is Canadian. Perhaps the site was set up in Canada? Bangladesh’s flag is number 7. There are also a series of images of children, which I didn’t find on the site itself and seem incongruous for a security company; and a disturbing image of a child clown doll. I hope it’s a doll. None of the images show any sticky notes in the background, which might contain usernames and/or passwords. There is an image of a firefighter, but their service (e.g. city) is cropped out. Though the image is likely a stock photo, it might have indicated sources of passwords. Similarly, the main background photo contains an officer. Her uniform contains chevrons, suggesting ranks like those of the military (two stripes would be a corporal). Another image appears to be from Dublin, which might be a source of passwords, including their sports teams. In truth, all of the images here are probably stock images, but in a real engagement there might be valuable information among the dross.

There is no robots.txt file. These files direct web crawlers not to explore or index particular pages. This can be done to shield portions of the site from the search engines powered by the web crawler. From an offensive standpoint, this is a bit like saying “ignore the man behind the curtain,” so evaluating the contents of a robots.txt file can be useful OSINT. Robots.txt files can also be used to alert legitimate crawlers of spider traps (see https://en.wikipedia.org/wiki/Spider_trap).

Any web page’s source is visible by right-clocking and choosing ‘view source’ (or similar) form the contextual menu that pops up. Typically, the browser menu also offers a method, and a shortcut key is [CTRL] + [U]. Looking through the source code, at first I only note some spelling errors. There are also irregularities in the capitalization of the rem lines (comments). These suggest a certain amount of sloppiness went into crafting the site, which may have carried over into its security posture.

One of the flags, it turns out, is hidden in the source code. I’ve whited out part of it – if you want the flag, you’ll have to find it yourself.

 

The source of the WordPress page contains about 150 lines of viewboxes and paths in a format I’m unfamiliar with. I’ll note it down, but given that I already have an outdated Apache Install and a WordPress site, hopefully I won’t need to figure this out. The Contact page’s source code reveals nothing of import, though I am again struck that the phone number on the top right of the page does not match the phone number in the Contact area of the page.

I can also run a more complete nmap scan:

sudo nmap 192.168.159.140 -sC -sV -O -Pn -p- -oA raven1

Here, I’ve directed nmap to limit its attention to the target ip, rather than spreading itself over my entire subnet. I’m also scanning with ‘usual’ scripts (-sC), scanning for software versions (-sV), scanning for operating system and version (-O), suppressing ping as before, scanning all ports (-p-) and directing the output to be saved to files with name “raven1”.

I find four open ports:

·         port 22, running OpenSSH 6.7p1 Debian 5+deb8u4 (protocol 2.0)

·         port 80, running Apache 2.4.10

·         port 111, running rpcbind 2-4 (RPC # 100000)

·         port 58053, status 1 (RPC #100024). This port is also mentioned in association with port 111.

Port 111 is a well-known-port for remote procedure calls (RPC). There may be something here, as there are known exploits for the RPC function.

Considering now the Apache Server, the RPC functions, and the WordPress blog as potential avenues, WordPress feels easier.

Wpscan is a scanner for WordPress blogs. For noncommercial use, it is free. Among other things, it can scan for themes and plugins (including any associated vulnerabilities), enumerate usernames, and attempt to brute-force passwords (as described in its user documentation (https://github.com/wpscanteam/wpscan/wiki/WPScan-User-Documentation), it can check for weak passwords by making brute force attacks. Exhaustive brute force attacks require other tools.) Having updated its databases (gem update wpscan) and its metadata (wpscan –update), I’m ready to launch:

wpscan --url 192.168.159.140/wordpress -eu

wpscan addresses the program.

--url tells it I’m feeding in an address to scan; it is followed by a space and then the address of the blog (in this case, the ip address followed by “/wordpress”).

-eu tells it to enumerate users.

Note that without additional flags, wpscan will run somewhat aggressively (noisily)

Perhaps a second later, wpscan returns two users, “michael” and “steven”. It also gives me the WordPress version, and notes that this version is outdated.

First Post (Last Post)

Capture the Flag: Raven. Part 1

Raven is a Capture the Flag (CTF) that runs as a virtual machine. The benefits of this are first, that as you hack Raven, you don’t have to worry about accidentally shutting something down – it’s a virtual machine with no other software on it; and second, you actually have to find the machine on your network, giving you some practice in network assessment.  I ran Raven on VMWare, attacking from a Kali Linux box, also on VMWare.

Finding the target:

Since I didn’t have an ip for Raven, my first step was a quick network scan.   I turned to nmap for this.  Since I knew that Raven includes a website, it seemed reasonable to scan for any machines with ports 80 (http) and/or 443 (https) open:

sudo nmap 192.168.159.0/24 -p80,443 -Pn

In this case, I didn’t need to use sudo, which runs nmap with administrator privileges, but nmap does require sudo for some of its scan types and I slipped up and added it.  No harm done.

nmap, of course, runs nmap, the network mapper, and this is followed by the CIDR range of my home network.

The p flag (option)n tells namp to only look at ports 80 and 443.  By default, nmap looks at 100 ports on each host; trimming the list to two ports sped things up.  If I had remembered whether Raven hosted its website on http or https, I could have eliminated one of those ports and sped things further, but with a small network (and no intrusion detection system (IDS)) the benefits would have been minimal.

Pn tells nmap to skip pinging hosts to see if they’re live.  In practice, hosts can be told not to respond to pings, meaning that lack of response to a ping doesn’t prove the lack of a host at that address.  A flurry of pings can also set off an IDS.  Suppressing pings causes nmap to proceed as if it successfully received a ping from every host on the network – i.e. it fully scans every address, whether there’s evidence of a host at that address or not.  Depending on the complexity of the scan and the size of the network, this can greatly add to the work nmap has to do, and thus the time it take nmap to complete, which the program warns you of when you use this flag.  Here, I had a small network and a simple scan, so the time burden was minimal.

Nmap returned five hosts. One was the ip for my attack box (the machine I was attacking from).  It is possible to tell nmap to skip the attack ip, but the extra keystrokes would have taken more time than it would have saved.  Of the other four, only one had an open port 80 or 443.  As a bonus, the MAC address is noted as VMWare, though MAC addresses can be spoofed.

Since port 80 was the open port, simply dropping that ip into my web browser of choice proved that this was indeed my target, as the Raven website popped up.

Assessing the Target:

Now that I had a website, let’s take a look at it.   Much of the site isn’t actually fleshed out – the links lead nowhere.  At the bottom of the home page, however, there is a list of blog posts which lead to a different nowhere.  Instead of leading right back to the page they start on (a # link), clicking on a blog entry yields an error:

Apache 2.4.10, huh?  Pretty outdated.  There should be some good exploits available here.

Adding this to my notebook, I kept going.  The bottom of the page contains a live link to colorlib, which provides website templates and WordPress themes  Perhaps there are known flaws in some of their products.?

Also at the bottom of the page there is a text entry field for visitors to enter their email addresses to stay abreast on Raven’s latest news.  A quick entry of a single quote yielded no peculiar results, but there could be something here on further investigation.

The About Us, Service, and Team pages yielded nothing of note, but the blog page liked out to a Wordpress blog. This page took about a minute to load, and came up as a mess.  Either someone did a really bad job coding here, or (more likely) the page isn’t loading properly.

Viewing the source code reveals the answer. There are three dns prefetches. Two look to be sites on the web, but the third (the first, actually, line 10, to raven.local) looks like an address stored on the same server as the web page.

A quick Google search tells me that dns prefetches are hints to a web browser that resources will be requested form a particular location, so making a connection with that server now will save time when the resource is actually requested.  Searching the web page’s source code shows 27 times where resources are requested from raven.local (not shown).  This looks to be the problem: the browser can’t find the resources that are stashed at raven.local.  No DNS lookup can provide this address; I need to tell the browser that these resources are located locally.

Doing so is via the /etc/hosts file.  Here, I’ve added Raven’s ip and the text ‘raven.local.’  When the computer wants to access a domain, it will first look here to resolve the domain name to its ip address; adding this line tells the computer where raven local is.  At the same time, I could add a line stating that 129.168.159.140 is “target”, so that I could substitute “target” for the ip for the rest of this engagement.

Note that /etc/hosts is rewritten every time the computer reboots, so changes here aren’t permanent.  I edited the file using nano – note that this file is write-restricted – I needed to edit with root privilege to be able to change the file (sudo nano /etc/hosts).

Saving my updated /etc/hosts file and reloading the blog generated a clean, properly loaded site, and enabled me to easily find the login page.

NOTE: In this write-up, I have included images of the Raven website. This website is copyright protected. However, I believe that the use of low-resolution images, used for the purposes of educating users about the site, is acceptable "fair use" of this material. If the copyright holder wishes me to remove these images, please comment on this post, including a method for replying.

Next Post

Why Today's FAA Snafu is a Cybersecurity Failure

 Cybersecurity, at the end of the day, is about protecting the CIA triad of confidentiality, integrity, and availability: data should be kept confidential (unauthorized persons should not have access), with integrity (it should be complete and correct) and availability (persons authorized to view and use the data should be able to do so.  Today's failure of the FAA's NOTAM (Notice to Air Missions) safety system is a clear example of a failure of availability, and the chaos that can result following that type of failure.  Without the data provided by the system, thousands of flights were grounded.  The cause now appears to be a corrupted file,(1, 2) meaning that integrity, another pillar of the triad, led to the loss of accessibility.

Though data breaches, hacking, and pen testing tend to be the first things thought of when cybersecurity is discussed, the more pedestrian functions of keeping the data safe from accidents is just as important.

1. Blackman, Jay, et. al. "Corrupted file to blame for FAA aviation stoppage that delayed thousands of flights" NBC News, Updated Jan. 11, 2023, 6:47 PM EST.  Accessed at https://www.nbcnews.com/news/us-news/us-flights-grounded-faa-outage-rcna65243 Jan 11, 2023 6:56 PM EST

2. Federal Aviation Administration, "FAA NOTAMS Statement: Wednesday, January 11, 2023", Accessed at https://www.faa.gov/newsroom/faa-notams-statement Jan 11, 2023, 7:00 PM EST