Demystifying the Command Line

The command line can be a confusing place. There is lots of black space and no where to click. This post is my attempt to at least partially demystify the command line. I realize this can be an intimidating tool. Powerful tools will always seem more difficult when you first adopt them.

Let's start with a simple PowerShell example to create a user account.

New-ADUser clark.kent -surname "Kent" -givenname "Clark" -displayname "Clark Kent"

I want to break this command into components. The first component is "New-ADUser". This is the command to be executed. In PowerShell, this is referred to as a PowerShell Cmdlet (pronounced command-let). This is the program (or script) to be executed. A quick note about case. Windows is case-insensitive which means you can use new-aduser, NEW-ADUSER, or nEW-aduSER. All of these examples are valid.

The next component is "clark.kent". This is an argument or parameter. Arguments are either optional or required. A command may have no arguments, one argument, or multiple arguments. Whether a argument is required and the number of arguments to use is determined by the command (or cmdlet).

The final component in this example is an option. The options in the above example are "-surname", "-givenname", and "-displayname". An option is just what the name suggests, a way to provide additional information at the command line. Command line options are typically not required. Some options will require a corresponding value while others will work as a toggle (to enable or disable a certain behavior). The options above all have corresponding values. See the table below.

Option	Value
surname	Kent
givenname	Clark
displayname	Clark Kent

A side note about options. The specifier for options will vary based on the command, operating system, or environment. In PowerShell, the specifier is the dash symbol (-). In the Windows command line, it is typically the slash (/). In Linux, the dash or double dash is common (- or --).

When you are using PowerShell, you can always find help with the Get-Help cmdlet. To find help with the New-ADUser cmdlet, use "Get-Help New-ADUser". You may be able to find examples by using the -examples option (i.e. "Get-Help New-ADUser -examples").

Finally, consider the example below. Hopefully the information above allows you to better understand this more complex command.

New-ADUser –Name "Jimmy Olsen" –SamAccountName jimmy.olsen –DisplayName "Jimmy Olsen" –Title "Photojournalist" –Enabled $true –ChangePasswordAtLogon $true -AccountPassword (ConvertTo-SecureString "TheD@ilyPlan3t" -AsPlainText -force) -PassThru

Try to identify the components of this command.

This example uses PowerShell but the concepts apply to other systems. I hope this helps you to understand the command line a little better.

Downgrade VMware Virtual Hardware Version

Note: According to VMware documentation, downgrading the hardware version of your vSphere virtual machine is unsupported. 

Mastering VMware vSphere 4 By Lowe, Scott (Google Affiliate Ad)

Recently, I found myself in a pinch and needing to quickly spin up a virtual guest on an ESXi 4.1 host. Unfortunately, the only template I had available for Windows Server 2008 R2 used virtual hardware 8 which is not compatible with ESXi 4.1. The notes below describe how I was able to downgrade the hardware version on a template from 8 to 7 and deploy a guest from that template.

There are three steps to downgrade the VMware hardware version on a template.

1. Remove the template from vCenter or host inventory (be careful not to delete it from disk).
2. Edit the .vmtx file and .vmdk pointer files.
3. Add the template back to the inventory.

In order to downgrade a VM template, you need to edit two files; a vmtx file and the vmdk pointer file. The simplest way to make these changes is from an SSH session on your ESXi host (or the ESXi console). After removing the template from inventory, navigate to the directory containing the VM template and open the .vmtx file in your favorite editor (like vi). Look for this line

virtualHW.version = "8"

and change it to

virtualHW.version = "7"

Save the changes to the vmtx file and find the pointer file to the vmdk. Open it with your editor and look for this line

ddb.virtualHWVersion = "8"

and change it to

ddb.virtualHWVersion = "7"

Now save this file and exit your editor. Add the template back to the inventory and test it out by deploying a VM guest from the template.

If you found this useful or if it didn't work out, leave a comment below.

Thanks for visiting!

                     

Fake Antivirus and Firefox Cache Tools

Firefox has some pretty nifty features. One of those is the ability to view the cache contents without any extra tools. This post covers an incident with a fake antivirus popup and how I used the built in Firefox tools to confirm my suspicions.

The Story

This all started when I got a text message from my wife earlier today. This is the image she sent me:

The story goes, our daughter was using the computer and this appeared on the screen. My initial thought was this is a fake antivirus popup. However, we do have Microsoft Security Essentials (MSE) on that computer and the screen shot is convincing. Following the old saying of "you are better safe than sorry"; I told her to shut down the computer and I would look at it when I got home.

The Initial Review

Once at home, I looked more closely at this incident. First, I opened MSE to review the logs and found that nothing was detected in any previous scans (edit: MSE actually calls this History). This starts to confirm the suspicion of a fake antivirus popup.

The next step was to take the cache files from my daughter's profile and put them in a virtual machine. Since she uses Firefox, this is easy to do. If you are interested, explanations of the Firefox cache directories are here.

A quick peek at the history reveals this is definitely fake antivirus related.

The entries for detectionprotectorprocesses.in and "Viruses were found on your computer!" are dead giveaways. At this point you could stop but I will take a few more minutes to show you some of the Firefox cache exploration tools.

Firefox Cache Tools

I start the cache exploration by typing about:cache into the URL bar. This gives you the screen below which is not very useful.

Clicking on "List Cache Entries" starts to look more interesting.

This page can be searched by pressing Ctrl+F. I searched for "detectionprotectorprocesses.in".

The fifth detectionprotectorprocesses.in entry refers to a PNG image file. Clicking on that link takes us to another page, specific to the alert.PNG cache entry.

This page is filled with information. It includes HTTP server response headers and a full packet capture of the PNG image. In the center of the page is a line marked "file on disk". This gives the location on the disk where the cached image is located. I navigated to that location, copied the file to a temporary directory, and renamed it with a PNG extension.

Opening this file removes any remaining doubt about the fake antivirus popup. This recovered image perfectly matches the text message I received earlier today!

Conclusion

I suspect the popup came from the website directly prior in the browsing history, possibly from an advertisement. If that is true, it appears the problem has been remedied. I did look for some contact information on that website, but I did not locate any. I would have preferred to report this information, but I was unable to.

Firefox is a great browser. These cache tools are great for troubleshooting and fun to explore with as well. I am certain Firefox includes many more tools that I don't know about. Hopefully you found something useful in this post. Thanks for reading!

Installing Nmap 6 on BackTrack 5 R2

It turns out, getting Nmap 6 to run on BackTrack 5 R2 is actually quite simple. Follow the steps below and prepare to bask in the newness of Nmap 6.


Linux Security Cookbook by Barrett, Daniel J./ Silverman, Richard E./ (Google Affiliate Ad)

First, you need to get rid of the included Nmap which is version 5.61. Simply run this command:

apt-get -y autoremove nmap

This command should only take a few seconds to complete. Next, grab the Nmap 6 source using this command:
wget http://nmap.org/dist/nmap-6.00.tgz

The source tarball is about 22 MB so it should (hopefully) download pretty quickly. After you have the source, you need to extract it. You can do that with this command:

tar zxvf nmap-6.00.tgz

Finally, these commands will compile and install Nmap 6. If you are unfamiliar with Linux, these are standard commands for installing software from source code.

cd nmap-6.00

./configure

make

make install

Depending on your hardware, these commands make need a few minutes to complete. To check that Nmap is installed, run:
nmap -V

This command should report version information similar to this:
Nmap version 6.00 ( http://nmap.org )
Platform: x86_64-unknown-linux-gnu
Compiled with: nmap-liblua-5.1.3 nmap-libpcre-7.6 libpcap-1.0.0 nmap-libdnet-1.12 ipv6
Compiled without: openssl

Now, Nmap 6 is installed. Check out the announcement here, http://nmap.org/6. You may also want to check out my previous post on Nmap NSE scripts, http://www.marshalgraham.com/2012/05/getting-started-with-nse-nmap-scripting.html.

One thing to note regarding this installation method. During the first step, the BackTrack maintained Nmap package is removed. This means that apt-get will no longer be able to update Nmap. When a new Nmap version is released, you will need to repeat this procedure to upgrade to the current version.

Happy Nmaping!

Edit: If you want to restore the BackTrack maintained Nmap, you can. Go back to the nmap-6.00 directory and run make uninstall. Next run apt-get -y install nmap to reinstall the packaged version of Nmap.

Getting Started With NSE, The Nmap Scripting Engine

After talking with some friends last week, I realized that the Nmap Scripting Engine (NSE) is an unappreciated and underutilized Nmap component. That is unfortunate, since NSE has easily become my favorite Nmap feature. According to the Nmap 6 release notes, the number of available NSE scripts is nearly 350! This seems like a good time for a long overdue blog post. This post talks about using the built in Nmap 5 scripts. It's intended to introduce NSE and assumes at least some Nmap exposure.

Linux Security Cookbook by Barrett, Daniel J./ Silverman, Richard E./ (Google Affiliate Ad)

If you are using Backtrack 5, the NSE scripts are located in /usr/local/share/nmap/scripts/. Each file ends with a .nse extension and is plain text. The scripts cover a variety of areas including vulnerabilities, information gathering, and exploitation. If you are uncertain of what a script does, simply open it in a text editor.

I'll walk you through a few examples of using NSE scripts. The first will show running the smb-enum-shares.nse script. This script connects to a Windows or Samba file server and enumerates the shares. The syntax is:

nmap -Pn --script=smb-enum-shares 192.168.1.136

You will obviously need to replace 192.168.1.136 with the IP address of your file server. Here is the output:

You can see there are four shares: ADMIN$, C$, IPC$, and "Documents and Settings". Another simple script is http-headers which does exactly what it says, retrieves HTTP headers. Here is the syntax:

nmap -Pn -p80 --script=http-headers slashdot.org

Again, replace "slashdot.org" with the server you wish to retrieve the HTTP headers from. And here is the output:

Those are some pretty simple examples. Here is a little more complex one using smb-check-vulns.

nmap -Pn -p445 --script=smb-check-vulns 192.168.1.136

While this command may not appear more complex than the previous examples, the checks performed are more powerful. This command checks for the MS08-067 vulnerability and if the host is infected with Conficker. Here is the output:

You can try running the unsafe checks with the command below. I have had limited luck with this, usually resulting in an SMB server crash (not good in a production environment!).

nmap -Pn -p445 --script=smb-check-vulns --script-args=unsafe=1 192.168.1.136

The previous commands all demonstrated running a single NSE script. Another method of invoking scripts is to use NSE script categories. This link lists all of the available categories, http://nmap.org/book/nse-usage.html#nse-categories. One of my favorites is the broadcast category. This is a very safe category that can be run on a production network with virtually no concerns. The syntax is very similar to the previous examples:

nmap -Pn --script=broadcast

Notice how this example does not specify a target host. These scripts find hosts and services that advertise themselves to the network broadcast address. The output format looks a little different than the previous examples. Each script name will be listed followed by the script output. Warning: these scripts can output a significant amount of data! Here is some sample output:

This scan produced output from these scripts: broadcast-wpad-discover, targets-ipv6-multicast-slaac (are you sure you aren't running IPv6?), broadcast-ping, and broadcast-netbios-master-browser. Broadcast-wpad-discover only returned that it could not discover a WPAD DNS or DHCP entry.

To get an idea of what broadcast checks are performed, check the broadcast scripts in /usr/local/share/nmap/scripts/ (ls /usr/local/share/nmap/scripts/broadcast*). Here's a sampling of things I have discovered using the broadcast category: Dropbox clients, shared iTunes libraries, TiVo beacons, mDNS/Avahi/Bonjour services, MS SQL servers, UPnP capable hosts, Netbios hosts, and proxy servers (via WPAD discovery). The TiVo actually discloses the TiVo Service Number (sort of like a serial number). It seems like each time I run this script, I find a new service. While writing this article, I learned from the broadcast-upnp-info script that the Roku runs an embedded web server on TCP port 8060! However, I think the real power of the broadcast scripts is the ability to enumerate network hosts and services in virtual silence, never requiring a direction connection to the discovered host or service.

I hope you enjoyed this intro to NSE scripts. Thanks for reading!

Remote Packet Captures With Wireshark

Here's a Wireshark feature I just recently discovered. I don't know how long it's been available but I believe it's fairly new. It is listed as experimental in WinPcap so YMMV.

If you have ever needed to do a remote packet capture you know it can be painful. It usually requires that you to go to the remote system or switch. You probably have to configure a mirrored port or install a hub inline. If you are lucky, you can get someone at the remote end to do this for you. In either case, it seems like it takes longer than it should. With Wireshark 1.6.2 and WinPcap 4.1.2 you can make this a much simpler task. Use the simple diagram below as a guide. In this example, we want to capture packets from the remote host with IP address 172.16.10.50.

Start by installing WinPcap on the machine you would like to capture packets from. This is probably a good time to note that this only works on Windows. After WinPcap is installed, drop to a command prompt (elevated command prompt in Vista/7/2008/2008R2).  Change directories to C:\Program Files\WinPcap or C:\Program Files (x86)\WinPcap. Run "rpcapd.exe -s rpcapd.ini -l 172.16.5.20" and then press Ctrl+C. Remember, 172.16.5.20 is the Wireshark computer. This creates the rpcapd.ini file necessary to run as a service. Next open rpcpad.ini in notepad.

This next part may be a little controversial. In order to connect, you need to disable username/password authentication. According to winpcap.org, username/password authentication is possible however I have not been able to locate any documentation on how to configure it. I have also asked on the winpcap-users mailing list. If you know the answer to this, drop me a line. Once I have this problem solved, I will update this post to enforce authentication. For additional security, you should disable the rpcapd service or uninstall WinPcap when you are finished with your capture.

With that out of the way, go back to notepad. Change the line NullAuthPermit = NO to NullAuthPermit = YES. Close notepad and run "net start rpcapd" to start the "Remote Packet Capture Protocol v.0 (experimental)" service. We are now done with the remote system.



Go to your computer with Wireshark installed and open Wireshark. Click Capture->Options.


Click the drop down arrow next to Interface and choose Remote.


Enter 172.16.10.50 (your remote capture machine) and 2002 for the port. Choose Null Authentication and click OK.



Next, just click Start to begin your packet capture. Wireshark behaves exactly as if you were capturing packets locally. By default, Wireshark ignores the RPCAP traffic. You might want to a make a copy of your rpcapd.ini file. If you need to do more caputres in the future, you can install WinPcap, copy your rpcap.ini file to a host, and start the rpcapd service.

As always, feel free to leave comments below and drop me a note if you found this useful.