I’ve been thinking a lot about how I’d really like to help those around me have a better understanding of internet/computer security.  Here are some common and simple things to keep in mind.  Please let me know in the comments if there’s anything that isn’t terribly clear.

Maximumpcguides.com offers a very easy-to-follow guide on opening a port in Windows 7′s firewall.  I had thought that simply setting up a service to run and making sure that that service was listed as “approved” in the firewall, as well as making sure my router had the port open that I would be good to go.  Sadly it was not that simple.  One tool that helped me realize that this was the problem was uTorrent’s port checker URL: http://www.utorrent.com/testport?port=80.  Simply change the port number at the end of the URL to test if the port is open on your firewall.  If it isn’t, follow the above guide.

Here are the steps I followed, in case the above mentioned guide becomes unavailable:

1. Browse to the Advanced Settings of the Windows Firewall
2. Select Inbound Rules in the left column
3. Select New Rule in the right column
4. Select Port in the rule wizard
5. List the port(s) that you want opened
6. Select Allow the Connection
7. Specify where you would like the rule applied
8. Name the rule and click Finish.

I have an Eee PC 1000HA and have been wanting to get more familiar with Backtrack.  I was tempted to just wipe out the drive completely and run pure BackTrack, but that would probably be less effective for my wife who shares the laptop with me.

The box touts 160GB total, but that’s inflated by 20Gb (not to mention the wrong calculation of GB – 160,000,000,000 Bytes (what retailers say is 160 GB) is really only 149 GigaBytes).  The break down of partitions ends up being

1. 80 GB for the main partition, with XP installed on it
2. 60 GB as an empty partition
3. 9 GB as the emergency recovery drive
4. 41 MB as something unidentifiable – I’m assuming this is just leftovers that didn’t fit somewhere

The tutorial on offensive-security.com showed the capability of choosing a guided-partition resize option, that let you drag a little bar to tell it how much space you wanted allocated for the install.  Well, all i got was either an option to format the whole hard drive or manually edit the partition tables.  I ended up taking the crash course in hard drive partitioning.

I figured I’d install Backtrack on part of the 60GB and freaked out when I sized it to 40GB, that the other 20GB became unusable.  After doing some research I found that I could easily extend the 40GB partition to fill up the 20GB, but with there being already 4 primary partitions, I couldn’t split it up, at least with the GUI provided.  So I went with a 60GB BackTrack partition with 1GB of swap memory.

So the final distribution ends up being 80GB for windows, 10GB for the emergency recovery, 59GB, about 1GB for swap.  I created a logical partition for the swap since it didn’t matter.

On the last stage of the installation, under the Advanced menu I left the boot loader device selection at default (hd0).

In theory, this should work.  But it didn’t for me (I got a little excited and posted this before I actually rebooted my computer).  The Grub boot loader never displayed on start-up.

What did end up working was to copy the /boot and /casper directories to my main hard drive and install Grub for windows (with some changes to the boot.ini and BackTrack menu.lst file).  Check out John’s very clear description here (written for BackTrack 4 Pre-Final, but it worked for me with the final release of 4).

To better understand what scanning tools are looking for I’ve been doing some research on Cross Site Scripting (XSS) and Injection exploits (SQL and Command to be covered in a future post). The types of XSS I’ve run across are reflected and stored – with numerous variations of each.

Reflected XSS

According to OWASP.org:

Reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server.

Stored XSS

From the same article, OWASP.org:

Stored attacks are those where the injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information.

Countermeasures

One of the most important countermeasures for XSS and many other vulnerabilities is data validation.  If you let users enter whatever they want to in your web app, they will, and you and your users will be adversely affected by it.  I won’t copy down all the countermeasures, but here are some sites with useful info:

• OWASP XSS Prevention Cheat Sheet

Hands-on Practice

I used IronGeek’s Mutillidae and OWASP’s WebGoat to gain a better understanding of what XSS is and how to safeguard against it.  Mutillidae is a lot simpler and straight forward (though you’ll need something like XAMPP to get it started), I’d suggest using it first and then WebGoat (downloads with Tomcat and Java – all you have to do is launch a .bat file) won’t be as perplexing.

RSnake provides a quite comprehensive list of the numerous ways XSS can be executed in his XSS Cheat Sheet (all examples use the generic alert(XSS!); example, but you can easily exercise your imagination a little bit).

I was given a nessusrc file to run with and not much explanation.  I was able to successfully run a few scans, but nothing too exciting came from them.  I thought (naively) that if I were to install some vulnerable webapps on the VM (Mutillidae or Damn Vulnerable Web App) I would get some more interesting results; of course I was wrong.  I figured it probably had something to do with the plugins that were running and other settings defined in the nessusrc file, so this is my attempt at explaining what I find.

Renaud was kind enough to reply to someone else’s question on the same topic.  He described the sections of the nessusrc file as follows:

SERVER_PREFS: these are the options which are sent back to the nessus daemon. They are all documented on the nessusd side – see /usr/local/etc/nessus/nessusd.conf

SCANNER_SET: the list of port scanners that are enabled by the user. You can merge this section within PLUGIN_SET, because scanners are plugins

PLUGIN_SET (currently absent in my file): the list of plugins which are enabled/disabled. The format is <id> = [yes|no].

SERVER_INFO: is un-necessary, it simply contains information about the last nessusd you connected to (this is used for XML export)

PLUGINS_PREFS: acts like the SERVER_PREFS section, except that very few options are thoroughly documented. However the most important ones (like SMB password) should be self-explanatory.

He also points us to update-nessusrc, which is a Perl script written to simplify the loading of plugins in your scans.  The script is dependent on several Perl modules, some of which are not included in the base Perl package.  TheGeekStuff.com provided a guide that helped me get through manually installing the necessary modules I was missing.  (Beware if you have just installed the basic Perl module, you will be missing some modules that the ones listed as requirements for update-nessusrc are dependent on – HTML-Parser, HTML-TagSet, URI, and possibly a few others.)

For those new to Perl, when configuring the update-nessusrc script to work with your setup, make sure you enclose the host address, user_name, and user_pass in single quotes.  Not enclosing them in quotes got me a “open_sock_opt_hn: invalid socket address” error and an hour of searching for what that meant.

I realize Nessus is currently up to version 4 with a GUI and will probably play with that at a future date.  So I’m not sure how useful this install info will be to anybody but me.

Download

Download the following 4 packages from nessus.org, selecting Nessus 2.2.11 source code from the drop-down menu, accepting the user license.

• nessus-libraries-2.2.11.tar.gz (418 KB)
• nessus-plugins-2.2.11.tar.gz (7468 KB)
• nessus-core-2.2.11.tar.gz (664 KB)
• libnasl-2.2.11.tar.gz (359 KB)

Setup

1. Copy files to desired directory (using your favorite SFTP/SCP client) e.g., /home/nessus
2. Extract using ‘tar zxf [filename]‘
3. Run the following commands to make sure the correct directories are in your $PATH
   • echo “/usr/local/bin” >> /etc/ld.so.conf
   • echo “/usr/local/sbin” >> /etc/ld.so.conf
   • echo “/usr/local/lib” >> /etc/ld.so.conf
   • ldconfig
4. Make sure the following packages are installed
   • libc6-dev
   • openssl
   • libssl-dev
   • flex
   • bison
   • make
5. Navigate to the nessus-libraries directory and run the following as root (waiting for each to complete)
   • ./configure
   • make
   • make install
6. Repeat commands in step5 inside the libnasl directory
7. Change to the nessus-core directory and run
   • ./configure –disable-dtk (this makes it so you can only run nessus from the command line, ideal for the environment setup earlier)
   • make
   • make install
8. Change to the nessus-plugins directory and run
   • ./configure
   • make
   • make install
9. Run “/usr/local/sbin/nessus-mkcert” accepting all the default values
10. Setup Nessus user account
    • Run “/usr/local/sbin/nessus-adduser”
    • Enter a user name
    • Enter “pass” and create a password for the user
    • To set no limits with the rules use: “default accept” (if you wish to restrict certain IP ranges use something like “accept 192.168.0.0/24″ [press enter] “default deny” – this will only allow the user to run nessus on the 192.168.0.0/24 subnet, only 255 addresses, making the default rule for any other address “deny”)
11. Startup the Nessus server before you start any scans
    • nessusd -D -a 127.0.0.1

An example of a command to get you started (and I’m still starting, so I won’t expound much more) is

• nessus -q 127.0.0.1 1241 [Nessus_Username] [Nessus_Username_pass] /home/nessus/target.list /home/nessus/results.nbe -T nbe -V -c /root/.nessusrc
  • target.list contains a list of comma separated IP addresses
  • results.nbe is where the results will be stored
  • nbe is the format type (you can also use html and a few other types)
  • .nessusrc is the scan policy you use that tells nessus what to do (I haven’t got too much into how this file works yet, but plan to investigate it further)
  • run “nessus –help” if you have more questions on the structure of the command

Scanning tools are useful both to hackers and system administrators.  At work we’ll be using a tool called Discovery and Dependency Mapping which basically scans the entire network and gathers information on all the devices on the network and their dependency on eachother.  This is probably a little more advanced than Nmap, but a real-life example of sys. admins wanting to know what’s on the network.

Nmap is a very useful, free scanning utility.  The first objective is to find out what hosts are out on a network.  Issuing the command “nmap -sP 192.168.100.*” would bring back all the hosts on the 192.168.100.0 network.

example of using nmap -sP

The next step is to stack fingerprint the network using the command “nmap -sT 192.168.100.102″:

nmap -sT

To see what Nmap is doing, you can use Wireshark to capture the packets that go to and from the target computer.  Here’s an example of nmap hitting port 80 on the target computer:

This command (nmap -sT) shows you the ports open on the target system, as well as the services running on those ports.  This can help you identify what operating system the computer is running which allow you to probe deeper and find out, for example, the type of server and version.  If you’re worried about your scan showing up on the target computer’s logs (as evident in the three-way handshake completed when identifying port 80 as open in the above image), you can do a stealth mode scan with “nmap -sS x.x.x.x”.

Running the command “nmap -O x.x.x.x” will have Nmap guess the operating system on the machine.  I didn’t have much success with that command (from the command line), but using the GUI and command “nmap -T4 –version-light -sV -F -O 192.168.100.102″, it guessed the OS as Windows along with a list of possible versions.

Nmap GUI

Network traffic generated from using Nmap, shown by its signature, can be very detectable.  Nmap can be configured to mask its signature from being easily detected.

The three-way handshake is the process by which two computers create a reliable connection to eachother using TCP (Transmission Control Protocol).  The computer requesting the connection sends out a synchronize packet (SYN), when the second computer receives this packet it responds by sending a synchronize packet and an acknowledgement packet (SYN/ACK).  When the initiating computer receives the acknowledgement from the requested computer, it then sends an ACK packet as well, completing the three-way handshake.  There now exists an open-communication channel between the two computers until one issues a “FIN” or “RST” packet or the connection times out.

This is a very important concept in IT security, and it is also very exploitable.  When you think about it, the requesting computer is making sure it is connecting to the right computer before completing the connection.  What happens if someone intercepts the SYN packet (disguised as the designated computer) and sends a spoofed SYN/ACK and the requestor then completes the connection thinking it’s connected to the desired computer?  Or someone can listen in on the connection you’ve made (if it isn’t secure) and disguise information/malware to look like it came from the computer you’re talking to.

Another vulnerability occurs when someone maliciously sends out a flood of SYN packets from a spoofed IP address to a server, causing the server to consume large amounts of resources trying to keep up with these malicious packets.  This is a form of a denial-of-service attack (DoS).  This vulnerability is less of a worry with modern networks.

Sources: wikipedia, Computer Security Lab Manual

Ping is a tool used to check the connectivity of a certain host, using ICMP (Internet Control Message Protocol).  At the command line you can ping an IP address or domain name and see how long the target takes to respond.  When this happens, ARP (Address Resolution Protocol) resolves the domain name or IP address to the target’s MAC (Media Access Control) address.  Displayed below is an example of how this works.  Once an address is pinged, it’s resolved MAC address is written to the ARP cache, which can be displayed using the “arp -a” command.

The tricky part comes in figuring out if that is really the correct MAC address for the target computer.  If you’re trying to identify someone who has tried to access your network illegally, they most likely used ARP spoofing.  More on this later…

The following are a few tools of which I am currently aware.  I’ve used some, and plan to dive deeper into each of them, and hopefully discover others along the way.  I’ll republish this list as I get further along.

1. Backtrack – live CD, combination of Auditor and WHAX, tons of security/forensics tools
2. Helix – live CD, can also run as an application in Windows, forensic tools
3. SecurityDistro – more live CD’s with loads of security tools
4. WebGoat – a tutorial on web security
5. p0f – OS fingerprinting tool, for profiling your targets
6. MetaSploit – ” useful information to people who perform penetration testing, IDS signature development, and exploit research”
7. KeePass – “a free open source password manager, which helps you to manage your passwords in a secure way”
8. Wigle.net – Wireless Geographic Logging Engine