martes, 24 de marzo de 2015

INCIDENCIA 24/3/2014: Virus Cryptolocker secuestra datos

Esta mañana me he encontrado con uno de esos días "divertidos" de los departamentos de IT.

Alguien ha decidido que era un buen día lanzar un ataque masivo del virus Cryptolocker, como mínimo no lo ha hecho en lunes o en fin de semana, es todo un detalle. Este virus responde a la categoría de ransomware, que básicamente lo que hace es impedir de alguna manera que trabajes o tengas acceso a tu equipo y te fuerza a pagar un rescate para recuperarlo.

El ciclo de vida del virus es el siguiente: 


El usuario recibe un email de un dominio @supportpiece.com con el asunto "carta certificada no entregado a usted" y que tiene que ir a recogerla o pagar una multa de unos 7€ .

08/04/2015 EDITADO: Durante el dia de hoy hemos detectado una nueva oleada del virus enviado desde los dominios @sda-poste.net y @sda-courier.com .

El email parece que se ha colado a traves de la mayoría de los servicios de antispam.


Como es lo mas normal del mundo, la gente hace click en alguno de los links y descarga el virus en cuestión. 

Parece que el ejecutable tambien se les ha colado a la mayoria de antivirus. 

Una vez infectado el equipo, un proceso que cifrará con RSA de 2048bits todos los archivos de Office que encuentre en el equipo y en las unidades de red. 

Allá donde haya pasado el virus cifrando archivos dejará un documento .txt y un .html indicando que te han secuestrado los archivos y que para poder recuperarlos tienes que pagar 299€  a través de un enlace a la red TOR, facilitando las instrucciones para instalar un navegador TOR donde podremos conectarnos y poder pagar el rescate. 


Que hacer como Admin? 

  • Detectar y bloquear los posibles orígenes de los emails.
  • Informar a todo el personal de la empresa que no abran este correo. 
  • Estar a punto para cuando las empresas de antivirus saquen la firma de este nuevo virus y actualizar todos los equipos lo antes posible. 


Y para los equipos ya infectados?

Según parece no queda otra que esperar a la actualización del antivirus para detectar y eliminar el Cryptolocker. 
Para los archivos no he visto ninguna herramienta segura que permita descifrarlos, y las que he visto no tienen buena pinta, así que parece que habrá que tirar de copias de seguridad. 

Como se podría haber evitado?

Por lo que parece, el email se ha colado a través de los antispam y el antivirus ha permitido ejecutarlo, así que las herramientas habituales de prevención no han hecho bien su trabajo. 
Se me ocurren soluciones pero ninguna user-friendly: A parte de sustituir el email por palomas mensajeras o dar manoplas a los usuarios, una buena configuración de las directivas que solo permitiere ejecutar los archivos autorizados podría haber evitado esto.



ANEXO 1:

Solo por curiosidad añado una captura de la web a la que te redirigen para pagar el rescate:


ANEXO 2: 

08/04/2015 EDITADO: Durante el dia de hoy hemos detectado una nueva oleada del virus enviado desde los dominios @sda-poste.net y @sda-courier.com .

27/04/2015 EDITADO: Voy a añadir un listado con los dominios que he detectado que se usan para entregar este ransomware:
@supportpiece.com
@sda-poste.net
@sda-courier.com
@ppt-takip.com
@ppt-takip.net 
@sda-courier.biz 
@sda-courier.nfo 
@sdacourier.net 
@sdacourier.org 
@ptt-esube.com 
@ptt-gonderi.net 
@ptt-gonderi.biz  

viernes, 20 de marzo de 2015

Como gestionar las máquinas virtuales de Java de forma centralizada

No creo que diga ninguna mentira si afirmo que uno de los mayores dolores de cabeza de los Admins son las aplicaciones y webs con módulos de Java. Las directivas de seguridad, la poca integración con las políticas de sistema, el constante cambio de versiones y de criterio convierte en una quimera conseguir que Java se comporte en toda la organización.

Un compañero me ha pasado para el blog el manual que ha creado el para poder gestionar la configuración de Java:

Lo primero que hay que hacer es tener instaladas las versiones de 32 o 64 bits de la Máquina Virtual de Java.

Una vez instaladas las dos versiones, hay que crear el directorio C:\WINDOWS\SUN\Java\Deployment .

Dentro de esta carpeta crear dos archivos Deployment.config y Deployment.properties con los siguientes parámetros:

Deployment.config
deployment.system.config=file\:C\:/Windows/Sun/Java/Deployment/deployment.properties
deployment.system.config.mandatory=true

Deployment.properties
deployment.javaws.shortcut=never
deployment.security.level=MEDIUM
deployment.security.mixcode=DISABLE
deployment.javaws.autodownload=never
deployment.expiration.check.enabled=false
deployment.expiration.check.enabled.locked
deployment.expiration.decision.suppression=true
deployment.expiration.decision.suppression.locked
deployment.expiration.decision=NEVER
deployment.expiration.decision.locked
deployment.user.security.exception.sites=c\:/Windows/Sun/Java/Deployment/exception.sites
deployment.system.security.trusted.certs=C\:\\Windows\\Sun\\Java\\Deployment\\trusted.certs

exception.sites
<URL QUE QUEREMOS AÑADIR COMO EXCEPCION>

trusted.certs
< Este archivo contiene los certificados de cada URL que queremos añadir para confiar. Este se genera en la carpeta c:\Users\<usuario> \AppData\LocalLow\Sun\Java\Deployment\security al entrar en la web y aceptar el Applet Java. Hay que copiarlo en cada equipo. >

Una vez creado la lista de excepciones que permiten que los applets de java se ejecuten, nos encontramos con los molestos mensajes de advertencia al intentar abrirlos. Yo he contado 5 mensajes de advertencia al abrir la consola de gestión de una VNX de EMC, un infierno...


Para evitar que aparezcan mensajes de advertencia como el anterior tenemos que configurar un conjunto de reglas en las que añadiremos todas las URLs que queremos permitir ejecutar sin preguntar al usuario.

Para poder configurar el ruleset tenemos que crear un archivo ruleset.xml y firmarlo con un certificado para poder distribuirlo en todos los equipos.

ruleset.xml
<ruleset version="1.0+">
<rule>
<id location="http://*.lasendadeladmin.com" />
<action permission="run" />
</rule>
<rule>
<id location="https://*.aeat.es" />
<action permission="run" />
</rule>
<rule>
<id />
<action permission="default">
<message>Este applet ha sido bloqueado por Java. Por favor contacte con su departamento de informatica para recibir ayuda.</message>
</action>
</rule>
</ruleset>

El siguiente paso es copiar este ruleset.xml donde tengamos el SDK (pe. C:\Program Files\Java\jdk1.7.0_71\bin) para poder firmar el archivo y empaquetarlo en un .JAR .

Crear Keystore


Antes de continuar, hay que crear un keystore si no lo teníamos creado de antes. Los pasos para crearlo son los siguientes.

> keytool -genkey -keyalg RSA -alias Areasselfsigned -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks" -storepass 123456 -validity 9000 -keysize 2048

Donde 123456 es el password para desbloquear el keystore (no confundir con el password del certificado).

Exportamos el certificado con el comando:
> keytool -export -alias Corporateselfsigned -file c:\Corporateselfsigned.crt -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks"
Y lo importamos como entidad certificadora (CA) :
> keytool -importcert -alias Corporateselfsigned -file c:\Corporateselfsigned.crt -trustcacerts -keystore "C:\Program Files\Java\jre7\lib\security\cacerts"
El password por defecto es changeit  


Y podemos distribuir el cacerts del equipo que estamos trabajando en los del resto de servidores y equipos, machacando el que pueda existir en el equipo de destino. Hay que copiarlo en la siguiente ruta:
C:\Program Files (x86)\Java\jre7\lib\security (es necesario copiarlo en la de 32bits)

Ahora que tenemos el certificado y ya lo tenemos distribuido en los equipos de destino podemos proceder a crear el paquete de distribución y firmarlo:

Creamos el jar:
> jar -cvf DeploymentRuleSet.jar ruleset.xml

Y lo firmamos con nuestro certificado:
> jarsigner -verbose -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks" -signedjar C:\DeploymentRuleSet.jar DeploymentRuleSet.jar Corporateselfsigned
En cada servidor y equipo de destino hay que copiar este DeploymentRuleSet.jar en la carpeta:

C:\Windows\Sun\Java\Deployment

Modificaciones en el ruleset.xml


Si más adelante es necesario modificar el ruleset.xml para añadir más url, hay que añadir las reglas al archivo y volver a crear, firmar y distribuir un nuevo DeploymentRuleSet.jar:
> jar -cvf DeploymentRuleSet.jar ruleset.xml
> arsigner -verbose -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks" -signedjar C:\DeploymentRuleSet.jar DeploymentRuleSet.jar Corporateselfsigned





miércoles, 11 de marzo de 2015

Como eliminar un servidor Exchange 2007 caído


Esta semana me he decidido ha hacer limpieza del AD y dejarlo todo listo para preparar la migración a Exchange 2013.

Tenia un servidor de Exchange 2007 que no retiramos de forma limpia y aun tenia información en el Active Directory. Para poder eliminar la información de Active Directory, se suelen dar dos métodos:

A) "El limpio" recuperar el servidor Exchange caído con setup.com /M:RecoverServer y posteriormente desinstalarlo.
B) "El sucio" podar el árbol del AD con el ADSI Edit

Como para ser brutos siempre se está a tiempo, empecé (y más o menos acabe) con la método limpio.

Como Recuperar un servidor Exchange 2007 caido para despúes eliminarlo


1. El primer paso és la recuperación en sí.

Los requisitos son:
  • Sistema Operativo Windows 2003 o 2008 (el R2 da problemas). 
  • Mantener la misma IP del servidor que queremos recuperar.
  • Usar el mismo nombre NETBIOS del servidor que queremos recuperar. 
  • Tambien es necesario instalar los Roles y Características que necesita el Exchange 2007. 
Para instalar abrimos un powershell y lanzamos el siguiente comando:
> Import-Module ServerManager
> Add-WindowsFeature RSAT-ADDS,Web-Server,Web-Metabase,Web-Lgcy-Mgmt-Console,Web-Dyn-Compression,Web-Windows-Auth,Web-Basic-Auth,Web-Digest-Auth,RPC-Over-HTTP-Proxy;

2. Cumplidos los prerequisitos, lanzamos el ejecutable de Exchange 2007 con el comando:
> Setup.com /M:RecoverServer
Esto instalará los roles que tenia asignados el servidor que falló, en mi caso el de Mailbox. Durante los checks tal vez indique que le falte alguna unidad (ese fue mi caso), solo tuve que montar un disco virtual y asignar las letra que indicada a cada volumen.



3. Una vez completado la recuperación, reiniciamos el servidor.

4. Si no quedan flecos sueltos, eliminar el rastro del Active Directory tiene que ser tan sencillo como desinstalar el Exchange 2007 desde el panel de control de Windows.

Como nunca nada es tan sencillo como lo pintan, yo me encontré con varios problemas desde al principio hasta el final y tuve que utilizar el ADSI Edit para solucionar alguno de ellos.