Quantcast
Channel: Hacking Land :: Hack, Crack and Pentest
Viewing all 1954 articles
Browse latest View live

King Phisher 1.5.2 – Toolkit para campañas de phishing

$
0
0
King Phisher es una herramienta para probar y promover la sensibilización de los usuarios mediante la simulación de ataques de phishing (suplantación de identidad) en el mundo real. Cuenta con una arquitectura fácil de usar pero muy flexible, que permite un control total sobre los correos electrónicos y el contenido del servidor. King Phisher puede ser utilizado para ejecutar las campañas que van desde la formación y concienciación simple hasta los escenarios más complicados en los que se sirven contenidos al usuario para recopilar credenciales.

Descripción general de funciones

- Ejecución de varias campañas de phishing de forma simultánea
- Envío de correo electrónico con imágenes incrustadas para una apariencia más legítima
- Autenticación opcional de dos factores
- Recolección de credenciales de páginas de destino
- Alertas SMS en relación con el estado de la campaña
- Capacidades de clonación de las páginas web
- Comprobación integrada de Sender Policy Framework (SPF)
- Geo localización de visitantes de phishing
- Envío de correo electrónico con invitaciones de calendario


Plugins

Tanto el cliente como el servidor pueden ampliar su funcionalidad mediante plugins. Por defecto King Phisher viene con un pequeño número de plugins y otros adicionales están disponibles en el repositorio de plugins.

Archivos de plantilla (templates)

Las plantillas, tanto para los mensajes como para las páginas de servidor, se pueden encontrar por separado en el repositorio de plantillas de King Phisher. Cualquier contribución con respecto a las plantillas deberá realizarse a través de una petición de pull en el repositorio correspondiente.

Variables de plantilla de mensajes

Las plantillas de mensajes cliente se formatean utilizando el motor de plantillas sde Jinja2 y soportando una serie de variables (puedes ver la wiki para la doc completa):

Nombre de variableValor de la variable
client.company_nameThe target's company name
client.email_addressThe target's email address
client.first_nameThe target's first name
client.last_nameThe target's last name
client.message_idThe unique tracking identifier (this is the same as uid)
sender.emailThe email address in the "Source Email (MIME)" field
sender.friendly_aliasThe value of the "Friendly Alias" field
sender.reply_toThe value of the "Reply To" field
url.tracking_dotURL of an image used for message tracking
url.webserverPhishing server URL with the uid parameter
url.webserver_rawPhishing server URL without any parameters
tracking_dot_image_tagThe tracking image in a preformatted tag
uidThe unique tracking identifier (this is the same as client.message_id)

Documentación

La documentación para los usuarios de la aplicación se proporciona en la página wiki del proyecto. Esto incluye medidas para ayudar a los nuevos usuarios a empezar con sus primeras campañas. La documentación técnica adicional destinada a los desarrolladores se mantiene por separado como se describe en la siguiente sección.

Documentación del código

King Phisher utiliza Sphinx para la documentación técnica interna. Esta documentación puede ser generada desde la fuente con el comando sphinx-build -b html docs/source docs/html. La documentación más reciente está alojada en ReadTheDocs de king-phisher.readthedocs.io.

Licencia

King Phisher está publicado bajo licencia BSD3. Para más detalles consulta el archivo de licencia.

Nota: King Phisher sólo debe ser usado para aplicaciones legales previa obtención del permiso explícito de una organización concreta.

Para obtener la última versión estable consulta las releases del proyecto en GitHub o utiliza git checkout. Para ver las instrucciones sobre cómo instalarlo consulta el archivo de INSTALL.md. Después de la instalación, para obtener instrucciones sobre cómo empezar consulta la wiki.

Proyecto: https://github.com/securestate/king-phisher/

Via:www.hackplayers.com

ir-rescue - A Windows Batch Script To Comprehensively Collect Host Forensic Data

$
0
0

ir-rescue is a lightweight Windows Batch script that collects a myriad of forensic data from 32-bit and 64-bit Windows systems while respecting the order of volatility and artifacts that are changed with the execution of the script ( e.g. , prefetch files). It is intended for incident response use at different stages in the analysis and investigation process. It can be set to perform comprehensive collections of data for triage purposes, as well as customized acquisitions of specific types of data. The tool represents an effort to streamline host data collection, regardless of investigation needs, and to rely less on on-site support when remote access or live analysis is unavailable.

ir-rescue makes use of built-in Windows commands and well-known third party utilities from Sysinternals and NirSoft, for instance, some being open-source. It is designed to group data collections according to data type. For example, all data that relates to networking, such as open file shares and Transmission Control Protocol (TCP) connections, is grouped together, while running processes, services and tasks are gathered under malware. The tool is also purposefully designed not to make use of PowerShell and Windows Management Instrumentation (WMI) in order to make it transversally compatible. The acquisition of data types and other general options are specified in a simple configuration file . It should be noted that the script launches a great number of commands and tools, thereby leaving a considerable footprint ( e.g. , prefetch files) on the system. The runtime varies depending on the computation power and configurations set, though it usually finishes within a maximum of one hour if configured to run fully.

ir-rescue has been written for incident response and forensic analysts, as well as for security practitioners alike. It can thus be used for leveraging the already bundled tools and commands during forensic activities.

Dependencies and Usage
ir-rescue relies on a number of third-party utilities for gathering specific data from hosts. The versions of the tools are listed in the next section and are provided with the package as is and, therefore, their licenses and user agreements must be accepted before running ir-rescue . Their descriptions and organization in the folder tree structure are given below, with both 32-bit and 64-bit versions of the tools included adjacently, if applicable:
  • tools-win\ : third-party tools folder:
    • ascii\ : text ASCII art files in *.txt format;
    • cfg\ : configuration files:
      • ir-rescue.conf : main configuration file;
      • nonrecursive-(acl|iconsext|md5deep).txt : accesschk[64].exe , iconsext.exe and md5deep[64].exe non-recursive locations;
      • nonrecursive.txt : non-recursive locations for multiple tools;
      • recursive-(acl|iconsext|md5deep).txt : accesschk[64].exe , iconsext.exe and md5deep[64].exe recursive locations;
      • recursive.txt : recursive locations for multiple tools;
    • cygwin\ : Cygwin tools and Dynamic Linked Libraries (DLLs):
      • tr.exe : used to cut out non-printable characters;
      • grep.exe : used to filter date with regular expressions;
    • evt\ : Windows events tools:
      • psloglist.exe ;
    • fs\ : filesystem tools:
      • tsk\ : The Sleuth Kit (TSK) tools and DLLs:
        • fls.exe : walks the Master File Table (MFT);
      • AlternateStreamView[64].exe : lists Alternate Data Streams (ADSs);
      • ExtractUsnJrnl[64].exe : extracts the C:\$Extend\$UsnJrnl (NTFS journal) file without the sparsed zeroes;
      • md5deep[64].exe : computes Message Digest 5 (MD5) hash values;
      • ntfsinfo[64].exe : shows information about NTFS;
      • RawCopy[64].exe : extracts data at the NTFS level;
    • mal\ : malware tools:
      • autoruns[64].exe : dumps autorun locations to the autoruns binary format;
      • autorunsc[64].exe : lists autorun locations;
      • densityscout[64].exe : computes an entropy-based measure for detecting packers and encryptors;
      • DriverView[64].exe : lists loaded kernel drivers;
      • handle[64].exe : lists object handles;
      • iconsext.exe : extracts icons from Portable Executables (PEs);
      • Listdlls[64].exe : lists loaded DLLs;
      • pslist[64].exe : lists running processes;
      • PsService[64].exe : lists services;
      • sigcheck[64].exe : checks digital signatures within PEs;
      • WinPrefetchView[64].exe : displays the contents of prefetch files;
    • mem\ : memory tools:
      • winpmem_1.6.2.exe : dumps the memory;
    • misc\ : miscellaneous tools:
      • LastActivityView.exe : displays a timeline of recent system activity;
      • OfficeIns[64].exe : lists installed Microsoft Office add-ins;
      • USBDeview[64].exe : lists previously and currently connected USB devices;
    • net\ : network tools:
      • psfile[64].exe : lists files opened remotely;
      • tcpvcon.exe : lists TCP connections and ports and UDP ports;
    • sys\ : system tools:
      • accesschk[64].exe : lists user permissions of the specified locations;
      • logonsessions[64].exe : lists currently active logon sessions;
      • PsGetsid[64].exe : translates between Security Identifiers (SIDs) and user names and vice-versa;
      • Psinfo[64].exe : displays system software and hardware information;
      • psloggedon[64].exe : lists locally logged on users that have their profile in the registry;
    • web\ : web tools:
      • BrowsingHistoryView[64].exe : lists browsing history from multiple browsers;
      • ChromeCacheView.exe : displays the Google Chrome cache;
      • IECacheView.exe : displays the Internet Explorer cache;
      • MozillaCacheView.exe : displays the Mozilla Firefox cache;
    • yara\ : YARA tools and signatures:
      • rules\ : *.yar rules folder;
      • yara(32|64).exe : YARA main executable;
      • yarac(32|64).exe : YARA rules compiler;
    • 7za.exe : compresses files and folders;
    • screenshot-cmd.exe : takes screenshots;
    • sdelete(32|64).exe : securely deletes files and folders;
  • data\ : data folder created during runtime with the collected data:
    • <HOSTNAME>-<DATE>\ : <DATE> follows the YYYYMMDD format:
      • ir-rescue : folder for ir-rescue -related data
        • ir-rescue.log : verbose log file of status messages;
        • screenshot-# : numbered screenshots;
      • folders named according to the data type set for collection.
ir-rescue needs to be run under a command line console with administrator rights and requires no arguments. It makes use of a configuration file to set desired options. As such, executing the script simply needs the issuing of the Batch file as follows:
  • ir-rescue.bat
Some tools that perform recursive searches or scans are set only to recurse on specific folders. This makes the data collection more targeted while taking into account run time performance as the folders specified are likely locations for analysis due to extensive use by malware. By default, the locations set in tools-win\cfg\recursive.txt for recursive search are the following:
  • C:\Users ;
  • C:\ProgramData ;
  • C:\Windows\Temp ;
  • D: .
In turn, the locations also set in tools-win\cfg\nonrecursive.txt for non-recursive search are the following:
  • C:\Windows\system(32|64) ;
  • C:\Windows\system(32|64)\drivers .
Some of the tools have dedicated files with specific locations to and not to recurse. These are also kept under tools-win\cfg\ and are named recursive-<tool>.txt and nonrecursive-<tool>.txt , with <tool> being changed to the tool name. All these files can be changed with the desired locations for analysis. Each file must have one location as full path per line.
During runtime, all characters printed to the Standard Output ( STDOUT ) and Standard Error ( STDERR ) channels are logged to UTF-8 encoded text files. This means that the output of tools are stored in corresponding folders and text files. Status ASCII messages are still printed to the console in order to check the execution progress. After collection, data can be compressed into a password-protected archive and accordingly deleted afterwards, if set to do so. The password of the resulting encrypted archive is, by default, "infected" without quotes.

Configuration File
The configuration file is composed of simple binary directives ( true or false ) for the general behaviour of the script, for which data types to collect and for which advanced tools to run. Lines preceded by a pound sign are considered comments. These are used to briefly describe what each option does, to enumerate folders, files or registry keys important to provide some context, as well as to list relevant tools.
Essentially, data is grouped into the types given by the following directives:
  • memory : this options sets the collection of the memory;
  • registry : this option sets the collection of system and user registry;
  • events : this option sets the collection of Windows event logs;
  • system : this option sets the collection of system-related information;
  • network : this option sets the collection of network data;
  • filesystem : this option sets the collection of data related with NTFS and files;
  • malware : this option sets the collection of system data that can be used to spot malware;
  • web : this option sets the collection of browsing history and caches;
  • misc : this option sets the collection of miscellaneous data that does not quite fit other options.
On the one hand, the usage of advanced tools set by the sigcheck , density , iconsext and yara options is independent of the configurations made to the collection of data types. On the other hand, directives under the respective main options of the data types are tied to them, meaning that they are disregarded if the main ones are set to false . For example, memory-dump=true , the option that instructs the tool to dump the Random Access Memory (RAM), is ignored if memory=false . The same goes for the <option>-all option, which sets all options of a certain data type to true for convenience. All options not found or commented in the configuration file are set to false during runtime.
Note that the iconsext option is useful to look for binaries compiled with unusual frameworks that set PE icons ( e.g. , Python). Moreover, YARA rules need to have a *.yar file extension and to be put in the tools-win\yara\rules\ folder. The output of all advanced tools are stored under the malware resulting folder.
Below is a minimal example of the configuration file setting the collection of the RAM, system registry and Windows event logs in text format, as well as the compression of the final data folder with password "infected" (without quotes).
# ir-rescue-win configuration file
# accepted values: 'true' or 'false' (exclusive)

# general
killself=false
sdelete=false
zip=true
zpassword=infected
ascii=false

# modules
memory=true
registry=true
events=true

# memory
memory-dump=true

# registry
registry-system=true

# events
events-txt=true

Third-Party Tool List and References
  • Sysinternals : the Sysinternals tools have been mostly developed by Mark Russinovich and are free to use under the Sysinternals Software License Terms . The full list of tools used by ir-rescue is accesschk[64].exe (v6.02), autoruns[64].exe (v13.62), autorunsc[64].exe (v13.61), handle[64].exe (v4.1), Listdlls[64].exe (v3.2), logonsessions[64].exe (v1.4), ntfsinfo[64].exe (v1.2), psfile[64].exe (v1.03), PsGetsid[64].exe (v1.45), Psinfo[64].exe (v1.78), pslist[64].exe (v1.4), psloggedon[64].exe (v1.35), psloglist.exe (v2.71), PsService[64].exe (v2.25), sdelete(32|64).exe (v2.0), sigcheck[64].exe (v2.52), and tcpvcon.exe (v3.01).
  • NirSoft : the NirSoft suite of tools are developed by Nir Sofer and are released as freeware utilities. The full list of tools used by ir-rescue is AlternateStreamView[64].exe (v1.51), BrowsingHistoryView[64].exe (v1.86), ChromeCacheView.exe (v1.67), DriverView[64].exe (v1.47), iconsext.exe (v1.47), IECacheView.exe (v1.58), LastActivityView.exe (v1.16), MozillaCacheView.exe (v1.69), OfficeIns[64].exe (v1.20), USBDeview[64].exe (v2.61), and WinPrefetchView[64].exe (v1.35).
  • Cygwin : the Cygwin project is open-source and is used by ir-rescue only to filter outputs with the tr.exe (v8.24-3) and grep.exe (v2.21) utilities, using the 32-bit DLLs.
  • The Sleuth Kit (TSK) (v4.3.0): the TSK is an open-source forensic tool to analyze hard drives at the file system level, used by ir-rescue only to walk the MFT with fls.exe .
  • 7za.exe (v9.20): 7-Zip is an open-source compression utility developed by Igor Pavlov and release under the GNU LGPL license.
  • winpmem_1.6.2 (v1.6.2): the Pmem suite is part of the open-source Recall memory analysis framework, used by ir-rescue to dump the memory.
  • md5deep[64].exe (v4.4): the md5deep utility is open-source and is maintained by Jesse Kornblum.
  • RawCopy[64].exe (v1.0.0.15) and ExtractUsnJrnl[64].exe (v1.0.0.3): RawCopy (essentially, a combination of ifind and icat from TSK) and ExtractUsnJrnl are open-source NTFS utilities to extract data and special files developed by Joakim Schicht.
  • densityscout[64].exe (build 45): the DensityScout utility to compute entropy was written by Christian Wojner and is released under the ISC license.
  • YARA (v3.5.0): YARA is an open-source signature scheme for malware that can be used to perform scans of specific indicators.
  • screenshot-cmd.exe : screenshot-cmd is an open-source utility released under the BSD-3 license to take screenshots.



Via:www.kitploit.com

Elevación de privilegios en el kernel de Linux

$
0
0
Se ha anunciado una vulnerabilidad que podría permitir elevar privilegios en sistemas Linux. Aunque no se ha aclarado, es posible que se esté explotando de forma activa en la actualidad.

Sigue la moda de poner nombres a vulnerabilidades, en esta ocasión el fallo ha sido bautizado como Dirty Cow (vaca sucia). En este caso Cow hace referencia al uso de la técnica "copy-on-write" que es donde reside el fallo. Nada mejor que un buen nombre, una web rebosante de ironía (https://dirtycow.ninja/) y, por supuesto, un logo atractivo, para que la vulnerabilidad destaque como no lo haría de otra forma. En esta ocasión incluso podemos hablar de… ¡una vulnerabilidad con Twitter!



El problema, con CVE-2016-5195, reside en una condición de carrera en la forma en que el subsistema de memoria del kernel de Linux maneja el concepto "copy-on-write" de mapeados de memoria privada de solo lectura. El fallo existe desde hace 9 años, se introdujo en la versión 2.6.22 (publicada en 2007).

Existe prueba de concepto disponible y también se ha encontrado un exploit que aprovecha la vulnerabilidad, sin embargo no está claro si se está empleando de forma activa. Hay que tener claro que se trata de una vulnerabilidad de elevación de privilegios, por lo que para poder explotarla es necesario tener un acceso local, con privilegios restringidos, en el sistema afectado.

Ya se han publicado una actualización del kernel de Linux que soluciona el problema:
Por otra parte las principales distribuciones como Red Hat, Debian, Ubuntuo SUSE ya han publicado actualizaciones, contramedidas o información sobre el problema.

Más información:

Dirty Cow

Antonio Ropero
Twitter: @aropero




Via:unaaldia.hispasec.com

Winter is Comming: Algunas reflexiones sobre el DDOS que tumbó Twitter, WhatsApp y alertó al mundo

$
0
0
Que Internet se ha metido en nuestras vidas de lleno desde hace unos años está claro tiempo atrás. Familiares y amigos se comunican por los servicios de las redes sociales diariamente, mucho más incluso que en el mundo físico sin necesidad de smartphones y conexiones de datos. Y ayer, muchos de ellos, fueron conscientes de cuánto lo necesitan. Se dieron cuenta que no funcionaba el Twitter, y por tanto los haters no podía desahogarse. Se dieron cuenta de que no funcionaba WhatsApp, y por tanto no podían pasarse memes, pero tampoco funcionaba NetFlix y no podían poner a las niñas a Masha y el Oso para que estuvieran calmados o escuchar música en Spotify mientras hacía running.


Figura 1: "Winter is Comming" Algunas  reflexiones sobre
el DDOS que tumbó Twitter y Whats y alertó al mundo

La lista de servicios - de los masivos - que se vieron afectados fue larga. XBOX, Twilio, Paypal, Play Station Network o CNN también estaban entre los afectados. Y entonces sí, entonces el mundo más allá de los que saben qué es una dirección IPv4 o una dirección IPv6 se empezó a preguntar... ¿Qué está pasando aquí? ¿Qué ha sucedido que sí que está afectando a mi vida?

La respuesta era tan sencilla, como tan difícil de hacer entender a la gente. Fue un ataque DDOS masivo contra los servidores DNS de una de las empresas que dan soporte a muchos de estos servidores y a muchos de los usuarios. Un ataque contra la petición de resolución de nombres que corta el contacto entre los clientes y los proveedores de servicios. Ya está, no funcionan los DNS y la infraestructura de Internet comienza a fallar

Los DNS en Internet

Que los DNS son una pieza clave en la infraestructura de Internet es algo que lo sabemos desde hace mucho tiempo. Si estos están atacados por un DDOS y no pueden resolver los nombres de dominio se acabó la conectividad, pero ya en el pasado hemos visto otros fallos, como el de Dan Kaminsky, que podrían haber tumbado todos esos servicios de igual forma modificando los valores de las respuestas a las direcciones IP.

Internet no nació pensando en todos estos ataques, y muchos servicios han ido evolucionando su funcionamiento añadiendo capas de seguridad sobre los estándares originales, como es el caso del DNS, pero que aún no se ha añadido globalmente en todos los servidores, donde muy pocos utilizan a día de hoy, por poner un ejemplo, DNSEC para firmar las resoluciones de los valores dados. Contra el caso de un ataque DDOS el problema no recae en el servicio DNS, sino en la red en sí. 

Figura 2: Verificación de Web Browser en CloudFlare

Supongamos el caso de un ataque de denegación de servicio contra la página web de una empresa. Si un adversario quiere hacer un DDOS, a nivel de HTTP se puede poner una Cloud por delante que filtre los bots atacantes de los usuarios legítimos, como hace por ejemplo CloudFlare, pero si se hace a los servicios DNS deben ser los routers que procesan las peticiones TCP o UDP sobre las que lleguen las peticiones DNS de resolución las que discriminen si esa petición llega desde una máquina legítima o no. Tarea un poco más compleja.

Un ejemplo de Anti-DDOS

Supongamos que la empresa DYN, objetivo de este ataque concreto, quiere detener este DDOS. Para ello, debe tener un red de protección previa a que el tráfico llegue a sus servidores. Si no fuera así, todo el tráfico del ataque DDOS llegaría hasta su red y, aunque lo detectase y lo descartara con un "drop", las peticiones de servicio no podrían ser procesadas porque el tráfico de llegar hasta el router ya está colapsado. Es decir, el paquete no-malicioso sería como un comprador habitual de un establecimiento que no puede llegar a la puerta del establecimiento porque es día de rebajas y está colapsada la puerta por las personas que vienen a por las ofertas.

Para ello, la empresa debe tener una red previa, proporcionada por el operador que le proporciona las conexiones a Internet, que fuera eliminando - antes de que lleguen a su router - las peticiones. Es decir, supongamos que el supermercado que tiene la puerta colapsada en día de rebajas decide poner en las 4 esquinas de las calles desde las que les llegan los compradores de rebajas cuatro puntos de control. Así, el tráfico masivo de nuevos compradores se dividiría por 4, quedando solo el 25% en cada punto de control. El comprador habitual pasaría uno de esos puntos de control con solo el 25% del tráfico del ataque para que luego, en la puerta de entrada del supermercado solo se encuentre y comparta entrada con otros compradores habituales.

Figura 3: El ataque DDOS a SpamHaus alcanzó 65 GPS

Si el tiempo de cruzar uno de esos cuatro puntos de control fuera aún muy lento, lo que debería considerar el supermercado es en contratar más personas para procesar en menos tiempo el 25% del tráfico que pasa por cada uno de esos puntos de control o crear nuevos puntos de control en una capa más alejada, para conseguir un mayor desglose del tráfico. 

Así es como funcionan los sistemas escudo que dan los ISPs desde la red, utilizando tecnologías como ARBOR para crear lo que se denominan escudos AntiDDOS proporcionados desde la red, que es lo que parece que podría haber hecho DYN para conseguir proteger sus servicios DNS, es decir, llamar a su proveedor de conexiones de red y solicitar la contratación de estos escudos Anti-DDOS desde la red.

¿Cómo se puede conseguir tanta potencia para hacer un ataque DDOS tan fuerte?

Los ataques DDOS a los servidores DNS pueden ser hechos de mucha forma. Ya vimos en el pasado - hace ya unos añitos - como se habían conseguido hacer ataques de gran potencia de tráfico mediante vulnerabilidades de DNS Amplification, como sucedió cuando se produjo el ataque a los servidores de SpamHaus. En ese caso, un spammer enfadado con las listas RBL fue capaz de tumbar los servidores con peticiones DNS por UDP spoofeadas en las que usaba como dirección de origen la de su objetivo para que los propios servidores DNS tumbaran a SpamHaus.

Pero si nos vamos a momentos más recientes, controlando routers, impresoras y equipos Windows, mediante bugs conocidos, exploits públicos, contraseñas por defecto o simple malware desplegado con kits de explotación, hemos visto como un grupo como Lizard Squad era capaz de tumbar en el pasado los servidores Play Station Network y de XBOS y hacer que el propio Kim Dot Com pagara con bonos de Mega para que pudiera seguir jugando a sus juegos.


¿Quién ha podido estar detrás?

Las especulaciones son como siempre de todo tipo. ¿Podría ser Korea del Norte atacando a EEUU para devolver una respuesta proporcionada al ataque de DDOS que sufrió como "castigo" por el ataque a SONY? ¿Podría ser un ataque para meter el miedo contra el voto electrónico? ¿Podría tener algo que ver con las elecciones en EEUU para que se beneficie el mensaje de uno u otro candidato? ¿Podría no ser nada más que una nueva versión de Lizard Squad enfadados por el bloqueo de alguna cuenta en Twitter? ¿Podría ser un ataque de ISIS por esos mismos bloqueos en Twitter

Ahora es tiempo para especulaciones, por supuesto, y para la conspiranoia. Pero si un estado tuviera esta botnet lista - que no dudo que algunos países tengan estas posibilidades - habría que ver si una operación así pone de manifiesto sus cartas. Lo que hemos visto en el pasado es que los ataques entre naciones han sido siempre sibilinos, utilizando 0days que no fueran detectados para evitar que dejaran de ser útiles, porque en el momento que se lanzan, los investigadores pueden descubrir cómo se ha hecho, qué han utilizando y dónde estaba el fallo aprovechado.

Figura 4: El ataque a Brian Krebs superó los 400 GPS con NTP Amplification

Hasta que no tengamos los detalles podría ser cualquiera cosa, pero viendo cómo fue el ataque a Brian Krebs, mi opinión iría más hacia esa dirección. Es decir, hacia alguien que ya tiene esa botnet creada con dispositivos IoT, routers y switches - como hacía la NSA - y que ahora está disfrutando con el uso de la misma en estos ataques DDOS. Me apuesto un camiseta de LUCA o de la FOCA a que en breve veremos más de estos y puede que, incluso los dispositivos de tu casa o de tu empresa sean parte de este ataque.

Saludos Malignos!

Via:www.elladodelmal.com

BBQSQL - A Blind SQL Injection Exploitation Tool

$
0
0

Blind SQL injection can be a pain to exploit. When the available tools work they work well, but when they don't you have to write something custom. This is time-consuming and tedious. BBQSQL can help you address those issues.
BBQSQL is a blind SQL injection framework written in Python. It is extremely useful when attacking tricky SQL injection vulnerabilities. BBQSQL is also a semi-automatic tool, allowing quite a bit of customization for those hard to trigger SQL injection findings. The tool is built to be database agnostic and is extremely versatile. It also has an intuitive UI to make setting up attacks much easier. Python gevent is also implemented, making BBQSQL extremely fast.

Overview of Readme
We tried to write the tool in such a way that it would be very self explanatory when setting up an attack in the UI. However, for sake of thoroughness we have included a detailed Readme that should provide you additional insight on the specifics of each configuration option. One thing to note is that every configuration option in the UI has a description associated with it, so if you do choose to fire up the tool without reading this page you should be able to hack your way through an attack.

High Level Usage
Similar to other SQL injection tools you provide certain request information.
Must provide the usual information:
  • URL
  • HTTP Method
  • Headers
  • Cookies
  • Encoding methods
  • Redirect behavior
  • Files
  • HTTP Auth
  • Proxies
Then specify where the injection is going and what syntax we are injecting. Read on for details.

Install
This should be straight forward, but what ever is. Try running:
sudo pip install bbqsql
If that doesn't work for you, you can install from source. The tool requires gevent , requests .

BBQSQL Options
In the menu you will see a place for BBQSQL options. Here you specify the following options:

query
This is described in greater detail below query syntax overview .

csv_output_file
The name of a file to output the results to. Leave this blank if you dont want output to a file.

technique
BBQSQL utilizes two techniques when conducting a blind SQL injection attack. The first and default technique used is binary_search. See Wikipedia for more information.
The second technique you can use is frequency_search. Frequency searching is based on an analysis of the English language to determine the frequency in which a letter will occur. This search method is very fast against non-entropic data, but can be slow against non-english or obfuscated data.
You can specify either binary_search or frequency_search as the value for this parameter.

comparison_attr
This specifies the type of SQL injection you have discovered. Here you can set which attribute of the http response bbqsql should look at to determine true/false.
You can specify: status_code , url , time , size , text , content , encoding , cookies , headers , or history
If you have identified sql injection that results in a different server status code set 'status_code' here. If the cookie is different set 'cookie'. If the response size is different set 'size'. You get the jist.

concurrency
Concurrency is based on the gevent library in Python. Functionally, it appears to act like threading but the specifics of how this works can be seen in our DefCon talk here [insert link here]. This setting controls the amount of concurrency to run the attack with. This is useful for throttling the requests and speeding up attack times. For really high performance web-servers such as nginx, we have been able to set the concurrency to 75. By default this is set to '30'.

Query Syntax Overview
If you run into a SQL injection vulnerability that has some weird quirks (such as certain characters can't be included or functions like ASCII/CHAR do not work), you have probably found yourself writing some sort of script with your custom injection syntax. BBQSQL takes out the scripting part and provides a way for you to paste in your custom query syntax and exploit with ease.
The query input is where you will construct your query used to exfiltrate information from the database. The assumption is that you already have identified SQL injection on a vulnerable parameter, and have tested a query that is successful.
Below is an example query you can use to construct your query.
In this example, the attacker is looking to select the database version:
vulnerable_parameter'; if(ASCII(SUBSTRING((SELECT @@version LIMIT 1 OFFSET ${row_index}) , ${char_index} ,1))) ${comparator:>}ASCII(${char_val}) WAITFOR DELAY '0\:0\:0${sleep}'; --
The query syntax is based around placeholders which tell BBQSQL how to execute the attack.
You need to provide the following placeholders of information in order for the attack to work. Once you put these in your query, bbqSQL will do the rest:
${row_index} : This tells bbqSQL to iterate rows here. Since we are using LIMIT we can view n number of row depending on ${row_index} value.
${char_index} : This tells bbqSQL which character from the subselect to query.
${char_val} : This tells bbqSQL where to compare the results from the subselect to validate the result.
${comparator} : This is how you tell BBQSQL to compare the responses to determine if the result is true or not. By default, the > symbol is used.
${sleep} : This is optional but tells bbqSQL where to insert the number of seconds to sleep when performing time based SQL injection.
Not all of these place holders are required. For example, if you have discovered semi-blind boolean based SQL injection you can omit the ${sleep} parameter.

HTTP Parameters
BBQSQL has many http parameters you can configure when setting up your attack. At a minimum you must provide the URL, where you want the injection query to run, and the method. The following options can be set:
  • files
  • headers
  • cookies
  • url
  • allow_redirects
  • proxies
  • data
  • method
  • auth
You specify where you want the injection query to be inserted by using the template ${injection} . Without the injection template the tool wont know where to insert the query.

files
Provide files to be sent with the request. Set the value to the path and BBQSQL will take care of opening/including the file.

headers
HTTP headers to be sent with the requests. This can be a string or a dictionary. For example:
{"User-Agent":"bbqsql"} or "User-Agent: bbqsql"

cookies
A dictionary or string of cookies to be sent with the request. For example:
{"PHPSESSIONID":"123123"} or PHPSESSIONID=123123;JSESSIONID=foobar

url
Specify a url that the requests should be sent to.

allow_redirects
This is a boolean that determines wether http redirects will be follwed when making requests.

proxies
Specify an http proxy to be used for the request as a dictionary. For example:
{"http": "10.10.1.10:3128","https": "10.10.1.10:1080"}

data
Specify post data to be sent along with the request. This can be a string or a dictionary. For example:
{"input_field":"value"} or input_field=value

method
Specify the method for the http request. Valid methods are
'get','options','head','post','put','patch','delete'

auth
Specify a tuple of username and password to be used for http basic authentication. For example:
("myusername","mypassword")

Export Config
After you have setup your attack in the UI, you can export the configuration file. You will see the option when you run the tool. The exported configuration file uses ConfigParser, and is easy to read. An example configuration file can be seen below:
`[Request Config] url = http://example.com/sqlivuln/index.php?username=user1&password=secret${injection} method = GET
[HTTP Config] query = ' and ASCII(SUBSTR((SELECT data FROM data LIMIT 1 OFFSET ${row_index:1}),${char_index:1},1))${comparator:>}${char_val:0} # technique = binary_search comparison_attr = size concurrency = 30`
This is useful if you plan on resuming an attack or maybe just adjusting the query but don't want to go through the hassle of reconfiguring every option.

Import Config
You can also import a config from the command line or from the user interface. To import a config from the command line just run bbqsl with the following options:
bbqsql -c config_file
When you load a config file either via command line or the user interface, the same validation routines are run on the paramters to make sure that are valid.

Custom Hooks
Sometimes you need to do something really crazy. Maybe do you need to encrypt the values going into a field before sending the request or maybe you need to triple URL encode. Regardless, these situations make other tools impossible to use. BBQSQL allows you to define "hook" functions that the tool will call at various points throughout the request. For example, you can specify a pre_request function that takes the request as its argument, does whatever mutations are necessary, and returns the modified request to be sent on to the server.
To implement this, create a Python file and specify hook functions. The available function names are listed bellow. In your hooks file, you can define as few or as many of these hooks functions as you would like. Then, in the bbqsql_options section of the menue, you can specify the location of your hooks_file. BBQSQL will suck in this file and use whatever hooks you defined.
It is important that the hooks functions you specify have the exact names specified bellow or else BBQSQL won't know which hook to call when. The args function receives one parameter that contains all the arguments that are being used to create the HTTP request. The pre_request function receives the request object before it is sent. The post_request function receives the request object after it has been sent. The response function receives the response object before it is returned to BBQSQL.
The following hooks are made available:
args : A dictionary of the arguments being sent to Request().
pre_request : The Request object, directly before being sent.
post_request : The Request object, directly after being sent.
response : The response generated from a Request.
For more information on how these hooks work and on how your hooks dictionary should look, check out the requests library documentation on its hooks
An example hooks file might look like this:
# file: hooks.py
import time

def pre_request(req):
"""
this hook replaces a placeholder with the current time
expecting the url to look like this:
http://www.google.com?k=v&time=PLACEHOLDER
"""
req.url = req.url.replace('PLACEHOLDER',str(time.time()))
return req

Found a Bug?
Submit any bug fixes or feature requests to https://github.com/Neohapsis/bbqsql/

Can I Help?
Please! We see this being a great starting place to build a fully capable sql injection framework. Feel free to fork the code and we can merge your changes if they are useful.

What's Up With the Name?
BBQ is absolutely delicious and so is SQL injection!



Via:www.kitploit.com

Denegación de servicio en versiones antiguas de BIND 9

$
0
0
ISC ha publicado un aviso en el que informa de una vulnerabilidad de denegación de servicio en versiones del servidor DNS BIND 9 anteriores a mayo de 2013. 

El servidor de nombres BIND es uno de los más usados en Internet. Creado en 1988, en la universidad de Berkeley, actualmente es desarrollado por el ISC (Internet System Consortium). BIND se encuentra disponible para una amplia gama de sistemas tanto Unix como Microsoft Windows.

El problema, con CVE-2016-2848, reside en que un paquete con la sección de opciones específicamente construida puede provocar un fallo de aserción, con la consiguiente caída del servicio. El problema fue corregido en las versiones de BIND distribuidas por ISC en mayo de 2013. Sin embargo algunas versiones de BIND, distribuidas por otras partes, siguen siendo vulnerables al no contener el cambio #3548.

Afecta a versiones de BIND 9.1.0 a 9.8.4-P2 y 9.9.0 a 9.9.2-P2, que no incluyan el cambio #3548 (anteriores a mayo de 2013).

Se recomienda actualizar a las versiones más recientes BIND 9.9.9-P3, 9.10.4-P3 y 9.11.0, disponibles en:

Más información:

CVE-2016-2848: A packet with malformed options can trigger an assertion failure in ISC BIND versions released prior to May 2013 and in packages derived from releases prior to that date.


Antonio Ropero

Twitter: @aropero

Via:unaaldia.hispasec.com

#DirtyC0w, una condición de carrera desde hace 11 años que permite hacerse root

$
0
0
Dirty Cow es un bug que lleva presente 11 años en Linux y permite a cualquiera elevar privilegios como root. El fallo se encuentra desde la versión 2.6.22 (de 2007) y ha sido corregida el 18 de Oct, 2016.

Su nombre es considerado un BWAIN (Bug With An Impressive Name) y COW viene de Copy On Write (copiar al escribir), un truco que los sistemas operativos más modernos utilizan para ahorrar tiempo cuando se copia algo (por ejemplo un archivo o un bloque de memoria), que en realidad consiste simple y llanamente en que por debajo no realizan la copia de inmediato. Es decir, cuando accedes a un elemento copiado sigues accediendo al elemento original, y realmente sólo se copia si se modifica porque sólo entonces habrá dos versiones distintas que necesitan divergir.

Por supuesto, si hay un fallo en el mecanismo COW y la copia no sucede cuando debe, o sucede cuando debería no ser así, los cambios se pueden perder, o realizarse en lugar equivocado.

El bug DirtyCOW, conocido oficialmente como CVE-2016-5195, es un fallo del segundo tipo: los datos se escriben en una ubicación de memoria incorrecta.

Concretamente es una condición de carrera que se ha encontrado en la forma en la que el subsistema de memoria del kernel de Linux maneja las asignaciones del acceso de escritura de las operaciones COW. Un usuario local sin privilegios podría usar este fallo para obtener acceso de escritura a mapas de memoria de sólo lectura y aumentar así sus privilegios en el sistema.

Ya se han publicado varias PoCs que demuestran cómo funciona y puede explotarse esta vulnerabilidad. Los exploit hacen más o menos lo siguiente:

- Primero mapean su propio proceso en lo que es conocido como un mapeo privado de escritura. Como decimos, con COW no se copiará inmediatamente por podremos modificar ese mapeo privado sin afectar al programa en ejecución.

- Segundo mapean en memoria un archivo con acceso de sólo lectura. En teoría, COW debería ser irrelevante aquí: no se tiene acceso de escritura al archivo por lo que tampoco se tiene acceso de escritura en el mapa de memoria y no se debería poder cambiarlo en absoluto.

- Y tercero, se ejecutan dos threads o hilos en paralelo. Uno que escribe los cambios en el mapa de memoria escribible y privado y el otro que le dice al kernel que puede liberar temporalmente cualquier memoria utilizada para el archivo asignado. Ambos hilos "colisionarán" y los datos que se están intentando escribir en el memory map privado "accidentalmente" se volcarán en el memory map del archivo de sólo lectura.

El resultado es que un usuario normal puede alterar de forma permanente los archivos del sistema que normalmente requieren un login de root para modificarlos. Eso podría incluir archivos de configuración importantes como ssh_config, las claves de cifrado privadas, o incluso el software del sistema, como el /bin/login.

Irónicamente, este error se abordó por primera vez hace once años por el propio Linus Torvalds, pero la solución entonces fue descartada debido a que causaba problemas en la versión mainframe de IBM de Linux.

Linus lo describe como un error meramente "teórico" en ese entonces pero que ha terminado por ser perfectamente práctico:

"Se trata de un antiguo error que en realidad se trató de corregir una vez (mal) por mí hace once años [...], pero que entonces se deshechó debido a problemas en el s390 ... Lo que era una condición de carrera puramente teórica en ese entonces se ha convertido en más fácil de desencadenar".

Por ahora ya está el parche para el kernel, pero hay que esperar a que las principales distribuciones de Linux lo publiquen o bien aplicar el parche y recompilar el kernel por uno mismo...

Detalles de la vulnerabilidad

https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails

Listado de PoCs (https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs):
Análisis del PoC:

faultin_page
  handle_mm_fault
    __handle_mm_fault
      handle_pte_fault
        do_fault <- pte is not present
      do_cow_fault <- FAULT_FLAG_WRITE
        alloc_set_pte
          maybe_mkwrite(pte_mkdirty(entry), vma) <- mark the page dirty
                                but keep it RO
# Returns with 0 and retry
follow_page_mask
  follow_page_pte
    (flags & FOLL_WRITE) && !pte_write(pte) <- retry fault

faultin_page
  handle_mm_fault
    __handle_mm_fault
      handle_pte_fault
        FAULT_FLAG_WRITE && !pte_write
      do_wp_page
        PageAnon() <- this is CoWed page already
        reuse_swap_page <- page is exclusively ours
        wp_page_reuse
          maybe_mkwrite <- dirty but RO again
          ret = VM_FAULT_WRITE
((ret & VM_FAULT_WRITE) && !(vma->vm_flags & VM_WRITE)) <- we drop FOLL_WRITE

# Returns with 0 and retry as a read fault
cond_resched -> different thread will now unmap via madvise
follow_page_mask
  !pte_present && pte_none
faultin_page
  handle_mm_fault
    __handle_mm_fault
      handle_pte_fault
        do_fault <- pte is not present
      do_read_fault <- this is a read fault and we will get pagecache
               page!

- El exploit se basa en en escribir a /proc/self/mem en una única condición de carrera.
- ptrace(PTRACE_POKEDATA) puede escribir en mapeos de sólo lectura.
- El ataque se basa en lanzar en paralelo la llamada al sistema con madvise(MADV_DONTNEED) a la vez que se tiene la página del ejecurable mapeada en memoria.

Referencias:

- https://nakedsecurity.sophos.com/2016/10/21/linux-kernel-bug-dirtycow-easyroot-hole-and-what-you-need-to-know/
- https://bugzilla.redhat.com/show_bug.cgi?id=1384344
- https://access.redhat.com/security/vulnerabilities/2706661
- https://plus.google.com/+KeesCook/posts/UUaXm3PcQ4n
- https://twitter.com/nelhage/status/789196293629370368
- https://bugzilla.suse.com/show_bug.cgi?id=1004418#c14

Via:www.hackplayers.com

Auto_EAP - Automated Brute-Force Login Attacks Against EAP Networks

$
0
0

Auto_EAP.py is a script designed to perform automated brute-force authentication attacks against various types of EAP networks. These types of wireless networks provide an interface to facilitate password guessing of domain credentials as radius servers check authentication against Active Directory. Using the python library wpaspy, created by Jouni Malinen j@w1.fi to interact with the wpa_supplicant daemon, automated authentication attacks can be preformed with the intent of not causing account lock-outs.

Demo

./Auto_EAP.py -s HoneyPot -K WPA-EAP -E PEAP -U test.txt -p Summer2016 -i wlan0
Initialized...
Trying Username Alice with Password test: SUCCESS
Trying Username Bob with Password test: FAILED
Trying Username Charles with Password test: FAILED
Trying Username David with Password test: SUCCESS
Completed

Installation

Run 'RunMeFirst.py' within the root directory of Auto_EAP. This will compile the wpaspy library as well as setup a stand alone wpa_supplicant.conf file that Auto_EAP.py will use for testing, leaving the system’s wpa_supplicant config file untouched.

Help

./Auto_EAP.py -h
usage: Auto_EAP.py [-h] -i Interface -s SSID -U Usernamefile -p Password -K
Key_mgmt -E Eap_type

optional arguments:
-h, --help show this help message and exit
-i Interface, --interface Interface
The Interface to use
-s SSID, --ssid SSID The SSID to attack
-U Usernamefile, --User Usernamefile
Path to username file
-p Password, --password Password
Password to use
-K Key_mgmt, --key_mgmt Key_mgmt
Key_Management type to use
-E Eap_type, --eap_type Eap_type
Eap type to use

Todo list

  • [✓] Resoved bug with .a type wireless cards (Shout out to Havok0x90 for his help in resolving this issue)
  • [-] Add multi-threading functionality
  • [-] Add support for password lists



Via:www.kitploit.com

Mozilla publica actualización para Firefox

$
0
0
La Fundación Mozilla ha publicadouna actualización para el navegador Firefox destinada a corregir dos vulnerabilidades de gravedad alta

El primer problema (CVE-2016-5287) reside en un uso de memoria después de liberar durante la destrucción de actor con service workers. Por otra parte, también se ha corregido otra vulnerabilidad (CVE-2016-5288) que podría permitir acceder a la información en la caché sí e10s está desactivado. Esto podría revelar las URLs visitadas y su contenido.

Para corregir estas vulnerabilidades, se ha publicado la versión Firefox 49.0.2, disponible para su descarga a través de los canales habituales o mediante las actualizaciones automáticas.

Más información:

Security vulnerabilities fixed in Firefox 49.0.2


Antonio Ropero

Twitter: @aropero

Via:unaaldia.hispasec.com

ssh-audit - SSH Server Auditing

$
0
0

ssh-audit is a tool for ssh server auditing.

Features
  • SSH1 and SSH2 protocol server support;
  • grab banner, recognize device or software and operating system, detect compression;
  • gather key-exchange, host-key, encryption and message authentication code algorithms;
  • output algorithm information (available since, removed/disabled, unsafe/weak/legacy, etc);
  • output algorithm recommendations (append or remove based on recognized software version);
  • output security information (related issues, assigned CVE list, etc);
  • analyze SSH version compatibility based on algorithm information;
  • historical information from OpenSSH, Dropbear SSH and libssh;
  • no dependencies, compatible with Python 2.6+, Python 3.x and PyPy;

Usage
usage: ssh-audit.py [-bnv] [-l <level>] <host[:port]>

-1, --ssh1 force ssh version 1 only
-2, --ssh2 force ssh version 2 only
-b, --batch batch output
-n, --no-colors disable colors
-v, --verbose verbose output
-l, --level=<level> minimum output level (info|warn|fail)
  • batch flag -b will output sections without header and without empty lines (implies verbose flag).
  • verbose flag -v will prefix each line with section type and algorithm name. 


ChangeLog

v1.6.0 (2016-10-14)
  • implement algorithm recommendations section (based on recognized software)
  • implement full libssh support (version history, algorithms, security, etc)
  • fix SSH-1.99 banner recognition and version comparison functionality
  • do not output empty algorithms (happens for misconfigured servers)
  • make consistent output for Python 3.x versions
  • add a lot more tests (conf, banner, software, SSH1/SSH2, output, etc)
  • use Travis CI to test for multiple Python versions (2.6-3.5, pypy, pypy3)

v1.5.0 (2016-09-20)
  • create security section for related security information
  • match and output assigned CVE list and security issues for Dropbear SSH
  • implement full SSH1 support with fingerprint information
  • automatically fallback to SSH1 on protocol mismatch
  • add new options to force SSH1 or SSH2 (both allowed by default)
  • parse banner information and convert it to specific sofware and OS version
  • do not use padding in batch mode
  • several fixes (Cisco sshd, rare hangs, error handling, etc)

v1.0.20160902
  • implement batch output option
  • implement minimum output level option
  • fix compatibility with Python 2.6

v1.0.20160812
  • implement SSH version compatibility feature
  • fix wrong mac algorithm warning
  • fix Dropbear SSH version typo
  • parse pre-banner header
  • better errors handling

v1.0.20160803
  • use OpenSSH 7.3 banner
  • add new key-exchange algorithms

v1.0.20160207
  • use OpenSSH 7.2 banner
  • additional warnings for OpenSSH 7.2
  • fix OpenSSH 7.0 failure messages
  • add rijndael-cbc failure message from OpenSSH 6.7

v1.0.20160105
  • multiple additional warnings
  • support for none algorithm
  • better compression handling
  • ensure reading enough data (fixes few Linux SSH)

v1.0.20151230
  • Dropbear SSH support

v1.0.20151223
  • initial version


Via:www.kitploit.com

Torneo de desarrollo seguro de software y Hackathon de CyberCamp 2016

$
0
0
Este año, durante el evento CyberCamp 2016 de INCIBE que tendrá lugar en León del 1 al 4 de diciembre, se celebrarán dos competiciones de seguridad para desarrolladores y apasionados de la seguridad:
Debido a que las fechas iniciales de cierre del registro de ambas competiciones está próximo, y con el objetivo de que aquellos que puedan estar interesados no desaprovechen la oportunidad, este artículo detalla las fechas relevantes, objetivos, motivaciones, posibles ventajas de participar (intentando ser realista), detalles internos del backstage, y algunas novedades (al final del artículo) que espero animen a aquellos que aún se lo están pensando... ;)

Fechas de registro

Respecto a las fechas relevantes, el proceso de registro del Torneo permanecerá (inicialmente) abierto hasta el 28 de octubre, y el registro del Hackathon estará abierto hasta el 1 de noviembre a las 23:59 (CET). En ambos casos, si no se completan todas las plazas disponibles, el registro permanecerá abierto con posterioridad a estas fechas para admitir a los rezagados (pero yo no me arriesgaría... ;).

A día de hoy todavía hay plazas disponibles para ambas competiciones, por lo que, si estás dudando en participar, lee las novedades más abajo, anímate y regístrate a través de la página web oficial de ambas competiciones (donde también se dispone de las bases de participación). ¡Prepárate para ganar la competición y conseguir los premios disponibles!

Motivaciones y posibles ventajas de participar

El principal motivo por el que nos hemos involucrado en ambas iniciativas desde DinoSec es, por un lado con el Torneo, concienciar y difundir la necesidad de que se genere código más seguro, e intentar hacerlo realidad empleando una nueva aproximación a través de la gamificación. Por otro lado con el Hackathon, disponer de la oportunidad de promover proyectos y herramientas de código abierto que sean de utilidad para la comunidad, ya que todos los que estamos en ella, hemos utilizado con éxito este tipo de herramientas a lo largo de nuestra vida profesional y actividades diarias. No es frecuente  disponer de la posibilidad de abordar estas dos problemáticas localmente, dentro de España.

Creo que la importancia de las herramientas de seguridad se refleja en la ley que acuño ya hace unos años Joshua Wright (@joswr1ght), un buen amigo, gran profesional e investigador de seguridad. Wright’s Law: "Security doesn’t get better until tools for practical exploration of the attack surface are made available", es decir, "La seguridad no mejora hasta que no hay disponibles herramientas para la exploración práctica de la superficie de ataque".



El Torneo pretende hacer hincapié en uno de los problemas fundamentales que afectan a las tecnologías y entornos informáticos en la actualidad, la generación de código inseguro o con vulnerabilidades. Esta es sin duda la raíz de muchos de los problemas que sufrimos en la industria de seguridad informática y tecnológica hoy en día, con numerosas vulnerabilidades, muchas de ellas críticas, publicadas cada semana.

Por este motivo, los lenguajes o entornos de programación objetivo de este año son los habituales en entornos empresariales y corporativos, y dónde se sustentan muchas de las aplicaciones y servicios de grandes empresas que usamos en el día a día: Java (Spring), Java (Enterprise), C# .NET (Webforms), C# .NET (MVC) y Ruby on Rails.

Tan pronto se llevó a cabo la publicación del Torneo, recibimos mensajes por parte de empresas, tanto del sector de la seguridad como de otras empresas de renombre españolas de varios sectores, interesadas en identificar a los mejores participantes de la competición. Más que nunca, hay necesidad de cubrir la carencia de desarrolladores y programadores concienciados e interesados por la seguridad.

Por tanto, si conoces a desarrolladores inquietos y con ganas de seguir aprendiendo y evolucionando, en este caso en el mundo de la seguridad, no dudes en comentarles que esta es su oportunidad de destacar.

Este interés no es novedad, ya que se presentó igualmente el año pasado (y de nuevo este año) con el Hackathon de CyberCamp 2015, dónde empresas del sector de la seguridad mostraban su atracción por los mejores clasificados. Participar no sólo te permite mostrar tus habilidades y conocimientos, sino también tu pasión e interés por la seguridad y por contribuir a la comunidad.

Por tanto, creo que la participación en ambas competiciones puede tener un impacto directo en la carrera profesional, actual o futura, de los participantes, tanto promocionándose y obteniendo mayor visibilidad y relevancia dentro de su empresa, como a la hora de empezar a trabajar o de encontrar nuevas oportunidades laborales. Eso sin considerar toda la experiencia real que se obtiene durante la competición en unas pocas horas o días.



En el caso del Hackathon, las herramientas propuestas por los participantes pueden aplicar a cualquier área relacionada con la seguridad que sea de su interés. Por un lado, es una oportunidad perfecta para colaborar en una de las herramientas de código abierto de referencia para tareas de ingeniería inversa y exploiting, como Radare, especialmente teniendo a Pancake (@trufae) en el jurado ;) Por otro lado, tras publicar por Twitter que se llevaría a cabo el Hackathon también este año, un buen conocido y persona relevante en el mundo de la seguridad web, Simon Bennetts (@psiinon), reflejó su interés a la hora de recibir contribuciones para su herramienta OWASP ZAP, uno de los proyectos estrella (o flagship) de OWASP en la actualidad.

El Hackathon puede ser una muy buena oportunidad para dar visibilidad a ese nuevo proyecto o idea, o contribución a herramientas ya existentes, que tienes rondando tu cabeza hace algún tiempo, y es sin duda la excusa perfecta para intentar llevarlo a cabo en un entorno competitivo, trabajando individualmente o en equipo, y pasándolo bien. Eso sí, esperamos que no se quede ahí, por lo que "El Hackathon debería ser sólo el comienzo…".

Para mi ha sido muy reconfortante este año recibir comentarios directos de algunos participantes del pasado año, enfatizando lo bien que se lo pasaron y saber que estaban haciendo todo lo posible para planificarse, cuadrar fechas, y poder repetir.

En el siguiente enlace web podéis ver los proyectos tan interesantes que participaron en el Hackathon del pasado año: https://cybercamp.es/cybercamp2015/actividades/hackathon.html

Este año, de nuevo, es para mí un honor contar con un jurado de lujo, que (aunque no todos me lo han dicho directamente) seguro estará encantado de recibir mejoras en sus herramientas de seguridad (por ejemplo, por si no se os ocurre qué herramienta elegir), como Radare (ya mencionada previamente), Delorean o Tinfoleak, entre otras ;)

Asimismo, las herramientas del Hackathon centradas en entornos industriales podrán ser incluidas en una futura distribución Unix realizada por INCIBE con enfoque en esta temática (ver detalles más abajo).

Adicionalmente, los participantes del Hackathon del entorno universitario que lo soliciten podrán conseguir un total de 2,1 créditos ECTS superando los hitos y criterios definidos por el jurado durante la competición del Hackathon. Como estudiante, ¿se te ocurre una mejor forma de obtener créditos que compitiendo y pasándotelo bien, a la vez que aprendes?

Desplazamiento

Para facilitar el desplazamiento (ya que sin duda es un aspecto importante a tener en cuenta), se va a disponer de un descuento con Renfe de un 35% para aquellos que vayan a asistir a CyberCamp 2016. Cuando se confirmen los participantes, se enviará el código de descuento.

Alojamiento

Para facilitar la participación, disponemos de novedades respecto al alojamiento de los participantes para ambas competiciones, detalladas a continuación.

Torneo de Desarrollo Seguro de Software

El Torneo, novedad en CyberCamp, es una competición individual en la que los participantes, tanto desarrolladores y programadores profesionales como estudiantes o entusiastas de la programación, podrán demostrar sus conocimientos y habilidades a la hora de programar, evaluar y generar código seguro, mediante la resolución de múltiples retos de seguridad.

Como novedad, la organización facilitará alojamiento gratuito a los participantes seleccionados del Torneo final en CyberCamp 2016.

Hackathon

El Hackathon es una competición por equipos centrada en el desarrollo y/o mejora de herramientas de seguridad de código abierto. Los participantes, tanto profesionales de seguridad como desarrolladores, estudiantes o apasionados de la seguridad, deberán exprimir al máximo sus conocimientos y habilidades, y competir con su equipo (o individualmente), tras enviar su propuesta basada en la herramienta de seguridad de su interés.

Como novedad, la organización proporcionará alojamiento gratuito a los participantes seleccionados para el Hackathon durante los días de duración de la competición.

Asimismo, este año cabe destacar que se dispone de un apartado orientado hacia los entornos industriales, donde los participantes podrán desarrollar herramientas específicas para sistemas o entornos de control (SCADA) y probarlas en una plataforma real con instrumentación industrial diseñada específicamente para este fin. Los elementos que componen la plataforma son variados (PLC, HMI, firewall industrial, switch, analizadores de red, etc.) y el tráfico generado será el propio de las redes de control (modbus, profinet, OPC, etc.). Todos los participantes que se interesen por esta temática recibirán con antelación información adicional sobre la arquitectura de la plataforma industrial a utilizar en el evento. Como distinción adicional, los mejores proyectos de esta temática podrán ser incluidos en una futura distribución Unix realizada por INCIBE y enfocada a la seguridad de entornos industriales.

  



Espero que todos estos detalles os animen a tomar la decisión de participar y que nos podamos ver en alguna de las dos competiciones durante CyberCamp 2016.

Contribución por Raúl Siles

Via:www.securitybydefault.com

Publicada la píldora formativa Thoth 39 "¿Cómo funciona el algoritmo RSA?"

$
0
0
Se ha publicado en el canal YouTube de la UPM la píldora formativa 39 del proyecto Thoth que lleva por título "¿Cómo funciona el algoritmo RSA?"

En febrero de 1978, es decir poco más de un año después de aquel intercambio de clave propuesto por Diffie y Hellman, otros tres investigadores norteamericanos, en este caso del Instituto Tecnológico de Massachusetts MIT, Ron Rivest, Adi Shamir y Leonard Adleman, proponen un sistema de cifra que llevará las iniciales de sus apellidos, algoritmo que se patenta como RSA. El algoritmo RSA basa su fortaleza en la dificultad computacional de factorizar un número compuesto muy grande, producto de dos primos grandes, un problema inabordable para la capacidad mundial de cómputo en 2016 con magnitudes por encima de mil bits.

Enlace en YouTube a la píldora Thoth 39 "¿Cómo funciona el algoritmo RSA?"

El proyecto Thoth publica de manera periódica píldoras formativas en seguridad de la información. Pueden ser tratados como complementos formativos basados en el concepto de vídeos cortos (con una duración en torno a los cinco minutos), muy didácticos y sobre temas muy específicos.

Todos los vídeos del proyecto Thoth cuentan con un archivo srt original de subtítulos incluido en YouTube, importante para personas con limitaciones auditivas, así como un archivo podcast mp3 que puede descargarse desde el sitio web, válido en este caso tanto para personas con limitaciones visuales como para quienes deseen realizar solamente la audición de estas lecciones.

Puedes acceder a la documentación en pdf, el podcast en mp3 y también al vídeo de esta nueva píldora y de todas las anteriores, desde la página web del Proyecto Thoth, que te permite además una búsqueda de vídeos mediante los siguientes cinco filtros: Fundamentos de seguridad, Criptografía clásica, Historia de la criptografía, Matemáticas en criptografía y Criptografía moderna.

Como siempre, quedamos a la espera de tus comentarios en YouTube, muy importantes y necesarios para la supervivencia de este proyecto de formación y difusión masiva y gratuita.

La próxima entrega del proyecto Thoth será en noviembre de 2016 con la píldora 40 de título "¿Es vulnerable el algoritmo RSA?"


Jorge Ramió, Alfonso Muñoz
Directores Proyecto Thoth



Via:unaaldia.hispasec.com

Cómo convertirse en root en un GNU/Linux explotando el bug de DirtyCOW

$
0
0
La semana pasada se publicó un exploit que se aprovecha de una vulnerabilidad para lograr ejecutar código en un contexto privilegiado. DirtyCOW es una vulnerabilidad de condición de carrera que puede provocar la ejecución de código y lograr una escalada de privilegios en un kernel de Linux. Afecta a todas las versiones del sistema operativo y podemos encontrar un mayor nivel de detalle en su CVE-2016-5196. Además, DirtyCOW va camino de vulnerabilidad mediática, por lo que tiene su propio sitio web y su propia imagen.

Figura 1: Cómo convertirse en root en un GNU/Linux explotando el bug de DirtyCOW

¿En qué consiste la vulnerabilidad? Realmente es una condición de carrera que se encontró en la forma en la que el subsistema de memoria del kernel de Linux gestiona COW, Copy-On-Write. En otras palabras, un usuario local sin privilegios podría utilizar esta vulnerabilidad para escribir y tener acceso a partes del sistema que son de otros usuarios, incluido el root. En el instante que se puede acceder a la escritura a partes pertenecientes a root, se puede escribir código que, al ser ejecutado, por ejemplo, con setuid, permiten ejecutar código con dicha identidad consiguiendo la escalada de privilegio.

Figura 2: Copy-on-Write en la Wikipedia

Como curiosidad hay que decir que la vulnerabilidad ha estado presente durante muchos años, desde la versión 2.6.22 del kernel de Linux, la cual fue liberada allá por el año 2007. Incluso el propio Linus Torvalds comentó en su día que la vulnerabilidad existía, pero todo era de forma teórica y no se conocía la forma de explotar. De hecho se dejó porque el parche que se había previsto afectaba al funcionamiento de Linux en los equipos IBM S390. Hoy día, ya tenemos un exploit público que se aprovecha de la vulnerabilidad para lograr ejecutar código con privilegio, y lograr la escalada.

Figura 3: Exploit para DirtyCOW que usaremos en la PoC

Para verificar que mi sistema es vulnerable o no a esta vulnerabilidad podemos ejecutar la siguiente instrucción en un terminal: uname -a. Si la versión del kernel está entre la 2.6.22 y la 3.9, tendremos un problema. El exploit público está preparado para arquitecturas x86 y x64, solo hay que descomentar la parte que no nos interesa.

Figura 4: Comprobación de versión del Kernel de Linux vulnerable a DirtyCOW

En exploit-db encontramos una de las pruebas de concepto de las varias que hay en Internet sobre el exploit. Para nuestra prueba de concepto utilizaremos la que hemos visto en exploit-db, pero os recomendamos que echéis un ojo a las distintas pruebas de concepto que se han ido publicando en Internet. En Github, se ha montado un repositorio sobre todas las pruebas de concepto.

Figura 5: Repositorio en GitHub para las PoCs de DirtyCOW

Una vez descargado el exploit, vamos a editar el exploit para, en función de nuestra arquitectura, amoldarlo a las necesidades. Si estamos en un sistema x86, debemos comentar el payload generado con msfvenom de Metasploit para x64, y si nos encontramos en un sistema x64, sería justamente al revés.

PoC: Escalando privilegios con DirtyCOW

Una vez tengamos claro esto, debemos compilar el exploit escrito en Lenguaje C. Para ello ejecutamos la siguiente instrucción gcc [exploit.c] -o [exploit binario] -pthread. Esto llevará a cabo la compilación del exploit y lo tendremos disponible.

Figura 6: Configuración del exploit de DirtyCOW para nuestra arquitectura

Si pensamos en el hardening de servidores GNY/Linux tenemos que pensar que tener disponible el compilador en un servidor o máquina dónde no se lleven a cabo este tipo de tareas no es una buena práctica de seguridad. Imaginemos que en un servidor disponemos de gcc u otros compiladores, estamos dando un arma a los atacantes, que hayan llegado hasta aquí.

Figura 7: Ejecución del exploit de elevación de privilegios gracias a DirtyCOW

Una vez compilado, lanzamos el binario y podremos ver que el exploit tiene éxito. En el momento que tiene éxito, disponemos de una sesión como root en la máquina local. Lógicamente, este tipo de escaladas de privilegios, pueden ir ligadas con un ataque previo remoto, en el que un atacante o un auditor consigue acceso al sistema, para posteriormente lograr la escalada de privilegio. No sería extraño ver en poco tiempo este exploit migrado al famoso framework de explotación Metasploit.

Figura 8: Vídeo de la explotación de DirtyCOW

Por último, os dejamos el video sobre la explotación local de la vulnerabilidad en un sistema Ubuntu 14.04. Existen ramas en el kernel de Linux que ya están parcheadas, que no son vulnerables a DirtyCOW, por lo que recomendamos a todos los equipos de IT que verifiquen que sus versiones de kernel de los sistemas Linux no sean vulnerables. Este es un claro ejemplo de cómo explotar vulnerabilidades en Linux, así que analízalo que se entiende muy fácil.


Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell

Via:www.elladodelmal.com

Drammer, un exploit para hacerse root en Android mediante un fallo... ¡en el hardware!

$
0
0
La memoria DRAM que tiene nuestras computadoras, incluido los smartphones, es un tipo de memoria volátil que utiliza millones de transistores y condensadores que se dividen en celdas de filas y columnas. Cada uno de estos condensadores tiene un estado de carga para almacenar el valor de un bit (1 con carga y 0 sin carga). Dado que están muy próximos entre sí (micro o nano escala) es posible afectar al estado de los condensadores contiguos cambiando el estado de los más cercanos una y otra vez (bit flipping), como si se tratase de las vibraciones de un martilleo continuo. 

Hace un par de años se habló de la técnica llamada 'row hammer' que se aprovechaba de eso: inundar una fila o columna entera de datos una y otra vez para afectar a las celdas de memoria contiguas cambiando su estado.

Sin embargo, parecía que aplicar está técnica era sólo factible con componentes de hardware muy específicos con fallos o que podían repelerse mediante capacidades avanzadas de gestión de memoria.

Pero nada más lejos de la realidad... un grupo de investigadores acaba de demostrar que este ataque puede llevarse a la práctica ahora mediante código javascript (rowhammer.js) capaz de escapar del sandbox del navegador y hacerse con la memoria del ordenador e incluso en nuestros smartphones.
De aquí surge Drammer que permite además llevar a cabo esta técnica en smartphones. En el siguiente vídeo podéis como en apenas un minuto se consigue acceso root en un Nexus 5 con Android 6.0.1:

La solución contra este ataque se presenta complicada puesto que, como comentamos, se trata fundamentalmente de un problema de hardware, así que veremos hasta que punto son efectivas las mitigaciones que vayan publicando en los próximos días. En cualquier caso es algo serio, más aún si se combina con otros vectores de ataque como Stagefright o BAndroid.

Respecto a los dispositivos afectados en este caso no se espera que se publique listados estáticos ya que hay dispositivos que aún siendo el mismo modelo podrían tener distintos componentes y por lo tanto unos podrían ser vulnerables y otros no. Los investigadores prometen una aplicación en Google play que podremos instalar en nuestros dispositivos para comprobar de forma específica si son vulnerables a Drammer o no. Estaremos atentos.

Paper: Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript
Drammer: https://www.vusec.net/projects/drammer/

Via:www.hackplayers.com

AutoBrowser 4.0 - AutoBrowser Screenshot of HTTP/s Based Ports

$
0
0

AutoBrowser is a tool written in python for penetration testers. The purpose of this tool is to create report(Json file) and screenshots of http/s based ports on the network. you can choose between analyze Nmap report(XML file -oX ) or scan with Nmap, then the tool automaticly Check the results with http/s request on each host using headless web browser, then it would take a screenshot of the response page content.
  • This tool is designed for IT professionals to perform penetration testing.

Documentation:
positional arguments: * analyze - Analyze and browse (Require argument: nmap report location) ** scan - Scan and browse (Require argument: target host or file)
optional arguments: * -h, --help - show this help message and exit * **-p PROJECT, --project PROJECT * - project name (folder which contain all the data. default: project) * **-t TIMEOUT, --timeout TIMEOUT * - http request timeout period * **-w MAX_WORKERS, --max-workers MAX_WORKERS * - Max worker processes (Default: 4) * **--useragent USERAGENT * - Set specific user agent * **--java-enabled * - Display Java enviroment * **--verbose * - Show all checks verbosly * **--proxy PROXY * - Relay connections through HTTP/socks5 proxy (Example: socks5://127.0.0.1:8080) * **--proxy-auth PROXY_AUTH * - Set proxy credentials. (Example: username:password)

Examples:
You must to delimiting the values on the CLI arguments via double quotes only!
  • Get argument details of scan method:
    python AutoBrowser.py scan --help   
  • Scan with Nmap, checks the results and create folder by name project_name verbose via 10 workers:
    python AutoBrowser.py scan "192.168.1.1/24" -a="-sT -sV -T3" -p project_name --workers=10   
  • Scan a host list via Nmap(like -iL Nmap flag), checks the results and create folder by name project_name and enabling java environment:
    python AutoBrowser.py scan file_path.txt -a="-sT -sV -T3" -p project_name --verbose --java-enabled   
  • Get the argument details of analyze method:
    python AutoBrowser.py analyze --help   
  • Analyzing Nmap XML report and create folder by name report_analyze trough a Proxy:
    python AutoBrowser.py analyze nmap_file.xml --project report_analyze --proxy="socks5://127.0.0.1:8080"   
  • Analyzing Nmap XML report and create folder by name report_analyze trough a Proxy with credentials:
    python AutoBrowser.py analyze nmap_file.xml --project report_analyze --proxy="http://127.0.0.1:8080" --proxy-auth="username:password"   
  • Analyzing Nmap XML report and create folder by name report_analyze with specify user agent:
    python AutoBrowser.py analyze nmap_file.xml --project report_analyze --user-agent="My New UserAgent"   

Requirements:

Linux Installation:
  1. sudo apt-get install python-pip python2.7-dev libxext-dev python-qt4 qt4-dev-tools build-essential nmap
  2. sudo pip install -r requirements.txt

MacOSx Installation:
  1. Install Xcode Command Line Tools (AppStore)
  2.      ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"    
  3. brew install pyqt nmap
  4. sudo easy_install pip
  5. sudo pip install -r requirements.txt

Windows Installation:
  1. Install setuptools
  2. Install pip
  3. Install PyQt4
  4. install Nmap
  5. Open Command Prompt(cmd) as Administrator -> Goto python folder -> Scripts (cd c:\Python27\Scripts)
  6. pip install -r (Full Path To requirements.txt)



Via:www.kitploit.com

Apple publica nuevas versiones de iOS, macOS Sierra, Safari, watchOS y tvOS

$
0
0
Apple ha publicado actualizaciones para sus productos más destacados, que incluyen macOS Sierra 10.12.1, iOS 10.1, Safari 10.0.1, tvOS 10.0.1 y watchOS 3.1. En total se solucionan 23 nuevas vulnerabilidades (aunque muchas de ellas se presentan en múltiples sistemas).

Dada la gran cantidad de novedades y productos actualizados, vamos a realizar un breve repaso de las actualizaciones publicadas y problemas solucionados.

Se ha publicado macOS Sierra 10.12.1 para OS X Yosemite 10.10.5, OS X El Capitan 10.11.6 y macOS Sierra 10.12; destinado a corregir 16 vulnerabilidades, la mayoría de ellas podrían llegar a permitir la ejecución de código arbitrario. Afectan a componentes tan importantes como AppleGraphicsControl, AppleSMC, ATS, CFNetwork Proxies, CoreGraphics, FaceTime, FontParser, ImageIO, libarchive, libxpc, ntfs, NVIDIA Graphics Drivers, Security y System Boot. macOS Sierra 10.12.1 también incluye el contenido de seguridad de Safari 10.0.1.

Las actualizaciones también han llegado a Safari, el popular navegador web de Apple, que se actualiza a la versión 10.0.1 para OS X Yosemite v10.10.5, OS X El Capitan v10.11.6 y macOS Sierra 10.12. Se solucionan dos vulnerabilidades relacionadas con problemas en WebKit (el motor de navegador de código abierto que es la base de Safari). Una de ellas podría permitir la ejecución remota de código arbitrario con solo acceder a una página web específicamente creada. Con identificadores CVE-2016-4613, CVE-2016-4666 y CVE-2016-4667.

Por otra parte, iOS se actualiza a la versión 10.1que soluciona 12 nuevas vulnerabilidades, las más graves podrían llegar a permitir la ejecución de código arbitrario. Se ven afectados los componentes CFNetwork Proxies, Contacts, CoreGraphics, FaceTime, FontParser, Kernel, libarchive, libxpc, Sandbox Profiles, System Boot y WebKit.
  
De forma similar, Apple publica WatchOS 3.1, destinada a su reloj inteligente (smartwatch) conocido como Apple Watch, con la que se solucionan ocho vulnerabilidades, la mayoría de ellas podrían permitir la ejecución remota de código arbitrario. Los problemas corregidos afectan a los componentes CoreGraphics, FontParser, Kernel, libarchive, libxpc, Sandbox Profiles y System Boot.

Por último, también ha publicado tvOS 10.0.1, el sistema operativo para Apple TV (de cuarta generación), que soluciona un total de 12 vulnerabilidades, las más graves de ellas podrían permitir la ejecución de código arbitrario. Se ven afectados los componentes: CFNetwork Proxies, CoreGraphics, FontParser, Kernel, libarchive, libxpc, Sandbox Profiles, System Boot y WebKit.

Más información:

About the security content of macOS Sierra 10.12.1

About the security content of Safari 10.0.1

About the security content of iOS 10.1

About the security content of watchOS 3.1

About the security content of tvOS 10.0.1



Antonio Ropero
Twitter: @aropero

Via:unaaldia.hispasec.com

Descarga el libro gratuito de "Seguridad en Redes"

$
0
0
Se acaba de publicar este nuevo libro gratuito denominado “Seguridad en Redes”. Esta obra presenta un enfoque eminentemente técnico de la experiencia de varios años de trabajo en grandes redes en las áreas de “Planificación y Operación de red”, “Seguridad de redes y TI” y “Auditoría de seguridad”, que podríamos afirmar, son los pilares fundamentales de toda red. Los prólogos de este libro están escritos por Chema Alonso y Antonio Castro Lechtaler, que como todos conocemos, son dos referentes internacionales en Redes y Seguridad.

Figura 1: Descarga el libro gratuito de "Seguridad en Redes"

El autor soy yo, Alejandro Corletti Estrada, que después de la publicación del libro “Seguridad por Niveles” en el año 2011  que alcanzó las 100.000 descargas, nuevamente me animé a crear esta obra para difusión y descarga gratuita para cualquier uso docente, quedando prohibida toda acción y/o actividad comercial o lucrativa, como así también su derivación y/o modificación sin autorización expresa del autor. Aquí tienes el prólogo que Chema Alonso escribió para este libro.
Ser un hacker y no un profesional 
Quiere el destino que escriba este prólogo solo un par de días después de que tuviera lugar el, hasta ahora, ataque de denegación de servicio distribuida más grande que se recuerda. Con una potencia de hasta 1.2 Terabits por segundo la botnet Mirai ha conseguido marcar el record en tráfico generado para hacer un ataque contra un objetivo concreto.

Corremos tiempos beligerantes en las redes de comunicaciones en los que los cibercriminales han encontrado en ellas un medio para perpetrar sus ataques con cierta percepción de impunidad al ocultarse en la distancia de países remotos con leyes no adaptadas que dejan que se escapen como polvo en los dedos.

Proteger este activo tan preciado que la tecnología nos ha dado es responsabilidad de todos. Desde el dueño de una impresora en su casa hasta el administrador de una pequeña red de equipos en una empresa pasando, lógico está, por los grandes proveedores de servicios en Internet. Cada fallo de seguridad en esta vasta y creciente red de redes puede ser utilizado por un adversario para conseguir una ventaja en un ataque y así, como hemos visto en el ataque que citaba al principio, la botnet Mirai se ha aprovechado de dispositivos como impresoras, routers, switches o cámaras de vigilancia mal configuradas, con bugs conocidos o contraseñas por defecto, para conseguir un número tal de equipos infectados que una empresa como DYN, que da soporte a una parte importante de los servicios DNS de Internet, no pueda contenerla.

Conocer nuestras redes, los rincones más pequeños y escorados de las mismas, para evitar que el eslabón más débil de esta cadena sea un dispositivo que forma parte del Shadow IT o el Shadow IoT de nuestra organización es fundamental. Pero más lo es conocer cómo funcionan y mantener la seguridad del mismo a lo largo del tiempo.

Decía la definición que hace el Internet Engineering Task Force en su RFC 1983 titulado Internet User’ Glossary que un Hacker es:

A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular. The term is often misused in a pejorative context, where "cracker" would be the correct term. 
Y es así lo que necesitamos todos que seas en tu red. Un auténtico hacker que tenga un conocimiento íntimo de cómo funciona tu red. Cuáles son los protocolos que están circulando por ellas, cómo están configurados, cómo se pueden mejorar y cuáles son los rastros que deben levantar una alerta en tus mecanismos de detección para saber que algo está pasando por ellas que no debiera.

Debes conocer todo lo que puedas tu red de comunicaciones. Saber cómo siente, piensa y respira cada poro de ella. Cada router, cada switch, cada firewall, cada equipo que envía o recibe tráfico por el medio que sea, por el protocolo que sea, por la aplicación que sea. Es tu red y debes conocerla como si la hubieras construido tú, debes ser el hacker de tu red y aprender de ella día a día.

En mi vida profesional, ya más larga de lo que me gustaría para poder disfrutar más de los muchos momentos que me toquen por venir aún, me he topado con una gran cantidad de informáticos que realmente no adoraban esta profesión. Profesionales que lo eran porque trabajaban de esto, pero que por falta de pasión y dedicación a conocer lo que tenían entre manos no deberían tener ese título.

Los que de verdad amamos este trabajo no escatimamos esfuerzos en aprender más día a día de lo que tenemos entre manos, en conocer aquello que desconocemos, en disfrutar del trabajo que nos llevó a meternos en esta afición que se convirtió en profesión.

Llegados a este punto debes hacerte a ti mismo esta pregunta. Debes preguntarte qué tipo de profesional quieres ser. Uno de esos que lo es por la tarjeta y la posición laboral o uno de esos que aprende todo lo que puede porque es un hacker que adora la tecnología. Decide tú. Tú manejas tu tiempo, tu vida, tus esfuerzos y tu carrera profesional. Hoy, y ahora, es el momento de que aprendas un poco más para que mañana puedas aprender un poco más sobre lo ya aprendido. Sé un hacker y no un trabajador de la informática.

Aprende todo lo que puedas y haz que tu trabajo sea tu pasión y que tu pasión sea tu trabajo. Solo así podrás ocuparte correctamente de la seguridad de tus redes.

Chema Alonso
El objetivo de esta obra es poder compartir conocimientos para que el nivel de seguridad de nuestras arquitecturas de red pueda mejorarse. El libro comienza con una detallada descripción de la historia y evolución de las redes, como punto de partida y pilar básico para ir abordando las diferentes estrategias y procesos. El texto presenta al detalle los dispositivos que forman el verdadero corazón mundial de la red fija y móvil.

Figura 2: Arquitecturas de redes para mitigar ataques DDoS 

Poco a poco sigue abordando los niveles de Switching y Routing desde un enfoque práctico y con ejemplos vigentes en las diferentes configuraciones y el empleo de los protocolos de red. Uno de los aspectos que más destacan de la obra, es la experiencia que intento transmitir por medio del uso de herramientas, comandos y programas que no pueden ser dejados de lado en el día a día de la seguridad de estas infraestructuras.

Figura 3: WireShark para analizar tráfico de red

Trata con suficiente grado de detalle los aspectos de seguridad que deben reunir los CPDs o centrales dónde se aloja el equipamiento de red. Y, como no podía ser de otra forma, el autor otra vez nos propone una importante cantidad de ejemplos prácticos en el empleo de comandos y herramientas, que tal cual menciona Chema Alonso en su prólogo, son la forma en la que operará todo hacker sobre nuestras redes y sistemas. Por lo tanto desde el punto de vista de los responsables de las mismas, deben conocerlas, saber emplearlas y sacarles provecho, previamente a que lo haga un intruso. Por supuesto, si quieres conocer más de tu adversario debes conocer cuáles son los ataques que hacen en redes IPv4 &IPv6.


Las versiones impresas de esta obra - estas sí son de pago - se distribuyen únicamente en España y se pueden solicitar a través de la cuenta  de correo info@darFe.es.  Si quieres descargar una copia, puedes hacerlo en esta URL "Libro Seguridad en Redes" y aquí lo tienes subido a SlideShare.

Autor: Alejandro Corletti Estrada
Doctor en Ingeniería y ex-jefe de redes del Ejército argentino

Via:www.elladodelmal.com

SAIVS, ¿el principio del fin de los pentesters humanos?

$
0
0
Actualmente las auditorías de aplicaciones web son realizadas por ingenieros de seguridad o pentesters y muchas veces la identificación de las vulnerabilidades depende en gran medida de su pericia, experiencia e intuición. ¿Y si elimináramos el factor humano para automatizar estas auditorías?

¿Sería posible sustituir completamente a un pentester humano por un software que no comete errores ni descuidos, capaz de obtener mayores tasas de detección de vulnerabilidades? ¿Y si se aprovecharan estos bots para los programas de recompensas de bugs?


Dejo en el aire estas preguntas, pero no me extrañaría que esto empiece a ponerse en práctica en pocos años...

Y es que una de las herramientas que más me impresionó del arsenal de la Black Hat en Asia de este año es la herramienta SAIVS (Spider Artificial Intelligence Vulnerability Scanner) de los japoneses Isao Takaesu y Takeshi Terada, que usa Inteligencia Artificial para encontrar vulnerabilidades de forma automática. Es decir, su objetivo es encontrar vulnerabilidades en aplicaciones web tal y como la haría un pentester humano.

De momento desde enero de 2016 ya están mostrando los resultados de la versión beta, que ya puede recorrer (llamarle spidering o crawling) aplicaciones web sencillas, incluyendo páginas dinámicas como "login," "create account" y "information search", y detectar vulnerabilidades como XSS y SQLi.

Mediante machine learning es capaz de establecer e imitar comportamientos humanos en tests de intrusión: "SAIVS reconoce el tipo de la página. Si se llega a la página de inicio de sesión sin tener credenciales, crea un login de inicio de sesión en la página de creación de cuentas. Después, inicia sesión con el nombre del usuario creado y rastrea el resto de las páginas y las escanea en busca de vulnerabilidades. Cuando termina todas las páginas, emite un informe del escaneo". Para ello utiliza algoritmos de aprendizaje automático como Naive Bayes, Q-Learning y Perceptrón multi-capa con el fin de lograr una de las capacidades mencionadas anteriormente, por lo que ya se puede utilizar para escanear aplicaciones web sencillas.

Aquí tenéis un vídeo con la demostración: https://www.mbsd.jp/blog/img/20160113_4.mp4 

Podéis encontrar más detalle en el blog de Isao Takaesu así como el material de la BlackHat (paper y presentación) y de la Code Blue (presentación) de 2016.

¿Llegará el día en que no haya pentesters humanos?

Via:www.hackplayers.com

Actualización de Adobe Flash Player para evitar un 0-day

$
0
0
Adobe ha publicado una actualización para Adobe Flash Player para evitar una nueva vulnerabilidad 0-day que está aprovechándose en la actualidad en ataques dirigidos y que afecta al popular reproductor. Esta vulnerabilidad podría permitir a un atacante tomar el control de los sistemas afectados.

Esta actualización, publicada bajo el boletín APSB16-36, resuelve la vulnerabilidad con CVE-2016-7855 que según informa Adobe se está empleando actualmente en ataques dirigidos contra usuarios con Windows versiones 7, 8.1 y 10. El problema reside en un uso de memoria después de liberarla que podría permitir la ejecución remota de código.

Las vulnerabilidades afectan a las versiones de Adobe Flash Player Desktop Runtime 23.0.0.185 (y anteriores) para Windows y Macintosh; Adobe Flash Player para Google Chrome 23.0.0.185 (y anteriores) para Windows, Macintosh, Linux y Chrome OS; Adobe Flash Player para Internet Explorer 11 y Microsoft Edge 23.0.0.185 (y anteriores) para Windows 10 y 8.1 y Adobe Flash Player para Linux 11.2.202.637 (y anteriores).

El problema fue reportado por Neel Mehta y Billy Leonard del Grupo de Analistas de Amenazas de Google. Adobe ha publicado las siguientes versiones de Adobe Flash Player destinadas a solucionar las vulnerabilidades, y se encuentran disponibles para su descarga desde la página oficial:
  • Flash Player Desktop Runtime 23.0.0.205
  • Flash Player para Linux 11.2.202.643
Igualmente se ha publicado la versión 23.0.0.205 de Flash Player para navegadores Internet Explorer, Edge y Chrome.

Más información:

Security updates available for Adobe Flash Player



Antonio Ropero
Twitter: @aropero

Via:unaaldia.hispasec.com

PCILeech - Direct Memory Access (DMA) Attack Software

$
0
0

The PCILeech use the USB3380 chip in order to read from and write to the memory of a target system. This is achieved by using DMA over PCI Express. No drivers are needed on the target system. The USB3380 is only able to read 4GB of memory natively, but is able to read all memory if a kernel module (KMD) is first inserted into the target system kernel. Reading 8GB of memory from the target system take around one (1) minute. The PCILeech hardware is connected with USB3 to a controlling computer running the PCILeech program. PCILeech is also capable of inserting a wide range of kernel modules into the targeted kernels - allowing for pulling and pushing files, remove the logon password requirement, loading unsigned drivers, executing code and spawn system shells. The software is written in visual studio and runs on Windows 7/Windows 10. Supported target systems are currently the x64 versions of: Linux, FreeBSD, macOS and Windows.

Hardware:
PCILeech is dependant on the PLX Technologies USB3380 chip. The actual chip can be purchased for around $15, but it's more convenient to purchase a development board on which the chip is already mounted. Development boards can be purchased from BPlus Technology, or on eBay / Ali Express. Please note that adapters may be required too depending on your requirements.
The hardware confirmed working is:
  • USB3380-EVB mini-PCIe card.
  • PP3380-AB PCIe card.
Please note that the ExpressCard EC3380-AB is not working!
Recommended adapters:
  • PE3B - ExpressCard to mini-PCIe.
  • PE3A - ExpressCard to PCIe.
  • ADP - PCIe to mini-PCIe.
  • Sonnet Echo ExpressCard Pro - Thunderbolt to ExpressCard.
Please note that other adapters may also work.

Flashing Hardware:
In order to turn the USB3380 development board into a PCILeech device it needs to be flashed. Flashing must be done in Linux as root. Download the source code for the flash kernel module to build. The files are found in the pcileech_flash folder and are named: pcileech_flash.c and Makefile. The card must be connected to the Linux system doing the flashing via PCIe.
NB! If flashing the PP3380 PCIe card the J3 jumper must be bridged to connect the EEPROM. This is not necessary for the USB3380-EVB mini-PCIe card.
  • cd /pathtofiles
  • make
  • [ insert USB3380 hardware into computer ]
  • insmod pcileech_flash.ko
The insmod command must be run as root. If compilation fails you might have to install dependencies before you try again. On debian based systems - such as debian, ubuntu and kali, run apt-get update && apt-get install gcc make linux-headers-$(uname -r) and try again.
If module insertion is successful flashing is also successful. In order to activate the flashed PCILeech device it must be power-cycled. Re-inserting it in the computer will achieve this. If one wish to flash more devices then unload the pcileech_flash kernel module by issuing the command: rmmod pcileech_flash . If there is an error flashing is unsuccessful. Please try again and check any debug error messages by issing the command: dmsg .

Installing PCILeech:
Please ensure you do have the most recent version of PCILeech by visiting the PCILeech github repository at: https://github.com/ufrisk/pcileech
Clone the PCILeech Github repository. The binaries are found in pcileech_files and should work on Windows 7 and Windows 10 64-bit versions. Please copy all files from pcileech_files since some files contains additional modules and signatures.
The Google Android USB driver also needs to be installed. Download the Google Android USB driver from: http://developer.android.com/sdk/win-usb.html#download Unzip the driver. Open Device Manager. Right click on the computer, choose add legacy hardware. Select install the hardware manually. Click Have Disk. Navigate to the Android Driver, select android_winusb.inf and install. The PCILeech lies about being a Google Glass so that the Android USB driver may be used to access the PCILeech hardware from Windows.

Generating Signatures:
PCILeech comes with built in signatures for Linux, FreeBSD and macOS. For Windows 8.1 and higher two full pages of driver code is needed to hijack the kernel. In order to avoid copyright issues the end user has to generate these signatures by themselves using the pcileech_gensig.exe program. The user needs to point to a valid ntfs.sys file in order to generate a signature. Alternatively it is possible to use the unstable/experimental win10_x64 generic built-in signature.

Capabilities:
Users should be able to extend PCILeech easily by writing own kernel shellcode modules and/or creating custom signatures used to patch target system memory. Some of the current capabilies are listed below:
  • Retrieve memory from the target system at >150MB/s.
  • Write data to the target system memory.
  • 4GB memory can be accessed in native DMA mode.
  • ALL memory can be accessed if kernel module (KMD) is loaded.
  • Execute kernel code on the target system.
  • Spawn system shell [Windows].
  • Spawn any executable [Windows].
  • Load unsigned drivers [Windows].
  • Pull files [Linux, FreeBSD, Windows, macOS].
  • Push files [Linux, Windows, macOS].
  • Patch / Unlock (remove password requirement) [Windows, macOS].

Limitations/Known Issues:
  • Read and write errors on some older hardware. Try "pcileech.exe testmemreadwrite -min 0x1000" in order to test memory reads and writes against the physical address 0x1000 (or any other address) in order to confirm.
  • Does not work if the OS uses the IOMMU/VT-d. This is the default on macOS (unless disabled in recovery mode). Windows 10 Enterprise with Virtuallization based security features enabled does not work fully - this is however not the default setting in Windows 10.
  • Some Linux kernels does not work. Sometimes a required symbol is not exported in the kernel and PCILeech fails.
  • Linux might also not work if some virtualization based features are enabled.
  • Linux based on the 4.8 kernel does not work (Ubuntu 16.10).
  • Windows Vista: some shellcode modules such as wx64_pscmd does not work.
  • Windows 7: signatures are not published.

Examples:
Load macOS kernel module:
         pcileech.exe kmdload -kmd macos    
    Remove macOS password requirement, requires that the KMD is loaded at an address. In this example 0x11abc000 is used.
           pcileech.exe macos_unlock -kmd 0x11abc000 -0 1    
      Retrieve the file /etc/shadow from a Linux system without pre-loading a KMD.
             pcileech.exe lx64_filepull -kmd LINUX_X64 -s /etc/shadow -out c:\temp\shadow    
        Show help for the lx64_filepull kernel implant.
               pcileech.exe lx64_filepull -help    
          Load a kernel module into Windows Vista by using the default memory scan technique.
                 pcileech.exe kmdload -kmd winvistax64    
            Load a kernel module into Windows 10 by targeting the page table of the ntfs.sys driver signed on 2016-03-29.
                   pcileech.exe kmdload -kmd win10x64_ntfs_20160329 -pt    
              Load a kernel module into Windows 10 (unstable/experimental). Compatible with VBS/VTL0 only if "Protection of Code Integrity" is not enabled.
                     pcileech.exe kmdload -kmd WIN10_X64    
                Spawn a system shell on the target system (system needs to be locked and kernel module must be loaded). In this example the kernel module is loaded at address: 0x7fffe000.
                       pcileech.exe wx64_pscmd -kmd 0x7fffe000    
                  Show help for the dump command.
                         pcileech.exe dump -help    
                    Dump all memory from the target system given that a kernel module is loaded at address: 0x7fffe000.
                           pcileech.exe dump -kmd 0x7fffe000    

                      Building:
                      The binaries are found in the pcileech_files folder. If one wish to build an own version it is possible to do so. Compile the pcileech and pcileech_gensig projects from within Visual Studio. Tested with Visual Studio 2015. To compile kernel- and shellcode, located in the pcileech_shellcode project, please look into the individual files for instructions. These files are usually compiled command line.

                      Changelog:
                      v1.0
                      • Initial release.
                      v1.1
                      • core: help for actions and kernel implants.
                      • core: search for signatures (do not patch).
                      • core: signature support for wildcard and relative offsets in addition to fixed offsets.
                      • implant: load unsigned drivers into Windows kernel [wx64_driverload_svc].
                      • signature: generic Windows 10 (Unstable/Experimental) [win10_x64].
                      • signature: Windows 10 updated.
                      • signature: Linux unlock added.
                      • other: firmware flash support without PLX SDK.
                      • other: various bug fixes.
                      v1.2
                      • core: FreeBSD support.
                      • implant: pull file from FreeBSD [fbsdx64_filepull]
                      • signature: Windows 10 updated.
                      • signature: macOS Sierra added.
                      • other: various bug fixes and stability improvements.
                      latest
                      • new implant: spawn cmd in user context [wx64_pscmd_user]
                      • implant: stability improvements for Win8+ [wx64_pscreate, wx64_pscmd, wx64_pscmd_user]



                      Via:www.kitploit.com
                      Viewing all 1954 articles
                      Browse latest View live