Seguretat de les aplicacions mòbils: Com garantir-la?

Què busquen els atacants en els nostres dispositius mòbils?

• Accés a credencials
• Dades personals (adreces, dades de targeta de crèdit, localització…)
• Accedir al magatzem de dades de l'aplicació
• Realitzar enginyeria inversa, per localitzar vulnerabilitats, credencials embegudes o algorismes que generin claus
• Instal·lació de malware o bloqueig de funcions existents
• Accedir al dispositiu i controlar les connexions
• Etc.

Com podem observar, dotar la nostra aplicació de mecanismes de seguretat que impedeixin realitzar les accions anteriors es converteix en quelcom imprescindible.

Blindatge en aplicacions mòbils: per què no és l'habitual?

La principal raó és que els desenvolupadors fan èmfasi en que aquestes funcionin correctament i en una gamma àmplia de dispositius, que compleixin amb tots els requisits definits… i es focalitzen sobretot en aspectes més atractius per a l'usuari com són la usabilitat, l'experiència d'usuari i la interfície gràfica.

Tanmateix, l'essencial és que siguem conscients que implementar mecanismes de seguretat en una aplicació mòbil és igual d'important, sobretot tenint en compte el gran volum d'usuaris que poden fer ús de la mateixa.

De fet, cada vegada són més les empreses les aplicacions de les quals han de passar per un procés de hacking ètic, que tracta de hackejar un sistema i identificar i reparar possibles vulnerabilitats, la qual cosa prevé eficaçment l'explotació per hackers maliciosos.

Mesures bàsiques en seguretat per a aplicacions mòbils

Quan fem el nostre desenvolupament mòbil, hem de posar el focus en diverses àrees i complir una sèrie de requisits en cadascuna d'elles. Per a això, podem basar-nos en l'estàndard de seguretat d'aplicacions mòbils OWASP, que s'encarrega de preveure requeriments per a arquitectes i desenvolupadors de programari que busquen desenvolupar aplicacions mòbils segures.

Aquesta guia defineix 2 nivells de verificació de seguretat, així com un conjunt de requisits de resistència a la enginyeria inversa.

La elecció del nivell dependrà del context de la nostra aplicació. El nivell L1 conté requeriments genèrics de seguretat recomanats per a totes les aplicacions mòbils. El següent nivell, L2, està enfocat a apps que manegen dades altament sensibles (sector financer, indústria de la salut).

A continuació especifiquem els requeriments de seguretat més destacables que hauríem de tenir en compte en el desenvolupament de la nostra aplicació categoritzats en set àrees, si bé podem trobar el llistat complet en la pròpia guia OWASP:

Emmagatzematge de dades i privacitat

La protecció de dades sensibles, com credencials i informació privada és, a més d'un imperatiu legal, un aspecte crític en la seguretat mòbil.

Alguns dels requisits que permeten prevenir l'accés a aquesta informació són els següents:

• No guardar informació sensible en l'emmagatzematge local del dispositiu, i en cas de ser necessari, aquesta ha de ser xifrada usant una clau derivada del maquinari d'emmagatzematge segur, el qual requereix autenticació prèvia.
• No escriure informació sensible als logs del sistema ni en còpies de seguretat.
• No exposar informació sensible com contrasenyes o números de targeta a través de la IU (interfície d'usuari) o captures de pantalla, i desactivar la memòria cau del teclat en els camps de text que contenen aquesta informació.

Ús de claus criptogràfiques

A l'hora de poder protegir la informació sensible emmagatzemada en el nostre dispositiu, la criptografia és un component fonamental. A l'hora de fer ús de claus criptogràfiques hem de tenir en compte els següents requisits:

• No dependre únicament de criptografia simètrica les claus de la qual es trobin directament en el codi font de l'app.
• No reutilitzar una mateixa clau criptogràfica per a diversos propòsits.
• Els valors aleatoris són generats utilitzant un generador de números aleatoris prou segur.

Autenticació i control de sessions

Perquè una aplicació sigui segura, ha de comptar amb un mecanisme d'autenticació i control de la sessió d'usuari. Tot i que és cert que la majoria d'aquesta lògica es troba al costat servidor, a continuació indiquem alguns requisits que hem de tenir en compte:

• La autenticació biomètrica, si n'hi ha, no està associada a esdeveniments (p. ex. usant una API que simplement retorna “true” o “false”), sinó basada en el desbloqueig del keychain/keystore (emmagatzematge segur).
• Per a aplicacions que gestionen informació molt sensible, aplicar mecanismes de doble factor d'autenticació.
• Les sessions i els tokens han d'expirar passat un temps predefinit d'inactivitat per part de l'usuari.

Comunicació amb serveis

Un aspecte important en les apps, és garantir la seguretat en la comunicació amb el servidor, assegurant la confidencialitat i integritat de les dades intercanviades. Per a això, alguns requisits són:

• La informació és enviada xifrada utilitzant el protocol TLS.
• L'aplicació verifica el certificat X.509 del sistema remot en establir el canal segur i només s'accepten certificats signats per una CA de confiança.
• L'aplicació utilitza el seu propi magatzem de certificats o realitza pinning del certificat o la clau pública del servidor.

Interacció amb la plataforma mòbil

La interacció entre les aplicacions i els sistemes operatius s'ha de dur a terme tenint en compte els següents aspectes:

• La app requereix la quantitat de permisos mínimament necessària.
• L'aplicació no exposa cap funcionalitat sensible a través de mecanismes IPC tret que aquests mecanismes estiguin degudament protegits
• Deshabilitar JavaScript dels Webviews tret que sigui necessari.
• Les WebViews es configuren per permetre el mínim dels esquemes (idealment, només https). Esquemes perillosos com file, tel i app-id estan deshabilitats.

Qualitat del codi

Tot i que les apps no són tan vulnerables a atacs de tipus Cross-Site Scripting, els desenvolupadors han de seguir una guia de bones pràctiques perquè el codi sigui segur:

• L'aplicació ha de ser signada i proveïda amb un certificat vàlid, així com ser publicada en mode release.
• L'aplicació captura i gestiona degudament les possibles excepcions.
• Les funcionalitats de seguretat gratuïtes de les eines, com ara minificació del byte-code, protecció de la pila, suport PIE i recompte automàtic de referències, es troben activades.
• Fer ús d'eines que permetin analitzar el codi font per detectar possibles vulnerabilitats com per exemple SonarQube.

Mecanismes contra la manipulació i enginyeria inversa

Hem d'evitar que un atacant pugui manipular la nostra aplicació o realitzar la enginyeria inversa del codi. Per a això, existeixen diversos mecanismes que s'han d'implementar:

• Signatura de l'aplicació: Una de les tècniques de seguretat més importants en Android és la signatura de les aplicacions utilitzant claus públiques i privades.

A l'hora de compilar una aplicació amb tots els elements que la componen (textos, gràfics, codi…) cada desenvolupador ha d'assegurar-la amb el seu certificat perquè la signatura identifiqui l'aplicació i sigui possible saber si ha estat modificada o es manté intacta. Aquesta és l'única manera de saber si una app és falsa o és autèntica: en el cas que s'hagi modificat la signatura, de tenir-la, no es correspondrà amb el desenvolupador original.

• Anti-Tamper: Les tècniques anti-tamper dificulten que un atacant pugui modificar un programari, realitzant enginyeria inversa i validant la seva integritat per al seu posterior ús modificat. Per a això, es verifica que la signatura de l'aplicació sigui l'original i s'apliquen mecanismes de comprovació del checksum.
• Ofuscació del codi: L'ofuscació del codi permet compactar, optimitzar i fer il·legible el codi reanomenant semànticament classes, camps, mètodes i noms. El resultat és una aplicació més petita i complexa de realitzar enginyeria inversa sobre ella, dificultant la comprensió dels mateixos davant els ulls maliciosos.
• Verificació de l'origen de l'instal·lador: Amb aquesta tècnica es comprova que l'aplicació ha estat distribuïda des de l'origen fiable, evitant que tinguem al nostre terminal una còpia de l'apk que hagi pogut ser infectada amb malware.
• Anti-Debug: Les tècniques anti-debug dificulten o detecten la depuració d'una aplicació, amb l'objectiu de poder aplicar determinades accions que evitin que un atacant continuï amb el procés. El mecanisme més senzill és a través d'una propietat en el propi manifest de l'app, si bé es recomana comprovar dinàmicament i en diversos punts si la depuració està tenint lloc o no.
• Anti-Emulador: Si la nostra aplicació s'està executant en un emulador fora del procés de desenvolupament, indica que algú més que nosaltres està intentant analitzar l'aplicació. Per això, una bona pràctica és comprovar que en una versió release, no s'està accedint a l'aplicació mitjançant un emulador que faciliti atacar la seguretat de la mateixa.
• Anti-Root: S'ha d'evitar sempre que sigui possible que una aplicació s'executi en terminals rootejats, ja que són terminals molt més vulnerables i que permeten accés a la memòria reservada del sistema i de l'aplicació, comprometent la persistència i per tant la privacitat de les dades que es gestionen.
• Anti-Clone: mecanisme per evitar que l'aplicació pugui ser clonada, en aquest sentit es definiran les propietats adequades per evitar fer una còpia de l'aplicació instal·lada i obtenir el binari que un possible atacant podria utilitzar per aplicar tècniques d'enginyeria inversa.
• Dispositiu fiable: Google disposa d'una API anti-abús (SafetyNet Attestation API), permet avaluar si el dispositiu Android en el qual s'executa una aplicació és fiable.

Conclusió

Cada dia fem ús de més aplicacions mòbils i cada vegada aquestes emmagatzemen una major quantitat d'informació sensible de l'usuari. Per això és molt important estar al dia sobre noves mesures de seguretat que vagin sorgint, i aplicar-les de manera proactiva sobre els nostres desenvolupaments. L'objectiu no ha de ser només que l'usuari interactuï amb una bona UX, sinó que també ho faci amb total seguretat.

“Ser conscient de les vulnerabilitats és ja la meitat de la seguretat”.