Mòdul 4: Monitoratge d'Activitat i Auditories de Xarxa
Intercepció de trànsit mòbil, proxies, gestió de certificats i validació de comunicacions segures (MASVS-NETWORK).
Fonaments de la Intercepció de Trànsit
Interceptar l'activitat de xarxa d'un mòbil és possible des del moment en què l'aplicació s'executa. Tot i que els protocols segurs (HTTPS/TLS) estan dissenyats per evitar-ho, un auditor pot configurar un entorn controlat per "trencar" aquesta privacitat de forma legítima.
🏷️ Server Name Indication (SNI)
Fins i tot en comunicacions xifrades, el nom del servidor (URL) pot ser visible en el primer paquet de la connexió (el Client Hello de TLS). Sense desxifrar el trànsit, un observador pot saber a quin servidor es connecta l'app, però no el contingut de la comunicació.
Implicació: Un tallafoc corporatiu pot filtrar per domini sense necessitat de desxifrar res.
🏛️ Certificats i Autoritats de Certificació (CA)
La confidencialitat de l'HTTPS depèn de la confiança en les CA. El teu dispositiu porta una llista de CAs de confiança integrada al sistema. Si aconseguim que el mòbil confiï en la nostra pròpia CA, podrem actuar d'intermediaris i desxifrar tot el trànsit.
Això és exactament el que fa un proxy d'auditoria: generar els seus propis certificats i signar-los amb la seva CA.
Atac Man-in-the-Middle (MitM)
Aquest és el model d'atac subjacent. Un MitM es col·loca entre el client i el servidor, interceptant i potencialment modificant les comunicacions. En un context d'auditoria, és una tècnica legítima i controlada; en mans d'un atacant, és una vulnerabilitat crítica.
L'Ús de Proxies de Comunicació
Un Proxy actua com un intermediari entre el dispositiu (client) i el servidor real. Quan el mòbil envia una sol·licitud, aquesta passa primer pel proxy, que la pot registrar, inspeccionar, modificar o bloquejar abans de reenviar-la al destí.
ZAP — Zed Attack Proxy
Eina gratuïta i de codi obert desenvolupada per OWASP. Ideal per a auditories i aprenentatge. Disposa d'escàner automàtic de vulnerabilitats, spider web i interceptor de peticions.
Burp Suite
Eina professional (amb versió Community gratuïta) molt utilitzada en pentesting real. Ofereix control granular sobre cada petició HTTP/S, un repetidor de peticions i eines d'anàlisi avançades.
mitmproxy
Proxy de codi obert orientat a la línia de comandes i a la automatització. Molt usat en entorns de CI/CD per validar les comunicacions d'una app de forma programàtica.
El diagrama mostra la posició del proxy dins del flux de comunicació. A l'esquerra hi ha el dispositiu mòbil o navegador que genera les peticions. Al centre, la màquina auditora amb ZAP o Burp Suite corrent actua d'intermediari: rep la petició, la registra i la analitza, i la reenvía al servidor real de l'aplicació web que hi ha a la dreta. La resposta del servidor fa el camí invers. Cap dels dos extrems sap que hi ha un intermediari al mig.
Configuració d'una Auditoria de Xarxa
Configurar un mòbil per ser auditat és més complex que configurar un navegador de PC. El mòbil i l'ordinador han d'estar a la mateixa xarxa WiFi i cal seguir uns passos concrets:
Preparació de l'entorn
Usar un emulador d'Android Studio (Android Virtual Device) o un dispositiu físic connectat a la mateixa xarxa WiFi que l'ordinador amb el proxy. L'emulador facilita la instal·lació de certificats sense restriccions de fabricant.
Configuració del Proxy al WiFi
Dins dels ajustos de la xarxa WiFi del mòbil, cal configurar manualment la IP
de l'ordinador i el Port del proxy (per defecte: ZAP
usa el port 8080, Burp Suite el 8080 o 8081).
Tota la resposta HTTP/S passarà per aquí.
Descàrrega del Certificat del Proxy
Des del mòbil, es navega a una URL especial del proxy (ex: http://zap/ o
http://burpsuite/) que serveix el seu certificat arrel en format
.cer o .pem per descarregar-lo.
Instal·lació de la CA al Dispositiu
Es va a Configuració → Seguretat → Instal·lar certificat i s'instal·la el fitxer descarregat. Un cop instal·lat, el mòbil "confia" en el proxy com si fos una CA legítima, i deixarà que desxifri les comunicacions.
La captura mostra la pantalla de gestió de certificats d'Android, concretament la pestanya "User" (certificats instal·lats per l'usuari, en contrast amb els del sistema). Es veu el certificat de ZAP llistat amb el seu nom. El fet que aparegui en aquesta pestanya i no a la de "System" és clau: Android diferencia clarament entre els certificats del fabricant (en els quals totes les apps confien) i els de l'usuari (en els quals les apps modernes no confien per defecte).
Gestió de Certificats en Android
Android gestiona els certificats en dos grups ben diferenciats amb nivells de confiança molt diferents:
🏛️ Certificats Arrel del Sistema (System)
Venen integrats en la imatge del sistema operatiu, gestionats per Google i el fabricant del dispositiu. Estan protegits pel Verified Boot: l'usuari no els pot modificar ni afegir-ne de nous al grup del sistema sense fer root al telèfon.
- ✅ Totes les apps hi confien per defecte.
- ✅ Inclouen CAs com DigiCert, Let's Encrypt, Google Trust Services.
- ❌ Immutables sense root.
👤 Certificats d'Usuari (User)
Són els que instal·lem per fer auditories. Qualsevol usuari els pot instal·lar i desinstal·lar lliurement. El navegador Chrome hi confia, però les aplicacions d'usuari no hi confien per defecte.
- ✅ Fàcils d'instal·lar sense permisos especials.
- ✅ Útils per auditar trànsit web al navegador.
- ❌ Les apps natives modernes els ignoren.
La pantalla mostra els detalls interns d'un certificat digital instal·lat com a CA d'usuari. Es pot llegir el camp Emès per (l'entitat que l'ha signat, en aquest cas el proxy ZAP), la clau pública associada, l'algorisme de signatura (normalment SHA-256 amb RSA) i el període de validesa. Entendre aquests camps és fonamental per verificar que el certificat instal·lat és el correcte i no un de fraudulent.
Restriccions Modernes i Seguretat d'Android
Amb el temps, Android ha tancat progressivament les portes a la intercepció de dades per protegir els usuaris d'atacs reals. Això dificulta les auditories però és una mesura de seguretat crítica:
TLS per defecte (Android 9, API 28+)
Des d'Android 9 Pie, les comunicacions en text pla (HTTP) estan
prohibides per defecte. Si una app intenta fer una connexió HTTP sense xifrar, el
sistema llança una IOException de seguretat i talla la conexió abans
que surti del dispositiu.
Desconfiança en CAs d'Usuari (Android 7, API 24+)
Les aplicacions modernes ignoren per defecte els certificats que
l'usuari instal·la manualment. Si intentem interceptar el trànsit d'una app com
Instagram o d'un banc, veurem un error de tipus SSLHandshakeException:
l'app detecta que el certificat del proxy no és del sistema i talla la connexió.
Configuració Expressa: network_security_config.xml
Perquè una app es deixi auditar, el desenvolupador ha d'afegir explícitament un fitxer de configuració de seguretat de xarxa que declari la confiança en CAs d'usuari per a builds de debug:
<network-security-config>
<debug-overrides>
<trust-anchors>
<certificates src="user"/>
</trust-anchors>
</debug-overrides>
</network-security-config>
La captura mostra el missatge d'error que apareix —bé en el log de l'app (Logcat) o bé en
pantalla— quan l'aplicació intenta establir una connexió TLS i detecta que el certificat
presentat no prové d'una CA de confiança del sistema. L'excepció típica és
javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
Aquest missatge confirma que les defenses de l'app funcionen correctament i que la intercepció
directa no és possible sense modificar-la.
Validació de l'Audit
Un cop superades les barreres de confiança (instal·lant la CA i configurant l'app en mode debug), el proxy registrarà totes les peticions. L'auditor pot analitzar el trànsit captat per detectar vulnerabilitats crítiques:
Credencials exposades
Verificar si contrasenyes, tokens o claus d'API s'envien en la URL (paràmetre GET), en lloc del cos de la petició (POST xifrat). Les URLs es guarden als logs dels servidors i als historials del navegador.
Dades personals sense xifrar
Detectar si les dades personals (nom, adreça, número de targeta) viatgen en text pla o amb un xifrat feble que no compleix els estàndards GDPR/PCI-DSS.
Manipulació de Respostes
Modificar una resposta del servidor en temps real per comprovar si l'app valida la integritat de les dades. Exemples: canviar el preu d'un producte, modificar el rol d'un usuari o alterar el resultat d'una validació de pagament.
La interfície de ZAP mostra en temps real totes les peticions HTTP/S generades pel dispositiu
mòbil. Al panell esquerre hi ha l'arbre de dominis i URLs contactats. Al panell central, la
llista de peticions capturades amb el mètode (GET, POST...), la URL
completa, el codi de resposta i la mida. Seleccionant qualsevol petició, els panells inferiors
mostren la capçalera i el cos tant de la petició com de la resposta en text
llegible, permetent a l'auditor examinar les dades sensibles que l'app transmet.
Certificate Pinning: la darrera barrera
Les apps molt sensibles (banca, salut) implementen Certificate Pinning: l'app porta "gravada" la clau pública del servidor al qual s'ha de connectar i refusa qualsevol altre certificat, fins i tot una CA del sistema. Saltar-se el pinning requereix modificar el bytecode de l'app amb eines com Frida o objection.