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