miércoles, 13 de diciembre de 2017

IPv10 ya llego, y yo sin enterarme.

La RFC del protocolo IPv10, publicado en noviembre de 2016, es una interesante lectura (Más información) , que se pasa a resumir teniendo en cuenta, exclusivamente, las mejoras del mismo.

RESUMEN DE ESTA EVOLUCIÓN

Este protocolo es la solución encontrada para fomentar el uso de IPv6 (Más información), haciendo que las comunicaciones entre IPv4 y IPv6 sean posibles, es decir, se ha buscado compatibilidad hacía atrás.

Para ello, y siempre utilizando la estructura del paquete introducido con el IPv6 (*), se adapta las IPv4 a la estructura de IPv6 (**) y el campo "Version" permite nuevos valores (***).

(*)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Estructura del paquete en el protocolo IPv6

(**)
Transformación de direccionamiento IPv4 a IPv6 en el protocolo IPv10.




(***)
Comparación del campo: Versión, entre IPv6 y IPv10


Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia.

jueves, 16 de noviembre de 2017

Comprobación de la red pasada por parámetro al estílo Nmap, pero en "bash"

Por "vaguería" todo el mundo termina automatizando tareas habituales.

El caso que se presenta aquí responde al hecho de generar un script en "bash" que control que el parámetro pasado se corresponde con una dirección de red válida. Por clarificar un poco más, se quiere hacer algo parecido al control que la herramienta NMap posee en referencia a la red pasada.

Ejemplos de parámetros válidos: 192.168.1.0/24, 10.55.22.15/32, 10.0.0.0/8, 125-126.0.0.0/8, 172,174.15.25.66/32, 135.55.15-25.2

Como tampoco se quería copiar y pegar en todos los scripts "bash" a realizar, se tomo la decisión de trabajar con librerías.

¡Correcto!, se puede trabajar con librerías en "bash".

Al final, la librería de nombre: "ComprobarParametros.sh", quedó:

Código de la librería que comprobar el correcto paso de los parámetros en formato CIDR pasados


Para incluir la librería en el script "bash" que se esté desarrollando, se tiene que incluir la sentencia al comienzo del código:

source <ubicación y nombre de la librería>

Un ejemplo para poder usar la librería anteriormente comentada es:

Código de script en bash que utiliza la librería creada anteriormente para el control del parámetro pasado

Ejemplos de parámetros pasados y comprobados:

Ejemplos del control de parámetro pasado


Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia.

jueves, 2 de noviembre de 2017

Hashes SMB, cada vez más fácil obtenerlos.

Hoy quiero hacerme eco de un pequeño aviso por parte de Juan Diego, a través de Packetstorm.com, referido al robo de los hashes de las credenciales de los usuarios de un entorno Windows, siempre y cuando existan carpetas compartidas que reúnan ciertas características.

La noticia que da origen a está entrada es:

https://packetstormsecurity.com/files/144754/ntlm-weakness.txt

Que posteriormente el autor amplía en los siguientes enlaces.

English:    https://www.sysadminjd.com/adv170014-ntlm-sso-exploitation-guide/
Spanish: https://www.sysadminjd.com/adv170014-ntlm-sso-guia-de-explotacion/

Continuando con la exposición comentar que para obtener los hashes de los usuarios de un entorno Windows, necesitamos tener:

1.- Una carpeta compartida en el sistema del que queremos obtener los hashes, esto es muy importante, con permisos de escritura para el usuario que se va a utilizar para conectarse a esa carpeta.
2.- Un archivo con extensión "SCF", convenientemente configurado.

Pero, ¿Qué es un archivo .SCF?

Los archivos SCF(Shell Command File ), fueron introducidos por Microsoft en Windows 3.11, y son archivos de texto plano, que pasan órdenes al Explorador de archivos de Windows para que realice ciertas acciones.

Añadir como curiosidad decir que, este tipo de archivo no tiene ni editor ni visor ni icono asociados.

Continuemos.

Al igual que las noticias por las cuales se escribe está entrada, se ha probado la explotación, para lo cual se ha:

1.-  Creado en una MV una carpeta compartida con permiso de lectura/escritura para todos los usuarios.

Carpeta compartida: PAPruebas

Permisos de la carpeta: PAPruebas


2.- Creado un archivo con extensión ".scf" modificado para hacer que el S.O. envíe los hashes al host que está escuchando, y que obviamente, se controla.

Para ello, en el archivo "scf" indicamos un recurso de red inexistente en la máquina que está escuchando con la intención de que el S.O vaya a visitarla, transfiriendo así los hashes.

Contenido del archivo: Test.scf

NOTA:

Este uso de los archivos ".scf"  recuerda mucho al uso descubierto en 1997 por Aaron Splanger, Mary su variante, descubierta en 2015

http://insecure.org/sploits/winnt.automatic.authentication.html
http://blog.elevenpaths.com/2015/04/aclaraciones-sobre-el-fallo-de-1997-que.html
http://www.hackplayers.com/2015/04/probando-la-vulnerabilidad-smb-redirect.html

Pero la diferencia está en que los anteriores casos se necesitaba la intervención del usuario, mientras que en el caso que nos ocupa, el usuario no entra en juego.

3.- Configurado el módulo: /auxiliary/server/capture/smb, del host con direccionamiento IP: 172.21.5.233, para esnifar los paquetes "smb" recibidos, y almacenarlos en un archivo que con posterioridad serán puestos a disposición del un crackeador para el descubrimiento de la clave en texto claro.


Uso del módulo /auxiliary/server/capture/smb

En sistema Windows podemos utilizar CAIN.

4.- Subido el archivo al recurso compartido con permisos de escritura, por el medio que se desee: uso de smbclient, mediante Copy/Paste en entorno Windows/Linux, etc.

Archivo: Test.scf, subido al recurso compartido: PAPruebas.

El resultado de todo el proceso es la obtención de los hashes de los usuarios de la máquina donde se ha configurado la carpeta compartida.

Hashes de los usuarios

Contramedidas

1.- Instalar un parche opcional, distribuido por Microsoft, para solucionar esta vulnerabilidad, pero sólo vale para  las versiones Windows 10 y Server 2016. Todas las demás versiones seguirán siendo vulnerables a este ataque.

2.- Inhabilitar totalmente esta característica de Windows, parece no ser la mejor opción para solucionar el problema, lamentablemente, parece ser la única salida.

3.- Si se sigue utilizando las carpetas compartidas, se recomienda hacer uso de una política de contraseñas seguras (cambio de contraseñas cada poco tiempo, utilización de contraseñas robustas para complicar el proceso de crackeo, etc), y en la medida de lo posible, permitir sólo la lectura del contenido compartido.

4.- También se puede mejorar la configuración de Windows. Existe un truco poco conocido que permite hacer una lista blanca de con qué servidores SMB nos vamos a comunicar, y evitar enviar credenciales al resto. Primero hay que "Denegar todo" en la opción de seguridad correspondiente. Y luego alimentar la lista blanca de direcciones IP o nombres NetBIOS. 

Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia.

POSTCOMENTARIOS


No se hará mención a la DoS referido en la misma noticia del blog: www.sysadminjd.com.

jueves, 26 de octubre de 2017

¡¡¡DDE localizado y errádicado!!!

Mucho se ha leído y comentado sobre el uso de la tecnología DDE en archivos ofimáticos de Microsoft para su uso en los procesos de infección.

1. https://sensepost.com/blog/2017/macro-less-code-exec-in-msword/ (original)
2. https://www.securitysift.com/abusing-microsoft-office-dde/
3. http://www.hackplayers.com/2017/10/RCE-en-ms-word-sin-macros-con-DDE.html
4.http://blog.segu-info.com.ar/2017/10/macro-less-ejecucion-de-codigo-en.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+NoticiasSeguridadInformatica+%28Noticias+de+Seguridad+de+la+Informaci%C3%B3n%29

La última noticia (de hoy): 5. https://isc.sans.edu/diary/rss/22970.

Al igual que está última noticia, se lleva varios días realizando una pequeña investigación sobre donde se almacena dentro de un documento ofimático la referencia a: DDEAUTO, que sería el indicativo del uso de la tecnología DDE, y como poder detectarla al realizar un análisis estático de un documento ofimático.

Y como se menciona en esta última notica, al abrir un documento  ofimático como si fuera un archivo comprimido, se puede ver que el archivo: Document.xlm, es donde se ubica la referencia a DDEAUTO

Estructura interna del archivo: RFQ-Modificado.doc

Contenido de la carpeta: word, del archivo: RFQ-Modificado.doc


Contenido del archivo: document.xml

Y al igual que los chic@s del sans.edu, otra vez, se ha desarrollado el siguiente código para la detección de tecnología DDE dentro de un archivo ofimático.

Código desarrollado

Ejemplo de detección de la cadena: DDEAUTO

Esta herramienta permitiría detectar de manera estática, si un archivo trabaja con la tecnología DDE o no.

En cualquier caso ...

Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia.


lunes, 23 de octubre de 2017

¡¡¡El proceso de ese ejecutable espía mi intento de infección!!!

Simplemente quiero hacerme eco de la noticias encontradas en los blogs: hackplayers.com (en castellano) y blog.rootshell.be (en inglés y origen del hilo).

En ambas, y para resumir, se comenta que entre los métodos que utilizan muchos de los actuales "malwares" que implementan técnicas anti-debugging y anti-MV, se encuentra la búsqueda de archivos ejecutables relacionados con procesos que podrían indicar al "malware" que están siendo monitorizados y/o debugeados.

El listado de ejecutables que todo "malware" que se precie debería eliminar antes de continuar con la infección, es:

AVK.exe
AVKProxy.exe
AVKService.exe
AVKTray.exe
AVKWCtlx64.exe
AgentSvc.exe
BDSSVC.EXE
Bav.exe
BavSvc.exe
BavTray.exe
BavUpdater.exe
BavWebClient.exe
CertReg.exe
EMLPROXY.EXE
FCDBlog.exe
FCHelper64.exe
FPAVServer.exe
FPWin.exe
FProtTray.exe
FSHDLL64.exe
FSM32.EXE
FSMA32.EXE
FilMsg.exe
FilUp.exe
FortiClient.exe
FortiClient_Diagnostic_Tool.exe
FortiESNAC.exe
FortiFW.exe
FortiProxy.exe
FortiSSLVPNdaemon.exe
FortiTray.exe
GDKBFltExe32.exe
GDSC.exe
GDScan.exe
GdBgInx64.exe
K7AVScan.exe
K7CrvSvc.exe
K7EmlPxy.EXE
K7FWSrvc.exe
K7PSSrvc.exe
K7RTScan.exe
K7SysMon.Exe
K7TSMain.exe
K7TSMngr.exe
K7TSecurity.exe
MCS-Uninstall.exe
MCShieldCCC.exe
MCShieldDS.exe
MCShieldRTM.exe
NS.exe
ONLINENT.EXE
OPSSVC.EXE
PSANHost.exe
PSUAMain.exe
PSUAService.exe
PtSessionAgent.exe
PtSvcHost.exe
PtWatchDog.exe
QUHLPSVC.EXE
SAPISSVC.EXE
SASCore64.exe
SASTask.exe
SBAMSvc.exe
SBAMTray.exe
SBPIMSvc.exe
SCANNER.EXE
SCANWSCS.EXE
SDFSSvc.exe
SDScan.exe
SDTray.exe
SDWelcome.exe
SSUpdate64.exe
SUPERAntiSpyware.exe
SUPERDelete.exe
ScSecSvc.exe
TRAYICOS.EXE
TRAYSSER.EXE
UnThreat.exe
UserReg.exee
VIEWTCP.EXE
VIPREUI.exe
Zanda.exe
Zlh.exe
acs.exe
av_task.exe
avpmapp.exe
bavhm.exe
cmd.exetaskkill/IMnwscmon.exe
coreFrameworkHost.exe
coreServiceShell.exe
econceal.exe
econser.exe
escanmon.exe
escanpro.exe
fcappdb.exe
filwscc.exe
fmon.exe
freshclam.exe
freshclamwrap.exe
fsgk32.exe
fshoster32.exe
fsorsp.exe
fssm32.exe
guardxkickoff_x64.exe
guardxservice.exe
iptray.exe
nanoav.exe
nanosvc.exe
nbrowser.exe
nfservice.exe
njeeves2.exe
nnf.exe
nprosec.exe
nseupdatesvc.exe
nvcod.exe
nvcsvc.exe
nvoy.exe
op_mon.exe
psview.exe
quamgr.exe
schmgr.exe
scproxysrv.exe
trigger.exe
twsscan.exe
twssrv.exe
uiSeAgnt.exe
uiUpdateTray.exe
uiWatchDog.exe
uiWinMgr.exe
utsvc.exe
virusutilities.exe
zlhh.exe

A partir de aquí, se podría elaborar una política en el AV personal/corporativo de cada uno para detectar procesos que intenten eliminar la ejecución vinculada con cada uno de los ejecutables anteriores.
                                                                                                                                                    

Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia.