Negação de Serviço

Descrição

O ataque de Negação de Serviço (Denial of Service - DoS) é focado em tornar

indisponíveis um recurso (site, aplicativo ou servidor) para a finalidade que foi
projetado. Há muitas maneiras de deixar um serviço indisponível para os usuários
legítimos através da manipulação de pacotes de rede, programação, lógica, ou
recursos de manipulação vulnerabilidades, entre outros. Se um serviço recebe um
número muito grande de solicitações, ele pode parar de fornecer o serviço a
usuários legítimos. Da mesma maneira, um serviço poderá deixar de funcionar se uma
vulnerabilidade de programação é explorada, ou o modo como o serviço manipula
recursos utilizados pelo mesmo.
Às vezes, o atacante pode injetar e executar código arbitrário ao executar um
ataque de negação de serviço, a fim de acessar informações críticas ou executar
comandos no servidor. Denial-of-service ataca significativamente a qualidade do
serviço experimentado por usuários legítimos. Ele apresenta grandes atrasos na
resposta, perdas excessivas, e interrupções de serviço, resultando em impacto
direto sobre a disponibilidade.

Exemplos

As seguintes técnicas DoS e exemplos foram extraídos da OWASP Testing Guide v2.

DoS Usuário especificado alocação de objeto ~

Se os usuários podem fornecer, direta ou indiretamente, um valor que irá
especificar quantos de um objeto para criar no servidor de aplicação, e se o
servidor não impõe um limite rígido sobre esse valor, é possível fazer com que o
ambiente possa executar de memória disponível. O servidor pode começar a afetar o
número necessário de objetos, mas se este for um número extremamente grande, pode
causar graves problemas no servidor, possivelmente enchendo toda a sua memória
disponível e danificando o seu desempenho.
O seguinte é um exemplo simples de código vulnerável em Java:

String TotalObjects = request.getParameter(“numberofobjects”);

int NumOfObjects = Integer.parseInt(TotalObjects);
ComplexObject[] anArray = new ComplexObject[NumOfObjects]; // wrong!

DoS entrada do usuário como um contador de loop ~

Similar ao problema anterior de utilização especificada e Atribuição de objeto, se
o utilizador pode, direta ou indiretamente, atribuir um valor que vai ser utilizado
como um contador em função loop, isto pode causar problemas de desempenho no
servidor.
O seguinte é um exemplo de código vulnerável em Java:

public class MyServlet extends ActionServlet {

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
. . .
String [] values = request.getParameterValues("CheckboxField");
// Process the data without length check for reasonable range – wrong!
for ( int i=0; i<values.length; i++) {
// lots of logic to process the request
}
 . . .
}
. . .
}

Como podemos ver neste exemplo simples, o usuário tem o controle sobre o contador
de loop. Se o código dentro do laço é muito exigente em termos de recursos, e um
intruso força a ser executado um número muito elevado de vezes, isso pode diminuir
o desempenho do servidor no tratamento de outras solicitações, causando uma
condição de negação.

DoS armazenar muitos dados em sessão ~

Cuidados devem ser tomados para não armazenar muitos dados em um objeto de sessão
do usuário. Armazenar muita informação na sessão, como grandes quantidades de dados
obtidos a partir do banco de dados, pode causar negação de questões de serviço.
Este problema é agravado se os dados da sessão também é rastreado antes de um
login, como um usuário pode iniciar o ataque, sem a necessidade de uma conta.

DoS bloqueio de Contas de Clientes ~

O primeiro caso de negação de serviço a considerar envolve o sistema de
autenticação da aplicação alvo. A defesa comum para evitar a descoberta de força
bruta de senhas de usuários é bloquear uma conta do uso depois de três a cinco
tentativas frustradas de login. Isto significa que mesmo que um usuário legítimo
foi a fornecer sua senha válida, eles não seriam capazes de entrar no sistema até a
sua conta ser desbloqueada. Esse mecanismo de defesa pode ser transformado em um
ataque DoS contra uma aplicação se não houver uma maneira de prever contas de logon
válidas.
Observe, não é um negócio versus equilíbrio de segurança que deve ser alcançado com
base nas circunstâncias específicas de um determinado aplicativo. Há prós e contras
para as contas de bloqueio, para os clientes poderem escolher os seus próprios
nomes de conta, ao uso de sistemas como o CAPTCHA, e assim por diante. Cada empresa
terá de equilibrar os riscos e benefícios, mas não todos os detalhes dessas
decisões são cobertos aqui.

DoS falha para liberar recursos ~

Se ocorrer um erro na aplicação que impede a liberação em um recurso de uso, pode
se tornar disponível para uso posterior. Exemplos possíveis incluem:

- Uma aplicação bloqueia o ficheiro para escrita, e, em seguida, ocorre uma

exceção, mas não explicitamente fechar e abrir o arquivo
- Vazamento de memória nas línguas em que o desenvolvedor é responsável pelo
gerenciamento de memória, como C & C + +. No caso de um erro, faz com que o fluxo
da lógica normal a ser contornada à memória atribuída não pode ser removida e pode
ser deixada em um estado tal que o coletor de lixo não sabe que deverá ser
recuperado
- Uso de objetos de conexão de um banco de dados onde os objetos não estão sendo
liberados se uma exceção é lançada. Uma série de tais pedidos repetidos podem
causar o aplicativo para consumir todas as conexões de banco de dados, já que o
código ainda irá realizar o objeto DB, e nunca liberar o recurso.

O seguinte é um exemplo de código vulnerável em Java. No exemplo, tanto a ligação e

a CallableStatement devem ser fechadas de um último bloco.

public class AccountDAO {

… …
public void createAccount(AccountInfo acct)
throws AcctCreationException {
 … …
try {
Connection conn = DAOFactory.getConnection();
CallableStatement calStmt = conn.prepareCall(…);
… …
calStmt.executeUpdate();
calStmt.close();
conn.close();
} catch (java.sql.SQLException e) {
throw AcctCreationException (...);
}
}
}

DoS sobrecarga de memória ~

Qualquer linguagem onde o desenvolvedor tem a responsabilidade direta pelo
gerenciamento de alocação de memória, mais notavelmente C & C + +, tem o potencial
para um buffer overflow (uma sobrecarga de memória). Embora o risco mais grave
relacionado a um buffer overflow é a capacidade de executar código arbitrário no
servidor, o primeiro risco vem da negação de serviço que pode acontecer se o
aplicativo falha.
O seguinte é um exemplo simplificado de código vulnerável em C:

void overflow (char *str) {

char buffer[10];
strcpy(buffer, str); // Dangerous!
}

int main () {
char *str = "This is a string that is larger than the buffer of 10";
overflow(str);
}

Se este exemplo de código for executado, causaria uma falha de segmentação e núcleo
de despejo. A razão é que strcpy iria tentar copiar 53 caracteres em uma matriz de
apenas 10 elementos, substituindo posições de memória adjacentes. Embora este
exemplo acima seja um caso extremamente simples, a realidade é que em um aplicativo
baseado na web pode haver lugares onde a entrada do usuário não é verificada de
forma adequada para o seu comprimento, tornando este tipo de ataque possível.