共用方式為

Office 365: Precisamos Falar Sobre Segurança

  • 發行項

By: Caio Ribeiro César

Este post irá comentar algumas atualizações/funcionalidades de Compliance já disponíveis para administradores de O365. Iremos também discutir quais os cenários de Segurança mais comuns no dia a dia do suporte.

SecureScore

  • Alguns clientes solicitam ao time de suporte um feedback para “melhorar” a segurança da organização. O Secure Score é uma ferramenta que irá fazer uma análise inicial para os administradores – levantando quais serão as melhorias recomendadas. A ferramenta pode ser executada com uma conta de administrador do O365, acesso disponível em: securescore.office.com.

Auditoria no Exchange Online

Já discutido anteriormente, mas vamos relembrar:

a) Auditing: como habilitar?

b) Mailbox Audit, como expandir?

  • Para validar se as mailboxes possuem Mailbox Audit habilitado + exportar o valor de ExchangeGuid:

Get-Mailbox -ResultSize Unlimited | where {$_.AuditEnabled -match "false"} | fl ExchangeGuid

Posteriormente, o administrador pode executar um .ps1 com o resultado de ExchangeGuid para habilitar MailboxAudit nas mailboxes que não possuem a feature habilitada.

  • Por padrão, assim que o Mailbox Audit é habilitado, as tags abaixo são monitoradas:

“Update,SoftDelete,HardDelete,SendAs,Create” se o administrador deseja expandir as tags monitoradas, utilize o cmdlet Set-Mailbox (exemplo abaixo):

Set-mailbox auditedmailbox -AuditDelegate update,softdelete,harddelete,sendas,create,folderbind

  • As entradas antigas de Mailbox Audit (+90 dias) são removidas automaticamente. O limite de dias pode ser aumentado via Cmdlet:

Set-mailbox mailbox -AuditlogAgeLimit 24855.03:14:07

Para todas:

Get-Mailbox -ResultSize Unlimited | where {$_. AuditlogAgeLimit -match "90.00:00:00"} | fl ExchangeGuid > exchangeGuidlist.log

Crie um .ps1 para “Set-mailbox ExchangeGuid* -AuditlogAgeLimit 24855.03:14:07”

*utilizando os valores de exchangeGuidlist.log

c) Como coletar os logs?

Os logs de Mailbox Audit estão localizados em cada mailbox, especificamente no path “/Recoverable Items/Audits ” .

Isso é “invisível” para o usuário final – O365 irá coletar os logs e então armazenar em uma database única (UnifiedAuditLogDatabase) que também é utilizada pelo Azure, ExO Admin Audit, OneDrive,Sharepoint Online.

d) Role Based Access Control. Como posso segregar as roles dos usuários que podem acessar os logs de Auditoria de Mailbox?

  • Pshell: Direct Role assignment via New-ManagementRoleAssignment -Role "Audit Logs" -User <Identity>  ou
  • EAC: Pre-Created RBAC Groups (Exchange Admin Center > Permissions > Admin Roles). Adicione os membros de Compliance para o grupo “Compliance Manager” ou
  • EAC: Crie um novo grupo com a Role “View-Only Audit Logs”.

Pentesting O365

É comum para o suporte receber ligações de parceiros ou clientes, com um report de Pentest/Vulnerability Assessment com ferramentas de terceiros (BackTrack, Cain, Meta Framework, Nessus, entre outros). Antes de efetuar a abertura de um chamado de suporte para uma análise dos relatórios, leve sempre em consideração:

  • Um Penetration Test bem feito é aquele em que o atacante (neste caso, o analista de segurança) entende por completo os relatórios da ferramenta. Existem falsos positivos e cenários em que a segurança é feita em outras camadas fora do O365 (network, patches, cultura de usuários finais);
  • Conhecimento sobre as leis imutáveis de segurança. Teoria antes da prática, este conhecimento é necessário antes de tomar qualquer ação em relatórios de Vulnerability Assessment;
  • O cenário mais comum é um ataque MitM (man in the middle) em que as senhas dos usuários finais são obtidas. Vamos elaborar abaixo como o MitM funciona (não somente para o ambiente O365, mas ataques em protocolos com ou sem SSL).

MitM

A principal funcionalidade das ferramentas de sniff é o Arp Poison Routing [APR]. Um ataque para a captura de sessões criptografadas como https/ldaps/sftp/ssh irão funcionar com o APR. Neste artigo, irei focar na ferramenta mais comum em um MitM, mas não se limita a somente esta ferramenta (temos diversas tools que podem ser utilizadas).

Em um APR, é esperado: “it enables sniffing on switched networks and the hijacking of IP traffic between hosts”. O APR é um requisito do ataque feito no teste, Man in the Middle (MitM) – temos o computador da vítima efetuando um reroute de pacote HTTPS para a ferramenta. Ou seja, um spoof de informações para que o host do atacante fique no meio da comunicação e consiga interceptar os dados.

Para que o APR funcione, o atacante deve saber a associação de IP vs. MAC > utilizando-se o scan MAC feature da tool para a obtenção de dados.

Assim que temos o “setup” concluído e a tool efetuando um MitM, temos o chamado “certificate injection * ” que se baseia em um spoof de certificado consumido pelo usuário final que consequentemente tem sua senha coletada pelo atacante. Vamos então aos fatos:

  1. Os pacotes enviados pelo Outlook para o O365 são criptografados. Um sniff sem certificate injection não coletará informações em plain text. O ataque não demonstra uma falha de segurança do produto ou na arquitetura de comunicação do Outlook com o Exchange Online;
  2. O mesmo ataque HTTPS para o Outlook irá funcionar via browser caso o certificado seja consumido na sessão. O MitM somente irá funcionar em um https attack com o certificate spoofing;
  3. Se o usuário final utilizar uma rede externa que está vulnerável, temos os mesmos resultados. A questão é o atacante possuir acesso para 1) spoof, 2) certificate injection, 3) sniff e também ao usuário final aceitar o certificado inválido na conexão. É uma lei imutável de segurança: Law#1: If a bad guy can persuade you to run his program on your Computer, it’s not solely your computer anymore;
  4. O ataque funciona em etapas, tanto quanto a proteção deste ataque - se o IDS/IPS pode proteger em questão de spoof/injection a nível de network, o MFA iria proteger o resultado final – obtenção de acesso de dados (neste caso, emails):

a) The HTTPS filter is enabled by the user in the configuration dialog
b) APR is enabled by the user using the button on the toolbar -> the Man-in-the-Middle   attack is ready
c) The victim client starts a new session to an HTTPS enabled server
d) Packets from the client are hijacked by APR and captured by Cain's sniffer by mean    of Winpcap driver
e) APR-HTTPS search for a fake certificate associated to the requested server in the Certificate Collector; if present the certificate will be used if not it will be automatically downloaded, properly modified and stored locally for future usage .
f) Packets from the victim are modified so that they are re-directed to the local acceptor      socket; modifications are made on MAC addresses, IP addresses and TCP source ports (Port Address Translation "PAT" is used to handle multiple connections). The data captured is then sent again into the network using Winpcap but it is this time addressed to the local socket that will accept the Client-side connection.
g) The Server-side socket is created and connected to the real server requested by the victim.
h) OpenSSL libraries are used to manage encryption on both sockets using the fake    certificate victim-side and the real certificate sever-side.
i) Packets sent by the Client-side socket are modified again to reach the victim's host.
j) Data coming from the server is decrypted, saved to session files, re-encrypted and   sent to the victim host by mean of the Client-side socket.
k) Data coming from the client is decrypted, saved to session files, re-encrypted and   sent to the server by mean of the Server-side socket.

Although it can be noticed from the fake certificate file used, this kind of attack is STEALTH from a client point of view because the victim thinks to be connected to the real server; try a "netstat -an" on the client to check yourself.

Once decrypted, traffic from the client is also sent to the HTTP sniffer filter for a further analysis on credentials.

Este tipo de ataque funciona para qualquer ferramenta/app e não se limita ao Outlook. O mais comum é um ataque http/https para obtenção de informações consumidas pelos browsers.

*IDS/IPS, se bem configurados, podem detectar certificate injection para a máquina que sofre o ataque (anomaly based detection) ou também detectar um hop a mais nesta comunicação (via Host Intrusion Detection: HIDS feature) e logo bloquear o ataque. Em um ataque sem SSL (ex. http), não é necessário a utilização de certificate injection.

O usuário final também deve ser levado em consideração, pelo fato de termos o aceite de um certificado inválido para que um ataque MitM com SSL funcione.

Want this post to be translated? Please comment below.

Comments

  • Anonymous
    December 08, 2016
    Great post CaioThank you for sharing Would it great to also have it completely in English :)Btw... about Secure Score tool In case sharing this data is needed but we don't want to give admin permissions.Any plans to make the results exportable?
    • Anonymous
      December 09, 2016
      The comment has been removed