Saturday, 3 September 2011

Practicing scanning and basic enumeration skills with a Solaris VM

I'm pretty comfortable hacking-around with Linux, Windows and Macs, but one of the platforms I have not used much (so far) is Solaris.

I love learning new things, so this seemed like a gap worth filling, especially as I am looking to take the Check CRT certification (in which Solaris/Oracle are a small part of the syllabus).

I had a bit of a play with OpenSolaris a while back, which gave me a flavor of some of the differences between Linux an Solaris (incidentally the OpenSolaris project seems to be stalled/ending?).

Anyway, I thought I would download the Solaris/Oracle VMs from from the following location and have a play (starting with some basic scanning):

http://www.oracle.com/technetwork/server-storage/solaris/solaris-vm-405695.html

(You need to register with Oracle to download these images)


Setting up a Solaris box

Once the Solaris10_9-10_VM.zip image is downloaded, unpack it with:

unzip Solaris10_9-10_VM.zip

Start VirtualBox, and import the appliance with:

File > Import > select the *.ovf file (and follow the rest of the menu)

Once this is imported you can start the VM and you will get to the following Solaris setup menu.


(Use F2 and F4 to continue through the menus)

Work through these menus, and in around 20 minutes you will be able to login, and will have a working Solaris system:
(Mmmm... lovely; dull grey and purple)


Managing services

Solaris services are managed differently from services in Linux, by using the "svcadm" tool.
So to go ahead and setup some extra services and scan the system:

To set up an apache webserver:

cd /etc/apache2
cp httpd.conf-example httpd.conf

svcadm -v enable /network/http:apache2

.. and check it's running:

svcs -p /network/http:apache2
STATE          STIME    FMRI
online         10:51:52 svc:/network/http:apache2
               10:51:52     1991 httpd
               10:51:53     1992 httpd
               10:51:53     1993 httpd
               10:51:53     1994 httpd
               10:51:53     1995 httpd
               10:51:53     1996 httpd

Let's also start some other (unnecessary and potentially insecure) services, to expand our target a bit:

svcadm enable network/telnet
svcadm enable network/ftp
svcadm enable network/finger


Scanning with nmap

First lets try a basic scan:


nmap 192.168.1.69


Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2011-08-29 19:28 BST
Nmap scan report for 192.168.1.69
Host is up (0.00052s latency).
Not shown: 994 closed ports
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
23/tcp  open  telnet
79/tcp  open  finger
80/tcp  open  http
111/tcp open  rpcbind
MAC Address: 08:00:27:33:49:19 (Cadmus Computer Systems)


Nmap done: 1 IP address (1 host up) scanned in 27.71 seconds


So we can see the services I added there, also it looks like ssh (and rpcbind) had been enabled by default.

Now for a more thorough scan using the NSE scripts


nmap --script all 192.168.1.69


Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2011-08-29 19:23 BST
Nmap scan report for 192.168.1.69
Host is up (0.0010s latency).
Not shown: 994 closed ports
PORT    STATE SERVICE
21/tcp  open  ftp
|_ftp-bounce: no banner
22/tcp  open  ssh
|_banner: SSH-2.0-Sun_SSH_1.1.3
| ssh-hostkey: 1024 78:af:4e:c7:67:0e:18:9b:da:77:c4:6d:c0:a7:1b:7d (DSA)
|_1024 a5:92:ed:16:f5:fc:26:8b:18:d4:5e:b5:9d:0c:21:3b (RSA)
23/tcp  open  telnet
79/tcp  open  finger
80/tcp  open  http
| http-brute:   
|_  ERROR: No path was specified (see http-brute.path)
|_citrix-brute-xml: FAILED: No domain specified (use ntdomain argument)
| http-methods: Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html
|_http-trace: TRACE is enabled
|_http-date: Mon, 29 Aug 2011 18:24:32 GMT; +1s from local time.
| http-headers: 
|   Date: Mon, 29 Aug 2011 18:24:34 GMT
|   Server: Apache/2.0.63 (Unix) DAV/2
|   Content-Location: index.html.en
|   Vary: negotiate,accept-language,accept-charset
|   TCN: choice
|   Last-Modified: Sun, 21 Nov 2004 14:35:21 GMT
|   ETag: "4614-5b0-a64a7c40;462a-961-a64a7c40"
|   Accept-Ranges: bytes
|   Content-Length: 1456
|   Connection: close
|   Content-Type: text/html
|   Content-Language: en
|   
|_  (Request type: HEAD)
| http-form-brute: 
|_  ERROR: No passvar was specified (see http-form-brute.passvar)
|_http-title: Test Page for Apache Installation
|_http-wp-plugins: nothing found amongst the 100 most popular plugins, use --script-arg http-wp-plugins.search= for deeper analysis)
| http-domino-enum-passwords:   
|_  ERROR: No valid credentials were found (see domino-enum-passwords.username and domino-enum-passwords.password)
111/tcp open  rpcbind
MAC Address: 08:00:27:33:49:19 (Cadmus Computer Systems)


Host script results:
|_dns-brute: Can't guess domain of "192.168.1.69"; use dns-brute.domain script argument.
|_path-mtu: PMTU == 1500
|_ipidseq: Unknown
| qscan: 
| PORT  FAMILY  MEAN (us)  STDDEV   LOSS (%)
| 1     0       732.20     508.23   0.0%
| 21    0       1143.80    853.92   0.0%
| 22    1       1236.80    734.74   0.0%
| 23    1       1248.10    782.83   0.0%
| 79    0       1065.30    794.20   0.0%
| 80    1       1297.50    742.94   0.0%
|_111   1       1577.30    1092.91  0.0%


Nmap done: 1 IP address (1 host up) scanned in 118.38 seconds

That didn't find a great deal extra except that the TRACE option is also enabled, which means that XST (cross-site tracing, a client-side attack) is potentially possible against old browser versions (though this attack is no-longer possible against the majority of modern browsers).

The SSH banner also reveals that we have a Solaris system.



Scanning with Nikto

We can scan the webserver with Nikto using the following command:

./nikto.pl -host 192.168.1.69
- Nikto v2.1.4                                                                                                                                                                                                                    
---------------------------------------------------------------------------                                                                                                                                                      
+ Target IP:          192.168.1.69                                                                                                                                                                                                
+ Target Hostname:    192.168.1.69                                                                                                                                                                                                
+ Target Port:        80                                                                                                                                                                                                          
+ Start Time:         2011-08-30 19:59:48                                                                                                                                                                                        
---------------------------------------------------------------------------                                                                                                                                                      
+ Server: Apache/2.0.63 (Unix) DAV/2                                                                                                                                                                                              
+ Apache/2.0.63 appears to be outdated (current is at least Apache/2.2.17). Apache 1.3.42 (final release) and 2.0.64 are also current.                                                                                           
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE                                                                                                                                                                          
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST                                                                                                                                                
+ OSVDB-2117: /: Appears to be a default Apache install.                                                                                                                                                                          
+ OSVDB-3092: /manual/: Web server manual found.                                                                                                                                                                                  
+ OSVDB-3233: /index.html.ca: Apache default foreign language file found. All default files should be removed from the web server as they may give an attacker additional system information.
... etc ...

+ OSVDB-3233: /index.html.var: Apache default foreign language file found. All default files should be removed from the web server as they may give an attacker additional system information.
+ OSVDB-3233: /cgi-bin/printenv: Apache 2.0 default script is executable and gives server environment variables. All default scripts should be removed. It may also allow XSS types of attacks. http://www.securityfocus.com/bid/4431.
+ OSVDB-3233: /cgi-bin/test-cgi: Apache 2.0 default script is executable and reveals system information. All default scripts should be removed.
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3268: /manual/images/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 6448 items checked: 2 error(s) and 36 item(s) reported on remote host
+ End Time:           2011-08-30 20:01:05 (77 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

As you can see, there is various default content there from my Apache install (this should all be removed in a production website, to prevent attackers from gaining extra information. Additionally we can see that we have an old version of Apache.



Scanning with Nessus

Now for a scan with Nessus to see what that can see:


In the Nessus report, there is a "High Severity" Denial of Service vulnerability for Apache.

This is a fairly recent exploit that many sites and services are currently vulnerable to. More information on this vulnerability is available at the following location:

http://archives.neohapsis.com/archives/fulldisclosure/2011-08/0203.html

Also, there are various information disclosure issues from the other running services (FTP, Telnet, Finger, SSH) which give us OS and service versions, and username information.


Finger and fingerd enumeration with a basic "for" loop

Nobody installs fingerd these days if they want to be secure (but hey, I trying to make the target bigger and practice some enumeration).

Nessus found the user root using finger, but is is also possible to find other accounts. This version of the finger daemon searches the user description in addition to the username, so you can also find users via words in the description as well.

Here is how to install the finger client on Backtrack and run a couple of different queries:

apt-get install finger


finger root@192.168.1.69
[192.168.1.69]
Login       Name               TTY         Idle    When    Where
root     Super-User            console        2 Mon 07:55  :0                  
root     Super-User            pts/3          2 Mon 08:29  :0.0                

finger user@192.168.1.69
[192.168.1.69]

Login       Name               TTY         Idle    When    Where
nobody   NFS Anonymous Access               < .  .  .  . >
noaccess No Access User                     < .  .  .  . >
nobody4  SunOS 4.x NFS Anonym               < .  .  .  . >


So, if there were other users on the system, we could try a dictionary attack to find them using finger in a "for" loop.

Given a list of names in "usernames.txt", we can use the following commandline for loop to iterate through them, and strip out anything found, dumping it to a file:

for name in $(cat usernames.txt); do finger $name@192.168.1.69 | awk 'NR!=1 && NR!=2' | grep -v ??? | cut -d " " -f1 | sort -u >> foundnames.txt; done

cat foundnames.txt | sort -u
adm
gdm
listen
lp
noaccess
nobody
nobody4
nuucp
postgres
root
smmsp
svctag
uucp
webservd

This could be a useful enumeration, which might make a dictionary attack against SSH (for example) a lot quicker.

Monday, 29 August 2011

Setting up Nessus in Backtrack 5 R1

In an earlier post I described how to setup Nessus on Backtrack 5:

http://insidetrust.blogspot.com/2011/05/easy-nessus-scan-for-beginner-with.html

For some reason, BT 5 R1 does not come with Nessus installed by default, but it's easy to download and install.

You will need to download Nessus from the following location:

http://www.tenable.com/products/nessus/select-your-operating-system

(I used the Debian 64 bit package)

Then install it with the following command:

dpkg -i Nessus-4.4.1-debian5_amd64.deb

Then you can simply follow the rest of the instructions in my original post.

Update - Of course, there is an easier way to do this ;o)

apt-get install nessus

Sunday, 28 August 2011

How good is your browser security?

So, if you are reading this blog, you are probably interested in IT security (or insecurity, otherwise you are in the wrong place).

Is your browser secure?

This is a great resource for testing browser security:

https://browsercheck.qualys.com/

Run the above test on each of the browsers on your system (IE, Firefox, Chrome etc)

If all is well you should get a screen which looks something like this:

 

If you get a red bar, you are not up-to-date, and probably not fully secure for browsing. If this is the case then I recommend you should to follow the on-screen instructions to get this fixed.

I would be interested to see how many people pass on the first attempt, and what measures others needed to take to get up-to-date.

For me, I run Backtrack 5 R1 (Linux), I needed to update Firefox, and the flash-plugin.

I have added explanations of how to upgrade to Firefox 6.x and also update the Flash plugin in my "Backtrack 5 R1 notes" at the following location:

http://insidetrust.blogspot.com/2011/08/backtrack-5-r1-some-things-fixed-some.html

I recommend anyone who is using Backtrack 5 R1 to apply the updates to help make their system more secure.

I also run chrome on this system, and my chrome status looks like this (Shockwave Flash 11.0 is currently pre-release)


Thursday, 25 August 2011

GIAC Web Application Penetration Tester (GWAPT)

I took and passed the GIAC Web Application Penetration Tester (GWAPT) exam today, so I thought I would write something about it (and the SANS course that supports it).


The SANS "Web Application Penetration Testing and Ethical Hacking" course coverage

I had taken the SANS "on-demand" online version of their Web Application Penetration Testing course. I felt the online version of the course is a great format, because it gives you plenty of time to absorb the material and experiment in your own time.

I had previously read the excellent book Web Application Hackers Handbook (which I would highly recommend, before considering the SANS course). There were a few key things on the SANS course that are not covered in that book (and vice versa)

On reflection, this course covers quite a lot of ground. It has the basics of various common attack vectors (such as SQL injection and XSS) but it goes beyond the norm in some areas (though some other attacks and detail seem to be missing).

Additionally to what is covered in the WAHH book, the SANS course covers subject areas such as:

Decomposition and basic analysis of Java applets and Flash objects
Understanding AJAX
Various tools for spidering, and Web app vulnerability scanning
Exploitation frameworks

Most notably, the SANS course covers the basics of a lot of different tools for web-app security testing, including:

Burpsuite, Webscarab, Paros, Dirbuster, Skipfish, W3af, Tamperdata, SQLinjectMe, Sqlmap, Grendel-scan, Nikto, Aura, SiteDigger, Wikto, Goolag Scanner, Maltego, Nmap,  HTTPrint,  OpenSSL, THC SSL Check, CeWL, SprAJAX, RatProxy, WebService Studio, WSDigger, WSFuzzer, Flare, HP SWFscan, SWFIntruder, JAD, Websecurify, XSS Me, GreaseMonkey, XSS Assistant, PostInterpreter, Absinthe, MonkeyFist, BeEF, Dursosploit, AttackAPI

This is a lot of coverage, though obviously in many cases we are talking about the bare minimum of one slide of notes per tool (you will need to do a lot of your own practice and research to get to know these tools properly).

Though I didn't feel the SANS audio track was as good as it could have been, the course notes and lab examples are good (if you complete them all a couple of times, and do some extra experimentation).

In addition, I did a lot of my own testing with the Web Security Dojo, and some Virtual Appliance UI research in my home lab - which I feel helped me a lot with understanding how to use some of the tools more effectively.


Notes for GWAPT test-takers

This is an open-book exam, which was a new thing for me. I would definitely recommend test-takers to study the SANS course thouroughly, and take there course material with them, because the exam sticks very closely to the SANS course material.

Also, make sure you know which information is in which section of the course material, i.e. know where you would find information on SQL injection syntax, or PHP functions, or HTTP response codes (as examples).

In terms of practice, the certification exam is similar to (but not as easy as) the example tests provided by GIAC. I would also recommend reading the course material a couple of times, completing all the course practicals, and doing extra practice with the tools, such as completing the Web Security Dojo (or Web Goat at the very least).