BlackBerry banning frenzy - proč nezakazovat Android/iPhone?

16.8.2010 23:41 | Přečteno: 2407× | programování | | poslední úprava: 17.8.2010 18:14

Nejspíš jste zaregistrovali, jak postupně více a více zemí se snaží zakázat/omezit komunikátor BlackBerry nebo se dohodnout s provozovatelem (Research In Motion - RIM). Saudská Arábie, Emiráty, Indie a další. Při čtení těchto zpráv mě zajímala otázka, proč je Android nebo iPhone "v pořádku"? iPhone nemám po ruce, ale podíval jsem se alespoň na Android.

Android attack vectors

Fakt, že se zmíňené státy "bojí" BlackBerry, znamená, že pro jiné telefony mají dostatečné technologické nebo politické páky. No-brainer páky:

• BlackBerry má vlastní messaging service, který je zašifrován end-to-end mezi telefonem a RIM servery (nevím momentálně jak spravují distribuci klíčů, nejspíš má každé zařízení od výroby svůj); naproti tomu pro obyčejné SMS/MMS/hovory stačí "pošťouchnout" lokálního operátora
• v "civilizovaných" zemích musí operátoři vysypat všechno (US - CALEA, EU - data retention apod.)
• zvláštní je, že se nikdo nepře s Google - vypadá to, že Google dá data každýmu, kdo si o ně řekne. Update:Etisalat (mobilní operátor v Emirátech) nepotřebuje ani spolupráci Google pro SSL MITM, viz můj komentář

Technická stránka - certifikáty

Ale k zajímavějším věcem - jak napadnout Android technologicky?

Vygenerování falešného SSL/TLS certifikátu s validním podpisem je složité pro běžného útočníka, nicméně pro vládu (která má dohodu s výrobcem/provozovatelem) to značí jen to, že mu musí systém (Android) věřit.

Seznam všech autorit lze z Androida přes Android SDK získat následovně (s Java SDK, Android SDK a bouncycastle provider bcprov-jdk16-141.jar):

#adb pull jsem zkousel na rootnutem telefonu (VillainROM 12 - upraveny HTC
#Android 2.1) a emulatoru, ale read-access je i na nerootnutem telefonu
adb pull /system/etc/security/cacerts.bks .

keytool -list -keystore cacerts.bks -storetype BKS \
    -provider org.bouncycastle.jce.provider.BouncyCastleProvider \
    -providerpath bcprov-jdk16-141.jar -storepass changeit | sort -n > cert_list

#v nasledovnich dvou prikazech ve for cyklu doplnit pocet certifikatu, jak to zobrazil
#predchozi prikaz ve vyslednim souboru cert_list

for I in {0..53}; do \
    keytool -export -keystore cacerts.bks -storetype BKS \
        -provider org.bouncycastle.jce.provider.BouncyCastleProvider \
        -providerpath bcprov-jdk16-141.jar -storepass changeit \
        -file $I.cer -alias $I; \
done

for I in {0..53}; do \
    echo $I; openssl x509 -in $I.cer -noout -text -inform DER | grep 'Subject';\
done

Seznam pak vypadá následovně (vygrepován jen subject kvůli délce):

OU=Copyright (c) 1997 Microsoft Corp., OU=Microsoft Corporation, CN=Microsoft Root Authority
OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
C=ES, L=C/ Muntaner 244 Barcelona, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068/emailAddress=ca@firmaprofesional.com
C=FR, O=Certplus, CN=Class 2 Primary CA
C=US, O=Digital Signature Trust, OU=DST ACES, CN=DST ACES CA X6
C=ES, O=FNMT, OU=FNMT Clase 2 CA
C=TW, O=Government Root Certification Authority
C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority
C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 2 CA/emailAddress=certificate@trustcenter.de
C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA
C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)
C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root
C=DE, O=Deutsche Telekom AG, OU=T-TeleSec Trust Center, CN=Deutsche Telekom Root CA 2
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN - DATACorp SGC
C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de
C=US, O=Equifax, OU=Equifax Secure Certificate Authority
C=HU, L=Budapest, O=NetLock Halozatbiztonsagi Kft., OU=Tanusitvanykiadok, CN=NetLock Uzleti (Class B) Tanusitvanykiado
C=BM, O=QuoVadis Limited, OU=Root Certification Authority, CN=QuoVadis Root Certification Authority
C=HU, L=Budapest, O=NetLock Halozatbiztonsagi Kft., OU=Tanusitvanykiadok, CN=NetLock Expressz (Class C) Tanusitvanykiado
C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root CA
C=PL, O=Unizeto Sp. z o.o., CN=Certum CA
C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network
C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2
L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 3 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance EV Root CA
C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 3
C=US, O=GTE Corporation, CN=GTE CyberTrust Root
C=JP, O=SECOM Trust.net, OU=Security Communication RootCA1
C=FI, O=Sonera, CN=Sonera Class2 CA
C=US, O=Entrust, Inc., OU=AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE, OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY, OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2008 Entrust, Inc., CN=Entrust Certification Authority - L1B
C=HU, ST=Hungary, L=Budapest, O=NetLock Halozatbiztonsagi Kft., OU=Tanusitvanykiadok, CN=NetLock Kozjegyzoi (Class A) Tanusitvanykiado
C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
C=US, O=America Online Inc., CN=America Online Root Certification Authority 1
C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
C=IL, ST=Israel, L=Eilat, O=StartCom Ltd., OU=CA Authority Dep., CN=Free SSL Certification Authority/emailAddress=admin@startcom.org
C=NL, O=Staat der Nederlanden, CN=Staat der Nederlanden Root CA
C=DK, O=TDC Internet, OU=TDC Internet Root CA
C=JP, O=Japan Certification Services, Inc., CN=SecureSign RootCA1
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com
C=ch, O=Swisscom, OU=Digital Certificate Services, CN=Swisscom Root CA 1
C=US, O=Equifax Secure Inc., CN=Equifax Secure eBusiness CA-1
C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure Server Certification Authority
C=EU, O=AC Camerfirma SA CIF A82743287, OU=http://www.chambersign.org, CN=Chambers of Commerce Root
L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 1 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
C=ES, ST=BARCELONA, L=BARCELONA, O=IPS Seguridad CA, OU=Certificaciones, CN=IPS SERVIDORES/emailAddress=ips@mail.ips.es
C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware

Jsou tam nějaké překvapení jako Taiwanská vládní CA nebo pro mě hodně podivný StartCom, nicméně tyto dva CA certifikáty jsou předinstalovány i ve Firefoxu (Windows 7 mají třeba by default taky StartCom, Opera ne, zase Opera i Android mají státní nizozemskou CA). Další trik spočíva v intermediate CAs, které de facto můžou podepsat libovolnou doménu, intermediate CAs mají Google, Microsoft a spousty dalších společností (technicky: stačí mít v basic constraints CA:true). Ale už jsme hodně odbočili; nicméně hlavní rozdíl mezi Androidem a browserem na který jsem chtěl poukázat je, že pro browser je mnohem jednodušší nainstalovat rozšíření typu Certificate Patrol nebo Perspectives, které dokáží podozřelé změny odhalit.

Android Market a GoogleTalk service

Ač se to nemusí zdát spojeno, Market a GoogleTalk mají hodně společného. Market ve skutečnosti funguje tak, že Market pošle request na instalaci aplikace, ale request není synchronní. Místo toho za nějaký čas obdrží out-of-band zprávu INSTALL_ASSET přes GoogleTalk, kde je určeno, co se má instalovat. Podobně existuje REMOVE_ASSET zpráva, která odinstaluje aplikaci.

REMOVE_ASSET již byla několikrát použita na odstranění malware (podobný mechanizmus má i iPhone). Důležitý detail je "out-of-band", což má za důsledek, že dokud GoogleTalk service na Androidu běží, je možné Googlem (nebo kýmkoli, kdo dokáže zfalšovat digitální podpis Googlu s využitím defaultních CA) způsobit instalaci nebo odstranění aplikace. Normálně uživatel o instalaci i odstranění dostane notifikaci, jenže to neznačí, že někde není option aby se to uživateli nezobrazovalo (Market a GoogleTalk není open-source součástí Androida).

GoogleTalk service jde přes menu v Androidu vypnout, ale spouští se přes Intent např. při spuštení Marketu. Místa, kde se spouští by bylo možné vysledovat přes logcat.

Co posíla Android při synchronizaci - mail, kalendář, GeoAPI

Komunikace Androidu se musí dumpovat přes nástroj jako airodump, z Android telefonu nelze (jednoduše) síťovat přes kabel. Wireshark umí dešifrovat WPA/WPA2-PSK, pokud znáte klíč (např. vlastní AP). I když jsem zpermutoval všechny možnosti nastavení Wiresharku, fungovalo mi to jenom na příkladu z návodu (kdyby někdo tušil proč, hodně by mě to zajímalo, jinak jsem musel na chvíli vypnout WPA, Wireshark žádné error hlášky nedal).

Ve zkratce: gmail komunikace je šifrována přes https, kalendář a GeoAPI nikoliv. Pro kalendář si aplikace přes gdata API zjistí authentication token (používá ClientLogin), ale data jdou pak bez šifrování přes http. Nejprve jsem myslel, že je to chyba HTC kalendáře, ale po googlení jsem zistil, že je to "defaultní" mód pro kalendář. I při přístupu přes desktop browser username/heslo jde přes https, ale zbytek přes http (tady je zvláštní, že když začnete přes https://calendar.google.com místo http://calendar.google.com, tak je většina komunikace přes https, zřejme si to někde v cookie poznamená). S authorization tokenem (viditelný v plain http) lze číst a modifikovat kalendář (jiné služby ne, protože název služby je součástí vytváření authorization tokenu).

GeoAPI: používá se pro určení přibližné pozice přes http://www.google.com/loc/m/api (neveřejné API), při wifi připojení posílá seznam viditelných wifi hotspotů (SSID a BSSID) se sílou signálu. Podle toho se určí pozice (Google nezveřejnil, odkud má informace o wifi AP, část z nich pochází ze StreetView vozů a část od "třetích stran"). Bez databáze wifi hotspotů není informace o viditelných AP a síle signálu příliš použitelná, pořád lze ale zavolat GeoAPI ručně, např. využitím projektu codetastrophe.

V nešifrovaných datech se nacházel taky typ telefonu a firmware (v tomhle případe VillainROM 12).

Shrnutí

SSL komunikace se dá narušit vydáním falešného validního certifikátu (pro vlivného útočníka) nebo přimět uživatele nainstalovat malware s rootkitem, který pozmění certificate store nebo podobnou službu. Hodně mě překvapilo, že procesy jako wpa_supplicant, které na desktop systému musí běžet pod rootem, běží na Androidu pod vlastním dedikovaným userem (tipoval bych to na úpravu jádra). Nejtěžší se zdá vyhnout se GoogleTalk service, tady asi jediná jednoduchá cesta je na způsob "ukuchtění" vlastní ROM bez Google aplikací ve VillainROM kitchen.

       

Komentáře

[________________]

to je jasné lebo BlackBerry je najlepší.

[optim]

Dovolil bych si malou technickou poznamku. V Opere je take pribalen certifikat StartComu.

[limit_false]

Zvláštní, v Opeře 10.61 (x86_64 Linux) StartCom jsem neměl. Lze ho ale najít na certs.opera.com. Opera si ho stáhla až při pokusu o ověření certifikátu vydaného StartComem z Rootstore.

[Filip Jirsák]

Jak jste přišel na to, že všechny zmíněné služby důvěřují všem systémovým certifikátům? Tj. že např. v GTalk se kontroluje jen „podepsáno systémovým certifikátem“ a nikoli „podepsáno systémovým certifikátem s otiskem ABC nebo vydavatelem Google“? Nahrál jste si do Androida svůj vlastní systémový certifikát a zkoušel jím požadavky podepsat?

[limit_false]

Nezkoušel jsem to já, ale Jon Oberheide, jednoduše přidal do certstore svůj CA certifikát a pak udělal MITM na spojení pomocí sslsniff.

Chtěl jsem si to časem vyzkoušet také, jen musím doma natahat kabely aby šlo použít notebook jako wifi AP se sslsniffem.

Když už bych si tipnul že nějaká aplikace nepoužívá systémový certstore, tak bych to tipoval na Operu Mini nebo Fennec (na všech systémech na kterých je znám mají vlastní certstore).

[Filip Jirsák]

Jestli to dobře chápu, tak systémový keystore je součást Android systému a uživatel (ani aplikace) nemá možnost jej upravovat (pokud systém nehackne). Evidentně to Google chápe tak, že poskytuje určité služby, a mobil s Androidem a Google palikacemi je zařízení, které umožní ty služby využívat. Google je zvyklý takhle pracovat (software nabízí jen velmmi málo, drtivou většinu jeho nabídky tvoří služby). Myslím, že pro koncové uživatele to takhle dává mnohem větší smysl, protože uživatel nechce software, ale službu jím poskytovanou. I když by neškodilo, kdyby to Google někde na jedné stránce přehledně popsal – člověk si může myslet, že když si chce software spravovat sám, nemá používat Market, ale GTalk klidně používat může, a ono to tak není. Ale hlavně že se člověk pořád může rozhodnout, že služby Googlu na Androidu používat nebude, a pak má prostě chytrý mobil, který pořád může normálně používat.

[limit_false]

Jj, systémový keystore nemá být upravován aplikacemi - jestli má něco na to práva, tak je stejně pozdě (může udělat v systému cokoliv).

Systém práv na Androidu mi přijde ještě lepší než na desktop linuxu. Každá aplikace je nainstalována pod jiným userem, pokud autor neurčí jinak (sdílet UID lze jenom pokud jsou dvě aplikace podepsané stejným klíčem), věci jako bluetooth a wifi subsystem (wpa_supplicant) mají taky svého dedikovaného uživatele místo roota, pod rootem běží myslím jen dva procesy, root exploit v userspace je tím pádem obtížnejší. Z core/include/private/android_filesystem_config.h:

#define AID_ROOT             0  /* traditional unix root user */

#define AID_SYSTEM        1000  /* system server */

#define AID_RADIO         1001  /* telephony subsystem, RIL */
#define AID_BLUETOOTH     1002  /* bluetooth subsystem */
#define AID_GRAPHICS      1003  /* graphics devices */
#define AID_INPUT         1004  /* input devices */
#define AID_AUDIO         1005  /* audio devices */
#define AID_CAMERA        1006  /* camera devices */
#define AID_LOG           1007  /* log devices */
#define AID_COMPASS       1008  /* compass device */
#define AID_MOUNT         1009  /* mountd socket */
#define AID_WIFI          1010  /* wifi subsystem */
#define AID_ADB           1011  /* android debug bridge (adbd) */
#define AID_INSTALL       1012  /* group for installing packages */
#define AID_MEDIA         1013  /* mediaserver process */
#define AID_DHCP          1014  /* dhcp client */
#define AID_SDCARD_RW     1015  /* external storage write access */
#define AID_VPN           1016  /* vpn system */
#define AID_KEYSTORE      1017  /* keystore subsystem */
#define AID_USB           1018  /* USB devices */

#define AID_SHELL         2000  /* adb and debug shell user */
#define AID_CACHE         2001  /* cache access */
#define AID_DIAG          2002  /* access to diagnostic resources */

/* The 3000 series are intended for use as supplemental group id's only.
 * They indicate special Android capabilities that the kernel is aware of. */
#define AID_NET_BT_ADMIN  3001  /* bluetooth: create any socket */
#define AID_NET_BT        3002  /* bluetooth: create sco, rfcomm or l2cap sockets */
#define AID_INET          3003  /* can create AF_INET and AF_INET6 sockets */
#define AID_NET_RAW       3004  /* can create raw INET sockets */
#define AID_NET_ADMIN     3005  /* can configure interfaces and routing tables. */

#define AID_MISC          9998  /* access to misc storage */
#define AID_NOBODY        9999

#define AID_APP          10000 /* first app user */

I s nezměněným certstorem bych byl ale opatrný např. v Emirátech: operátor Etisalat se již pokoušel kompromitovat uživatelské telefony. Certificate chain na https://www.etisalat.ae vypadá následovně:

GTE CyberTrust Global Root (serial 0x1a5, SHA1 fingerprint 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74)
  \- Comtrust Root Certification Authority basic constraints: CA:true; O: Etisalat, OU: Etisalat eBusiness Services
    \- Comtrust Server Certification Authority basic constraints: CA:true; O: Etisalat, OU: Etisalat eBusiness Services
      \- www.etisalat.ae

Z řetezce certifikátů plyne, že ve vlastní síti umí operátor Etisalat SSL MITM podpisem libovolného serverového certifikátu (a evidentně by se toho neštítil). Jenže GTE Root CA je předinstalována jak v Androidu, tak i v Opeře a Firefoxu.

[pavlix]

Systém práv na Androidu mi přijde ještě lepší než na desktop linuxu. Každá aplikace je nainstalována pod jiným userem

Nezdá se mi, že by jeden z těch systémů byl striktně lepší nebo horší.

[petr_p]

Google nezveřejnil, odkud má informace o wifi AP

Ale to je prosté: Pokud telefon má i GPS, tak zpárované údaje poloha–WiFi signál zasílá Googlu. Proč složitě a draze mapovat AP, když to uživatelé udělají zadarmo.

[tmr]

Ale samozrejme se to uzivatele po prvnim spusteni zepta, jestli to chce povolit.

[limit_false]

Pokud vím, Google měl tyhle informace ještě dřív, než uvedl Android. Pořád ale je možné, že známá data "updatuje" takhle. Ješte před Googlem měla podobnou databázi myslím Skyhook (nejspíš Google nejakou "startovací" DB nakoupil od několika firem a pak pokračoval po svém). A Skyhook taky používa wardriving na zběr dat.

[petr_p]

Tak jistě že si Google musel sběr dat odzkoušet a musel uživatele navnadit, aby hlášení povolili, takže prvotní údaje získal jinak. Ale obecně Google nemůže procestovat celou Zemi (navíc údaje by zastaraly dřív, než by ji celou zmapoval), takže největší kus práce leží na uživatelích. (Možná to tak z Prahy nevypadá, ale zkuste si službu v okresním městě.)

[thingie]

Jak zhruba by to mělo v malém okresním městě reagovat? Moje zkušenost (z malého okresního města) je, že to našlo moji skutečnou polohu +- 100 metrů. No. To asi fakt Google neprochází celý svět.