One of my favorite tools for penetration testing is Nessus from Tenable Network Security. Nessus 5 is the latest release in the family of vulnerability scanners that is probably amongst the most prolific. Nessus 5 does discovery, configuration auditing, profiling, looks at patch management and performs vulnerability analysis on a variety of platforms. Nessus can also run on a Linux, Windows or Mac OS X and can be used to scan and keep track of vulnerabilities for practically any platform, including Mac OS X.
To install Nessus, go to the Nessus site and click on the Download button, around the middle of the page. Agree to the download agreement and then choose the version that is right for you (Mac OS X in this case).
The software will then download and need to be installed. Once downloaded, open the Nessus dmg and extract it. Inside will be the Nessus 5 package installer.
Open the installer and click through the defaults to perform a basic installation.
Once done, you’ll have the Nessus Server Manager and Nessus Client.url in a Nessus folder in the Applications directory.
Open the Nessus Server Manager and authenticate as an administrator when prompted. When you downloaded the software you would have been prompted for registration. Provide that information in the registration field. Then click on Update plugins to make sure all of the Nessus plugins are running the latest version. Finally, click on Manager Users… to create your users.
At the list of Nessus users, click on the plus sign and create a new user, likely making the user an admin (I see few vulnerability scanning stations that have non-administrative users, which would just be for viewing reports and the such). Click Save to create the user and then close at the List of users screen.
If the Nessus server isn’t started, click on Start Nessus Server. Then click on the Nessus Client.url file back where the Nessus Server manager was accessed. At the Nessus login screen, provide the username and password for the Nessus server that was previously created.
Once authenticated, you will be placed in the Scans screen. Before we configure any scans, we’re first going to create a Policy (which defines how a scan operates for the most part). To do so, click on Policies and then click on the Add button. There are four policy tabs (aligned on the left sidebar). In the General pane, you will configure the name for the Policy, “Mac Servers” in this example. Then we’re going to check the boxes in the Scan section for Designate Hosts by their DNS Name, Log Scan Details to Server, Stop Host Scan on Disconnect and Avoid Sequential Scans. Then check the boxes in the Port Scanners section for TCP, SYN, SNMP, Netstat SSH and Ping Host. Leave the Port Scan Range set to default and the Performance options at their default values as well. These are useful when you’re done tinkerating to get better performance out of the system, but we’re not really there just yet.
Click on the Next button to define any credentials you’ll use during scans. Initially, I’d leave this blank, although you can provide SMB information for up to 4 accounts to see what kind of access users have. You can also define Kerberos, SSH and various cleartext credentials as well. We’re going to skip that for now and click Next to define the Plugins.
At the Plugins screen, we’re initially going to leave all of the plugins on. The reason for this is that many of the Lion Server services are similar to those of the various Unix and Linux variants and we can scan SMB with the Windows plugins. These can’t hurt, they might just waste a little time though. Clicking on a Family and then a plugin will show you what each does. Clicking on the green light for each will disable it.
Click on Preferences and define any preferences that you need. Amongst the plugin preferences I usually enable network printer scanning, CGI scanning, Enable experimental scripts, set my Report verbosity to Verbose, provide any certificates needed and then hit Submit to create the new Policy.
Next, let’s click back on Scans in the navigation bar on the screen. As you can see here, I’ve created a few template scans, but we’re going to create a new one by clicking on the Add button.
Provide a name for the scan and then choose the Policy you just created. Set the Type to Run Now (since we’re just testing) and put the IP address of a target into the Scan Targets field. You can also import a large set of targets using the Brows button and a csv file or use Schedule or Template rather than Run Now in the Type field to schedule scans or create a template scan. Click Launch to kick off the first scan.
Once started, click on the Reports button in the top nav bar to see the status of the scan.
Once the scan is finished, click on the scan to see a list of vulnerabilities and open ports, sorted by the severity of issues. Here, double-click on the host.
The Report screen then shows each service and the vulnerabilities found for that service. Click on one of the vulnerabilities to see what Nessus thinks is problematic with it.
Now for the fun part. Each of the vulnerabilities listed will have CVEs attached.
By default, Nessus is just looking at the service banners to determine vulnerabilities. If you look up the CVE at CVE Details or PacketStorm you’ll see that it was patched a few months ago by most vendors. Now Nessus can get things wrong with Mac OS X. The issue is that Apple forks the code for many open source projects, not always updating version numbers on banners. Looking up or testing whether a vulnerability is still applicable can be tedious but would likely need to be done per service according to your internal security policies.
An easy way to test these vulnerabilities is to use Metasploit, a tool I’m long overdue to write an article on. Another way is to try and run the exploit against the host. Apple does a pretty good job of addressing CVEs in their security updates, so don’t waste a lot of time trying things if Apple has already patched them. I have found a really good tool for automatically attempting to exploit via msf + nessus to be Carlos Perez’ auto exploit tool, available on github.
Finally, Nessus is a great tool for scripting. One of the big differences that throws off many an experienced Nessus operator off with the version for the Mac is the location of the Nessus binaries. They are in /Library/Nessus/run/bin. In here you’ll find nasal, nessus, nessus-fetch, nessuscmd etc. The command line control here is pretty awesome. Let’s run nessuscmd to scan a net mask of hosts (192.168.210.0/24):
sudo /Library/Nessus/run/bin/nessuscmd 192.168.210.0/24
There are tons of other options for nessuscmd, such as adding ssh keys, smb logins, scanner options, using a remote nessus server, etc. Or use the nessus binary to kick off scans using a nessus config file. The nessus.conf file is also stored in the /Library/Nessus/run/etc/nessus directory, worth looking into.
krypted February 23rd, 2012
I am getting so sick and tired of seeing brute force attempts against SSH traffic. Let’s just change the port that it listens on and then miraculously watch all those brute force attempts disappear. There are a few different ways to go about this in Mac OS X.
The first is to just change the port entries in /etc/services (mileage may vary). To do so open /etc/services in your favorite text editor and look for the lines that begin with ssh. These should look something like the following:
# Jon Postel
ssh 22/udp # SSH Remote Login Protocol
ssh 22/tcp # SSH Remote Login Protocol
# Tatu Ylonen
Just change the 22 to something else, like 2020 or even something that won’t be blocked by many firewalls like 80 or 443 (stateful or deep packet inspection notwithstanding) provided that those ports aren’t already in use. Now restart ssh and you should be listening on your new port (port scan to verify). You can then scan your localhost (127.0.0.1) and verify that you’re listening on the correct port.
That’s the most popular way to do this going back to the beginning of time, but Apple can just change things whenever they like in an OS update and blow out your SSH connectivity (given that /etc/services isn’t protected from such a thing). Therefore, you can also do this using launchd. To do so you’ll look at /System/Library/LaunchDaemons/ssh.plist. You can copy this to /Library/LaunchDaemons and rename it to something like CustomSSH.plist, providing a new label and SockServiceName. If you wanted to stick with port 443 you could do the SockServiceName of https. If you choose to go this route, the next step would be to load your new LaunchDaemon and then check that it is working (unloading your old sshd listener in the process). Oh, and you can remove the Bonjour key from listeners as well if you don’t want it out there…
If you are simply trying to protect against external threats and not internal then another method would be to remove access to SSH on the organization’s border firewall. Oh wait, many can’t do that. So then you could simply do a port redirect on the firewall appliance. Basically you would route port 443 to port 22 on the internal LAN for the IP in question. This is pretty basic and supported in even prosumer types of appliances these days. This would effectively make the traffic look like https traffic to the outside world and when you are behind the firewall it would be port 22.
These steps do not remove the need to edit sudoers and other steps many use to secure SSH, they’re just here to change the port so that the logs can show fewer invalid attempts.
krypted October 21st, 2010
Posted In: Mac Security
All 3 of the Snow Leopard titles I’m working on, editing or in one case done with for Apress are now posted to Amazon and can be purchased.
krypted September 21st, 2009
I’ve been asked by a number of people whether or not we will be updating the Mac OS X security book I did a couple of years ago for Apress to Snow Leopard. The answer is yes. We are currently working on the updates and hope to have it available by December. The book will undergo a number of changes/improvements, as all second editions should. I’ll update when it’s available on Amazon & of course, in stores.
krypted August 22nd, 2009
The two primary aspects of time setup are typically setting the time zone and setting the Network Time Protocol (NTP) server. The systemsetup command can be used to set both of these date and time options for Mac OS X computers. To see a listing of the available time zones in Mac OS X use the systemsetup with the -listtimezones option as follows:
Once you have the time zones you can then use systemsetup with the -settimezone option to configure the time zone on your system. It is often easiest to simply paste the time zone into the command. So to set the time zone to Detroit for example, you would use the following command:
systemsetup -settimezone America/Detroit
systemsetup -setusingnetworktime on
systemsetup -setnetworktimeserver ntp.krypted.com
systemsetup -setdate 07:12:09
systemsetup -settime 11:30:00
krypted July 13th, 2009