OWASP Top 10: Security misconfiguration, logging e monitoramento

Security Misconfiguration - Introdução

Bem-vindo a mais um curso de OWASP top 10 riscos de segurança em aplicações web.

E nesse caso nós vamos falar agora sobre os riscos a partir do A6 até o 10, passar mais cinco ou seis riscos para nós discutirmos sempre lembrando que nós temos muita coisa legal para ver que são em que situações nós podemos estar vulnerável, então um conjunto de diversos exemplos de situações, onde nós podemos ter esse risco presente.

Nós vamos ver que é basicamente sempre que nós vamos ter esses riscos ou diversos desses nas nossas aplicações e cada vez em aplicações mais modernas nós vamos ter mais deles em várias situações.

E como preveni-los, então exemplos de técnicas que nós podemos utilizar para preveni-los e para garantir que eles não voltem a nos aborrecer no futuro.

Então tudo isso vai ser bem legal, nós discutimos todos eles com os exemplos que o próprio OWASP passa para nós e vários outros exemplos do dia a dia que aparecem nas aplicações mais diversas de uma forma independente de qual linguagem ou ferramenta nós utilizamos no dia a dia, então nós vamos discutir isso nesse curso, vamos lá.

Security Misconfiguration - Security misconfiguration

Então bem-vindo ao segundo curso de OWASP top 10, infelizmente top 10 são de riscos, não de coisas positivas.

E vamos lá então, nesse primeiro assunto desse top 10 que nós vamos falar nesse segundo curso é o A6, a configuração meia-boca de segurança, meia-boca na verdade Misconfiguration não é meia-boca, parece, para mim parece, mas não é, é uma configuração errônea, inadequada e por aí vai.

Então vamos pegar alguns exemplos, tem vários exemplos que vão citados para nós e eu gosto de pegar não necessariamente esse primeiro de todos que ele vai citar, nós vamos passar por todos, claro, mas um que eu gosto é esse daqui, funcionalidades não necessárias instaladas ou ativas.

Então por exemplo, imagina que eu estou na minha primeira empresa eu vou instalar um servidor Linux com MySQl com várias coisas e eu descubro que já existe um sistema operacional que já vem com tudo isso instalado.

Então eu pego uma máquina no Cloud ou uma máquina minha aqui conecto na internet, coloco IP fixo e instalo esse Linux que já tem tudo pré-instalado e deixo lá.

E por acaso ninguém usa um banco de dados que está instalado lá, não me importa se é MySQL se é PostgreSQL, se é XPTO se é NoSQL, não me importa, mas é uma versão qualquer de um banco qualquer que está lá que ninguém usa que veio por padrão, não me importa se é Mongo, se é não sei o que, não me importa, veio por padrão, está lá, ninguém está usando, só veio porque eu coloquei a instalação daquele sistema operacional que já veio com aquilo pré-instalado.

E estão lá instalados por padrão desnecessariamente e ninguém está nem preocupado com isso, afinal, ninguém utiliza.

O que acontece é, descobre-se uma falha de segurança naquela versão daquele software e o software é atualizado, como nós não estamos utilizando aquele software nós não atualizamos e o que acontece? Nós temos uma falha de segurança, porque nós temos rodando uma funcionalidade ou um software inteiro instalado que não é necessário.

Então no caso eu estou citando um serviço mesmo de software de um MySQL ou de um Mongo, seja lá o que for, estou dando exemplo de banco de dados, não que o banco de dados só daria acesso ao banco porque as falhas de segurança dos bancos ou de outras coisas podem dar acesso ao sistema operacional, podem dar acesso a várias outras coisas.

Então super arriscado, claro, o meu primeiro erro em teoria foi eu não estar utilizando processo de DevOps, utilizando Kubernetes, utilizando Docker, eu não estar mantendo atualizado todo o meu sistema operacional, tem diversas maneiras de eu me prevenir nesse caso especifico que eu citei.

Poderia começar com o Linux bem limpo, minimalista e instalar o software que é necessário através de Kubernetes, seja lá o que for, aqui na Alura temos cursos para diversos desses assuntos, quem já conhece, quem já trabalha com isso conhece esses softwares e é claro que o que nós faz na área de segurança é indicar que só instala o que é necessário e o que é necessário que foi instalado vai ter que ser mantido.

Então vamos lá, tem vários exemplos de aplicações vulneráveis, vamos passar aqui uma a uma.

Então primeiro, faltando hardening, hardening é quando nós deixamos a coisa mais dura, mais difícil de quebrar, então está faltando hardening de segurança numa parte da aplicação.

Então em uma parte da aplicação inteira sua está faltando nós travarmos uma segurança lá e é por isso que tem a recomendação, que já apareceu em outros itens da OWASP de nós fazermos o que? De nós criarmos uma camada de segurança na nossa aplicação.

Então você coloca uma primeira camada de segurança, de autenticação e autorização que passa por padrão por aquela camada ou seja lá o que for que tem que ser feito, além de outras coisas que você pode colocar na sua aplicação, no seu código customizado.

Então se você tem a sua aplicação, talvez você queira colocar ela para ser rodada num usuário com menos permissões, porque se aquele usuário que roda a sua aplicação tem permissão de root na máquina, bom, se hackearem a sua aplicação hackearam a máquina inteira.

Então nós queremos tomar certos cuidados, então nós estamos hardening nós estamos colocando mais coisas ali para dificultar, deixar mais duro o processo, ou deixa mais dura a segurança, então essa é uma abordagem importante.

E configurações de permissão indevidas em serviços de cloud, por que que ele cita serviços de cloud? Na verdade, permissões indevidas em qualquer lugar, se eu coloco lá no meu sistema operacional que qualquer usuário pode acessar qualquer arquivo eu estou danado.

Porque por padrão, no sistema operacional, quando você instala tem já alguns usuários, tem admin, tem diversos outros usuários que são criados por padrão, tem seus grupos, eu estou pensando em Linux, etc. tem seus grupos e cada um tem suas permissões, quando você instala um MySQL por padrão vai criar um usuário para gerenciar o MySQL no sistema operacional.

Vai instalar um Nginx ou algum servidor web, vai ter um usuário para gerenciar esse serviço etc. Por quê? Porque assim você tem um espaço que diz as permissões de execução de cada um desses usuários, mas se de repente você permite tudo para todo mundo, isto é uma falha de configuração de permissão, então tem outras falhas de configuração de permissão em arquivos de configurações, em arquivos de permissões, tomar esses cuidados.

Abre todas as portas, vai no Iptables e abre todas as portas para fora ou algo do gênero, poxa, não é assim, você abre só a porta que você quer abrir, que você precisa abrir que ele cita que logo depois, portas desnecessárias abertas, abriu portas desnecessária? Sabe se lá o que vai ser feito com essa porta por alguém que nós desconhecemos.

Então toma cuidado, mas por que que ele cita explicitamente cloud services? Porque o que eu citei até agora são de configurações independente de estar no cloud ou não, mas no cloud tem um cenário que adiciona uma camada de complicação para quem está desenvolvendo pela primeira vez.

Então eu estou desenvolvendo pela primeira vez o meu aplicativo, desenvolvi aqui na minha máquina, funcionou, na minha equipe funcionou e nós vamos colocar no ar e nós colocamos no cloud.

Só que o nosso serviço precisa acessar o banco de dados, vamos supor, na Amazon é o RDS ou em outro serviço, no [AGER] é um outro serviço e por aí vai, não me importa onde, você tem um serviço de banco, então a minha máquina precisa acessar esse serviço do banco, ela precisa tem permissão para acessar esse serviço do banco.

Isso quer dizer o que? Que em algum lugar da Amazon, do [AGER], etc. você vai ter que falar que olha, a máquina que está neste IP tem acesso àquele servidor de banco de dados que está naquele outro IP, ou algo do gênero, existem outras maneiras de fazer esse mapeamento, estou falando a maneira mais simples e boba e fixa e sólida de propósito.

Por quê? Porque imagina que você derruba a máquina, levanta de novo e ela levanta com outro IP? O que que acontece? Você se deu muito mal, porque você vai ter que fazer o que agora? Vai ter que reconfigurar isso e enquanto não reconfigurar isso a sua aplicação não está acessando o banco de dados.

Então percebe que numa configuração se eu fosse pela primeira mais simples que eu aprendo eu ia me dar muito mal, porque eu ia colocar em produção e no primeiro stop start que perdeu IP ia me dar muito mal ou algo do gênero, não necessariamente pelo IP, mas qualquer configuração, mudança simples eu poderia perder o acesso ao meu banco de dados temporariamente e derrubar todo o meu serviço, tudo parar de funcionar.

Então uma configuração muito fixa, por exemplo, como IPs faria isso, você fala, então o que que eu faço, então eu como desenvolvedor iniciante, o que que eu faço? Eu já estou começando na carreira, não tenho muita noção das coisas, eu vou lá e falo que no meu banco de dados, quer saber? Qualquer IP pode acessar, agora que você abriu para qualquer IP acessar você abriu a porta ao mundo inteiro.

Então essa é uma configuração de permissão imprópria, você configurou para que qualquer um no mundo possa acessar o seu serviço de banco de dados.

E agora a pessoa nem precisa estar lá no meio das suas máquinas, não precisa nem ser uma máquina que está dentro do seu usuário da Amazon por exemplo, pode ser uma outra máquina, percebe que você abriu totalmente o buraco?

Então existem milhares de outras maneiras, não milhares, mas diversas outras maneira de configurar isso que dão mais controle para nós e nós temos que ir para essas outras, então configurar através de uma VPN e etc. então tem várias maneiras de fazer isso, depende do serviço que você está utilizando.

E tem outras maneiras de verificar se é vulnerável, vou passar por várias delas, mas a ideia é essa, uma configuração mal feita e existem diversas maneiras de nós termos configurações mal feitas.

Security Misconfiguration - Mais exemplos

Vamos ver outros exemplos de vulnerabilidade de configuração para nós ficarmos atento no nosso dia a dia como desenvolvedor e desenvolvedora ou como equipe de segurança para dar um toque para a galera e educá-la, educar a galera, vamos ver lá.

Na parte de coisas desnecessárias eu comentei de portas abertas desnecessariamente, claro, mas também comentei de IPs aberto ou de serviços abertos para IPs desnecessariamente, quer dizer, abertos para lugares desnecessários, seja para fora de uma VPN onde eu estou rodando os meus serviços, seja lá o que dor, ou mesmo serviços que eu não precisa.

Se você não precisa dar suporte a ping em uma máquina, por que que a sua máquina está dando suporte a ping? Se a máquina não precisa de um HTTP, por que você tem um Nginx nela?

Sua máquina não precisa de um Mongo, por que que você tem um Mongo nela? Se o ser serviço tem uma página antiga que não é mais utilizada, por que aquela página está lá, ou contas, se existe um usuário que não deve mais ter acesso por que que aquele usuário está lá?

Ou até mesmo privilégios, se aquele tipo de privilégio ninguém vai utilizar, por que que existe aquilo? Como privilégio pode ser role, pode ser permissão pode ser o que for, mas qualquer coisa desnecessária tem que estar desativada ou desinstalada, essa é a ideia.

Ela nem existe no nosso sistema, se ela não existe no nosso sistema, ela não é um problema para nós, se ela existe no nosso sistema já é um primeiro problema, se ela existe e está ativada é um segundo problema.

Vamos lá, contas padrão, é claro, contas padrão superperigoso, é superfamoso uma época em que, se eu não me engano era o JBoss, posso estar errado, que vinha com o usuário e senha padrão, então usuário e senha padrão, que era tipo admin admin, ou não, não vinha com usuário e senha padrão mas era muito fácil de dizer um sim e quero um usuário e senha padrão durante a instalação e talvez sem um aviso de segurança e problema do gênero.

Ou até mesmo com usuário e senha padrão com uma pergunta de sim ou não dizendo que sim terá um problema de segurança se você deixar admin admin, mas já esta preenchido o campo admin admin para você dar yes, algo do gênero, ou admin vazio seja lá o que for.

E qual que é o problema disso? Se tem usuário e senha vazio e você coloca isso no ar e as pessoas descobrem que você está usando aquele serviço, elas vão tentar qual usuário e senha primeiro, admin vazio ou admin admin, ou seja lá o que for e se descobrirem que tem e que está acessando quebrou toda a sua segurança, eles tem o acesso do admin admin.

Então contas padrão, por padrão não, por favor, então para quem desenvolve um serviço, por favor, por padrão, não coloque contas padrão, nós sabemos da comodidade do usuário, mas pergunta para o usuário qual que é a conta que ele quer, pode até perguntar o nome de usuário, mas a senha é customizada.

Controle de erro, controle de erro vazar o stack traces, o stack traces em época de desenvolvimento, debug, etc. superutil, em produção também super útil para quem vai desenvolver e procurar erro, para quem é usuário final? Super desnecessário, para o hacker? Super útil, porque dá informações sobre o que nós utilizamos, onde que o sistema estava, o que o nosso sistema possui de classes, de métodos de funções, seja lá o que for então revelar stack traces não.

O que que nós fazemos? Todo o tratamento de erro tem que esconder informações, informações demasiadas nas mensagens de erro entregam informações demais, afinal é isso, informação demasiada, então o mínimo de informação, só dizer se é sincero que teve um erro e falar que tipo de erro que pode ser feito para ser corrigido pelo usuário final.

Lembrando que o desenvolvedor ou desenvolvedora ou quem é responsável pelo suporte que vai correr atrás do stack traces, etc. então loga, põe onde for necessário, com segurança.

Quando você atualiza um sistema, então imagina que você tem um sistema, ele está em produção, ele está rodando um MySQL e você atualiza o MySQL as novas funcionalidades de segurança do MySQL, da versão nova do MySQL, nós temos que ativar, nem sempre ela vai se ativar automaticamente.

As vezes ela é compatível com tudo o que tinha antes, etc. e pode até ativar automaticamente, mas muitas vezes não, é muito comum, por exemplo, em frameworks web, que aparece aqui Strut, Spring, ASP, NET, etc. que você podia passar qualquer coisa como parâmetro, é muito comum, é o padrão, é o que todo mundo fazia.

E isso foi mudado uma época, principalmente, eu lembro de um ataque no [REALS] que foi quando o [REALS], acho que pelo [REALS] três, muito tempo atrás mudou para uma lista de permissão, então você tinha que falar uma lista de permissão de quais são os parâmetros que você quer acessar e meio que desde então todo mundo deixa meio que por padrão esse caminho de lista de permissão ou você mesmo buscar os parâmetros que você quer.

Então essa mudança de uma versão para outra é uma quebra de compatibilidade, então ou você não consegue migrar e beleza porque você não consegue migrar e você vai ter que migrar na mão e tomar a decisão na mão, ou migra automaticamente mas e como que fica a questão de ativar essa questão de segurança automaticamente? Ativa e quebra ou ativa só para as coisas novas.

Então não está realmente aplicada essa questão de segurança, está parcialmente, ou deixa desativada, percebe que para quem desenvolve o que vai ser utilizado para os desenvolvedores é uma decisão difícil e para quem utiliza ferramenta é importante, atualizou? Confere que, na versão atualizada as novas funções de segurança estão ativadas.

Então essa seria já a prevenção, certo? Cuidado que eu estou falando o tempo da vulnerabilidade já dá para prevenção, prevenção nós vamos acabar passando mais rápido.

Configurações de segurança nos servidores de aplicação ou frameworks ou bibliotecas ou banco de dados, etc. seja lá o que for não estarem para valores seguros, essa sim é super genérica.

Isto é, todas as suas configurações têm que estar com valores seguros, o que que está dizendo? Entenda as questões de segurança de todas as ferramentas que você utiliza e configure-as adequadamente, meio que é isso, uma regra super genérica que meio que mata tudo isso daqui de uma vez só, generaliza para tudo isso, esse etc. aqui e valores seguros.

O servidor não envia headers de segurança ou diretivas de segurança com os valores adequados, então aqui quando ele está falando de servidores e headers, provavelmente ele está pensando em HTTP, apesar que outros protocolos também têm headers, muitos protocolos, mas provavelmente essa situação aqui é em relação HTTP.

Então HTTP tem diversos cabeçalhos de segurança de cookies, não de cookies, de referências, etc. e vão ser discutidos em diversos cursos aqui de segurança e nós temos que tomar os cuidados adequados e enviar esses cabeçalhos que fazem sentido.

O software está desatualizado ou ser vulnerável, com certeza é superimportante, está ligado com A9 que é utilizar componentes com vulnerabilidades conhecidas.

Se você tem um software que tem vulnerabilidades conhecida tem que atualizar ele, tem que atualizar e depois que atualizou, tem que fazer o que? Conferir que está ativo.

Qual que é o problema? Se nós não tivermos alguma cosia, um processo de configuração repetível, os sistemas vão estar em mais risco.

O que que ele quer dizer com repetível? Se nós vamos na mão de novo criar uma máquina Linux instalar as coisas e fazer as coisas na mão nós estamos danado, por quê? Porque a chance de nós abrirmos um novo buraco é muito grande e é aí que vai entrar DevOps e a parte de DevOps com segurança para que esteja essas duas coisas engajadas, tanto DevOps e segurança estejam andando de mãos dadas para que os buracos de segurança sejam tampados durante esse processo, alguns dos buracos adequados.

Tem exemplos de ataque aqui embaixo, o servidor de aplicação vem com aplicações por padrão e isso é super comum, servidores de aplicação vinham historicamente com aplicações padrão.

Então, você instalou um Tomcat vamos chamar de aplicação servidor de aplicação na época, mas um Tomcat e o Tomcat já vinha com alguma coisa e você acessava o local “host/ 8080/XPTO” e caia no XPTO.

Então só de ter o XPTO a pessoa já sabia que você estava então rodando um Tomcat e além disso essas aplicações podia ter falhas de segurança, então se está lá, boa sorte e algumas dessas aplicações eram consoles de admin e alguns desses consoles de admin tinham contas padrão com senhas padrão, então superperigoso, está vendo?

Então você repara que tudo que é padrão nós tomamos cuidado, por isso que nós falamos hoje em algum instante vai repetir, o padrão é o mais fechado, o padrão é o mais seguro.

Lista de diretórios no servidor, eu comentei lá para trás no outro curso no S3 ou em outros lugares repositórios de arquivos que pode ter a listagem de arquivos publicamente, superperigoso, então listar o diretório, você acessou uma URI ele lista os arquivos de um diretório, abriu o buraco, abriu o buraco para saber os arquivos que existem e por aí vai.

E se de alguma maneira o atacante conseguir encontrar e baixar os arquivos, aqui ele está citando, arquivos Java compilados, não me importa, os arquivos rub, os arquivos python, os arquivos closer, os arquivos seja lá o que for, qualquer arquivo compilado, não compilado, seja lá o que for, descompilarem, fazer engenharia reversa, não me importa, eles vão ter cada vez mais controle sobre a nossa aplicação.

Porque eles vão conseguir encontrar os fluxos de acesso ou entender melhor os fluxos de acesso, tentar encontrar melhor caminhos e buracos.

A configuração dá informação demais no stack traces, que é o que eu citei, certo? Então expõe informações sensíveis e por aí vai, então também cuidados a serem tomados, nomes de classes que você utiliza parâmetros, métodos, tudo coisa que a pessoa pode utilizar para tentar criar outros ataques.

Um provedor de cloud tem por padrão permissão para compartilhar dados, tem permissão nisso.

Então tem que tomar todo o cuidado, se os seus servidores de cloud tem configurações padrão que são abertas tem que tomar cuidado, em geral, em geral, quando você cria um serviço cru nos servidores de cloud você tem acesso a nada, ninguém tem acesso aquilo e aquilo não tem acesso a nada e você tem que dar na mão o acesso, e é justo por isso que quem está começando no Cloud tem esses problemas de segurança.

Por quê? Porque se eu não consigo nem acessar o servidor que eu criei lá na Amazon, ou [AGER] ou seja lá aonde for, o que que eu faço? Eu que não manjo de nada ainda por que eu estou começando na minha carreira? Eu abro completamente e na hora que eu abro completamente eu fui para o extremo oposto do fechar completamente e eu abri a segurança demais e vamos ver daqui a pouquinho então como prevenir e é isso.

Sobre o curso OWASP Top 10: Security misconfiguration, logging e monitoramento

O curso OWASP Top 10: Security misconfiguration, logging e monitoramento possui 95 minutos de vídeos, em um total de 19 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Security Misconfiguration
• Cross site scripting
• Insecure Deserialization
• Using components with known vulnerabilities
• Insufficiente Logging and Monitoring