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
    • nessus -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

I’m just getting started with creating my own virtual environment so that I can start figuring out Nessus, WebInspect, Nmap, and several other scanning tools.  This is the process I followed to setup a bare-bones (no GUI) Debian 5 linux system.

Download ISO

1. Download the 8MB .iso image – mini.iso

Create and Configure VM

1. File > New > Virtual Machine
2. Custom, Next
3. Choose desired workstation compatibility (e.g., Workstation 5)
4. Installer disc image file (.iso), locate downloaded .iso from step 1
5. Guest OS – Linux
6. Version – Other 2.6.x kernel, Next
7. Enter desired VM name and location for VM
8. Select number of processors (e.g., 1)
9. Select memory to allocate, 256MB should be plenty, Next
10. Choose desired network connection (because of my location on my network I chose NAT), Next
11. I/O Adapter type, leave default (LSI Logic), Next
12. Create a new virtual disk, Next
13. Virtual Disk Type – SCSI
14. Max disk size 8GB (I chose to split into 2GB chunks, but it’s up to you), Next
15. Name disk file or leave default, Next
16. Check ‘Power on this virtual machine when finished’, Finish

Install and Configure OS

1. You must be connected to the internet for this installation
2. Choose Advanced options, hit enter
3. Choose Expert install, hit enter
4. Choose language – default (highlighted), enter
5. Choose country – default (highlighted), enter
6. Choose locale – default (highlighted), enter
7. Choose other locales – hit ‘tab’, and then enter
8. Choose keyboard – default (highlighted), enter
9. Choose keymap – default (highlighted), enter
10. Detect network hardware – default (highlighted)
11. Start PC card – default (highlighted)
12. PCMCIA (should be blank) – tab and then enter
13. Detect network hardware  – default (highlighted)
14. Config network – default (highlighted)
15. Primary network – default (highlighted)
16. Auto DHCP – choose YES
17. Hostname – name it what ever you like, tab and then enter
18. Domain name (should be blank) – hit tab then enter
19. Choose mirror – default (highlighted)
20. Protocol for file download – default (highlighted)
21. Debian archive mirror country – default (highlighted)
22. Debain archive mirror – choose whatever one is possibly closest to you
23. HTTP Proxy (should be blank, unless you’re behind a proxy) – tab then enter
24. Debian version to install – default (highlighted)
25. Download installer components – default (highlighted)
26. Installer components to load (choose nothing, should be default) – tab then enter
27. Configure the clock – default (highlighted)
28. Set clock using NTP  – default (highlighted)
29. NTP server to use – default, hit tab then enter
30. Select your timezone, enter
31. Detect disks – default (highlighted), enter
32. Partition disks – default (highlighted), enter
33. Partition method – choose ‘Guided – use entire disk’, enter
34. Select disk to partition – default (highlighted), enter
35. Partitioning scheme – default (highlighted, unless you’d prefer something else), enter
36. Partition overview – default (highlighted), enter
37. Write changes to disks – choose yes
38. Install base system – default (highlighted)
39. Kernel to install – choose linux-image desired (at the time of this I’ve chosen -2.6.26-2-686)
40. Drivers to include in the intitrd – default (highlighted)
41. Setup users and pass – default (highlighted)
42. Enable shadow pass – default (highlighted)
43. Allow login as root – default (highlighted)
44. Root pass, tab and then enter
45. Confirm root pass, tab and then enter
46. Normal user account – choose no and then enter
47. Configure the pack manager – default (highlighted)
48. Use non-free software – default (highlighted)
49. Use contrib software – default (highlighted)
50. Services to use – default, tab then enter
51. Select and install software – default (highlighted)
52. participate in package usage – default (highlighted)
53. Choose software to install – choose nothing (deselect selected), tab and then enter
54. Install the Grub boot loader – default (highlighted)
55. Install Grub 2 – default (highlighted)
56. Install the Grub boot loader to master boot record – default (highlighted)
57. Grub password (should be blank) – tab and then enter
58. Finish the installation – default (highlighted)
59. System clock set to UTC – default (highlighted)
60. Installation is complete – default (highlighted)
61. System reboots

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

I’d like to keep track of my experiences and record the knowledge I gain as I start exploring the world of IT security more in depth.  I do not claim to be an expert on any of the topics I introduce here; but welcome any further insights or questions from anyone who takes the time to visit El Blog de Seguridad.

I hope this can become some sort of a digital resume to help display the experience I gain working with and researching IT security.  I’d like to set a public goal of publishing here at least once a week (so bug me if you don’t see anything newer than a week).