terça-feira, 17 de maio de 2016

Deu a louca no instrutor: Combo gravações cursos OSSEC + Snort por R$250,00.

Caros,



Deu a louca no instrutor!!! Visando a nova geração dos curso com novos conteúdos e aventuras, estamos liquidando a venda do combo das gravações OSSEC + SNORT por APENAS R$250,00. São praticamente 65h de curso gravado.

A promoção é válida com pagamento via DOC/TED e compras/pagamento até domingo dia 22/05.

Oportunidade única antes dos novos cursos no segundo semestre com a Clavis.

Curso OSSEC

1. Entendo funcionamento OSSEC HIDS x NIDS
   1.1. Funcionalidades OSSEC
   1.2. Modos instalação
   1.3. Sistemas suportados
 

2. Instalando o OSSEC
   2.1. Requisitos
   2.2. Modos instalação Local / Agente / Servidor
   2.3. Replicando instalação
 

3. Configurações OSSEC
   3.1. Cliente e Servidor
   3.2. Alertas
   3.3. Regras
 

4. Decoders/Regras
   4.1. Entendendo os Decoders
   4.2. Entendendo as Regras
   4.3. Linkando decoders e regras
 

5. Sistema de Integridade e detecção de rootkits
   5.1. O que é um rootkit?
   5.2. Como funciona a detecção de rootkit do ossec
   5.3. Monitorando a integridade de seu sistema (HIMS)


6. Active Response
   6.1. Active Response disponíveis
   6.2. Configuração de Active Response
   6.3. Ferramentas Active Response
 

7.Usando interface web
   7.1. Instalando a interface web
   7.2. Analisando e pesquisando eventos
 
8. Integração básica Elastic Search / Kibana 

Curso Snort


1-) Introdução a protocolos
2-) Mundo IDS ( NDIS, HIDS , WIDS , KIDS)
3-) Atacantes
4-) Como funciona o Snort
5-) Entendendo a aquisição de dados (DAQ)
6-) Posicionamento dos sensores
7-) Decoders
8-) Preprocessadores (teoria e prática)

       - Frag3
       - Stream5
       - sfPortScan
       - SMTP/POP/IMAP
       - Arp Spoof
       - HTTP Inspect
       - DCE/RPC2
       - Sensitive Data
       - IP Reputation

9-) Analise de performance
        - Performance das regras
        - Performance dos preprocessadores
        - Performance pacotes


10-) Output
         - Syslog
         - Unified 2

11-) Host Attribute Table
12-) Configurações Múltiplas
13-) Escrevendo e lendo regras para o Snort
         - Básico
            - Cabeçalho
            - Opções de Regra
         - Genericas
         - Payload
         - Non-Payload
         - Após detecção / Resposta Ativa

14-) Regras Shared Object
15-) PulledPork – Atualização de Regas
16-) Interface de Gerenciamento de Alertas / Dicas de analise de incidentes – Snorby
17-) Dicas finais

Total de praticamente 65h de gravações bem práticas, com teoria e laboratórios.

Interessado entrar em contato spooker@gmail.com


Happy Detection!

Rodrigo Montoro!

quinta-feira, 17 de março de 2016

Windows EventID 4688 (Process Creation) - Adicionando comando todo no evento

Como muitos sabem, temos investido bastante tempo e pesquisa nos eventos do Windows (EventIDs) aqui na Clavis. No caso, um que chama atenção por fornecer bastante informação é o eventid 4688, que se refere a criação de novos processos, o qual muito utilizado por um atacante com acesso a máquina.



Se repararmos nesse evento, notaremos que a parte do Command Line está vazia, pois essa opção não sei por qual motivo não vem habilitada por padrão e ela que realmente faz todo o diferencial para um analista de segurança diferenciar comandos maliciosos ou não (logicamente exemplo bem simplista aqui).

Abaixo duas tabelas baseados apenas no NewProcess e no CommandLine completo para os mesmos eventos, isso em uma máquina laboratório com minimo acesso no momento, porém máquina de testes. Da pra se notar como a quantidade de informação é BEM diferentes com e sem o KB, lembrando que as infos se completam, pois no New Process Name tem o Path completo do caminho, o que pode ser o indicador do processo malicioso também.


Mapeando somente Novo Processo



Mapeando o Command Line



Para ter essa opção, precisa instalar um kb e habilitar após isso no template para envio do comando completo. Abaixo os links possuem isso muito bem explicado.

Caso faça monitoramento dos novos processos, certamente aplicar esse KB é bem interessante e se não faz o uso de monitorar esse evento, realmente recomendo. Nós utilizamos para armazenar o Elastic Stack no caso.


E para finalizar, não sei porque esse kb e templates não vem habilatidos por padrão, será consumo de recursos ? ** Atualizado - Bem lembrado pelo Sieira, algumas aplicações infelizmente chamam o command line com usuario/senha e vem desabilitado por padrão.



Happy Detection!

Rodrigo "Sp0oKeR" Montoro

terça-feira, 8 de março de 2016

Utilizando Malware Patrol MD5 list com o Suricata IDS

O Suricata dentro vários vetores de detecção, possui uma função bem interessante, onde ele calcula o md5 de arquivos sendo enviados/recebidos e o compara com uma lista de md5 maliciosas. Aqui demonstrarei como utilizar a lista do Projeto Malware Patrol.

O Projeto Malware Patrol, apesar do nome em inglês foi criado e é desenvolvido na sua maioria pelo brasileiro André Correa. O projeto possui uma versão gratuita e uma versão paga, que é um investimento bem pequeno e necessário para ter acesso a lista MD5. Para saber mais sobre o projeto acesse http://malwarepatrol.net .

No site do Suricata, na parte de documentação, temos uma boa parte falando sobre detecção de arquivos on the fly, mas no nosso caso usaremos a parte MD5

Retirado do site https://redmine.openinfosecfoundation.org/projects/suricata/wiki/File-keywords
 
filemd5

Match file MD5 against list of MD5 checksums.

Syntax:
filemd5:[!]filename;

The filename is expanded to include the rule dir. In the default case it will become /etc/suricata/rules/filename. Use the exclamation mark to get a negated match. This allows for white listing.

Examples:
filemd5:md5-blacklist;
filemd5:!md5-whitelist;

File format

The file format is simple. It's a text file with a single md5 per line, at the start of the line, in hex notation. If there is extra info on the line it is ignored.

Output from md5sum is fine:
2f8d0355f0032c3e6311c6408d7c2dc2 util-path.c b9cf5cf347a70e02fde975fc4e117760 util-pidfile.c 02aaa6c3f4dbae65f5889eeb8f2bbb8d util-pool.c dd5fc1ee7f2f96b5f12d1a854007a818 util-print.c

Just MD5's are good as well:
2f8d0355f0032c3e6311c6408d7c2dc2 b9cf5cf347a70e02fde975fc4e117760 02aaa6c3f4dbae65f5889eeb8f2bbb8d dd5fc1ee7f2f96b5f12d1a854007a818



Entendido o funcionamento, precisará ter sua conta no Malware Patrol para baixar a lista de MD5 (hoje por volta de 70 mil hashes)

Basicamente, terá vinculado com sua conta, uma URL para  "Suricata IDS / IPS - malicious MD5s"

#Diretório das regras

[root@centos-7-x64 ~]# cd /opt/suricata/etc/suricata/rules/

# Baixando arquivo de md5

[root@centos-7-x64 rules]# wget "https://lists.malwarepatrol.net/cgi/getfile?receipt=" -O suricatamd5.txt
--2016-03-07 12:52:22--  https://lists.malwarepatrol.net/cgi/getfile?
Resolving lists.malwarepatrol.net (lists.malwarepatrol.net)... 104.20.78.76, 104.20.77.76, 2400:cb00:2048:1::6814:4e4c, ...
Connecting to lists.malwarepatrol.net (lists.malwarepatrol.net)|104.20.78.76|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘suricatamd5.txt’


Header md5 downloaded

#
#        Malware Patrol - Block List - https://www.malwarepatrol.net
#        List for Suricata IDS / IPS
#        Generated at: 20160308105602 UTC
#
#     Please do not update this list more often than every hour.
#
#       Copyright (c)  2016 - Andre Correa - Malware Patrol - Malware Block List
#       This information is provided as-is and under the Terms and Conditions
#       available in the following address:
#
#       https://www.malwarepatrol.net/terms.shtml
#
#       Using this information indicates your agreement to be bound by these
#       terms. If you do not accept them, please delete this file immediately.
#
#       You can report false positives or broken rules/signatures to:
#       fp (a t) malwarepatrol.net

Com isso, precisamos criar uma regra e apontar para esse arquivo.

Criei um arquivo específico para ele, mas você pode adicionar no local.rules também.

# cat malwarepatrol.rules

alert http any any -> any any (msg:"FILE MD5 Check against Malware Patrol blacklist"; filemd5: suricatamd5.txt; sid:10203040; rev:1;)

Após essa regra, precisaremos finalizar a configuração do arquivo config

# vim /opt/suricata/etc/suricata/suricata.yaml

Adicionaremos na parte de rules-files a entrada com o nome da nossa regra.

# Set the default rule path here to search for the files.
# if not set, it will look at the current working dir
default-rule-path: /opt/suricata/etc/suricata/rules
rule-files:
 - malwarepatrol.rules
 - botcc.rules
 - ciarmy.rules

Feito isso, basta reiniciar o processo e fazer download de algum arquivo malicioso listado lá.

Quando iniciando o processo terá nos logs:

7/3/2016 -- 06:50:10 - - Loading rule file: /opt/suricata/etc/suricata/rules/malwarepatrol.rules
7/3/2016 -- 06:50:10 - - MD5 hash size 3198000 bytes


Exemplo de saída:

eve.json

{"timestamp":"2016-03-06T11:33:00.638110-0500","flow_id":30172784,"in_iface":"eth0","event_type":"alert","src_ip":"69.163.211.36","src_port":80,"dest_ip":"159.203.10.127","dest_port":40818,"proto":"TCP","tx_id":0,"alert":{"action":"allowed","gid":1,"signature_id":10203040,"rev":1,"signature":"FILE MD5 Check against Malware Patrol blacklist","category":"","severity":3}}

fast.log

03/06/2016-11:33:00.638110  [**] [1:10203040:1] FILE MD5 Check against Malware Patrol blacklist [**] [Classification: (null)] [Priority: 3] {TCP} 69.163.211.36:80 -> 159.203.10.127:40818

Outro ponto interessante da função MD5 é que você pode criar md5 dos arquivos sensiveis e monitorar se o mesmo não está sendo enviado para fora, lembrando que checagem md5 vai além do protocolo http.


* Vale lembrar o uso memória é bem pequeno e suporte a milhões de entrada segundo benchmarks sem afetar a performace "Each MD5 uses 16 bytes of memory. 20 Million MD5's use about 310 MiB of memory."

** Não esqueça ver o valor app-layer.protocols.http.libhtp.default-config.response-body-limit, o default é de apenas 100kb. Para Malware Patrol o ideal seria 4mb, porém sempre bom analisar performance.

Happy Detection!

Rodrigo "Sp0oKeR" Montoro

segunda-feira, 1 de fevereiro de 2016

[TIP] - Improving "Elastic Search command line" security and auditing

Hi there!

As we most know, elasticsearch CLI options are very dangerous when somebody logged at shell, even if they are not root in special default installations.

Since Elastic Search 2.X, by default it only bind on localhost, what increase a lot default installation security. But what if an attacker has somehow access to a non-root user ? Besides that how to track this in paranoid mode ?

To ilustrate this better I'll create this laboratory:
- CentOS 7.1
- Elasticsearch 2.X
- auditd
- iptables
- user segregation (counting that people has different users when logging to your system =))

Step One without hardening logged as a non-root user:
[elkuser@eventidlabs ~]$ whoami
elkuser
[elkuser@eventidlabs ~]$
[elkuser@eventidlabs ~]$ curl http://localhost:9200 -v
{
  "status" : 200,
  "name" : "EventID One",
  "cluster_name" : "eventid",
  "version" : {
    "number" : "1.7.4",
    "build_hash" : "0d3159b9fc8bc8e367c5c40c09c2a57c0032b32e",
    "build_timestamp" : "2015-12-15T16:45:04Z",
    "build_snapshot" : false,
    "lucene_version" : "4.10.4"
  },
  "tagline" : "You Know, for Search"
}
As we can see, you could easily run any command since there is no authentication in a default installation (and I dind't add anything to protect ES as a reverse proxy or shield).

But to improve monitoring first we could use audit basic rule:
# auditctl -a exit,always -F arch=b64 -S connect -k ELK
Result will be:
# ausearch -k ELK
type=PROCTITLE msg=audit(01-02-2016 21:18:57.770:191034) : proctitle=curl http://localhost:9200 -v
type=SOCKADDR msg=audit(01-02-2016 21:18:57.770:191034) : saddr=inet host:127.0.0.1 serv:9200
type=SYSCALL msg=audit(01-02-2016 21:18:57.770:191034) : arch=x86_64 syscall=connect success=yes exit=0 a0=0x3 a1=0x7f4484000a40 a2=0x10 a3=0x0 items=0 ppid=22817 pid=22842 auid=elkuser uid=elkuser gid=elkuser euid=elkuser suid=elkuser fsuid=elkuser egid=elkuser sgid=elkuser fsgid=elkuser tty=pts1 ses=1187 comm=curl exe=/usr/bin/curl key=ELK

Now to limit access only from a specific user to ES port we will use iptables with owner module (remember to add a group with logstash, elastic and other users you probably need to connect to this port besides root to make less rules).
 # iptables -I OUTPUT -p tcp --dport 9200:9300 -m owner --uid-owner elkuser -j DROP
[elkuser@eventidlabs ~]$ curl http://localhost:9200 -v
* About to connect() to localhost port 9200 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
 And auditd
type=PROCTITLE msg=audit(01-02-2016 21:36:09.016:192757) : proctitle=curl http://localhost:9200 -v
type=SOCKADDR msg=audit(01-02-2016 21:36:09.016:192757) : saddr=inet host:127.0.0.1 serv:9200
type=SYSCALL msg=audit(01-02-2016 21:36:09.016:192757) : arch=x86_64 syscall=connect success=no exit=-115(Operation now in progress) a0=0x4 a1=0x7ffda9338d70 a2=0x10 a3=0x2 items=0 ppid=22817 pid=23071 auid=elkuser uid=elkuser gid=elkuser euid=elkuser suid=elkuser fsuid=elkuser egid=elkuser sgid=elkuser fsgid=elkuser tty=pts1 ses=1187 comm=curl exe=/usr/bin/curl key=ELK
That's not a big deal but we could improve security a bit using those steps. I'm just showing some basic info related to iptables and auditd, specially auditd you could create but of awesome configuration to monitor lot of other stuff as configuration modifications and if user is using sudo to root, you will have auid different from uid.

Besides Elastic Search you could user audit for lot of cool detection and paranoid. I'll create another post in pt_BR about auditd soon.

Good info related to auditd - https://www.digitalocean.com/community/tutorials/understanding-the-linux-auditing-system-on-centos-7

Happy Detection!

Rodrigo "Sp0oKeR" Montoro

domingo, 10 de janeiro de 2016

Feliz 2016!!!! O que vem por ai ....

Caros,

Primeiramente Feliz 2016 com pouco de atraso para todos!!!

Ando meio ausente, porém com várias idéias de posts para fazer e isso voltará a ocorrer conteudo esse ano, sem desculpas, até porque quanto mais posto, mais aprendo. Vamos conectar os pontos e transformar informação em conhecimento, ou eventos em detecções =)

Esse ano, para compartilhar algo aqui, publicamos no Blog da Clavis um artigo juntamente com o podcast + Slides da palestra do (H2HC e JampaSec) com foco no uso do ELK stack para Análise de Logs.

http://www.blog.clavis.com.br/elk-uma-solucao-mais-eficaz-para-o-gerenciamento-de-logs/

2016 será um ano com foco em outros áreas um pouco, digo outras pois temos coisas por vir envolvendo uso de EventID do Windows. Entre os assuntos que postarei, penso:

- Honeypots, criar a série do MHN e projetos relacionados

- Análise de logs (dicas simples até algo mais complexo)

- Hardening

- Detecção de Intrusos
  - Snort e Snort++
  - Suricata
  - Netflow
  - OSSEC
  - WAF

- Elastic Stack (Elastic Search, Kibana, Logstash e o Beats). Criaremos uma série no blog da Clavis, por isso recomendo assinarem lá também =)

- Análise de tráfego (tcpdump, wireshark)

- Machine Learning (isso será aprendizado pra mim e vou compartilhando)

Paralelo a isso, sempre postarei conteúdo e vídeos que ler/assistir, tem muita coisa boa na internet, só precisamos filtrar.

Do resto promessa é dívida e esse ano aguardem por bastante conteúdo, estou em dívida em compartilhar informações.

Aproveitando, estarei no Campus Party em São Paulo nos dias 28 e 29 de Janeiro, se estiverem por lá bora conversar.

Caso tenham alguma sugestão, por favor entre em contato que ser for do meu conhecimento, certamente terei prazer em postar algo.

Happy Detection!

Rodrigo "Sp0oKeR" Montoro