[SECURITY] [DSA 1774-1] New ejabberd packages fix cross-site scripting

<!– Envelope-to: email@address Delivery-date: Fri, 17 Apr 2009 18:09:06 +0100 Received: from outgoing.securityfocus.com ([205.206.231.26] helo=outgoing2.securityfocus.com) by lt.network5.net with esmtp (Exim 4.43) id 1LurYo-0002Ii-LF for email@address; Fri, 17 Apr 2009 18:09:06 +0100 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing2.securityfocus.com (Postfix) with QMQP id A58E1143B81; Fri, 17 Apr 2009 09:12:35 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: <bugtraq.list-id.securityfocus.com> List-Post: <mailto:bugtraq@securityfocus.com> List-Help: <mailto:bugtraq-help@securityfocus.com> List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com> Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 1070 invoked from network); 17 Apr 2009 07:06:43 -0000 Resent-Cc: recipient list not shown: ; Old-Return-Path: <white@debian.org> X-Original-To: lists-debian-security-announce@liszt.debian.org Delivered-To: lists-debian-security-announce@liszt.debian.org X-policyd-weight: DYN_NJABL=ERR NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_BL_NJABL=-1.5 DSBL_ORG=ERR CL_IP_EQ_HELO_MX=-3.1 (check from: .debian. – helo: .apu.snow-crash. – helo-domain: .snow-crash.) FROM/MX_MATCHES_NOT_HELO(DOMAIN)=0 <client=78.47.227.179> <helo=apu.snow-crash.org> <from=white@debian.org> <to=debian-security-announce@lists.debian.org>, rate: -6.1 Message-Id: <20090417071242.8D4E7849052@hannah.localdomain> X-Virus-Scanned: at lists.debian.org with policy bank moderated X-Spam-Status: No, score=-10.68 tagged_above=3.6 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, FVGT_m_MULTI_ODD=0.02, IMPRONONCABLE_2=1, LDO_WHITELIST=-5, MURPHY_WRONG_WORD2=0.2, PGPSIGNATURE=-5] X-Spam-Level: X-Debian: PGP check passed for security officers Priority: urgent Resent-Message-ID: <V6VPwnltXIN.A.ZrC.DwC6JB@liszt> Reply-To: listadmin@securityfocus.com Mail-Followup-To: bugtraq@securityfocus.com Resent-Date: Fri, 17 Apr 2009 07:13:07 +0000 (UTC) Resent-From: list@liszt.debian.org (Mailing List Manager) X-IMAPbase: 1176125385 8818 Status: O X-UID: 8818 Content-Length: 5043 X-Keywords:

]]> http://sechero.com/new-ejabberd-packages-fix-cross-site-scripting-2/feed/ 0 http://sechero.com/new-ejabberd-packages-fix-cross-site-scripting/ http://sechero.com/new-ejabberd-packages-fix-cross-site-scripting/#comments Fri, 17 Apr 2009 07:12:42 +0000 invalid string http://sechero.com/new-ejabberd-packages-fix-cross-site-scripting/

[SECURITY] [DSA 1774-1] New ejabberd packages fix cross-site scripting

Posted by Steffen Joeris on Apr 17

————————————————————————
Debian Security Advisory DSA-1774-1 security_at_debian.org
www.debian.org/security/ Steffen Joeris
April 17, 2009 www.debian.org/security/faq
…

URL: http://seclists.org/fulldisclosure/2009/Apr/0180.html

Vuln: ejabberd MUC Logs Cross Site Scripting Vulnerability

ejabberd MUC Logs Cross Site Scripting Vulnerability

URL: http://www.securityfocus.com/bid/34133

Making the most of your runbooks, (Fri, Mar 20th)

To perform effective security incident handling, a standard model is often used. SANS through its GIAC GCIH affiliation certification teaches a six step model comprising of the following steps:
preparation, identification, containment, eradication, recovery and lessons learned.
Today, I want to look at preparation. Given that during the current economic climate we are all expected to do more with the same, or often less resource, now is the time to see how we can use preparation time to make our incident response skills slick, and effective whilst not raising operational costs.
As incident response teams mature from the chaos of the first incidents through to the slick teams we all hope they will become, optimizing the processes within the team is an important maturity step. The Capability Maturity Model defines these maturity steps as:
Ad-hoc, repeatable, defined, managed, and optimized.
The way to identify where your incident processes are up to in this model are to use some easily identifiable characteristics

ad-hoc – Processes are undocumented and what process there is changes a lot
repeatable – Documented, and may even give the same results, but little discipline in operating the process
defined – Documentation is well defined and have been improved over time
managed – metrics are embedded within the processes, and used to check the effectiveness of the processes
optimizing – found to be focused on continual improvement of the process

Given that the standard way of documenting incident response processes is via the run book, lets look at some ways of improving the effectiveness of those processes.
1. Paper Based Run Books
If you don’t have procedures, written down ones with steps etc, now is the time to start. Every time you perform an incident for which you dont have a run book, transpose your notes you took during the incident into a documented step by step action sheet as to what you do next time. It doesnt have to be a huge weighty tome of information, infact a single sheet process, with a page or two of notes on what the process steps do should be more than enough.
2. Using a Wiki rather than using paper
Incident teams work effectively by collaborating during an event, an onwards through the incident until the service is recovered. During the lessons learned process step of an incident, when you walk through and find what you did good at, and what sucked, this is the time to change your run books to address those issues. Having collaborative publishing as with a Wiki allows the whole team to discuss and propose changes to your run books via the Wiki and then you can move, with team agreement, from 1.0, to 2.0 of your run books. One thing to remember, make sure you have local, offline copies of your wiki on your incident response laptops so you can refer to the documentation if your website, or network is down, or compromised. Other points to consider on the choice of wiki software, and its configuration are:

use SSL to encrypt the connections to the wiki
turn off default read to the wiki
create accounts for each of your incident team, and those needed to authorize changes to your procedures

3. Automating steps within the Wiki Run Book
This is the key step in making the most of your run books. If during an incident, for example an IDS alert against your corporate web site, you will need to perform some standard steps time and time again. Lets automate them, and define them within the Wiki run book.
For example, grab todays web logs, and search them for entries for a particular IP address. Your run books should have this defined as a step, so on your wiki, have a link that pulls the logs, performs the grep, or other such search, and display the results for you on the web page.
For example, should you want to pull all 404 errors from your web site, you could have a link as shown in the picture below:

And this could result in

193.225.244.201 – - [10/Mar/2009:20:53:24 +0000] GET /sql/phpMyAdmin-2.10.0-beta1/main.php HTTP/1.0 404 234 – -
193.225.244.201 – - [10/Mar/2009:20:53:24 +0000] GET /sql/phpMyAdmin-2.10.0-rc1/main.php HTTP/1.0 404 232 – -
193.225.244.201 – - [10/Mar/2009:20:53:24 +0000] GET /sql/phpMyAdmin-2.10.0.1/main.php HTTP/1.0 404 230 – -
193.225.244.201 – - [10/Mar/2009:20:53:24 +0000] GET /sql/phpMyAdmin-2.10.0.2/main.php HTTP/1.0 404 230 – -
193.225.244.201 – - [10/Mar/2009:20:53:25 +0000] GET /sql/phpMyAdmin-2.10.0/main.php HTTP/1.0 404 228 – -
193.225.244.201 – - [10/Mar/2009:20:53:25 +0000] GET /sql/phpMyAdmin-2.10.1-rc1/main.php HTTP/1.0 404 232 – -
193.225.244.201 – - [10/Mar/2009:20:53:25 +0000] GET /sql/phpMyAdmin-2.10.1/main.php HTTP/1.0 404 228 – -
193.225.244.201 – - [10/Mar/2009:20:53:25 +0000] GET /sql/phpMyAdmin-2.10.2-rc1/main.php HTTP/1.0 404 232 – -

4. Producing evidence of run book adherence

In larger organizations the auditing of adherence to the steps performed during an incident will be expected, and indeed checked. So, again using your automated run book methodology, use tick boxes, radio buttons, etc, to show where decisions are made, and what choices were made during an incident. These can be logged and presented as audit evidence later on. If you have a team spread across multiple sites/countries, etc, then you could use a communications server, such as IRC, Jabber, etc, to allow people to talk about the event and then save the logs. If audit ask for decision points during an event, and where they are recorded, show them your logs. Of course, if your using communication servers, implement SSL on them, and deny access in the clear.

5. MI
Management information during an incident should describe the effectiveness of the process. Time to respond, time to step through the four steps of the incident handling process which are used during an incident. Using the automated run books method will speed up key functions within your response and allow you to demonstrate that you true are doing more for less!
Finally, if you have any tips on improving your run books, pass them along and I’ll update this diary over the weekend. I am on duty again on Monday, so I’ll ensure that those few of you who don’t read us over the weekend are not left out!

URL: http://isc.sans.org/diary.php?storyid=6049&rss

CVE-2009-0934 (ejabberd)

Cross-site scripting (XSS) vulnerability in ejabberd before 2.0.4 allows remote attackers to inject arbitrary web script or HTML via unknown vectors related to links and MUC logs.

URL: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-0934