La NSA construyó su propio ‘Google secreto’

La Agencia de Seguridad Nacional de EE.UU. (NSA) construyó un sistema de intercambio de información masivo destinado a permitir a la Policía el acceso a los registros que detallan la vida de personas de todo el mundo.

ICREACH, un buscador tipo Google, fue desarrollado por la agencia ya en 2007, pero no se ha hecho público hasta este lunes gracias a los documentos clasificados que dio a conocer el excontratista de la NSA Edward Snowden, escribe The Intercept.

Los documentos filtrados indican que el buscador creado por la NSA permite a los analistas de inteligencia de 23 agencias gubernamentales, incluyendo la Oficina Federal de Investigación (FBI) y la Agencia de Control de Drogas, compartir un conjunto de datos sensibles recogidos por la comunidad de inteligencia de EE.UU. y sus socios en relación no solo a los sospechosos de terrorismo extranjero, sino a “millones de registros de ciudadanos estadounidenses que no han sido acusados de ningún delito”, observa el medio.

Según The Intercept, “la información compartida a través de ICREACH se puede utilizar para rastrear los movimientos de la gente, trazar sus redes de asociados, ayudar a predecir las acciones futuras y potencialmente revelar las creencias religiosas o las afiliaciones políticas”.

Los detalles sobre ICREACH muestran que la NSA construyó un buscador que puede contener más de 850.000 millones de registros diferentes. Con respecto a este sistema específico, la NSA parece haber creado un buscador lo suficientemente potente como para permitir a los agentes del Gobierno algún día rastrear el equivalente a más de 100 registros para cada persona en la Tierra.

Y ya que los documentos aportados por Snowden son de hace algún tiempo, la agencia podría haber dado ya los primeros pasos hacia el aumento de la capacidad de almacenar información sensible, apunta el medio.

Fuente: http://actualidad.rt.com/actualidad/

Anuncios

Entrevista a Bernardo Quintero fundador de Virustotal, comprada por Google

empresa

Con motivo de la compra de Virustotal por parte de Google entrevistamos a Bernardo Quintero, fundador de la empresa. Muy recomendable también leer la nota que ha publicado en el boletín de noticias una-al-día donde muestra su filosofía sobre cómo se deben crear las empresas de internet y lanza algunos consejos muy interesantes para emprendedores.

De dónde nace tu interés por la seguridad informática? cuáles crees que son los principales retos a los que se enfrenta este sector de aquí en adelante?

Mi historia con la informática supongo que es muy similar a la de cualquiera de mi generación. Cuando era un crío quería una consola de videojuegos, mi padre en su lugar, y con buen criterio, me compró un Spectrum con 16kB de memoria. Ahí empecé a interesarme en la programación y la informática en general, desarrollando juegos a nivel totalmente amateur.

El mundo de la seguridad no llegaría hasta la época adolescente, cuando tuve mi primer PC, un Amstrad PC1512 sin disco duro, y me infecté por primera vez con un virus Se trataba del “Ping-Pong”, un virus de boot que se propagaba a través del sector de arranque de los disquetes, cuando se activa te muestra en pantalla una especie de pelotita rebotando en los márgenes de la pantalla y borrando todos los caracteres que encuentra a su paso. Me fascinó aquello, era capaz de reproducirse y pasar de disquete en disquete y de ordenador en ordenador, era una especie de vida artificial. Así que me puse a investigar sobre el tema y terminé desarrollando un pequeño detector para ese tipo de virus para poder protegerme. Después de aquello no volví a tocar el tema de los virus hasta el primer curso en la universidad, donde surgió otra oportunidad.

La incursión a nivel profesional en seguridad informática vendría con la creación del boletín “una-al-día” e Hispasec, en 1998. En principio fue simplemente un boletín de noticias sobre seguridad informática, sin ninguna otra pretensión, pero dos años más tarde nos vimos “forzados” a crear la sociedad limitada para poder satisfacer los servicios que los lectores del boletín nos pedían de forma espontánea. Llegamos a tener más de 100.000 suscriptores del boletín por e-mail, sólo por el boca a boca, sin ningún tipo de publicidad. Fuimos una empresa creada a demanda del mercado, sin plan de negocio, sin idea de donde nos estábamos metiendo. Hispasec me llevó a sumergirme en todo tipo de disciplinas relacionadas con la seguridad informática e Internet, así que soy aprendiz de todo y experto en nada 🙂

Para tí cuál ha sido el principal motivo para que Virustotal haya tenido tanto éxito y haya llegado a llamar la atención de Google?

VirusTotal se diseñó para dar solución a un problema, no pensando en un modelo de negocio. En mi opinión ese enfoque fue parte de su éxito, si hubiéramos pensado en inicio en como monetizar el servicio probablemente no hubiéramos ido muy lejos. Hay proyectos donde, por su naturaleza, el dinero no llega hasta que has conseguido una masa de usuarios importantes alrededor de él, y en muchos casos el modelo de negocio aparece o evoluciona de una forma que no hubieras imaginado inicialmente. Mi forma de emprender es poner el foco en solucionar un problema de la mejor manera posible, no de la manera más rentable económicamente, así que supongo soy un “mal empresario”.

Cómo ves el panorama de las startups en España y dónde crees que están las mejores oportunidades de negocio en estos momentos?

Respecto al sector, todo lo relacionado con seguridad TIC no ha dejado de crecer en los últimos 15 años, y los indicadores apuntan a que seguirá así. Además es un mercado especialmente estable, incluso en momentos de crisis como los actuales se acentúa la necesidad de estar protegidos por un aumento en los ataques e intentos de fraude. Es un sector que recomiendo tanto a emprendedores como a jóvenes técnicos a los que les apasione el tema, es una profesión con presente y futuro.

Cuáles son tus planes a partir de ahora tras la compra de Virustotal por parte de Google?

Mis planes siguen siendo los mismos que antes de la adquisición, nuestra filosofía y objetivos no han cambiado. Google comparte nuestra visión de proteger a los usuarios del malware, así como de proveer de servicios a la comunidad e industria de la seguridad para incrementar la seguridad de toda la web. VirusTotal seguirá su camino, pero sin duda ahora tendremos más posibilidades de acelerar la consecución de nuestros objetivos.

Y para el que le haya sabido a poco aquí tenéis otra entrevista más extensa y centrada en los temas de seguridad informática.

Un troyano diseñado para Linux afecta a los usuarios de Windows.

Habitualmente estamos acostumbrados a leer esta frase al revés: un software de Windows es portado a Linux para que los usuarios del sistema operativo libre puedan utilizarlo sin necesidad de emuladores. Sin embargo, Linux también tiene grandes piezas de software (buenas o maliciosas) que algunos consideran de interés para portarlas al sistema operativo más utilizado: Windows.

 

Aunque el sistema operativo libre tiene fama de ser mucho más seguro que Windows o Mac OS X, en realidad no es un sistema operativo blindado. Algunos usuarios malintencionados han desarrollado también aplicaciones maliciosas que afectan a los usuarios de este sistema operativo aunque a menor escala ya que es más complicado infectarse y, de hacerlo, que el malware logre actuar con libertad sin permisos de root. Un ejemplo de malware para Linux es una herramienta maliciosa detectada en mayo de este mismo año utilizada para controlar los sistemas de forma remota y realizar ataques DDoS contra otros objetivos.

La empresa Dr. Web ha detectado que una de las variantes de este troyano para Linux, denominada Trojan.DnsAmp.1 ha sido portada a Windows y está afectando a un considerable número de usuarios en todo el mundo. Esta nueva variante se instala en los sistemas bajo el servicio “Test My Test Server 1.0″ y se almacena en el disco duro bajo el nombre “vmware-vmx.exe”.

linux_troyano_ddos

Cuando este malware infecta al usuario envía una señal al pirata informático y queda pendiente de recibir órdenes con un objetivo concreto al que atacar. También es capaz de funcionar como “downloader” y descargar otras piezas de malware en el sistema operativo de la víctima, lo que aumenta potencialmente su peligrosidad. La mayor parte de los ataques DDoS detectados durante los últimos dos meses han sido generados por este malware, lo que indica que su actividad ha aumentado y supone un peligro real para los usuarios de Internet.

Un antivirus actualizado y sentido común al descargar y ejecutar archivos son los principales consejos para evitar ser víctima de este malware que ha llegado desde Linux.

¿Cuáles son los países de América Latina más vulnerables al ciberespionaje?

Latinoamérica es una de las regiones del planeta más expuestas a los ciberataques, que han estado afectando a entidades militares, diplomáticas y gubernamentales de países como Colombia, Venezuela y Ecuador desde el 2010.

Ciudadanos y organizaciones de Brasil, México, Venezuela y Perú son las principales víctimas. El director del equipo de seguridad y análisis para América Latina de Kaspersky, Dmitri Bestúzhev, afirmó que “no se puede especular sobre el origen de los ataques, aunque se sabe que quien está detrás de esto habla español y es de Latinoamérica. Se han robado cientos de gigabytes de información clasificada”, a lo que añadió también que “al menos 775 personas y otras entidades se han visto afectadas”.

En Latinoamérica, Brasil es el país más expuesto a los crímenes cibernéticos. En 2013 fue víctima de entre el 33 % y el 43% de los ataques en la región, sostuvo el especialista.

Bestúzhev, quien participó en la Cuarta Cumbre de Analistas de Seguridad, indicó que el espionaje cibernético también afectó a las misiones diplomáticas de Rusia, Francia, China, Bélgica y España en los países latinoamericanos. “A los atacantes no les interesaba el dinero, sino información clasificada de carácter militar, estratégica y todo lo relacionado con la seguridad y de los servicios de Inteligencia de un Gobierno”, remarcó Bestúzhev.

La compañía rusa Kaspersky Lab denominó ‘Machete’ esta oleada de ataques que fue descubierta cuando un general de un Estado latinoamericano viajó a China y sospechó que su ordenador había sido vulnerado. El militar contactó con el servicio de asistencia de su antivirus, Kaspersky Lab, quienes hallaron en su dispositivo un paquete de Java con librerías de grabación de archivos de audio, archivos cifrados y archivos con lenguajes de programación.

Detrás de Machete podría esconderse un servicio de espionaje de un país latinoamericano

La investigación de Machete por parte de la compañía rusa les llevó a concluir que este virus era parecido a lo que se conoce en términos informáticos como ‘troyano’, solo que este era desconocido hasta el momento, por lo que las bases de datos de los antivirus no lo detectaron antes. Se sospecha que este virus se infiltraba en los equipos cuando sus víctimas descargaban archivos de Power Point especialmente creados, de acuerdo con el perfil del usuario objetivo, con material pornográfico, bélico o político.

El virus permitía interceptar otros dispositivos de hardware como teclados y micrófonos, tomar capturas de pantalla y registrar físicamente a las víctimas para robar y filtrar información a páginas web que controlaba su diseñador, desde donde descargaba los datos a un dispositivo de almacenamiento físico o virtual desconocido de momento. Desde Kaspersky no descartan que detrás de Machete se encuentre algún servicio de espionaje de la misma región latinoamericana.

América Latina es una de las regiones del mundo más expuestas a las vulneraciones informáticas provocadas por softwares malignos o malware.

Fuente: http://actualidad.rt.com/actualidad/

Snowden destapa a MonsterMind, el antivirus de la NSA

La NSA prepara MonsterMind, un bot anti-malware

La NSA prepara MonsterMind, un bot anti-malware

Edward Snowden, al que algunos conocen como “el hombre más buscado del mundo”, ha revelado nuevos datos sobre la NSA. Uno de estos datos tiene mucho que ver con el proyecto MonsterMind, que tiene como objetivo eliminar todo el malware que se detecte en las redes a nivel mundial.

MonsterMind aparentemente parece una gran idea, aunque para eliminar todo el malware hay que atacar a la privacidad para descubrir si es malware o no. Esto supondría un escaneo constante de redes de datos, que puede que a más de uno no le haga gracia alguna.

Por otro lado, Matt Blaze, profesor en la Universidad de Pensilvania, reconocía que estos ataques pueden detectarse a través de un patrón en los metadatos de esos paquetes de información. Este patrón sería capaz de detectar y eliminar el malware, antes de que afectase al dispositivo.

Este nuevo proyecto, no solamente tendría la capacidad de poder anular estos ataques maliciosos, sino que incluso podría contraatacar detectando al responsable/s de esos ataques y yendo a por él/ellos. Detectar estos ataques supone un rastreo profundo por parte de la NSA para que recoja y analice todo el tráfico de Internet, detectando así lo malo.

Hace años, DARPA había lanzado algo similar, el llamado Plan X. En estos momentos desconocemos el estado actual en el que se encuentra, por lo que podría estar siguiéndonos el rastro o inactivo. Estamos efectivamente ante proyectos que para mejorar y ayudarnos con la seguridad, deben atacar antes a nuestra privacidad.

Fuente:http://www.elgrupoinformatico.com

UMAP To Test the Security Of USB Host Implementations

UMAP To Test the Security Of USB Host Implementations. Its is a tool which allows you to test the security of USB host implementations i.e. something you plug a USB device into, like a PC or a tablet. Its primary function at the moment is a fuzzer with test cases based on a combination of data from standards documentation and the author’s experience of where USB bugs are commonly found. However, it also has additional functionality that will be expanded further in future versions, for example:

> Operating system identification
> Installed application identification
> Vendor-specific driver enumeration
> Endpoint Protection System assessment

Running Umap

umap is written in Python so to run it just type:
$ sudo python3 umap.py
(umap must be run as root)
---------------------------------------
 _   _ _ __ ___   __ _ _ __
| | | | '_ ` _ \ / _` | '_ \
| |_| | | | | | | (_| | |_) |
 \__,_|_| |_| |_|\__,_| .__/
                      |_|

The USB host assessment tool
Andy Davis, NCC Group 2013
Version: 1.01

Based on Facedancer by Travis Goodspeed

For help type: umap.py -h
---------------------------------------

Error: Facedancer serial port not supplied
As you can see, it complains that you haven’t supplied the serial port to which the Facedancer is connected. By typing umap.py -h you can see how to do this:
Usage: umap.py

Options:
  --version    show program's version number and exit
  -h, --help   show this help message and exit
  -P SERIAL    Facedancer serial port **Mandatory option** (SERIAL=/dev/ttyX
               or just 1 for COM1)
  -L           List device classes supported by umap
  -i           identify all supported device classes on connected host
  -c CLS       identify if a specific class on the connected host is supported
               (CLS=class:subclass:proto)
  -O           Operating system identification
  -e DEVICE    emulate a specific device (DEVICE=class:subclass:proto)
  -v VID       specify Vendor ID (hex format e.g. 1a2b)
  -p PID       specify Product ID (hex format e.g. 1a2b)
  -r REV       specify product Revision (hex format e.g. 1a2b)
  -f FUZZC     fuzz a specific class (FUZZC=class:subclass:proto:E/C/A[:start
               fuzzcase])
  -s FUZZS     send a single fuzz testcase
               (FUZZS=class:subclass:proto:E/C:Testcase)
  -d DLY       delay between enumeration attempts (seconds): Default=1
  -l LOG       log to a file
  -R REF       Reference the VID/PID database (REF=VID:PID)
  -u           update the VID/PID database (Internet connectivity required)

  Experimental Options:
    -A APPLE   emulate an Apple iPhone device (APPLE=VID:PID:REV)
    -b VENDOR  brute-force vendor driver support (VENDOR=VID:PID)

The only mandatory option is -P to provide the serial port that the Facedancer board is connected to e.g.
$ sudo python3 umap.py -P /dev/ttyUSB0

First – what drivers are supported?

In order to fuzz a USB host you need to emulate the process of physical insertion and removal of your virtual device. The USB design is expecting this process to be performed by a human and therefore, attempting to perform the operation too quickly results in the host getting confused (…but that a whole different area of potential research). As a result, USB fuzzing can be very slow (7-10 seconds per fuzz test case) so it’s very important to be able to enumerate what classes of USB device are supported by the host before you start fuzzing.
To display which device classes umap can emulate use the -L option, which results in something like this:
XX:YY:ZZ - XX = Class : YY = Subclass : ZZ = Protocol
01:01:00 - Audio : Audio control : PR Protocol undefined
01:02:00 - Audio : Audio streaming : PR Protocol undefined
02:02:01 - CDC Control : Abstract Control Model : AT commands V.250
02:03:ff - CDC Control : Telephone Control Model : Vendor specific
02:06:00 - CDC Control : Ethernet Networking Control Model : No class-specific protocol required
03:00:00 - Human Interface Device : No subclass : None
06:01:01 - Image : Still image capture device : Bulk-only protocol
07:01:02 - Printer : Default : Bidirectional interface
08:06:50 - Mass Storage : SCSI : BBB
09:00:00 - Hub : Default : Default
0a:00:00 - CDC Data : Default : Default
0b:00:00 - Smart Card : Default : Default
As you can see, USB class information is represented by three bytes, the first being the base class e.g. 08 = Mass Storage class, the second is the sub-class e.g. 06 = SCSI (for Mass Storage) and the third is the protocol e.g. BBB (for Mass Storage).
In order to identify which of these virtual devices is supported by the USB host that your are testing, use the following command:
$ sudo python3 umap.py -P /dev/ttyUSB0 -i

01:01:00 - Audio : Audio control : PR Protocol undefined
 **SUPPORTED**
01:02:00 - Audio : Audio streaming : PR Protocol undefined
 **SUPPORTED**
02:02:01 - CDC Control : Abstract Control Model : AT commands V.250
 
02:03:ff - CDC Control : Telephone Control Model : Vendor specific
 
02:06:00 - CDC Control : Ethernet Networking Control Model : No class-specific protocol required
 
03:00:00 - Human Interface Device : No subclass : None
 **SUPPORTED**
06:01:01 - Image : Still image capture device : Bulk-only protocol
 **SUPPORTED**
07:01:02 - Printer : Default : Bidirectional interface
 
08:06:50 - Mass Storage : SCSI : BBB
 **SUPPORTED**
09:00:00 - Hub : Default : Default
 **SUPPORTED**
0a:00:00 - CDC Data : Default : Default
 **SUPPORTED**
0b:00:00 - Smart Card : Default : Default
The output above shows that the Audio device class is supported, but CDC is not. The -c option allows you to test if specific device classes are supported by the host rather than cycling through all of them.

Emulating a virtual USB device

Now that we know what classes are supported we can emulate a device and virtually connect it to the USB target host. Below is output of umap emulating a Still image capture device connected to an Ubuntu Linux host, which concluded with Linux starting the Shotwell application and displaying an image that is stored on the virtual USB camera device:
$ sudo python3 umap.py -P /dev/ttyUSB0 -e 06:01:01

Emulating 06:01:01 - Image : Still image capture device : Bulk-only protocol
Facedancer reset
GoodFET monitor initialized
MAXUSB initialized
MAXUSB enabled
MAXUSB revision 19
MAXUSB connected device USB image device
USB image device received request dir=1, type=0, rec=0, r=6, v=256, i=0, l=64
USB image device received GET_DESCRIPTOR req 1, index 0, language 0x0000, length 64
MAXUSB wrote 12 01 00 02 00 00 00 40 da 04 74 23 10 00 01 02 03 01 to endpoint 0
USB image device received request dir=0, type=0, rec=0, r=5, v=15, i=0, l=0
USB image device received SET_ADDRESS request for address 15
USB image device received request dir=1, type=0, rec=0, r=6, v=256, i=0, l=18
USB image device received GET_DESCRIPTOR req 1, index 0, language 0x0000, length 18
MAXUSB wrote 12 01 00 02 00 00 00 40 da 04 74 23 10 00 01 02 03 01 to endpoint 0
USB image device received request dir=1, type=0, rec=0, r=6, v=1536, i=0, l=10
USB image device received GET_DESCRIPTOR req 6, index 0, language 0x0000, length 10
MAXUSB wrote 0a 06 00 02 00 00 00 40 01 00 to endpoint 0
USB image device received request dir=1, type=0, rec=0, r=6, v=512, i=0, l=9
USB image device received GET_DESCRIPTOR req 2, index 0, language 0x0000, length 9
MAXUSB wrote 09 02 27 00 01 01 04 e0 32 to endpoint 0
USB image device received request dir=1, type=0, rec=0, r=6, v=512, i=0, l=39
USB image device received GET_DESCRIPTOR req 2, index 0, language 0x0000, length 39
MAXUSB wrote 09 02 27 00 01 01 04 e0 32 09 04 00 00 03 06 01 01 00 07 05 01 02 40 00 00 07 05 82 02 40 00 00 07 05 83 03 08 00 10 to endpoint 0
USB image device received request dir=1, type=0, rec=0, r=6, v=768, i=0, l=255
USB image device received GET_DESCRIPTOR req 3, index 0, language 0x0000, length 255
MAXUSB wrote 04 03 09 04 to endpoint 0
USB image device received request dir=1, type=0, rec=0, r=6, v=770, i=1033, l=255
USB image device received GET_DESCRIPTOR req 3, index 2, language 0x0409, length 255
MAXUSB wrote 10 03 44 00 4d 00 43 00 2d 00 46 00 53 00 37 00 to endpoint 0
USB image device received request dir=1, type=0, rec=0, r=6, v=769, i=1033, l=255
USB image device received GET_DESCRIPTOR req 3, index 1, language 0x0409, length 255
MAXUSB wrote 14 03 50 00 61 00 6e 00 61 00 73 00 6f 00 6e 00 69 00 63 00 to endpoint 0
USB image device received request dir=1, type=0, rec=0, r=6, v=771, i=1033, l=255
USB image device received GET_DESCRIPTOR req 3, index 3, language 0x0409, length 255
MAXUSB wrote 3e 03 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 31 00 58 00 30 00 32 00 30 00 39 00 30 00 33 00 30 00 37 00 35 00 34 00 to endpoint 0
USB image device received request dir=0, type=0, rec=0, r=9, v=1, i=0, l=0
USB image device received SET_CONFIGURATION request
USB image device received request dir=1, type=0, rec=0, r=6, v=772, i=1033, l=255
USB image device received GET_DESCRIPTOR req 3, index 4, language 0x0409, length 255
MAXUSB wrote 0c 03 49 00 6d 00 61 00 67 00 65 00 to endpoint 0
USB image interface handling 16 bytes of Image class data
USB image interface got OpenSession
USB image interface sent Image:OK
USB image interface responding with 12 bytes: 0c 00 00 00 03 00 01 20 00 00 00 00
USB image interface handling 12 bytes of Image class data
USB image interface got GetDeviceInfo
USB image interface sent Image:OK
USB image interface responding with 211 bytes: d3 00 00 00 02 00 01 10 01 00 00 00 64 00 06 00 00 00 64 00 00 00 00 10 00 00 00 01 10 02 10 03 10 04 10 05 10 06 10 07 10 08 10 09 10 0a 10 0c 10 0d 10 14 10 15 10 16 10 1b 10 04 00 00 00 04 40 05 40 08 40 09 40 02 00 00 00 06 d4 07 d4 00 00 00 00 06 00 00 00 01 30 02 30 06 30 0d 30 01 38 0d 38 0a 50 00 61 00 6e 00 61 00 73 00 6f 00 6e 00 69 00 63 00 00 00 08 44 00 4d 00 43 00 2d 00 46 00 53 00 37 00 00 00 04 31 00 2e 00 30 00 00 00 20 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 31 00 58 00 30 00 32 00 30 00 39 00 30 00 33 00 30 00 37 00 35 00 34 00 00 00 00 00
USB image interface responding with 12 bytes: 0c 00 00 00 03 00 01 20 01 00 00 00
USB image interface handling 12 bytes of Image class data
USB image interface got GetStorageIDs
USB image interface sent Image:OK
USB image interface responding with 20 bytes: 14 00 00 00 02 00 04 10 02 00 00 00 01 00 00 00 01 00 01 00
USB image interface responding with 12 bytes: 0c 00 00 00 03 00 01 20 02 00 00 00
USB image interface handling 16 bytes of Image class data
USB image interface got GetStorageInfo
USB image interface sent Image:OK
USB image interface responding with 40 bytes: 28 00 00 00 02 00 05 10 03 00 00 00 04 00 03 00 00 00 00 00 18 78 00 00 00 00 00 80 da 77 00 00 00 00 00 00 00 00 00 00
--truncated for brevity--

Emulating a specific device

Specific USB devices are identified by three 16-bit numbers: Vendor ID (VID), Product ID (PID) and Revision number (Rev – although this is often not used and just left as zero). This information is registered with and maintained by the USB Implementers Forum. If you wish to emulate a specific device of a certain class you can specify the VID, PID and REV using the -v, -p and -r options respectively. Furthermore, umap maintains a local copy of the VID/PID/REV database and lookups can be performed using the -R option (the local copy can be updated with -u). An example is shown below:
$ sudo python3 umap.py -P /dev/ttyUSB0 -R 04da:2374

Looking up VID= 04da / PID= 2374
Panasonic (Matsushita) Lumix Camera (PTP mode)

$ sudo python3 umap.py -P /dev/ttyUSB0 -e 06:01:01 -v 04da -p 2374 -r 0000

VID = 04da
PID = 2374
REV = 0000
Emulating 06:01:01 - Image : Still image capture device : Bulk-only protocol
Facedancer reset
GoodFET monitor initialized
MAXUSB initialized
MAXUSB enabled
MAXUSB revision 0
MAXUSB connected device USB image device
USB image device received request dir=1, type=0, rec=0, r=6, v=256, i=0, l=64
USB image device received GET_DESCRIPTOR req 1, index 0, language 0x0000, length 64
MAXUSB wrote 12 01 00 02 00 00 00 40 da 04 74 23 00 00 01 02 03 01 to endpoint 0
USB image device received request dir=0, type=0, rec=0, r=5, v=16, i=0, l=0
USB image device received SET_ADDRESS request for address 16
USB image device received request dir=1, type=0, rec=0, r=6, v=256, i=0, l=18
USB image device received GET_DESCRIPTOR req 1, index 0, language 0x0000, length 18
MAXUSB wrote 12 01 00 02 00 00 00 40 da 04 74 23 00 00 01 02 03 01 to endpoint 0
USB image device received request dir=1, type=0, rec=0, r=6, v=1536, i=0, l=10
USB image device received GET_DESCRIPTOR req 6, index 0, language 0x0000, length 10
MAXUSB wrote 0a 06 00 02 00 00 00 40 01 00 to endpoint 0
USB image device received request dir=1, type=0, rec=0, r=6, v=512, i=0, l=9
USB image device received GET_DESCRIPTOR req 2, index 0, language 0x0000, length 9
MAXUSB wrote 09 02 27 00 01 01 04 e0 32 to endpoint 0
--truncated for brevity--

Operating system identification

umap can perform simple operating system identification (this will be extended in future versions of the tool) using the -O option. More information about techniques that can be used to identify operating systems and applications via USB can be found in the Revealing Embedded Fingerprintswhite paper. An example is shown below:
$ sudo python3 umap.py -P /dev/ttyUSB0 -O

Fingerprinting the connected host - please wait...

OS Matches: Apple iPad/iPhone

Fuzzing

The primary function of umap is fuzzing. So if you wish to fuzz a specific device class on the target host you can use either the -f (fuzz) or -s (single-shot) options. The class information is provided as usual, but you also need to specify if you want to fuzz just the enumeration phase (‘E’), just the class-specific test cases (‘C’) or everything (‘A’). In single-shot mode you then need to provide the test case number to use and if a test case number if provided in fuzz mode, the fuzzer will start at the specified test case. Examples are shown below (note that in both modes umap first performs a test to confirm that the device class is supported by the target):
$ sudo python3 umap.py -P /dev/ttyUSB0 -s 01:01:00:E:6

Fuzzing:
01:01:00 - Audio : Audio control : PR Protocol undefined
 **SUPPORTED**
2013/10/10 15:35:26 Enumeration phase: 0006 - Device_bMaxPacketSize0_null
$ 
$ sudo python3 umap.py -P /dev/ttyUSB0 -f 01:01:00:C

Fuzzing:
01:01:00 - Audio : Audio control : PR Protocol undefined
 **SUPPORTED**
Class-specific data...
2013/10/10 15:38:04 Audio class: 0000 - CSInterface1_wTotalLength_null
2013/10/10 15:38:15 Audio class: 0001 - CSInterface1_wTotalLength_lower
2013/10/10 15:38:26 Audio class: 0002 - CSInterface1_wTotalLength_higher
2013/10/10 15:38:37 Audio class: 0003 - CSInterface1_wTotalLength_max
2013/10/10 15:38:47 Audio class: 0004 - CSInterface1_baInterfaceNr1_null

*** No response from host - check if the host is still functioning correctly ***
$
In the second example above, the target crashed as a result of the fourth test case (CSInterface1_wTotalLength_max), as there is no response to the fifth test case that was sent. The test cases are stored in testcases.py and therefore can easily be changed or added to.

Logging

The output can be logged to a file using the -l option:
-l LOG       log to a file

Delay

It’s highly unlikely you’ll need this option, but if you wish to add a delay between test cases then the -d option can be used:
-d DLY       delay between enumeration attempts (seconds): Default=1

Download – See more at: http://blog.hackersonlineclub.com/2014/06/umap-to-test-security-of-usb-host.html#sthash.7QqMNws9.dpuf

Análisis de tráfico SSL

El protocolo SSL (y su sucesor, TLS), es el principal encargado de que las comunicaciones en Internet sean seguras, proporcionando múltiples opciones de cifrado y autenticación. El cifrado es obligatorio, mientras que la autenticación no, aunque normalmente se autentica al menos el servidor, para evitar ataques de tipo Man-in-the-Middle. Obviamente, es un protocolo imprescindible en cuanto la información transmitida es mínimamente sensible.

No obstante, también complica el análisis de las comunicaciones por parte de los responsables de seguridad, ya que no es posible hacer un filtrado basado en el contenido del tráfico, al estar cifrado. De hecho, no es raro encapsular tráfico dentro de SSL para evadir el control de proxies o firewalls. Este análisis puede también ser necesario para análisis de incidentes, o para conocer en detalle qué información estamos mandando a webs o aplicaciones que utilizan este protocolo.

En esta entrada veremos dos alternativas distintas para analizar tráfico SSL, explicando los principios que hacen posible el descifrado de los datos. Pero antes de nada, destacar que interceptar tráfico SSL ajeno, sin consentimiento o autorización explícita, no es legal.

Negociación de claves

Dentro de las suites de cifrado que ofrece SSL, encontramos criptosistemas destinados a la negociación de claves, al cifrado de información y a su autenticación. Por ejemplo, para los algoritmos definidos en el RFC 5246:

  • TLS_RSA_WITH_AES_128_CBC_SHA: Utiliza RSA para intercambio de claves, cifra con AES-128 en modo CBC y utiliza SHA1 en la autenticación HMAC.
  • TLS_DH_anon_WITH_AES_256_CBC_SHA: Utiliza Diffie-Hellman anónimo (sin autenticar) para intercambio de claves, AES-256 en modo CBC para cifrado, y SHA1 para la autenticación HMAC.
  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: Utiliza Diffie-Hellman efímero con DSS (derivado de DSA) para autenticar el intercambio de claves, AES-256 en modo CBC para cifrado y autenticación HMAC con SHA-256.

En lo concerniente a esta entrada, para entender cómo funciona la intercepción del tráfico, nos interesa la primera parte (la verde), ya que es la encargada de la generación de las claves criptográficas. Para saber qué esquema utiliza un sitio web concreto, se puede utilizar por ejemplo la web de Qualys SSL Labs o, para los que sean más de consola, un script como el descrito en este post de superuser.com. Chrome también lo muestra, al pinchar en el candado que indica que SSL está activo, y acceder a la pestaña “Conexión”.

Resumiendo, en SSL cliente y servidor negocian un premaster secret común, del que derivan el master secret, que a su vez usan para crear las claves criptográficas para autenticación y cifrado. Con los diferentes mecanismos de negociación de clave, lo que se hace es variar la forma en que se obtiene dicho premaster secret.

Descifrando SSL directamente con el premaster secret

Evidentemente, si nos hacemos con el premaster secret, podemos realizar todos los cálculos necesarios para derivar las claves finales igual que hacen cliente y servidor. Esta opción es la que menos esfuerzo requiere, ya que los propios navegadores permiten volcar el premaster secret a un fichero. Posteriormente, en Wireshark, desde “Edit > Preferences > Protocols > SSL” se puede indicar dónde se encuentran estos ficheros.

Wireshark: fichero de  premaster secrets

La principal ventaja de este método es, evidentemente, su sencillez. La principal desventaja (de cara al análisis de incidentes), es que sólo sirve para analizar nuestro propio tráfico, aunque si lo que queremos es estudiar el tráfico de una aplicación concreta, esto tampoco es problema. Esto podría solventarse concatenando todos los ficheros de log obtenidos de los navegadores de las distintas máquinas, ya que Wireshark va explorando una a una las entradas de dicho fichero hasta encontrar una que permite descifrar el tráfico. No obstante, esto reduce la sencillez y dificulta la escalabilidad.

Descifrando SSL con un proxy MitM

En esta alternativa no se tiene acceso directo al premaster secret y básicamente, actuamos como un atacante activo, a modo de Man-in-the-Middle. Hay varios proxies que permiten realizar la intercepción necesaria para el posterior descifrado. Por ejemplo, Burp Proxy, mitmproxy o Squid con SSL Bump. Posteriormente, con Wireshark, se puede especificar la clave privada utilizada por el proxy para negociar el premaster secret. Evidentemente, hay que configurar los navegadores (o las máquinas) para que enruten el tráfico a través del proxy. Pero aparte de esto, ¿cuál es la teoría detrás de la práctica?

Cuando el método de intercambio de claves utilizado es RSA, el cliente calcula el premaster secret y lo envía cifrado con la clave pública (RSA) del servidor. En este caso, al cambiar el certificado del servidor original por el de nuestro proxy, podremos utilizar la clave privada asociada para descifrar el premaster secret.

Si se utiliza Diffie-Hellman, el modo de proceder será modificar el tráfico, utilizando unos valores (z, Z = gz) propios en lugar de los valores (a, A = ga) y (b, B = gb) que generan cliente y servidor durante el algoritmo, tal y como se muestra en el siguiente esquema (imagen original de Wikipedia), donde Alice sería el cliente, Bob el servidor y Mallory nuestro proxy.

MITM en Diffie-Hellman

En caso de utilizarse la variante no autenticada de Diffie-Hellman (DH_anon), con eso será suficiente. Si, como se hace normalmente, sí se autentica el intercambio, el proxy tendrá que cambiar el certificado que envía el servidor. En los esquemas definidos como DH, el valor B enviado por el servidor es fijo (contenido en el certificado del servidor); mientras que en los definidos como DHE (la E viene de efímero), este valor se genera aleatoriamente en cada negociación y es firmado por el servidor (con la clave privada asociada a su certificado). Por tanto, la intercepción variará también dependiendo de si el algoritmo es DH o DHE. No obstante, de todo esto se encarga el proxy, ya que negocia sesiones SSL de forma independiente con cliente y servidor.

En cualquier caso, dejando de lado la teoría, una vez esté en marcha el proxy, nosotros sólo tendremos que introducir en Wireshark la clave adecuada. Esto se puede hacer desde “Edit > Preferences > Protocols > SSL > RSA keys list > Edit“, podemos indicar dónde están las claves RSA utilizadas durante la negociación (por lo tanto, para esta variante, Wireshark permite el descifrado cuando SSL intercambia claves usando RSA).

Wireshark fichero claves RSA

En este caso, salvo que instalemos en los navegadores la CA que hemos utilizado para firmar los certificados, se generarán alertas en los navegadores (por no confiar en la CA o gracias a técnicas como el certificate pinning). En cualquier caso, como lo que queremos es descifrar nuestro propio tráfico, no hay problema con esto: simplemente ignoramos las advertencias del navegador, y continuamos.

La ventaja de esta opción es que permite ampliar el análisis a múltiples máquinas (todas las que pasen por el proxy), lo cual puede ser útil en incidentes en los que no se sabe qué máquinas pueden estar afectadas, aunque el setup puede ser algo más complicado.

Ejemplos

La siguiente captura muestra una conexión a https://www.inteco.es (la dirección IP 195.53.165.3) interceptada con Squid, desplegado como proxy local en la misma máquina que el cliente. Como se puede observar, Wireshark descifra automáticamente el tráfico SSL entre cliente y proxy. También se ve cómo se hacen dos negociaciones SSL: los mensajes 290, 340 y 347 corresponden a la negociación entre el servidor de INTECO y el proxy, mientras que los mensajes 322, 324, 326 y 328 pertenecen a la negociación entre cliente y proxy.

  Captura tráfico SSL MITM

La intercepción se observa también por el hecho de que el certificado mostrado por el navegador (izquierda) no es el original (derecha):

Fuente:http://www.inteco.es/