UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMTICA

GRADO EN INGENIERA INFORMTICA

TRABAJO FIN DE GRADO

Herramienta de pentest orientado y automtico

Daniel Garca Artalejo

Julio, 2014

H ERRAMIENTA DE PENTEST ORIENTADO Y AUTOMTICO

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMTICA
Tecnologas y Sistemas de Informacin
TECNOLOGA ESPECFICA DE
INGENIERA DE COMPUTADORES

TRABAJO FIN DE GRADO

Herramienta de pentest orientado y automtico

Autor: Daniel Garca Artalejo

Director: Francisco Moya Fernndez

Julio, 2014

Daniel Garca Artalejo

Toledo Espaa
E-mail: Daniel.GarciaArtalejo@gmail.com
Telfono: 676 96 72 73
c 2014 Daniel Garca Artalejo

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.3 or any later version published by the Free Software
Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy
of the license is included in the section entitled "GNU Free Documentation License".
Se permite la copia, distribucin y/o modificacin de este documento bajo los trminos de la
Licencia de Documentacin Libre GNU, versin 1.3 o cualquier versin posterior publicada por
la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida en
el apndice titulado GNU Free Documentation License.
Muchos de los nombres usados por las compaas para diferenciar sus productos y servicios son
reclamados como marcas registradas. All donde estos nombres aparezcan en este documento, y
cuando el autor haya sido informado de esas marcas registradas, los nombres estarn escritos en
maysculas o como nombres propios.

TRIBUNAL:

Presidente:
Vocal:
Secretario:

FECHA DE DEFENSA:

CALIFICACIN:

PRESIDENTE

Fdo.:

VOCAL

SECRETARIO

Fdo.:

Fdo.:

ii

Resumen
La seguridad informtica es todava un tema pendiente para muchas empresas en Espaa.
Muchas de ellas an no estudian cul es su estado, y ni mucho menos realizan comprobaciones de seguridad mediante auditoras. Este software est destinado para que las empresas
de auditora reflejen al cliente los problemas de seguridad que se encuentran en su sistema,
como paso previo a una auditora real, para que haga patente sus deficiencias ante la duda
del cliente de si es beneficioso este tipo de examen para su empresa que, mediante un entorno automatizado, quite la desconfianza (por desconocimiento) del cliente en auditoras de
seguridad.
La idea nace de la cuestin del desconocimiento y, desafortunadamente, la nica manera
de conocer esos problemas es realizando una auditora en si, por lo que nos encontramos
ante un crculo vicioso. Por lo tanto, la cuestin que quiere cubrir este trabajo fin de grado es
realizar el primer anlisis del sistema, siendo automtico, llamativo y que pueda realizar el
responsable de la empresa en cuestin, ya que su fin es puramente contractual con la empresa
de auditora, para que ste sirva de prueba de concepto.
Esta herramienta debe mostrar de la forma ms visual posible si existen algunos problemas frecuentes de seguridad, y para ello se usar internamente un abanico de herramientas
de auditora ya existente, con mtodos de ataque bien conocidos, teniendo como base las
aplicaciones disponibles en la distribucin Kali Linux, como por ejemplo Metasploit.
Para la gestin de la aplicacin se crear un servidor web, para facilitar la gestin desde
cualquier dispositivo y se realizar utilizando la pila javascript denominada MEAN formada
por MongoDB, Express, AngularJS y Node.JS. Como metodologa se ha utilizado Scrum,
una metodologa agile ya que creemos que se acopla perfectamente a la situacin de desarrollo: es un proyecto con requisitos de tiempo muy altos (muy limitados), el equipo de
desarrollo es muy pequeo, el desconocimiento en la tecnologa empleada y, especialmente,
la intencin de poner en el mercado la aplicacin en el menor tiempo posible.

III

Abstract
Computer security is still an unresolved issue for many companies in Spain. Many of
them are not studying what is the condition of this yet, of course this is far for making tests
of security by audits. The destination of this software is that the audit companies would be
able to show to the clients the security problems in their systems as a previous step to a real
audit, to make obvious their faults. In case of doubt of the client about the benefits of this
test for his company, in an automatic environment, the software will be able to remove the
client distrust usually generate by ignorance in security audits.
The idea comes, in effect, from the question of ignorance and, unfortunately , the only way
to know these problems is making an audit itself, so we are in a vicious circle. Therefore,
this final project wants to cover the question of making a first test of the system, being
automatic, appealing and can be maked by the person responsable of the company himself.
Its destination is purely contractual with the audit company in orfer to be a concept test. If
there are any frequent security problems this tool should be as visual as posible. For this it
is going to be used a range of existing audit tools , with well known attack methods, taking
as a starting point the avaliable applications in Kali Linux SO, for example Metasploit. A
web server will be created for the application management, to make easy the use from any
dispositive and it will be possible using the Javascript stack known as MEAN formed by
MongoDB, Express, AngularJS, and Node.JS. The method we use is Scrum, a agile method,
considering that we think this connects perfectly to the development situation: a small project
with really big time requirements very restricted, a really small development team, the
ignorance of the technology we are employing and, specially, the intention of commercialise
the application as soon as possible.

IV

Agradecimientos
No hubiera podido finalizar este TFG sin la influencia de un gran nmero de personas que,
directamente o indirectamente, han colaborado de forma tcnica o me han dado su apoyo
en su realizacin y es por ello por lo que les agradezco de todo corazn su inters en este
proyecto.
En primer lugar, querra agradecer este proyecto al profesor Francisco Moya, director del
TFG, por su inters, colaboracin y disponibilidad. Realmente, espero algn da volver a
trabajar con l, porque no hay nada ms estimulante que trabajar con alguien que disfruta
con su trabajo.
Me gustara mencionar tambin a mis compaeros Csar Aguirre y Fernando Martn, por
todos los momentos que hemos pasado juntos en clase. Espero que algn da coincidamos
de nuevo en un futuro.
Tambin querra agradecer a mi familia y seres queridos, en especial a mis padres, que han
hecho todo lo posible para que estudie en la universidad. Pero en especial a mis hermanos
(Vctor e Ismael) por ponerme como reto concentrarme en este proyecto.
Y tambin a Eva, ya que sin su ayuda no hubiera podido alcanzar ninguna meta.
Daniel

ndice general

Resumen

III

Abstract

IV

Agradecimientos

ndice general

VI

ndice de cuadros

IX

ndice de figuras

ndice de listados

XII

Listado de acrnimos

XIII

1. Introduccin

1.1. Estructura del Trabajo Fin de Grado (TFG) . . . . . . . . . . . . . . . . . .

2. Objetivos e hiptesis de trabajo

4
6

2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2. Objetivos especficos y secundarios . . . . . . . . . . . . . . . . . . . . .

3. Antecedentes

3.1. Tcnicas para evaluar la seguridad . . . . . . . . . . . . . . . . . . . . . .

3.1.1. Tcnicas de examen . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.2. Tcnicas de anlisis e identificacin de objetivos . . . . . . . . . .

3.1.3. Criterios en la evaluacin de la seguridad . . . . . . . . . . . . . .

10

3.1.4. Modos de la realizacin de las pruebas . . . . . . . . . . . . . . . .

14

3.1.5. Metodologias para las evaluaciones de seguridad . . . . . . . . . .

16

3.2. Tcnicas de validacin . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.2.1. Test de penetracin . . . . . . . . . . . . . . . . . . . . . . . . . .

17

VI

3.2.2. Fases de las pruebas de penetracin . . . . . . . . . . . . . . . . .

18

3.3. Software para el pentesting . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.3.1. Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.3.2. Metasploit API . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.3.3. Meterpreter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.4. Kali Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4. Mtodo

29

4.1. Metodologa Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.1.1. El manifiesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.2. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.2.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

4.2.2. Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.2.3. Motivos para elegir Scrum . . . . . . . . . . . . . . . . . . . . . .

34

4.3. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.3.1. Entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.3.2. Desarrollo de software . . . . . . . . . . . . . . . . . . . . . . . .

35

4.3.3. Desarrollo del trabajo escrito . . . . . . . . . . . . . . . . . . . . .

36

4.3.4. Desarrollo del programa . . . . . . . . . . . . . . . . . . . . . . .

37

5. Resultados

39

5.1. Requisitos en el Product Backlog . . . . . . . . . . . . . . . . . . . . . . .

39

5.1.1. Primera reunin . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.1.2. Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.2. Organizacin del desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.2.1. Dependencias en NodeJS . . . . . . . . . . . . . . . . . . . . . . .

41

5.2.2. Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . . . .

43

5.2.3. Diseo de clases . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.2.4. Diseo de la base de datos . . . . . . . . . . . . . . . . . . . . . .

46

5.2.5. Ejecucin de un anlisis . . . . . . . . . . . . . . . . . . . . . . .

46

5.2.6. Diseo de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . .

47

6. Conclusiones

54

6.1. Ejecucin de los objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .

54

6.2. Conclusin final y expectativas de futuro . . . . . . . . . . . . . . . . . . .

55

vii

A. Iteraciones Scrum

58

A.1. Iteracin 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

A.2. Iteracin 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

A.3. Iteracin 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

A.4. Iteracin 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

A.5. Iteracin 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

B. Ejecucin del software

66

C. Manual de usuario para el responsable

68

GNU Free Documentation License

75

1. APPLICABILITY AND DEFINITIONS . . . . . . . . . . . . . . . . . . . .

75

2. VERBATIM COPYING . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

3. COPYING IN QUANTITY . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

4. MODIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

5. COMBINING DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . .

80

6. COLLECTIONS OF DOCUMENTS . . . . . . . . . . . . . . . . . . . . . .

80

7. AGGREGATION WITH INDEPENDENT WORKS . . . . . . . . . . . . . .

81

8. TRANSLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

9. TERMINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

10. FUTURE REVISIONS OF THIS LICENSE . . . . . . . . . . . . . . . . . .

82

ADDENDUM: How to use this License for your documents . . . . . . . . . . .

82

Referencias

84

viii

ndice de cuadros

1.1. Personal dedicado en pymes en tantos por ciento . . . . . . . . . . . . . .

3.1. Conjunto de tcnicas de anlisis . . . . . . . . . . . . . . . . . . . . . . .

25

3.2. Conjunto de habilidades de referencia para Tcnicas para el anlisis . . . .

26

3.3. Tcnicas de anlisis e identificacin de objetivos . . . . . . . . . . . . . .

27

3.4. Tcnicas de anlisis e identificacin de objetivos . . . . . . . . . . . . . .

27

3.5. Resumen del conjunto de herramientas de BackTrack 5 . . . . . . . . . . .

28

4.1. Comparativa entre metodologas giles y tradicional . . . . . . . . . . . . .

32

IX

ndice de figuras

1.1. Motivos por los que las pymes no invierten en seguridad. Fuente: Panda Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2. Porcentaje de empresas que afirman que cuentan con personas dedicadas a
la seguridad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1. Fases para la realizacin de pruebas de penetracin. Fuente: del ingls: National Institute of Standards and Technology. Es el Instituto Nacional de Normas y Tecnologa de Estados Unidos (NIST) SP800-115. . . . . . . . . . .

18

3.2. Logo de Metasploit al ejecutar msfconsole. . . . . . . . . . . . . . . . . .

19

3.3. Arquitectura de Metasploit. Fuente: offensive-security.com . . . . . . . . .

21

3.4. Fases de ejecucin de meterpreter en un objetivo. Fuente [Sin12] . . . . . .

23

3.5. Logo de Kali Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.1. Jeff Sutherland y Ken Schwaber en el evento Scrum, alrededor del 2009 . .

31

4.2. Diagrama del ciclo iterativo scrum [Pal14] . . . . . . . . . . . . . . . . . .

34

5.1. Diagrama de casos de uso para el responsable de la empresa . . . . . . . .

41

5.2. Diagrama de casos de uso para el responsable de la empresa . . . . . . . .

44

5.3. Diagrama de clases. NOTA: Para la visualizacin en detalle del diseo de la

base de datos, se ha creado otro diagrama de entidad-relacin. . . . . . . .

49

5.4. Adaptacin al modelo entidad-relacin de la base de datos en MongoDB . .

50

5.5. Diagrama de secuencia para el responsable de la empresa . . . . . . . . . .

51

5.6. Comparacin entre el diseo para PC y Smartphone . . . . . . . . . . . . .

52

5.7. Diseo adaptado para tablet . . . . . . . . . . . . . . . . . . . . . . . . . .

53

C.1. Primera vista de la interfaz. . . . . . . . . . . . . . . . . . . . . . . . . . .

68

C.2. Listado de objetivos ya disponibles, ahora mismo ninguno (primer inicio). .

69

C.3. La aplicacin est buscando objetivos en la red. . . . . . . . . . . . . . . .

70

C.4. Lista de objetivos encontrados. . . . . . . . . . . . . . . . . . . . . . . . .

70

C.5. Lista de polticas agregadas por defecto. . . . . . . . . . . . . . . . . . . .

71

C.6. Formulario para agregar una poltica nueva. . . . . . . . . . . . . . . . . .

71

C.7. Pantallazo de la seccin de anlisis. . . . . . . . . . . . . . . . . . . . . .

72

C.8. Formulario para agregar poltica. . . . . . . . . . . . . . . . . . . . . . . .

72

C.9. Formulario para elegir objetivo. . . . . . . . . . . . . . . . . . . . . . . .

73

C.10. Anlisis con xito. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

C.11. Listado de secciones establecidas con un objetivo. . . . . . . . . . . . . . .

74

C.12. Captura de pantalla realizada sobre el objetivo. . . . . . . . . . . . . . . .

74

xi

ndice de listados
5.1. Ejemplo de servidor con Express. . . . . . . . . . . . . . . . . . . . . . .

42

5.2. Al llamar a la funcin Save, se ejecuta el cdigo listado, que evala la informacin antes de ser almacenada en la Base de datos (BD). . . . . . . . . . .

42

5.3. Configuracin de inicio de la herramienta. . . . . . . . . . . . . . . . . . .

48

B.1. Instalando dependencias de software. . . . . . . . . . . . . . . . . . . . . .

66

B.2. Instalando dependencias dentro de NodeJS. . . . . . . . . . . . . . . . . .

66

B.3. Comandos para la ejecucin de Metasploit. . . . . . . . . . . . . . . . . .

67

B.4. Opciones de ejecucin del programa. . . . . . . . . . . . . . . . . . . . . .

67

XII

Listado de acrnimos
API Application Programming Interface
ASLR Address Space Layout Randomization
ATA Serial Advanced Technology Attachment
BD Base de datos
CRUD Create, Read, Update y Delete
CSS Cascading Style Sheets
GNU GNU is Not Unix
IDS Sistemas de detenccin de Intrusin
DEP Sistemas de prevencin de ejecucin de datos
DNS Domain Name server
DSDM Dynamic Systems Development Method
GUI Graphical user interface
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
IDE Integrated Development Environment
IP Internet Protocol
IPS Intrusion Prevention System
JSON JavaScript Object Notation
LAN Local Area Network
MVC Modelo Vista Controlador
NIST del ingls: National Institute of Standards and Technology. Es el Instituto Nacional de Normas

y Tecnologa de Estados Unidos

OSSTMM del ingls: Open Source Security Testing Methodology Manual. En espaol: Manual de la

Metodologa Abierta de Testeo de Seguridad

PDF Portable Document Format
SO Sistema Operativo
SSL Secure Sockets Layer
TCP Transmission Control Protocol
TFG Trabajo Fin de Grado
TI Tecnologas de la Informacin
TLS Transport Layer Security
TLV Type-length-value

XIII

UML Unified Modeling Language

VPN Virtual Private Network
WAN Wide Area Network
WEP Wired Equivalent Privacy
WPA Wi- Fi Protected Access
XP eXtreme Programming
XML eXtensible Markup Language

xiv

Captulo 1

Introduccin

la aparicin de Creeper, el primer virus para computadores que infect por primera vez un equipo informtico [CRE11], los programas maliciosos han ido aumentando de una manera increble, casi paralelamente junto al crecimiento de la potencia de
cmputo. Y es que la inofensividad del primer virus, que mostraba tan solo el mensaje Im
the creeper, catch me if you can! (en espaol: soy la Enredadera, cgeme si puedes) ha
quedado muy atrs. No obstante, los dispositivos informticos se han abierto paso en todos
los mbitos ya que si la tecnologa es beneficiosa para las personas de a pie, lo es an ms
para las empresas, que vuelcan su gestin o incluso directamente su funcionamiento en los
dispositivos informticos. Es tal la presencia de los computadores en las empresas que segn AETIC [VVA11] la utilizacin en Espaa alcanza el 96,2 % (en el ao 2011) con un
incremento de casi el 6 % respecto a los tres anteriores aos.
ESDE

Pero an muchas empresas no ven importante la incorporacin de equipos informticos en

sus sistemas. Como vemos en los porcentajes mencionados anteriormente, aunque es muy alto (roza el 100 %) an no todas las empresas de Espaa confan en la informtica. Esto es as
porque dichas empresas no son conscientes de las mejoras que ofrece la computacin a sus
negocios ya que, quiz, ven muy complicado los sistemas que conocen o, ms posiblemente,
no creen que la mejora les ahorre tiempo.
De igual manera que existen empresas que an no se han actualizado al siglo XXI, muchas
de las pymes no dedican recursos a la seguridad de su empresa. El problema que se plantea es
similar: no se quiere dedicar personal para ello, no se es consciente de las consecuencias de
los problemas de seguridad y, especialmente, se debe gastar tiempo en ello, al igual que las
empresas que se resisten en incorporar equipos informticos en su sociedad. De hecho, segn
Panda Security [Secb], existen tres principales motivos para que no dediquen sus recursos
en seguridad informtica: porque es caro (33 %), porque no se considera importante (8 %) y
porque el sistema de seguridad consume muchos recursos virtuales (8 %) (ver figura 1.1).
Las limitaciones en seguridad de las pymes
El grado de importancia de la seguridad en las pymes tambin se encuentra reflejado en
un estudio realizado por Inteco [PSJ09] sobre el estado de la seguridad de la informacin

Figura 1.1: Motivos por los que las pymes no invierten en seguridad. Fuente: Panda Security.

en las pymes espaolas. De l se desprende que aunque un 96,1 % utiliza un antivirus o

antiespa y un 75 % cortafuegos, tan solo un 34 % utiliza un cifrado de datos de media,
aunque este dato se eleva hasta el 45 % en las pequeas empresas y hasta el 54 % en las
medianas empresas. No obstante, es un nmero an muy bajo. Un 35 % lo justifica indicando
que no lo necesita y otro 35 % indica que desconoce de qu se trata. Es el caso de una
decisin con impacto grave en la seguridad, fcilmente explotable mediante una auditora
para la obtencin de datos, y que es originado por desconocimiento de la situacin. Esto se
agrava an ms al comprobar las medidas de seguridad en las redes Wifi, encontrndose solo
un 27,4 % protegidas con un protocolo Wi- Fi Protected Access (WPA)/WPA2, un 27,4 %
con Wired Equivalent Privacy (WEP) (explotable muy fcilmente) y un 12,4 % sin ninguna
proteccin.
Personal dedicado a la seguridad de la informacin
El tamao de la empresa est relacionado con la dedicacin interna a la seguridad. Segn
el estudio de Inteco [PSJ09], es ms probable encontrar personal especializado en seguridad
en una mediana empresa que en una pequea, pero los datos son an ms bajos que en la
media europea (66 %, figura 1.2). Como puede verse en el cuadro 1.1, las microempresas
directamente descartan dedicar personal a la seguridad en su organizacin. En las pequeas empresas el nmero desciende hasta el 16 %, pero en lo referente al personal externo
contratado, el porcentaje disminuye segn aumenta el tamao de la organizacin.
Puntos dbiles de las pymes en seguridad
Como conclusin en su anlisis de la seguridad en las empresas espaolas, Inteco realiza
una reflexin bastante llamativa sobre la situacin actual despus de haber mostrado qu

Figura 1.2: Porcentaje de empresas que afirman que cuentan con personas dedicadas a la
seguridad.

Personal de seguridad

Microempresa

Pequea empresa

Mediana empresa

S, con personal exclusivamente dedicado a la seguridad

S, con personal interno de informtica
S, mediante una empresa externa
No, no est considerado
No sabe/no contesta

3,9

5,5

12,4

15,9
34,9
44,8
0,5

32,7
44,3
15,8
1,7

50,4
29,4
7,2
0,5

Cuadro 1.1: Personal dedicado en pymes en la seguridad informtica en tantos por ciento
carencias hay en las pymes. Por un lado, existe una falsa sensacin de seguridad, ya que
se da la falsa creencia de que los ataques de seguridad tienen como objetivo las grandes
compaas o entidades y que un incidente grave es remoto y, por ese motivo, no necesitan
disponer de ningn procedimiento que permita recuperarse despus del ataque.
Tampoco existe un conocimiento o formacin suficiente en gestin de seguridad en ciertas
reas de la empresa, que se encuentra enfocado excesivamente en la dimensin tecnolgica.
Con ello, se refiere a que la preparacin nicamente se realiza desde el punto de vista del
componente tecnolgico, pero existe una carencia en buenas prcticas y estrategias en la
gestin de imprevistos. La ISO 270011 estudia esta visin global de los sistemas, donde
permite a las organizaciones proporcionar ciertas garantas sobre los servicios ofrecidos.
1

Pgina oficial de la ISO: http://www.iso.org/iso/home/standards/management-standards/iso27001.

htm

Objetivo: un estudio automatizado

Este TFG nace para cubrir la situacin de este tipo de empresas, como un medio previo
a una auditora minuciosa por parte de profesionales en seguridad, para as demostrar, mediante una prueba de concepto, las posibles consecuencias de sus problemas de seguridad e
intentar disminuir el nmero de pymes que no realizan (por desconocimiento o no), dichas
pruebas.
As pues, el TFG est orientado para que el responsable de la empresa pueda ejecutar el
proceso, participe lo menos posible y pueda hacer pruebas de explotacin de una forma automtica, para as comprobar que realmente existe un problema en su empresa en el apartado de
seguridad y las consecuencias que ocasionara tanto a su imagen como legales (recordemos
la Ley de Proteccin de datos, si los datos de los clientes son expuestos). Es, por tanto, un
sistema de caja negra donde se visualiza tan solo la salida de la ejecucin de ciertas rdenes
preconfiguradas sobre objetivos, intentando evidenciar que el sistema requiere un mantenimiento mediante un examen real por parte de una empresa de auditora en seguridad.
No se trata por tanto de implementar una herramienta que sustituya a un pentester (especialista en pruebas de penetracin) profesional, sino ms bien una herramienta de ayuda a
las actividades de preventa de una empresa enfocada en auditoras de seguridad para pymes.
Los comerciales no tienen por qu tener alta cualificacin en auditoras de seguridad, pero
se beneficiaran significativamente si el cliente potencial fuera consciente de su exposicin a
riesgos debidos a problemas de seguridad. Un entorno automatizado que analice los problemas ms comunes en las pymes y los presente de forma sencilla y entendible puede servir
como argumento de venta para realizar un anlisis en profundidad. La secuencia operativa
sera la siguiente:
El equipo de pentesters de la empresa de auditora preparara el conjunto de ataques
ms habituales segn su experiencia previa, configurando la herramienta de forma que
se analicen las vulnerabilidades de forma totalmente automtica. Para ello no es necesario el desplazamiento del equipo.
El equipo de preventa de la empresa realizara visitas a clientes potenciales concertando citas con los responsables de informtica (CIO o COO) a los que se les propone
realizar el anlisis automtico.
Con la debida autorizacin del responsable se ejecuta el anlisis y se genera un informe
detallado de las vulnerabilidades encontradas, que se le presenta al cliente potencial
para justificar la necesidad de auditoras peridicas.

1.1 Estructura del TFG

A continuacin se mostrar cmo se ha organizado la memoria para abordar todos los
requisitos y conocimientos adquiridos para el desarrollo del proyecto. Se mostrar de forma

resumida qu se explica en cada captulo para as situar al lector en la organizacin del

documento.
Captulo 2: Objetivos e hiptesis de trabajo
En este captulo se enumerarn los objetivos principales y secundarios del TFG, es
decir, cules sern los requisitos mnimos que deber cumplir el software. Se analizar
en detalle el resultado esperado basndonos en la situacin empresarial explicada en
la introduccin.
Captulo 3: Antecedentes
Se desarrollar la situacin actual y los conceptos que rodean a las auditoras de seguridad basados en el conocimiento adquirido desde la bibliografa, normativas y estndares.
Como columna vertebral se hablar del estandar SP800-115 publicado por el NIST,
utilizado para la realizacin de evaluaciones de seguridad en empresas, que ser la base
para la organizacin del programa a realizar en el TFG, ya que organiza el proceso. Por
otro lado, se analiza la arquitectura de Metasploit, el software base que se utilizar en
el TFG.
Captulo 4: Mtodo
En este captulo se realiza un estudio de la metodologa agile empleada: un poco de
historia, en qu consiste y cmo se organiza. La metodologa agile Scrum nace para
cubrir la necesidad de una metodologa ligera en documentacin para proyectos de
equipos medianos o pequeos y proyectos no complejos, y es por ese motivo por el
que se ha elegido para el desarrollo de este TFG. Tambin se abarca y se explica el lenguaje de programacin base utilizado, NodeJS, junto con la pila javascript denominada
MEAN (MongoDB, Express, AngularJS y NodeJS); as como el uso de diferentes herramientas que se ha utilizado que han ayudado a completar el proyecto fin de grado,
como por ejemplo el entorno de desarrollo eclipse junto con el plugin nodeclipse o
el software para gestin de base de datos MongoDB, robomongo, que ha facilitado la
manipulacin de las mismas.
Captulo 5: Resultados
Al seguir la metodologa agile de Scrum, el desarrollo se ha partido en Iteraciones. En
este captulo se mostrar un resumen de las iteraciones, detalles sobre las dependencias
de software, la especificacin de requisitos y la planificacin realizada ayudndonos
de diagramas UML que han facilitado la comprensin y la organizacin del proyecto.
Captulo 6: Conclusiones
El ltimo apartado de la memoria donde se incluye un breve resumen de los objetivos
cumplidos en el proyecto y las destrezas acumuladas a lo largo de su realizacin.

Captulo 2

Objetivos e hiptesis de trabajo

L desarrollo de esta aplicacin con xito requiere una especificacin de objetivos inicial

slido para formar una base firme de la que filtrar los requisitos de la aplicacin. Por lo
tanto, se ha distinguido entre un objetivo general y varios especficos que se debe cumplir.

2.1 Objetivo general

El objetivo general es la realizacin de una aplicacin que de forma automtica realice
pruebas de penetracin en los objetivos de la organizacin que previamente una empresa
de auditora informtica ha configurado para ejecutar automticamente simples pruebas de
seguridad.

2.2 Objetivos especficos y secundarios

Por otro lado, existen una serie de objetivos que deben alcanzarse, pero se encuentran
en un segundo lugar. Son aquellas especificaciones dedicadas a la interfaz o requisitos de
desarrollo.
Ejecutable en dispositivos mviles. Por la naturaleza intuitiva y adaptable a cualquier
dispositivo, se especifica como objetivo que sea ejecutable en dispositivos mviles (o
accesible) y programado en un lenguaje de programacin de alto nivel que permita el
acceso o ejecucin del mismo en cualquier sistema operativo.
Interfaz simple, intuitiva y llamativa. La interfaz de la aplicacin debe ser muy
simple y especialmente atractiva, para que se ejecute el proceso de la forma ms rpida
y sencilla posible.
No exceder con informacin tcnica. Para que pueda ser ejecutado el proyecto por
personas no profesionales en la seguridad informtica no debe estar cargado de informacin tcnica.
Multiplataforma. Independientemente del Sistema Operativo (SO) que se utilice en
la versin final, se fija como objetivo que se puedan visualizar los resultados desde
cualquier plataforma.
Personalizable. Con ello nos referimos a la capacidad de modificar el entorno grfico
6

para que sea posible manipular los colores, imgenes, etctera.

Facilidad de ampliacin las funcionalidades. Debe tener la capacidad de ampliar sus
caractersticas como por ejemplo en la ejecucin de exploits para diferentes objetivos
(wireless por ejemplo) o acciones post-explotacin.
Ejecucin de exploits de diversa ndole. Debe estar preparado para la ejecucin de
exploits sobre diferentes objetivos.
Agrupacin de exploits en categoras. Para una mejor clasificacin hacia los objetivos, los exploits deben clasificarse en categoras con acciones comunes y personalizables.
Reconocimiento de objetivos. Para la ejecucin de algunos exploits es necesario el
reconocimiento de objetivos dentro de la organizacin.
Seleccin de objetivos. El proceso debe ejecutarse dentro de esa red aportando al
usuario informacin detallada sobre el objetivo (algn tipo de identificacin, por ejemplo nombre del equipo).
Analizar la informacin. Documento que resuma el proceso de explotacin realizado.

Captulo 3

Antecedentes

pruebas de penetracin, del ingls Penetration Testing, pueden ser definidas como
un anlisis legal y autorizado que examina las vulnerabilidades, pero que tambin las
explota, proporcionando una prueba de concepto de un ataque real y as demostrar las posibilidades reales que podra tener una persona externa (o interna) con la intencin de comprometer el sistema. Este tipo de pruebas se han convertido en el ncleo principal del escenario
actual para abarcar los aspectos fundamentales de la seguridad, realizando un anlisis en una
situacin de la vida real [Sin12].
AS

La importancia de la ejecucin de pruebas de penetracin radica en que ayuda la visin

de amenazas y debilidades desde la perspectiva de un atacante real, explotando las fisuras
que se puedan encontrar en el sistema. En las pruebas de caja blanca, existe una completa
informacin sobre el objetivo y el tester deber identificar cualquier debilidad conocida o
desconocida que pueda existir. Sin embargo, una prueba basada en caja negra se realiza
cuando no existe ese conocimiento.
A lo largo de este captulo, abarcaremos en qu consiste las evaluaciones de seguridad,
cules son los pasos que se realizan en las auditoras de seguridad, las metodologas de evaluacin, etctera, a travs de los estndares establecidos en el campo. Tambin estudiaremos
la estructura de Metasploit, sus funcionalidades y componentes, as como un anlisis de las
herramientas que podemos encontrar en el sistema operativo Kali Linux, una herramienta
fundamental en las auditoras de seguridad.
El propsito de una evaluacin de seguridad es determinar la efectividad con la que se
evala una entidad, ya sea un host, un sistema, una red, procedimiento, etc., que cumple
los objetivos de seguridad esperados. Los mtodos para la evaluacin se pueden agrupar en
tres categoras: testing, examen y entrevistas. Este ltimo mtodo se define como un proceso
de estudio mediante reuniones con el personal o grupos dentro de la organizacin, para as
facilitar el entendimiento, dar razonamientos sobre una poltica de trabajo o para identificar
la ubicacin de un problema. Por otro lado, en examen nos centramos en la inspeccin,
observacin, estudio o anlisis de uno o ms objetivos de evaluacin con la finalidad de
lograr un incremento del detalle de los resultados y, para terminar, en testing nos centramos
en realizar la evaluacin en si de los objetivos mediante varias tareas seleccionadas para

as comparar el comportamiento real del esperado. Durante este paso se realiza el primer
avance en la evaluacin, ya que en las dos fases anteriores no se lleva a cabo una ejecucin
de pruebas, sino un anlisis del comportamiento del equipo y dispositivos de la empresa.
Por lo tanto, de las tres categoras mencionadas, nos centraremos en el proceso de testing,
ya que es aquel para el que el presente trabajo est centrado. Para llevar a cabo esta fase de
la evaluacin de la seguridad debe realizarse una serie de tcnicas de anlisis que facilitan el
xito de la evaluacin. Dichas tcnicas estn clasificadas dependiendo de su objetivo, como
veremos ms adelante basndonos en la publicacin SP800-115 [SSCO08].

3.1 Tcnicas para evaluar la seguridad

Cualquier sistema o red puede ser examinada o testada de diversas formas. No obstante,
las tcnicas empleadas se vern condicionadas a la situacin en la que se ejecutan, ya que
pueden depender de si nos encontramos en un permetro externo o interno en la organizacin.
Por ejemplo, en una situacin externa podramos analizar las Domain Name server (DNS),
puertos abiertos, servicios en ejecucin, etc. mientras que en un anlisis interno la situacin
difiere, ya que estaramos dentro de la barrera de seguridad que rodea a la red. En esta seccin
nos centraremos en aquellas ms populares, sin profundizar demasiado, agrupndolas en las
siguientes categoras: Tcnicas de examen, tcnicas de anlisis e identificacin de objetivos
y tcnicas de validacin de vulnerabilidad en un objetivo.

3.1.1

Tcnicas de examen

Es el modo de analizar sistemas, aplicaciones, redes, procedimientos, etc. de forma pasiva,

por lo que conlleva un riesgo bajo. Mediante esta tcnica se acumula informacin que luego
puede ser utilizada para otras evaluaciones que podran facilitar y optimizar.
Como punto de partida, en el cuadro 3.1 vemos un conjunto de aspectos que se incluyen en
el anlisis de la documentacin (planes de seguridad del sistema, acuerdos de autorizaciones,
planes de respuesta ante incidentes, etc.), un estudio del log (identificaciones en el servidor,
logs de firewalls y routers, as como cualquier LOG de antivirus, Sistemas de detenccin
de Intrusin (IDS) o Intrusion Prevention System (IPS)), estudio de sistemas basados en
conjuntos de reglas (como routers o firewalls) o anlisis de la configuracin del sistema.
A continuacin en el cuadro 3.2 vemos que cada tcnica implica ciertas destrezas que el
evaluador debe cubrir para que todo sea ejecutado de forma segura y precisa. Cada evaluador
debe seguir una serie de referencias que sus competencias deben alcanzar.

3.1.2

Tcnicas de anlisis e identificacin de objetivos

Este tipo de tcnicas son tambin muy importantes a la hora de la evaluacin de seguridad
en una organizacin, ya que en esta fase se va a iniciar la etapa principal: la identificacin de
objetivos y las tcnicas para sus anlisis. Veremos qu dispositivos estn activos junto con

sus respectivos puertos y servicios que permiten, por ejemplo, crear mapas de la topologa
de red, configuracin de IDS o firewalls, etctera. Las tareas que se deben llevar a cabo en la
identificacin de objetivos son varias y es el evaluador el que debe elegir cul es la ms adecuada para ser sigiloso o para aumentar su porcentaje de xito en obtencin de informacin.
Como ejemplo, en el anlisis de la red tenemos a nuestra disposicin varias herramientas
que nos permiten analizar paquetes sospechosos (como SYN/FIN). Por otra parte, tambin
es aconsejable un escaneo de vulnerabilidades o escaneo de redes wireless. En el cuadro 3.3
vemos un resumen de las tcnicas a emplear y sus objetivos.
Por ltimo, en el cuadro 3.4 se resume qu conjunto de competencias debera adquirir cada
evaluador para conseguir llevar a cabo esta tarea.

3.1.3

Criterios en la evaluacin de la seguridad

Seguir unos criterios en la evaluacin de seguridad que den capacidad de reutilizacin y

documentacin es muy beneficioso, ya que permite proporcionar consistencia y estructura a
los tests de seguridad (minimizando los riesgos de la prueba), acelera un hipottico cambio
del equipo de evaluacin y tambin aborda las limitaciones de recursos relacionados con las
pruebas.
Entre las limitaciones referidas, nos encontramos requisitos de tiempo, equipo, hardware
y software, la disponibilidad de realizar evaluaciones de seguridad se limita en el tipo y en
la frecuencia. Es precisamente por este motivo por lo que el anlisis de los tipos de pruebas
de seguridad y exmenes que la organizacin ejecutar, el desarrollo de una metodologa
adecuada y la identificacin de los recursos necesarios, son puntos clave para mitificar el
problema de los recursos. Siguiendo estos pasos, junto con la utilizacin de vas consolidadas
como el personal capacitado y las plataformas de testing normalizadas, disminuye el tiempo
requerido para realizar una evaluacin y la necesidad de adquirir nuevos equipos de prueba
y de software, haciendo que el coste de la evaluacin global baje.
La metodologa de evaluacin de la informacin por etapas debe perseguir una estructura
fcil de seguir que proporcione puntos naturales de ruptura, es por ello por lo que ofrece una
gran serie de ventajas. Las mnimas fases que debe poseer la metodologa son:
1. Planificacin: Es un paso crucial para que la evaluacin de seguridad tenga xito. En
esta fase se recopila la informacin necesaria para la evaluacin de la ejecucin, los
objetivos a ser evaluados, las amenazas de inters sobre los objetivos, y los controles
de seguridad que se usan para mitigar esas amenazas. Una evaluacin de seguridad
debe ser tratada como cualquier otro proyecto: con un plan de gestin que haga frente
a los objetivos y metas, entorno, requisitos, papel de los equipos y responsabilidades,
limitaciones, factores de xito, suposiciones, recursos, linea de tiempo y producto final.
Ampliado en la seccin 3.1.3.
2. Ejecucin: Los primeros objetivos en la fase de ejecucin son la identificacin de vul10

nerabilidades y validarlos cuando es conveniente. En esta fase se debera abordar las

actividades asociadas con las intenciones del mtodo de evaluacin y tcnica. Aunque las actividades especficas para esta fase difirieren por su tipo de evaluacin, una
vez completada la fase, los evaluadores tendrn identificadas las vulnerabilidades del
sistema, de la red y de los procesos de la organizacin.
3. post-ejecucin: En esta ltima fase nos centramos en analizar las vulnerabilidades
identificadas para determinar las causas de raz, establecer unas recomendaciones de
mitigacin y desarrollar un informe final.
Actualmente existen varias metodologas aceptadas para el desarrollo de evaluaciones de
seguridad de la informacin. Por ejemplo el NIST ha creado una metodologa documentada
en una SP 800-53A(Special Publication, publicacin especial en espaol), titulada Guide
for Assessing the Security Controls in Federal Information Systems, traducido como Gua
para la evaluacin de los controles de seguridad en los sistemas de informacin federales,
que ofrece sugerencias para una evaluacin eficaz de los controles de seguridad resumidos en
la publicacin NIST SP 800-53 1 . Otra metodologa ampliamente utilizada es la OSSTMM 2 .
Ms adelante se analizar ambas metodologas.
Planificacin de la evaluacin
Como en todo proyecto, la planificacin es la clave para el xito y no es diferente en
la evaluacin de la seguridad, aunque es una actividad compleja enumerar los requisitos,
nmero y tipos de sistemas de la organizacin, etctera.
La base de una correcta planificacin es la priorizacin y la planificacin de las evaluaciones, la creacin de polticas, escoger y personalizar los procedimientos (adaptndose a la
situacin de la empresa), seleccin de recursos y herramientas, consideraciones legales y por
supuesto, todo depende de las habilidades y destrezas del evaluador.
1. Desarrollo de una poltica. Las organizaciones deberan desarrollar una poltica de
evaluacin para proporcionar una direccin y orientacin a sus evaluadores. La poltica
debe identificar los requisitos y fijar responsables para que esas personas aseguren
que las evaluaciones son llevadas a cabo segn se fij en los requisitos, adems de la
periodicidad de la misma. Por otro lado, si existe algn cambio en la organizacin que
modifique los requisitos establecidos, debe ser revisada la poltica, aunque tambin es
recomendable ser revisada al menos anualmente.
2. Priorizacin y planificacin de la evaluacin. La ejecucin de tareas de forma prioritaria, puede ser necesaria si impera una limitacin de tiempo, dependencia de resultados, gestin del sistema, disponibilidad de recursos o directamente la normativa
1

Se puede consultar en http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

visitado el 8 de junio de 2014
2
Pgina oficial http://www.isecom.org/research/osstmm.html visitado el 8 de junio de 2014

11

aplicable. Por otro lado, la frecuencia de las evaluaciones tambin son parte de una
correcta organizacin de las evaluaciones ya que puede generar un decaimiento no llevarse a cabo de forma peridica si se produce una actualizacin o correccin antes de
la realizacin de la prueba.
3. Seleccionando y personalizando las tcnicas de examen: Existen muchos factores
que determinan qu tcnicas deberan ser usadas para una evaluacin en particular.
Dichos factores pueden ser directamente los objetivos, las clases de procedimiento de
los cuales se pueden obtener informacin en los que se apoyan otros procedimientos
y las tcnicas apropiadas dentro para cada clase de objetivo. Algunas tcnicas tambin requieren que la organizacin determine la opinin personal de los asesores (por
ejemplo, un anlisis interno versus externo).
4. Determinar la logstica de la evaluacin. Con ello nos referimos a identificar todos
los recursos, incluyendo al equipo de evaluacin y a escoger el entorno y localizaciones
donde se requiere realizar el anlisis.
5. Plan de desarrollo de la evaluacin Es necesario desarrollar una documentacin de
las actividades previstas a ejecutar en el anlisis y tambin de cualquier tipo de informacin relacionada, especificando qu reglas y lmites que los evaluadores deben
cumplir. El plan debe identificar los sistemas y redes a ser examinados, el tipo y el
nivel de las pruebas permitidas, los detalles logsticos de la evaluacin, requisitos de
manipulacin de datos y una orientacin para el manejo de incidentes.
6. Consideraciones legales. Antes de la ejecucin de anlisis, las organizaciones deben
examinar las consecuencias legales que se pudiera ocasionar, especialmente si existe
algn procedimiento que sea especialmente intrusivo (por ejemplo, en test de penetracin) o bien si la evaluacin es llevada a cabo por una entidad externa. El departamento
legal debera analizar el plan de anlisis, abarcando especialmente en lo que concierne
a la privacidad.
Ejecucin del anlisis
Al ejecutar una evaluacin de seguridad, algunas vulnerabilidades son identificadas por los
procedimientos elegidos en la fase de planificacin. Por lo tanto, durante el anlisis se debe
seguir una coordinacin, un plan de gestin de incidentes, a la vez de estudiar cmo gestionar
la recogida de datos, almacenamiento, transmisin y destruccin de ficheros relacionados con
la evaluacin.
1. Coordinacin. Como se ha mencionado anteriormente, es necesario una coordinacin
entre las entidades de la organizacin, que debe ser fijado en el ROE (plan de evaluacin). Un ejemplo de organizacin puede ser no realizar una evaluacin en el momento
que se realiza una actualizacin, ya sea de cambiar de Hardware o Software, puesto
que la evaluacin puede ser alterada.
12

2. Evaluacin. A la hora de realizar una evaluacin, nos podemos encontrar con varios
retos o incidentes que tenemos que hacer frente.
Uno de ellos es la resistencia por parte de los usuarios o administradores de redes o
sistemas ante la evaluacin, otra puede ser la falta de realismo ya que los usuarios o
administradores pueden haber modificado su sistema para ser resistente a las pruebas,
por lo que puede ser un motivo para realizar un anlisis sin aviso previo. Otra barrera
a la hora de realizar la evaluacin es el tiempo es que se ejecute bajo un plazo de
tiempo demasiado corto, algo a tener en cuenta ya que los evaluadores estn limitados
a marcos de tiempo muy pequeos, mientras los atacantes no tienen tales limitaciones.
3. Anlisis. Cuando nos referimos a anlisis, se quiere dar a entender al proceso que se
realiza de estudiar los resultados a lo largo de la ejecucin de las evaluaciones. Es por
ello por lo que los anlisis deben ser llevados a cabo durante la ejecucin, ya que se
debe descartar los falsos positivos e interpretar los resultados.
4. Manipulacin de datos.
El mtodo por el cual los datos de una organizacin se maneja durante toda la evaluacin es fundamental para garantizar la proteccin de la informacin confidencial,
incluida la arquitectura del sistema, configuraciones de seguridad y vulnerabilidades
del sistema. Las organizaciones deben garantizar la adecuada documentacin de los
requisitos para el manejo de datos en el plan de evaluacin o ROE, y se adhieren a
sus polticas de gobierno sobre el manejo de las vulnerabilidades del sistema. Se debe establecer mtodos para la recogida, almacenamiento y transmisin de datos de la
evaluacin durante un compromiso, as como para el almacenamiento y la destruccin
de los datos una vez que una evaluacin es completa.
5. Almacenamiento de datos. Debemos tener un especial trato con los datos que se van
recolectando segn avanza la evaluacin, incluyendo vulnerabilidades, resultados de
anlisis y recomendaciones de mitigacin. Una publicacin inapropiada de la informacin puede daar a la organizacin, por ejemplo en su reputacin, e incrementar la
posibilidad de explotacin externa.
6. Transmisin de datos y su destruccin. Podra ser necesario enviar datos de las evaluaciones a travs de la red interna o tambin externa. Asegurar la transmisin de
dichos datos debe estar garantizada mediante cifrado (Virtual Private Network (VPN)
o cualquier otro tipo de modo). Por otro lado, tambin se debe garantizar la destruccin de datos. Concretamente existe un SP, el 800-88, donde se aborda este tema. De
forma resumida, lo que intenta mostrar esta publicacin es que se debe tener precaucin con los los soportes fsicos y su reciclaje, pero tambin con los datos digitales,
los datos acumulados. Como ejemplo, menciona que para la eliminacin recomienda
la ejecucin de Secure Erase (para Serial Advanced Technology Attachment (ATA))

13

para un borrado completo que impida la recuperacin. Tambin puede realizarse una
destruccin de los datos mediante incineracin, pulverizacin, trituracin, etc.
Post-testing
Una vez realizada la fase de ejecucin, iniciamos la fase de post-testing. En este apartado
se mostrar una serie de acciones que, utilizando los datos obtenidos previamente, deberan
ser ejecutados para mejorar su seguridad. Entre ellos destacan la mitigacin, la realizacin
de un informe y soluciones.
1. Recomendaciones de mitigacin. Existen recomendaciones tcnicas y no tcnicas,
que se centran en cmo los procesos de la organizacin son gestionados. Por otro lado,
entre las recomendaciones tcnicas, podemos realizar por ejemplo la aplicacin de un
parche y entre las no tcnicas, el modo de gestin de dicho parche. En el SP 800-53,
encontramos una gran lista de recomendaciones de mitigacin como modificaciones
de procedimientos, cambios en la arquitectura de la seguridad, parches en el SO y
aplicaciones, etctera.
2. Informe. Una vez realizado el anlisis el informe debe identificar el estado de la red,
del sistema y de las vulnerabilidades de la organizacin, as como las acciones recomendadas para su mitigacin. Los informes pueden ser organizados dependiendo
del pblico al que se dirige, con ello se quiere decir que es recomendable un informe
diferente para ingenieros de seguridad, gestin de la configuracin o personal tcnico.
3. Soluciones. El primer paso para realizar la mitigacin es estudiar las recomendaciones
redactadas en el paso antes mencionado, pero se recomienda que se apliquen previamente en un entorno de prueba. En un segundo lugar, debe haber una coordinacin
entre las personas involucradas en los cambios pendientes para medir su impacto en
el entorno y las operaciones a realizar. En tercer lugar, una vez aplicados los cambios,
una auditora del sistema probando el sistema y sus componentes para as tener una
verificacin tcnica de los cambios realizados. Tambin es aconsejable volver a testar
el sistema para validar las acciones de mitigacin. Por ltimo, es importante actualizar
el POA&M para identificar las actividades que no se han cumplido, se han realizado
parcialmente o dependen de una tercera persona.

3.1.4

Modos de la realizacin de las pruebas

Las pruebas a ejecutar sobre un objetivo puede realizarse de varias formas. Depender tanto de la posicin del atacante como el conocimiento que tiene el evaluador sobre el objetivo
y el entorno que le rodea.

14

Externo e interno
Cuando hablamos de una posicin interna o un ataque externo, nos referimos a si nos
encontramos dentro del permetro de seguridad imaginario que rodea a la administracin y
asla de las amenazas del exterior. Normalmente, la parte externa suele ser Internet y la
parte interna de la organizacin intranet y como se puede deducir, los test de prueba estn
condicionados a esta situacin ya que normalmente la seguridad dentro de la organizacin
es ms dbil que en el lado exterior.
El testeo de la seguridad en el lado externo ofrece la capacidad de ver el comportamiento de la seguridad en el sistema como si fuera un atacante externo. Para la comprobacin
externa podemos utilizar tcnicas como buscar datos de registro pblico de un dominio, la
informacin DNS de un servidor, publicaciones en grupos de noticias, nombres del sistema, direcciones IP, etc. A continuacin podramos buscar servicios o puertos activos de un
posible firewall que crea el permetro, a la vez de ver qu informacin es filtrada, etc.
Para el lado interno los evaluadores se encuentran en una situacin similar a la que un
atacante haya burlado el permetro de defensa. Estos tipos de pruebas revelan vulnerabilidades que se podran aprovechar y demuestra el dao potencial que este tipo de atacante
podra realizar. Por otra parte, el nivel de acceso del asesor, que normalmente es el de un
usuario general, conlleva ejecutar las pruebas a su nivel pero, dependiendo de la naturaleza
del test, podra incrementar sus privilegios de acceso o conseguir el nivel de administrador
del sistema. Sin embargo, tambin es comn ejecutar las pruebas con diferentes niveles de
privilegios para as abarcar cualquier frente.
Encubierto o pblico: White hat y Black hat
A la hora de ejecutar una serie de pruebas, tambin se pueden realizar desde dos puntos de
vista que son vitales a la hora de su ejecucin, ya que no es lo mismo realizar comprobaciones
de seguridad si los empleados de una hipottica empresa son conocedores del mismo o si
no lo son. Cuando son conocedores de las pruebas que se estn realizando, se le dominan
pruebas White hat. El personal Tecnologas de la Informacin (TI) es plenamente consciente
de ello y de que ellos mismos estn formando parte de la prueba (de forma activa o pasiva).
Estas pruebas tambin pueden ayudar al personal indicando cmo llevar a cabo la misma
prueba o estudiando nuevas formas de evaluar sus propios sistemas que configuran.
Pero tambin existe otro tipo de pruebas, que son las pruebas encubiertas. Son aquellas
donde los empleados de la organizacin desconocen que se est sometiendo una prueba de
seguridad en el sistema. Tambin es llamado Black hat a este proceso y a menudo es
llevado a cabo por organizaciones que designan a un tercero para llevar a cabo esta tarea
con conocimiento y consentimiento de la direccin. En esta situacin esta tercera persona o
empresa, designa un agente para el equipo TI, direccin, etc. que media en las actividades y

15

facilita la comunicacin. Como se puede imaginar, este tipo de test es bastante beneficioso
para comprobar los controles tcnicos de seguridad, la respuesta del equipo a los incidentes
de seguridad y el conocimiento del equipo e implementacin de la poltica de seguridad de
la organizacin.
Con las pruebas Black hat, analizamos el dao que puede generar un atacante que busca
vulnerabilidades. Pero por otro lado, suele ser un proceso que suele llevar mucho tiempo
y suele ser costoso debido a los requisitos que conlleva el sigilo. Para llevar a cabo en un
entorno de cautela, el equipo de pruebas tendr que bajar su nivel de accin para evitar estar
bajo el radar del equipo de seguridad de la organizacin. Por contra, las pruebas White
hat son menos costosas y conllevan menos riesgos que las pruebas encubiertas pero, sin
embargo, las pruebas encubiertas demuestran una situacin ms real ya que los administradores no han aumentado su consciencia en la prueba y los resultados obtenidos son garanta
de haber ocurrido como un da cotidiano.

3.1.5

Metodologias para las evaluaciones de seguridad

A la hora de realizar pruebas de seguridad en una organizacin, existen una serie de metodologas que dan capacidad de reutilizacin y documentacin a las pruebas, beneficioso
ya que permite proporcionar consistencia y estructura a los tests de seguridad (minimizando
los riesgos de la prueba), acelera un hipottico cambio del equipo de evaluacin y tambin aborda las limitaciones de recursos relacionados con las pruebas. Destacaremos dos de
ellas, la realizada por el NIST publicado en la SP 800-373 y otra realizada por la del ingls:
Open Source Security Testing Methodology Manual. En espaol: Manual de la Metodologa
Abierta de Testeo de Seguridad (OSSTMM)4
SP 800-37. La publicacin especial del NIST 800-37, es una gua para para aplicar la gestin de riesgos en sistemas de la informacin federales de Estados Unidos,
desarrollado por Joint Task Force Transformation Initiative Working Group, que intenta transformar la certificacin y acreditacin tradicional (C&A, Certification and
Accreditation en ingls) en un proceso de seis etapas para gestionar los riesgos denominado Risk Management Framework (RMF) [Div10]:
NIST

1. Categorizar el sistema de la informacin. En esta etapa se clasifica el sistema y se

documenta los resultados de la clasificacin de seguridad en el plan de seguridad.
2. Seleccionar los controles de seguridad. Identificar los controles de seguridad que
son proporcionados por la organizacin as como los controles para los sistemas
de informacin de la organizacin y documentar los controles dentro de un plan
de seguridad (o un documento diferente). Tambin se desarrolla una estrategia
para el monitoreo de seguridad.
3

Se puede consultar en http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.

pdf ltima visita el 8 de junio de 2014.
4
Web oficial: http://www.isecom.org/research/osstmm.html ltima visita el 8 de junio de 2014.

16

3. Implementar controles de seguridad. Se implementa los controles seleccionados

previamente.
4. Controles de evaluaciones de seguridad: En esta etapa se debe desarrollar y aprobar un plan para los controles de evaluaciones de seguridad. Por otro lado tambin
se debe preparar un informe para documentar problemas, eventos y recomendaciones.
5. Autorizar el sistema de informacin. Preparar el plan de accin e hitos basados
en los eventos y recomendaciones desde el informe de seguridad. Por otro lado,
tambin se determinan los riesgos que puedan surgir.
6. Monitorear los controles de seguridad. Determinar el impacto de cambios propuestos o realizados entre otros aspectos.
OSSTMM. Del ingls Open Source Security Testing Methodology Manual, en espaol,

Manual de la Metodologa Abierta de Testeo de Seguridad [P.03], es una metodologa

de seguridad realizada por Pete Herzog que muestra una serie de actividades de testeo
especficas por rea, sobre las que se comprueban las especificaciones de seguridad,
integradas con las verificaciones realizadas en las revisiones rutinarias [OSS11]. Hay
que destacar sobre la metodologa, que tambin abarca aspectos sobre los responsables
de las pruebas. Realmente, trata de estandarizar las credenciales del desarrollador a
cargo del test, el formato de los resultados, crear un cdigo tico, un plan temporal
de ejecucin, etctera [P.03]. Entre las tareas de la versin 2.1 (versin gratuita), se
encuentra [L.10]
1. Seguridad de la Informacin
2. Seguridad de los Procesos
3. Seguridad en las tecnologas de Internet
4. Seguridad en las Comunicaciones
5. Seguridad Inalmbrica
6. Seguridad Fsica

3.2 Tcnicas de validacin

Es en este tipo de tcnicas donde se encuentran los test de penetracin, ya que nos sirven
para producir evidencias de vulnerabilidades potenciales.

3.2.1

Test de penetracin

Los test de penetracin son pruebas de seguridad en las cuales los asesores atacan mediante
tcnicas utilizadas en el mundo real para identificar mtodos para eludir las medidas de
seguridad en una aplicacin, sistema o red [SSCO08]. Las pruebas de penetracin puedes
ser tiles para:

17

Saber cmo el sistema tolera modelos de ataque reales.

Nivel de sofisticacin que los atacantes necesitan para comprometer el sistema.
Contramedidas adicionales que podran mitigar las amenazas contra el sistema.
Capacidad de los defensores para detectar ataques y responder a ellos de forma correcta.

3.2.2

Fases de las pruebas de penetracin

Entre las etapas de las pruebas de penetracin, encontramos la planificacin, el anlisis, el

ataque y el informe, como vemos en la figura 3.1.

Figura 3.1: Fases para la realizacin de pruebas de penetracin. Fuente: NIST SP800-115.

Planificacin. No se realiza ninguna prueba durante esta fase, pero se identifican las
reglas y se fijan los objetivos de las pruebas.
Anlisis. En esta fase se incluyen dos partes. En la primera se llevan a cabo las pruebas
normales y se obtiene informacin y se escanea las redes. Para ms informacin sobre
las tcnicas de bsqueda de informacin, puedes encontrarla en el captulo 3.1.1.
Durante la segunda parte, arranca la etapa de anlisis e identificacin de objetivos(ver
el captulo 3.1.2).
Ataque. Es la fase principal de un test de penetracin ya que es el proceso en el cual
se ejecutan los exploits. Algunos de ellos permitirn escalar privilegios en el sistema
o red para obtener acceso a recursos adicionales. Si esto ocurre, se requieren anlisis
y pruebas adicionales para determinar el verdadero nivel de riesgo para la red, tales
como la identificacin de los tipos de informacin que se puede extraer, cambiar o
eliminar del sistema.
Informe. Esta fase se produce casi de forma simultnea con las otras dos fases, ya que
en la fase de planificacin se ha desarrollado el plan de evaluacin. En la fase de anlisis y ataque, los log escritos se mantienen e informes peridicos son realizados para
18

los administradores del sistema o gestores. Como conclusin del test, un informe es
desarrollado para describir e identificar vulnerabilidades, presentar un nivel de riesgo
y dar soluciones para disminuir las debilidades encontradas.

3.3 Software para el pentesting

Para la realizacin de pruebas de penetracin o pentesting, el software por excelencia es
Metasploit. A continuacin se introducir este framework que ha revolucionado el panorama
de la seguridad informtica.

3.3.1

Metasploit

Metasploit es un framework Open Source de seguridad informtica desarrollado por Rapid7 destinado a localizar y explotar fallos de seguridad. Su objetivo es facilitar en gran
medida los penetration tests o test de penetracin. Estos test de penetracin involucran
un anlisis activo del sistema en todos los sentidos ya que envuelve no slo a los posibles
fallos de seguridad, sino tambin a los propios errores humanos generados por ingeniera
social [DK11].

Figura 3.2: Logo de Metasploit al ejecutar msfconsole.

Nace en 2003 de la mano de H. D. Moore y fue escrito en Perl, pero luego fue adquirido
por la empresa Rapid7 en 2007 y fue reescrito desde cero en Ruby. Desde entonces ha estado
disponible en dos versiones del software (generalizando), una de pago y otra gratuita, cuya

19

diferencia entre ellas es un entorno ms amigable y herramientas automticas de exploracin

y explotacin en la version de pago.
Todo su potencial lo ha convertido en el nombre ms escuchado en el campo de la seguridad informtica y ha revolucionado la forma en la que podemos ejecutar test de seguridad
en un sistema. La razn que hace que Metasploit sea tan popular es su plataforma de mdulos, la gran base de datos de exploits que dispone y la gran comunidad que hay detrs
del Framework. Est disponible tanto para Windows como para Linux (en versin 32 y 64
bits) requiriendo un procesador con una frecuencia mayor 2GHz y 2GB de Ram disponible [Seca].
Versiones de Metasploit
Como hemos mencionado previamente, las versiones de Metasploit se pueden agrupar en
dos opciones: la versin de pago y la gratuita. Entre la versin de pago podemos encontrar
Metasploit Express y Metasploit Pro, que son interfaces web para Metasploit Framework.
Estas utilidades proporcionan una gran automatizacin y hace todos los procesos ms fcilmente, proporcionando un completo acceso al framework pero incluyen tambin herramientas que no estn disponibles en la edicin Community del programa, as como el sistema de
fuerza bruta automtica para contraseas y los ataques automatizados para pginas web.
Arquitectura de Metasploit
Como podemos ver en la figura 3.3, en Metasploit est compuesto por tres conjuntos de
bibliotecas (library): Rex, Msf core y msf base. Vemos que con Rex interactan las herramientas y en msf base encontramos los plugins, interfaces (consola, cli, web, Graphical user
interface (GUI) y Armitage) y los mdulos.
Los mdulos implementan las funcionalidades del framework. Existen cinco categoras:
exploits, payloads, encoders, post-mods y auxiliary [DK11].
Herramientas bsicas de Metasploit
Metasploit cubre las tres principales interfaces, ya que es posible gestionarlo mediante
un entorno grfico para escritorio (Armitage), mediante lnea de comandos (msfconsole,
msfpayload, etc.) y mediante navegador web [PGP].
1. msfpayload. Permite generar shellcodes para diferentes lenguaje de programacin (C,
C#, Perl, Ruby, Raw, VBA,Python, etc.) o listar las shellcodes disponibles en el framework. Normalmente se utiliza para generar el cdigo que se utilizar con un exploit
que no se encuentre en el framework.
2. msfencode. Dificulta a los IDS, antivirus, etc. la deteccin del payload. msfencode se
basa en una serie de codificadores que buscan ofuscar algn modo estos payloads.

20

Figura 3.3: Arquitectura de Metasploit. Fuente: offensive-security.com

21

3. msfvenom. Unifica las dos citadas anteriormente.

4. msfpescan y msfelfscan. Son dos herramientas que permiten escanear ficheros ejecutables en Windows (la primera) y en sistemas GNU/Linux (la segunda) para encontrar
instrucciones de cdigo mquina sobre una imagen basada en memoria.
5. msfrop. En muchos sistemas operativos existe un Sistemas de prevencin de ejecucin
de datos (DEP) que previene la ejecucin del shellcode en la pila. Debido a ello, los
atacantes buscaron la manera de saltarse esta limitacin desarrollando ROP. El payload
ROP se crea utilizando conjuntos de instrucciones ya existentes sin el modo Address
Space Layout Randomization (ASLR) y as conseguir que el shellcode sea ejecutable.
Esta herramienta analiza el binario que se le pasa y tras el procedimiento devuelve los
gadgets que pueden ser usados.
6. msfd Es el daemon (o demonio) que escucha en un puerto. Permite a los clientes
conectar a ese servicio y disponer de su propia interfaz de consola. Los clientes pueden
conectarse mediante netcat indicando la direccin IP y el puerto. Por ejemplo: nc -v
127.0.0.1 55554.
7. msfconsole. msfconsole es el componente ms popular de Metasploit y proporciona
(siempre desde una forma sencilla), lanzar exploits contra objetivos, cargar mdulos
auxiliares, crear escuchas (listeners) o ejecutar una explotacin masiva contra una red
entera.
8. msfcli. Mientras que msfconsole proporciona una manera interactiva de acceder a todas las caractersticas de Metasploit mediante una interfaz amigable, msfcli da prioridad a ejecutar un script e interpretar con otras herramientas basadas en consola. Msfcli
tambin da soporte a lanzar exploits y mdulos auxiliares como msfconsole.

3.3.2

Metasploit API

Metasploit dispone de una Application Programming Interface (API) para los desarrolladores que se ejecuta en el puerto 3790 TCP, que es accedido mediante el protocolo Hypertext
Transfer Protocol (HTTP) sobre Secure Sockets Layer (SSL). El formato que utiliza es el de
Message-pack, un formato JavaScript Object Notation (JSON) de intercambio de informacin que representa la estructura de datos como arrays, intentando sus desarrolladores que
sea tan compacto como sea posible [Sin12].
Como cualquier peticin HTTP, recibe una serie de cdigos para informar del xito o
fracaso de la ejecucin. As pues los ms conocidos son 200, peticin ejecutada con xito o
500, la peticin ha devuelto un error.
Metasploit API da la oportunidad a los desarrolladores de ejecutar cualquier tipo de comando sobre Metasploit como si estuviramos trabajando con MSFConsole. Ya que permite
ejecutar comandos sobre sesiones, crear consolas, etctera [Rap13].

22

3.3.3

Meterpreter

Meterpreter es un intrprete de comandos para Metasploit pero que tambin acta como
Payload utilizando inyeccin de una DLL en memoria y un formato en arquitectura nativa de
un objeto compartido. Es una herramienta muy sigilosa y potente ya que, por ejemplo, funciona en el contexto del proceso vulnerable, por lo que no crea nuevos procesos [Sin12].
Como pasos para la ejecucin del intrprete de comandos, a continuacin se enumera el
proceso que Meterpreter realiza. Vemos en 3.4 un pequeo resumen.

Figura 3.4: Fases de ejecucin de meterpreter en un objetivo. Fuente [Sin12]

1. Obviamente el primer paso es que el exploit y el payload sean enviados a la mquina

objetivo.
2. A continuacin, el staget se adjunta al objetivo en una tarea especfica e intenta conectar con el atacante y un canal de comunicacin establecido.
3. Cuando se completa la inyeccin, MSF enva las DLL de Meterpreter para para establecer la comunicacin completa.
4. Por ltimo, meterpreter carga la extensin as como stdapi y priv. Ambas funciones son
cargadas mediante Transport Layer Security (TLS)/1.0 utilizando el protocolo Typelength-value (TLV). Por lo tanto, meterpreter utiliza comunicaciones cifradas con el
objetivo, por lo que es otra de las grandes ventajas que tiene.

3.4 Kali Linux

Kali Linux es el sucesor de la popular distribucin GNU/Linux BackTrack, diseada principalmente para la auditora y seguridad informtica. Al contrario que BackTrack, est basa23

da en Debian, y es mantenida por la compaa Offensive Security Ltd 5 , quienes desarrollaron

la distribucin a partir de su antecesor [kal].

Figura 3.5: Logo de Kali Linux

Se distribuye en imgenes ISO y contiene una gran variedad de herramientas para el testeo
de seguridad, anlisis de redes, sniffing, cracking de contraseas, testeo de acceso remoto,
anlisis de Bluetooth, pruebas de penetracin, etc. En el cuadro 3.5 puede consultarse un resumen de las herramientas ms conocidas clasificadas para diferentes anlisis de BackTrack
5, muy similar a Kali Linux, como ejemplo de la variedad de herramientas que contiene.

Web oficial http://www.offensive-security.com visitado el 7 de junio 2014.

24

Tcnica

Competencias

Examen de la documentacin

Evala tcticas (Policies) y procedimientos para la

precisin tcnica e integridad
Proporciona la informacin del historial en el uso
del sistema, configuracin y modificacin. Podra
revelar problemas potenciales y desviaciones en la
policy utilizada
Revela agujeros en los controles basados en conjuntos de reglas
Evala la complejidad de la configuracin del sistema y valida que el sistema est configurado segn la poltica establecida
Monitorizacin del trfico de la red para capturar
informacin como sistemas activos, sistemas operativos, protocolos de comunicacin, servicios y
aplicaciones. Verifica el cifrado de las comunicaciones
Identifica los cambios en archivos importantes.
Tambin puede identificar ciertas formas de archivos indeseables tales como herramientas conocidas por atacantes.

Analizar el log

Revisin del conjunto de reglas

Anlisis de la configuracin
del sistema
Sniffing en la red

Comprobacin de la integridad de los ficheros

Cuadro 3.1: Conjunto de tcnicas de anlisis

25

Tcnica

Conjunto de habilidades requeridas

Examen de la documentacin

Conocimiento general de la seguridad desde una

perspectiva de tctica
Conocimiento de los formatos de log y habilidad
para interpretar y analizar los datos de los log. Habilidad para usar un anlisis automtico de logs y
herramientas de correlacin de logs.
Conocimiento de los diferentes formatos de conjuntos de reglas y estructuras. Habilidad para correlacionar y analizar el conjunto de reglas desde
una variedad de dispositivos
Conocimiento de la configuracin de un sistema
seguro incluyendo el SO y politicas de configuracin para varios SO. Habilidad para utilizar herramientas de testing y su configuracin.
Control de transmisin general del protocolo
Transmission Control Protocol (TCP)/ Internet
Protocol (IP) y conocimiento de redes. Habilidad
para interpretar y analizar el trfico de la red. Habilidad para desplegar y usar herramientas de sniffing de redes.
Conocimiento del sistema de archivos general. Habilidad para usar herramientas que comprueben la
integridad de ficheros de forma automatizada e interpretar sus resultados.

Analizar el log

Revisin del conjunto de reglas

Anlisis de la configuracin
del sistema

Sniffing en la red

Comprobacin de la integridad de los ficheros

Cuadro 3.2: Conjunto de habilidades de referencia para Tcnicas para el anlisis

26

Tcnica

Competencias

Bsqueda de red

Encuentra los dispositivos activos. Identifica las

rutas de comunicacin y facilita el anlisis de las
arquitecturas de la red.
Analiza los dispositivos activos y analiza qu puertos estn abiertos asociados a aplicaciones o servicios.
Identifica hots y puertos abiertos. Identifica vulnerabilidades conocidas (con alto porcentaje de falsos positivos). A menudo proporciona consejos para mitigar vulnerabilidades encontradas.
Identifica dispositivos wireless no autorizados detro de un rango. Detecta seales wireless externas
al permetro de la organizacin. Busca potenciales
backdoors y otras violaciones de seguridad
Monitorizacin del trfico de la red para capturar
informacin como sistemas activos, sistemas operativos, protocolos de comunicacin, servicios y
aplicaciones. Verifica el cifrado de las comunicaciones
Identifica los cambios en archivos importantes.
Tambin puede identificar ciertas formas de archivos indeseables tales como herramientas conocidas por atacantes.

Puertos de la red e identificacin de Servicios

Escaneo de vulnerabilidades

Anlisis de Wireless

Sniffing en la red

Comprobacin de la integridad de los ficheros

Cuadro 3.3: Tcnicas de anlisis e identificacin de objetivos

Tcnica

Conjunto de habilidades de referencia

Bsqueda de red

Conocimiento de redes y de la pila TCP/IP. Habilidad para usar herramientas tanto pasivas como
activas de red.
Conocimiento de TCP/IP y conocimiento de redes.
Conocimiento de puertos para una gran variedad
de sistemas operativos. Habilidad en el uso de herramientas de escaneo de puertos. Habilidad para
interpretar los resultados.
Conocimiento de TCP/IP y conocimiento de redes.. Conocimiento de puertos, protocolos, servicios y vulnerabilidades para una gran variedad de
sistemas operativos. Habilidad para usar vulnerabilidades automatizadas e interpretar y analizar los
resultados.
Conocimiento general de transmisiones de radio y
computacin adems de conocimiento especfico
en protocolos wireless, servicios y arquitecturas.
Habilidad para usar escaneo de wireless automtico y herramientas de sniffing.

Puertos de la red e identificacin de Servicios

Escaneo de vulnerabilidades

Anlisis de Wireless

Cuadro 3.4: Tcnicas de anlisis e identificacin de objetivos

27

Tcnica de testeo de seguridad

Network Sniffing

Herramienta de testeo de seguridad

Review
Dsniff, Ettercap, Kismet, Mailsnarf, Msgsnarf,
Ntop, Phoss, SinFP, SMB Sniffer y Wireshark
Autopsy, Foremost, RootkitHunter y Sleuthkit.

Comprobacin de integridad
de archivos
Identificacin del objetivo y anlisis
Testeo de seguridad en aplica- CIRT Fuzzer, Fuzzer 1.2, NetSed, Paros Proxy y
ciones
Peach
Estudio de la red
Autonomous System Scanner, Ettercap, Firewalk,
Netdiscover, Netenum, Netmask, Nmap, P0f,
Tctrace y Umit
Identificacin de servicios y Amap, AutoScan, Netdiscover, Nmap, P0f, Umit,
puertos de la red
and UnicornScan
Escaneo de vulnerabilidades
Firewalk, GFI LANguard, Hydra, Metasploit,
Nmap, Paros Proxy, Snort y SuperScan
Wireless Scanning
Airsnarf, Airsnort, BdAddr, Bluesnarfer, Btscanner, FakeAP, GFI LANguard, Kismet y WifiTAP
Validacin de las vulnerabilidades del objetivo
Password Cracking
Hydra, John the Ripper, RainbowCrack, Rcrack,
SIPcrack, SIPdump, TFTP-Brute, THC PPTP, VNCrack y WebCrack
Testeo de acceso remoto
IKEProbe, IKE-Scan, PSK-Crack y VNC_bypauth
Test de penetracin
Driftnet, Dsniff, Ettercap, Kismet, Metasploit,
Nmap, Ntop, SinFP, SMB Sniffer y Wireshark

Cuadro 3.5: Resumen del conjunto de herramientas de BackTrack 5

28

Captulo 4

Mtodo

la sociedad demanda un producto y una empresa quiere cubrir esa necesidad,

sta requiere de una respuesta rpida y gil del producto para cubrir esa parte del
sector y as tener la mayor porcin del mercado posible, ya que vivimos en entorno donde
la competencia es un concepto a la orden del da. Es por ello por lo que ha surgido las
metodologas giles, ya que proporcionan una entrega rpida, clara y flexible del software
mientras se modifican y aparecen nuevos requisitos.
UANDO

El desarrollo agile surge en la dcada de los aos noventa debido a que, aunque las notaciones de modelado y las herramientas eran clave del xito para un proyecto de software,
an se requera una metodologa de software que indicase buenas directivas para llevarse a
cabo el proyecto. Hasta ese momento, las metodologas que se utilizaban tenan una rigurosa
definicin de roles, actividades y artefactos (incluyendo un modelado y una documentacin
muy detallados) que, no obstante, son necesarios hoy en da, ya que tenemos que hacer frente en muchas ocasiones a proyectos de gran envergadura que requieren gestionar al detalle
tiempo y recursos. Sin embargo, segn avanzaba la indispensabilidad del software, entraban
en el escenario nuevas situaciones en las cuales no encajaba totalmente las metodologas
tradicionales [Pal14].
Es aqu donde entra el desarrollo gil, ya que muchos de los proyectos actuales son muy
cambiantes y se exige reducir los tiempos de desarrollo, pero manteniendo una alta calidad.
El cliente parte de visin medianamente clara, pero debido a la velocidad en la que se mueve
su sector de negocio y tambin al nivel de innovacin que requiere, le es imposible predecir con detalle cmo ser el resultado final. Debido a esta situacin, muchos desarrolladores
prefieren prescindir de la elaborada documentacin de las metodologas antes mencionadas
(con los riesgos que conlleva), para as cumplir con el tiempo especificado para sus proyectos. Por lo tanto Agile nace para esta situacin, aportando una simplificacin, pero que no
renuncia a las prcticas principales para preservar la calidad del software. Por su contra, muchos equipos que utilizan hasta la fecha las metodologas tradicionales, argumentan que la
introduccin e inversin en formacin y herramientas es muy alta [PL06].

29

4.1 Metodologa Agile

Aunque la metodologa agile comenz a surgir a mediados de los noventa, no fue hasta el ao 2001 cuando miembros de la comunidad se reunieron en Snowbird (Utah) y se
adopt el nombre de mtodos giles. As pues en febrero de ese ao, diecisiete desarrolladores de software se reunieron para analizar los mtodos ligeros para el desarrollo, entre los
que se encontraban Scrum (1986), Crystal Clear (cristal transparente), programacin extrema (en ingls eXtreme Programming (XP), 1996), desarrollo de software adaptativo, feature
driven development, Mtodo de desarrollo de sistemas dinmicos (en ingls Dynamic Systems Development Method (DSDM), 1995). Fue entonces cuando se public el manifiesto
del desarrollo gil, tabla 4.1.

4.1.1

El manifiesto

Los integrantes de la reunin redactaron lo que para ellos eran las motivaciones de la
metodologa agile, aunque existan an en el ao 2005 cierta controversia sobre qu mtodo
era el ptimo. El manifiesto consta de cuatro valoraciones [PL06]:
1. Se valora ms a los individuos y a las interacciones del equipo del desarrollo que
a los procesos y a las herramientas. Se considera la sentencia ms importante de
todo el manifiesto, ya que el equipo quera mostrar que este era la columna vertebral de la metodologa. Por lo tanto, las personas son el factor principal de xito en
un proyecto de software ya que, aunque se siga un buen proceso de desarrollo, si el
equipo falla, el xito puede que no se consiga. Sin embargo, si las personas (el equipo) rinden correctamente, el objetivo final es ms que posible. No se valoran a los
grandes desarrolladores, sino aquellos que se adapten adecuadamente al equipo. No
obstante tambin se debe tener en cuenta que el exceso de herramientas puede afectar
negativamente ya que puede sobrecargar innecesariamente al equipo, por lo que puede
conllevar a un rendimiento ms bajo de lo esperado. Por este motivo, se prefiere una
eleccin correcta del equipo antes que enfocar todos los recursos en tener excelentes y
variadas herramientas.
2. Valorar el desarrollo de software que funciona antes de conseguir una documentacin excelente. Esta idea parte de que un software sin documentacin no va a ninguna parte, pero quiz la regla ms apropiada es no producir documentos a menos
que sean necesarios de forma inmediata para tomar un decisin importante. La documentacin debe estar centrada en el tema fundamental y ser muy corta, ya que la
documentacin excesiva no ofrece la riqueza de una comunicacin directa, porque si
una organizacin y varios equipos se comunican mediante documentos muy cargados,
se forma una barrera entre departamentos.
3. Valorar el contacto con el cliente antes de la negociacin contractual. Por las propias caractersticas de algunos proyectos de software, algunos han fracasado por estar
30

centrados en intentar cumplir los plazos y costes preestablecidos al inicio, fijados por
lo que el cliente solicitaba en ese momento. Es por este motivo por lo que la las prcticas giles estn indicadas para proyectos destinados a un escenario cambiante debido
al entorno del cliente. Es por ello por lo que el ambiente idneo de trabajo es aquel en
el que el cliente participe activamente, ms que tener una relacin limitada a establecer
unos lmites de contrato.
4. Valoracin al cambio que al seguimiento del plan. El fracaso o el xito de un proyecto puede estar determinado en cmo se responde a los cambios o imprevistos que
puedan surgir a lo largo del proyecto. Es por ello por lo que la flexibilidad, anticipacin
y la adaptacin deben estar presentes cuando se lleve a cabo la planificacin ya que
es mejor realizar planificaciones detalladas para unas pocas semanas y planificaciones
ms abiertas para los meses siguientes.

4.2 Scrum
Existen un gran abanico de metodologas gil para elegir por el desarrollador, entre las que
se puede destacar Crystal Methodologies, Adaptive Software Development, Dynamic
Systems Development Method o SCRUM. Nos centraremos en explicar SCRUM ya
que es la metodologa utilizada para el desarrollo del presente trabajo fin de grado.
Scrum es un mtodo de desarrollo identificado por Ikujiro Nonaka y Hirotaka Takeuchi a
principios de los aos 80 despus de analizar el modo de desarrollo de las principales empresas del momento tales como Epson, Brother, Canon, Honda, Nec, etc. El trmino deriva
de la posicin del jugador scrum del Rugby, siendo es el encargado de dirigir el juego de
la delantera, al igual que el apertura dirige el juego de la lnea, y dirigiendo entre ambos el
juego del equipo [Scr]. Se caracteriza principalmente por utilizar una estrategia incremental, mediante iteraciones (llamadas sprint con una duracin mayor a una semana pero no
superior a treinta das. Tambin se caracteriza por la implicacin del cliente (al que se muestra el producto al final de cada iteracin) y por el solapamiento de fases de desarrollo, en
contraposicin a las metodologas secuencial o cascada [Pal14].

Figura 4.1: Jeff Sutherland y Ken Schwaber en el evento Scrum, alrededor del 2009

31

Por otra parte, la palabra Scrum no comienza a aparecer en entornos de trabajo hasta los
aos 90, donde Ken Schwaber empez a utilizar Scrum en su compaa y, por otra parte, Jeff
Sutherland, con John Scumniotales y Jeff McKenna, desarrollaron una aproximacin similar
en la empresa Easel Corporation. Pero no fue hasta 1995 donde Sutherland y Schwaber presentaron conjuntamente un artculo describiendo la metodologa Scrum en el Business Object
Design and Implementation Workshop llevado a cabo en las conferencias Object-Oriented
Programming, Systems, Languages & Applications en la edicin de 1995 ( [Sch95]) en Austin (Tejas) siendo su primera presentacin. Sin embargo, ambos continuaron colaborando
durante los siguientes aos para unir sus trabajos anteriormente mencionados, sus experiencias y las mejores prcticas en lo que ahora es conocido como Scrum.
Metodologa gil

Metodologa tradicional

Pocos Artefactos. El modelado es prescindible, modelos desechables.

Pocos Roles, ms genricos y flexibles.
Cliente es parte del equipo de desarrollo
(adems in-situ)
No existe un contrato tradicional, debe
ser bastante flexible
Orientada a proyectos pequeos. Corta
duracin (o entregas frecuentes), equipos pequeos (<10 integrantes) y trabajando en el mismo sitio
La arquitectura se va definiendo y mejorando a lo largo del proyecto
nfasis en los aspectos humanos: el individuo y el trabajo en equipo
Basadas en heursticas provenientes de
prcticas de produccin de cdigo

Ms Artefactos. El modelado es esencial, mantenimiento de modelos.

Ms Roles, ms especficos
Existe un contrato prefijado
El cliente interacta con el equipo de
desarrollo mediante reuniones
Aplicables a proyectos de cualquier tamao, pero suelen ser especialmente
efectivas/usadas en proyectos grandes y
con equipos posiblemente dispersos
Se promueve que la arquitectura se defina tempranamente en el proyecto
nfasis en la definicin del proceso: roles, actividades y artefactos
Basadas en normas provenientes de estndares seguidos por el entorno de
desarrollo
Se espera que no ocurran cambios de
gran impacto durante el proyecto

Se esperan cambios durante el proyecto

Cuadro 4.1: Comparativa entre metodologas giles y tradicional

4.2.1

Roles

Se pueden destacar tres roles bien diferenciados en Scrum dentro del ScrumTeam: el
ScrumMaster, el cliente y el equipo [EW10].
ScrumMaster. Su papel es similar al tradicional manager project de las metodologas
tradicionales, pero no igual ya que es el responsable de que el ScrumTeam siga las
normas de Scrum, prcticas y valores. Su cometido es el xito del proyecto y l o
ella colabora aumentando la probabilidad de xito ayudado por el Product Owner que
selecciona lo ms destacado del Product Backlog y, mediante el Team, vuelve ese
backlog a la funcionalidad. Si el Scrum Team se enfrenta a un Blocker, un problema
32

que impide el progreso esperado, el ScrumMaster debe reaccionar rpidamente para

su rpida resolucin.
Product Owner. Es la persona propietaria del Product Backlog (requisitos del usuario). Su traduccin literal al espaol sera Propietario del producto pero es quien
toma las decisiones del cliente con el fin de que se simplifique la comunicacin y
las decisiones. Su funcin es representarlo. Por otra parte, es quien da prioridad a los
items de trabajo y define las condiciones de aceptacin y conocer todos los detalles del
cliente. El Scrum Product Owner debe reunirse con las partes interesadas (stakeholders) para as abarcar y conocer las necesidades [KS07] de cuatro grupos direccin,
que son aquellos que encargan el proyecto, empleados internos (aquellos a los que les
afecta el resultado del proyecto), socios y usuarios finales (son las partes interesadas
que usarn el producto que est desarrollo).
Team. Est formado por el conjunto de profesionales que participan en el proyecto,
como desarrolladores, testers, etc. que se requieren para llevar a cabo los requisitos
del Product Backlog. El equipo organiza y gestiona el proyecto y lo transforma en
incrementos. Aunque un equipo Scrum responde en su conjunto de forma cohesionada,
y tienen un mismo jefe comn, cada miembro responde por su trabajo.
ScrumTeam. Est formado por el Product Owner, el ScrumMaster y el equipo. Su
responsabilidad es localizar los puntos clave en el Product Backlog y entender cmo
llevar a cabo los diferentes incrementos para cada Sprint mientras gestionan su propio
trabajo en el proceso.

4.2.2

Artefactos

Para que el ScrumTeam lleve a cabo con xito el desarrollo del proyecto, existe una serie
de prcticas para la organizacin del equipo [Mar12].
Product Backlog: O bien pila de producto. Son los requisitos (priorizados) desde los
cuales crece el producto e indica la importancia, tanto en esfuerzo como en valor, del
desarrollo. El resultado de esta etapa puede ser el resultado de un informe de requisitos, mediante una tormenta de ideas, etc. Por otra parte, tambin se determina qu
elementos son los ms prioritarios que confieren ms valor al producto.
Sprint Backlog. Es un documento que describe cmo el equipo implementar los
requisitos durante los sprint. Las tareas se dividen en horas y son seleccionadas por los
miembros del equipo, segn vean oportuno para el desarrollo del proyecto, teniendo
en cuenta el esfuerzo que prev que tendr la tarea.
Sprint. Es la iteracin en la que el equipo trabaja para completar una tarea siguiendo
un Sprint Backlog. Un sprint es una manera idnea para planificar el tiempo del
proyecto y canalizar los recursos para trabajar en las necesidades de mayor prioridad.

33

La recomendacin sobre la duracin de un sprint vara, por ejemplo Ken Schewaber

recomienda un mes, aunque depende de la situacin podran ser ms cortas. As pues
la duracin de un Sprint en la mayora de los equipos (por ejemplo dentro de IBM) es
de dos semanas.
Sprint Review meeting. El principal objetivo de estas reuniones es comprobar si el
ScrumMaster consigui el objetivo principal (Sprint Goal). Todo el ScrumTeam forma
parte en estas reuniones y se debate sobre el trabajo realizado durante el Sprint para
as comprobar que todo se ha llevado a cabo como se esperaba.

Figura 4.2: Diagrama del ciclo iterativo scrum [Pal14]

4.2.3

Motivos para elegir Scrum

La razn principal por la que se ha decantado por esta metodologa son los requisitos de
tiempo (limitados), que el equipo de desarrollo est compuesto por una nica persona y,
especialmente, el desconocimiento de la tecnologa empleada para el desarrollo. Por ello,
creemos que es la metodologa que ms se adapta a la situacin con la que se inicia el
TFG.
Por otro lado, Scrum establece que la atencin recae sobre el software a desarrollar, especialmente en el equipo, quedando la documentacin en un segundo plano. Este es otro
motivo de peso para utilizar esta metodologa, especialmente porque la intencin del proyecto es tambin sacar al mercado el producto en el menor tiempo posible. La decisin de este
motivo no es otro que cubrir una necesidad actual y evitar retrasos indeseables.
Las iteraciones pueden consultarse en el Anexo A.

4.3 Herramientas utilizadas

Para el desarrollo del TFG se ha utilizado una serie de herramientas que han ayudado
incrementando la velocidad de su evolucin. Se han clasificado las herramientas segn su
finalidad.
34

4.3.1

Entorno
Diferentes sistemas operativos. Para el desarrollo de las pruebas de ejecucin de los
exploits, se ha utilizado como sistema operativo aquel que es necesario para su ejecucin. Con ello nos referimos a que, en el caso de que el exploit sea de Windows XP,
por ejemplo ms08_067_netapi, obviamente es requerido un Windows XP corriendo
en la mquina virtual. Por otro lado, se ha utilizado el sistema operativo Linux Mint
para el desarrollo del trabajo. Linux Mint es un sistema operativo libre, con ncleo
Linux, que ofrece un entorno amigable para el desarrollo de aplicaciones, entre otras
funciones.
Mercurial. Se ha elegido un control de versiones, ya que es la forma ms fcil de
gestionar los cambios que se producen en el cdigo del programa, as como gestionar
los sprint del proyecto. En este caso, se ha decantado por Mercurial por las ventajas que
ofrece respecto a los clsicos sistemas de control de versiones centralizados [OS07].
Repositorio. El repositorio del proyecto se encuentra en http://bitbucket.org que se
gestionar mediante Mercurial, junto con TortoiseHG en Windows, una herramienta
visual de Mercurial que facilita enormemente la gestin del repositorio.
Sistemas de virtualizacin. Como se ha mencionado anteriormente, se requera la virtualizacin del Windows XP para la ejecucin de los exploits. Para ello, se ha utilizado
la versin 4.3.10 de Oracle VM VirtualBox Manager.
Kali Linux. Este sistema operativo se ha convertido en el punto de referencia en cuanto
a auditora se refiere. Contiene una gran variedad de software dedicado a la seguridad
en computadores (ver el captulo 3).

4.3.2

Desarrollo de software

A continuacin se mencionan algunas herramientas que se han utilizado para complementar el desarrollo del proyecto.
Gimp 1 . Cuyo nombre son las siglas de GNU Image Manipulation Program, es un
programa que ofrece un abanico de sorprendentes funcionalidades en la edicin de
imgenes, tanto dibujos como fotografas. Se ha utilizado Gimp para editar las fotografas del documento escrito del TFG as como en la edicin de prototipos del entorno
grfico de la aplicacin.
Eclipse + plugin de Node.js. Eclipse es un conocido programa compuesto por un
conjunto de programas de cdigo abierto (multiplataforma), utilizado para desarrollar entornos de desarrollo integrados (Integrated Development Environment (IDE)).
Contiene un Workspace y una gran cantidad de plug-in que permiten personalizarlo
y hacen posible que sea compatible con varios lenguajes de programacin como C,
1

Web del proyecto: http://www.gimp.org/. Visitado el 26 de junio de 2014

35

C++, Fortran, Ruby, Perl, PHP o Python. Para el desarrollo del proyecto, en Node.js,
se ha utilizado el plug-in Nodeclipse que adapta el Workspace a las caractersticas de
Node.js.
NPM. Es un gestor de paquetes para NodeJS. Localiza conflictos de forma inteligente
de paquetes y los instala o bien en el directorio del proyecto o globalmente. Se ha
utilizado para satisfacer las dependencias con mdulos utilizados en Node.js. En su
pgina web oficial se pueden consultar todos los paquetes disponibles, alcanzando ya
80 246 2 .
Gedit. Es un editor de texto de Gnome, que no se excede en detalles para el desarrollo,
por lo que se utiliz para editar ficheros simples tales como package.json, o para la
edicin rpida de ficheros. Web del proyecto en https://wiki.gnome.org/Apps/Gedit.
Se encuentra disponible tambin para Windows y Mac OS X.
Chromium. Es un navegador web de cdigo abierto publicado por Google, que ya
ha alcanzado la versin 34.0. Se ha utilizado para visualizar el entorno grfico de la
aplicacin as como para depurar AngularJS.
Robomongo 3 . Es un entorno grfico para visualizacin y edicin de base de datos de
MongoDB. Se ha utilizado la versin 0.8.3 y ofrece un entorno amigable y sencillo de
utilizar y se ha utilizado para manipular las base de datos (test y de ejecucin normal)
de la aplicacin. Est disponible para Mac OS, Windows y sistemas GNU/Linux.

4.3.3

Desarrollo del trabajo escrito

El desarrollo de la memoria del trabajo se ha llevado a cabo casi en su totalidad mediante

LATEX, complementado con Visual Paradigm, un software de edicin de diagramas.
LATEX. Es un lenguaje para la edicin de textos orientado a la creacin de libros y
artculos cientficos. Se ha utilizado LATEXpor la facilidad de redactar documentos estructurados, la construccin de macros y rdenes y la sencillez a la hora de redactar
el texto. Para la edicin de los ficheros se ha utilizado TexMaker, un potente editor de
texto para LATEXcon control de ortografa para espaol, asistente de bibliografa, etctera. La versin que se utilizaba es la 4.1. Por otro lado, se ha utilizado la clase esi-tfg
adaptada a la normativa del TFG de la Escuela Superior de Informtica de Ciudad Real
(ver ltima pgina de la presente memoria).
Visual Paradigm. Segn leemos en su web 4 Visual Paradigm es una herramienta de
diseo especializada en proyectos de software agile. Admite modelos normalizados
como Unified Modeling Language (UML), SysML, ERD, DFD, BPMN, ArchiMate,
2

Extrado de https://www.npmjs.org/. Visitado el 26 de junio de 2014

Web del proyecto: http://robomongo.org/. Visitado el 24 de junio de 2014.
4
http://www.visual-paradigm.com/. Visitado el 24 de junio de 2014.
3

36

etc. y facilita el desarrollo de software y sistemas. Destaca en la experiencia del usuario

soportando casos de uso, agrupacin de requisitos, flujo de eventos y un largo etctera.

4.3.4

Desarrollo del programa

Por ltimo, se lista a continuacin los lenguajes de programacin empleados. El producto

final se encuentra desarrollado en Node.JS. Se sigue la llamada pila Javascript (del ingls
STACK Javascript), denominada MEAN, formada por MongoDB, Express, AngularJS y Node.JS.
Node.js 5 . Es un entorno de programacin en el lado del servidor basado en el lenguaje
Javascript. Est orientado a eventos y utilizada el motor V8 de Google, incorporado
en su navegador Google Chrome. Est disponible para cualquier sistema operativo,
GNU/Linux incluido, estando disponible para descarga desde repositorios con el paquete nodejs. No obstante se puede descargar desde su pgina web.
Mocha. Es un framework de testing para Node.js. Ofrece soporte para las libreras
expect.js o should.js, aunque para los test se utilizar tan solo expect.
MongoDB. Es un sistema de base de datos clasificada como NoSQL orientada a almacenar documentos. Proviene de la palabra inglesa homongous, que significa gigantesco, y es una base de datos open-source que rechaza el modo tradicional de base de
datos basada en tablas, para mostrar el contenido mediante un formato JSON con schemas dinmicas, facilitando la integracin de los datos en las aplicaciones de forma ms
rpida. En la pgina web de MongoDB nos indica que el almacenamiento est orientado a documentos y que se caracteriza por ser indexado mediante cualquier atributo,
replicacin en redes Local Area Network (LAN) y Wide Area Network (WAN) y, especialmente, indica que reduce el coste, acelera el tiempo al mercado y mitiga el riesgo
con mantenimiento proactivo y potencial para el entorno empresarial [MON14].
AngularJS. Es un framework desarrollado por Google para aplicaciones web en el
lado del cliente, cuyo objetivo es colaborar con aplicaciones Modelo Vista Controlador
(MVC) para facilitar las pruebas del software y su desarrollo.
Bootstrap. Es un framework front-end para el desarrollo responsive en entorno web,
tanto para escritorio como para dispositivos mviles. Se ha elegido Boostrap debido a
la sencillez de la gestin del contenido por parte del Cascading Style Sheets (CSS).
Metasploit. Es un framework Open Source de seguridad informtica desarrollado por
Rapid7 cuyo objetivo es facilitar en gran medida los penetration tests. Metasploit
nace en 2003 de la mano de H. D. Moore escrito en Perl, siendo luego adquirida por
la empresa Rapid7 en 2007 reescribindose desde cero en Ruby. Desde entonces ha
estado disponible en dos grupos de versiones de software, una de pago y otra gratuita,
5

Web oficial http://nodejs.org/, ltima visita el 25 de mayo de 2014

37

cuya diferencia entre ellas es un entorno ms amigable y herramientas automticas

de exploracin y explotacin en la versin de pago mediante una interfaz web. Se
comunicara con Metasploit mediante la API disponible para desarrolladores [Rap13]
(ver ms en el captulo antecedentes, en la seccin 3.3.1).
NMAP [NMA]. Es una herramienta que nos permite recopilar informacin sobre una
red que haya sido fijada como objetivo. Entre las opciones disponibles, NMAP facilita la obtencin de datos como, por ejemplo, los puertos abiertos en un dispositivo
o incluso su sistema operativo. En definitiva, es una eficaz herramienta para analizar
el estado de una red y ver los posibles escenarios de vulnerabilidad que podran tener
lugar.

38

Captulo 5

Resultados

lo largo de este captulo, se desarrollar cmo se ha abarcado el proyecto as como

su estructura apoyada mediante diagramas UML, para mejorar la comprensin de las
acciones que tiene que realizar el usuario para ejecutar un anlisis, encontrar objetivos en la
red, etctera.

5.1 Requisitos en el Product Backlog

Antes de analizar cmo se ha estructurado el proyecto, se mostrar en esta seccin cmo
se ha organizado, as como sus requisitos. As pues, en la planificacin y distribucin de
roles y realizacin del Product Backlog, este ltimo estar formado por los puntos fijados
como objetivos en el captulo 2. En cuanto a la planificacin de roles, explicado en el captulo 4 (seccin 4.2.1) el equipo estar formado por una nica persona, el alumno, Daniel
Garca Artalejo, que desempear dentro del equipo la funcin de diseo grfico, pruebas y
desarrollo. Por otro lado, el director del TFG, Francisco Moya, tendr los papeles de Product
Owner y Scrum Master, ya que la funcin de director del TFG queda representada por estos
roles. El cliente, desconocido, ser aquellas empresas de auditora que utilicen el software
como anlisis pentesting automtico.

5.1.1

Primera reunin

Durante la primera reunin se fijan los objetivos mencionados y tambin las herramientas
disponibles para el equipo Scrum as como el lenguaje de programacin y entorno grfico a
utilizar. Respecto al lenguaje de programacin, se establece utilizar la pila Javascript denominada MEAN, formada por MongoDB, Express, AngularJS y Node.JS. Como se explic en
el captulo de mtodo (seccin 4.3), MongoDB es una base de datos NoSQL, Node.JS es un
entorno de programacin en Javascript para el lado del servidor, acompaado de la biblioteca
Express y AngularJS para el entorno grfico (basado en web) y apoyado con bootstrap. Para
ms informacin sobre estas herramientas, se puede leer en la seccin 4.3 dentro del captulo
de mtodo.

39

5.1.2

Iteraciones

En las iteraciones fijadas en la primera reunin con el Scrum Master, se decide que el
software constar de cinco iteraciones, de tres semanas de duracin cada una, donde se desarrollarn las funciones que se detallarn a continuacin, indicando cules son los requisitos
del software. No obstante, debido a que se considera que los detalles de cada iteracin (por
ejemplo, la prioridad, el equipo, etc.) es de carcter complementario, se encuentran en el
Anexo A de este documento.
Iteracin 1: Se fija como objetivo la realizacin de un anlisis de la red utilizando
NMAP. Se debe mostrar el resultado mediante la interfaz web y tambin habilitar un
formulario para poder escribirla. Se recuerda que debe crearse un servidor web para
que el cliente pueda conectarse y ejecutar el proceso mediante una interfaz clara y
limpia de sobrecarga, aqu es donde entra la utilizacin de express y su organizacin
de paquetes.
Iteracin 2: En esta iteracin se fija realizar la primera ejecucin de un exploit sobre
un objetivo seleccionado y muestra la informacin por la interfaz grfica. Se utiliza
Metasploit API para comunicarse con el framework.
Iteracin 3: Ejecucin de polticas sobre un objetivo seleccionado. Se habilitan los
anlisis y mostrar la informacin del proceso. De nuevo, al igual que la iteracin nmero uno, se debe crear en la interfaz las pertinentes secciones de una forma clara, tal
y como se fij en el Product Backlog.
Iteracin 4: En esta iteracin se desarrolla las opciones de agregar opciones explotacin. Una vez ejecutado un anlisis con efectividad, se deben realizar acciones sobre l.
En esta iteracin se debe aadir esas opciones y mostrar la informacin por la interfaz
grfica.
Iteracin 5: Por ltimo, se debe desarrollar un sistema para generar un informe sobre los test de penetracin realizados. Debe generarse en formato Portable Document
Format (PDF).

5.2 Organizacin del desarrollo

Ya que el objetivo principal del proyecto es la ejecucin de exploit, se ha creado un diagrama de casos de uso para mostrar este proceso por parte del responsable de la empresa.
En la figura 5.1 vemos que solo existe un actor, el responsable, que es quien debe ejecutar el
software cuya primera accin es buscar los dispositivos conectados dentro de la red donde
se ejecuta el programa, para as poder seleccionar los objetivos sobre los que realizar los
anlisis. A continuacin, debe seleccionar un anlisis ya creado y elegir las polticas de las
que consta dicho anlisis. Vemos que las polticas estn formadas por diferentes exploits,
que pueden tener diferentes comportamientos. Una vez realizado el anlisis, y en el caso de

40

haber establecido una sesin con un objetivo, podr ejecutar el mdulo de post-explotacin
para realizar cualquier accin sobre el objetivo.

Figura 5.1: Diagrama de casos de uso para el responsable de la empresa

5.2.1

Dependencias en NodeJS

Para el desarrollo del programa se ha utilizado una serie de dependencias que han facilitado el avance del proyecto. A continuacin, se realiza una breve explicacin de la funcin
de cada biblioteca y por qu se ha elegido, dando especial mencin a express, socket.io,
mongoose y msfnode, ya que son los pilares de la aplicacin.
Express 1 . Es un potente framework para Node.js definido segn sus creadores como
un entorno de desarrollo de aplicaciones web minimalista y flexible. Est inspirado
en Sinatra (para el lenguaje de programacin Ruby) y es el software ms conocido en
la actualidad para Node.js 2 . Su intencin es proporcionar servidores HTTP de forma
robusta y sencilla, intentando ser la mejor solucin para aplicaciones basadas en web,
web sites o API pblicas. La versin utilizada es la 3.5.1 y debido (adems) a su organizacin, facilita la organizacin del desarrollo en multicapas [EXP14]. La sencillez
de express puede verse en el listado 5.1 donde con pocas lneas se ha creado un sencillo servidor web. Al visitar el puerto 3000 de la mquina donde se ejecuta, muestra el
tpico hello world.
libxmljs 3 . Es una biblioteca que sirve para gestionar ficheros eXtensible Markup Language (XML). Se utilizar para recoger la informacin aportada por NMAP.
1

http://expressjs.com/ Visitado el 18 de junio de 2014.

Con 47 311 descargas en un da segn https://www.npmjs.org/package/express (visitado el 18 de junio
de 2014).
3
https://github.com/polotek/libxmljs. Visitado el 18 de junio de 2014.
2

41

var e x p r e s s = r e q u i r e ( e x p r e s s ) ;
var app = e x p r e s s ( ) ;
app . g e t ( / , f u n c t i o n ( req , r e s ) {
r e s . send ( h e l l o world ) ;
}) ;
app . l i s t e n ( 3 0 0 0 ) ;

Listado 5.1: Ejemplo de servidor con Express.

jade. Es una biblioteca que ofrece al programador un sistema de plantillas para generar
los ficheros HyperText Markup Language (HTML) en el lado del servidor para ser
servidos al cliente [JAD14].
msfnode 4 . Biblioteca versin 0.5 que permite el envo de comandos a Metasploit
utilizando su API mediante paquetes Msgpack. Permite la creacin de consolas (con
comandos como msfconsole) y muchas funcionalidades ms que permite la API de
Metasploit.
mongoose 5 . Biblioteca que permite la interaccin entre el programa y la base de datos
de MongoDB. Proporciona una solucin basada en schema para modelar los datos
de la aplicacin e incluye conversin de tipos, validacin, construccin de querys,
etctera [MON14]. Mongoose es un middleware y es necesario destacar una de sus
caractersticas ya que permite definir funciones que son ejecutados antes o despus de
las operaciones save o remove (ver en el listado 5.2 un ejemplo de ejecucin de una
serie de comandos antes de guardar la instancia). Por defecto MongoDB no notifica
detalles si ocurre un error, sin embargo mongoose soluciona este error llamando a la
funcin db.getLastError y mostrndolo al desarrollador [Rau12].
MODEL. p r e ( s a v e , f u n c t i o n ( next ) {
if ( t h i s . isNew ) {
// doSomething
}else{
// doSomethingElse
}
}) ;

Listado 5.2: Al llamar a la funcin Save, se ejecuta el cdigo listado, que evala la
informacin antes de ser almacenada en la BD.
npmlog 6 . Biblioteca que gestiona el log de la herramienta.
async 7 . Es una biblioteca que facilita la ordenacin en la ejecucin de funciones en
4

https://github.com/eviltik/msfnode. Visitado el 18 de junio de 2014.

web oficial http://mongoosejs.com/. Consultado el 15 de junio de 2014
6
Repositorio e informacin: https://www.npmjs.org/package/npmlog. Consultado el 15 de junio de 2014
7
Documentacin https://github.com/caolan/async. Consultado el 15 de junio de 2014
5

42

NodeJS. Por cuestiones de seguridad, se requiere la versin 0.7, ya que permite encolar
las funciones, indispensable en el proyecto y disponible a partir de la mencionada
versin, ya que es a partir de la cero punto seis donde se facilita el control de ejecucin,
encolando iteraciones, e incluso permite pausar el proceso.
socket.io. Es una biblioteca que facilita la interaccin en tiempo real entre el cliente
y el servidor, por lo que se diferencia en dos tipos de bibliotecas, teniendo ambas un
comportamiento idntico en la API. Socket.io utiliza un protocolo de WebSocket y
proporciona una asociacin con cada cliente y entrada/salida asncrona [SOC14].

5.2.2

Estructura del proyecto

Para realizar ms sencillo el desarrollo de la aplicacin, se ha elegido el sistema de arquitectura por capas, un patrn que separa los datos y la lgica de una aplicacin de la interfaz.
Como principal ventaja, cabe destacar que el desarrollo se puede realizar independientemente de qu parte se ample, por lo que encaja perfectamente en el desarrollo que se ha
planificado. Tambin es ideal debido a la metodologa elegida, ya que es un desarrollo incremental. En el modelo multicapa, se suele encontrar tres niveles: presentacin, desarrollo (o
gestin) y datos (o entidades) [CAP14].
Presentacin: En la capa de presentacin es aquella donde se presenta el sistema al
usuario y donde se ejecutan las acciones y se visualiza la informacin desde el servidor,
como se puede ver en el diagrama de paquetes de la figura 5.2. Tambin suele ser
conocida como interfaz grfica y su caracterstica principal es la de ser amigable con
el usuario. En cuanto a la implementacin de esta capa, se ha llevado en dos partes: la
carpeta views y la carpeta public forman parte de ella. Debido al modelo escogido de
visualizar la informacin, era requisito mostrar al menos una pgina que cargase las
bibliotecas Javascript en el lado del cliente (AngularJS, socket.io y el resto de ficheros
del lado del cliente se explicar ms adelante). Por lo tanto, en views se encuentra
un fichero que utiliza la biblioteca Jade para mostrar la cabecera de la pgina en el
navegador, y en la carpeta public se encuentran los ficheros CSS, Javascript y HTML
que mostrarn la informacin. Ms adelante se detalla la organizacin de la carpeta
public.
Gestin o desarrollo. Es aquel cdigo que recibe las peticiones que solicita el cliente
y mediante el cual se envan las respuestas. Esta capa se comunica con la capa de
presentacin y es mediante esta comunicacin interna cmo se enva la informacin
al cliente. En nuestro software, son clases de gestin todas aquellas almacenadas en el
directorio routes (apoyadas por bibliotecas enlib) con funciones que son llamadas por
Express dependiendo de la informacin que quiera visualizar el cliente o acciones que
se ejecuten.
Datos. Es la capa por la cual se recuperan los datos desde la BD (en este caso Mon-

43

goDB). Cada clase est formada normalmente por los mtodos Create, Read, Update
y Delete (CRUD) para manipular los objetos con la BD: create (crear), read (leer), update (actualizar) y delete (borrar). En nuestro desarrollo, estas clases son denominadas
Models (gestionadas por la biblioteca Mongoose) que son construidas a partir de los
Schemes de la BD, gracias a estos models podemos manipular los datos de una manera
sencilla y almacenarlos en la base de datos.

Figura 5.2: Diagrama de casos de uso para el responsable de la empresa

Teniendo como referencia el diagrama de paquetes (ver figura 5.2), vemos que las clases se
encuentran agrupadas en seis paquetes, llevando a cabo cada uno una accin correspondiente
al sistema por capas, as pues en el TFG encontramos:
routes. Se corresponde con la capa de gestin o desarrollo y contiene las clases que
gestionan las peticiones de Express, correspondientes a las solicitudes que hace el
cliente. La organizacin de este paquete se ha llevado a cabo creando una clase para
cada tipo de peticin. As, las peticiones sobre anlisis las gestiona la clase Scan,
por ejemplo. Este paquete depende de models (la capa de datos) para crear nuevas
instancias de los datos o recuperarlos para manipularlos. Por otro lado, libs contiene
las bibliotecas que gestionan los datos. Adems, tiene relacin con views y public ya
que es la capa intermedia entre la capa de presentacin y datos, y en esos paquetes se
encuentran las diferentes clases del entorno grfico.
models. En este paquete se encuentran las clases correspondientes a la capa de datos.
Concretamente cada archivo es un model de uno o varios schemas que modelan los
datos de la aplicacin correspondiente a la collection (lo correspondiente a una tabla en
44

mongoDB) y adems de los mtodos CRUD, permite aadir funciones para ejecutarse
en la instancia. Ms adelante, se detalla cmo facilita mongoose un entorno claro y
sencillo con los modelos o models.
lib. Forman parte de la capa de desarrollo ya que son clases que son utilizadas para
aquellas del paquete routes, como se ha mencionado anteriormente.
public. Contiene los ficheros HTML, Javascript y dems que son servidos por el servidor web express y que ver el cliente. Obviamente, corresponde a la capa de presentacin.

5.2.3

Diseo de clases

A continuacin, se analizar el diseo del diagrama de clases, agrupadas en paquetes (ver

diagrama 5.3). Siguiendo la organizacin de paquetes antes expuesta, se detallar el diseo
de cada clase junto con su funcin.
App. Es la clase que inicia la ejecucin de la aplicacin. Se declaran los objetos de
express y socket.io. Depende de la clase Index donde se indican las rutas (routes) para
express. Este fichero es clave ya que asocia express con las clases del nivel de gestin
y permite el flujo de informacin entre las capas de presentacin y gestin.
Presentacin. En la capa de presentacin se encuentran tres clases que engloban todo
el funcionamiento de este nivel. App.js es el encargado de iniciar la instancia de AngularJS y, utilizando los mdulos netServices y ngRoute, se especifican los archivos
de rutas en el lado del cliente y su correspondiente plantilla HTML, gestionados por
los controllers, funciones que se encuentran en la clase Controllers y que contienen la
lgica de cada pgina. Por otro lado, como servicios (en la clase Service) indicamos
las funciones responsables de crear el objeto singleton, utilizado con express en el lado del servidor. Dichos ficheros se encuentran en el paquete public, la carpeta raz del
servidor web.
En el lado del servidor, consideramos la biblioteca Jade como parte de la capa de
presentacin, ya que crea el cdigo HTML sobre el que se ejecutar la aplicacin en el
lado del cliente utilizando el fichero index.html del paquete views.
Gestin. Es donde se encuentra la lgica del programa. Dependiendo de la url solicitada express llamar a la clase correspondiente. La clase Home ser llamada cuando
el cliente visite la pgina principal de la aplicacin, Scans para la manipulacin de
anlisis de pentesting, Policies para la configuracin de polticas, MsfManager para
la gestin de las sesiones establecidas con el objetivo, Report (quien es llamado por
las clases Scans y Net para registrar actividades y, a su vez, es utilizado para generar
un informe de las actividades realizadas y mostrarla para descarga) y, para finalizar,
Socket.io que es un conjunto de funciones listener que se encuentran a la escucha para
responder las peticiones del cliente interactivamente. Por otro lado, Modules es una
45

clase que gestiona los mdulos de sesin y exploit utilizados para la ejecucin de comandos de post-explotacin, permitiendo su personalizacin mediante mdulos (que
se encuentran en el paquete modules).
Datos. Encontramos las clases ModuleMSF, Network, Policies y Scan. El primero
gestiona el schema correspondiente a los exploits, Network administra los schemas de
Net y Target, redes y objetivos respectivamente. Se ha decidido una relacin muchos
a muchos en este model para evitar duplicidades de objetivos (obviamente se entiende
que si un dispositivo tiene una IP siempre ser ese mismo dispositivo si se llama a esa
IP). Respecto a Policies y Scan, son models correspondientes con las polticas y los
anlisis, como su nombre indica, y todas ellas son llamadas por las clases de gestin
con el nombre homnimo, excepto Target que es utilizada en las clases de gestin
Policy y Scans.
Para la visualizacin en detalle del diseo de la base de datos, se ha creado otro diagrama de entidad-relacin que puede visualizarse en la seccin diseo de base de
datos, es por esa razn por la que tan solo aparecen los nombres de las clases correspondientes a este nivel del modelo de capas, ya que con MongoDB (como se ha
mencionado), son las mismas clases de datos las que son almacenadas en la base de
datos (ver seccin 5.2.1 para ms detalles).

5.2.4

Diseo de la base de datos

Aunque MongoDB es clasificada como una base de datos orientada a documentos y utiliza schemas (esquemas) dinmicos, se ha realizado su diseo mediante el modelo entidadrelacin. Los modelos entidad-relacin se encuentran justificados para la presentacin de
cualquier tipo de datos y es un buen sistema para mostrar la estructura de un modelo, es por
ello por lo que se ha utilizado este procedimiento. Para llevar a cabo la posterior adaptacin
de los tipos de archivos a MongoDB, tan solo se han tenido que modificar varchar por el tipo
String, integer por Number y bit por Boolean. No obstante es ms compleja la adaptacin
de las relaciones entre las tablas mostradas en MongoDB, ya que se organiza de una manera
diferente. Sin embargo, el diagrama (ver figura 5.4) muestra de forma fiel y clara el diseo
final utilizado en el proyecto.

5.2.5

Ejecucin de un anlisis

El objetivo principal del proyecto es la ejecucin del proceso por parte de un responsable
de la empresa, es decir, de alguien que no tiene conocimientos relacionados con la seguridad
(o incluso un nivel bajo de conocimientos de informtica), es por ello por lo que existe un
nico actor que analiza las redes, seleccionando los objetivos y arrancando el anlisis. En la
figura 5.5 vemos el proceso detallado del proceso antes mencionado.
Como vemos, una vez que el programa est arrancado (ver Anexo B para ver cmo iniciar

46

el software), el actor solicita una bsqueda de red, que es gestionada mediante la biblioteca
express, llamado sta a una funcin de la clase NetRoute. sta a su vez, solicita a una biblioteca del paquete lib (NetScan), el anlisis de la red solicitada. Devuelve los datos mediante
un mensaje JSON con la red y sus IP a la funcin y sta crea un nuevo model con la red y los
objetivos, que son almacenados en la BD, una vez terminado express devuelve la informacin
al cliente.
Terminado este proceso, el usuario puede crear un anlisis (aunque ya debe de estar configurado) por lo que express llamar a la clase ScanRoute y ste consultar las polticas
aadidas en el sistema para que el usuario elija cules son las ms apropiadas para el anlisis. El usuario as selecciona los objetivos y las polticas y express se lo comunica a la clase
NetScan, quien crea una instancia del model ScanModel y ejecuta cada exploit incluido en
la poltica comunicndose con la clase ModulesLib quien ejecuta los comandos sobre MsfManager, encargada de enviar los mensajes a MsfNode, quien crea los mensajes en formato
Msgpack para comunicarse con Metasploit. Una vez finalizado, NetScan actualiza la instancia creada y enva la informacin aportada por la API de Metasploit al cliente. Despus
de este proceso, el cliente puede realizar acciones sobre las sesiones establecidas, como por
ejemplo, realizar una captura de pantalla.

5.2.6

Diseo de la interfaz

Como ya se ha mencionado a lo largo del captulo, la interfaz de la aplicacin se apoya en

un servidor web. En este apartado analizaremos cmo se ha adaptado HTML5 al diseo as
como las posibilidades de personalizacin:
Fcilmente configurable para la empresa de auditora. Uno de los requisitos impuestos
a la hora de comenzar el desarrollo de este TFG era la capacidad de personalizacin por
parte de la empresa de auditora del software. Realizar la interfaz en HTML no solo da
libertad para consultar la informacin desde cualquier dispositivo, tambin da facilidad
de manipulacin de imgenes, mens, colores, etc. gracias a la comodidad de edicin
que permite CSS o la manipulacin directa de ficheros. Como ejemplo, tenemos al logo
de la empresa, que puede sustituirse fcilmente por otro con tan solo un par de clic de
ratn.
Adaptable. La utilizacin de bootstrap ha hecho posible un diseo adaptable, esto quiere decir que el diseo de la aplicacin se amolda a la resolucin de la pantalla del
dispositivo desde el cual se ha accedido. Concretamente se ha fijado tres tipos de resoluciones (ver figuras 5.6 y 5.7): PC (con una resolucin destinada a la web mayor a
970px), tablet (750px) y smartphone en resoluciones menores.
Personalizacin. En el fichero config.conf (ver listado 5.3) existe una serie de variables
que son fcilmente editables donde se pueden especificar el nombre de la organizacin
entre otros datos, que luego sern utilizados en el informe.
47

e x p o r t s . p o r t = p r o c e s s . env .PORT | | 3 0 0 0 ;
e x p o r t s . mongodb = {
u r i : p r o c e s s . env .MONGODB | | l o c a l h o s t / p e n t e s t i n g
};
e x p o r t s . companyName = t f g SA ;
e x p o r t s . projectName = TFG: Herramienta de p e n t e s t o r i e n t a d o y a u t o m a t i c o
;
e x p o r t s . systemEmail = D a n i e l . G a r c i a A r t a l e j o @ g m a i l . com ;
exports . MetasploitServer = {
IP : p r o c e s s . env . m e t a s p l o i t i p | | l o c a l h o s t ,
p o r t : p r o c e s s . env . m e t a s p l o i t p o r t | | 55553 ,
l o g i n : p r o c e s s . env . m e t a s p l o i t L o g i n | | myLogin ,
password : p r o c e s s . env . m e t a s p l o i t P a s s | | myPassword
};
e x p o r t s . db = {
normal : mongodb : / / l o c a l h o s t / p e n t e s t i n g ,
t e s t : mongodb : / / l o c a l h o s t / p e n t e s t i n g _ t e s t
};

Listado 5.3: Configuracin de inicio de la herramienta.

Crditos a imgenes
Antes de finalizar esta seccin sobre el diseo de la interfaz, es necesario citar a tres
diseadores que gracias a su trabajo publicado mediante licencias Creative Commons 8 , se
ha podido dar vida con imgenes al TFG.
Imagen de la parte inferior izquierda azul: Realizado por Dev.Arka 9 Bajo licencia (CC
BY-ND 2.0).
Logotipo de empresa de pentesting. Realizado por Freepik 10 Con licencia CC BY 3.0.
Imgenes de la pgina inicial. Realizado por graphicloads

11

Con licencia CC BY 3.0.

Fotografa de Jeff Sutherland fue tomada desde su web personal http://scrum.jeffsutherland.

com con licencia CC BY-NC-SA 3.0.

http://creativecommons.org/. Visitado el 2 de Julio de 2014.

https://www.flickr.com/photos/totallygenius/808187848/sizes/o/in/photostream/ consultado el 2 de
julio de 2014.
10
http://www.flaticon.com/free-icon/policeman 1259 consultado el 2 de julio de 2014.
11
http://www.iconarchive.com/artist/graphicloads.html consultado el 2 de julio de 2014.
9

48

Figura 5.3: Diagrama de clases. NOTA: Para la visualizacin en detalle del diseo de la base
de datos, se ha creado otro diagrama de entidad-relacin.
49

Figura 5.4: Adaptacin al modelo entidad-relacin de la base de datos en MongoDB

50

Figura 5.5: Diagrama de secuencia para el responsable de la empresa

51

(a) Diseo adaptado a un PC

(b) Diseo adaptado a un Smartphone

Figura 5.6: Comparacin entre el diseo para PC y Smartphone

52

Figura 5.7: Diseo adaptado para tablet

53

Captulo 6

Conclusiones

lo largo de este captulo se har un breve resumen de aquellos conocimientos adquiridos durante la realizacin de este TFG as como de los aspectos en los que podra
aumentar su capacidad de cara al futuro.

6.1 Ejecucin de los objetivos

Como resumen de los objetivos alcanzados, se ha dividido por funcionalidades de la aplicacin. Por un lado, tenemos la interaccin entre los programas de pentesting y su recogida
de datos, la comunicacin con el usuario y el almacenamiento en una base de datos de las
polticas, exploit y dems datos que la empresa de auditora ha aadido al sistema para su
ejecucin.
Comunicacin con herramientas de test de penetracin. Uno de los principales
obstculos en la realizacin de la aplicacin para realizar tests de penetracin, recae,
de forma obvia, sobre la comunicacin entre sta y el software a utilizar para ejecutar dichas pruebas. Por ejemplo, en la aplicacin utilizada para escanear los puertos y
dispositivos en una red, NMAP, se aprovech la salida en formato XML, despus reconocido mediante la biblioteca libxmljs de Node.js y, por otro lado, la funcin principal,
la ejecucin de exploits y la post-explotacin, gracias a Metasploit, se realiz mediante
su API, como se ha comentado en captulos anteriores.
Persistencia de datos. Otro aspecto importante es el de almacenar datos generados
por Metasploit o NMAP que son recogidos por la aplicacin y, an ms importante, la
configuracin correspondiente a la personalizacin y ejecucin de los ataques aadidos por la empresa de auditora ya que tiene que modelar el software para cumplir el
objetivo del proyecto: evidenciar un problema de seguridad. En este sentido, cumple
perfectamente el cometido el motor de bases de datos MongoDB, ya que existe una
relacin nativa con los objetos del lenguaje Javascript, adems de ser rpida y permitir
un acceso fcil y cmodo a los datos. Sin embargo, la eleccin de MongoDB ha conllevado la modificacin del modo de trabajo respecto a las tradicionales base de datos
relacionales, que ha generado en muchas facilidades, pero tambin dificultad, como
por ejemplo en las relaciones de muchos a muchos, dado que se gestiona de una forma

54

completamente diferente entre ambos tipos de BD.

Comunicacin con el usuario. Como eleccin de un entorno amigable se ha elegido
crear un entorno web. Esta eleccin me ha servido para comenzar a programar con
bibliotecas javascript en el lado del cliente como AngularJS y JQuery o el conjunto
de clases CSS, bootstrap, que han facilitado un entorno muy llamativo para el usuario.
Gracias a Express y a socket.io en el lado del servidor, he podido comprobar cmo se
manejan los datos entre el cliente y el servidor mediante un alto nivel de abstraccin,
haciendo posible gracias a ello uno de los principales objetivos del TFG: que tenga un
acceso a la aplicacin de forma atractiva y fcil. Adems, hay que aadir que bootstrap
ha facilitado en gran medida la adaptacin a diferentes tamaos de pantallas gracias a
la facilidad de realizar diseos adaptables (o responsive), teniendo en cuenta la accesibilidad de una pgina web, ha sido posible que sea accedida desde una gran variedad
de dispositivos. Gracias a este conjunto de bibliotecas se ha facilitado el desarrollo de
una parte no importante del proyecto con resultados que sobresalen de lo esperado.
Fcilmente ampliable. Para conseguir este objetivo se llev a cabo la realizacin de
plantillas que sirven como base para la ejecucin de diferentes rdenes sobre los objetivos, tanto en post-explotacin como en la ejecucin de exploit en s. Este modo
de planificacin asegura la ejecucin de cualquier tipo de exploit ya que permite a los
pentesters utilizar cualquier configuracin, ya que cada plantilla queda personalizada
con los requisitos de dicho exploit. Por lo tanto, sta ltima caracterstica del software
es la que realmente aporta un alto grado de configuracin y, lo que es ms importante,
una automatizacin total.

6.2 Conclusin final y expectativas de futuro

Como aspectos importantes en cuanto al software empleado, he descubierto un lenguaje
que desde siempre haba pensado que en la informtica se encontraba en un segundo lugar.
Y es que he podido comprobar a lo largo de este trabajo que gracias a la pila Javascript, he
conseguido cumplir los objetivos de una forma rpida y realmente fcil, ya que es un lenguaje
basado en eventos, con entrada/salida no bloqueante y que, adems, es sorprendentemente
rpido, arropado por una participativa y abrumadora comunidad. En el apartado del entorno
grfico, he aumentado mis conocimientos en diseo web gracias a CSS 3, HTML 5, AngularJS
y al uso de la librera Bootstrap.
Como caractersticas pendientes, que complementaran a las actuales, son aquellas que
permiten la ejecucin de scripts, una tarea ms especializada y ms cercana al pentester
profesional, as cmo una gestin ms compleja de los mdulos antes mencionados, ya que
la interaccin implementada es la ms bsica. Por otra parte, como es lgico, tambin se
requiere aadir exploits y ms medidas de ingeniera social, con el fin de ser una aplicacin
ms compleja. Esto se lograra aadiendo una nueva sesin para el pentester que permitira
55

configurar los exploits (su comportamiento, sus dependencias, etc.), actualmente se aade
una serie de exploit ya configurados para su ejecucin.
Cabe destacar que una de las principales metas que se han intentado conseguir a lo largo
de este trabajo fin de grado, sin tener en cuenta el entorno software para llevarlo a cabo, es
la de estudiar y conocer una de las ramas ms importantes de la informtica (la seguridad)
que segn he podido comprobar, en varios mbitos, no se encuentra an entre las opciones
importantes entre aquellas que las pymes dedican sus recursos. Al avanzar el proyecto e ir
encontrando informacin en publicaciones y leyendo artculos publicados, se va afianzando
la idea expuesta en la introduccin de este proyecto: la seguridad en informtica est muy
poco valorada y, especialmente, la aparicin de vulnerabilidades crticas en cualquier tipo de
aplicacin est a la orden del da. Por lo que, si la informtica es un campo muy dinmico,
la seguridad lo es an ms, lo que implica no solo una nica revisin de seguridad: esta
auditora debe ser adems peridica.
Para finalizar, espero que en algn momento este software sea adaptado para ser ejecutado en un entorno profesional y finalizar con ese crculo vicioso visto en el captulo 1 de
introduccin, para as ayudar a que las pymes estn ms protegidas ante ataques o amenazas.
Como experiencia personal, ha sido muy gratificante realizar este proyecto no solo por la
gran cantidad de conocimientos en el apartado de seguridad, que han complementado a todo
lo que he estudiado en el grado, sino tambin por ser un pequeo paso al futuro laboral, que
espero que est relacionado con este tema en particular, porque realmente es muy importante
y esencial en la sociedad de hoy en da.

56

ANEXOS

57

Anexo A

Iteraciones Scrum

En este Anexo se especificar el Product Backlog, los requisitos que deben cubrirse en
cada una de las cinco iteraciones planificadas. Para la lectura de las tablas, debe tenerse
encuentra que las filas con un color de fondo ms oscuro se corresponde a que esa tarea no
se ha finalizado al terminar la iteracin.

A.1 Iteracin 1
Objetivo principal: fijar como objetivo la realizacin de un anlisis de la red utilizando
NMAP. Se debe mostrar el resultado mediante la interfaz web y tambin habilitar un formulario para poder escribirla. Se recuerda que debe crearse un servidor web para que el cliente
pueda conectarse y ejecutar el proceso mediante una interfaz clara y limpia de sobrecarga,
aqu es donde entra la utilizacin de express y su organizacin de paquetes.

58

Nombre de la tarea

Fecha de inicio

Fecha de finali-

Prioridad

zacin

Estudio de software en Kali Linux

2014-01-19

No finalizado

Alta

Leer manuales de NodeJS, Mongoose, MongoDB y Metasploit

2014-01-19

No finalizado

Alta

Buscar integracin con Eclipse

2014-01-19

2014-01-23

Alta

Crear una estructura bsica de trabajo

2014-01-19

2014-01-21

Media

Crear repositorio en Bitbucket

2014-01-19

2014-01-23

Media

Disear, implementar y probar un

hello word en Node.js junto con
express

2014-01-19

2014-01-21

Media

Estudiar cmo comunicarse con

NMAP

2014-01-19

2014-01-31

Media

Buscar mejores prcticas con Express y AngujarJS

2014-01-19

No terminado

Media

Implementar la clase npmlog

2014-01-29

2014-01-30

Baja

Nombre de la tarea

Fecha de inicio

Fecha de finali-

Prioridad

zacin

Desarrollar una biblioteca para comunicarse con NMAP mediante

libxmljs

2014-01-31

2014-02-05

Media

Estudiar posibilidades de diseo con

Bootstrap

2014-01-28

No finalizado

Media

Desarrollar clase de gestin Net

2014-02-03

2014-02-10

Media

Disear models para redes y objetivos

2014-02-03

2014-02-17

Media

Disear e implementar un formulario

HTML y recibir los datos

2014-01-23

2014-02-28

Media

Buscar informacin sobre AngularJS

2014-01-19

No terminado

Baja

Estudiar y disear la interaccin

AngularJS-Express

2014-02-24

2014-02-27

Alta

Implementar interaccin AngularJSExpress

2014-01-24

2014-03-02

Alta

59

A.2 Iteracin 2
Objetivo principal: En esta iteracin se fija realizar la primera ejecucin de un exploit
sobre un objetivo seleccionado y muestra la informacin por la interfaz grfica. Se utiliza
Metasploit API para comunicarse con el framework.
Nombre de la tarea

Fecha de inicio

Fecha de finali-

Prioridad

zacin

Estudio de software en Kali Linux

2014-01-19

2014-03-01

Alta

Leer manuales de NodeJS, Mongoose, MongoDB y Metasploit

2014-01-19

No finalizado

Alta

Estudiar posibilidades con Bootstrap

2014-03-01

2014-03-05

Media

Implementar men con Bootstrap

2014-03-02

2014-03-08

baja

Modificar formulario de redes encontradas

2014-03-01

2014-03-05

baja

Buscar informacin sobre Metasploit

API

2014-03-01

No finalizado

Alta

Bsqueda de plantillas libres que

usen bootstrap

2014-03-01

2014-03-10

Baja

Anlisis de la mejor opcin de ejecucin de exploit usando la API

2014-03-15

2014-03-20

Alta

Desarrollar men HTML

2014-03-16

2014-03-20

Baja

Buscar informacin sobre socket.io

2014-03-16

2014-05-01

Media

Buscar el exploit ms sencillo de ejecutar

2014-03-18

2014-03-20

Alta

Creacin de nueva seccin con un

formulario que muestre los objetivos

2014-03-29

En progreso

Alta

Ejecucin interactuando directamente con la API al hacer clic sobre el

objetivo. Se muestra la informacin
por consola.

2014-03-29

2014-04-15

Alta

Buscar informacin de la librera

async. Problemas al ejecutar exploits
por dependencias de ejecucin.

2014-03-29

2014-04-05

Baja

Creacin de la biblioteca para interactuar con la API.

2014-04-05

2014-04-09

Media

60

Nombre de la tarea

Fecha de inicio

Fecha de finali-

Prioridad

zacin

Creacin de la biblioteca para interactuar con la API.

2014-04-05

2014-04-09

Alta

Incorporacin de Socket.IO para el

flujo de informacin

2014-04-09

En progreso

Alta

Realizacin de diagrama entidadrelacin para la base de datos

2014-04-09

2014-04-13

Alta

Implementacin de las clases del nivel de entidad de polticas y exploits

2014-04-12

2014-04-20

Alta

Ejecucin de exploit utilizando polticas en vez de exploits directos junto

con la biblioteca creada previamente

2014-04-17

2014-04-23

Alta

Realizacin de pruebas con redes y

objetivos

2014-04-18

2014-04-25

Media

A.3 Iteracin 3
Objetivo principal: Ejecucin de polticas sobre un objetivo seleccionado. Se habilitan los
anlisis y mostrar la informacin del proceso. De nuevo, al igual que la iteracin nmero
uno, se debe crear en la interfaz las pertinentes secciones de una forma clara, tal y como se
fij en el Product Backlog.
Nombre de la tarea

Fecha de inicio

Fecha de finali-

Prioridad

zacin

Leer manuales de NodeJS, Mongoose, MongoDB y Metasploit

2014-01-19

No finalizado

Alta

Buscar informacin sobre Metasploit

API

2014-03-01

2014-04-30

Alta

Incorporacin de Socket.IO para el

flujo de informacin

2014-04-30

2014-05-10

Alta

61

Nombre de la tarea

Fecha de inicio

Fecha de finali-

Prioridad

zacin

Creacin de nueva seccin con un

formulario que muestre los objetivos

2014-05-02

2014-05-04

Alta

Buscar exploits ms complejos (al

menos dos)

2014-05-02

2014-05-02

Alta

Buscar bibliotecas de Node.js que

permitan enviar emails y subir ficheros por FTP

2014-05-02

2014-05-02

Alta

Diseo y desarrollo de la clase

Scans.

2014-05-02

2014-05-10

Alta

Diseo de la seccin anlisis en la

interfaz de usuario

2014-05-02

2014-05-23

Medias

Implementacin CSS y HTML en la

interfaz anlisis

2014-05-02

2014-05-15

Media

Ejecucin de dos exploits en un anlisis.

2014-05-04

2014-05-17

Alta

Implementacin con socket.io la manipulacin de polticas y objetivos

sobre un anlisis

2014-05-13

2014-05-30

Alta

Posibilidad de crear un anlisis

2014-05-13

2014-05-13

Media

Posibilidad de editar informacin de

un anlisis

No iniciado

No iniciado

Alta

Diseo atractivo de la interaccin

con el usuario en la seccin anlisis

2014-05-20

2014-05-30

Media

Implementacin de cifrado en el servidor web

2014-05-23

2014-05-23

Baja

62

Nombre de la tarea

Fecha de inicio

Fecha de finali-

Prioridad

zacin

Reorganizacin de la estructura fsica del proyecto

2014-05-23

2014-05-23

Baja

Desarrollo de la seccin de polticas

2014-05-23

2014-05-24

Media

Diseo y desarrollo de mdulos para

la ejecucin de exploit

2014-05-23

2014-05-28

Alta

Creacin de seccin de polticas

2014-05-23

2014-05-26

Media

Personalizar (editando)
(nombre y descripcin)

polticas

2014-05-26

2014-05-26

Media

Agregar/eliminar exploits a una poltica

2014-05-26

2014-05-27

Alta

Realizacin de pruebas en anlisis

2014-05-26

2014-05-28

Media

63

A.4 Iteracin 4
Objetivo principal: En esta iteracin se desarrolla las opciones de agregar opciones explotacin. Una vez ejecutado un anlisis con efectividad, se deben realizar acciones sobre
l. En esta iteracin se debe aadir esas opciones y mostrar la informacin por la interfaz
grfica.
Nombre de la tarea

Fecha de inicio

Fecha de finali-

Prioridad

zacin

Leer manuales de NodeJS, Mongoose, MongoDB y Metasploit

2014-01-19

2014-06-01

Media

Modificacin de la clase manager

con Metasploit

2014-06-01

2014-06-01

Media

Creacin de seccin sessiones

2014-06-01

2014-06-05

Media

Planificacin y desarrollo con socket.io de la seccin sesiones en el

lado del servidor

2014-06-05

2014-06-07

Media

Desarrollo de plantilla para sesiones

2014-06-05

2014-06-05

Media

Bsqueda de posibles comandos fciles de ejecutar

2014-06-05

2014-06-05

Media

Desarrollo de mdulos para ejecutar

en sesiones

2014-06-05

2014-06-07

Alta

Bsqueda de iconos para la pgina

principal y logotipo de la empresa

2014-06-07

2014-06-07

Baja

Adaptacin de la pgina principal

con accesos directos

2014-06-08

2014-06-08

Alta

64

A.5 Iteracin 5
Objetivo principal: Se debe desarrollar un sistema para generar un informe sobre los test
de penetracin realizados. Debe generarse en formato PDF.
Nombre de la tarea

Fecha de inicio

Fecha de finali-

Prioridad

zacin

Buscar una biblioteca para poder generar PDF

2014-06-08

2014-06-08

Baja

Verificar la viabilidad de hacerlo en

Socket.io

2014-06-08

2014-06-08

Baja

Generar y disear informe de prueba

2014-06-08

2014-06-10

Media

Planificar y disear el entorno dentro

de la interfaz grfica

2014-06-08

2014-06-10

Media

verificar funcionalidades del software

2014-06-10

2014-06-10

Media

Editar informacin de un anlisis

(nombre y descripcin)

2014-06-10

2014-06-12

Alta

65

Anexo B

Ejecucin del software

Como se ha mencionado previamente, se ha realizado el programa utilizando la pila Javascript. En el lado del servidor, corresponde tener instalado NodeJS y NPM como gestor de
paquetes para Node, para ello en Kali Linux (o cualquier distribucin basada en Debian), debe ejecutarse el siguiente comando como administrador para su instalacin (listado B.1).
Una vez instalado, debemos verificar si se encuentra instalado Metasploit y Nmap. Si no
es as, debe visitar la pgina web oficial de Metasploit y descargar la versin Community.
Una vez descargado, debe instalarlo como administrador (listado B.1). Si se ejecuta en Kali
Linux, no es necesario realizar ninguna accin de instalacin.
Se recuerda que se utiliza como base de datos MongoDB, por lo que debe estar instalado (listado B.1). Para el correcto funcionamiento del programa, se requiere una versin de
MongoDB mayor que la 2.5.
aptg e t i n s t a l l n o d e j s npm
aptg e t i n s t a l l nmap
aptg e t i n s t a l l mongodb

Listado B.1: Instalando dependencias de software.

Una vez instalados los programas de los que depende el software, debe situarse en la carpeta del mismo y ejecutar el comando de la lista B.2, con el que se instalaran todas las dependencias del software dentro de NodeJS, que pueden visualizarse en la subseccin 5.2.1.
npm i n s t a l l

Listado B.2: Instalando dependencias dentro de NodeJS.

Terminada la instalacin, se debe configurar las variables de configuracin. Esto es, por
ejemplo, en qu IP se encuentra el servidor Metasploit (junto con el nombre y usuario), el
nombre de la organizacin, etc. El nombre fijado en el fichero de configuracin y su contrasea deben ser la misma que la configurada al arrancar el fichero en Metasploit. Aunque es
ajeno al proyecto, se indica a continuacin cmo ejecutar el servidor de Metasploit con una
66

contrasea y usuario genricas. Existe un fichero de ejemplo, config.sample.js, que puede ser
utilizado como plantilla. El fichero de configuracin debe tener como nombre config.js. Se
recuerda tambin que el servicio de Metasploit debe estar ejecutndose,a continuacin puede
consultar ambos comandos (listado B.3).
service metasploit start
msfrpcd U myLogin P myPassword f

Listado B.3: Comandos para la ejecucin de Metasploit.

Si se han realizado estos pasos, el software debera poder ejecutarse en todos los SO derivados de Debian, por lo que se puede iniciar el programa. Para ello, se puede utilizar o bien
npm o bien directamente mediante NodeJS (listado B.4).
npm s t a r t
n o d e j s app . j s

Listado B.4: Opciones de ejecucin del programa.

Una vez iniciado, puede visitar con su navegador la direccin https://SERVIDOR:4000.

Sustituya SERVIDOR por la direccin IP donde se ha iniciado el software. Por ejemplo,
utilice https://localhost:4000 si se ejecuta desde localhost.

67

Anexo C

Manual de usuario para el responsable

Para la ejecucin de la aplicacin, antes deben realizarse una serie de pasos por parte de la
empresa de auditora para que todas las dependencias de software sean satisfechas. Este paso
se puede consultar en el anexo B. As pues, una vez realizada esta etapa previa y ejecutndose
la aplicacin, debe visitar con su navegador preferido la direccin https://SERVIDOR:4000.
Se debe sustituir SERVIDOR por la direccin IP donde se ha iniciado el software. Por ejemplo, utilice https://localhost:4000 si se ejecuta desde localhost.
La primera pantalla (ver figura C.1) que se ver ser la que podemos ver, denominada
pgina de inicio o home en ingls. Vemos que en la parte superior se encuentra un men
por el que podemos navegar para visitar todas las secciones del programa, pero antes de
visitarlas se describir el contenido de la pgina de inicio.

Figura C.1: Primera vista de la interfaz.

Como vemos, en la parte superior se encuentra dos columnas con estadsticas de la aplicacin y ms abajo cuatro accesos directos: buscar objetivos, configurar polticas, ejecutar
68

acciones sobre sesiones e iniciar anlisis.

A continuacin, deberamos seguir estos pasos para realizar test de penetracin:
1. Objetivos. Hacemos clic en objetivos y a continuacin en lista de objetivos. Como
se puede ver en la figura C.2, en estos momentos no existen ninguna red aadida, por lo
que debemos analizar la red haciendo clic de nuevo sobre objetivos y a continuacin
sobre buscar nuevos objetivos. Nos aparecer un formulario (ver figura C.3) donde
introduciremos la red (IP y mscara), haremos clic en escanear y despus de unos
segundos (dependiendo del tamao de la red, se redireccionar a la pgina antes vista
con los objetivos encontrados (ver figura C.4).

Figura C.2: Listado de objetivos ya disponibles, ahora mismo ninguno (primer inicio).

2. Configuracin de polticas. Como paso previo a la configuracin de los anlisis, debemos agrupar en polticas los exploits disponibles en la base de datos que queramos
utilizar. Hacemos clic en polticas y nos aparecer la lista de las ya agregadas (ver
figura C.5). En este panel podremos realizar los siguientes pasos:
Agregar una nueva poltica. Para ello, hacemos clic en agregar poltica y veremos un formulario que debemos rellenar (nombre y descripcin). Posteriormente
podremos configurar los exploits.
Aadir/eliminar Exploits. Tan solo debemos hacer clic en la columna exploits
en el icono de configuracin. Se mostrar un dilogo (ver figura C.6) y podremos
seleccionar o eliminar los exploits de los que consta.
Manipular polticas. En la columna de acciones hay disponibles varias opciones
para modificar su funcionamiento: podemos eliminar o editar su informacin.

69

Figura C.3: La aplicacin est buscando objetivos en la red.

Figura C.4: Lista de objetivos encontrados.

3. Configurar anlisis. Para ejecutar las polticas, debemos crear un nuevo anlisis. Slo
tenemos que hacer clic en anlisis y veremos los ya creados (ver figura C.7). En esta
pantalla podremos realizar las siguientes acciones:
Agregar un nuevo anlisis. Debemos hacer clic en agregar anlisis y veremos
un formulario que debemos. Posteriormente podremos configurar los exploits.
Aadir/eliminar polticas. Tan solo debemos hacer clic en el icono de configura-

70

Figura C.5: Lista de polticas agregadas por defecto.

Figura C.6: Formulario para agregar una poltica nueva.

cin de la columna polticas. Se mostrar un dilogo (ver figura C.8) con un

formulario donde podremos seleccionar o eliminar las polticas que queramos.
Aadir/eliminar objetivos. Debemos hacer clic en el icono de configuracin. de
la columna objetivos y se mostrar un dilogo en el cual podremos seleccionar o
eliminar los objetivos que queramos (ver figura C.9).
Acciones. En esta columna podremos eliminar, iniciar, pausar y parar un anlisis.
Tambin podremos reiniciar y ver los datos obtenidos desde su ejecucin. Para
71

Figura C.7: Pantallazo de la seccin de anlisis.

Figura C.8: Formulario para agregar poltica.

iniciar un anlis, hacemos clic sobre el icono play y, si tiene xito, veremos
en la barra de progreso el color verde (ver figura C.10). En el caso de fracaso, el
color es rojo y, por ltimo, si es un exploit que requiere una accin por parte del
objetivo (como visitar una url), aparecer en naranja.
4. Sesiones activas. Una vez ejecutado el anlisis y si han tenido xito los exploits ejecutados, se debe haber creado una sesin donde podremos ejecutar los comandos pre-

72

Figura C.9: Formulario para elegir objetivo.

Figura C.10: Anlisis con xito.

configurados por la empresa de auditora. Debemos hacer clic en sesiones (figura

C.11) y haciendo clic sobre una sesin establecida, podremos seleccionar las acciones
a realizar. En la figura C.12 vemos el ejemplo de captura de pantalla.
5. Generar informe. Por ltimo, y no menos importante, podremos generar un informe
de todos los pasos creados hasta ese momento. Para ello, hacemos clic en generar
informe en el men superior y se ofrecer la opcin de descarga.

73

Figura C.11: Listado de secciones establecidas con un objetivo.

Figura C.12: Captura de pantalla realizada sobre el objetivo.

74

GNU Free Documentation License

Version 1.2, November 2002

c 2000,2001,2002 Free Software Foundation, Inc.
Copyright
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but
changing it is not allowed.

Preamble
The purpose of this License is to make a manual, textbook, or other functional and useful
document free in the sense of freedom: to assure everyone the effective freedom to copy
and redistribute it, with or without modifying it, either commercially or noncommercially.
Secondarily, this License preserves for the author and publisher a way to get credit for their
work, while not being considered responsible for modifications made by others.
This License is a kind of copyleft, which means that derivative works of the document
must themselves be free in the same sense. It complements the GNU General Public License,
which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free
software needs free documentation: a free program should come with manuals providing the
same freedoms that the software does. But this License is not limited to software manuals; it
can be used for any textual work, regardless of subject matter or whether it is published as a
printed book. We recommend this License principally for works whose purpose is instruction
or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice
placed by the copyright holder saying it can be distributed under the terms of this License.
75

Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that
work under the conditions stated herein. The Document, below, refers to any such manual
or work. Any member of the public is a licensee, and is addressed as you. You accept
the license if you copy, modify or distribute the work in a way requiring permission under
copyright law.
A Modified Version of the Document means any work containing the Document or
a portion of it, either copied verbatim, or with modifications and/or translated into another
language.
A Secondary Section is a named appendix or a front-matter section of the Document
that deals exclusively with the relationship of the publishers or authors of the Document to
the Documents overall subject (or to related matters) and contains nothing that could fall
directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a
matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The Invariant Sections are certain Secondary Sections whose titles are designated, as
being those of Invariant Sections, in the notice that says that the Document is released under
this License. If a section does not fit the above definition of Secondary then it is not allowed
to be designated as Invariant. The Document may contain zero Invariant Sections. If the
Document does not identify any Invariant Sections then there are none.
The Cover Texts are certain short passages of text that are listed, as Front-Cover Texts or
Back-Cover Texts, in the notice that says that the Document is released under this License.
A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25
words.
A Transparent copy of the Document means a machine-readable copy, represented in
a format whose specification is available to the general public, that is suitable for revising
the document straightforwardly with generic text editors or (for images composed of pixels)
generic paint programs or (for drawings) some widely available drawing editor, and that
is suitable for input to text formatters or for automatic translation to a variety of formats
suitable for input to text formatters. A copy made in an otherwise Transparent file format
whose markup, or absence of markup, has been arranged to thwart or discourage subsequent
modification by readers is not Transparent. An image format is not Transparent if used for
any substantial amount of text. A copy that is not Transparent is called Opaque.
Examples of suitable formats for Transparent copies include plain ASCII without markup,
Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD,
and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats

76

include proprietary formats that can be read and edited only by proprietary word processors,
SGML or XML for which the DTD and/or processing tools are not generally available, and
the machine-generated HTML, PostScript or PDF produced by some word processors for
output purposes only.
The Title Page means, for a printed book, the title page itself, plus such following pages
as are needed to hold, legibly, the material this License requires to appear in the title page.
For works in formats which do not have any title page as such, Title Page means the text
near the most prominent appearance of the works title, preceding the beginning of the body
of the text.
A section Entitled XYZ means a named subunit of the Document whose title either
is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in
another language. (Here XYZ stands for a specific section name mentioned below, such
as Acknowledgements, Dedications, Endorsements, or History.) To Preserve
the Title of such a section when you modify the Document means that it remains a section
Entitled XYZ according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this
License applies to the Document. These Warranty Disclaimers are considered to be included
by reference in this License, but only as regards disclaiming warranties: any other implication
that these Warranty Disclaimers may have is void and has no effect on the meaning of this
License.

2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying
this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to
obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly
display copies.

3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of
the Document, numbering more than 100, and the Documents license notice requires Cover
77

Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both
covers must also clearly and legibly identify you as the publisher of these copies. The front
cover must present the full title with all words of the title equally prominent and visible.
You may add other material on the covers in addition. Copying with changes limited to the
covers, as long as they preserve the title of the Document and satisfy these conditions, can
be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the
first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto
adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100,
you must either include a machine-readable Transparent copy along with each Opaque copy,
or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a
complete Transparent copy of the Document, free of added material. If you use the latter
option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated
location until at least one year after the last time you distribute an Opaque copy (directly or
through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before
redistributing any large number of copies, to give them a chance to provide you with an
updated version of the Document.

4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of
sections 2 and 3 above, provided that you release the Modified Version under precisely this
License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition,
you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in
the History section of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the
principal authors of the Document (all of its principal authors, if it has fewer than five),
unless they release you from this requirement.
78

C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public
permission to use the Modified Version under the terms of this License, in the form
shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover
Texts given in the Documents license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled History, Preserve its Title, and add to it an item stating
at least the title, year, new authors, and publisher of the Modified Version as given
on the Title Page. If there is no section Entitled History in the Document, create one
stating the title, year, authors, and publisher of the Document as given on its Title Page,
then add an item describing the Modified Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a
Transparent copy of the Document, and likewise the network locations given in the
Document for previous versions it was based on. These may be placed in the History
section. You may omit a network location for a work that was published at least four
years before the Document itself, or if the original publisher of the version it refers to
gives permission.
K. For any section Entitled Acknowledgements or Dedications, Preserve the Title
of the section, and preserve in the section all the substance and tone of each of the
contributor acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their
titles. Section numbers or the equivalent are not considered part of the section titles.
M. Delete any section Entitled Endorsements. Such a section may not be included in
the Modified Version.
N. Do not retitle any existing section to be Entitled Endorsements or to conflict in title
with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as
Secondary Sections and contain no material copied from the Document, you may at your
option designate some or all of these sections as invariant. To do this, add their titles to

79

the list of Invariant Sections in the Modified Versions license notice. These titles must be
distinct from any other section titles.
You may add a section Entitled Endorsements, provided it contains nothing but endorsements of your Modified Version by various partiesfor example, statements of peer review
or that the text has been approved by an organization as the authoritative definition of a
standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to
25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version.
Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity. If the Document already includes a cover
text for the same cover, previously added by you or by arrangement made by the same entity
you are acting on behalf of, you may not add another; but you may replace the old one, on
explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission
to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under
the terms defined in section 4 above for modified versions, provided that you include in the
combination all of the Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its license notice, and that you
preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical
Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections
with the same name but different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original author or publisher of that
section if known, or else a unique number. Make the same adjustment to the section titles in
the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled History in the various original documents, forming one section Entitled History; likewise combine any sections
Entitled Acknowledgements, and any sections Entitled Dedications. You must delete all
sections Entitled Endorsements.

6. COLLECTIONS OF DOCUMENTS
80

You may make a collection consisting of the Document and other documents released
under this License, and replace the individual copies of this License in the various documents
with a single copy that is included in the collection, provided that you follow the rules of this
License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually
under this License, provided you insert a copy of this License into the extracted document,
and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent
documents or works, in or on a volume of a storage or distribution medium, is called an
aggregate if the copyright resulting from the compilation is not used to limit the legal rights
of the compilations users beyond what the individual works permit. When the Document is
included in an aggregate, this License does not apply to the other works in the aggregate
which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document,
then if the Document is less than one half of the entire aggregate, the Documents Cover Texts
may be placed on covers that bracket the Document within the aggregate, or the electronic
equivalent of covers if the Document is in electronic form. Otherwise they must appear on
printed covers that bracket the whole aggregate.

8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the
Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some
or all Invariant Sections in addition to the original versions of these Invariant Sections. You
may include a translation of this License, and all the license notices in the Document, and
any Warranty Disclaimers, provided that you also include the original English version of this
License and the original versions of those notices and disclaimers. In case of a disagreement
between the translation and the original version of this License or a notice or disclaimer, the
original version will prevail.
If a section in the Document is Entitled Acknowledgements, Dedications, or History, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION
81

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the
Document is void, and will automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this License will not have their
licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present
version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document
specifies that a particular numbered version of this License or any later version applies to
it, you have the option of following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the Free Software Foundation.
If the Document does not specify a version number of this License, you may choose any
version ever published (not as a draft) by the Free Software Foundation.

ADDENDUM: How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the
document and put the following copyright and license notices just after the title page:

c YEAR YOUR NAME. Permission is granted to copy, distribute

Copyright
and/or modify this document under the terms of the GNU Free Documentation
License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the with
. . . Texts. line with this:

with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover
Texts being LIST, and with the Back-Cover Texts being LIST.

82

If you have Invariant Sections without Cover Texts, or some other combination of the
three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing
these examples in parallel under your choice of free software license, such as the GNU
General Public License, to permit their use in free software.

83

Referencias
[CAP14] Programacin por capas.
https://es.wikipedia.org/wiki/Programaci%C3%
B3n por capas consultado el 13 de junio de 2014, 2014.
[CRE11] The DNEWS editors. First Computer Virus, Creeper, Was No Bug. http://news.
discovery.com/tech/first-computer-virus-creeper-was-no-bug-110316.htm ltima comprobacin 17 de marzo de 2014., 2011.
[Div10] Computer Security Division. SP 800-37: Guide for Applying the Risk Management
Framework to Federal Information Systems. National Institute of Standards and
Technology, 2010.
[DK11] Devon Kearns y Mati Aharoni David Kennedy, Jim OGorman. Metasploit: The
Penetration Testers Guide. William Pollock, 2011.
[EW10] Matthew Ganis Elizabeth Woodward, Steffan Surdek. A Practical Guide to Distributed Scrum. IBM Press, Pearson plc, 2010.
[EXP14] API Reference of Jade. http://expressjs.com/3x/api.html consultado el 13 de
junio de 2014, 2014.
[JAD14] Language Reference of Jade. http://jade-lang.com/reference/ consultado el 13
de junio de 2014, 2014.
[kal]

Manual Kali Linux. Web oficial: http://es.docs.kali.org/ consultado el 17 de Marzo de 2014.

[KS07] Carl Kessler y John Sweitzer. Outside-in Software Development: A Practical Approach to Building Successful Stake-holder-Based Products. IBM Press, 2007.
[L.10]

Garcia L. Metodologa OSSTMM. http://www.securitybydefault.com/2010/03/

metodologia-osstmm.html ltima comprobacin 06 de junio de 2014., 2010.

[Mar12] J. Martnez de Sousa. Succeding with Agile. Software development using Scrum.
Addison-Wesley, 2012.
[MON14] Mongoose: elegant MongoDB object modeling for Node.js. http://mongoosejs.
com/docs/guide.html consultado el 13 de junio de 2014, 2014.
84

[NMA] Manual NMAP. Web oficial: http://nmap.org/man/es/ consultado el 17 de Marzo

de 2014.
[OS07] Bryan OSullivan. Control Distribuido de Revisiones con Mercurial. 2007.
[OSS11] Manual de la Metodologa Abierta de Testeo de Seguridad (OSSTMM).
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/551 ltima comprobacin 17 de Mayo de 2014., 2011.
[P.03]

Herzog P. OSSTMM 2.1 Manual de la Metodologa Abierta de Testeo de Seguridad.

2003.

[Pal14] Juan Palacio. Scrum Manager I: Las reglas de Scrum. Addison-Wesley, 2014.
[PGP]

Chema Alonso Pablo Gonzlez Prez. Metasploit para Pentesters. 0xWORD,

edicin 2.

[PL06] Ma Carmen Penads Patricio Letelier. Mtodologas giles para el desarrollo

de software: eXtreme Programming. http://www.cyta.com.ar/ta0502/b v5n2a1.
htm#1 consultado el 13 de mayo de 2014, 2006. Universidad Politcnica de Valencia, Spain.
[PSJ09] P. Prez San-Jos, C. Gutirrez Borge, E. lvarez Alonso, L. Garca Prez, y
S. de la Fuente Rodrguez. Inteco: Estudio sobre seguridad de la informacin y continuidad de negocio en las pymes espaolas. www.inteco.es/file/
Sp61c9ljOlMT7jcjbxYNVQ ltima comprobacin 5 de junio de 2014., 2009.
[Rap13] VVAA Rapid7. Metasploit: Remote API User Guide. https://community.rapid7.
com/docs/DOC-1516 ltima consulta 1 de mayo de 2014s, 2013.
[Rau12] Guillermo Rauch. Smashing Node.js. Javascript Everywhere. 2012.
[Sch95] K. Schwaber. SCRUM Development Process. OOPSLA95 Workshop on Business
Object Design and Implementation. http://www.tiac.net/users/jsuth/oopsla/
oo95summary.html consultado el 13 de mayo de 2014, 1995.
[Scr]

Medio scrum. http://es.wikipedia.org/wiki/Medio scrum consultado el 13 de mayo de 2014.

[Seca]

Offensive Security. Metasploit Unleashed. http://www.offensive-security.com/

metasploit-unleashed/Requirements.

[Secb]

Panda
Security.
Barmetro
Internacional
de
Seguridad
en
PYMEs.
http://www.pandasecurity.com/NR/
rdonlyres/9A6054F7-7C2F-4CFB-9A83-315BA2072B35/0/

85

01PF Barometro Seguridad PYMEs Ejemplo.pdf

17 de marzo de 2014.

ltima

comprobacin

[Sin12] Abhinav Singh. Metasploit Penetration Testing Cookbook. Packt Publishing, 2012.
[SOC14] Docs for Socket.io. http://socket.io/docs/ consultado el 13 de junio de 2014,
2014.
[SSCO08] K. Scarfone, M. Souppaya, A. Cody, y A. Orebaugh. SP 800-115:Technical Guide to Information Security Testing and Assessment. National Institute of Standards
and Technology, 2008.
[VVA11] VVAA.
Las TIC en las empresas espaolas.
DescargarDocumento.aspx?idd=4219 pg. 100, 2011.

86

www.ametic.es/

Este documento fue editado y tipografiado con LATEX

empleando la clase esi-tfg que se puede encontrar en:
https://bitbucket.org/arco group/esi-tfg
[Respeta esta atribucin al autor]

87