SEGURETAT EN SISTEMES INFORMÀTICS.SESSIÓ DE LABORATORI

Vulnerabilitat en Aplicacions WEB

ÍNDEX

1.OBJECTIUS DE LA SESSIÓ........................................................................................................22.PREPARACIÓ DE L’ENTORN.....................................................................................................4

2.1  Arrancar el LiveCD.................................................................................................................................42.2 Configurar l'idioma del teclat..................................................................................................................42.3 Iniciar l’aplicació WebScarab..................................................................................................................42.4 Configurar el navegador WEB.................................................................................................................62.5 Iniciar l’aplicació WebGoat.....................................................................................................................7

3.EXERCICIS.....................................................................................................................................83.1  Validació de paràmetres .........................................................................................................................8

3.1.1 Camps Ocults.........................................................................................................................................................83.1.2 Camps Ocults (correu no validat) .......................................................................................................................103.1.3 Evitar validacions en la part client......................................................................................................................123.1.4 Practiqueu............................................................................................................................................................15

3.2  Administració de sessions i autenticacions............................................................................................163.2.1 Autenticació mitjançant Cookies.........................................................................................................................16

3.3  Cross Site Scripting...............................................................................................................................183.4  SQL Injection........................................................................................................................................21

4.REFERENCIES ............................................................................................................................24

1. OBJECTIUS DE LA SESSIÓ

Les vulnerabilitats de les aplicacions o sistemes basats en la web, són les responsables de la majoria de violacions de seguretat en les xarxes. Cada vegada més, els atacs van més dirigits a aquestes aplicacions, com les compres per Internet, els formularis web, així com els punts d’autenticació i accés a pàgines web protegides per contrasenyes i continguts dinàmics procedents de bases de dades vinculades amb transaccions i peticions d’informació realitzades per un navegador.

Quan es parla de seguretat en les aplicacions web, s’ha de tenir en compte que no ens referim a problemes o vulnerabilitats en els sistemes operatius o servidors HTTP (actualització de versions, pegats, etc.) sinó a les vulnerabilitats que es troben en el propi programari. Aquestes vulnerabilitats es troben directament relacionades amb la lògica, l’escriptura del codi i el contingut de l’aplicació web.El conèixer aquestes vulnerabilitats ens proporciona evidentment més seguretat però també ens serveix per poder proporcionar més control i qualitat als nostres desenvolupaments.

L’objectiu de la present sessió és l’estudi d’algunes de les principals vulnerabilitats trobades en aplicacions WEB, estudiar algunes de les formes més bàsiques de realitzar els atacs i comprendre l’origen d’aquestes vulnerabilitats i com poden evitar­les. 

Per a realitzar aquesta sessió, ens basarem en les següents aplicacions:

- WebGoat   : És una aplicació J2EE desenvolupada per OWASP (The Open Web Application Security Project) i basada en Tomcat. Es tracta d’una aplicació insegura i aquesta és bàsicament la seva funció. L’objectiu és utilitzar­la com a introducció a diferents atacs dirigits a les aplicacions web (entorn de proves), consta de diferents lliçons en les quals es proporciona informació i ajuda per aprendre i aconseguir superar­les.

- WebScarab   : És un framework per l’anàlisi d’aplicacions web desenvolupat per OWASP. Treballa amb HTTP i HTTPS, es pot fer servir com a proxy, per estudiar les peticions i respostes de les pàgines, revisar­les i modificar­les abans que arribin al client o servidor.

- Aquestes dues aplicacions es poden trobar en un LiveCD anomenat OWASP Live CD Education Project (LabRat) v2.1, que serà el que utilitzarem.

Vulnerabilitats que veurem:

- Modificació de camps ocults:    Com obtenir informació addicional de les aplicacions web i modificar les peticions generades pel client o respostes del servidor per tal de realitzar l’atac.

- Identificació de sessió dèbils:    Veurem els perills que comporta una autenticació dèbil, en aquest cas com suplantar una identitat mitjançant la creació o modificació d’una cookie de sessió.

- Cross Site Scripting (XSS)   : És l’atac basat en l’explotació de vulnerabilitats del sistema de validació de HTML incrustat. Aprofita la falta de mecanismes de filtratge en els camps d’entrada, permeten l’entrada i enviament de dades sense cap validació, podent generar seqüències de comandes malicioses o scripts.

- SQL Injection:    És una vulnerabilitat en el nivell de la validació de les entrades a la base de dades d’una aplicació. L’origen és el filtrat incorrecte de les variables utilitzades en el codi de l’aplicació que utilitza sentencies SQL.

2. PREPARACIÓ DE L’ENTORN.

2.1  Arrancar el LiveCD.Al menú d'inici del LiveCD heu d'escollir l'opció d'arrencada amb mode gràfic. La primera opció que apareix servirà.

Un cop el LiveCD hagi arrencat s’han de seguir les següents passes:

2.2 Configurar l'idioma del teclatPer a configurar el teclat, anar a la barra d'eines, al marge inferior esquerre, i amb el botó dret feu clic sobre la bandera que s'hi troba. Accediu a Configure.

Apareixerà una pantalla com la que es veu a sota. Afegir la configuració del nostre teclat ­la espanyola­ a les actives, seleccionant­la i prement el botó Add. Prémer OK per a aplicar els canvis i tancar la finestra.

Activar la configuració que s'acaba d'afegir. Botó dret del ratolí sobre la bandera i seleccionar la desitjada.

2.3 Iniciar l’aplicació WebScarabEs pot iniciar prement sobre la icona de la barra d'eines on apareix un escarabat en blau, o bé, des del menú inici de KDE: Anar al menú OWASP liveCD WebScarab i prémer sobre WebScarab s’obrirà la pantalla següent:

S'iniciarà WebScarab amb totes les funcions, mostrant­se la següent pantalla: 

NOTA: Si no us apareixen tantes pestanyes al WebScarab, cal habilitar el mode complet, cosa que s'explica a continuació:

Depenent la versió de WebScarab, s’inicia amb una interfície amb poques funcions. Verificar que estan totes les funcions activades: anar al menú Tools i prémer sobre “Use full­featured interface”.

 Apareixerà el següent missatge indicant que s’ha de tornar a iniciar WebScarab  per   poder  veure totes les funcions de WebScarab

2.4 Configurar el navegador WEB1. Obrirem el navegador web i el configurarem per a que faci servir un proxy local, en aquest 

cas WebScarab, que fa servir el port 8008 per defecte.

a. Anar al menú Edit  Preferences... Advanced  Pestanya network  Connection Settings:

b. Configurem l’opció de proxy manual com s’indica a continuació, vigileu que al camp “No Proxy for” no s’indiqui “127.0.0.1” o “localhost”:

2.5 Iniciar l’aplicació WebGoat

Al menú inici de KDE: Anar al menú OWASP liveCD i prémer sobre Start WebGoat al port que es vulgui. Si tot va bé, s'obrirà una pestanya al navegador amb la pàgina d'inici de WebGoat, abans però apareixerà aquest missatge el qual s'ha d'acceptar per accedir a WebGoat:

NOTA: Si no s'obre la pestanya, proveu de tancar i obrir WebGoat de nou.

NOTA: Si la pestanya s'obre però apareix un error dient que no pot obrir la pàgina, espereu un moment, refresqueu­la, i assegureu­vos que l'adreça on aneu coincideix amb la següent: http://127.0.0.1/WebGoat/attack Carregar WebGoat pot tardar una estona, ja que ha d'iniciar el servidor web i carregar l'aplicació, és possible que per a aquest motiu la pàgina no es pugui carregar al primer intent.

Fet això, l'entorn ja està preparat per a la realització de la sessió.

3. EXERCICIS

3.1  Validació de paràmetres En aquest apartat veurem el perill que pot suposar no validar el paràmetres d’entrada d’una aplicació WEB o validar­los incorrectament. En l’apartat Unvalidated Parameters trobarem tres exercicis on podrem accedir a camps ocults, modificar paràmetres no validats i saltar validacions que s’executen a la part client.

3.1.1 Camps Ocults

Accediu a la lliçó “How to exploit Hidden Fields” de WebGoat. Com veureu, l’objectiu d’aquesta lliçó és realitzar la compra d’un producte per un preu inferior a l’indicat en la plana web.

Si observem la plana, veiem que el camp “Price” no és modificable. Feu diferents proves, prement “Update Cart” o “Purchase” o observant el codi prement “Show Java” per intentar modificar el preu del producte. Heu trobat alguna cosa?

Anem a observar la petició que es enviada al servidor quan intentem fer una compra, per això realitzeu les següents passes:

- Aneu a la pantalla de WebScarab i premeu la casella “Intercept Requests” dintre de “Manual Edit”:

- Un cop activada la intercepció de peticions, torneu a WebGoat i intenteu fer una compra (prement a “Purchase”).

- Apareixerà una nova finestra de WebScarab amb la petició que ha interceptat. Si ens fixem en la pestanya “URLEncoded” trobarem tres variables (QTY, SUBMIT, Price). Una d’aquestes variables fa referencia al preu de compra, intenteu modificar el preu a la columna “Value”, desactiveu la intercepció de peticions (prement de nou a la casella “Intercept  Requests” i premeu al botó “Accept Changes”.

­ Efectivament hem pogut modificar la petició enviada al servidor amb un preu diferent al indicat en la plana web.

3.1.2 Camps Ocults (correu no validat) 

Accediu a la lliçó “How to exploit Unchecked mail” de WebGoat. Com veureu, l’objectiu d’aquesta lliçó és poder canviar l’adreça de correu on s’envien els comentaris introduïts a la plana web. Feu diferents proves, introduint comentaris, enviant­los prement a “Send” o observant el codi prement “Show Java” per intentar modificar l’adreça de correu. Heu trobat alguna cosa?

Farem servir una altra funcionalitat de WebScarab que serveix per mostrar els camps ocults de la plana web (també es podria utilitzar la mateixa tècnica que en l’apartat anterior).

- Aneu a la pantalla de WebScarab i premeu a la pestanya “Miscellaneous” dins de “Proxy”. En aquesta pantalla haureu de prémer la casella “Reveal hidden fields in HTML pages”.

- A continuació, torneu a carregar la plana del navegador i veureu que ha aparegut nova informació a la plana:

- Aquesta opció de WebScarab ens ha permès descobrir un camp ocult i justament és el camp on s’indica l’adreça de correu. Que passa si el modifiqueu i premeu el botó “Send”?

- Hem aconseguit modificar l’adreça de correu i enviar els comentaris a un altra adreça. Torneu a WebScarab i desactiveu l’opció “Reveal hidden fields in HTML pages”.

3.1.3 Evitar validacions en la part client

Accediu a la lliçó “How to bypass Client Side JavaScript Validation” de WebGoat. Com veureu, l’objectiu d’aquesta lliçó és poder evitar la validació implementada en la part client de l’aplicació. 

La plana envia set valors al servidor, però aquests set valors han de complir  unes expressions regulars que són validades localment. Feu diferents proves, introduint valor incorrectes i correctes a cadascun dels camps, enviant­los prement a “Submit” o observant el codi prement “Show Java” per intentar trobar el codi que implementa les validacions dels camps. Heu trobat alguna cosa?

- Que passa si enviem valors incorrectes a tots els camps? Per exemple, un guió (­).

- Les dades han estat validades a la part client i no ens permet enviar­les al servidor. Mirant el codi, podeu trobat la secció que implementa la validació dels valors:

if (!pattern1.matcher(param1).matches()){err++;msg += "<BR>Server side validation violation: You succeeded for Field1.";}if (!pattern2.matcher(param2).matches()){err++;msg += "<BR>Server side validation violation: You succeeded for Field2.";}...if (err > 0){s.setMessage(msg);}

- Aquest codi es descarrega al fer la petició de la plana web. Intentem saltar aquesta validació:o Hem de modificar la configuració de WebScarab, ara ens interessa interceptar les 

respostes del servidor. A la pestanya “Proxy”, premeu a l’opció “Intercept Responses” i comproveu que la casella “Intercept Requests” no està activada.

o A continuació, refresqueu la pantalla del navegador per tornar a fer una petició de la plana web. Apareixerà una nova pantalla de WebScarab amb la resposta interceptada, si premem a la pestanya “Raw” de la meitat inferior de la finestra podrem veure tota la resposta que ens ha enviat el servidor. I en aquesta resposta trobarem el codi que fa la validació dels valors dels camps i que volem evitar.

o Editeu el codi i elimineu la part que fa la validació: Les línies entre (msg=’JavaScript... i (if (err >0 ...

o Desactiveu la casella “Intercept responses”o Premeu el botó “Accept Changes”, torneu a la plana web i premeu a “Submit” per 

enviar les dades al servidor amb valors incorrectes.

– Així doncs hem pogut eliminar la validació de la part client i enviar els valors incorrectes al servidor, modificant la resposta que envia el servidor quan es fa una petició de la plana web.

3.1.4 Practiqueu

Accediu a la lliçó “How to bypass a Fail Open Authentication Scheme” de l’apartat “Improper Error Handling” de WebGoat. I intenteu resoldré la lliçó amb les mateixes tècniques que hem vist als apartats anteriors, mostreu el resultat al professor.

3.2  Administració de sessions i autenticacions

3.2.1 Autenticació mitjançant Cookies

En aquest apartat veurem com les aplicacions utilitzen les cookies per mantenir la informació de sessió i com aquesta informació pot ser explotada per establir una sessió com un altre usuari sense saber­ne les seves credencials.

Accediu a la lliçó“Spoof an Authentication Cookie” de l'apartat Session Management Flaws de WebGoat. Com veureu, l’objectiu d’aquesta lliçó és poder establir una sessió com a l’usuari “Alice” sense saber­ne les seves credencials.Feu diferents proves, autenticant­vos a la plana web amb els usuaris “webgoat/webgoat” i “aspect/aspect” i refrescant la pantalla per a observar com la plana web fa servir la cookie per a validar i mantenir la sessió, observeu el codi prement “Show Java” per intentar alguna forma de establir la sessió com l’usuari “Alice”. Heu trobat alguna cosa?

Anem a observar el mecanisme que es fa servir per a l’autenticació mitjançant la cookie:- Inicieu la sessió amb l’usuari “webgoat”.- Activeu la casella “Intercept Request” de WebScarab i premeu a “Refresh”. S’obrirà una 

nova finestra de WebScarab amb la petició, observeu el valor de la Cookie.

- Desactiveu la casella “Intercept Requests” i premeu el botó “Accept Changes”.- Feu el mateix amb l’usuari “aspect” i observeu el valor de la cookie, compareu­lo amb el 

valor que heu vist per a l’usuari “webgoat”.

- Repetiu el procediment més vegades, observant sempre el valor de la cookie per a cadascun dels usuaris.

- El valor de la variable “AuthCookie” per a cadascun dels usuaris sempre és el mateix. Així doncs, podem pensar que si trobem la lògica amb la que es genera aquest valor podrem intentar modificar la cookie per a simular una sessió amb la identitat d’un altre usuari,

- Estudiem els valors per a cadascun:Usuari AuthCookiewebgoat 65432ubphcfxaspect 65432udfqtbAlice 65432?????

o Podem observar que el valor de la variable “AuthCookie” sempre comença amb “65432”, així que ens centrarem en la part que varia.

o Sembla que el nombre de caràcters del nom d’usuari està directament relacionat amb el codi generat:

webgoat 7 caràcters  upbhcfx 7 caràcters aspect 6 caràcters  udfqtb 6 caràcters alice 5 caràcters  sembla lògic pensar que seran 5 caràcters

o Ara toca fer un exercici de cap i veure si hi ha alguna relació entre els caràcters: El codi generat pels dos usuaris comença amb “u” però el nom d’usuari no 

comença amb el mateix caràcter, però si ens fixem sí que acaben els dos amb una “t”.

Intentem posar­ho en ordre invers:

Usuari AuthCookietaogbew ubphcfxtcepsa udfqtb

Ara només cal mirar­se una estona els caràcters per descobrir que, cadascun dels caràcters del nom d’usuari correspon a un caràcter més de l’alfabet de la paraula de la variable “AuthCookie”. Es tracta d’una variació del xifrat César o Caesar, un mètode de xifrat clàssic i molt bàsic en el que es realitza una substitució d’un caràcter per un altre caràcter, garantint sempre que la transformació de caràcters sigui bijectiva.

• t u, ab, op, gh, bc, ef, wx• tu, cd, ef, pq, st, ab

Així doncs podem intentar generar el codi per a l’usuari “alice”:

Usuari AuthCookiewebgoat 65432ubphcfxaspect 65432udfqtbalice 65432fdjmb

- Ara intentem enviar al servidor el valor de la variable “AuthCookie” modificat amb el codi que hem trobat per a l’usuari “alice”. Per això, inicieu una sessió amb l’usuari “webgoat” o “aspect”, activeu la casella “Intercept Requests” de WebScarab i premeu a “Refresh”.

- En la nova finestra de WebScarab amb la petició, modifiqueu el valor “AuthCookie” pel valor que hem calculat, desactiveu la casella “Intercept Requests” i premeu a “Accept Changes”.

- Com observareu, la plana dona la benvinguda a l’usuari “alice”. Per tant, modificant el valor de la cookie hem pogut establir una sessió amb un usuari del que no sabem les credencials.

3.3  Cross Site ScriptingEn aquest apartat veurem com aprofitar una vulnerabilitat dins d’un formulari, tot just aprofitant el que s’ha après en l’apartat anterior.

Accediu a la lliçó “LAB: Cross Site Scripting (XSS)” de WebGoat. Com veureu, l’objectiu d’aquesta lliçó és que l’aplicació serveixi un script desenvolupat per nosaltres a un altre usuari.

Feu diferents proves, autenticant­vos a la plana web amb diferents usuaris (la contrasenya és igual al nom de l’usuari), observant quines funcionalitats tenen i buscant com podem fer que s’executi un script quan un usuari accedeixi a una de les funcionalitats. Idees?

- Bàsicament es tracta d’una aplicació de recursos humans, en la que cada usuari pot consultar el seu perfil i els usuaris administradors poden fer consultes i actualitzacions sobre altres usuaris.

- Autentiqueu­vos a l’aplicació de recursos humans amb un usuari amb pocs privilegis, un empleat. Per exemple, “Tom Cat” amb contrasenya “tom”.NOTA: es podria fer també amb un usuari privilegiat, però es dona per suposat que aquest, de per si, ja podria tenir altres maneres d'obtenir la informació que pretén obtenir l'script.

- Seleccioneu l'usuari a la llista i premeu el botó “ViewProfile”.

- A continuació, modificarem un dels camps de l’usuari, afegint un script per tal que quan l’usuari, o altri, consulti el seu perfil s’executi.

o Afegiu el següent codi a un dels camps del perfil de l’usuari. Per exemple, al camp “Street”:

><script>alert(“Sessió Robada ” + document.cookie)</script>

o Premeu el botó “UpdateProfile” i “Logout”. 

- Per a comprovar si el nostre script s’executarà correctament, autentiqueu­vos a l’aplicació amb un altre usuari que tingui accés al perfil al que heu fet la modificació: ell mateix, un cap de recursos (hc) o un administrador (l'exemple és fet amb Jerry Mouse).

- Seleccioneu Tom Cat de la llista i premeu el botó “ViewProfile”:

- Comprovareu que l’aplicació ha servit aquest script a un altre usuari, així doncs hem aconseguit el nostre objectiu.

3.4  SQL Injection

En aquest apartat veurem com inserir sentencies SQL Arbitràries, dins una consulta prèviament establerta, amb l’objectiu de manipular els processos lícits d’una aplicació determinada.

Accediu a la lliçó “ String SQL Injection” de l'apartat “Injection Flaws” de WebGoat. Com veureu, l’objectiu d’aquesta lliçó és obtenir un llistat amb els números de les targetes de crèdit dels usuaris de la base de dades.

Feu diferents proves, introduint com a paràmetre “Smith” i altres valors, observeu els resultats al realitzar la consulta i estudieu com es modifica la sentència SQL que proporciona el llistat. 

Fixeu­vos que la consulta està esperant un valor que s’introduirà a la sentència SQL entre cometes simples, que podem fer per modificar la sentència SQL?

I si introduïm dues cometes simples sense cap altre valor?

La sentència SQL és correcte i no retorna cap resultat. Si introduïm només una cometa simple?

La sintaxi de la sentència SQL no és correcte, és necessari que hi hagi una cometa simple per indicar el començament d’un string i un altre per indicar el final del string. Sabent això i que la sentència SQL insereix una cometa simple al inici i un altre al final obligatòriament, hem de buscar un valor per posar­hi entremig que sigui sintàcticament correcte i que permeti modificar la sentència de forma que sempre sigui certa. 

- Afegiu el següent texte al camp “last_name” i executeu la consulta prement “Go!”o FIB’ or ‘1’=’1o El que estem fent és introduir qualsevol valor i tancar la primera cometa simple que 

introdueix la sentència SQL automàticament. A continuació hem de construir un valor que sempre que s’executi doni un resultat cert. Per exemple la comparació de dos strings exactes (‘1’=’1’), però tenint en compte que la sentència SQL introduirà de nou un altre cometa simple al final. Si afegim aquests dos valors amb un operand lògic OR, tenim com a resultat una consulta SQL que sempre s’avalua a cert i per tant retornarà tots els valors de la taula.

- Intenteu posar altres valors i construir altres sentencies SQL que sempre s’avaluïn a cert.

- Efectivament, la sentència SQL resultant sempre s’avalua a cert i ha retornat totes els números de les targetes de crèdit.

- En executar correctament la injecció de SQL, la sentència SQL ha estat modificada a WebGoat per una consulta parametritzada. Intenteu reproduir l’atac amb aquest tipus de consulta, podeu fer una injecció de SQL? Observeu les diferències entre els dos models de consulta SQL, podeu ajudar­vos del codi de la plana web prement a “Show Java”.

4. REFERENCIES 

- Projecte OWASP, http://www.owasp.org- Projecte OWASP a Sourceforge, http://sourceforge.net/projects/owasp- Web Application Security Consortium (WASC), http://www.webappsec.org- Common Vulnerabilities and Exposures (CVE), http://www.cve.mitre.org- http://www.faqs.org/rfcs/rfc2660.html   - http://www.faqs.org/rfcs/rfc2616.html   - http://www.faqs.org/rfcs/rfc1945.html   - Secure Coding: Principles & Practices, http://www.securecoding.org/