tag:blogger.com,1999:blog-24500549370363739032019-08-26T03:06:54.003-07:00DinoSecRaul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-2450054937036373903.post-49863549808685579872018-12-18T01:36:00.000-08:002018-12-18T01:36:10.412-08:00Reconocimiento a los hackers, investigadores y/o profesionales técnicos de seguridad españoles<i><u>NOTE</u></i>: This post, as an exception, has been published in Spanish, as it is dedicated to the Spanish hacker (and technical cybersecurity) community, for a well deserved recognition.<br /><br />Es para mí todo un honor haber sido designado como merecedor del premio a la trayectoria profesional en valor de la ciberseguridad por parte del Centro Criptológico Nacional (CCN), especialmente, en estas <a href="https://www.ccn-cert.cni.es/xiijornadas.html">XII Jornadas STIC CCN-CERT</a> (inolvidables por múltiples motivos),&nbsp;<a href="http://www.casareal.es/ES/Actividades/Paginas/actividades_actividades_detalle.aspx?data=13805">otorgado de la mano de Su Majestad el Rey, Don Felipe VI</a>:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-BgknhdgvuKY/XBdcf7mOb2I/AAAAAAAABIs/hlGDc_2FXCEHpPXpkdgXU8eZkFDDhFyqQCLcBGAs/s1600/Rey_STIC_20181212_07.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="935" data-original-width="1400" height="427" src="https://4.bp.blogspot.com/-BgknhdgvuKY/XBdcf7mOb2I/AAAAAAAABIs/hlGDc_2FXCEHpPXpkdgXU8eZkFDDhFyqQCLcBGAs/s640/Rey_STIC_20181212_07.jpg" width="640" /></a></div><br />En primer lugar, creo que es muy significativa la presencia de Su Majestad el Rey en este evento, reflejando la importancia que ha adquirido la seguridad de los entornos tecnológicos en nuestro día a día. Esta relevancia aumentará aún más en el futuro, debido a la sobredependencia tecnológica que vivimos actualmente, tanto en el plano personal o como sociedad, como en el plano profesional, institucional o industrial.<br /><div style="text-align: center;"><br /></div><div style="text-align: center;"><iframe allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/JiM1dWRbIs8?start=1022" width="560"></iframe></div><div style="text-align: center;"><span style="font-size: x-small;">Video: Fragmento del <a href="https://youtu.be/JiM1dWRbIs8?t=1022">momento de la entrega del premio</a>.</span></div><div style="text-align: center;"><br /></div>Casualmente, este año se podría decir que cumplo la mayoría de edad como profesional dedicado íntegramente a la seguridad informática, de la información, y de las tecnologías (hoy en día denominada ciberseguridad :-), qué comenzó allá por 2000-2001 cuando trabajaba en HP (Hewlett-Packard). Circunstancialmente, 2018 ha sido también el año del décimo aniversario de mi compañía, <a href="https://www.dinosec.com/">DinoSec</a>, que fundamos para intentar hacer realidad nuestros sueños profesionales y dedicarnos a aquello que más nos gusta. Después de un intenso año de trabajo y tras casi 20 años de carrera profesional en este campo, este premio es la "culminación" al comienzo de una todavía (espero) larga trayectoria para intentar seguir aportando mi granito de arena al apasionante mundo de la seguridad.<br /><br />Se trata de un premio aún joven, que comenzó a entregarse el pasado año, pese a que algunos tenemos la suerte de haber participado en las doce ediciones de este evento de referencia, lo que hace que me sienta aún más orgulloso de haberlo recibido en una edición temprana. Estoy seguro de que a tod@s nos vienen, o vinieron en el momento de la entrega, a la cabeza, numerosos otros profesionales que se merecen igualmente este premio, y que estoy seguro, serán reconocidos en años venideros.<br /><br />Agradezco al CCN su confianza, reflejada en este premio, así como el mensaje difundido este año, y plasmado en la interpretación tan positiva que se ha hecho del mismo por parte de la comunidad a la que pertenezco, y en ocasiones como ésta, represento: los profesionales técnicos de seguridad, investigadores, o <i>hackers</i> (<a href="https://dle.rae.es/?id=JxlUKkm">aunque el término es lo de menos</a>), que son tan necesarios para, con su alto conocimiento técnico especializado y dedicación, evaluar e identificar las debilidades y vulnerabilidades de la tecnología, con el objetivo de que sean corregidas y de mejorarla, para que todos dispongamos de entornos más seguros.<br /><div style="text-align: center;"><br /></div><div style="text-align: center;"><iframe allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/siNScXMBb5o?start=2125" width="560"></iframe></div><div style="text-align: center;"><span style="font-size: x-small;"><span style="text-align: center;">Video: Fragmento antes de nuestra ponencia sobre DNSSEC para, muy brevemente (por las limitaciones de tiempo), <a href="https://youtu.be/siNScXMBb5o?t=2125">poder agradecer el premio</a></span><span style="text-align: center;">.</span></span></div><div style="text-align: center;"><br /></div>Enfatizar, que de alguna manera, se demuestra que el trabajo duro siempre da sus frutos, ya que este es un premio al talento, al inconmensurable valor que debe tener el conocimiento técnico de unas tecnologías e infraestructuras cada vez más complejas, a las capacidades de análisis y de pensamiento lateral, a la motivación de resolver nuevos retos, y a los valores con los que siempre me he identificado y, que de alguna manera, también se reflejan en este premio: esfuerzo, pasión, dedicación, compromiso, implicación, sacrificio, humildad, profesionalidad, curiosidad, inquietud, y muchas ganas de siempre seguir aprendiendo.<br /><br />Quizás el término que más se ha repetido en todos los mensajes de felicitación recibidos ha sido "merecido", lo que, viniendo de tantos y tan valiosos profesionales, le da aún más valor y me hace estar más orgulloso y satisfecho. Un mensaje que, ahora más que nunca, siento que no nos debemos de cansar de transmitir a las nuevas generaciones.<br /><br />Sin duda, <a href="https://twitter.com/CCNCERT/status/1072768927917359104/">la entrega del premio</a> constituyó un emotivo e inolvidable momento, que uno sólo tiene posiblemente la suerte de poder disfrutar una vez en la vida:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-AEWQbdwzTlo/XBdfGInookI/AAAAAAAABI4/Stdgrj2X9kcAD0JvE6FlMk5YMOe4BFQCgCLcBGAs/s1600/Entrega_trofeo.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="900" data-original-width="1200" height="480" src="https://2.bp.blogspot.com/-AEWQbdwzTlo/XBdfGInookI/AAAAAAAABI4/Stdgrj2X9kcAD0JvE6FlMk5YMOe4BFQCgCLcBGAs/s640/Entrega_trofeo.jpg" width="640" /></a></div><br />Como colofón, uno no tiene la oportunidad de poder departir unos minutos en persona con Su Majestad el Rey, para desde la modestia, intentar transmitirle la importancia de estos valores, de disponer de una educación y formación de calidad en España, y la trascendencia que tiene, y tendrá, para nuestro país, contar con profesionales técnicos altamente cualificados, para cubrir la creciente demanda de nuestro sector. Y todo ello tras haber disfrutado de una demostración en directo del funcionamiento de una máquina Enigma de tres rotores, cifrando y descifrando un mensaje, como ejemplo vivo de la historia de la criptografía. <a href="https://twitter.com/dinosec/status/1072945505674641408/">Dejé el trofeo bajo ella durante unas horas, por si se le pegaba algo...</a> :-)<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-NhI1n5x-9KY/XBdfP7Ety6I/AAAAAAAABI8/8UBO4UthJTcI0MonirOff9PCqRfNkBKMwCLcBGAs/s1600/Enigma_trofeo.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1600" data-original-width="743" height="640" src="https://3.bp.blogspot.com/-NhI1n5x-9KY/XBdfP7Ety6I/AAAAAAAABI8/8UBO4UthJTcI0MonirOff9PCqRfNkBKMwCLcBGAs/s640/Enigma_trofeo.jpg" width="296" /></a></div><br />Aunque el premio es entregado a una persona individual, por un lado es justo agradecer y destacar que yo no podría haber recibido este premio sin el incondicional apoyo y compañía de mi mujer, Mónica Salas, que durante un cuarto de siglo ha estado siempre ahí, haciéndome crecer tanto como persona, como en el plano profesional. Este premio es una realidad, sin duda, gracias a ella. Igualmente, a mi familia (tanto a los que aún están con nosotros, como especialmente a los que no), por acompañarme en este camino; con su esfuerzo y cariño siempre se preocuparon de proporcionarme la mejor educación y formación posible, y de crear el entorno ideal para que pudiera llegar donde me encuentro a día de hoy. Y por supuesto, a mis hijos, representando a las futuras generaciones que tendrán que protegernos dentro de muy pocos años... :-)<br /><div style="text-align: center;"></div><br />Por último, y no menos importante, no quiero olvidarme de aquellos con los que he compartido mi carrera profesional de forma más cercana todos estos años (compañeros, colaboradores, clientes, alumnos, conferencias de seguridad, etc.), y quiero también agradecer enormemente el extenso y afectuoso apoyo que he recibido por parte de toda nuestra comunidad, de tantas y tantas personas, que se han visto reflejadas en mí y en este premio. ¡Muchas gracias a tod@s!<br /><br />Aunque los años no pasan en balde, y siempre uno se considera más joven de lo que es, quiero aclarar que ni mucho menos me ha llegado la hora de jubilarme (como algunos asumen que ocurre tras recibir un premio como éste :-), sino que este premio constituye un aliciente, que sirve para reflexionar, valorar lo realizado hasta ahora y seguir querer haciendo más y mejores cosas, siempre disfrutando.<br /><br />Para no extenderme más, todas las anécdotas asociadas a mi indumentaria, con frases como "<i>¿Es un fotomontaje o Raúl se ha puesto un traje?</i>", las dejo para círculos más cerrados... ;-)<br /><div><br /></div><div><i><u>Autor</u>: Raúl Siles</i></div>Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com1tag:blogger.com,1999:blog-2450054937036373903.post-22295072957070450412018-05-22T22:42:00.000-07:002018-12-18T01:30:14.349-08:00DinoSec's 10-Year Anniversary... and WPA3<i><u>UPDATE</u></i>: The <a href="https://www.dinosec.com/en/lab.html#NNED8">WPA3 presentation</a>&nbsp;by Raul Siles at Navaja Negra (#NN8ED) in October 2018 has been published, including the <a href="https://www.youtube.com/watch?v=B10qZrAAtZw">video</a>&nbsp;(in Spanish) and <a href="https://www.dinosec.com/en/lab.html#NNED8">an early PDF version</a> that includes all the technical references.<br /><br />This month, May 2018, is DinoSec's 10-year anniversary and this milestone deserves, at least, a blog post... of appreciation and technical content! ;-)<br /><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-WoLLRfYqNFY/WvIHmvHLmDI/AAAAAAAABB8/spQ8kYo2CColaYkkmodl8Teo066hEPHqACLcBGAs/s1600/logo%2B10th%2Banniversary.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="637" data-original-width="692" height="183" src="https://1.bp.blogspot.com/-WoLLRfYqNFY/WvIHmvHLmDI/AAAAAAAABB8/spQ8kYo2CColaYkkmodl8Teo066hEPHqACLcBGAs/s200/logo%2B10th%2Banniversary.png" width="200" /></a></div>First of all, we want to say thank you to all our customers for showing their trust and confidence in us and our high quality practices, helping to make DinoSec's adventures and business a reality. We also want to thank our collaborators for their support, allowing us to accomplish more ambitious and complex projects and challenges. Thanks you all for allowing&nbsp;<a href="https://www.dinosec.com/en/company.html">DinoSec's original essence and goals as a company</a> remain after a decade!<br /><br />We are very aware DinoSec's Blog has remained quite quiet during the last three years. Although I don't want this to sound as an excuse (as the reality is that we are quite busy), it is true that back in the early days, publishing blog articles was one of the main mechanisms we used in the security industry to spread the word about new research, tools and topics. This is what I did throughout the three&nbsp;<a href="https://radajo.blogspot.com.es/">RaDaJo</a>, <a href="http://blog.taddong.com/">Taddong</a> and <a href="http://blog.dinosec.com/">DinoSec</a> blogs over time. However nowadays, although blogs are still used and relevant, there are many other methods to distribute contents, mainly social networks, team messaging and messaging apps (super)groups (public and private), technical training, and (still) presentations and talks (like the ones you can find at&nbsp;<a href="https://www.dinosec.com/en/lab.html">DinoSec's Lab</a>) delivered at a very long list of cybersecurity conferences, local (e.g. <a href="https://twitter.com/raulsiles/lists/hacking-conferences-spain">Spain</a>) or <a href="https://twitter.com/raulsiles/lists/hacking-conferences">worldwide</a>.<br /><br />Switching to the technical content, one of the technologies I have been passionate about during almost two decades has been Wi-Fi security. This is a good reason to focus, once again, on Wi-Fi security in this (last?) DinoSec blog post (coincidentally, I also talked about Wi-Fi security in <a href="http://blog.dinosec.com/2015/02/why-do-wi-fi-clients-disclose-their-pnl.html">the latest DinoSec's blog post</a> more than three years ago).<br /><br />The <a href="https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-publishes-2018-wi-fi-predictions">2018 Wi-Fi predictions from the Wi-Fi Alliance</a> include various attractive programs they are developing, such as bringing enterprise design practices to new home Wi-Fi networks via the <a href="https://www.wi-fi.org/discover-wi-fi/wi-fi-home-design">Wi-Fi Home Design</a> initiative, optimizing the Wi-Fi user experience and performance by unifying multiple key technologies in programs such as <a href="https://www.wi-fi.org/discover-wi-fi/wi-fi-vantage">Wi-Fi Vantage</a>, or improving the retail and shopping experience via <a href="https://www.wi-fi.org/discover-wi-fi/wi-fi-aware">Wi-Fi Aware</a> by allowing Wi-Fi devices to discover their word nearby and exchange (peer-to-peer) data with other devices without a Wi-Fi infrastructure, even managing location information through <a href="https://www.wi-fi.org/discover-wi-fi/wi-fi-location">Wi-Fi Location</a>. The Wi-Fi bandwidth and speed keeps growing over the years via new technologies such as <a href="https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-wigig">WiGig</a> (60 GHz) and&nbsp;High Efficiency (HE) IEEE&nbsp;<a href="https://standards.ieee.org/develop/project/802.11ax.html">802.11ax</a> (2.4 &amp; 5 GHz), with products expected in the market late 2018 or 2019. The predictions also mention how the ongoing <a href="https://www.wi-fi.org/discover-wi-fi/security">Wi-Fi security</a> evolution will introduce new WPA3 (Wi-Fi Protected Access, version 3) enhancements&nbsp;throughout this year.<br /><br />In 2018 the <a href="https://www.wi-fi.org/discover-wi-fi/security">WPA2 certification program</a> will continue to evolve to meet new security requirements, such as standardizing 128-bit cryptographic suites, or making mandatory the use of Protected Management Frames (PMF), a feature defined in the IEEE&nbsp;<a href="https://standards.ieee.org/findstds/standard/802.11w-2009.html">802.11w</a> standard to avoid easy manipulation of sensitive 802.11 management frames, widely used in deauthentication attacks. <a href="https://www.krackattacks.com/">KRACK</a> mitigations are going to be <a href="https://www.youtube.com/watch?v=AnTmqumcCow#t=3m35s">mandatory too in future WPA2</a> certified products.<br /><br />The Wi-Fi Alliance <a href="https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-security-enhancements">announced in January this year (2018) the upcoming release of WPA3</a>, a new security standard focused on enhancing Wi-Fi security protections in both personal and enterprise networks. It is not clear to what extent this announcement has been influenced by the discovery and publication of <a href="https://www.krackattacks.com/">KRACK</a> (Key Reinstallation Attacks: Breaking WPA2 by forcing nonce reuse) in October 2017. Last week, the announcement of a <a href="https://wccftech.com/qualcomm-integrates-wpa3-encryption-across-the-snapdragon-845-and-the-companys-product-portfolio/">large chipset vendor integrating WPA3</a> in their upcoming products hit the news (really? isn't this something all manufacturers are going to do along this year..?: "According to the Wi-Fi Alliance, new devices supporting WPA3 will be released later in 2018, many of which will <a href="https://venturebeat.com/2018/05/19/what-is-wpa3-why-does-it-matter-and-when-can-you-expect-it/">likely be announced at Computex in June</a>").<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-OMfh4qX08VU/WwA1rJm4OfI/AAAAAAAABEQ/x-qx5KThAUUyprUKAp9JnWp31kgWjp4dACLcBGAs/s1600/wpa3-wifi-security.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="380" data-original-width="728" height="332" src="https://4.bp.blogspot.com/-OMfh4qX08VU/WwA1rJm4OfI/AAAAAAAABEQ/x-qx5KThAUUyprUKAp9JnWp31kgWjp4dACLcBGAs/s640/wpa3-wifi-security.png" width="640" /></a></div><br />The new <b>WPA3</b> improvements include <b>four specific security capabilities</b>:<br /><br /><ul><li>Robust protections even when users choose passwords that fall short of typical complexity recommendations.</li><li>Simplify the process of configuring security for devices that have limited or no display interface.</li><li>Strengthen user privacy in open networks through individualized data encryption.</li><li>A 192-bit (cryptographic) security suite, aligned with the Commercial National Security Algorithm (CNSA) Suite (more suitable for government, defense, industrial, and other high security sensitive environments).</li></ul><br />Unfortunately,&nbsp;&nbsp;it seems we do not learn from history in the infosec (nowadays called cybersecurity) industry. The Wi-Fi Alliance (WFA) is currently working on an internal WPA3 draft. Wouldn't make sense opening the WPA3 draft specification for a global and public security review?, trying to find potential vulnerabilities beforehand, and with the goal of getting it right before it is already implemented in millions and millions of Wi-Fi products and chipsets... ("<a href="https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-publishes-2018-wi-fi-predictions">...more than three billion (Wi-Fi) devices shipping (just) in 2018 (are expected)</a>."). The reality is that the Wi-Fi Alliance impose <a href="https://www.youtube.com/watch?v=AnTmqumcCow">tight controls on the specifications</a>&nbsp;confidentiality until they are finalized and published... :(<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-B7nLsekfdL0/WwE1yp__zWI/AAAAAAAABEc/JczEzjGuSjEJhyrjNLA-PR0XOXrjVRsIgCLcBGAs/s1600/dt131211.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="280" data-original-width="900" height="198" src="https://4.bp.blogspot.com/-B7nLsekfdL0/WwE1yp__zWI/AAAAAAAABEc/JczEzjGuSjEJhyrjNLA-PR0XOXrjVRsIgCLcBGAs/s640/dt131211.gif" width="640" /></a></div><div style="text-align: center;"><br /></div>This is something we have (somehow) learned to do in the cryptographic community, requesting peer reviews and opening competitions for new standards, such as NIST did with the Advanced Encryption Standard (<a href="https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines/archived-crypto-projects/aes-development">AES</a>, Rijndael), the Secure Hash Algorithm-3 (<a href="https://csrc.nist.gov/projects/hash-functions/sha-3-project">SHA-3</a>, Keccak), or with <a href="https://csrc.nist.gov/Projects/Post-Quantum-Cryptography">post-quantum cryptography</a>. As most Wi-Fi security improvements in WPA3 are crypto-related, perhaps we should learn from others in the wireless and network protocols community...<br /><br />In the next four sections, due to the limited details available in <a href="https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-security-enhancements">the initial Wi-Fi Alliance announcement</a>, I will try to provide some additional technical details about these new security capabilities introduced by WPA3, complementing the <a href="https://github.com/d33tah/call-for-wpa3">identified needs</a> or <a href="https://www.mathyvanhoef.com/2018/03/wpa3-technical-details.html">WPA3 analysis and interpretation</a>&nbsp;already published by other researchers. Apart from these four features, WPA3 might remove the option to use WEP or TKIP (considered obsolete nowadays), and (re)define the supported list of EAP methods for WPA3-Enterprise.<br /><br /><h3>Updated and More Secure WPA3 Handshake</h3>"<i>Robust protections even when users choose passwords that fall short of typical complexity recommendations</i>"<br /><br />The current WPA2 traditional four-way handshake does not implement specific countermeasures against hardware-based offline cracking attacks, although the original design made use of PBKDF2 (a key derivation function, in this case, using 4,096 HMAC-SHA1 iterations) and a salt (the SSID, or Wi-Fi network name) to slow down password cracking attacks (offline dictionary or brute force attacks).<br /><br />The new WPA3 four-way handshake adds extra protections for the WPA3-PSK password, even when a robust passphrase is not used. WPA3 is based on the <a href="https://ieeexplore.ieee.org/abstract/document/4622764/?part=1">Simultaneous Authentication of Equals (SAE)</a> handshake, a variant of an authentication and key exchange protocol (or PAKE, Password-Authenticated Key Exchange) known as Dragonfly.&nbsp; Dragonfly, currently defined in&nbsp;<a href="https://tools.ietf.org/html/rfc7664">RFC 7664</a>&nbsp;and in the <a href="https://ieeexplore.ieee.org/document/7786995/">802.11-2016 specification</a>&nbsp;(a PDF with more than 3,500 pages),&nbsp;has been supposedly enhanced to mitigate&nbsp;<a href="https://eprint.iacr.org/2013/058.pdf">previously identified Dragonfly offline attacks</a>&nbsp;(and/or&nbsp;<a href="https://www.ietf.org/mail-archive/web/cfrg/current/msg03537.html">other weaknesses</a>), it is also the foundation for&nbsp;<a href="https://tools.ietf.org/html/draft-harkins-tls-dragonfly-02">TLS-PWD</a>&nbsp;and there is even a&nbsp;<a href="http://orbilu.uni.lu/bitstream/10993/24767/1/Dragonfly.pdf">security proof</a>&nbsp;for it (...&nbsp;like for WPA2 before KRACK? ;-).&nbsp;SAE was&nbsp;originally used for 802.11-based mesh networks under the IEEE <a href="https://mentor.ieee.org/802.21/dcn/11/21-11-0084-01-0000-survery-of-mesh-networking-security.ppt">802.11s security</a>&nbsp;umbrella, although in WPA3 infrastructure networks typically only the Wi-Fi AP (Access Point) will initiate the handshake. For compatibility reasons, both WPA2-PSK (or Personal) and SAE might coexist simultaneously in WPA3-Personal APs.<br /><br />SAE employs discrete logarithm cryptography (finite fields or elliptic curve cryptography, FFC or ECC) for a mutual authentication exchange using only a password, that is used to derive an ephemeral key, similarly to a Diffie-Hellman (DH) key exchange, and it benefits from associated properties such as forward secrecy (the derived key cannot be recovered in the future even if the password is obtained). It is designed to&nbsp;be (probably) resistant against offline dictionary attacks, as no information about the password (or the key) is disclosed except whether a password guess is correct or incorrect.<br /><br />The result of the SAE handshake is a strong shared secret (or derived key) that will become the PMK (Pairwise Master Key, 256 bits) in WPA3 (like the PMK in WPA2), therefore, it will be used in the traditional four-way handshake to derive the PTK (Pairwise Transient Key, 512 bits). Thus, the new WPA3 handshake replaces the traditional WPA2 PBKDF2 key derivation process to obtain the PMK from the PSK (Pre-shared Key), or password... or passphrase.<br /><br />One potential drawback of this new WPA3 handshake is that the Wi-Fi AP&nbsp;<a href="https://www.mathyvanhoef.com/2018/03/wpa3-technical-details.html">might require storing the password in plaintext</a>, as pointed out by Mathy Vanhoef (from KRACK). Although a <a href="https://tools.ietf.org/id/draft-irtf-cfrg-pake-reqs-02.html#rfc.section.3.1">"balanced" PAKE</a> also allows storing a hash of the password with a random salt, as a <a href="https://www.ietf.org/mail-archive/web/cfrg/current/msg03537.html">"non-augmented" protocol</a>, the stored values (or hashes) can be used directly to authenticate to the AP. Therefore, the stored hash is acting as a plaintext password (even if it cannot be easily read by humans), and becomes vulnerable to PtH-like (Pass-the-Hash) attacks (in which a dictionary or brute force attack to obtain the original password is not required).<br /><br /><h3>Updated and More Secure WPS Alternative</h3>"<i>Simplify the process of configuring security for devices that have limited or no display interface</i>"<br /><br />WPA3 introduces new capabilities to configure secure Wi-Fi networks in devices without screens or input peripherals, such as IoT (Internet of Things) devices.<br /><br />The simplification of the initial setup process to join a new Wi-Fi client to a Wi-Fi network in a secure way has been troublesome in the past. The WPS (<a href="https://www.wi-fi.org/discover-wi-fi/wi-fi-protected-setup">Wi-Fi Protected Setup</a>) standard has suffered serious online (Reaver) and offline (Pixie) vulnerabilities in recent years.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-uMpgZbLCAq8/WwAd16YZNJI/AAAAAAAABEE/qIpASafUQ9gzRxuY4yPRStrURK826poMACLcBGAs/s1600/WPS.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="131" data-original-width="86" src="https://1.bp.blogspot.com/-uMpgZbLCAq8/WwAd16YZNJI/AAAAAAAABEE/qIpASafUQ9gzRxuY4yPRStrURK826poMACLcBGAs/s1600/WPS.gif" /></a></div><br />WPA3 tries to replace WPS with a new technical specification named&nbsp;<a href="https://www.wi-fi.org/downloads-registered-guest/Device_Provisioning_Protocol_Draft_Technical_Specification_Package_v0_0_23_0.zip/31255">Wi-Fi Device Provisioning Protocol (DPP), still in draft state (registration required)</a>. This new three-way handshake authentication or setup protocol requires the usage of public key cryptography to identify and authenticate all Wi-Fi devices. DPP employs elliptic curve cryptography (ECC), and specifically elliptic curve Diffie-Hellman (ECDH), to derive a shared secret or key. Again, upon successful validation of the peer discovery process, the Wi-Fi devices will&nbsp; mutually derive a PMK (Pairwise Master Key) that will be used in the traditional four-way handshake to derive the PTK (Pairwise Transient Key). AES-SIV (Synthetic Initialization Vector, <a href="https://tools.ietf.org/html/rfc5297">RFC 5297</a>) is involved in the protocol for the parties to prove possession of the private keys associated to the public identity keys.<br /><br />Mutual authentication is desired between the Wi-Fi devices (e.g. client and AP), but due to constraints in some clients, it is not mandatory (thus, more insecure). One of the methods promoted by the new WPA3 mechanism to identify the other device is the usage of QR codes (e.g. containing the public key with the identity of the Wi-Fi network) for client devices with a camera. Other options for bootstrapping trust involve&nbsp;<a href="https://www.wi-fi.org/downloads-registered-guest/NeighborAwarenessNetworking_TechnicalSpecification_v2.0.pdf/29731">Neighbor Aware Networking (NAN)</a>, used in <a href="https://www.wi-fi.org/discover-wi-fi/wi-fi-aware">Wi-Fi Aware</a>, USB, NFC, or Bluetooth, or proof of knowledge of a shared code, key, phrase, or word.<br /><br /><h3>Individualized Data Encryption</h3>"<i>Strengthen user privacy in open networks through individualized data encryption</i>"<br /><br />This feature tries to offer encryption (using individual encryption keys for each connecting client) for open Wi-Fi networks, where the common WPA2-PSK security based on a unique Wi-Fi network password is not even available. This feature will mainly affect open Wi-Fi networks commonly used in public Wi-Fi hotspots (hotels, airports, libraries, coffee shops, restaurants, conferences, etc.).<br /><br />Long time ago, around year 2010, a few proposals to offer enterprise-level security for open or public Wi-Fi networks were already discussed, named <a href="http://www.riosec.com/articles/Open-Secure-Wireless">Open Secure Wireless</a>&nbsp;(OSW), promoted by&nbsp;Christopher Byrd, or a variant, <a href="http://www.hakim.ws/BHUS2011/materials/Arsenal/BH_US_11_Cross_Arsenal_Secure_Wireless_Slides.pdf">Secure Open Wireless Networking</a> (SOWN or SOWA, Secure Open Wireless Access), promoted by Tom Cross &amp; Takehiro Takahashi. These proposals emphasized that open does not mean unencrypted.<br /><br />OSW main goal was to make use of all the security benefits provided by WPA2-Enterprise, without the need of authenticating the user, that is, providing open access to any user. OSW only requires a slightly modified EAP-TLS type (anonymous authentication) supported by the Wi-Fi clients, and there is even a <a href="https://github.com/cbyrd01/osw-test">prototype implementation</a> available. A new&nbsp;<a href="http://www.riosec.com/articles/open-secure-wireless-20">OSW 2.0 revision</a>&nbsp;(OSW2) was released afterwards, incorporating <a href="https://standards.ieee.org/findstds/standard/802.11u-2011.html">IEEE 802.11u</a> improvements. I have found even <a href="https://patents.google.com/patent/US9510194B2/en">a related patent</a> for something like OSW/SOWN.<br /><br />SOWN, also EAP-TLS based, focused more on binding the Wi-Fi network digital certificate (associated to the RADIUS server) to the Wi-Fi network name (or SSID), enhanced as an eXclusive or eXtended SSID (or XSSID). Even before that age, in 2007, George Ou made a proposal to use a WPA2-Enterprise PEAP-based Wi-Fi network with a <a href="https://www.zdnet.com/article/a-secure-wireless-lan-hotspot-for-anonymous-users/">generic or guest account for anonymous users</a>, to accomplish similar goals.<br /><br /><div style="text-align: center;"><img alt="" class="" height="auto" src="https://zdnet2.cbsistatic.com/hub/i/r/2014/10/04/13280795-4bab-11e4-b6a0-d4ae52e95e57/resize/370xauto/d31e2f3ebf3645647cc1cdd4cba9aa06/securehotspot.png" width="370" /></div><br />WPA3 "individualized data encryption" refers to&nbsp;<a href="https://tools.ietf.org/html/rfc8110">Opportunistic Wireless Encryption (OWE)</a> for Wi-Fi networks, a mechanism designed to provide encryption without authentication, encompassed under the <a href="https://tools.ietf.org/html/rfc7435">"opportunistic security" concept</a>&nbsp;(RFC 7435), and defined in <a href="https://tools.ietf.org/html/rfc8110">RFC 8110</a>.<br /><br />OWE provides protections against passive attacks, such as traffic sniffing. Similarly to the new WPA3 handshake, OWE negotiates or derives a PMK (Pairwise Master Key) using a Diffie-Hellman (DH) key exchange (again using finite fields or elliptic curves), but with no initial password involved this time (as there is no authentication in public or open Wi-Fi networks). The PMK is used again&nbsp;throughout the traditional four-way handshake to derive the PTK (Pairwise Transient Key).<br /><br />WPA3 APs will advertise support for OWE in their 802.11 beacons and probe responses. Once a Wi-Fi client performs a standard open authentication (request and response), additional information elements (IE) are incorporated into association requests and responses to perform the DH key exchange, allowing both the Wi-Fi AP and the client to exchange their public keys and, as a result, perform the cryptographic computations required to derive the PMK.<br /><br /><h3>A 192-bit Cryptographic Security Suite</h3>"<i>A 192-bit (cryptographic) security suite, aligned with the Commercial National Security Algorithm (CNSA) Suite</i>"<br /><br />WPA2 (ignoring TKIP, that should not be used anymore) implements an encryption protocol based on AES CCMP (CTR mode with CBC-MAC Protocol). CTR mode, also known as <a href="https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)">CounTeR mode</a>,&nbsp;turns a block cipher into a stream cipher (as detailed in the KRACK attacks). <a href="https://tools.ietf.org/html/rfc3610">RFC 3610 defines the Counter with CBC-MAC (CCM)</a> protocol, and specifies that this generic authenticated encryption (AE) block cipher mode is defined for use with 128-bit block ciphers, such as AES.<br /><br />Therefore, the new 192-bit crypto suite introduced by WPA3 does not simply offer an increased key size, but must use a different encryption algorithm (referred as NIST "Suite B" cryptographic algorithms), most probably, AES GCMP (Galois/Counter Mode Protocol), described in <a href="https://tools.ietf.org/html/rfc5288">RFC 5288</a> for TLS. <a href="https://framebyframewifi.net/2016/08/02/802-11ac-encryption-upgrade/">GCMP was already "silently" introduced in WPA2 for 802.11ac</a>, even using longer 256-bit keys, and will be used by <a href="https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-wigig">WiGig</a> too.<br /><br /><h3>Wi-Fi Hidden Networks... Still in WPA3?</h3>Apart from these four previously detailed WPA3 security enhancements, there are pending security issues that still need to be addressed in the current Wi-Fi specification. Future Wi-Fi-related WPA3 developments might focus on protecting users privacy too (probably a lost battle globally at this point...), including MAC address randomization (using locally administered MAC addresses when the client is not associated to the Wi-Fi network yet, or even post-association...) as well as reducing other types of information leakage (SSID names in probe requests). Thus, WPA3 might introduce privacy enhancements (badly named, as they also have serious implications from a security perspective, not just privacy), such as mitigating Wi-Fi devices from sending directed probe requests until the associated SSIDs have been already discovered via passive scanning (obtaining and processing the 802.11 beacon frames in the area) or active scanning (via wildcard or generic 802.11 probe requests).<br /><br />One of the main issues I have been really interested in during the last years is Wi-Fi&nbsp;<a href="http://blog.dinosec.com/2015/02/why-do-wi-fi-clients-disclose-their-pnl.html">hidden (or non-broadcasting) networks,</a> a useless feature that facilitates <a href="http://blog.dinosec.com/2014/10/attacking-wi-fi-clients-introduction.html">attacks against Wi-Fi clients and promotes the disclosure of their PNL</a> (Preferred Network List). In fact, the potential WPA3 privacy enhancements mentioned in the previous paragraph would be equivalent to not considering a Wi-Fi network as hidden anymore or, said otherwise, if WPA3 introduces these mitigating behaviours, Wi-Fi clients won't be capable of connecting to hidden networks anymore, which drives us to my next point.<br /><br />Wi-Fi PNL disclosure is one of the topics I extensively cover in my "<a href="https://twitter.com/dinosec/status/951434889034915840">Practical Wireless &amp; Radio Hacking</a>" (PWRH) training, and I do even have a slide (see below) detailing what should be removed from the IEEE 802.11-2012 specification to eliminate support for Wi-Fi hidden networks and, as a result, mitigate the related privacy and security attacks. It is trivial for a potential attacker to fire up a fake Wi-Fi AP impersonating one of the legitimate APs the victim Wi-Fi client has connected to in the past, and is searching for. The attacker has plenty of opportunities to attack the victim Wi-Fi client, no matter what security type was used by the legitimate Wi-Fi network (open, WEP, WPA(2)-PSK or WPA(2)-Enterprise).&nbsp; <br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-cQtwklTyXjw/WwAazcdCKZI/AAAAAAAABD4/6seE_WRRdckrL2RbpjqkgNCFGnnkzT4xQCLcBGAs/s1600/Wi-Fi_Hidden_Networks.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1197" data-original-width="1600" height="476" src="https://3.bp.blogspot.com/-cQtwklTyXjw/WwAazcdCKZI/AAAAAAAABD4/6seE_WRRdckrL2RbpjqkgNCFGnnkzT4xQCLcBGAs/s640/Wi-Fi_Hidden_Networks.png" width="640" /></a></div><br />In the past I tried to approach the IEEE to promote the removal of Wi-Fi hidden networks, but I was disappointed about the bureaucracy&nbsp;and obstacles I had to confront, at least, for a security researcher that does not belong to any of the IEEE 802.11 Working Group (WG) members. If you know someone in the 802.11 WG interested on helping with this, please, <a href="https://www.dinosec.com/en/contact.html">send me an e-mail</a>. Another approach would be to get it out of the specification through the Wi-Fi Alliance thanks to WPA3. If we are lucky and get it removed from the next IEEE 802.11 specification, perhaps a decade from now, all Wi-Fi products in the market will not <a href="http://blog.dinosec.com/2015/02/why-do-wi-fi-clients-disclose-their-pnl.html">disclose their PNL for free</a>&nbsp;via directed 802.11 probe requests... ;-)<br /><br />Happy WPA3 security testing!<br /><br /><span style="font-size: x-small;">Image source:&nbsp;http://www.systemandgeneration.com/uploads/images/about/logo%2010th%20anniversary.png</span><br /><span style="font-size: x-small;">Image source:&nbsp;https://1.bp.blogspot.com/-9LQ5duG0Xe4/WlUHLIsS2CI/AAAAAAAAvaU/GGErwBXBy34duL8XNVqfpTKgeMwZ82J5wCLcBGAs/s728-e7/wpa3-wifi-security.png</span><br /><span style="font-size: x-small;">Image source:&nbsp;http://dilbert.com/strip/2013-12-11</span><br /><br />Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com3tag:blogger.com,1999:blog-2450054937036373903.post-60448082784085829692015-02-20T01:41:00.000-08:002018-10-24T04:10:06.842-07:00Why Do Wi-Fi Clients Disclose their PNL for Free Still Today?<i><u>Shameless plug</u></i>: Don't miss this year <a href="https://www.rootedcon.com/rlab38-tecnicas-de-ataque-sobre-clientes-wi-fi/">2015 RootedLab</a>, a great opportunity to learn and practice effective client Wi-Fi attacks (&amp; defenses) though a new updated hands-on workshop full of tips and tricks and real-world pen-testing advice: <a href="https://www.rootedcon.com/rlab38-tecnicas-de-ataque-sobre-clientes-wi-fi/">"<b>Técnicas de ataque sobre clientes Wi-Fi</b>"</a>. It will take place in Madrid on <a href="https://www.rootedcon.com/rootedlabs/">March 4</a> (in two weeks) in Spanish, and right now there are only a few seats available (check also the other interesting workshops, called&nbsp;<a href="https://www.rootedcon.com/rootedlabs/">RootedLabs</a>,&nbsp;that are running before this year <a href="http://www.rootedcon.com/">RootedCON</a> conference). During the workshop we will cover in-depth all the topics from the <a href="http://blog.dinosec.com/2014/10/attacking-wi-fi-clients-introduction.html">introductory</a> blog post, from this blog post, and put in practice traditional and new advanced attacks (FreeRADIUS-WPE, EAP LEAP-Down, EAP Dumb-Down, LEAP2PEAP relay...), and much more..., such as (not released yet) new FreeRADIUS-WPE patches for the LEAP-Down attack, or a new <a href="http://www.dinosec.com/en/lab.html#iStupid">iStupid</a> version (v1.4) implementing the <a href="http://www.coresecurity.com/advisories/android-wifi-direct-denial-service">DoS Wi-Fi Direct attack against Android 4.x devices (CVE-2014-0997)</a>.<br /><br /><br />The <a href="http://blog.dinosec.com/2014/10/attacking-wi-fi-clients-introduction.html">initial introduction to the "Attacking Wi-Fi Clients" DinoSec blog post series</a> highlighted multiple topics involved in current Wi-Fi client weak behaviors and potential attack opportunities. This next installment in the series focuses on understanding why and when Wi-Fi clients disclose their PNL still today.<br /><br /><b><span style="font-size: large;">State-of-the-Art: The PNL</span></b><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-TuIDdk_eR1c/VOcDxR98lcI/AAAAAAAAAqs/N0JA8TLUNIc/s1600/PNL.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-TuIDdk_eR1c/VOcDxR98lcI/AAAAAAAAAqs/N0JA8TLUNIc/s1600/PNL.gif" height="172" width="200" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div>There are scenarios where Wi-Fi clients still disclose their PNL, that is, the list of known Wi-Fi networks the client has connected to in the past, and it is willing to connect to again, now and in the future. This weakness in the default behavior of Wi-Fi clients (part of the IEEE 802.11 specification) was discovered <a href="http://www.raulsiles.com/old/docs/Chatty_Windows_Wifi_Sep05.html">around the end of 2004, early 2005</a>, and tools were released to exploit it by automatically impersonating any open network the client device tries to connect to, such as <a href="http://www.theta44.org/karma/">Karma</a>. Alternative tools have been published over the years, such as <a href="http://dev.metasploit.com/redmine/projects/framework/wiki/Karmetasploit">Karmetasploit</a> or <a href="http://www.aircrack-ng.org/doku.php?id=airbase-ng">airbase-ng</a>. Although in January 2007 Microsoft released an optional <a href="http://support.microsoft.com/kb/917021">client update to prevent the wireless advertising of the PNL</a> for Windows XP SP2, still today lots of Wi-Fi clients are vulnerable.<br /><br /><b><span style="font-size: large;">When Do Wi-Fi Clients Disclose their PNL?</span></b><br /><br />The following paragraphs detail different modern scenarios in which Wi-Fi clients still might disclose their PNL, including some curious references to constraints you will find when you try to manage the PNL of your Wi-Fi clients.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-0PQerHtmdWA/VOcD2LNgR3I/AAAAAAAAAq0/HBC9Rd9yczg/s1600/PNL-Libro.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-0PQerHtmdWA/VOcD2LNgR3I/AAAAAAAAAq0/HBC9Rd9yczg/s1600/PNL-Libro.jpg" height="124" width="200" /></a></div><br /><b>Wi-Fi Client State and Other Peculiarities</b> <br /><br />The PNL disclosure behavior is highly influenced by the Wi-Fi client state, such as if it is currently connected to a known Wi-Fi network, or if there are no well known networks in its vicinity. However, distinct clients and implementations behave differently, and even when connected, it is still possible for a client to disclose its PNL, while looking for more "interesting" known networks. Sometimes, they do when trying to connect to a new network, or when the network they were previously connected to disappears or the signal is low enough. Besides that, an attacker can also force a victim Wi-Fi client to disassociate from the current network, forcing it to disclose its PNL.<br /><br />Unfortunately, by default there are multiple Wi-Fi clients that continuously disclose their PNL in the air. Others, however, only disclose it sometimes. If you try to fix both of these scenarios, you suddenly realize this behavior is heavily influenced by several complex factors, such as the specific hardware used by the client, that is, the chipset used on its Wi-Fi interface or card, the firmware version, the version of its Wi-Fi drivers (used by the operating system to interact with the card),&nbsp;and the supplicant implementation (the Wi-Fi client capabilities at the software level). For example, I saw iOS 7.0.4 tended to disclose the PNL if running on an iPhone 4, but not on an iPhone 4S (even when running iOS 7.0.3), but iOS 6.1.3 didn't disclose it either when running on an iPad 3.<br /><br />New features introduced in modern Wi-Fi clients, such as the <a href="https://twitter.com/raulsiles/status/479315100378337281">MAC address randomization capabilities of iOS 8</a> when it scans for Wi-Fi networks, open the door to evaluating how effective this behavior is both from a privacy and security point of view, and promote <a href="https://twitter.com/raulsiles/status/514811201319342080">additional research</a>.<br /><br />As a result, while researching about why and when Wi-Fi clients disclose their PNL, I have found difficult to consistently reproduce some scenarios in which it's not very clear why the PNL has been revealed. A complex combination of factors is behind the root cause, such as the surrounding Wi-Fi networks and signal levels, the existence of hidden Wi-Fi networks nearby, the current state of the client mobile (2/3/4G) interface, the current and previous Wi-Fi client states and transitions, the PNL contents, and even if the device is getting power through a computer USB port or from a power plug... a very long list of sometimes unrepeatable facts. But the truth is that Wi-Fi clients still disclose their PNL.<br /><br />For all these reasons, it is required to design a very thorough methodology to evaluate why and when a target Wi-Fi client discloses its PNL. <br /><br /><b>Hidden Wi-Fi Networks</b><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-1cmRMQpEkwA/VOcAPMR6tEI/AAAAAAAAAqY/8ujT1XvOJhU/s1600/hidden.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-1cmRMQpEkwA/VOcAPMR6tEI/AAAAAAAAAqY/8ujT1XvOJhU/s1600/hidden.jpg" height="240" width="320" /></a></div><br />Hidden or non-broadcast Wi-Fi networks are one of the most common scenarios why Wi-Fi clients disclose their PNL. In fact, the only way a Wi-Fi client can connect to a hidden network is by disclosing its PNL. This is definitely one of the main reasons why you should never configure Wi-Fi networks as hidden (although still today there are people <a href="https://twitter.com/raulsiles/status/543730289256955904">recommending this as a best practice</a>), as this is not providing any effective security to the Wi-Fi infrastructure, but it is in fact exposing the Wi-Fi clients that connect to it.<br /><br />A very specific case related to mobile devices is when Wi-Fi networks are added manually to, for example, iOS or Android. In the case of mobile devices, <a href="http://blog.taddong.com/2013/04/how-to-add-wi-fi-networks-to-mobile.html">manually adding a Wi-Fi network</a>&nbsp;(<a href="http://blog.dinosec.com/p/security-advisories.html">check the various advisories I published during the last few years</a>) commonly implies this network will be considered as hidden by the device and, therefore, it will be disclosed. To sum up, if a Wi-Fi network (hidden or not) is manually added to a mobile device, there is a very high probably it will be disclosed by that Wi-Fi client.<br /><br /><b>Case Study: iOS 5.x</b> <br /><br />On early 2012 I discovered a scenario where Apple devices based on iOS 5.x (at that time), like iPhones and iPads, fully disclose their PNL (including both hidden and visible networks) every 45 seconds when they enter sleep mode (also referred as suspend or standby mode). Therefore, an attacker can force a victim device to disclose its PNL if he has temporary physical access to it, making the device going to sleep by pressing the power (or Sleep/Wake) button, the device owner can make the device to enter standby mode by its own, or even the device will do it automatically after not being used for a few minutes, depending on its settings.<br /><br />I can briefly mention this vulnerability at this point as the impact today is clearly low, due to the existence of newer iOS versions, and because this is still the default behavior of lots of Wi-Fi clients.<br /><br /><b><span style="font-size: large;">Managing the PNL</span></b><br /><br />On the one hand, some Wi-Fi clients allow you to manage their PNL, such as Android 4.x devices although it would be great to be able to prioritize the entries in the PNL or identify if they correspond to hidden or visible networks. On the other hand, other widely used Wi-Fi clients, such as Apple devices running iOS, do not provide capabilities to manage it. Therefore workarounds are required in case you want to easily remove some entries from the PNL, such as using <a href="http://www.dinosec.com/en/lab.html#iStupid">iStupid</a>. Although this seems to only affect mobile devices or other "dumb things" from IoT (Internet of Things) with Wi-Fi client capabilities, this is not always the case and surprisingly, even modern operating systems used in traditional computing might be affected, taking a step back.<br /><br /><b>Case Study: Windows 8 &amp; 8.1</b><br /><br />Another more traditional scenario where managing the PNL has taken a step back is Windows 8 (even if it does not disclose the PNL by default, you may want to edit or remove previously added hidden networks). If you thought the already mentioned issues were just affecting mobile or embedded devices nowadays, it is not the case. Although in Windows 7 it was trivial to manage the PNL via the <a href="http://windows.microsoft.com/en-au/windows/create-modify-network-profiles#1TC=windows-7">Wireless Profile Manager (for Windows 7)</a>, these capabilities were removed from the graphical user interface (GUI) in Windows 8. As a result, you can only view or remove a network from the PNL from the Wireless Network List if it is currently in range (as it is the case with iOS devices); remember you can always use <a href="http://www.dinosec.com/en/lab.html#iStupid">iStupid</a> [0] to help you making those faraway networks reappear ;-)<br /><br />The other options available to manage the PNL in Windows 8 are through third-party tools, such as <a href="http://www.thewindowsclub.com/wifi-profile-manager-windows-8">WiFi Profile Manager 8</a> or <a href="http://winaero.com/blog/how-to-manage-wireless-networks-in-windows-8-1-and-windows-8-using-classic-shell/">Classic Shell</a>, using <a href="http://windows.microsoft.com/en-us/windows-8/manage-wireless-network-profiles">the command prompt</a> via "netsh" (including managing the <a href="http://www.thewindowsclub.com/view-change-wireless-network-connection-priority-windows-8">priority of networks within the PNL</a>), or manually, by accessing or removing the XML files where the Wi-Fi networks profiles are stored: "C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\{Interface-ID}\{Profile-ID}".<br /><br /><a href="http://windows.microsoft.com/en-us/windows-8/manage-wireless-network-profiles">Windows 8.1 has slightly improved the manageability of the PNL</a>. Although it does not include full capabilities as Windows 7, at least from the "Settings - Change PC settings - Networks - Connections" menu it is possible to manage and change some properties for each PNL entry. Still, <a href="http://windows.microsoft.com/en-us/windows-8/manage-wireless-network-profiles">to delete an entry you need to go to the command prompt</a> and execute the "netsh" tool (probably an alternative not suitable for the average user). <br /><br /><span style="font-size: x-small;">[0] For the sharp reader, there are newer versions of iStupid in DinoSec Lab, apart from v1.0, waiting for you :-)</span><br /><br /><b><span style="font-size: large;">Security &amp; Privacy Risks and Implications of Disclosing the Wi-Fi PNL</span></b><br /><br />Finally, as it seems vendors and manufacturers of Wi-Fi products with client capabilities still do not take this issue seriously, we need to evaluate what are the real privacy and security risks of disclosing the PNL, that is, letting everyone know what are the Wi-Fi networks the Wi-Fi client device wants to connect to.<br /><br /><b>Privacy</b><br /><br />On the one hand,&nbsp;an attacker can gather the PNL details to exclusively fingerprint a Wi-Fi client, with direct privacy implications. The fingerprinting process is based on identifying a very unique network name (SSID) used by that client, match that SSID to the client Wi-Fi MAC address, and be able to track its common locations and activities. If a very unique SSID is not found, most probably the Wi-Fi client will disclose a unique set of SSIDs. Even if some of these SSIDs are commonly used by millions of users, the whole set of SSIDs of a given client PNL tends to be a good distinguishing factor (even when the MAC address is randomized). This fingerprinting capabilities definitely help to launch very targeted attacks against key individuals, such as a high level executives of a given target organization.<br /><br />Changing the default SSID and selecting a unique value is a positive countermeasure when protecting the Wi-Fi infrastructure, and in particular WPA(2)-PSK networks, as it acts as a deterrent against pre-calculated (<i>raibowtable</i>) password attacks on the PSK, because the master key (PMK) is based on the SSID (it acts as a salt). However, when talking about Wi-Fi clients, that unique SSID can help to identify a specific target.<br /><br /><b>Security</b><br /><br />On the other hand, an attacker can gather the PNL details with the goal of impersonating one of the legitimate networks the client is trying to connect to, and as a result, get the Wi-Fi client to effectively connect to the attacker's infrastructure automatically, with serious security implications. In future installments of this series we will provide more details about these attacks, no matter what security mechanism is used by the legitimate Wi-Fi network (Open, WEP, WPA(2)-PSK, or WPA(2)-Enterprise). At this point, the victim client is sharing the network (at layer 1&amp;2 and above) with the attacker. This is, at least, scary and opens the door to several direct and Man-in-the-Middle (MitM) attacks!<br /><br />It is time to take this issue very seriously and responsibly address it, specially considering the impact it will have with the<a href="http://www.huffingtonpost.com/vala-afshar/50-incredible-wifi-tech-s_b_4775837.html"> upcoming industry trend</a> associated to the Internet of Things (IoT) or Internet of Everything (IoE), and the enhanced Wi-Fi bandwidth capabilities of 802.11ac networks. More and more, critical devices and gadgets used on a daily basis are going to provide Internet and data communication capabilities, some of them through LAN/Ethernet ports, but I foresee most of them (to get away of the uncomfortable wires) through a Wi-Fi interface.<br /><br /><b><span style="font-size: large;">Solutions</span></b><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-SXWcZibRoZo/VOcAnYWR7WI/AAAAAAAAAqg/LUJLAZQAUz4/s1600/wifi%2Bfixing.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-SXWcZibRoZo/VOcAnYWR7WI/AAAAAAAAAqg/LUJLAZQAUz4/s1600/wifi%2Bfixing.PNG" /></a></div><br />The sort term solution is to start evaluating if your personal, or your organization, Wi-Fi client devices disclose their PNL through specific Wi-Fi assessments and research. By Wi-Fi client devices I mean everything that has Wi-Fi client capabilities, from mobile devices to "everything" (IoT) in the residential, corporate, and mobile environments. If they disclose their PNL, at least you know it and can take informed security decisions, although there is not to much you can do if the vendor does not fix it, apart from carefully and diligently managing your PNL. Try to reduce the number of entries in the PNL and be sure all the known networks are using robust security... because you, or your organization employees, never ever connect to a free and open Wi-Fi hotspot, right?<br /><br />The mid term solution is to implement some of the tools or solutions currently available that try to change the default behavior of some Wi-Fi client platforms, such as <a href="https://www.kismetwireless.net/android-swm/">Smarter Wi-Fi Manager</a> or <a href="https://play.google.com/store/apps/details?id=be.uhasselt.privacypolice">Wi-Fi Privacy Police</a> for Android mobile devices, to name a couple.<br /><br />The long term solution is to promote a modification (I'm making this request public here!) of the next version of the IEEE 802.11 specification to, on the one hand, completely remove the existence of hidden Wi-Fi networks (Wi-Fi access points shouldn’t provide an option to configure a Wi-Fi network as hidden, and Wi-Fi clients should never allow users to add a Wi-Fi network as hidden), and on the other hand, mandate that Wi-Fi clients must never check for the availability of the specific Wi-Fi networks contained in their PNL through directed Probe Request frames. Instead, Wi-Fi clients must always discover the surrounding networks by sending a generic (or broadcast) Probe Request frame with a wildcard (or empty) SSID.<br /><br /><br /><span style="font-size: x-small;"><u><i>NOTE</i></u>: For the record, this year updated </span><span style="font-size: x-small;"><span style="font-size: x-small;"><a href="https://www.rootedcon.com/rlab38-tecnicas-de-ataque-sobre-clientes-wi-fi/">"<i>Técnicas de ataque sobre clientes Wi-Fi</i>"</a> </span>session, <a href="https://www.rootedcon.com/rlab38-tecnicas-de-ataque-sobre-clientes-wi-fi/">2015 RootedLab</a>, complements the workshops I run in RootedCON on previous years, <a href="https://sites.google.com/a/rootedcon.es/rootedlabs2011/labs-y-trainers/taddong-seguridad-en-bluetooth-wi-fi-gsm-y-gprs">2011 RootedLab, "<i>Seguridad en Bluetooth, Wi-Fi, GSM y GPRS</i>"</a>, the <a href="https://sites.google.com/a/rootedcon.es/rootedlabs2012/labs-y-trainers/raul-siles---analizando-y-explotando-aplicaciones-web-con-samurai-wtf">2012 RootedLab, "<i>Analizando y explotando aplicaciones web con Samurai-WTF</i>"</a>, and the <a href="http://www.rootedcon.es/index.php/tecnicas-de-ataque-sobre-clientes-wi-fi/">2014 RootedLab</a>, "<i>Técnicas de ataque sobre clientes Wi-Fi</i>" (all 2014 links have been removed from the official website).</span>Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com2tag:blogger.com,1999:blog-2450054937036373903.post-23212903666907580572015-02-06T00:00:00.000-08:002018-10-24T04:10:07.257-07:00iOS Passcode Recovery with iPhone Data Protection Tools (Using Yosemite)<i><u>Shameless plug</u></i>: During the first half of this year <span style="font-family: inherit;"><span lang="EN-US">I will be teaching the 6-day SANS SEC575 training, "SEC575: Mobile Device Security and Ethical Hacking", in <a href="http://www.sans.org/event/secure-europe-2015/course/mobile-device-security-ethical-hacking"><span style="font-family: inherit;">Amsterdam</span>,<span style="font-family: inherit;"> Netherlands</span> (M<span style="font-family: inherit;">a</span>y 11-16, 201<span style="font-family: inherit;">5</span>)</a>, <a href="http://one-esecurity.com/es/SANS/Calendario/2015.php">Madrid, Spain (May 25-30<span style="font-family: inherit;">, 2015 in Spanish</span>)</a>, and <a href="http://www.sans.org/event/london-in-the-summer-2015/course/mobile-device-security-ethical-hacking"><span style="font-family: inherit;">London</span>, <span style="font-family: inherit;">UK</span> (Ju<span style="font-family: inherit;">ly</span> 1<span style="font-family: inherit;">3</span>-18, 201<span style="font-family: inherit;">5</span>)</a>.</span></span> <br /><br /><u>UPDATE</u>: Xcode 6.2 (March 9, 2015).<br /><br />Since the early days when the <a href="http://www.sans.org/sec575">SANS </a><span style="font-family: inherit;"><span lang="EN-US"><a href="http://www.sans.org/sec575">"SEC575: Mobile Device Security and Ethical Hacking"</a> class <span style="font-family: inherit;">made its debut around </span></span></span><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;"><a href="http://www.sans.org/training_events/archives/">May 2012</a></span>, <a href="http://www.willhackforsushi.com/">Joshua Wright</a>, <span style="font-family: inherit;">the SEC575</span> author, included<span style="font-family: inherit;"> details</span> <span style="font-family: inherit;">f</span>or the <a href="https://code.google.com/p/iphone-dataprotection/">iPhone Data Protection Tools</a> presented at HITB 2011 in Amsterdam.</span></span><br /><br /><span style="font-family: inherit;"><span lang="EN-US">We cover <span style="font-family: inherit;">t</span>his toolset <span style="font-family: inherit;">in</span> SEC575 during the "Mitigating the Stolen (or Lost) Device Thread" section on day 2. We l<span style="font-family: inherit;">ik</span>e not only covering the tool internals, but are used to run a live demo in class showing attendees how the tool works and how easy it is to obtain a 4-digit passcode in a few minutes without leaving any significant <span style="font-family: inherit;">trace on the mobile device</span>. I particularly l<span style="font-family: inherit;">ove</span> to run <span style="font-family: inherit;">the</span> live demo and go deeper into the technical details about how the built-in <a href="https://www.apple.com/privacy/docs/iOS_Security_Guide_Oct_2014.pdf">iOS full device encry</a><span style="font-family: inherit;"><a href="https://www.apple.com/privacy/docs/iOS_Security_Guide_Oct_2014.pdf">ption and data protection</a> is implemented, the impact of firmware/hardware vulnerabilities (such as the <a href="https://theiphonewiki.com/wiki/Bootrom"><span style="font-family: inherit;">b</span>oot<span style="font-family: inherit;">rom</span></a> vulnerability leveraged by the by <a href="http://theiphonewiki.com/wiki/Limera1n">l<span style="font-family: inherit;">i</span>mera<span style="font-family: inherit;">1</span>n's exploitation</a> process), the importance of software and hardware security updates, and how the full keychain contents can be decrypted once the passcode is </span></span></span><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;"><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;">obtained, exposing multiple sensitive user credentials</span></span></span>. <span style="font-family: inherit;">A</span>lthough this <span style="font-family: inherit;">particular </span>attack (based on limera1n) can only be launched against <span style="font-family: inherit;">Apple devices up to the iPhone 4 and the iPa<span style="font-family: inherit;">d <span style="font-family: inherit;">1</span> (using the vulnerable <a href="http://iossupportmatrix.com/">Apple A4 SoC</a>), </span></span>it can be used to empha<span style="font-family: inherit;">size </span>the attack possibilities and impact of</span></span></span><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;"><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;"> </span></span></span></span></span></span><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;"><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;"><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;">future </span></span></span></span></span></span>similar vulnerabilities in <span style="font-family: inherit;">other modern</span> Apple devices.</span></span></span><br /><br /><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;"><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;">Definitely, running this kind of impressive attack demos in fron<span style="font-family: inherit;">t of C-level executives </span></span></span>really help to make the point and create individual users, and corporate, awareness regarding the risks of using 4-di<span style="font-family: inherit;">git passcodes, or leaving mobile devices unattended for a few minutes (due to a<span style="font-family: inherit;">n urgent phone call<span style="font-family: inherit;"> or</span> meeting, etc) or more (a tablet left in a hotel room during dinner, etc).</span></span></span> Fo<span style="font-family: inherit;">r this reason, </span></span></span></span>a</span>part from covering the attack details and running the demo in class, in order for the attendees to be able to reproduce it, the SEC575 DVD contains a th<span style="font-family: inherit;">oroug<span style="font-family: inherit;">h</span> step-by-step <span style="font-family: inherit;">guide</span> describing how to prepare yo<span style="font-family: inherit;">ur OS X pen-testing syste<span style="font-family: inherit;">m to launc<span style="font-family: inherit;">h the attack.</span></span></span> </span>Originally, the g<span style="font-family: inherit;">uide </span>was available for OS X Lion (10.7) <span style="font-family: inherit;">and</span> we updated it for OS X Mountain Lion (10.8) a few months later.&nbsp;</span></span></span><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-Njoh993S1_E/VM66GQuu7fI/AAAAAAAAApk/xpbRf59kqGU/s1600/iPhone_iDPT.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-Njoh993S1_E/VM66GQuu7fI/AAAAAAAAApk/xpbRf59kqGU/s1600/iPhone_iDPT.png" height="400" width="230" /></a></div><br /><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;">H<span style="font-family: inherit;">owever, </span>due to the fact this is an "old" attack, one of the most challenging tasks over the years is making it work with the latest operating system versions, libraries and modules, development frameworks and languages, and <span style="font-family: inherit;">other required dependencies</span>. For this same reason, I have recently updated t<span style="font-family: inherit;">he guide for OS X Yosemite (10.10), so that you can demo<span style="font-family: inherit;">nstrate the attac<span style="font-family: inherit;">k still today if you are running the latest OS X version, and we are making it public out of the SEC575 realm (perhaps reaching out to potential future SEC575 candidates):</span></span></span></span></span></span><br /><ul><li><a href="http://www.dinosec.com/docs/Apple%20iOS%20Key%20Recovery%20with%20iPhone%20Data%20Protection%20Tools%2020121003.pdf"><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;">Apple iOS Key Recovery with iPhone Data Protection Tools (Using <span style="font-family: inherit;">Mountain Lion</span>) - 10/30/2012</span></span></span></span></span></span></span></a></li><li><span style="font-family: inherit;"><span lang="EN-US"><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;"><a href="http://www.dinosec.com/docs/Apple%20iOS%20Key%20Recovery%20with%20iPhone%20Data%20Protection%20Tools%20-%20Using%20Yosemite%2020150125.pdf"><span style="font-family: inherit;">Apple iOS Key Recovery with iPhone Data Protection Tools (Using Yosemite) - 01/25/2015</span></a> </span></span></span></span></span></span></li></ul><span style="font-family: inherit;"><span lang="EN-US">This new version of the guide <span style="font-family: inherit;">w</span>as<span style="font-family: inherit;"> </span>tested under OS X Yosemite (10.10.1), the <span style="font-family: inherit;">associated official</span> Xcode version (6.1.1) and <span style="font-family: inherit;"><span style="font-family: inherit;">using</span> a couple of target mobile devices,</span> an iPad 1 (<span style="font-family: inherit;">running</span> iOS 5.1.1) and an iPhone 4 (<span style="font-family: inherit;">running</span> iOS 7.0.4).</span></span><br /><span style="font-family: inherit;"><span lang="EN-US">&nbsp;</span></span><br /><u><b>Is Your Xcode Environment Vulnerable?</b></u><br /><br /><u>UPDATE</u>: Finally, on March 9, 2015, <a href="https://support.apple.com/en-us/HT204427">Apple released Xcode 6.2</a> fixing the following Git vulnerability (CVE-2014-9390) after more than two and a half months. The new default Git version is "1.9.5 (Apple Git-50.3)".<br /><br />On December 18, 2014, <a href="http://git-blame.blogspot.com.es/2014/12/git-1856-195-205-214-and-221-and.html">a vulnerability in Git was released (CVE-2014-9390; in reality this CVE includes three vulnerabilities)</a>, affecting multiple Git versions both for Windows and Mac OS X Git clients. It allows remote code execution by rewriting the contents of the ".git" directory, such as the "config" file or the "hooks" sub-directory, for example, through "git pull" or "git checkout" operations. <a href="http://blogs.msdn.com/b/bharry/archive/2014/12/18/git-vulnerability-with-git-config.aspx">Microsoft released patches for their different Git implementations</a>, <a href="https://github.com/blog/1938-vulnerability-announced-update-your-git-clients">GitHub also updated their GitHub for Windows and GitHub for Mac clients</a>, and <a href="http://support.apple.com/en-us/HT204147">Apple addressed it in Xcode 6.2 beta 3</a>.<br /><br />On early January 2015 <a href="https://community.rapid7.com/community/metasploit/blog/2015/01/01/12-days-of-haxmas-exploiting-cve-2014-9390-in-git-and-mercurial">a Metasploit module was released</a> to exploit this specific vulnerability through <a href="http://www.rapid7.com/db/modules/exploit/multi/http/git_client_command_exec">an HTTP server designed to simulate a Git repository</a>.<br /><br />If you are an Apple developer, I expect you to update your Xcode environment frequently to be able to benefit and test the latest features, including the iOS 8.2 SDK with WatchKit support (for Apple Watch) in Xcode 6.2 beta versions. But if you are a security professional and use Xcode for security testing, for tasks like the ones described in this blog post, your Xcode environment might be vulnerable.<br /><br />At the time of this writing, end of January 2015, the latest official Xcode version available through the App Store is Xcode 6.1.1 (released on Dec 02, 2014). This Xcode version still uses Git v1.9.3 and it is still vulnerable (for almost one and a half months) to CVE-2014-9390:<br /><br /><span style="font-size: small;"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">$ git --version<br />git version 1.9.3 (Apple Git-50)</span></span><br /><br />In order to install Xcode 6.2 beta 3 (or later beta versions) you need to <a href="https://developer.apple.com/xcode/downloads/">manually download Xcode</a> using a free (or paid) Apple developer account, and proceed with the installation. The Xcode beta version goes into "/Applications/Xcode-Beta.app" (vs. the default "/Applications/Xcode.app" directory). However, even when the beta version has been installed, the Xcode command-line tools (of which Git is part of) will still use the official Xcode version. To switch between the different versions of the Xcode command-line tools, you need use the xcode-select tool (as root):<br /><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">$ git --version<br />git version 1.9.3 (Apple Git-50)</span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">$ xcode-select -p<br />/Applications/<b>Xcode.app</b>/Contents/Developer</span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">$ sudo xcode-select --switch /Applications/Xcode-Beta.app/</span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">$ xcode-select -p<br />/Applications/<b>Xcode-Beta.app</b>/Contents/Developer</span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">$ sudo xcodebuild -license</span><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">$ git --version<br />git version 1.9.5 (Apple Git-50.3)</span><br /><br />Therefore, the Git version for Xcode 6.2 beta 4 is 1.9.5, not vulnerable to CVE-2014-9390. Time to update your Xcode version!Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com0tag:blogger.com,1999:blog-2450054937036373903.post-26063059603080918242015-01-25T02:59:00.000-08:002018-10-24T04:10:07.688-07:00iOS: Back To The Future IILast year I disclosed publicly the <a href="http://blog.dinosec.com/2014/06/ios-back-to-future.html">"iOS: Bact to the Future"</a> vulnerability affecting iOS Apple devices, from version 5.x up to version 7.x (the video of the presentation is available <a href="https://www.youtube.com/watch?v=UMhGKXPOacw">in Spanish</a>, and <a href="https://www.youtube.com/watch?v=fgLkjtHzcDw">dubbed into English</a>). Anyone intercepting the target mobile device traffic could freeze a iOS victim device into its current operating system (OS) version forever. Once I notified Apple, in March last year they modified their update servers to behave differently when they identify a client request with a future date (in the "If-Modified-Since" header). As a result, the vulnerability could be still exploited but limited to freezing the iOS victim device into its current OS version till the next update is released, that is, bypassing the most recent updates available.<br /><br />In September 2014, Apple addressed the "iOS: Back to the Future" vulnerability in <a href="http://support.apple.com/kb/HT6441">iOS 8</a> and identified it with <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4383">CVE-2014-4383</a>. After doing some research I discovered that the changes introduced by Apple in iOS included similar checks as the ones previously described for the update servers but on the client side, in particular when iOS identifies a server response with a future date (in the "Last-Modified" header). However, again, the new verifications only check for future dates, opening the door to manipulating requests and responses with a date between the date of the last update and the current date.<br /><br />Therefore, last month I presented the current state-of-the-art for this vulnerability as <a href="http://www.dinosec.com/docs/iOS_Regreso_al_Futuro2-CCN-CERT_RaulSiles_DinoSec_v1.0.pdf">"iOS: Back to the Future II"</a>, emphasizing not only that nothing has changed from an exploitation perspective since March 1, 2014, but some deep thoughts about the fact that vulnerabilities might be supposedly fixed, even when a CVE gets assigned to them, but perhaps they are not. Perhaps involving the researchers in the verification process for the fix might help to confirm if the vulnerability is really solved...<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-y9yefHlYsQg/VMS3dTmCJBI/AAAAAAAAApI/8pPuiP3CMcg/s1600/bttf2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-y9yefHlYsQg/VMS3dTmCJBI/AAAAAAAAApI/8pPuiP3CMcg/s1600/bttf2.png" height="153" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-xdFcBogy0CQ/VMS2xSaz_8I/AAAAAAAAAo4/87CvpAqOw2c/s1600/bttf2logo.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><br /></a></div>Although the presentation is in Spanish, I think you can easily follow the timelines on slides 11 and 19, and the technical details on slides 12, 14, 16 and 17.<br /><br />The following videos demonstrate the current iOS 8.x behavior in different exploitation scenarios:<br /><br />1. The <a href="https://www.youtube.com/watch?v=wCf2gb8AW1A">first video</a> shows an iPhone device running iOS 8.0.2 attacked using the StarWars (Jedi) temporary variant, although the most recent iOS version available is 8.1:<br /><div style="text-align: center;"><br /><iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/wCf2gb8AW1A" width="560"></iframe></div><br />2. The <a href="https://www.youtube.com/watch?v=cU1Y1Hl91L4">second video</a> shows an iPhone device running iOS 8.0.2 attacked using the Matrix permanent variant (as if iOS 8.0 were the most recent version on 07 Nov 2014), although the most recent iOS version available is 8.1 (officially published on 20 Oct 2014):<br /><div style="text-align: center;"><br /><iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/cU1Y1Hl91L4" width="560"></iframe></div><br />3. The <a href="https://www.youtube.com/watch?v=TBLcUS0FcrY">third video</a> shows how the update server replies with the current update when receiving a request with a date in the future (07 Nov 2024), and how when an iPhone device running iOS 8.0.2 is attacked using the Matrix permanent variant (with a response using a date in the future, year 2024), it does not process it, requesting subsequent updates from scratch. The most recent iOS version available is 8.1 (officially published on 20 Oct 2014):<br /><div style="text-align: center;"><br /><iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/TBLcUS0FcrY" width="560"></iframe></div><br />4. The <a href="https://www.youtube.com/watch?v=1GInTgmQPhs">fourth video</a> shows how a previous victim iPhone device running iOS 8.0.2 is manually forced (on purpose, "07 Sep 2014") to discover the most recent iOS version available, 8.1 (officially published on 20 Oct 2014) and it even downloads the current update documentation. Then, it is attacked again using the Matrix permanent variant (as if iOS 8.0 were the most recent version on 07 Nov 2014), and it becomes a victim again:<br /><div style="text-align: center;"><br /><iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/1GInTgmQPhs" width="560"></iframe></div><br />5. The <a href="https://www.youtube.com/watch?v=2BPUKSETh-s">fifth video</a> shows how the attack is not possible once the victim iPhone device has already downloaded the most recent update (e.g. iOS 8.1), as it does not even try to check for new updates till the local pending update gets installed:<br /><div style="text-align: center;"><br /><iframe allowfullscreen="" frameborder="0" height="315" src="//www.youtube.com/embed/2BPUKSETh-s" width="560"></iframe></div><br />Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com0tag:blogger.com,1999:blog-2450054937036373903.post-55437888467185914102014-10-13T02:14:00.000-07:002018-10-24T04:10:08.090-07:00Attacking Wi-Fi Clients: IntroductionDuring the last decade, an uncountable number of articles, whitepapers and presentations have been published about Wi-Fi security, hacking, attacks and defenses. Most of that research, including attack techniques and tools, has focused on the infrastructure side, that is, Wi-Fi access points (APs) and networks. These have been the main targets since the early WEP weaknesses announced around 2001. As the Wi-Fi technologies matured, and assuming nowadays (with the right skills and knowledge) it is possible to build a robust and reasonably secure Wi-Fi network, Wi-Fi attacks started to move towards the client side a few years ago. However, despite Wi-Fi client attacks got some early attention around 2005 (thanks to <a href="http://www.theta44.org/karma/">Karma</a>), they blurred over the years. Attacks focused on the Wi-Fi clients have evolved slowly, progressively, sometimes silently but significantly since then, nevertheless from an end user awareness perspective, corporate security perspective, or even from the point of view of major industry leaders and vendors, they have not been taken seriously enough. The reality is that, still today, Wi-Fi clients present multiple vulnerable behaviors that can be leveraged for targeted attacks or even mass exploitation. The situation can only get worse in the upcoming Internet of Things (IoT) or <a href="http://www.wi-fi.org/connectyourlife">the Wi-Fi Internet of Everything (IoE)</a> age:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-6ecBjEux-fI/VDr5jfqYFPI/AAAAAAAAAmM/w8t5o_x81hU/s1600/IoE_Graphic.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-6ecBjEux-fI/VDr5jfqYFPI/AAAAAAAAAmM/w8t5o_x81hU/s1600/IoE_Graphic.jpg" height="391" width="400" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-yiB-R4Mmmus/VDr5kE872wI/AAAAAAAAAmU/RO_7C-9ale0/s1600/Wi-Fi_Connect_your_life.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-yiB-R4Mmmus/VDr5kE872wI/AAAAAAAAAmU/RO_7C-9ale0/s1600/Wi-Fi_Connect_your_life.jpg" height="400" width="381" /></a></div><div style="text-align: center;"><br /></div>On the one hand, the current Wi-Fi client vulnerabilities and misbehaviors might allow an attacker (or pen-tester; I will use the term 'attacker' from now on) to accurately fingerprint specific targets, with significant personal privacy and tracking implications. On the other hand, they can be used to force a victim Wi-Fi client to reveal the networks it is trying to connect to, their security type, and even the associated Wi-Fi network key or user credentials. Additionally, the attacker might force the target Wi-Fi client to connect to its own network, an scenario that opens the door to a huge range of traditional network-based attacks. <br /><br />The following list briefly outlines multiple aspects that are relevant when describing these kind of Wi-Fi client weaknesses and attacks. These topics are going to be covered in future installments of this "Attacking Wi-Fi Clients" DinoSec blog post series, following this introduction: <br /><ul><li>First of all, it is crucial to understand how modern Wi-Fi clients behave, discover and connect to Wi-Fi networks, including the different options available for the end user to select a new network, as well as the technical details and 802.11 frames involved in the process.</li><li>One critical element that is involved in that selection and connection process is the Preferred Network List (PNL), that is, a local client repository (or database) that contains the list of known Wi-Fi networks the client has connected to in the past.</li><li>From a security perspective, the way the PNL is used by Wi-Fi clients determines the attack opportunities. Multiple factors influence the PNL usage, including if the client connects automatically to known networks, which network is selected when multiple known networks are available, what specific Wi-Fi network details the identification process is based on, etc.</li><li>In addition to the PNL usage, the PNL management features available for the end user (or corporate environment) also determine the PNL contents and the defensive capabilities. Wi-Fi clients should provide features to fully manage the PNL, including its visualization, selecting the priority of the different networks available in the PNL, as well as management options to add, delete or edit all the properties of any Wi-Fi network contained inside the PNL. However, we are currently facing various challenges, such as anomalies to be able to properly manage the Wi-Fi PNL (Preferred Network List) in modern mobile devices, like iOS, or even in traditional operating systems whose previous versions had the required capabilities, like Windows 8. The iOS constraints can be partially overcome by skilled users or enterprises via the <a href="http://www.dinosec.com/en/lab.html#iStupid">iStupid tool</a> (that I already <a href="http://blog.taddong.com/2013/05/istupid.html">described</a> in several&nbsp;<a href="http://blog.taddong.com/2013/05/istupid-setup-basic-usage.html">previous</a> <a href="http://blog.taddong.com/2013/06/istupid-advanced-usage.html">blog posts</a>).</li><li>Unfortunately, and although some traditional Wi-Fi clients fixed this specific vulnerable behavior a few years ago, still today several Wi-Fi clients disclose the contents of their PNL for free. There are multiple scenarios and reasons where Wi-Fi clients unnecessarily reveal their PNL all over the air (the details will be covered latter in the series). For example, <a href="http://blog.dinosec.com/p/security-advisories.html">multiple vulnerabilities have been published since 2010</a> affecting modern mobile devices and the way a new Wi-Fi network is manually added by the user to the PNL through the user interface. Anyone monitoring the wireless traffic can easily obtain the details of the PNL, and as a result, identify the list of Wi-Fi networks the client device is trying to connect to.</li><li>The fact that Wi-Fi clients still disclose their PNL for free today, together with its MAC address, entails significant privacy implications and security risks. Although <a href="https://www.eff.org/deeplinks/2014/07/your-android-device-telling-world-where-youve-been">recently the EFF emphasized the associated privacy risks</a>, something we knew about <a href="http://www.willhackforsushi.com/?page_id=137">wireless pervasive technologies since around 2008</a>, the main concern must be centered on the security threats. Anyone that identifies the PNL of a given target, that is the list of Wi-Fi networks the client device is trying to connect to, can easily impersonate these legitimate networks through a fake AP. As a result, multiple attack scenarios are viable, depending on the security mechanisms used by the legitimate network. By the way, the legitimate Wi-Fi network security type can be easily identified using different impersonation techniques.</li><li>The simplest and easiest scenario is targeting an open Wi-Fi network, as only the network name is required to impersonate the legitimate network and get the victim client to automatically connect to it. However, even for the security conscious (or "paranoid") user, that never ever connects to an open (or WEP-based network), there are additional security risks to consider.</li><li>When a WEP or WPA(2)-PSK network is impersonated, the legitimate Wi-Fi network key is required for the victim client to establish a connection with the fake AP. There are two WEP-based attacks that can obtain the original key from the victim Wi-Fi client: Caffe-Latte and Hirte. Similarly, for WPA(2)-PSK networks it is possible to capture two frames of the initial 4-way WPA(2) handshake in an AP-less scenario with the goal of cracking the PSK via dictionary attacks or rainbowtables (for the name of that specific Wi-Fi network). These kind of attacks provide two benefits to the attacker: On the one hand, the valid key for the legitimate network can be obtained, therefore, if the location of that legitimate network is known or can be obtained through other methods, the attacker would be able to connect to it. On the other hand, the victim client will connect to the attacker's network regardless of where the attack is taking place.</li><li>Finally, Wi-Fi network impersonation attacks focusing specifically on Wi-Fi Enterprise networks based on 802.1x/EAP can use various offensive methods to obtain the user enterprise credentials, and once again, even get full client connectivity between the victim and the attacker (in some scenarios). The following handmade draft table shows four different Wi-Fi enterprise client attacks, including their main pros and cons, FreeRADIUS-WPE, EAP LEAP-Down, EAP Dumb-Down, and LEAP2PEAP Relay:</li></ul><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-RLyU0BE8pYE/VDaJ81J-KNI/AAAAAAAAAl8/FbGXtoQX2cw/s1600/Wi-Fi_Enterprise_Attacks.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-RLyU0BE8pYE/VDaJ81J-KNI/AAAAAAAAAl8/FbGXtoQX2cw/s1600/Wi-Fi_Enterprise_Attacks.png" height="457" width="640" /></a></div><ul><li>Once the network is shared at layer 1 &amp; 2 (and above) between the attacker and the victim, traditional full Man-in-the-Middle (MiTM) attacks are possible, via ARP poisoning and other TCP/IP (and upper protocols and services) tricks.</li><li>Besides attacking Wi-Fi clients using legitimate 802.11 traffic through a fake AP, it is possible to manipulate 802.11 frames to launch other types of attacks, such as Denail of Service (DoS) attacks affecting specific Wi-Fi chipsets, launch web-based injection attacks throughout 802.11 frames, or go deeper into the almost forgotten 802.11 driver attacks.</li><li>Finally, understanding in detail these weaknesses and attacks, as well as the associated countermeasures and defensive opportunities and alternatives both at the user and the enterprise level, is the only way to properly mitigate the risk against these real-world Wi-Fi client attacks.</li></ul>Some related contents are available on my RootedCON 2013 presentation, named "<a href="http://www.dinosec.com/docs/RootedCON2013_Taddong_RaulSiles-WiFi.pdf">Wi-Fi: Why iOS (Android &amp; others) Fail inexplicably</a>" (<a href="http://vimeo.com/70718776">video</a> available in Spanish), and several presentations that followed and were part of a subsequent awareness campaign I did at the end of 2013 and early 2014.<br /><br /><h3>How Can I Start Taking a Look At The Wi-Fi Client Activities Around Me?</h3>As this introduction is mainly theoretical, for the curious readers that cannot wait until the publication of the next blog post in this series and want to start taking a look at the Wi-Fi client activities around them, and the potential disclosure of the PNL from vulnerable Wi-Fi clients, there are a few options, depending on the operating system you plan to use: Linux, OS X or Windows<br /><br />In <b>Linux</b> you only need to have a Wi-Fi card that supports monitor (or RFMON) mode. Configure the card in monitor mode (via the "<a href="http://www.aircrack-ng.org/doku.php?id=airmon-ng">airmon-ng</a>" command available in the <a href="http://www.aircrack-ng.org/">aircrack-ng</a> suite, or by directly using the "iw phy <u>phy0</u> interface add <u>mon0</u> type monitor" command), and start using <a href="https://www.wireshark.org/">Wireshark</a> (or tshark from the command line) to <a href="http://wiki.wireshark.org/CaptureSetup/WLAN">capture the traffic from that specific Wi-Fi interface</a> (commonly identified as "mon0").<br /><br />In <b>OS X</b> you can follow similar steps when using<a href="http://wiki.wireshark.org/CaptureSetup/WLAN#Mac_OS_X"> the default 802.11 Airport Extreme Wi-Fi card</a>. From the "Capture - Options..." menu in Wireshark, by double clicking on the Wi-Fi card (commonly identified as "en1"), the interface can be configured in monitor mode via the "Capture packets in monitor mode" option.<br /><br />In <b>Windows</b>, although there have been significant constraints to put Wi-Fi cards in monitor mode in the past, thanks to <a href="https://www.acrylicwifi.com/">Acrylic Wi-Fi</a> you can configure its associated Wi-Fi driver in monitor mode for your built-in Wi-Fi card. By running Wireshark as Administrator, start capturing traffic from the Acrylic Wi-Fi driver, named with the prefix "Acrylic NDIS" followed by the name of your native Wi-Fi card in the "Capture Interfaces" windows in Wireshark (available from the "Capture -&gt; Interfaces..." menu). If you want to use tshark instead from the command line, using a command promt (cmd.exe) running as Administrator, run "tshark.exe" with the "-D" option to identify all the network interfaces available. The Acrylic Wi-Fi driver associated to your card (in this case, ID number 3) will look like this:<br /><span style="font-size: small;"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">...</span></span><br /><span style="font-size: small;"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">3. \\.\airpcap11_{ABC...-...-...DEF}-{012...-...-...789}-0000 (Acrylic NDIS &lt;your_Wi-Fi_card_name&gt;)</span></span><br /><br /><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-OW232oVmZrg/VDsQYyRIWSI/AAAAAAAAAm8/dWoC-NZBpkw/s1600/Wireshark_icon.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-OW232oVmZrg/VDsQYyRIWSI/AAAAAAAAAm8/dWoC-NZBpkw/s1600/Wireshark_icon.png" height="50" width="50" /></a></div><div style="text-align: center;"><br /></div>If you are using Wireshark, your favorite display filter in order to capture the 802.11 probe request frames that may disclose specific names for the Wi-Fi networks contained in the PNL of vulnerable Wi-Fi clients should be:<br /><br /><span style="font-size: small;"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">(wlan.fc.type_subtype == 0x04) &amp;&amp; !(wlan_mgt.ssid == "")</span></span><br /><br />If you are using tshark from the command line, you can use the following command in order to extract some of the most relevant details from the same interesting 802.11 probe request frames:<br /><br />(<i>Linux, OS X &amp; Windows</i>; simply change the Wi-Fi interface name with the "-i" option)<br /><span style="font-size: small;"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">C:\Temp&gt;tshark -i 3 -n -l -s 0 -T fields -E separator=, -E quote=d -e wlan.sa -e<br />&nbsp;radiotap.dbm_antsignal -e wlan_mgt.ssid -Y "wlan.fc.type_subtype == 4 and !(wla<br />n_mgt.ssid == \"\")"</span></span><br />or<br /><span style="font-size: small;"><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">$ sudo tshark -i mon0 ...</span></span><br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-QYC1hNb_Sg0/VDsRSwF_FHI/AAAAAAAAAnI/c7ORttd3OOo/s1600/tshark_Windows.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-QYC1hNb_Sg0/VDsRSwF_FHI/AAAAAAAAAnI/c7ORttd3OOo/s1600/tshark_Windows.png" height="387" width="640" /></a></div><br /><h3><i>Shameless Plug</i> - "Attacking Wi-Fi Clients: Hands-on Workshop"</h3>I have authored a hands-on technical workshop, called "Attacking Wi-Fi Clients" (or "<i>Técnicas de ataque sobre clientes Wi-Fi</i>" in Spanish), with the goal of bringing together real-world personal experience, research, and pen-testing tips &amp; tricks for Wi-Fi client attacks collected during the last few years. The workshop covers in-depth all the topics of the upcoming "Attacking Wi-Fi Clients" DinoSec blog post series (of which this is the first installment), and much more... The material is available in English and is delivered both in English or Spanish.<br /><br />This workshop&nbsp; focuses on providing the attendees real-world hands-on experience identifying and researching Wi-Fi clients weaknesses, and executing multiple Wi-Fi client attacks in different scenarios, with specific emphasis in the layer 2 802.11 and associated protocols, like 802.1x/EAP, versus more traditional TCP/IP client attacks. The attendees get their own Alfa Wi-Fi USB card (in particular the current best model identified for this kind of Wi-Fi client offensive activities) and leave the workshop with a fully functional virtual machine based environment ready for Wi-Fi pen-testing activities or deeper research and vulnerability discovery. At the end of the session, the defensive countermeasures required to mitigate the previously covered Wi-Fi attacks are also analyzed. The workshop is available in both a very intense one-day session (bootcamp style) or in a two-day extended format, that can be delivered in both security conferences and private onsite events (contact me if you are interested).<br /><br />The first sold-out workshop session took place during the <a href="https://www.rootedcon.es/">RootedCON</a> trainings (called RootedLabs) on March 3, 2014, with very good feedback from the audience. Recently, the workshop has been significantly updated for <a href="https://www.noconname.org/files/2014/NcN_2014-Tecnicas_ataque_clientes_Wi-Fi-Raul_Siles.pdf">an upcoming session</a> that will take place in about three weeks during the <a href="https://www.noconname.org/">NoConName</a> (NcN) <a href="https://www.noconname.org/#trainings">trainings</a> (October 30, 2014). The NcN workshop price includes a conference ticket, so... if you are in Spain at the end of this month and speak Spanish, you cannot miss it! :-) My goal by offering this highly specialized but affordable workshop is focused on helping to improve the overall quality of Wi-Fi security pen-tests and assessments, and in particular, in identifying the current Wi-Fi clients risks and threats, while promoting future additional related Wi-Fi research in the upcoming Wi-Fi Internet of Everything (IoE) era (contributing to the health and wealth of the Spanish security conferences and local security community is an added value :-) <br /><br /><span style="font-size: x-small;">Image source: http://www.wi-fi.org/sites/default/files/images/IoE_Graphic.jpg</span><br /><span style="font-size: x-small;">Image source: http://www.wi-fi.org/sites/default/files/images/Wi-Fi_Connect_your_life.jpg</span>Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com1tag:blogger.com,1999:blog-2450054937036373903.post-9722729313643975112014-09-24T03:42:00.000-07:002019-05-22T02:15:45.033-07:00Bypassing iOS Lock Screens: A Comprehensive Arsenal of Vulns<u><b>UPDATED</b></u>: Up to iOS 12.3 (May 22, 2019)<br /><br />The iOS mobile platform has been subject to numerous lock screen bypass vulnerabilities across multiple versions. Although Apple strives to fix these vulnerabilities in various updates to iOS (<a href="http://support.apple.com/kb/ht1222">http://support.apple.com/kb/ht1222</a>), it is important for information security professionals and pen testers to pay close attention to the current unfixed lock screen bypass scene at any given time, evaluate its risks, and promote enforcing physical security and tight access controls on iOS devices.<br /><br /><u><i>Shameless plug</i></u>: If you are interested in this kind of technical details and want to learn more, <a href="https://www.sans.org/instructors/raul-siles">Raul Siles will be teaching future SANS courses</a>, such as the 6-day "<a href="https://www.sans.org/event/london-november-2019/course/mobile-device-security-ethical-hacking">SANS SEC575: Mobile Device Security and Ethical Hacking</a>" course in <a href="https://www.sans.org/event/london-november-2019/course/mobile-device-security-ethical-hacking">London, UK (Nov 11-16, 2019)</a>&nbsp;or <a href="https://www.sans.org/event/paris-december-2019/course/mobile-device-security-ethical-hacking">Paris, France (Dec 2-7, 2019)</a>.<br /><br />Many pen testers tend to focus more on traffic or network activity analysis and attacks, Mobile Device Management (MDM) and back-end systems auditing, jailbreaking or rooting opportunities, or in-depth mobile applications analysis, leaving unattended scenarios with physical access to a target device, or the stolen or loss device threat. However, real incidents constantly confirm unattended or stolen devices with a lockscreen bypass vulnerability are a serious threat that should be included, or at least evaluated, when scoping a mobile pen testing exercise.<br /><br />Throughout the years, I've been researching, testing, and collecting a list of all these iOS lock screen bypass vulnerabilities for pen testing engagements, presentations, and training sessions. Some of them are related to other hardware components, such as the SmartCover or the SIM card, while others are purely driven by new software features and capabilities, such as Siri or the new Control Center in iOS 7. Some issues impact only iPads or just iPhones, while others affect them all. History ratifies it is hard for Apple to fully mitigate this threat, as the attack surface is significantly wide, and it even increases with newer versions of the iOS platform.<br /><br />The following list summarizes the history of all the lock screen bypass vulnerabilities that iOS has suffered from iOS 5 to the most recent iOS version (until the last update :-). It also includes links to demos and/or videos associated with each vulnerability. The vulnerabilities have been classified based on the iOS version that provides the appropriate fix. Therefore, iOS versions earlier than the one providing the fix are potentially effected by each vulnerability.<br /><br />The official number of screen lock bypass related vulnerabilities addressed in each major iOS version are:<br /><ul><li>iOS 5.x: 4 vulnerabilities.</li><li>iOS 6.x: 8 vulnerabilities.</li><li>iOS 7.x: 12 vulnerabilities.</li><li>iOS 8.x: 11 vulnerabilities.</li><li>iOS 9.x: 6 vulnerabilities.</li><li>iOS 10.x: 10 vulnerabilities.</li><li>iOS 11.x: 10 vulnerabilities.</li><li>iOS 12.x: 7 vulnerabilities (officially, so far!!!).</li></ul><br /><h3>iOS Lock Screen Bypass Vulnerability History</h3>The following list has been sorted by iOS version, starting first with a list of generic lock screen bypasses with no officially recognized CVE associated to them (only for this generic section, entries are sorted by date and the iOS version specified refers to the vulnerable iOS version):<br /><ul><li>Generic, not officially recognized by Apple, or still unfixed lock screen bypasses (the iOS version specified for each flaw is the latest version known to be vulnerable):</li><ul><li>&nbsp;Siri (iOS 5, iPhone 4S, Oct 2011): Full phone interaction via Siri and voice commands (send e-mails, make calls, calendar and contacts access, etc); could be avoided disabling Siri via Settings. Ref: <a href="http://www.triskt.com/word/2011/10/18/ios-5-siri-authentication-bypass/">http://www.triskt.com/word/2011/10/18/ios-5-siri-authentication-bypass/</a> Video: <a href="http://www.youtube.com/watch?v=UM0Ee4KW5-I">http://www.youtube.com/watch?v=UM0Ee4KW5-I</a></li><li>Digital picture frame (iOS 5, iPad, Oct 2011): Access to all photos from the lock screen; could be disabled via Settings. The digital picture frame is not available anymore since iOS 7. Ref: <a href="http://www.groovypost.com/howto/apple-ios-5-security-lock-down-private-photos-picture-frame/">http://www.groovypost.com/howto/apple-ios-5-security-lock-down-private-photos-picture-frame/</a></li><li>Phone &amp; Contacts access due to a race condition in SIM card insertion (iOS 5.0.1, iPhone, Feb 2012). Ref: <a href="http://www.cultofmac.com/147700/ios-5-security-flaw-allows-access-to-contacts-list-recent-calls-text-messages-without-passcode/">http://www.cultofmac.com/147700/ios-5-security-flaw-allows-access-to-contacts-list-recent-calls-text-messages-without-passcode/</a> Video: <a href="http://www.youtube.com/watch?v=Vhy9_bYVIwk">http://www.youtube.com/watch?v=Vhy9_bYVIwk</a> (5.0) Video: <a href="http://www.youtube.com/watch?v=eFfDR1T6mMg">http://www.youtube.com/watch?v=eFfDR1T6mMg</a> (5.0.1) Video: <a href="http://www.youtube.com/watch?v=IZqY1VaMr_A">http://www.youtube.com/watch?v=IZqY1VaMr_A</a></li><li>Quick camera access (iOS 5.1, iPhone 4S, Mar 2012): Allows taking pictures; camera icon also available in iOS 5 by double-pressing the Home button. This vulnerability still applies today to iOS 7 and can only be mitigated by restricting access to the camera via Settings. Ref: <a href="http://www.cnet.com/how-to/access-the-iphone-camera-from-the-lock-screen-even-quicker-on-ios-5-1/">http://www.cnet.com/how-to/access-the-iphone-camera-from-the-lock-screen-even-quicker-on-ios-5-1/</a></li><li>Emergency dialer screen (iOS 5.1.1, Jul 2012). Video: <a href="http://www.youtube.com/watch?v=12OoO9IdBH4">http://www.youtube.com/watch?v=12OoO9IdBH4</a></li><li>Access to photos via Control Center - Calculator (iOS 7 beta 1, Jun 2013). Video: <a href="http://www.youtube.com/watch?v=tTewm0V_5ts">http://www.youtube.com/watch?v=tTewm0V_5ts</a></li><li>Brute force attacks against incorrect passcode restrictions in Settings (iOS 6, iPad, Jun 2013). Ref: <a href="http://www.journaldulapin.com/2013/06/04/brute-force-attack-against-restrictions-code-is-possible-on-ios/">http://www.journaldulapin.com/2013/06/04/brute-force-attack-against-restrictions-code-is-possible-on-ios/</a> Video: <a href="http://www.youtube.com/watch?v=C6md792nMhY">http://www.youtube.com/watch?v=C6md792nMhY</a></li><li>Apple Touch ID bypass (iOS 7, iPhone 5S, Sep 2013). Ref: <a href="http://ccc.de/en/updates/2013/ccc-breaks-apple-touchid">http://ccc.de/en/updates/2013/ccc-breaks-apple-touchid</a> Video: <a href="http://vimeo.com/75324765">http://vimeo.com/75324765</a></li><li>Make calls via Voice Control (iOS 7, Apr 2014): Siri has to be disabled. Video: <a href="http://www.youtube.com/watch?v=0CNh_j46byA">http://www.youtube.com/watch?v=0CNh_j46byA</a></li><li>Bypass time delay for incorrect passcode attempts via iTunes Sync (iOS 7.0-7.1.2, Jun 2014). Video: <a href="http://www.youtube.com/watch?v=_rT7o_IXehk">http://www.youtube.com/watch?v=_rT7o_IXehk</a></li><li>Exceed the maximum number of failed passcode attempts from the Settings app by setting forward the current time (related to Settings but not to the lock screen; iOS 8.1, Oct 2014). Ref: <a href="http://phonerebel.com/new-ios-8-1-bypass-discovered/">http://phonerebel.com/new-ios-8-1-bypass-discovered/</a> Video: <a href="https://www.youtube.com/watch?v=JY-SbkwZuxU">https://www.youtube.com/watch?v=JY-SbkwZuxU</a> </li><li>Airplane mode via Control Center and missed call in Notification Center (iOS 7.1.1/7.1.2, Aug 2014): Access to last open app. Ref: <a href="http://phonerebel.com/how-to-bypass-ios-7-lockscreen/">http://phonerebel.com/how-to-bypass-ios-7-lockscreen/</a> Video: <a href="http://www.youtube.com/watch?v=Hg9Vy7XzGZY">http://www.youtube.com/watch?v=Hg9Vy7XzGZY</a> Although the official security content for iOS 8 does not mention a specific fix for this issue, in iOS 8 the vulnerability cannot be exploited. When the missed called notification is selected in airplane mode, it is removed from the Notification Center and the following message is displayed in the lock screen:</li></ul></ul><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-zzAcbVDzQak/VCG3izV56nI/AAAAAAAAAj4/bl4cFJlWnCY/s1600/iOS_call_airplane_mode.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://1.bp.blogspot.com/-zzAcbVDzQak/VCG3izV56nI/AAAAAAAAAj4/bl4cFJlWnCY/s1600/iOS_call_airplane_mode.png" width="213" /></a></div><ul><ul><li>Passcode "Merge App Service" bypass &amp; Siri (iOS 7.1.2, Sep 2014). Video: <a href="http://www.youtube.com/watch?v=9gBtJ5tyRgI">http://www.youtube.com/watch?v=9gBtJ5tyRgI</a></li><li>("Voice hacking") Several information leakages via Siri (iOS 7 &amp; iOS 8, Sep 2014): Post to Facebook, get contact details, see call history last 25), listen recent messages, and get full access to notes. It can be mitigated disabling Siri in the lock screen via Settings. Video: <a href="https://www.youtube.com/user/videosdebarraquito/videos">https://www.youtube.com/user/videosdebarraquito/videos</a> Video: <a href="http://www.youtube.com/watch?v=NTA8k4tyY78">http://www.youtube.com/watch?v=NTA8k4tyY78</a></li><li>Access to message creation, contacts and photos via Control Center and the Clock app (Alarm) when rotation is on (iOS 9 Beta 3, Jul 2015). It can be mitigated disabling Control Center in the lock screen. Video: <a href="https://www.youtube.com/watch?v=KEwZSpWT3sI">https://www.youtube.com/watch?v=KEwZSpWT3sI</a> Video: <a href="https://www.youtube.com/watch?v=_rAlOHo8f6I">https://www.youtube.com/watch?v=_rAlOHo8f6I</a></li><li>Siri lock screen bypass (iOS 10.0.1). Video: <a href="https://www.youtube.com/watch?v=EVO8ziXT79g">https://www.youtube.com/watch?v=EVO8ziXT79g</a> </li><li>Access to iMessages, contacts and photos via a FaceTime (or phone) call, a custom message and Siri (plus VoiceOver). Again, this bypass can be mitigated disabling Siri in the lock screen&nbsp;(iOS 10.1.1 &amp; 10.2Beta3 in iPhones and iPads, the discontinued iOS 9.3.5 - iPhone 4S, and back to iOS 8.3...). Video:&nbsp;<a href="https://www.youtube.com/watch?v=LWJG5I8xCDU">https://www.youtube.com/watch?v=LWJG5I8xCDU</a>&nbsp;Video:&nbsp;<a href="https://www.youtube.com/watch?v=hP3BMyrFBSs">https://www.youtube.com/watch?v=hP3BMyrFBSs</a>&nbsp;(Fixed in iOS 10.2, but not in previous iOS 9.x, or below, versions).</li><li>Siri allows accessing (by reading) the content of (hidden, via "show previews") notifications for third party apps from the lock screen (iOS 11.3 beta - March 20, 2018; similar to CVE-2017-13805 for iOS 11.1). Ref:&nbsp;<a href="https://macmagazine.com.br/2018/03/20/bug-de-privacidade-do-ios-faz-a-siri-ler-notificacoes-escondidas-na-tela-bloqueada/">https://macmagazine.com.br/2018/03/20/bug-de-privacidade-do-ios-faz-a-siri-ler-notificacoes-escondidas-na-tela-bloqueada/</a>&nbsp;Ref:&nbsp;<a href="https://www.macrumors.com/2018/03/22/apple-to-fix-siri-reading-hidden-notifications/">https://www.macrumors.com/2018/03/22/apple-to-fix-siri-reading-hidden-notifications/</a></li><li>iOS 11.x passcode bypass services and/or products (iOS 11.3?):</li><ul><li>Cellebrite 'Advanced Unlocking and Extraction Services': <a href="https://www.forbes.com/sites/thomasbrewster/2018/02/26/government-can-access-any-apple-iphone-cellebrite">https://www.forbes.com/sites/thomasbrewster/2018/02/26/government-can-access-any-apple-iphone-cellebrite</a> (<a href="https://media.cellebrite.com/wp-content/uploads/2017/12/advanced-unlocking-extraction-datasheet-jan2018.pdf">https://media.cellebrite.com/wp-content/uploads/2017/12/advanced-unlocking-extraction-datasheet-jan2018.pdf</a>)</li><li>Grayshift GrayKey: <a href="https://blog.malwarebytes.com/security-world/2018/03/graykey-iphone-unlocker-poses-serious-security-concerns/">https://blog.malwarebytes.com/security-world/2018/03/graykey-iphone-unlocker-poses-serious-security-concerns/</a>&nbsp;&amp; <a href="https://www.forbes.com/sites/thomasbrewster/2018/03/05/apple-iphone-x-graykey-hack/">https://www.forbes.com/sites/thomasbrewster/2018/03/05/apple-iphone-x-graykey-hack/</a>&nbsp;&amp; <a href="https://motherboard.vice.com/en_us/article/vbxxxd/unlock-iphone-ios11-graykey-grayshift-police">https://motherboard.vice.com/en_us/article/vbxxxd/unlock-iphone-ios11-graykey-grayshift-police</a> (<a href="https://graykey.grayshift.com/">https://graykey.grayshift.com</a>)</li></ul><li>iOS 12.1: Access to contacts via Siri, FaceTime and airplane mode from the lock screen. Video:&nbsp;<a href="https://www.youtube.com/watch?v=ojigFgwrtKs">https://www.youtube.com/watch?v=ojigFgwrtKs</a>&nbsp;(Fixed in iOS 12.1.1).</li></ul></ul>By iOS version:<br /><ul><li>iOS 5.0 (Oct 2011): <a href="http://support.apple.com/kb/HT4999">http://support.apple.com/kb/HT4999</a></li><ul><li>Home Screen switching between apps (CVE-2011-3431)</li></ul><li>iOS 5.0.1 (Nov 2011): <a href="http://support.apple.com/kb/HT5052">http://support.apple.com/kb/HT5052</a></li><ul><li>SmartCover (iPad 2 - CVE-2011-3440; SmartCover functionality could be disabled via Settings). Video: <a href="http://www.youtube.com/watch?v=NLgQ22naQhE">http://www.youtube.com/watch?v=NLgQ22naQhE</a></li></ul><li>iOS 5.1 (Mar 2012): <a href="http://support.apple.com/kb/HT5192">http://support.apple.com/kb/HT5192</a></li><ul><li>Race condition in gestures to bypass lock screen (CVE-2012-0644)</li><li>Siri in lock screen allows e-mail access (CVE-2012-0645) •&nbsp;</li></ul><li>iOS 5.1.1 (May 2012): <a href="http://support.apple.com/kb/HT5278">http://support.apple.com/kb/HT5278</a></li><ul><li>&nbsp;N/A </li></ul></ul><ul><li>iOS 6 (Sep 2012): <a href="http://support.apple.com/kb/HT5503">http://support.apple.com/kb/HT5503</a></li><ul><li>Access to last used app (CVE-2012-3735)</li><li>Screen lock bypass via termination of FaceTime calls (CVE-2012-3736)</li><li>Access to photos by spoofing the current time (CVE-2012-3737): Since iOS 5 (iPhone, Dec 2011), photos &amp; videos access from lock screen due to incorrect time setting. Ref: <a href="http://peekay.org/2011/12/31/incorrect-time-setting-could-leak-ios-5-album-pictures/">http://peekay.org/2011/12/31/incorrect-time-setting-could-leak-ios-5-album-pictures/</a> </li><li>Perform FaceTime calls and Contacts disclosure (CVE-2012-3738): Since iOS 5.0.1 (iPhone, Feb 2012), Voice Control from the emergency dialer screen allows access to Contacts (enumeration) and make FaceTime calls. Ref: <a href="http://peekay.org/2012/02/05/more-fun-with-locked-iphone-4/">http://peekay.org/2012/02/05/more-fun-with-locked-iphone-4/</a></li><li>Screen lock bypass via camera (CVE-2012-3739)</li><li>Screen lock bypass (CVE-2012-3740)</li></ul><li>iOS 6.0.1 (Nov 2012): <a href="http://support.apple.com/kb/HT5567">http://support.apple.com/kb/HT5567</a></li><ul><li>Passbook passes access (CVE-2012-3750). Ref: <a href="http://www.amsys.co.uk/2012/blog/passbook-a-security-flaw/">http://www.amsys.co.uk/2012/blog/passbook-a-security-flaw/</a></li></ul><li>iOS 6.1 (Jan 2013): <a href="http://support.apple.com/kb/HT5642">http://support.apple.com/kb/HT5642</a></li><ul><li>N/A</li></ul><li>iOS 6.1.3 (Mar 2013): <a href="http://support.apple.com/kb/HT5704">http://support.apple.com/kb/HT5704</a></li><ul><li>Emergency calls (CVE-2013-0980). Ref: <a href="http://www.zdnet.com/iphone-ipad-lock-screen-bypass-fixed-but-34-days-too-late-7000012829/">http://www.zdnet.com/iphone-ipad-lock-screen-bypass-fixed-but-34-days-too-late-7000012829/</a> Video: <a href="http://www.youtube.com/watch?v=sVV9S17mZpw">http://www.youtube.com/watch?v=sVV9S17mZpw</a> Video: <a href="http://www.youtube.com/watch?v=MDkLpj3MM-c">http://www.youtube.com/watch?v=MDkLpj3MM-c</a> &amp; iTunes Sync: Ref: <a href="http://www.vulnerability-lab.com/get_content.php?id=875">http://www.vulnerability-lab.com/get_content.php?id=875</a> Video: <a href="http://www.youtube.com/watch?v=oKOj0GMf810">http://www.youtube.com/watch?v=oKOj0GMf810</a></li></ul><li>iOS 6.1.6 (Feb 2014): <a href="http://support.apple.com/kb/HT6146">http://support.apple.com/kb/HT6146</a></li><ul><li>N/A </li></ul></ul><ul><li>iOS 7 (Sep 2013): <a href="http://support.apple.com/kb/HT5934">http://support.apple.com/kb/HT5934</a></li><ul><li>Screen lock bypass via SIM card ejection (CVE-2013-5147): via Voice Control. Video: <a href="http://www.youtube.com/watch?v=QCGJTuTZf8M">http://www.youtube.com/watch?v=QCGJTuTZf8M</a></li><li>View notifications in Lost Mode (CVE-2013-5153)</li></ul><li>iOS 7.0.2 (Sep 2013): <a href="http://support.apple.com/kb/HT5957">http://support.apple.com/kb/HT5957</a></li><ul><li>Make calls to any number (CVE-2013-5160). Video: <a href="http://www.youtube.com/watch?v=L_1Tary_Qoc">http://www.youtube.com/watch?v=L_1Tary_Qoc</a></li><li>Recently used apps &amp; photos (CVE-2013-5161). Video: <a href="http://www.youtube.com/watch?v=tTewm0V_5ts">http://www.youtube.com/watch?v=tTewm0V_5ts</a></li></ul><li>iOS 7.0.3 (Oct 2013): <a href="http://support.apple.com/kb/HT6010">http://support.apple.com/kb/HT6010</a></li><ul><li>Make calls to any number from the emergency dialer screen (CVE-2013-5144). Video: <a href="http://www.youtube.com/watch?v=7DbdRChmFFg">http://www.youtube.com/watch?v=7DbdRChmFFg</a> Video: <a href="http://www.youtube.com/watch?v=AUlhgsgRaXw">http://www.youtube.com/watch?v=AUlhgsgRaXw</a></li><li>Bypass time delay for incorrect passcode attempts (CVE-2013-5162)</li><li>Access &amp; Call arbitrary contacts via Siri and Facetime (CVE-2013-5164). Video: http://www.youtube.com/watch?v=fVpfdYYy1Dg Video: <a href="http://www.youtube.com/watch?v=AUlhgsgRaXw">http://www.youtube.com/watch?v=AUlhgsgRaXw</a></li></ul><li>iOS 7.0.4 (Nov 2013): <a href="http://support.apple.com/kb/HT6058">http://support.apple.com/kb/HT6058</a></li><ul><li>N/A</li></ul><li>iOS 7.0.6 (Feb 2014): <a href="http://support.apple.com/kb/HT6147">http://support.apple.com/kb/HT6147</a></li><ul><li>N/A</li></ul><li>iOS 7.1 (Mar 2014): http://support.apple.com/kb/HT6162</li><ul><li>FaceTime contacts (CVE-2014-1274). Video: <a href="http://www.youtube.com/watch?v=xYuO9k0_WBA">http://www.youtube.com/watch?v=xYuO9k0_WBA</a></li><li>Springboard during activation (CVE-2014-1285). Video: <a href="http://www.youtube.com/watch?v=FEC_s800A5A">http://www.youtube.com/watch?v=FEC_s800A5A</a></li><li>SpringBoard Lock Screen DoS (CVE-2014-1286)</li><li>Disable 'Find My iPhone' w/o iCloud credentials (CVE-2014-2019). Video: <a href="http://www.youtube.com/watch?v=QnPk4RRWjic">http://www.youtube.com/watch?v=QnPk4RRWjic</a></li></ul><li>iOS 7.1.1 (Apr 2014): <a href="http://support.apple.com/kb/HT6208">http://support.apple.com/kb/HT6208</a></li><ul><li>N/A</li></ul><li>iOS 7.1.2 (Jun 2014): <a href="http://support.apple.com/kb/HT6297">http://support.apple.com/kb/HT6297</a></li><ul><li>Access to contacts &amp; make calls via Siri (CVE-2014-1351). Video: <a href="http://www.youtube.com/watch?v=6cHZBk-eKps">http://www.youtube.com/watch?v=6cHZBk-eKps</a> </li></ul></ul><ul><li>iOS 8.0 (Sep 2014): <a href="http://support.apple.com/kb/HT6441">http://support.apple.com/kb/HT6441</a></li><ul><li>AssistiveTouch (CVE-2014-4368)</li><li>Determine which app is frontmost (CVE-2014-4361)</li><li>Home screen available during activation lock (CVE-2014-1360)</li><li>Text message previews (CVE-2014-4356)</li></ul><li>iOS 8.0.1 (Sep 2014): :-D</li><li>iOS 8.0.2 (Sep 2014): <a href="http://support.apple.com/kb/DL1758">http://support.apple.com/kb/DL1758</a></li><ul><li>N/A&nbsp;</li></ul><li>iOS 8.1 (Oct 2014): <a href="https://support.apple.com/kb/HT6541">https://support.apple.com/kb/HT6541</a></li><ul><li>N/A</li></ul><li>iOS 8.1.1 (Nov 2014): <a href="https://support.apple.com/en-us/HT6590">https://support.apple.com/en-us/HT6590</a></li><ul><li>Exceed the maximum number of failed passcode attempts (CVE-2014-4451 - affects iOS 6, 7 &amp; 8). Ref: <a href="http://technicalnotebook.com/software-bugs/apple-ios-bug-allowing-unlimited-incorrect-pin-attempts/">http://technicalnotebook.com/software-bugs/apple-ios-bug-allowing-unlimited-incorrect-pin-attempts/</a> Ref: <a href="http://www.darthnull.org/2014/11/18/ios-lockout-bypass">http://www.darthnull.org/2014/11/18/ios-lockout-bypass</a> Video: <a href="https://www.youtube.com/watch?v=2Bok9Zgas6g">https://www.youtube.com/watch?v=2Bok9Zgas6g</a></li><ul><li><a href="http://smarterforensics.com/2014/12/locked-ios-devices-hindering-your-investigations/">iP-BOX</a> is a hardware unlocking device that can be used to defeat 4 digit PINs in iOS devices (<a href="http://www.teeltech.com/wp-content/uploads/2014/11/IP-Box-documentation-rev2-1-16-2015.pdf">More technical details</a> at <a href="http://www.teeltech.com/mobile-device-forensic-tools/ip-box-iphone-password-unlock-tool/">TeelTech</a>). </li></ul><li>Access photos in the Photo Library via Leave a Message in FaceTime (CVE-2014-4463). Video: <a href="http://phonerebel.com/new-bypass-ios-8-1-lockscreen-access-photos-iphone-ipad-ipod-touch/">http://phonerebel.com/new-bypass-ios-8-1-lockscreen-access-photos-iphone-ipad-ipod-touch/</a></li></ul><li>iOS 8.2 (March 2015): <a href="https://support.apple.com/en-us/HT204423">https://support.apple.com/en-us/HT204423</a></li><ul><li>Springboard: Home screen available during activation (CVE-2015-1064)</li></ul><li>iOS 8.3 (April 2015): <a href="https://support.apple.com/en-us/HT204661">https://support.apple.com/en-us/HT204661</a></li><ul><li>QuickType (displayed on the lockscreen) could learn users' passcodes (CVE-2015-1106)</li><li>Prevent erasing the device after failed passcode attempts (CVE-2015-1107)</li><li>An attacker may exceed the maximum number of failed passcode attempts (CVE-2015-1108)&nbsp;</li></ul><li>iOS 8.4 (June 2015): <a href="https://support.apple.com/en-us/HT204941">https://support.apple.com/en-us/HT204941</a></li><ul><li>N/A</li></ul><li>iOS 8.4.1 (August 2015): <a href="https://support.apple.com/en-us/HT205030">https://support.apple.com/en-us/HT205030</a></li><ul><li>An attacker may be able to accept untrusted certificates from the lock screen (CVE-2015-3756)</li></ul></ul><ul><li>iOS 9.0 (Sep 2015): <a href="https://support.apple.com/en-us/HT205212">https://support.apple.com/en-us/HT205212</a></li><ul><li>Access notifications of content that is set not to be displayed at the lock screen via Siri (CVE-2015-5892)</li><li>Reply to audio messages from the lock screen when message previews are disabled (CVE-2015-5861)</li></ul><li>iOS 9.0.1 (Sep 2015): <a href="https://support.apple.com/kb/DL1842">https://support.apple.com/kb/DL1842</a></li><ul><li>N/A&nbsp;</li></ul><li>iOS 9.0.2 (Sep 2015): <a href="https://support.apple.com/en-us/HT205284">https://support.apple.com/en-us/HT205284</a></li><ul><li>Access to message creation, contacts and photos via Siri and a race condition in the lock screen via the Clock app (CVE-2015-5923). It can be mitigated disabling Siri in the lock screen via Settings. Video (9.0): <a href="https://www.youtube.com/watch?v=_giVIDKwRr4">https://www.youtube.com/watch?v=_giVIDKwRr4</a> Video (9.0.1): <a href="https://www.youtube.com/watch?v=wl4aoGSZbPc">https://www.youtube.com/watch?v=wl4aoGSZbPc</a></li></ul><li>iOS 9.1 (Oct 2015): <a href="https://support.apple.com/en-us/HT205370">https://support.apple.com/en-us/HT205370</a></li><ul><li>Phone and Messages notifications may appear on the lock screen even when disabled (CVE-2015-7000)</li></ul><li>iOS 9.2 (Dec 2015): <a href="https://support.apple.com/en-us/HT205635">https://support.apple.com/en-us/HT205635</a></li><ul><li>Siri allows reading notifications of content that is set not to be displayed at the lock screen (CVE-2015-7080)</li></ul><li>iOS 9.2.1 (Jan 2016): <a href="https://support.apple.com/en-us/HT205732">https://support.apple.com/en-us/HT205732</a></li><ul><li>N/A</li></ul><li>iOS 9.3 (Mar 2016): <a href="https://support.apple.com/en-us/HT206166">https://support.apple.com/en-us/HT206166</a></li><ul><li>N/A </li></ul><li>iOS 9.3.1 (Apr 2016): <a href="https://support.apple.com/en-us/HT206225">https://support.apple.com/en-us/HT206225</a></li><ul><li>N/A </li></ul><li>iOS 9.3.2 (May 2016): <a href="https://support.apple.com/en-us/HT206568">https://support.apple.com/en-us/HT206568</a></li><ul><li>Siri allows accessing contacts and photos from the the lock screen (CVE-2016-1852)&nbsp;</li></ul><li>iOS 9.3.3 (Jul 2016): <a href="https://support.apple.com/en-us/HT206902">https://support.apple.com/en-us/HT206902</a></li><ul><li>N/A </li></ul><li>iOS 9.3.4 (Aug 2016): <a href="https://support.apple.com/en-us/HT207026">https://support.apple.com/en-us/HT207026</a></li><ul><li>N/A </li></ul><li>iOS 9.3.5 (Aug 2016): <a href="https://support.apple.com/en-us/HT207107">https://support.apple.com/en-us/HT207107</a></li><ul><li>N/A </li></ul></ul><ul><li>iOS 10.0 (Sep 2016): <a href="https://support.apple.com/en-us/HT207143">https://support.apple.com/en-us/HT207143</a></li><ul><li>N/A</li></ul><li>iOS 10.0.1 (Sep 2016): <a href="https://support.apple.com/en-us/HT207145">https://support.apple.com/en-us/HT207145</a> </li><ul><li>N/A&nbsp;</li></ul><li>iOS 10.0.2 (Sep 2016): <a href="https://support.apple.com/en-us/HT207199">https://support.apple.com/en-us/HT207199</a> </li><ul><li>N/A</li></ul><li>iOS 10.0.3 (Oct 2016):&nbsp;<a href="https://support.apple.com/en-us/HT207263">https://support.apple.com/en-us/HT207263</a></li><ul><li>N/A</li></ul><li>iOS 10.1 (Oct 2016):&nbsp;<a href="https://support.apple.com/en-us/HT207271">https://support.apple.com/en-us/HT207271</a></li><ul><li>N/A</li></ul><li>iOS 10.1.1 (Oct 2016):&nbsp;<a href="https://support.apple.com/kb/HT207287">https://support.apple.com/kb/HT207287</a></li><ul><li>N/A</li></ul><li>iOS 10.2 (Dec 2016):&nbsp;<a href="https://support.apple.com/en-us/HT207422">https://support.apple.com/en-us/HT207422</a></li><ul><li>Access to photos and contacts (and iMessages) from the lock screen &nbsp;via a FaceTime (or phone) call, a custom message and Siri, plus VoiceOver (CVE-2016-7664). Video:&nbsp;<a href="https://www.youtube.com/watch?v=LWJG5I8xCDU">https://www.youtube.com/watch?v=LWJG5I8xCDU</a></li><li>The device does not lock the screen after the idle timeout when the Touch ID prompt is shown (CVE-2016-7601).</li><li>Access to photos and contacts from the lock screen due to a validation issue in the handling of media selection (CVE-2016-7653).</li><li>Device can be unlocked due to a counter issue in the handling of passcode attempts when resetting the passcode (CVE-2016-4781).</li><li>Device can remain unlocked due to a cleanup issue in the handling of Handoff with Siri (CVE-2016-7597).</li></ul><li>iOS 10.2.1 (Jan 2017):&nbsp;<a href="https://support.apple.com/en-us/HT207482">https://support.apple.com/en-us/HT207482</a></li><ul><li>Auto Unlock may unlock when Apple Watch is off the user's wrist (CVE-2017-2352).</li><li>An activation-locked device can be manipulated via Wi-Fi to present the home screen (CVE-2017-2351).</li></ul><li>iOS 10.3 (Mar 2017): <a href="https://support.apple.com/en-us/HT207617">https://support.apple.com/en-us/HT207617</a></li><ul><li>iCloud authentication prompts may disclose the user's Apple ID from the lock screen (CVE-2017-2397).</li><li>Siri might reveal text message contents while the device is locked (CVE-2017-2452).</li></ul><li>iOS 10.3.1 (Apr 2017): <a href="https://support.apple.com/en-us/HT207688">https://support.apple.com/en-us/HT207688</a></li><ul><li>N/A</li></ul><li>iOS 10.3.2 (May 2017): <a href="https://support.apple.com/en-us/HT207798">https://support.apple.com/en-us/HT207798</a></li><ul><li>N/A</li></ul><li>iOS 10.3.3 (July 2017):&nbsp;<a href="https://support.apple.com/en-us/HT207923">https://support.apple.com/en-us/HT207923</a></li><ul><li>Notifications may appear on the lock screen when disabled (CVE-2017-7058).</li></ul></ul><ul><li>iOS 11.0 (Sep 2017):&nbsp;<a href="https://support.apple.com/en-us/HT208112">https://support.apple.com/en-us/HT208112</a></li><ul><li>A screenshot of secure content may be taken when locking an iOS device (CVE-2017-7139).</li></ul><li>iOS 11.0.1 (Sep 2017):&nbsp;<a href="https://support.apple.com/en-us/HT208143">https://support.apple.com/en-us/HT208143</a></li><ul><li>N/A (empty)</li></ul><li>iOS 11.0.2 (Oct 2017):&nbsp;<a href="https://support.apple.com/en-us/HT208164">https://support.apple.com/en-us/HT208164</a></li><ul><li>N/A&nbsp;(empty)</li></ul><li>iOS 11.0.3 (Oct 2017):&nbsp;<a href="https://support.apple.com/en-us/HT208182">https://support.apple.com/en-us/HT208182</a></li><ul><li>N/A&nbsp;(empty)</li></ul><li>iOS 11.1 (Oct 2017):&nbsp;<a href="https://support.apple.com/en-us/HT208222">https://support.apple.com/en-us/HT208222</a></li><ul><li>A person with physical access to an iOS device may be able to access photos from the lock screen (CVE-2017-13844).</li><li>A person with physical access to an iOS device may be able to use Siri to read notifications of content that is set not to be displayed at the lock screen (CVE-2017-13805).</li></ul><li>iOS 11.1.1 (Nov 2017):&nbsp;<a href="https://support.apple.com/en-us/HT208255">https://support.apple.com/en-us/HT208255</a></li><ul><li>N/A&nbsp;(empty)</li></ul><li>iOS 11.1.2 (Nov 2017):&nbsp;<a href="https://support.apple.com/en-us/HT208282">https://support.apple.com/en-us/HT208282</a></li><ul><li>N/A&nbsp;(empty)</li></ul><li>iOS 11.2 (Dec 2017):&nbsp;<a href="https://support.apple.com/en-us/HT208334">https://support.apple.com/en-us/HT208334</a></li><ul><li>N/A&nbsp;(empty)</li></ul><li>iOS 11.2.1 (Dec 2017):&nbsp;<a href="https://support.apple.com/en-us/HT208357">https://support.apple.com/en-us/HT208357</a></li><ul><li>N/A&nbsp;(empty)</li></ul><li>iOS 11.2.2 (Jan 2018):&nbsp;<a href="https://support.apple.com/en-us/HT208401">https://support.apple.com/en-us/HT208401</a></li><ul><li>N/A&nbsp;(empty)</li></ul><li>iOS 11.2.5 (Jan 2018):&nbsp;<a href="https://support.apple.com/en-us/HT208463">https://support.apple.com/en-us/HT208463</a></li><ul><li>N/A&nbsp;(empty)</li></ul><li>iOS 11.2.6 (Feb 2018):&nbsp;<a href="https://support.apple.com/en-us/HT208534">https://support.apple.com/en-us/HT208534</a></li><ul><li>N/A&nbsp;(empty)</li></ul><li>iOS 11.3 (Mar 2018):&nbsp;<a href="https://support.apple.com/en-us/HT208693">https://support.apple.com/en-us/HT208693</a></li><ul><li>A person with physical access to an iOS device may be able to see the email address used for iTunes via the Clock alarms and timers (CVE-2018-4123)</li><li>File Widget may display contents on a locked device (CVE-2018-4168)</li><li>A person with physical access to the device may be able to disable Find My iPhone without entering an iCloud password when restoring from a back up (CVE-2018-4172)</li></ul><li>iOS 11.4 (Jun 2018): <a href="https://support.apple.com/en-gb/HT208848">https://support.apple.com/en-gb/HT208848</a></li><ul><li>A person with physical access to an iOS device may be able to view the last image used in Magnifier from the lock screen (CVE-2018-4239)</li><li>A person with physical access to an iOS device may be able to enable Siri from the lock screen (CVE-2018-4238)</li><li>A person with physical access to an iOS device may be able to use Siri to read notifications of content that is set not to be displayed at the lock screen (CVE-2018-4252)</li><li>An attacker with physical access to a device may be able to see private contact information due to an issue with Siri permissions and Contacts (CVE-2018-4244)</li></ul><li>iOS 11.4.1 (July 2018):&nbsp;<a href="https://support.apple.com/en-gb/HT208938">https://support.apple.com/en-gb/HT208938</a></li><ul><li>N/A (empty)</li></ul></ul><ul><li>iOS 12.0 (Sep 2018):&nbsp;<a href="https://support.apple.com/en-gb/HT209106">https://support.apple.com/en-gb/HT209106</a></li><ul><li>A person with physical access to an iOS device may be able to determine the last used app from the lock screen (CVE-2018-4325)</li></ul><li>iOS 12.0.1 (Oct 2018):&nbsp;<a href="https://support.apple.com/en-us/HT209162">https://support.apple.com/en-us/HT209162</a></li><ul><li>A lock screen issue allows a potential attacker access to photos and contacts on a locked device via Siri and VoiceOver (CVE-2018-4380). Video:&nbsp;<a href="https://www.youtube.com/watch?v=X2yQS1VzmZ0">https://www.youtube.com/watch?v=X2yQS1VzmZ0</a></li><li>A lock screen issue allows a potential attacker accessing the share function (share items) on a locked device via Siri and VoiceOver&nbsp;(CVE-2018-4379). Video:&nbsp;<a href="https://www.youtube.com/watch?v=fZh4cM3R0qU">https://www.youtube.com/watch?v=fZh4cM3R0qU</a></li></ul><li>iOS 12.1 (Oct 2018):&nbsp;<a href="https://support.apple.com/en-us/HT209192">https://support.apple.com/en-us/HT209192</a></li><ul><li>A lock screen issue allows a potential attacker access to photos via Reply With Message on a locked device (CVE-2018-4387). Video:&nbsp;<a href="https://www.youtube.com/watch?v=CjiLN2L_v5k">https://www.youtube.com/watch?v=CjiLN2L_v5k</a></li><li>A lock screen issue allows a potential attacker&nbsp;access to the share function on a locked device (CVE-2018-4388). Video: <a href="https://www.youtube.com/watch?v=CjiLN2L_v5k&amp;t=160">https://www.youtube.com/watch?v=CjiLN2L_v5k&amp;t=160</a></li></ul><li>iOS 12.1.1 (Dec 2018):&nbsp;<a href="https://support.apple.com/en-us/HT209340">https://support.apple.com/en-us/HT209340</a></li><ul><li>A lock screen issue allows a potential attacker&nbsp;access to view contacts from the lock screen via FaceTime (CVE-2018-4430). Video:&nbsp;<a href="https://www.youtube.com/watch?v=ojigFgwrtKs">https://www.youtube.com/watch?v=ojigFgwrtKs</a></li></ul><li>iOS 12.1.2 (Dec 2018):&nbsp;This update has no published CVE entries (<a href="https://support.apple.com/en-us/HT201222">https://support.apple.com/en-us/HT201222</a>).</li><li>iOS 12.1.3 (Jan 2019):&nbsp;<a href="https://support.apple.com/en-us/HT209443">https://support.apple.com/en-us/HT209443</a></li><ul><li>N/A (empty)</li></ul><li>iOS 12.1.4 (Feb 2019):&nbsp;<a href="https://support.apple.com/en-us/HT209520">https://support.apple.com/en-us/HT209520</a></li><ul><li>N/A (empty)</li></ul><li>iOS 12.2 (Mar 2019):&nbsp;<a href="https://support.apple.com/en-us/HT209599">https://support.apple.com/en-us/HT209599</a></li><ul><li>N/A (empty)</li></ul><li>iOS 12.3 (May 2019):&nbsp;<a href="https://support.apple.com/en-us/HT210118">https://support.apple.com/en-us/HT210118</a></li><ul><li>A person with physical access to an iOS device may be able to see the email address used for iTunes (CVE-2019-8599).</li></ul><ul></ul><ul></ul><ul></ul><ul></ul><ul></ul><ul></ul><ul></ul><ul></ul><ul></ul></ul><ul><ul></ul><ul></ul><ul></ul><ul></ul><ul></ul><ul></ul></ul><ul><ul></ul><ul></ul></ul><ul><ul></ul></ul><ul><ul></ul></ul><ul><ul></ul></ul><ul><ul></ul></ul><i><u>NOTE</u></i>: Since all of these vulnerabilities have not been officially acknowledged by Apple, it is sometimes complex to identify duplicates or missing ones. If you identify any discrepancy, inaccuracies, or additional references or videos, please let me know.<br /><br /><h3>Protecting iOS Devices Against Lock Screen Bypass Vulnerabilities</h3>This extensive list of iOS lock screen bypass vulnerabilities can be exploited by anyone that gets physical access to a target device, even temporarily. It is therefore crucial for both security professionals and pen testers, as part of their recommendations within pen test reports, to provide countermeasures that mitigate the associated risks. In fact, unless an organization is impeccable in their patching and update process, you are pretty much guaranteed to find an older version of iOS on some of their devices that could lead to a significant finding. And, if the organization employs a Bring Your Own Device (BYOD) policy, again you are ensured of a proliferation of older versions ripe for attack. If you can gather information about the use of such devices, you’ll have a nice finding for your report.<br /><br />In order to minimize the impact of lock screen bypass vulnerabilities in iOS devices, it is highly recommended to always update the mobile device to the latest iOS version available, which supposedly fixes all the publicly known vulnerabilities, and manually (or though an MDM solution) verify that you really are in the latest and expected iOS version (<a href="http://blog.dinosec.com/2014/06/ios-back-to-future.html">http://blog.dinosec.com/2014/06/ios-back-to-future.html</a>).<br /><br />Besides that, in iOS some of the (current and future) lock screen bypass vulnerabilities can be mitigated by limiting the functionality available in the lock screen. The following list summarizes various recommended configuration options currently available to protect the lock screen on iOS devices (it is outdated, as it applies to iOS version 8, with additional clarifications for iOS 7; however, the concepts can also be applied to newer iOS versions). Of course, turning off these functions can improve security by lowering the attack surface, but also may anger users who aren’t able to utilize the latest gee-whiz features of their devices. Evaluate each of these actions before applying them, as there is always a security versus usability trade off associated to disabling the functionality and features available in the lock screen without requiring the user to enter a passcode. For organizations requiring a high degree of security, though, these hardened configurations should at least be considered:<br /><br /><ul><li>Disable Siri (or Voice Dial, if Siri is not enabled; watch out as Music Voice Control is always enabled (*)) when the device is locked: Navigate to "Settings –&gt; Passcode –&gt; Siri (or Voice Dial)" and disable it there ("Allow access when locked: Siri = OFF"):</li></ul><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-liuv5TCnbPI/VCG_mtCa9eI/AAAAAAAAAkQ/45FMQ2KdiJM/s1600/Siri.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://4.bp.blogspot.com/-y7JtuVyCUVg/VCG_iJL14aI/AAAAAAAAAkI/zDYT7wXq9Y0/s1600/VoiceDial.png" width="213" />&nbsp;&nbsp;&nbsp; <img border="0" height="320" src="https://4.bp.blogspot.com/-liuv5TCnbPI/VCG_mtCa9eI/AAAAAAAAAkQ/45FMQ2KdiJM/s1600/Siri.png" width="213" /></a></div><ul><li>Disable Passbook when the device is locked: Navigate to "Settings –&gt; Passcode –&gt; Passbook" and disable it there ("Allow access when locked: Passbook = OFF").</li><li>Disable the Control Center from the lock screen to avoid exposing sensitive controls, such as enabling/disabling the Wi-Fi or Bluetooth interfaces, or even airplane mode: Navigate to "Settings –&gt; Control Center –&gt; Access on Lock Screen = OFF". The multiple controls available in Control Center cannot be customized; therefore it can only be enabled or disabled completely.</li></ul><div style="text-align: center;"><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-qTjWXKzKP28/VCG_-5tRMsI/AAAAAAAAAkk/5ygisqK5Djs/s1600/ControlCenter.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://2.bp.blogspot.com/-qTjWXKzKP28/VCG_-5tRMsI/AAAAAAAAAkk/5ygisqK5Djs/s1600/ControlCenter.png" width="213" /></a></div></div><ul><li>Disable the Notification Center, and specifically, its availability from the lock screen, including Today View (new since iOS 7). In iOS 8, navigate to "Settings –&gt; Passcode –&gt; Allow access when locked:" and disable both "Today" and "Notifications View": </li></ul><div style="text-align: center;"><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-G3ivgHJ0Pss/VCHAAN_5TVI/AAAAAAAAAk4/kOGJEubgZt0/s1600/NotificationCenter.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://1.bp.blogspot.com/-G3ivgHJ0Pss/VCHAAN_5TVI/AAAAAAAAAk4/kOGJEubgZt0/s1600/NotificationCenter.png" width="213" /></a></div></div><ul><li>To accomplish the same task in iOS 7, navigate to "Settings –&gt; Notification Center –&gt; Access on Lock Screen" and disable both, "Notifications View" and "Today View".</li><li>More granular notification settings can be configured for each individual app from the "Include" section of Notification Center. Apps can be completely unlinked from Notification Center by accessing their settings and turning off notifications. In iOS 8, go to "Settings –&gt; Notifications –&gt; <app> –&gt; Allow Notifications = OFF". The app will be moved to the "Do Not Include" section at the bottom (e.g. Twitter app):</app></li></ul><div style="text-align: center;"><app></app><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-8tz4kTS6CD4/VCG_-KjTOiI/AAAAAAAAAkY/VKE2DZG-5gw/s1600/AllowNotifications_off_Twitter.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://1.bp.blogspot.com/-eCemXtKDyqQ/VCG_-nF3jqI/AAAAAAAAAkg/kN44sRq5gGE/s1600/AllowNotifications_on_Twitter.png" width="213" />&nbsp;&nbsp;&nbsp;&nbsp; <img border="0" height="320" src="https://3.bp.blogspot.com/-8tz4kTS6CD4/VCG_-KjTOiI/AAAAAAAAAkY/VKE2DZG-5gw/s1600/AllowNotifications_off_Twitter.png" width="213" /></a></div></div><ul><li><app>Additionally, the "Show on Lock Screen" setting from the same menu allows defining if the individual app notifications will be available on the lock screen or not. In iOS 7, these and other adjustments in the next set of recommendations were available under "Settings –&gt; Notification Center –&gt; ..." instead. In iOS 7, to unlink an app from the Notification Center go to "Settings –&gt; Notifications –&gt; <app> –&gt; Show in Notification Center = OFF".</app></app></li><li><app><app>iOS allows answering back a phone call without knowing the passcode by simply swapping the missed call notification available in the lock screen. This behavior cannot be disabled, except by not showing this kind of missed call notification in the lock screen (go to "Settings –&gt; Notifications –&gt; Phone –&gt; Show on Lock Screen = OFF"):</app></app> </li></ul><div style="text-align: center;"><app><app></app></app><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-AZ7w8zG3ptk/VCHABkC7BgI/AAAAAAAAAlI/fgj2g0fUtcw/s1600/ShowOnLockScreen.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://4.bp.blogspot.com/-AZ7w8zG3ptk/VCHABkC7BgI/AAAAAAAAAlI/fgj2g0fUtcw/s1600/ShowOnLockScreen.png" width="213" /></a></div></div><ul><li><app><app>Similar recommendations apply to other apps that can also show sensitive information in the lock screen, such as Messages. It is recommended to disable the preview of Messages by going to "Settings –&gt; Notifications –&gt; Messages –&gt; Show Previews = OFF" (a specific issue with this setting has been fixed in iOS 8, CVE-2014-4356):</app></app></li></ul><div style="text-align: center;"><app><app>&nbsp;</app></app><a href="http://1.bp.blogspot.com/-JTsiaz8Uc1s/VCHAB5DQ4tI/AAAAAAAAAlU/xh6Gm5R3nqQ/s1600/ShowPreviews.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://1.bp.blogspot.com/-JTsiaz8Uc1s/VCHAB5DQ4tI/AAAAAAAAAlU/xh6Gm5R3nqQ/s1600/ShowPreviews.png" width="213" /></a></div><ul><li><app><app>In order to avoid issues with the SmartCover in iPad devices, its usage can be disabled from "Settings –&gt; General –&gt; Lock/Unlock":</app></app> </li></ul><div style="text-align: center;"><app><app></app></app><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-VwyS2fa7oOA/VCHACLfmsdI/AAAAAAAAAlM/_egTKNwDcQQ/s1600/SmartCover.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="96" src="https://2.bp.blogspot.com/-VwyS2fa7oOA/VCHACLfmsdI/AAAAAAAAAlM/_egTKNwDcQQ/s1600/SmartCover.png" width="400" /></a></div></div><ul><li><app><app>Disable the camera: In order to remove the quick camera access icon from the lock screen, completely restrict access to the camera via "Settings –&gt; General –&gt; Restrictions" and disable the 'Camera', which will also turn off FaceTime. As there is no other way to simply disable the quick camera access icon, this radical countermeasure is the only option available to avoid someone taking pictures from your iOS device:</app></app></li></ul><div style="text-align: center;"><app><app></app></app><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-EoSqEDSKx7k/VCHAAGZq8SI/AAAAAAAAAkw/DQ56uuDakEI/s1600/Restrictions_Camera.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://1.bp.blogspot.com/-4Zqvbx7jLmw/VCHAAr7i9ZI/AAAAAAAAAk0/9jeD8oXT7Qg/s1600/Restrictions_FaceTime.png" width="213" />&nbsp;&nbsp;&nbsp;&nbsp; <img border="0" height="320" src="https://2.bp.blogspot.com/-EoSqEDSKx7k/VCHAAGZq8SI/AAAAAAAAAkw/DQ56uuDakEI/s1600/Restrictions_Camera.png" width="213" /></a></div></div><ul><li><app><app>Establish a passcode with at least one alphabetic character, so that the look &amp; feel of the iOS lock screen does not disclose if your passcode is just a PIN (4 digits), is made up of just digits (more than 4), or (preferred option) is alphanumeric.</app></app></li><li><app><app>... and remember to frequently physically clean up the screen of your iOS devices too to avoid fingerprints, residues and smudge revealing your passcode :-)</app></app></li></ul><app><app>(*): Voice Dial is always enabled since iOS 7.1, and there is no configuration option to disable it, as it was the case in previous iOS versions (e.g. 7.0.x) from "Settings -&gt; General -&gt; Passcode Lock -&gt; Voice Dial" (since iOS 7.1 it should be under "Settings -&gt; Passcode").</app></app><br /><br /><app><app>All these recommended actions can be manually implemented through the Settings app or (most of them) via a configuration profile that can be pushed to the target iOS mobile devices through an MDM solution. Both offensive attack opportunities and defensive protections are thoroughly covered in the SANS SEC575: Mobile Device Security and Ethical Hacking course, with the main goal of testing and improving the overall security of corporate mobile environments.</app></app><br /><br /><app><app><i><u>NOTE</u></i>: This article has been crossed posted in both the <a href="http://pen-testing.sans.org/blog">SANS Pen-Testing Blog</a> (<a href="http://pen-testing.sans.org/blog/pen-testing/2014/09/24/bypassing-ios-lock-screens-a-comprehensive-arsenal-of-vulns#">here</a>) and <a href="http://blog.dinosec.com/">DinoSec's Blog</a> (<a href="http://blog.dinosec.com/2014/09/bypassing-ios-lock-screens.html">here</a>) in September 2014. </app></app>Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com3tag:blogger.com,1999:blog-2450054937036373903.post-25522007075263995942014-06-24T00:48:00.000-07:002018-10-24T04:10:08.905-07:00iOS: Back To The Future<b>UPDATE</b> (<i>January 25, 2015</i>): New details regarding <a href="http://blog.dinosec.com/2015/01/ios-back-to-future-ii_25.html">"iOS: Back to the Future II"</a> released.<br /><br /><b>UPDATE</b> (<i>September 17, 2014</i>): Apple has addressed the "iOS: Back to the Future" vulnerability in <a href="http://support.apple.com/kb/HT6441">iOS 8</a> and it has been identified with <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4383">CVE-2014-4383</a>.<br /><br />Apple mobile devices based on the iOS platform, such as iPhones and iPads, implement <a href="https://www.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf">multiple protection mechanisms and platform restrictions</a> to fulfill several security requirements and support Apple's lucrative business model.<br />In early 2012 I found a vulnerability that allows the manipulation of a sensitive core default iOS capability, the iOS device update process. The iOS update process is protected by <a href="https://www.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf">System Software Authorization</a>, which prevents downgrading iOS devices to previous versions of this operating system. This measure can be partially circumvented by freezing the mobile device to its current iOS version.<br /><br />An attacker in a Man-in-the-Middle (MitM) position (e.g. connected to the same public Wi-Fi hotspot as the victim, or by <a href="http://www.dinosec.com/en/lab.html#Rooted2013WiFi">impersonating one of the legitimate Wi-Fi networks the iOS device wants to connect to</a>) &nbsp;can intercept the iOS update check traffic of a target device. Through the modification of HTTP requests and/or responses, specifically some dates in the headers, as well as implementing replay attacks, can force the target device to think its current version is the latest iOS version available.<br /><br />The vulnerability can be used in carefully planned targeted attacks to temporarily or permanently freeze the current version of an iOS device. Before notifying the vulnerability to Apple (on February 6, 2014), the iOS version of Apple's devices could be permanently frozen to any time in the future, effectively setting its iOS version forever. In its current state, the version of iOS 7 devices can be permanently frozen up to the next update, while previous iOS versions still remain completely vulnerable. The temporary attacks still apply to all affected iOS versions.<br /><br />Once the iOS version has been frozen, this attack facilitates the exploitation of other vulnerabilities potentially targeting a specific version of this mobile platform, such as the 197 vulnerabilities fixed in iOS 6.0, or the 80 vulnerabilities fixed in iOS 7.0 (plus all the others fixed between major iOS versions). It is scary to think how many potential victims could have been attacked by this vulnerability during the last two and a half years, allowing both massive device manipulation attacks as well as stealthier and targeted attacks (that can also be reverted back silently).<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-yvFcD-aT4fY/U6IIxSCzJvI/AAAAAAAAAhI/8S38c7bMUJE/s1600/SW_update.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-yvFcD-aT4fY/U6IIxSCzJvI/AAAAAAAAAhI/8S38c7bMUJE/s1600/SW_update.png" height="299" width="640" /></a></div><br />The design flaw affects the multiple Apple mobile devices (iPhone, iPad, iPad mini, iPod Touch..) since iOS version 5 up to the latest iOS 7 version (7.1.1). In iOS 5, Apple introduced new wireless capabilities to perform specific operations Over the Air (OTA), actions that previously required the usage of USB cables, such as iCloud backups, iTunes data synchronization and backups over Wi-Fi, or iOS software updates. This behavior introduced the aforementioned vulnerability, which can be exploited in iOS 5, 6 &amp; 7 by applying core principles from movies like Back to the Future, Star Wars or Matrix ;)<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-8M-6pSgnJ4c/U6IJEqdyJeI/AAAAAAAAAhU/Ubhp-cbEde0/s1600/iOS_BttF.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-8M-6pSgnJ4c/U6IJEqdyJeI/AAAAAAAAAhU/Ubhp-cbEde0/s1600/iOS_BttF.png" height="320" width="268" /></a><a href="http://4.bp.blogspot.com/-GLjk_xdQxKM/U6IJEgMYmqI/AAAAAAAAAhQ/D1It8e6-_sk/s1600/StarWars-Matrix.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-GLjk_xdQxKM/U6IJEgMYmqI/AAAAAAAAAhQ/D1It8e6-_sk/s1600/StarWars-Matrix.png" height="320" width="268" /></a></div><br />Although the flaw was discovered in early 2012, it has remained private while researching and evaluating first hand the current immature and controverted vulnerability disclosure models, the real interests of modern vulnerability markets and brokers, as well as other vulnerability discovery implications, topics that have also been discussed during my talks.<br /><br />I disclosed this vulnerability this year both at the 5th anniversary of the <a href="http://www.rootedcon.es/">RootedCON</a> 2014 conference (Madrid, Spain, March 2014) and at the 1st anniversary of the "new" <a href="http://www.area41.io/">Area 41</a> conference (Zurich, Switzerland, June 2014). More information about the vulnerability is available on both slide decks, as well as in the associated videos, with exploitation demos. They include the overall impact of the vulnerability, all the associated technical details surrounding System Software Authorization and how the iOS update process works, the vulnerability behavior in iOS 5, 6 and 7, and its history, limitations, and complementary tools used during the research process, such as <a href="http://blog.dinosec.com/2014/06/icamasu.html">iCamasu</a> (<a href="http://www.dinosec.com/en/lab.html#iCamasu">new 0.42 version released</a>):<br /><br /><ul><li>"<a href="http://www.dinosec.com/en/lab.html#Rooted2014iOS">iOS: Back To The Future</a>". RootedCON 2014. March 2014. (Presentation in English &amp; Video in Spanish).</li><li>"<a href="http://www.dinosec.com/en/lab.html#Area41-2014iOS">iOS: Back To The Future</a>". Area 41. June 2014.&nbsp;(Presentation &amp; Video&nbsp;in English).</li></ul><br /><i><u>NOTE</u></i>: <i>The video is currently available only in Spanish from RootedCON. The English version of the video (and presentation) from Area41 will be released in a few weeks. Follow @dinosec for updates.</i><br /><br />Unfortunately, due to the fact the vulnerability has not been completely addressed by Apple yet, the iProxy tool and the archive of previous iOS software update plist files mentioned in the talks are not going to be publicly released. These two&nbsp;allow weaponizing its exploitation in real-world scenarios. However, it is crucial for organizations at this point to know about this vulnerability in order to take proactive countermeasures, such as verifying their managed iOS devices are running the latest, or expected, iOS version via their MDM solution.<br /><br />My hope is that the vulnerability will be fixed in iOS 8 later this fall, but still several unanswered questions remain open: Why Apple didn't use HTTPS (and certificate pinning) for the iOS update check process? Was it due to performance reasons? Even in this case, it is crucial to differentiate between the update check process (to verify if there is a new version available) and getting the update contents, that is, the update process itself (to download and install the new available version).<br /><br />We definitely do not learn from the past and repeat the same mistakes, again and again, regarding how to use technology in a secure way... Perhaps due to its increasing complexity or perhaps, wait... intentionally... Once again, the debate opens the door to reflect on the current technologies and the inherent weaknesses of our modern information society, sophisticated but vulnerable.Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com0tag:blogger.com,1999:blog-2450054937036373903.post-80339210531741974422014-06-04T04:38:00.000-07:002018-10-24T04:10:09.308-07:00iCamasuFor the iOS updates security research I presented at both <a href="http://www.rootedcon.es/">RootedCON</a> and <a href="http://www.area41.io/">Area41</a> this year (more details will be published in an upcoming blog post... still waiting for a fix!), I processed and analyzed (several times and in multiple ways over the last 2.5 years) the PLIST files used by Apple devices to check for new iOS updates. Since iOS 5, and due to the new OTA (Over-the-Air) update capabilities introduced with that version, every time a new iOS update is available, a new file containing the list of official iOS versions and the mobile devices supported by each of them is published at <a href="http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdate/com_apple_MobileAsset_SoftwareUpdate.xml">http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdate/</a><br /><a href="http://com_apple_mobileasset_softwareupdate.xml/">com_apple_MobileAsset_SoftwareUpdate.xml</a>, together with the associated iOS documentation file, available at <a href="http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdateDocumentation/com_apple_MobileAsset_SoftwareUpdateDocumentation.xml">http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdateDocumentation/</a><br /><a href="http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdateDocumentation/com_apple_MobileAsset_SoftwareUpdateDocumentation.xml">com_apple_MobileAsset_SoftwareUpdateDocumentation.xml</a>.<br /><br />iCamasu, <u><b>i</b></u>OS <u><b>c</b></u>om_<u><b>a</b></u>pple_<u><b>M</b></u>obile<u><b>A</b></u>sset_<u><b>S</b></u>oftware<u><b>U</b></u>pdate, is a Python-based tool that parses and extracts multiple details from Apple iOS software update PLIST files,"com_apple_MobileAsset_SoftwareUpdate.xml" (BTW, the tool does not parse the associated documentation files).<br /><br />iCamasu provides multiple parsing options to select the input file (-f), extract the minimum (-m) and maximum (-M) iOS versions currently available, show a brief summary (-s or -S) including the SHA-1 hash for the file and its size, the number of assets or entries, devices, and iOS versions, and allows classifying the current iOS versions by device (-D) or iOS version (-I). Additionally it includes search capabilities by device (-d) or iOS version (-i), and a more verbose output and extended details via the "-v" and "-F" options.<br /><br />iCamasu usage examples:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-qLkVGMSm9lk/U48D_W0p8HI/AAAAAAAAAgA/BV78oeCcyKQ/s1600/iCamasu_h.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-qLkVGMSm9lk/U48D_W0p8HI/AAAAAAAAAgA/BV78oeCcyKQ/s1600/iCamasu_h.png" height="301" width="320" /> </a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-ESCo3jPOukw/U48D_6-NVII/AAAAAAAAAgQ/JQg4l6Q83AI/s1600/iCamasu_m_M_s_S.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-ESCo3jPOukw/U48D_6-NVII/AAAAAAAAAgQ/JQg4l6Q83AI/s1600/iCamasu_m_M_s_S.png" height="320" width="309" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-mfr8iBi82IE/U48D9yytWdI/AAAAAAAAAfs/L2fcDLdMzVg/s1600/iCamasu_D.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-mfr8iBi82IE/U48D9yytWdI/AAAAAAAAAfs/L2fcDLdMzVg/s1600/iCamasu_D.png" height="320" width="265" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-R5p1V11vloI/U48D-RMH_bI/AAAAAAAAAf4/us2jqsmCNHY/s1600/iCamasu_I.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-R5p1V11vloI/U48D-RMH_bI/AAAAAAAAAf4/us2jqsmCNHY/s1600/iCamasu_I.png" height="268" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-qLkVGMSm9lk/U48D_W0p8HI/AAAAAAAAAgA/BV78oeCcyKQ/s1600/iCamasu_h.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"></a><a href="http://3.bp.blogspot.com/-UAuVYlTZEZE/U48D-VY6IKI/AAAAAAAAAfw/lq0Wqb36Gd0/s1600/iCamasu_d_.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-UAuVYlTZEZE/U48D-VY6IKI/AAAAAAAAAfw/lq0Wqb36Gd0/s1600/iCamasu_d_.png" height="224" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-7XZrQxdJsXM/U48D_j3PyhI/AAAAAAAAAgI/wRp8zKlIkP0/s1600/iCamasu_i_.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-7XZrQxdJsXM/U48D_j3PyhI/AAAAAAAAAgI/wRp8zKlIkP0/s1600/iCamasu_i_.png" height="218" width="320" /></a></div><br />If you plan to do any iOS research related with new updates or iOS versions, I hope you find iCamasu useful to easily dig deeply into the PLIST file contents. As usual, the tool is available <a href="http://www.dinosec.com/en/lab.html#iCamasu">at DinoSec's Lab</a> (where future major versions will be published too) and also in the new <a href="https://github.com/dinosec">DinoSec GitHub repository</a>, in case you want to <a href="https://github.com/dinosec/iCamasu">contribute updates and feedback</a>. The first public version is 0.41, as for the <a href="http://www.area41.io/">Area41 conference</a> where it was released, and runs on Linux, OS X and Windows. Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com0tag:blogger.com,1999:blog-2450054937036373903.post-44351460138997619032014-02-20T00:57:00.000-08:002018-10-24T04:10:09.976-07:00DinoSec Challenge 0: Solution and WinnersThis article provides details about the solution and winners of "<a href="http://blog.dinosec.com/2014/02/dinosec-challenge-0-what-is-name-of.html">DinoSec Challenge 0</a>" (... and also explains how you can ruin a challenge trying to publish a nice blog post with images that fit on the web page ;)<br /><br /><span style="font-size: large;">Solution</span><br /><br />The original goal of the challenge was to use the three images referenced by the "<a href="http://blog.dinosec.com/2014/02/dinosec-challenge-0-what-is-name-of.html">DinoSec Challenge 0</a>", called "dinosec1.png", "dinosec2.jpg"and "dinosec3.jpg". However, due to the large size of some of these images, and in order to publish a nice looking blog post, I decided to use a reduced version of them for the challenge description, called "dinosec1_blog.png", "dinosec2_blog.jpg"and "dinosec3_blog.jpg", as you can see in the source code of the web page:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-vEZQ6IcTOnc/UwTyCvnXNRI/AAAAAAAAAcM/6i_U4kZ-jxQ/s1600/DinoSec_0_source-code.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-vEZQ6IcTOnc/UwTyCvnXNRI/AAAAAAAAAcM/6i_U4kZ-jxQ/s1600/DinoSec_0_source-code.png" height="204" width="320" /></a></div><br />Google allows you to search for images by using terms (text) or '<a href="http://www.google.com/insidesearch/features/images/searchbyimage.html">Search By Image</a>' capabilities, via URLs (pointing to image files) or by uploading local image files, both manually or using drag &amp; drop. In the following video you can see how, depending on the web browser you are using, the Google Images search behavior varies. For example, when using Safari, the full URL of the image file pointed by the link (that is, the URL in the "&lt;a href=…&gt;" HTML tag, such as "http://.../dinosec1.png") is loaded into Google Images. As a result, Google cannot find any reference to any of the three images apart from the DinoSec challenge blog post (this was the expected behavior for this challenge). However, when using Chrome or Firefox, the reduced image used for the publication within the blog post (such as "dinosec1_blog.png", 320x212 pixels) is used instead. As a result, for images 1 and 3 Google is capable of finding direct references to the original images (in the case of the first one, even pointing to the original source, commons.wikimedia.org: <a href="http://commons.wikimedia.org/wiki/File:Silesaurus_w_Krasiejowie.JPG">1</a>, <a href="http://commons.wikimedia.org/wiki/File:Silesaurus_w_Krasiejowie2.JPG">2</a> &amp; <a href="http://commons.wikimedia.org/wiki/File:Silesaurus_w_Krasiejowie3.JPG">3</a>) and, therefore, helping to directly and easily solve the challenge:<br /><div style="text-align: center;"><br /></div><div style="text-align: center;"><iframe allowfullscreen="" frameborder="0" height="313" mozallowfullscreen="" src="//player.vimeo.com/video/87108279" webkitallowfullscreen="" width="500"></iframe> </div><div style="text-align: center;"><span style="font-size: x-small;"><a href="http://vimeo.com/87108279">DinoSec Challenge 0 Solution via Google Images</a> from <a href="http://vimeo.com/dinosec">DinoSec</a> on <a href="https://vimeo.com/">Vimeo</a></span>.</div><div style="text-align: left;"><br /></div><div style="text-align: left;">As a result, I ended up trying to identify the reasons behind the described behavior. When creating that reduced version of the images for publication, I probably used derivatives of the original images, an obviously, none of the SHA1 hashes of the different files match. On the one hand, Google is capable of visually matching image 1 (in PNG format, 320x212 pixels) with the original source image 1 (in JPEG format, 4,288x2,848 pixels). However, image 2 is not found by Google. On the other hand, image 3 (in JPEG format, 320x212 pixels) is also matched with the original image 3 on a third-party website (same format but 4,288x2,848 pixels)&nbsp;and with another JPEG image of a different size (780x518 pixels) on another website. You can read some of the details regarding reverse&nbsp;<a href="http://insidesearch.blogspot.com.es/2011/06/search-by-text-voice-or-image.html">image</a> and <a href="http://googleresearch.blogspot.com.es/2013/06/improving-photo-search-step-across.html">photo search</a>&nbsp;from <a href="http://googlesystem.blogspot.com.es/2013/07/google-search-by-image-and-special.html">multiple</a> <a href="http://searchengineland.com/up-close-with-google-search-by-image-82313">articles</a> around the web, based on mathematical models, computer vision and machine learning technologies, combined with EXIF metadata and web pages context.</div><br />Although this was designed as an introductory challenge, the idea for it was not to be so easily solved, unless you were really lucky searching for dinosaur images through the web. Instead, it was designed to be solved by inspecting the raw images, finding and decoding a few artifacts added on purpose.<br /><br />Images 2 and 3 ("dinosec2.jpg" and "dinosec3.jpg") are JPEG files with 4,288x2,848 pixels. If you look inside their metadata you can find a couple of messages.<br /><br />The "IPTC-NAA data (IIM)" metadata section for&nbsp;image 2&nbsp;contains a "RAW File Info" field with the following obfuscated message: "NTQ0OTUwMzEzYTIwNTc2ODZmMjA2NDY5NjQyMDYzNzI2NTYxNzQ2NTIwNzQ2ODY5NzMyMDYzNjg2<br />MTZjNmM2NTZlNjc2NTNmMjA0ZDcyMmUyZTJl". If it is decoded as base64 and that output is decoded again as ASCII hex, you get the first ASCII message: "<u>TIP1: Who did create this challenge? Mr...</u>". The image bellow shows the decoding process using Burp Decoder, but other tools or scripting languages can be used to obtain the same result:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-45pREfpYp6o/UwVCWubHcUI/AAAAAAAAAcc/iy40r8QV6_o/s1600/Burp_TIP1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-45pREfpYp6o/UwVCWubHcUI/AAAAAAAAAcc/iy40r8QV6_o/s1600/Burp_TIP1.png" height="193" width="320" /></a></div><br />The "IPTC-NAA data (IIM)" metadata section for&nbsp;image 3 contains a "RAW File Info" field with the following obfuscated message: "56456c514d6a6f67535851675a57356b63794231634342336158526f4948526f5a53423362334a6b49<br />434a7a5958567964584d6949446f744b513d3d". If it is decoded as ASCII hex and that output is decoded again as base64, reverting the decoding process for image 2, you get the second ASCII message: "<u>TIP2: It ends up with the word "saurus" :-)</u>". The image bellow shows the decoding process using Burp Decoder, but again, other tools or scripting languages can be used to obtain the same result:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-Gj_kBd1Gti4/UwVCaoO_0iI/AAAAAAAAAck/8x0YW1biK7U/s1600/Burp_TIP2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-Gj_kBd1Gti4/UwVCaoO_0iI/AAAAAAAAAck/8x0YW1biK7U/s1600/Burp_TIP2.png" height="193" width="320" /></a></div><br />Putting together the answer for both tips you can solve the challenge: <b><u>Silessaurus</u></b>. Yes, indeed, it is my oldest ancestor I'm aware of :)<br /><br />Image 1 ("dinosec1.png") is a JPEG file with 800x531 pixels, that still contains a hidden message. Although the message is not required to solve the challenge, I'm not going to disclose how to obtain it, so that the inquisitive reader can still play around with it :) (<i>tip: stego</i>)<br /><br /><span style="font-size: large;">Winners</span><br /><br />This challenge winners are Juan Manuel Fernández (@TheXC3LL), with a very fast and correct answer using search engines, and @neosysforensics, with a correct technical answer based on decoding the image files metadata. Based on the details and epic fail previously explained, and although initially I thought on having a single winner, I decided it was fair this time to select two winners, one for the first correct answer (even when using the easy path :-), and a second one for the first technical answer. The winners books are on its way, "<a href="http://secviz.org/content/applied-security-visualization">Apply Security Visualization</a>" and "<a href="http://www.digital-evidence.org/fsfa/">File System Forensic Analysis</a>", both related somehow to the techniques used to solve the challenge.<br /><br />Honorable mentions go to other participants like Ricardo, José Manuel, Román, Daniel, and David, that also provided a valid answer by using Google, <a href="https://www.tineye.com/">TinEye</a> (reverse image search engine), or technical analysis using base64 and Python. Thanks for all your submissions!<br /><br /><span style="font-size: large;">Lessons Learned</span><br /><br />Designing a challenge is always tough, specially finding the right balance between difficulty and affordability. Even for introductory challenges, never underestimate the minor details, manage them as more advanced and complex challenges, and always give a much higher priority to the challenge than to its publication :-) Seriously, in order to solve this first challenge speed of submission was a key factor, especially if you followed the easy path. Thus, in this case the "luck" of been aware of the existence of the challenge influenced a fast and timely response. Therefore, future challenges will be published in advance, with a well known deadline, and all submissions will be evaluated based on their quality, accuracy, creativity, and technical contents.<br /><br />Besides that, prizes will be announced in advance too, so that you can evaluate your participation based on them. Quite honestly, if you participate because of the prizes and not the enjoyable learning experience, I'm sure you will find wealthier challenges and CtFs out there... although I cannot think of an easiest way of winning a security book than dragging &amp; dropping an image into Google :-D<br /><br />Follow the @dinosec Twitter account and this blog... and get ready for the next challenge!!<br /><br />Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com0tag:blogger.com,1999:blog-2450054937036373903.post-74479519534500670022014-02-10T01:31:00.000-08:002018-10-24T04:10:10.374-07:00DinoSec Challenge 0: What is the name of this dinosaur?At the end of last year, during the <a href="https://www.ccn-cert.cni.es/index.php?option=com_content&amp;view=article&amp;id=3517&amp;Itemid=198&amp;lang=es">CCN-CERT conference</a>, I challenged the audience when I reached my speaker bio slide. There, I&nbsp;showed "my picture"&nbsp;and how I "look like" nowadays as a member of <a href="http://www.dinosec.com/">DinoSec</a> :-) The question was: "<strong>What is the name of this dinosaur?</strong>". Nobody answered it...<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-MQiVvUowzlQ/UviWS7uAmBI/AAAAAAAAAbU/FcsTEaa9pq8/s1600/slide.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-MQiVvUowzlQ/UviWS7uAmBI/AAAAAAAAAbU/FcsTEaa9pq8/s1600/slide.png" height="240" width="320" /></a></div><br />Throughout my professional career I've really learned a whole lot and enjoyed both participating and creating security challenges. Thus, I would like to start posting again security challenges from time to time using the <a href="http://blog.dinosec.com/">DinoSec blog</a>. As I don't like unanswered questions to last forever, this is the first introductory challenge where you need to use your investigative, exploratory, and digital paleontologist skills to be able to get the generic name of this dinosaur. To help with its identification, I have provided you three pictures, so that you can see&nbsp;the dinosaur&nbsp;physiognomy and details:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://www.dinosec.com/challenges/dinosec1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-s2fpvm8J1sE/UviZqq3Ny1I/AAAAAAAAAbk/E2CAX73txeo/s1600/dinosec1_blog.png" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://www.dinosec.com/challenges/dinosec2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-jRooZxreiis/UviZqu-4rdI/AAAAAAAAAbg/OFmolstRUfo/s1600/dinosec2_blog.jpg" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://www.dinosec.com/challenges/dinosec3.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-F9_YnV2oV-A/UviZq7_DjjI/AAAAAAAAAbo/Lo88bIDF-mY/s1600/dinosec3_blog.jpg" /></a></div><br />I will&nbsp;hand over&nbsp;prizes for the winner(s) of these challenges, like information security books or other gadgets. In this case, the challenge does not have a deadline. It will be open until someone answers the question and submits the right generic name for this dinosaur. Please, send your submissions to <u>info @AT@ dinosec .dot. com</u>, with the title "DinoSec Challenge 0", and briefly describing in a&nbsp;couple of&nbsp;paragraph how you "guessed" the dinosaur name.<br /><br /><em>Suggestion if you have kids</em>: If I were you (as Josh Wright educated me sometime ago) I would teach them to start counting at zero! They will express gratitude for it forever :-) Now, you know why this is challenge number zero :-)Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com0tag:blogger.com,1999:blog-2450054937036373903.post-18558591911922226952013-12-09T13:52:00.000-08:002018-10-24T04:10:10.777-07:00Removing the Android Device Lock from any Mobile App<span style="font-family: inherit;"><i style="font-family: Calibri;"><span lang="EN-US">Shameless plug</span></i><span lang="EN-US">: I will be teaching the 6-day SANS SEC575 training, "SEC575: Mobile Device Security and Ethical Hacking", in <span style="color: blue;"><a href="http://www.sans.org/event/abu-dhabi-2014/course/mobile-device-security-ethical-hacking">AbuDhabi, UAE (Apr 26, 2014 - May 1, 2014)</a></span> and <span style="color: blue;"><a href="http://www.sans.org/event/pentest-berlin-2014/course/mobile-device-security-ethical-hacking">Berlin,Germany (Jun 16-21, 2014)</a></span>.</span></span><br /><span style="font-family: inherit;"></span><br /><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">The </span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;"><a href="http://www.sans.org/sec575">"SANS SEC575: Mobile Device Security and Ethical Hacking"</a></span></span><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;"> training is one of the most entertaining and challenging courses I have ever taught, with enhanced coverage of Android, iOS, Windows Phone, and BlackBerry. The last couple of times I run it at the end of this year I travelled around the world with six different mobile devices, including Android 2.x &amp; 4.x plus iOS 4.x, 5.x, 6.x &amp; 7.x, my other production mobile devices, two laptops, Wi-Fi access points plus multiple USB cards and antennas, a Pineapple, a portable stand camera and a few other gadgets... This makes crossing airport security quite challenging too, a kind of extra social engineering exercise for a pen-tester . Yes, I get stares. :-)</span><br /><span style="font-family: inherit;"></span><br /><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">Last week, a new Android vulnerability was disclosed: </span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;"><a href="https://cureblog.de/2013/11/cve-2013-6271-remove-device-locks-from-android-phone/">"CVE-2013-6271: Remove DeviceLocks from Android Phone"</a></span></span><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">. It affects Android Jelly Bean (JB) 4.3 devices, as well as earlier version based on my own testing, such as Android Ice Cream Sandwich (ICS) version 4.0.3. The flaw allows any mobile application (from now on referred to as an "app") to remove the passcode or lock protection of Android mobile devices, no matter the lock mechanism in place: PIN code, password or passphrase, dot pattern or gesture, or face unlock. That's pretty huge.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">Android implements an Inter Process Communication (IPC) mechanism through messages, called Intents. About a year ago, we started covering in Day 3 of the SEC575 class Android Intents analysis via the </span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;"><a href="https://labs.mwrinfosecurity.com/blog/2013/06/05/mercury-v2-2-1/">Mercury framework</a></span></span><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">,<span style="mso-spacerun: yes;">&nbsp; </span>developed by MWR InfoSecurity. You can read all about Mercury in a Chris Crowley's previous article on the </span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;"><a href="http://pen-testing.sans.org/blog/">SANS Pen-Testing blog</a></span></span><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">, </span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;"><a href="http://pen-testing.sans.org/blog/2013/05/02/intentional-evil-an-pen-testers-overview-of-android-intents">"Intentional Evil: A PenTester's Overview of Android Intents"</a></span></span><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">. The SEC575 training has been recently updated with its replacement tool, called </span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;"><a href="https://labs.mwrinfosecurity.com/tools/drozer/">Drozer</a></span></span><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">. As the Drozer framework is explicitly mentioned in the PoC section of the CVE-2013-6271 vulnerability, I thought this vulnerability was a great opportunity to show on this blog how to dissect an Android app, and offer a quick step-by-step overview of the methods and tools we can use as pen-testers and security researchers to discover and analyze, in depth, this kind of still very common Android app weakness.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">A more detailed analysis of the various Android app components (Activities, Services, Receivers, etc.) and their relationships, app attack opportunities, and components exposure are covered in Day 3 of SEC575, including live demos, hands-on exercises<span style="mso-spacerun: yes;"> </span>and details of real vulnerabilities, such as </span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;"><a href="http://seclists.org/bugtraq/2013/Jan/27">a similar vulnerability affecting the AndroidFacebook app, v.1.8.1</a></span></span><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">(I was not aware of my artistic skills after Björn took a picture of my screen during SANS London 2013 after going through the vulnerability details :-):</span></div><div class="separator" style="clear: both; margin: 0cm 0cm 10pt; text-align: center;"><a href="http://2.bp.blogspot.com/-dAlRhsJ32UE/UqYj3nRYpHI/AAAAAAAAAUQ/QlgT9TtgNh8/s1600/Facebook_intents_vulnerability.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://2.bp.blogspot.com/-dAlRhsJ32UE/UqYj3nRYpHI/AAAAAAAAAUQ/QlgT9TtgNh8/s1600/Facebook_intents_vulnerability.png" height="312" width="400" /></span></a></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">The attack vector that can be leveraged to take advantage of the CVE-2013-6271 vulnerability is based on having an offending app installed on the victim mobile device, previously installed by the user or installed by exploiting any other vulnerability in the Android platform. In order to send an intent to a public Activity, the offending app does not require any special permission in the Android platform. This increases the device exposure, as the most benign looking apps, or even future app updates, could be used now to unlock the Android device (even those apps requesting no permissions at all; BTW, these are the ones really suspicious to me :-)</span></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="mso-ansi-language: EN-US;"></span><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">The SEC575 Android static analysis section mainly focuses in the evaluation of third-party mobile apps from a corporate perspective, such as the ones you can get from Google Play (the official Android app store) or any other source or third-party store. When you need to analyze a default system Android app, such as the Settings app in the case of the CVE-2013-6271 vulnerability, there are a couple of differences that influence the analysis process.</span></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="mso-ansi-language: EN-US;"></span><span style="font-family: inherit;"><u><span lang="EN-US" style="mso-ansi-language: EN-US;"><em>NOTE</em></span></u><span lang="EN-US" style="mso-ansi-language: EN-US;">: The analysis process described uses Windows 7 as the host operating system and the Android emulator as the target mobile environment, although the same steps apply when using a real Android mobile device or a different host operating system.</span></span><br />&nbsp;</div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; font-size: x-large; mso-ansi-language: EN-US;">Android App Static Analysis</span></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">In order to analyze any Android app, the first requirement is to get a copy of the corresponding Android package (.apk file) from Google Play or from within an Android device. An Android package is a compressed ZIP file, so it can be easily inspected. Inside you can find resources and certificates information, as well as the two most relevant files for Android apps: AndroidManifest.xml (which includes the permissions required by the app and the components publicly exported by it, among others), and classes.dex (the app binary in Dalvik EXecutable , or DEX, format):</span></div><div class="separator" style="clear: both; margin: 0cm 0cm 10pt; text-align: center;"><a href="http://3.bp.blogspot.com/-xVcwGjBYuMo/UqYmrTFpijI/AAAAAAAAAUc/l7aYciodMtw/s1600/files_inside_an_apk_file.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://3.bp.blogspot.com/-xVcwGjBYuMo/UqYmrTFpijI/AAAAAAAAAUc/l7aYciodMtw/s1600/files_inside_an_apk_file.png" /></span></a></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">However, the default system Android apps are optimized to speed up their performance when loading and running, and as a result, the corresponding .apk file does not contain a classes.dex file. Instead, the binary has been extracted out of the .apk file and has been converted to an .odex file (Optimized DEX file).</span></span></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;"><span lang="EN-US" style="mso-ansi-language: EN-US;"></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;">The CVE-2013-6271 vulnerability affects the default system Settings app (identified as "com.android.settings"). The Settings app is located in the "/system/app/" directory of Android devices, split in two files: Settings.apk and Settings.odex. The adb tool available in the Android SDK can be used to extract these two files:</span></span></span></span></div><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-2rP-8p4Eg80/UqYvyt0GMnI/AAAAAAAAAV0/sAid_aDyrzw/s1600/adb_pull_Settings.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://2.bp.blogspot.com/-2rP-8p4Eg80/UqYvyt0GMnI/AAAAAAAAAV0/sAid_aDyrzw/s1600/adb_pull_Settings.png" height="209" width="640" /></span></a></div><div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;">﻿</span></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"></span></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;">As the .apk file does not contain the app binary, our analysis will focus on the .odex file. The .odex file has to be deoptimized and disassembled for inspection, a process known as </span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue;"><a href="https://code.google.com/p/smali/wiki/DeodexInstructions">deodexing</a></span></span><span lang="EN-US" style="mso-ansi-language: EN-US;">. The baksmali tool helps to deodex the file and requires four arguments; the Android API level (-a), the target .odex file (-x), a directory containing all the framework libraries (-d), and an output directory to save the disassembled Smali code from the app (-o).</span></span></span></span></span></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"></span></span></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: &quot;Courier New&quot;, Courier, monospace; line-height: 115%; mso-ansi-language: EN-US;">C:\&gt; baksmali -a 18 -x Settings.odex -d framework -o Settings</span></span></span></div><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;">The API level is based on the Android version and can be easily obtained from the Android<span style="mso-spacerun: yes;">&nbsp; </span></span></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;"><a href="http://source.android.com/source/build-numbers.html">"Codenames, Tags, and Build Numbers"</a></span></span><span style="font-family: inherit;"><span style="mso-ansi-language: EN-US;"> <span lang="EN-US">webpage. As we are using an Android 4.3 target device, the corresponding API level is 18.</span></span></span></span></span><br /><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"><br /></span><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><o:p><span style="font-family: inherit;"><span lang="EN-US" style="mso-ansi-language: EN-US;">The directory containing all the framework libraries can be created by checking the value of the BOOTCLASSPATH environment variable from the Android 4.3 device. Again, adb can be used to retrieve its value:</span><br /></span></o:p></span></span></span></span><br /><div class="separator" style="clear: both; text-align: center;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit;"><a href="http://2.bp.blogspot.com/-0Zz5sw18ld8/UqYvzEro47I/AAAAAAAAAV4/OSjev3B0Meg/s1600/adb_shell_BOOTCLASSPATH.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-0Zz5sw18ld8/UqYvzEro47I/AAAAAAAAAV4/OSjev3B0Meg/s1600/adb_shell_BOOTCLASSPATH.png" height="238" width="640" /></a></span></span></span></span></div><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span style="font-family: inherit;"></span><span lang="EN-US" style="mso-ansi-language: EN-US;"></span></span></span></span></span><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;"></span></span></span></span></span></span><br /><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">You can copy and paste the BOOTCLASSPATH variable contents in a single line into a text file ("BOOTCLASSPATH-jar.txt") and process that file in Windows to obtain (via adb pull) all the Android framework libraries from the device, plus the associated .odex files. The following commands will streamline the process (see the "Additional Resources" section below to get the "BOOTCLASSPATH.bat" script):</span></span></span></span></span></span></div><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"></span><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><pre><span style="font-family: inherit;"><span style="font-family: &quot;Courier New&quot;, Courier, monospace;">C:\&gt; set /p BCPJAR= &lt; BOOTCLASSPATH-jar.txt<br />C:\&gt; echo %BCPJAR:.jar=.odex% &gt; BOOTCLASSPATH-odex.txt<br />C:\&gt; set /p BCPODEX= &lt; BOOTCLASSPATH-odex.txt<br />C:\&gt; echo %BCPJAR% &amp;&amp; echo %BCPODEX%<br />C:\&gt; FOR %a in (%BCPJAR::= %) do @echo %a &gt;&gt; BOOTCLASSPATH-jar-lines.txt<br />C:\&gt; FOR %a in (%BCPODEX::= %) do @echo %a &gt;&gt; BOOTCLASSPATH-odex-lines.txt<br />C:\&gt; mkdir framework<br />C:\&gt; cd framework<br />C:\&gt; FOR /F %i in (..\BOOTCLASSPATH-jar-lines.txt) DO adb pull %i<br />C:\&gt; FOR /F %i in (..\BOOTCLASSPATH-odex-lines.txt) DO adb pull %i</span><br /></span></pre></div><span style="font-family: inherit;"></span><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">The "framework" directory can now be used as the input for the baksmali "-d" argument.</span></div><span style="font-family: inherit;"></span></span></span></span></span></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span style="font-family: inherit;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;">After running the baksmali command, a new "Settings" directory will be created containing the Settings app Smali code. The smali tool can be used then to reassemble the Smali code into a Dalvik EXecutable file (.dex file). The tool simply requires two arguments, the previously created "Settings" directory and the output DEX filename (-o):</span></span><br /> </span><span lang="EN-US" style="mso-ansi-language: EN-US;"><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-size: 10pt; line-height: 115%; mso-ansi-language: EN-US;"><span style="font-family: &quot;Courier New&quot;, Courier, monospace;"><span style="font-size: small;">C:\&gt; smali Settings -o Settings.dex<o:p></o:p></span></span></span></div><span style="font-family: inherit;"></span><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;"><span lang="EN-US" style="mso-ansi-language: EN-US;">As a result, a new "Settings.dex" file will be created containing a deoptimized binary version of the Settings app. This file would be similar to the "classes.dex" file available in the APK file for third-party apps. At this point, the dex2jar tool can be run on this DEX file to decompile the Dalvik EXecutable and extract the corresponding Java bytecode (.class files):<o:p></o:p></span></span></div><span style="font-family: inherit;"></span><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;"> </span><span style="font-family: &quot;Courier New&quot;, Courier, monospace;"><span lang="EN-US" style="font-size: 10pt; line-height: 115%; mso-ansi-language: EN-US;"><span style="font-size: small;">C:\&gt; dex2jar Settings.dex<o:p></o:p></span></span></span></div><span style="font-family: inherit;"></span><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;"> <span lang="EN-US" style="mso-ansi-language: EN-US;">The dex2jar tool will create a new "Settings_dex2jar.jar" file that contains the Java bytecode for the Settings app. Through a Java decompiler, such as JD-GUI, it is possible to open this .jar file and obtain the Java source code for the target app, or an approximate representation of it.</span></span><br />&nbsp;</div><span style="font-family: inherit;"></span></span></span></span></span></span><o:p><span style="font-family: inherit; font-size: x-large;">Android App Dynamic Analysis</span></o:p><br /><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">The Drozer framework provides advanced capabilities to interact with Android apps and their different components. After installing the Drozer agent in the target Android device, which will act as the offensive app, it is possible to establish a communication between the Drozer<span style="mso-spacerun: yes;">&nbsp; </span>console and the agent. From the Drozer console, all the packages associated with the "settings" term can be listed, trying to identify the target Android Settings app ("com.android.settings"):</span></span></span></span></span></span><br /><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;"></span></span></span></span><br /><div class="separator" style="clear: both; text-align: center;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;"><img border="0" src="http://3.bp.blogspot.com/-4MhRGzQYop8/UqYv0fVuGpI/AAAAAAAAAWg/YganBRnd8Ys/s1600/dz_settings.png" height="348" width="640" /></span></span></span></span></div><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"></span><span lang="EN-US" style="mso-ansi-language: EN-US;"></span></span></span></span></span><div class="MsoNormal" style="margin: 0cm 0cm 10pt; text-align: left;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;"></span></span></span></span></span></span><br /><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">Drozer provides multiple modules to perform a deeper inspection on the components exposed by the Settings app, and in particular, the potentially vulnerable Activity from the total 104 Activities exported by the app, named "com.android.settings.ChooseLockGeneric":</span></span></span></span></span></span></div><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"></span><div style="text-align: center;"><span style="font-family: inherit;">&nbsp;</span><a href="http://1.bp.blogspot.com/-nRZsG9mCZYA/UqYv0ys_eLI/AAAAAAAAAWk/l9D7Ss6HXks/s1600/dz_settings_activities.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://1.bp.blogspot.com/-nRZsG9mCZYA/UqYv0ys_eLI/AAAAAAAAAWk/l9D7Ss6HXks/s1600/dz_settings_activities.png" height="348" width="640" /></span></a></div><span style="font-family: inherit;"> </span><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-ytpZQu6t-Tw/UqYv1YPcAuI/AAAAAAAAAWw/gpUbF3eVv4s/s1600/dz_settings_activities_ChooseLockGeneric.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://2.bp.blogspot.com/-ytpZQu6t-Tw/UqYv1YPcAuI/AAAAAAAAAWw/gpUbF3eVv4s/s1600/dz_settings_activities_ChooseLockGeneric.png" height="196" width="640" /></span></a></div><span style="font-family: inherit;"></span><div style="text-align: justify;"></div><span style="font-family: inherit;"></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><div class="MsoNormal" style="margin: 0cm 0cm 10pt; text-align: justify;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">At this point, the JD-GUI decompiler can be used to open the Settings app Java bytecode (.jar file) and inspect the specific class we are interested in, via the CVE-2013-6271 vulnerability details and the Activity name previously identified,<span style="mso-spacerun: yes;">&nbsp; </span>"com.android.settings.ChooseLockGeneric". By inspecting this class source code, we can see how at the Activity creation time (inside the "onCreate()" function) the "confirm_credentials" extra boolean parameter, is extracted and evaluated from the Intent, trying to determine if a confirmation is required from the user:</span></div><span style="font-family: inherit;"></span><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-X6pXZ41Z9yE/UqYvx_68uDI/AAAAAAAAAVY/LcCOK_aU32c/s1600/Settings_confirm_credentials.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://2.bp.blogspot.com/-X6pXZ41Z9yE/UqYvx_68uDI/AAAAAAAAAVY/LcCOK_aU32c/s1600/Settings_confirm_credentials.png" height="344" width="640" /></span></a></div><span style="font-family: inherit;"></span><div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt; text-align: justify;"><span style="font-family: inherit;">﻿</span></div><span style="font-family: inherit;"></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">Additionally, an extra "lockscreen. password_type" integer parameter is expected from the Intent associated to the Activity used to update the lock preferences:</span></div><span style="font-family: inherit;"></span><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-cM3AP3wpk3w/UqYvyP7LpHI/AAAAAAAAAVk/R6dm92m-eSY/s1600/Settings_update_preferences.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://2.bp.blogspot.com/-cM3AP3wpk3w/UqYvyP7LpHI/AAAAAAAAAVk/R6dm92m-eSY/s1600/Settings_update_preferences.png" height="312" width="640" /></span></a></div><span style="font-family: inherit;"></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><div class="MsoNormal" style="margin: 0cm 0cm 10pt; text-align: left;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;"></span><br /><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">The app will call then the "updateUnlockMethodAndFinish()" function that contains the final vulnerable code if the value of the previously mentioned parameter is equal to 0 (after going through the "upgradeQuality()" function and the associated code):</span></div><span style="font-family: inherit;"></span><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-4IqEhW3Zgdg/UqYvyZ-ZSrI/AAAAAAAAAVc/XMl5sTtNPRA/s1600/Settings_vulnerable_code.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://3.bp.blogspot.com/-4IqEhW3Zgdg/UqYvyZ-ZSrI/AAAAAAAAAVc/XMl5sTtNPRA/s1600/Settings_vulnerable_code.png" height="248" width="640" /></span></a></div><span style="font-family: inherit;"></span><div align="center"><span style="font-family: inherit;">﻿</span></div><span style="font-family: inherit;"></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><div style="text-align: left;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;"></span><br /><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">After inspecting the source code, it is possible to identify the two extra parameters required by the "com.android.settings.ChooseLockGeneric" Activity to be able to execute the vulnerable code. The Drozer frameworks facilitates the creation of a new Activity and the submission of the Intent with these two extra parameters against the target component:</span><br />&nbsp;</div><span style="font-family: inherit;"></span><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-y1WHM6DSgpc/UqYv1xr7cMI/AAAAAAAAAW4/Df9kx3UqdHE/s1600/dz_unlock_device.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://2.bp.blogspot.com/-y1WHM6DSgpc/UqYv1xr7cMI/AAAAAAAAAW4/Df9kx3UqdHE/s1600/dz_unlock_device.png" height="334" width="640" /></span></a></div><span style="font-family: inherit;"></span><div align="center" style="text-align: left;"><span style="font-family: inherit;">﻿</span></div><span style="font-family: inherit;"></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;"></span><br /><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">If the target Android 4.3 device is protected with a passcode (e.g. PIN code), after sending the Intent with the appropriate extra parameters from the Drozer agent to the target Settings app, the vulnerable code previously mentioned will run and the lock protection will be immediately removed from the device as shown below:</span></div><span style="font-family: inherit;"></span><div class="separator" style="clear: both; text-align: center;"><span style="font-family: inherit;"><img border="0" src="http://2.bp.blogspot.com/-zTPenUUpeko/UqYvw7sjq_I/AAAAAAAAAVA/B4cCB3qzCWk/s1600/Android_PIN.png" height="320" width="206" /></span><a href="http://1.bp.blogspot.com/-XKkQy6Rnmx8/UqYvxF6wB9I/AAAAAAAAAVM/QVxqRS5yi9o/s1600/Android_unlocked.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://1.bp.blogspot.com/-XKkQy6Rnmx8/UqYvxF6wB9I/AAAAAAAAAVM/QVxqRS5yi9o/s1600/Android_unlocked.png" height="320" width="207" /></span></a></div><span style="font-family: inherit;"></span><div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;">﻿</span></div><span style="font-family: inherit;"><span lang="EN-US" style="mso-ansi-language: EN-US;">When the lock is removed, it's quite startling to see the open device. The combination of both static and dynamic analysis techniques have allowed to identify the vulnerable code and to exploit it to remove the lock protection from the Android device.</span></span><br /><br /><span style="font-family: inherit;"></span></span></span></span></span></span></span></span></span></span></span><span style="font-family: inherit; font-size: x-large;">Countermeasures Implemented in Android 4.4</span><br /><br /><span lang="EN-US"><span style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">When the same analysis is performed in Android 4.4, and Drozer is used to exploit the vulnerability, the behavior observed is the expected one for a non-vulnerable device. Before the user or an app can change or remove the lock or passcode protection, the mobile device prompts the user for confirmation by requesting the previous lock value (e.g. the user has to enter the previous PIN code):</span></span></span></span></span></span><br /><span lang="EN-US"><span style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"></span></span></span></span></span><div class="separator" style="clear: both; text-align: center;"><span lang="EN-US"><span style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"><img border="0" src="http://4.bp.blogspot.com/-cd7nehFZemM/UqYvvzmpc7I/AAAAAAAAAUw/MwJpTDOk_RM/s1600/Android_unlocking_KitKat_4.4_prompt.png" height="320" width="203" /></span></span></span></span></span></div><span lang="EN-US"><span style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"></span></span></span></span></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><o:p><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">An in depth analysis of the new Settings app in Android 4.4 reveals how the vulnerability was fixed in the latest Android version. The default system Settings app in Android 4.4 is stored in a different location, "/system/priv-app/", the new default location for </span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;"><a href="https://android.googlesource.com/platform/frameworks/base/+/ccbf84f">Privileged Apps</a></span></span><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;"> (instead of the old default location for all System Apps in previous Android versions, "/system/app"):</span></div><span style="font-family: inherit;"></span><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-bmGrZblHi34/UqYvyyHZHSI/AAAAAAAAAVw/DBn3NptCggI/s1600/adb_pull_Settings_KitKat_4.4.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://2.bp.blogspot.com/-bmGrZblHi34/UqYvyyHZHSI/AAAAAAAAAVw/DBn3NptCggI/s1600/adb_pull_Settings_KitKat_4.4.png" height="224" width="640" /></span></a></div><span style="font-family: inherit;"></span><div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;">﻿</span></div></span></span></span></span></span></span></span></span></span></span></span></span></span></o:p></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><o:p><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"><span lang="EN-US" style="mso-ansi-language: EN-US;">The new APK location can be obtained, for example, through the package inspection capabilities available in the Drozer framework, that provide extensive information about any app:</span></span><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-1oB1mY82_9Y/UqYv1ukeo5I/AAAAAAAAAW0/A1NS0k4i_yw/s1600/dz_settings_info.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://2.bp.blogspot.com/-1oB1mY82_9Y/UqYv1ukeo5I/AAAAAAAAAW0/A1NS0k4i_yw/s1600/dz_settings_info.png" height="500" width="640" /></span></a></div><span style="font-family: inherit;"></span><div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;">﻿</span></div></span></span></span></span></span></span></span></span></span></span></span></span></span></o:p></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"><span lang="EN-US" style="mso-ansi-language: EN-US;">The Settings.odex file can be inspected in-depth following the same analysis process previously described for Android 4.3. The main difference is the extended set of libraries used by the default Android 4.4 framework, as the BOOTCLASSPATH value denotes:</span></span><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-cAzW0avaXDs/UqYvznKv5tI/AAAAAAAAAWA/xN-ix6p8GBA/s1600/adb_shell_BOOTCLASSPATH_KitKat_4.4.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://3.bp.blogspot.com/-cAzW0avaXDs/UqYvznKv5tI/AAAAAAAAAWA/xN-ix6p8GBA/s1600/adb_shell_BOOTCLASSPATH_KitKat_4.4.png" height="182" width="640" /></span></a></div><span style="font-family: inherit;"></span><div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;">﻿</span></div><span style="font-family: inherit;"></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">As a result, the following three main differences help to fix the vulnerability and make Android 4.4 not vulnerable to the same attack. The source code of the "com.android.settings.ChooseLockGeneric" class includes a new "InternalActivity" subclass at the bottom of the source code:</span></div><span style="font-family: inherit;"></span><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-8p_K4OHhEVM/UqYvxD4HPNI/AAAAAAAAAVE/UwwIgxJLMvA/s1600/ChooseLockGeneric_code_KitKat_4.4.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://1.bp.blogspot.com/-8p_K4OHhEVM/UqYvxD4HPNI/AAAAAAAAAVE/UwwIgxJLMvA/s1600/ChooseLockGeneric_code_KitKat_4.4.png" height="344" width="640" /></span></a></div><span style="font-family: inherit;"></span><div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;">﻿</span></div><span style="font-family: inherit;"></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">A quick comparison of the "ChooseLockGeneric" class source code between Android 4.4 and Android 4.3 exposes the new code introduced in version 4.4. The "onCreate()" function now verifies that the Activity is an instance of the new "InternalActivity" class, to limit its creation from other external apps:</span></div><span style="font-family: inherit;"></span><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-qVzAmXftHTQ/UqYv0AGcrXI/AAAAAAAAAWs/x1KsG7IkUtM/s1600/diff_Settings_code_KitKat_4.4_vs_JellyBean_4.3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://4.bp.blogspot.com/-qVzAmXftHTQ/UqYv0AGcrXI/AAAAAAAAAWs/x1KsG7IkUtM/s1600/diff_Settings_code_KitKat_4.4_vs_JellyBean_4.3.png" height="312" width="640" /></span></a></div><span style="font-family: inherit;"></span><div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;">﻿</span></div><span style="font-family: inherit;"></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">Finally, the AndroidManifest.xml file for the Settings app has been changed from Android 4.3 to Android 4.4 in order not to publicly export the new "InternalActivity" Activity. This XML file is in binary format, so the AXMLPrinter2 tool can be used to convert it to text for in-depth inspection:</span></div><span style="font-family: inherit;"></span><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: &quot;Courier New&quot;, Courier, monospace; line-height: 115%; mso-ansi-language: EN-US;">C:\&gt; AXMLPrinter2 AndroidManifest.xml &gt; AndroidManifest.txt</span></div><span style="font-family: inherit;"></span></span><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-rA88pJdvUgA/UqYv0Bn-WwI/AAAAAAAAAWQ/gFO3mMf4pgM/s1600/diff_Settings_AndroidManifest_KitKat_4.4_vs_JellyBean_4.3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" src="http://1.bp.blogspot.com/-rA88pJdvUgA/UqYv0Bn-WwI/AAAAAAAAAWQ/gFO3mMf4pgM/s1600/diff_Settings_AndroidManifest_KitKat_4.4_vs_JellyBean_4.3.png" height="312" width="640" /></span></a></div><span style="font-family: inherit;"></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">Again, the combination of both static and dynamic analysis techniques have allowed to confirm that Android 4.4 is not vulnerable and identify the fixes introduced in the new code to ask for confirmation before removing the lock protection from the Android device.</span></span></span></span></span></span></span></span></span></span></span></span></span></span></span><br /><span style="font-family: inherit;"></span><br /><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; font-size: x-large; mso-ansi-language: EN-US;">Tool References</span></div><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;">AXMLPRinter2: <a href="http://code.google.com/p/android4me/">http://code.google.com/p/android4me/</a><br />dex2jar: <a href="https://code.google.com/p/dex2jar/">https://code.google.com/p/dex2jar/</a><br />Drozer: <a href="https://labs.mwrinfosecurity.com/tools/drozer/">https://labs.mwrinfosecurity.com/tools/drozer/</a><br />JD-GUI: <a href="http://jd.benow.ca/#jd-gui">http://jd.benow.ca/#jd-gui</a><br />smali/baksmali: <a href="https://bitbucket.org/JesusFreke/smali/">https://bitbucket.org/JesusFreke/smali/</a></span></span></span></span></span><br /><br /><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-family: inherit;"><u><span lang="EN-US" style="mso-ansi-language: EN-US;">NOTE</span></u><span lang="EN-US" style="mso-ansi-language: EN-US;">: The different tool commands used during the analysis process are Windows batch scripts that simply invoke the corresponding Java tool, such as baksmali, executing in reality the "java -jar baksmali-2.0.2.jar %*" command.</span></span></div><span style="font-family: inherit;"></span></span></span></span></span><span style="font-family: inherit;"></span><br /><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: inherit; font-size: x-large; mso-ansi-language: EN-US;"><o:p>Additional Resources</o:p></span></div><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><a href="http://www.dinosec.com/tools/BOOTCLASSPATH.bat"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;">BOOTCLASSPATH.bat</span></span></a><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">: Windows batch script that creates a 'framework' directory with all the Android framework libraries (both .jar &amp; .odex files) specified in the local "BOOTCLASSPATH-jar.txt" file, extracted via "adb pull" from a local Android device or Android emulator (AVD).</span></span></span></span></span></span><br /><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"></span></span></span></span></span><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><a href="http://www.dinosec.com/tools/BOOTCLASSPATH-jar_4.3.txt"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;">BOOTCLASSPATH-jar_4.3.txt</span></span></a><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">: Default Android 4.3 framework libraries.</span></span></span></span></span><br /><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><a href="http://www.dinosec.com/tools/BOOTCLASSPATH-jar_4.4.txt"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="color: blue; font-family: inherit;">BOOTCLASSPATH-jar_4.4.txt</span></span></a><span lang="EN-US" style="font-family: inherit; mso-ansi-language: EN-US;">: Default Android 4.4 framework libraries.</span>&nbsp;</span></span></span></span></div><span style="mso-ansi-language: EN-US;"><span lang="EN-US"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span lang="EN-US" style="mso-ansi-language: EN-US;"><span style="font-family: inherit;"></span></span></span></span></span><span style="font-family: inherit;"><strong><em>This article has been cross-posted in the </em></strong></span><a href="http://pen-testing.sans.org/blog/pen-testing/2013/12/09/removing-the-android-device-lock-from-any-mobile-app"><span style="font-family: inherit;"><strong><em>SANS Pen-Testing blog</em></strong></span></a><span style="font-family: inherit;"><strong><em>.</em></strong></span><br />Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com3tag:blogger.com,1999:blog-2450054937036373903.post-90929721047063765982013-11-19T15:38:00.000-08:002018-10-24T04:10:11.184-07:00OWASP Vulnerable Web Applications Directory (VWAD) ProjectFor about two years (Oct 2011 - Oct 2013) I have been maintaing the "<a href="http://blog.taddong.com/2011/10/hacking-vulnerable-web-applications.html">Hacking Vulnerable Web Applications Without Going To Jail</a>" blog post, adding new vulnerable web applications you can use to put in practice your knowledge and skills acquired during web application security training sessions, as well as to test any web hacking tools and offensive techniques.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-0fL6WA_e59Q/Tp4CmaTA32I/AAAAAAAAAAQ/r0XKgf2Ej_g/s1600/get-out-of-jail.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-0fL6WA_e59Q/Tp4CmaTA32I/AAAAAAAAAAQ/r0XKgf2Ej_g/s1600/get-out-of-jail.jpg" height="133" width="200" /></a></div>However, last month we (<a href="https://www.owasp.org/index.php/User:Simon_Bennetts">Simon Bennetts</a>, <a href="https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project">ZAP project lead</a>, and myself) created the "<a href="https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project">OWASP Vulnerable Web Applications Directory (VWAD) Project</a>", migrating the previous list to a new community OWASP project where more people can contribute and get access to the current directory of vulnerable web apps. The vulnerable web applications have been classified in three categories: online, offline, and virtual machines or ISO images.<br /><br />If you are interested in contributing to the project, you have two options:<br /><ul><li>You can directly&nbsp;<a href="https://www.owasp.org/index.php?title=OWASP_Vulnerable_Web_Applications_Directory_Project&amp;action=edit">edit the associated OWASP wiki page</a>, if you have wiki write access permissions, and add any new web-apps in alphabetic order or correct mistakes. If possible, please&nbsp;<a href="https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project#tab=Project_About">let us know</a>&nbsp;when you update new content.&nbsp;</li><li>You can submit a git pull request to <a href="https://github.com/OWASP/OWASP-VWAD">the associated GITHUB project repository</a>.</li></ul>From a technical perspective, the GITHUB VWAD repository contains a couple of Python scripts to convert the wiki contents into TSV (Tab Separated Value) files, and vice versa. You can use the TSV files to import the VWAD contents into other projects or tools.<br /><br />Enjoy and contribute to the VWAD project! :-)<br /><br />Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com1tag:blogger.com,1999:blog-2450054937036373903.post-19493977885861941952013-11-13T12:43:00.000-08:002018-10-24T04:10:11.580-07:00The Birth of the DinoSec BlogAnd the story continues... Almost four years ago we founded the <a href="http://blog.taddong.com/">Taddong Security Blog</a>, replacing our first information security blog, <a href="http://www.radajo.com/">RaDaJo</a>, originally created about four years before. So, it seems I'm fated to change blogs every four years... :-)<br /><br />The new <a href="http://blog.dinosec.com/">DinoSec blog</a>, that comes to light today, will be one of the main channels&nbsp;<a href="http://www.dinosec.com/">DinoSec</a>&nbsp;will use&nbsp;to publish and promote the security research, open-source and community contributions, tools, and cutting-edge professional activities Monica and I (Raul) will be performing. DinoSec is an independent information security company we established in Spain in 2008 to support our daily activities with no public presence.<br /><br />DinoSec has a worldwide service scope, focused on improving its customers information security stance, by discovering and eliminating or mitigating the real risks that threaten their information technology infrastructures, applications, systems and networks. More details about the company are available on its website, <a href="http://www.dinosec.com/">www.dinosec.com</a>, where you can also find our <a href="http://www.dinosec.com/en/contact.html">contact details</a>.<br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-kp4CgYOdeAc/UnxAn3nnnvI/AAAAAAAAADM/rwYqVKifG0Y/s1600/dinosec.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-kp4CgYOdeAc/UnxAn3nnnvI/AAAAAAAAADM/rwYqVKifG0Y/s320/dinosec.png" height="142" width="320" /></a></div>If you were a previous Taddong blog reader and follower (or even a previous RaDaJo blog reader; if this is the case... <i><u>hats off to you</u></i>!), we are really glad to have you with us again in this new and exciting journey. If you are joining us for the first time, we welcome you on board. In any case, the blog relies on your presence and feedback, so do not forget to subscribe to the blog feed by using the syndication buttons available on the right sidebar. Now that DinoSec comes to light, you can also follow our activities in other social networks, such as <a href="http://www.twitter.com/dinosec">Twitter</a>, and in the future we might be active too in <a href="http://www.linkedin.com/company/dinosec">LinkedIn</a>, <a href="http://www.google.com/+Dinosec">Google+</a>, <a href="http://www.youtube.com/dinosectube">YouTube</a>, <a href="http://www.vimeo.com/dinosec">Vimeo</a>, and/or <a href="http://www.facebook.com/dinosec">Facebook</a>.<br /><br />Effective immediately, we are switching from Taddong blog to <b>DinoSec blog</b>! <br /><br />Raul Sileshttp://www.blogger.com/profile/15605985650569727525noreply@blogger.com0