Anti-Spam Doesn't Catch Everything

Here's an interesting email: 

 

You'll need to click to enlarge.  The interesting part isn't that it's a phish, it's that it seems to have been released by Proofpoint and marked safe.

Initially, I thought that the email had been dressed up to look as something that had been screened, enabling it to slip through the email filters - sort of like parking where you know you're not supposed to park and leaving your own ticket on your windshield - maybe the meter maid will think they've already ticketed you and will leave you alone.  But on looking at the headers, that doesn't seem to be the case:

Based on comments by others (see https://security.stackexchange.com/questions/172860/analyzing-received-from-header-of-phishing-email), the prod.exchangelabs.com addresses seem to be various Microsoft servers, dutifully passing along the mail, and the original header looks to be gone, perhaps deleted by Proofpoint.

Oddly, the email address looks to be a Microsoft spoof:

The same address appears higher in the email (see the first image) as a "To" address earlier in the email thread.  Always look closely at email addresses - they may not be what they look like.  I nice trick to check email addresses for hidden mispellings is to (carefully) copy them into Word, then convert case to all caps: an rn masquerading as an m becomes RN, rather than M.

Finally, a coda.  As I wrote this post, my email app labeled the original email as junk and blocked the links.  Better late than never.

 

 

Rannsomeware deployed via unsecured webcam

Bleeping Computer reports the Akira ransomeware gang, initially stymied in their effort to deploy ransomware due to the target's EDR system, pivoted to an unsecured webcam for their deplyment. The gang gained most-likely gained initial access via stolen or brute-forced credentials, then used remote-desktop protocol software to move laterally. Once in place, they attempted to deploy their ransomeware. The target's End-point Detection and Response (EDR) solution quarantined the ransomware, so Akira scanned the network and found the unsecured camera, from which they successfully deployed the ransomware.

This raises a few questions:

• Why was the camera unsecured? Details are limited, but web-enabled cameras need to be patched in the same way that other items are. If the device can no longer be updated, the most-secure next move is to replace it, but failing that, wall it off.
• Related, why didn;t the EDR solution include the camera? Clearly, the EDR was capable of recognizing the ransomeware, so this seems like a missed opportunity to head oiff this attack.
• Did the camera need to be on the same network as the data server housing the target's corporate data? Internet of Things devices often can be relegated to their own network. If they can't be, monitoring their traffic seems like an obvious step. Here, the threat actor made had to increase the ammount of traffic between the camera and the servers, presenting an opportunity to discover the attack, but the camera's traffic wasn't being monitored. Similarly, it looks like Akira had to use the camera to connecct to end points that it didn't normally connect with, meaning that monitoring of the volume or type of communicationf wiht the camera, or the devices with which it communicated, would have revelaed the attack.

What all of this boils down to is: Zero Trust. All of the traffic accociated with this camera seems to have been trusted implicitly. As an industry, many of us are being slow to move from an implicit trust (or allow) to an implicit suspicion (or deny) among the components of our networks. The reasons are the usual, including inertia, financial and labor costs, lack of will from above, and the need to accommodate legacy components; but the costs only go up.

And what have you been up to, Mr B?

Long, time, no see, and what have you been up to? Rather a lot, really, and I'm proud of my accomplishments.

I completed CS50x, a programming class, which includes basic knowledge of C, Python, SQL, and web design; including a final project that runs a grading web application, titled Mascarra. The application allows logged-in faculty members to pull up images of students in the classes they teach, either by generating an alphabetized photo directory or by returning the image and class info for a student selected from a drop-down list. It then enables grading of student groups along several metrics, one of which applies equally to all members of the group, the others of which apply individually. One metric is attendance; if a student is absent, the app zeroes out their other metrics for the session, even if the faculty member forgets to. All of the data is then written back to the spreadsheet for export to an LMS. It's not gorgeous (I spent my time on making it functional, not on making it pretty), but for a single-person's work, I'm pretty happy with it. Submitting it for grading included the creation of an explanatory video: https://www.youtube.com/watch?v=GoA0LZsxAZM. I'm currently waiting to see if the application can be brought inside our intranet at work, which would simplify a lot of the security aspects of the build, or if I'll have to deploy it myself, pwerhaops on AWS Elastic Beanstalk.

I also submitted a patent application to the United States Patent and Trademark Office. The application describes a method for demonstrating X-rays, and a model for use with the method. I won't go into the details here since the application is pending (and likely will be for about a year and a half - that seems to be the standard turn-around time.) I may have another application to write up for a type of pliers - that's still in the research phase; we'll see what happens.

And, of course, there's the full time job, and the part time job, and that fussy little things commonly called life. So: no, not slacking off. More to report soon.

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