¿Por qué debemos de informar sobre 0Day?

En las últimas semanas no cesan de aparecer noticias relacionadas con PRISM desde que lo filtrara Edward Snowden, que trabajaba para Booz Allen Hamilton, contratista de defensa para la NSA.

Un resultado interesante de estas filtraciones es el acceso por parte de la NSA a vulnerabilidades 0Day por parte de Microsoft y quién sabe si de otras grandes compañías (Google, Apple, Adobe, etc.) bajo los programas de colaboración Microsoft Active Protections Progam (MAPPS) y el Security Cooperation Program (SCP). El primero es para empresas de seguridad y el segundo para organismos gubernamentales -por ejemplo la agencia de inteligencia española (CNI) es miembro de este programa- con el objetivo de ser informados los primeros cuando aparecen vulnerabilidades para poder protegerse antes de que salgan los conocidos parches y actualizar sus productos de seguridad.

Estos programas se crearon con fines defensivos pero plantean una interesante cuestión: el uso de esta información para fines ofensivos.

Encontrar vulnerabilidades en productos de las grandes compañías es cada vez más costoso, por lo que el acceso a información sobre 0Day por parte de las agencias de inteligencia les hace ganar tiempo y ahorrar recursos. Ahora solo tienen que desarrollar exploits para atacar cualquier sistema, ya que recordemos que aún no se ha publicado el parche de seguridad.

Los países que quieran establecer unas capacidades ofensivas y defensivas deberían crear programas nacionales que ofrezcan una recompensa económica (en función de una escala) a los individuos que les informen de 0Day.

Las grandes compañías de software e Internet son principalmente americanas, pero muchas vulnerabilidades son identificadas y reportadas por expertos en seguridad extranjeros. Si existiera un programa nacional sobre vulnerabilidades podrían informar primero a su gobierno y no a las compañías de software.

La cuestión es ¿por qué debemos informar de vulnerabilidades a las compañías de software para que ellos a su vez informen a sus agencias de inteligencia para realizar actos ofensivos a otras naciones?

Recordemos que las vulnerabilidades 0day y exploits tienen valor económico hoy en día, y muchas empresas públicas y privadas pagan un buen dinero por ello.

En el fondo no deberían sorprendernos los actos de la NSA, ya que al fin y al cabo su misión es la seguridad nacional utilizando todos los medios posibles (legales ¿?), igual que hacen las agencias de inteligencia de muchos países.

Lo que está claro es que el caso PRISM puede que tenga más repercusiones para los EE.UU. de lo que parecía en un principio, y seguramente muchos países cambien su política de ciberseguridad defensiva / ofensiva.

Sin duda será interesante observar cómo las políticas de ciberseguridad evolucionan en los países durante los próximos años.

¿Qué cambios crees que son necesarios en las políticas de ciberseguridad?

— Simon Roses Femerling

Publicado en Hacking, Seguridad, Tecnologia | Etiquetado , , , , , , , | Deja un comentario

Una historia de troyanos gubernamentales

Mucho se está hablando estos días sobre el posible uso de troyanos por parte de las Fuerzas y Cuerpos de Seguridad del Estado debido al anuncio de un borrador de la comisión Gallardón, que propone el uso de troyanos y colaboración de hackers para acceder a ordenadores, tabletas y móviles en el curso de investigaciones de delitos de especial gravedad.

Disclaimer: soy el fundador de VULNEX, una boutique española altamente especializada en ciberseguridad que ofrece servicios y productos ofensivos y defensivos por lo que quizás no sea objetivo, pero tampoco pretendo serlo.

Como era de esperar, se están diciendo auténticas barbaridades en muchos medios de prensa, imagino que por la falta de conocimiento en la materia, por lo que expresaré mi opinión al respecto e intentaré arrojar un poco de luz sobre el asunto.

Personalmente no estoy en contra de la utilización de troyanos por parte de las Fuerzas y Cuerpos de Seguridad SIEMPRE Y CUANDO sea para capturar criminales (pederastas, terroristas, mafias, etc.) y NUNCA para otros fines (políticos, espionaje, etc.). Aunque estando en España y con la clase política que tenemos esta cuestión es realmente preocupante.

Vayamos por partes:

  1. Los criminales se han modernizado y utilizan sofisticadas medidas de seguridad informática (equipos de última generación, cifrado seguro, servidores por diferentes países sin tratados de extradición, etc.), por lo que es absolutamente necesario que las Fuerzas y Cuerpos de Seguridad se modernicen y utilicen las últimas tecnologías ofensivas y defensivas para la seguridad nacional.
  2. Pensemos que esto es el equivalente a las escuchas telefónicas (por las que nadie protesta) en el mundo digital.
  3. El uso de troyanos por parte de los gobiernos no es nada nuevo, solo que se mantiene en secreto o se intenta al menos (por ejemplo, Alemania o el FBI en los EE.UU.).
  4. Lo que se propone en el borrador no es pecata minuta, ya que escribir un troyano no es nada trivial. Para esta tarea vamos a requerir un equipo muy preparado con diferentes perfiles (jefes de proyecto, programadores para las diferentes tecnologías, expertos en vulnerabilidades, equipo de testeo, etc.). Vamos, unas capacidades ofensivas que actualmente no existen en este país y sobre todo que no son baratas. (Ejemplo estimación del equipo desarrollo de Stuxnet)
  5. Aparte del troyano con soporte para diferentes plataformas hay que contar con una infraestructura de comunicaciones, soporte y almacenamiento de datos. ¿Cómo y dónde se almacena la información recolectada? ¿Podrían los criminales atacar la infraestructura o subvertir el troyano?
  6. Si este troyano existiera, ¿cómo se haría llegar e instalaría en los equipos de los sospechosos? La seguridad en los entornos desktops (Windows, Linux, MacOS) no tiene el mismo nivel de seguridad que en móviles (Android, iPhone/iOS, BlackBerry, Windows Phone, Firefox OS, etc.). Hoy en día existen varias compañías que ofrecen troyanos profesionales y que aún no han resuelto este problema.
  7. Respecto a la colaboración de hackers, tendremos que ver en que consiste exactamente la colaboración. La cuestión es si será por la fuerza y gratis o remunerada. ¿Qué tipo de hackers: buenos/éticos o detenidos anteriormente? ¿Tendrían acceso al troyano? ¿A qué tipo de información tendrían acceso? ¿Podrían sabotear la operación?, etc.
  8. Los antivirus no serían un impedimento como se dice en algún medio, ya que esta tecnología presenta diversos problemas (por mucho que lo nieguen y les pese a las casas antivirus). Si son tan fiables que se lo digan a Google, RSA, Lockheed-Martin entre otros muchos que han sido atacados y comprometidos y que por supuesto contaban con antivirus, así como otros mecanismos de seguridad (ojo, estoy a favor del uso de los antivirus, pero como una medida más dentro de una estrategia de Defensa en Profundidad).
  9. El desarrollo y uso de tecnologías ofensivas y defensivas por parte de agentes del gobierno deberían estar enmarcados dentro de un plan nacional (Estrategia de CiberSeguridad), que tanto reclama el sector privado. Tema que la EU está trabajando.
  10. Nos quejamos del uso de troyanos por parte de los gobiernos, que lo que buscan es capturar criminales, argumentando que se vulneran nuestros derechos cuando nosotros mismos no paramos de subir información y fotos tanto propias como de nuestro entorno totalmente gratis a todo tipo redes sociales, que son empresas privadas que ganan mucho dinero ofreciendo esta información a terceros y que saben demasiado.

En España hemos sufrido y seguimos sufriendo el azote del terrorismo y demás lacras, todo lo que sea acabar con ello me parece fantástico siempre que se respete la libertad y el derecho de los ciudadanos.

¿Y cuál es tu opinión al respecto sobre esta cuestión: a favor o en contra?

— Simon Roses Femerling

Publicado en Hacking, Hacking Etico, Malware, Privacidad, Seguridad, Tecnologia | Etiquetado , , , , , , , | 5 comentarios

AppSec: Cómo detectar Rooted en tu app

Por diferentes motivos muchas apps necesitan detectar si el teléfono ha sido “rooteado”, por lo que en este artículo veremos diferentes técnicas para averiguarlo. He pensado que un post sobre el tema sería de interés para muchos lectores, ya que es frecuente ver este tipo de preguntas en foros de desarrollo.

En este post de StackOverflow podemos encontrar técnicas comúnmente utilizadas en apps para detectar Rooted. El siguiente código hace uso de 3 métodos para detectar Rooted: el primero busca la cadena “test-keys”, que es una llave genérica para firmar paquetes; el segundo método comprueba si existe el Superuser.apk en el disco, esta app gestiona el acceso al comando su (privilegios administrador) para las demás apps; y por último el tercer método llama directamente a su y ejecuta un comando con privilegios de root.


 /**
 * @author Kevin Kowalewski
 * 
 */
public class Root {

    private static String LOG_TAG = Root.class.getName();

    public boolean isDeviceRooted() {
        if (checkRootMethod1()){return true;}
        if (checkRootMethod2()){return true;}
        if (checkRootMethod3()){return true;}
        return false;
    }

    public boolean checkRootMethod1(){
        String buildTags = android.os.Build.TAGS;

        if (buildTags != null && buildTags.contains("test-keys")) {
            return true;
        }
        return false;
    }

    public boolean checkRootMethod2(){
        try {
            File file = new File("/system/app/Superuser.apk");
            if (file.exists()) {
                return true;
            }
        } catch (Exception e) { }

        return false;
    }

    public boolean checkRootMethod3() {
        if (new ExecShell().executeCommand(SHELL_CMD.check_su_binary) != null){
            return true;
        }else{
            return false;
        }
    }
}

/**
 * @author Kevin Kowalewski
 *
 */
public class ExecShell {

    private static String LOG_TAG = ExecShell.class.getName();

    public static enum SHELL_CMD {
        check_su_binary(new String[] {"/system/xbin/which","su"}),
        ;

        String[] command;

        SHELL_CMD(String[] command){
            this.command = command;
        }
    }

    public ArrayList
<string> executeCommand(SHELL_CMD shellCmd){
        String line = null;
        ArrayList
<string> fullResponse = new ArrayList<string>();
        Process localProcess = null;

        try {
            localProcess = Runtime.getRuntime().exec(shellCmd.command);
        } catch (Exception e) {
            return null;
            //e.printStackTrace();
        }

        BufferedWriter out = new BufferedWriter(new OutputStreamWriter(localProcess.getOutputStream()));
        BufferedReader in = new BufferedReader(new InputStreamReader(localProcess.getInputStream()));

        try {
            while ((line = in.readLine()) != null) {
                Log.d(LOG_TAG, "--> Line received: " + line);
                fullResponse.add(line);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }

        Log.d(LOG_TAG, "--> Full response was: " + fullResponse);

        return fullResponse;
    }

}
</string></string></string>

Las apps en un teléfono que no este rooteado no podrían ejecutar cualquiera de estos métodos, ya que todas las apps en Android están dentro de una sandbox (un sistema de aislamiento de procesos) y con privilegios limitados.

Los tres métodos descritos posiblemente sean los más comunes y si hacemos ingeniería inversa de forma frecuente los podemos encontrar en conocidas apps.

Otras técnicas incluyen el uso de la fantástica librería RootTools que facilita el desarrollo de apps que necesitan root ofreciendo diversas herramientas. Muchas apps utilizan esta librería.

Las funcionalidades de esta librería incluyen comprobar si existe o instalar BusyBox (programa que combina muchas utilidades estándares de Unix en un solo ejecutable pequeño), comprobar si existe o instalar SuperUser, comprobar que se tiene acceso root, herramientas nativas o suficiente espacio en la SD Card.

Como ejercicio para comprobar las técnicas de detección de Rooted he escrito el VULNEX ROOT TESTER que combina diferentes técnicas, desde las básicas aquí presentadas a algunas más sofisticadas de las que hablaremos en otro post. A continuación algunas capturas de la herramienta.

vulnex_root_tester1
vulnex_root_tester2
vulnex_root_tester3
vulnex_root_tester4

Sin duda la capacidad de detectar Rooted puede ser necesaria para determinadas apps que requieren un elevado nivel de seguridad, pero igualmente para muchas apps legítimas, como diversas apps de seguridad, requieren de root para funcionar correctamente o aprovechar al máximo la plataforma Android.

Tenemos que tener en cuenta que a la hora de escribir una app segura no es suficiente con detectar Rooted, sino que también debemos pensar en realizar un modelo de amenazas de los posibles riesgos para nuestra app, desarrollar de forma segura (por ejemplo OWASP Mobile) y aplicar técnicas de ofuscación de código (entre otras muchas medidas) para mitigar vulnerabilidades y dificultar la ingeniería inversa. Mi recomendación es que si no estamos familiarizados con estos conceptos hablemos con algún profesional en desarrollo seguro.

¿Y vuestra app que técnicas utiliza para detectar Rooted?

— Simon Roses Femerling

Publicado en Hacking, Hacking Etico, Modelo de Amenazas, OWASP, Privacidad, SDL, Seguridad | Etiquetado , , , , , , , , , | Deja un comentario