The vulnerabilities I found:

1. Non-persistent XSS in search
2. Persistent XSS in user “My details” (only affected the currently logged in user)
3. Persistent XSS in news comments

There was absolutely no input filtering at all on strings, which were just blindly echoed back to the client. I sent an e-mail to BAM regarding my finds and to be quite honest I was extremely surprised I got a reply within 24 hours. I proceeded the send more details once I knew I wasn’t conversing with the receptionist in their Swansea offices. I hoped they would have some clue with what they were doing after I pointed the issues out (misplaced confidence that was). They replied telling me the issues were fixed, I went ahead to test. Indeed they had fixed the problems using strip_tags() which is not the best solution to the problem, and it can also cause other problems. It also will not deal with attackers breaking out of attributes to add their own. I advised them they should be using htmlspecialchars() to escape strings taken from user input, which they seem to have done now. Their reply to this e-mail seems to have vanished into some sort of Internet oblivion, I’ve asked them to resend it. It has now been added below.

From: Richard Moseley <rm@[removed]>
To: chris+sumarketing.co.uk@[removed]
Date: Thu, 13 Nov 2008 09:49:57 +0000

Hi Chris,

I would be interested in hearing what security vulnerabilities you
have found in the web platform, so that we can further investigate
these problems.

I look forward to hearing from you.

Many thanks

Richard Moseley
BAM
2nd Floor
No 8 Castle Square
Swansea
SA1 1DW

Tel: 0845 1300 667
Fax: 0845 1300 668

The information in this email and any attachments is confidential and
may be legally privileged. If you are not the intended recipient's),
you must not read, use, distribute or disseminate this email or the
information in it save to the intended recipient's) nor take any
action in reliance on it. If you receive this email or any attachments
in error, please notify us immediately by email or by telephoning 0845
1300 667 and then delete the same and any copies.

BAM Agency Ltd accepts no responsibility for any loss or damage
whatsoever arising in any way from receipt or use of this email or any
attachments.this email or any attachments.

>
>
> From: hello@[removed] [mailto:hello@[removed]]
> Sent: 13 November 2008 00:01
> To: rh@[removed]
> Subject: Comments From -
> Importance: High
>
>
> BAM
> 2nd Floor
> 8 Castle Square
> Swansea
> SA1 1DW
>
> Tel: 0845 1300667  Fax: 0845 1300668  Email: hello@[removed]
>
> |
>
> This message was sent via the contact form on www.sumarketing.co.uk
>
> Name: Chris Smith
>
> Company: -
>
> Telephone: -
>
> Email: chris+sumarketing.co.uk@[removed]
>
> Comments: I have found several security vulnerabilities in your
> websites do you have a point of contact so I can report them
> responsibly?
>
> How did they here about us: Other
>
> Click to visit the site
>

Date: Thu, 13 Nov 2008 20:59:46 +0000
From: Chris Smith <chris@[removed]>
To: Richard Moseley <rm@[removed]>

Richard Moseley wrote:
> I would be interested in hearing what security vulnerabilities you have
> found in the web platform, so that we can further investigate these
> problems.

I have found three XSS issues, considering the ease it took me to find
them I expect there maybe more. The prime cause seems to be sloppy
programming by not sanitising user data before it is accessed. Two of
the XSS vulnerabilities are of the more serious persistent type and the
other is non-persistent. In order of severity:

* Non-persistent XSS in search:

- - Enter the search term:
<script>alert(document.cookie);</script>
- - Click search

Result:
Users cookies are displayed in a message box.

Severity:
Minor would require social engineering to get people to enter a
malicious search term.

* Persistent XSS in user "My details":

- - Login
- - Set first name to:
<script>alert(document.cookie);</script>
- - Click update
- - Logout
- - Login

Result:
Users cookies are displayed in a message box.

Severity:
Minor requires social engineering again to accomplish and it is per user.

Notes:
This is also a problem for "last name" and probably some of the other
fields.

* Persistent XSS in news comments:

- - Find a news article you can comment on
- - Enter the comment:
<script>alert(document.cookie);</script>
- - Click post

Result:
Users cookies are displayed in a message box.

Severity:
Severe once posted the attack works against anyone viewing the site,
with some elaborate JavaScript it would be possible to trap data entry
to the username and password box capturing the input and sending it to a
remote server. Or if a user is logged in you could combine this attack
with the second issue I mentioned to silently modify the users "first
name" using an XmlHttpRequest to include another XSS which persisted on
all pages they visited on the site.

>> How did they here about us: Other

Spelling error "here" instead of "hear".

From: Richard Moseley <rm@[removed]>
To: chris+sumarketing.co.uk@[removed]
Date: Thu, 13 Nov 2008 21:20:48 +0000

Hi Chris, thanks for bringing these items to our attention, i will get
someone onto these items in the morning, and advise when they have
been resolved.

Thanks

Richard Moseley
Web Developer
BAM
2nd Floor
No 8 Castle Square
Swansea
SA1 1DW

Tel: 0845 1300 667
Fax: 0845 1300 668

The information in this email and any attachments is confidential and
may be legally privileged. If you are not the intended recipient's),
you must not read, use, distribute or disseminate this email or the
information in it save to the intended recipient's) nor take any
action in reliance on it. If you receive this email or any attachments
in error, please notify us immediately by email or by telephoning 0845
1300 667 and then delete the same and any copies.

BAM Agency Ltd accepts no responsibility for any loss or damage
whatsoever arising in any way from receipt or use of this email or any
attachments.this email or any attachments.

Date: Sat, 15 Nov 2008 14:51:40 +0000
From: Chris Smith <chris@[removed]>
To: Richard Moseley <rm@[removed]>

Richard Moseley wrote:
>
> Hi Chris, thank you for bringing these items to our attention. These
> have now been resolved.

I notice your resolution seems to be to use strip_tags() to remove tags
while this is all well and good it doesn't address everything.
Ampersands are still inserted into the HTML un-escaped, this is not
going to cause an XSS attack but it causes invalid HTML to be outputted.
More worryingly if you have any code that inserts user input into a tag
attribute, which is not an entirely unreasonable scenario, strip_tags()
will do squat all to protect you. For example if you take a string from
the user and place it into the href attribute of an anchor and use
strip_tags() to protect yourself, I could send a string like this:

" onmouseover="alert(document.cookie);" dummy="

This assumes you have some code like

<a href="/xyz/<?php echo strip_tags($_GET['var']); ?>/index.php">

This would result in the following:

<a href="/xyz/" onmouseover="alert(document.cookie);" dummy="/index.php">

The solution is to use htmlspecialchars() which ensures double quotes,
ampersands and angle brackets are escaped. Meaning its impossible to
break out of your tags or inject new ones, one thing htmlspecialchars()
doesn't do by default is escape single quotes but you shouldn't be using
them in HTML.

It is also worth noting that strip_tags() is quite zealous with its
removal of 'tags' and will remove things like '<43' which is not
unreasonable to occur in for example a statement with a mathematical
inequality.

I would suggest either just using htmlspecialchars() or using both
functions.

I must admit I am impressed by the quick turnaround on this even if the
fix is flawed.

From: Richard Moseley <rm@[removed]>
To: chris+sumarketing.co.uk@[removed]
Date: Fri, 14 Nov 2008 08:22:13 +0000

Hi Chris, thank you for bringing these items to our attention. These
have now been resolved.

Kind Regards

Richard Moseley
Web Developer
BAM
2nd Floor
No 8 Castle Square
Swansea
SA1 1DW

Tel: 0845 1300 667
Fax: 0845 1300 668

The information in this email and any attachments is confidential and
may be legally privileged. If you are not the intended recipient's),
you must not read, use, distribute or disseminate this email or the
information in it save to the intended recipient's) nor take any
action in reliance on it. If you receive this email or any attachments
in error, please notify us immediately by email or by telephoning 0845
1300 667 and then delete the same and any copies.

BAM Agency Ltd accepts no responsibility for any loss or damage
whatsoever arising in any way from receipt or use of this email or any
attachments.this email or any attachments.

From: Richard Moseley <rm@[removed]>
Date: 15 November 2008 16:42:18 GMT
To: Chris Smith <chris@[removed]>
Subject: Re: Comments From -

Hi Chris,

Thanks for the email, we are currently doing an audit on the XSS
vulnerabilities to ensure that it does not affect any of our other
code on the system, so as a quick resolution we used the
strip_tags() route as we knew that this did not effect any of the
existing coding, while investigating any potential impact of using
htmlspecialchars() on the system including the forums, and issues
caused as a consequence.

Once we have completed this assessment we will convert the system
over to using htmlspecialchars() instead.

Thanks for the update and the feedback you have provided on this
matter.

Kind Regards

Richard Moseley
BAM
2nd Floor
No 8 Castle Square
Swansea
SA1 1DW

Tel: 0845 1300 667
Fax: 0845 1300 668

The information in this email and any attachments is confidential
and may be legally privileged. If you are not the intended
recipient's), you must not read, use, distribute or disseminate this
email or the information in it save to the intended recipient's) nor
take any action in reliance on it. If you receive this email or any
attachments in error, please notify us immediately by email or by
telephoning 0845 1300 667 and then delete the same and any copies.

BAM Agency Ltd accepts no responsibility for any loss or damage
whatsoever arising in any way from receipt or use of this email or
any attachments.

OpenSSH, which can only be described as the best utility of all time, is quite a versatile tool one feature people use frequently is port forwarding. This allows you to open a port on your computer that forwards the data over the SSH connection to the destination you specify, very useful when needing access to the an intranet web server when you don’t have a proper VPN set up for example. However, SSH can also do this in reverse! It opens a listening port up on the remote machine which then relays data to the destination you specify. For example you can SSH into a remote host and get SSH to open a port on that host which relays data back to the SSH port on the machine you are connection from, thereby allowing SSH access to a machine where it would normally be impossible.

A practical example:

chris@ktulu:~$ ssh sandman.cs278.org -R 2222:localhost:22

This connects to the server sandman.cs278.org and opens port 2222 which forwards traffic to localhost:22 (localhost is the machine I am connecting from). Once logged into the server I can do this:

chris@sandman:~$ ssh localhost -p 2222

Which opens a connection back to the remote machine.

        $ignore = array( 'HTTP_COOKIE' );

        foreach ( $_SERVER as $key => $value )
                if ( !in_array( $key, $ignore ) )
                        $comment["$key"] = $value;

        $query_string = '';
        foreach ( $comment as $key => $data )
                $query_string .= $key . '=' . urlencode( stripslashes($data) ) . '&';

        $response = akismet_http_post($query_string, $akismet_api_host, '/1.1/comment-check', $akismet_api_port);

The bit that worries me is the use of $_SERVER, the only item from this array not sent is HTTP_COOKIE, fair enough. But why do you need to know the full paths to the files on my server and other server environment variables Akismet? I do not have a problem with sending data to Akismet, just not this data!

Source

1. Install Munin Node:

   $ sudo aptitude install munin-node

2. Create the upstart event file:

   $ sudo -e /etc/event.d/munin-tunnel

   Write in the following text:

   start on runlevel 2
   start on runlevel 3
   
   stop on runlevel 0
   stop on runlevel 1
   stop on runlevel 4
   stop on runlevel 5
   stop on runlevel 6
   
   exec sudo -u munin ssh -N munin-reporter@munin-server.example.com
   respawn

3. Generate a SSH key for munin:

   You do not want to set a password on the SSH key

   $ sudo sudo -H -u munin /bin/bash
   $ mkdir /var/lib/munin/.ssh/
   $ cd /var/lib/munin/.ssh
   $ ssh-keygen -b 1024 -C munin@`hostname -f` -t rsa
   $ exit

4. Edit the SSH configuration for the munin user:

   $ sudo -e /var/lib/munin/.ssh/config
   $ sudo chown munin:munin /var/lib/munin/.ssh/config

   Insert:

   Host munin-server.example.com
   RemoteForward some-port-number localhost:4949

5. Now you need to do some leg work on your server first create a user so that the SSH tunnel can be created, I used munin-reporter. Then you need to copy the munin users public key on your client into the ~munin-reporter/.ssh/authorized_keys file on your munin server. I will leave this as a user task, set up how you like on your server. I would recommend prepending the munin public key with the following in the authorized_keys file to restrict what the user can do.

   no-pty,no-X11-forwarding,no-agent-forwarding

6. Again, on your server, we need to tell munin where to get the data about the remote host from, using the snippet below:

   sudo nano /etc/munin/munin.conf

   [node.example.com]
   address 127.0.0.1
   port some-port-number
   use_node_name yes
   

7. Next we need to test the connection and verify the host signature so, that it doesn’t need to be done again.

   $ sudo sudo -u munin ssh munin-reporter@munin-server.example.com -v

   Check for any errors etc. if you spot a problem retrace your steps.

8. All that is left is to start the upstart event and wait for some pretty graphs

   sudo start munin-tunnel

$ svn diff http://svn.automattic.com/wordpress/tags/2.1.2 http://svn.automattic.com/wordpress/tags/2.1.3

Piped it to a file and applied it to WordPress using patch, no drama no mess no effort. Just the way I like it

To patch:

$ patch -i ./wordpress-2.1_2.1.2.diff -d /path/to/wordpress -p0

$ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
2048 d6:59:bc:0b:18:ba:17:15:41:fc:d0:2a:60:f4:7e:e8 /etc/ssh/ssh_host_rsa_key.pub

I will be tidying this up and possibly turning it into a automated script. I must admit this has not been easy no one guide has got it going it has taken multiple HOWTOs to inch every step of the way, but now I have it done I am happy, the gotchas were rather frustrating at time due to the difficulty of easily debugging the initial ram image when the machine is booting.