-->

Anuncio!

Entendendo injeção de objeto PHP

A injeção de objeto PHP


Injeção de objeto PHP é uma vulnerabilidade muito incomum, pode ser difícil de explorar, mas pode ser realmente perigoso. Para entender essa vulnerabilidade, é necessário entender o básico de código PHP.

Aplicações vulneráveis


Se você achar que esse não é um tipo importante de vulnerabilidade, consulte a lista abaixo. Pesquisadores descobriram vulnerabilidades do PHP Object Injection em aplicações PHP muito comuns:

E muitos outros. Pode haver muitas outras injeções de objetos PHP não descobertas nesses ou em outros aplicativos PHP muito comuns, então talvez você possa fazer uma pausa para o café e tentar entendê-la.

Objetos e classes PHP


Classes e objetos são fáceis de entender em PHP. Por exemplo, o código a seguir apenas define uma classe com uma variável e um método:


<?php

classTestClass

{

    // A variable

    

    public$variable= 'This is a string';

    

    // A simple method

    

    publicfunctionPrintVariable()

    {

        echo$this->variable;

    }

}

// Create an object

$object= newTestClass();

// Call a method

$object->PrintVariable();

?>





Ele cria um objeto e chama a função “PrintVariable”, que imprime o valor da variável.

Se você quiser aprender mais sobre Programação Orientada a Objetos PHP, siga este link:



Métodos PHP magic


As classes PHP podem conter funções especiais chamadas funções mágicas. O nome das funções mágicas começa com “__”, por exemplo: __construct, __destruct, __toString, __sleep, __wakeup e outros.

Essas funções são chamadas automaticamente em determinadas situações, por exemplo:

  • __construct é chamado quando um objeto é criado (construtor)

  • __destruct é chamado quando um objeto é destruído (destrutor)

  • __toString é chamado quando um objeto é usado como uma string


Vamos adicionar algumas funções mágicas à nossa classe para entender como os métodos mágicos funcionam.


<?php

classTestClass

{

    // A variable

    

    public$variable= 'This is a string';

    

    // A simple method

    

    publicfunctionPrintVariable()

    {

        echo$this->variable . '<br />';

    }

    

    // Constructor

    

    publicfunction__construct()

    {

        echo'__construct <br />';

    }

    

    // Destructor

    

    publicfunction__destruct()

    {

        echo'__destruct <br />';

    }

    

    // Call

    

    publicfunction__toString()

    {

        return'__toString<br />';

    }

}

// Create an object

// Will call __construct

$object= newTestClass();

// Call a method

// Will print 'This is a string'

$object->PrintVariable();

// Object act as a string

// Will call __toString

echo$object;

// End of PHP script

// Will call __destruct

?>





Temos agora 3 outros métodos: __construct, __destruct e __toString. Como você pode ver, __construct é chamado quando o objeto é criado, __destruct é chamado quando o script PHP termina e o objeto é destruído e __toString é chamado quando o objeto age como uma string. A função "echo" tratará o objeto $ obj como uma string e a função __toString será chamada automaticamente.

Este script produzirá:



__construct

This is a string
__toString

__destruct

Estas são as idéias básicas dos métodos magic. Se você quer aprender sobre todos os métodos magic, por favor siga este link: Métodos Magic

Serialização de objeto PHP


PHP permite a serialização de objetos. Serialização é um procedimento que permite salvar um objeto e reutilizá-lo posteriormente. Por exemplo, você pode salvar um objeto contendo algumas informações do usuário e reutilizá-lo posteriormente.

Para serializar um objeto, você precisa chamar a função “serialize”. Ele retornará uma representação de string que você pode reutilizá-lo posteriormente chamando a função “unserialize” para recriar seu objeto.

Vamos pegar uma classe de usuário simples, serializar um objeto e ver sua representação serializada.


<?php

// Simple class definition

classUser

{

    // Class data

    

    public$age= 0;

    public$name= '';

    

    // Print data

    

    publicfunctionPrintData()

    {

        echo'User '. $this->name . ' is '. $this->age

             . ' years old. <br />';

    }

}

// Create a user

$usr= newUser();

// Set user data

$usr->age = 20;

$usr->name = 'John';

// Print data

$usr->PrintData();

// Serialize object and print output

echoserialize($usr);

?>



Isto irá produzir:


User John is 20 years old.

0:4:"User":2:{s:3:"age";i:20;s:4:"name;s:4:"John";}



Como você pode ver, existem variáveis de classe e dados do conjunto de usuários: John e 20. Não há nada relacionado ao método de classe (PrintData), apenas os dados do objeto são serializados.

Para reutilizar esse objeto, nós não serializamos a string serializada:





<?php

// Simple class definition

classUser

{

    // Class data

    

    public$age= 0;

    public$name= '';

    

    // Print data

    

    publicfunctionPrintData()

    {

        echo'User '. $this->name . ' is '. $this->age . ' years old. <br />';

    }

}

// Create a user

$usr= unserialize('O:4:"User":2:{s:3:"age";i:20;s:4:"name";s:4:"John";}');

// Print data

$usr->PrintData();

?>





Isto irá produzir:


User John is 20 years old.

Serializando funções magic


Como o construtor (__construct) e o destrutor (__destruct) são chamados automaticamente quando um objeto é criado e destruído, outras funções magic são chamadas quando um objeto é serializado e desserializado:

  • __sleep magic method é chamado quando um objeto é serializado (com serialize)

  • __wakeup magic method é chamado quando um objeto é desserializado (com unserialize)


Note que __sleep deve retornar um array com nomes de variáveis serializadas.

Um exemplo sobre como essas funções funcionam:


<?php

classTest

{

    public$variable= 'BUZZ';

    public$variable2= 'OTHER';

    

    publicfunctionPrintVariable()

    {

        echo$this->variable . '<br />';

    }

    

    publicfunctionconstruct()

    {

        echo'__construct<br />';

    }

    

    publicfunction__destruct()

    {

        echo'__destruct<br />';

    }

    

    publicfunction__wakeup()

    {

        echo'__wakeup<br />';

    }

    

    publicfunction__sleep()

    {

        echo'__sleep<br />';

        

        returnarray('variable', 'variable2');

    }

}

// Create an object, will call __construct

$obj= newTest();

// Serialize object, will call __sleep

$serialized= serialize($obj);

// Print serialized string

print'Serialized: '. $serialized. <br />';

// Unserialize string, will call __wakeup

$obj2= unserialize($serialized);

// Call PintVariable, will print data (BUZZ)

$obj2->PrintVariable();

// PHP script ends, will call __destruct for both objects($obj and $obj2)

?>



Isto irá produzir:



__construct
__sleep
Serialized: O:4:"Test":2:
{s:8:"variable";s:4:"BUZZ";s:9:"variable2";s:5:"OTHER";}
__wakeup
BUZZ
__destruct
__destruct



Como você pode ver, criamos um objeto, serializamos (e chamamos __sleep), criamos outro objeto desserializando o primeiro objeto serializado (e __wakeup foi chamado) e após a execução do script PHP, o destruct foi chamado para os dois objetos.

Para encontrar mais informações sobre a serialização de objetos, por favor siga este link:

Serialização de objetos

Injeção de objeto PHP


Agora entendemos como a serialização funciona, mas como podemos explorá-la? Existem várias possibilidades, tudo depende do fluxo de aplicativos, classes disponíveis e funções magic.

Lembre-se de que um objeto serializado contém valores de objetos controlados pelo atacante.

Você pode encontrar no código-fonte do aplicativo da Web, uma classe que define __wakeup ou __destruct e essas funções fazem algo que pode afetar o aplicativo da web.

Por exemplo, podemos encontrar uma classe que armazene temporariamente o log em um arquivo. Quando destruído, o objeto pode não precisar mais do arquivo de log e excluí-lo.
<?php

class LogFile
{
// Specify log filename

public $filename = 'error.log';

// Some code

public function LogData($text)
{
echo 'Log some data: ' . $text . '<br />';
file_put_contents($this->filename, $text, FILE_APPEND);
}

// Destructor that deletes the log file

public function __destruct()
{
echo '__destruct deletes "' . $this->filename . '" file. <br />';
unlink(dirname(__FILE__) . '/' . $this->filename);
}
}

?>

Um exemplo de como usá-lo:
<?php

include 'logfile.php';

// Create an object

$obj = new LogFile();

// Set filename and log data

$obj->filename = 'somefile.log';
$obj->LogData('Test');

// Destructor will be called and 'somefile.log' will be deleted

?>

Em outro script, podemos encontrar uma chamada para "desserializar" a função usando dados fornecidos pelo usuário (atacante controlado - $ _GET):
<?php

include 'logfile.php';

// ... Some other code that uses LogFile class ...

// Simple class definition

class User
{
// Class data

public $age = 0;
public $name = '';

// Print data

public function PrintData()
{
echo 'User ' . $this->name . ' is ' . $this->age . ' years old. <br />';
}
}

// Unserialize user supplied data

$usr = unserialize($_GET['usr_serialized']);

?>

Como você pode ver, o código usa a classe “LogFile”. Há uma chamada para "desserializar" a função usando dados fornecidos pelo usuário e aqui está o ponto de injeção.

Uma solicitação válida seria assim:
script.php?usr_serialized=O:4:"User":2:{s:3:"age";i:20;s:4:"name";s:4:"John";}

Mas o que acontece se, em vez de enviar um objeto “User” serializado, enviarmos um objeto “LogFile” serializado? Nada nos obriga a enviar um objeto "User" serializado, para que possamos enviar qualquer objeto serializado que desejarmos.

Vamos criar um objeto "LogFile" serializado:
<?php

$obj = new LogFile();
$obj->filename = '.htaccess';

echo serialize($obj) . '<br />';

?>

Isto produzirá:
O:7:"LogFile":1:{s:8:"filename";s:9:".htaccess";}
__destruct deletes ".htaccess" file.

Agora fazemos a solicitação usando o objeto “LogFile” serializado:
script.php?usr_serialized=O:7:"LogFile":1:{s:8:"filename";s:9:".htaccess";}

O resultado será:
__destruct deletes ".htaccess" file.

E o arquivo ".htaccess" agora é excluído. Isso é possível porque a função __destruct é chamada automaticamente e temos acesso às variáveis de classe “LogFile” para que possamos definir o “filename” para qualquer valor.

Então é daí que vem o nome da vulnerabilidade: ao invés de usar um objeto serializado esperado, você injeta outro objeto PHP, a fim de obter execução de código ou outro comportamento inesperado útil para você como um invasor.

Mesmo que esse não seja o melhor exemplo, você pode entender a ideia: não desserializar chama automaticamente __wakeup e __destruct e um invasor pode manipular variáveis de classe para atacar o aplicativo da web.

Pontos de injeção comuns


Mesmo que a capacidade de exploração “padrão” esteja relacionada às funções magic __wakeup ou __destruct, há outros pontos de injeção comuns que podem permitir que você explore esse tipo de vulnerabilidade. Tudo está relacionado ao fluxo do código do aplicativo.

Por exemplo, uma classe User pode definir um método __toString para permitir que o programador use o objeto como uma string (por exemplo, echo $ obj). Mas outra classe também pode definir um método __toString que permita que um programador leia um arquivo (por exemplo, um FileClass).
<?php

// ... In some other included file ...

class FileClass
{
// Filename variable

public $filename = 'error.log';

// Object used as a string displays the file contents

public function __toString()
{
return file_get_contents($this->filename);
}
}

// Main User class

class User
{
// Class data

public $age = 0;
public $name = '';

// Allow object to be used as a String

public function __toString()
{
return 'User ' . $this->name . ' is ' . $this->age . ' years old. <br />';
}
}

// Expected: a serialized User object

$obj = unserialize($_GET['usr_serialized']);

// Will call __toString method of the unserialized object

echo $obj;

?>

Uma solicitação válida usará um objeto de usuário serializado:
script.php?usr_serialized=O:4:"User":2:{s:3:"age";i:20;s:4:"name";s:4:"John";}

A saída representará as informações do usuário:
User John is 20 years old.

Mas o que acontece se usarmos um objeto FileClass serializado?

Podemos criar um objeto FileClass serializado como este:
<?php

$fileobj = new FileClass();
$fileobj->filename = 'config.php';

echo serialize($fileobj);

?>

E nossa string serializada será:
O:9:"FileClass":1:{s:8:"filename";s:10:"config.php";}

O que acontece se chamarmos o mesmo script anterior com o nosso objeto FileClass?
script.php?usr_serialized=O:9:"FileClass":1:{s:8:"filename";s:10:"config.php";}

Ele irá mostrar na página o conteúdo do arquivo “config.php”:
<?php

$private_data = 'MAGIC';

?>

É fácil entender por que: desserializar, em vez de criar um objeto "Usuário", criará um objeto "FileClass". Quando o script chamará “echo $ obj”, porque o objeto que fornecemos é um objeto “FileClass”, ele chamará o método “__toString” da classe “FileClass” e isso lerá e exibirá o conteúdo do arquivo especificado pela Variável "filename" que controlamos.

Outras possíveis situações de exploração


É possível usar outras funções magic também: __chamada será chamada se o objeto chamar uma função inexistente, __get e __set serão chamados se o objeto tentar acessar variáveis de classe inexistentes e assim por diante.

Mas a exploração não se limita a funções magic. A mesma ideia funcionará com funções normais. Por exemplo, uma classe User pode definir um método "get" para localizar e imprimir alguns dados do usuário, mas outra classe pode definir um método "get" que obtém dados do banco de dados, resultando em uma vulnerabilidade de Injeção de SQL. Ou um método "set" ou "write" gravará dados em um arquivo arbitrário, sendo possível explorá-lo e obter uma execução remota de código.

O único problema técnico é sobre as classes disponíveis no ponto de injeção, mas algumas estruturas ou scripts podem ter um recurso de "carregamento automático". Você pode encontrar mais informações aqui: Autoloading classes .

O maior problema é humano: entender o fluxo do código do aplicativo para explorar esse tipo de vulnerabilidade, pois pode exigir muito tempo para ler e entender o código.

Como corrigir e evitar


Não use “unserialize” nos dados fornecidos pelo usuário. Você pode usar "json_decode".

Conclusão


Mesmo que seja difícil de encontrar e ainda mais difícil de explorar, isso pode ser uma vulnerabilidade muito perigosa. Isso pode resultar em negação de serviço, leitura de arquivo arbitrário, SQL Injection, execução remota de código ou qualquer coisa que o fluxo de código do aplicativo possa permitir.

Fonte bibliográfica:


https://securitycafe.ro/2015/01/05/understanding-php-object-injection/






Compartilhar:

seksen: emulador 8086/186

Bom galera nesse pequeno tutorial vamos dar uma rápida olhada no emulador chamado seksen. O seksen é um emulador da arquitetura x86, sendo mais especifico ele emula os processadores 8086 e 80186. Podemos baixar o seksen no sourceforge no seguinte link

http://seksen.sourceforge.net/

O seksen é um emulador feito em java então é necessário o java instalado na maquina para conseguir rodar ele, esse emulador não compila os códigos apenas executa os binários então vamos precisar também de um compilador para gerar os programas da arquitetura x86 (no meu caso vou esta utilizando o nasm que é um compilador assembly muito conhecido). Depois de baixar e executar nos deparamos com uma aba onde podemos selecionar o processador, criar ou abrir uma maquina pronta.



Depois de escolher o processador e apertar em "create" vai aparecer uma nova janela, onde a aba central mostra os códigos carregados na memoria (lembrando que o 8086 funciona apenas em modo real já que o modo protegido surgiu a partir dos processadores 286/386), na aba superior da esquerda temos os registradores, na aba inferior temos algumas opções como log, output, memory e etc.



Para nós carregarmos o nosso binário apertamos no menu "File", selecionamos o tipo do nosso binário (podendo ser elks, binário puro, e Intel), procuramos o binário na maquina, e por fim escolhemos o endereço de memoria onde sera carregado aquele binário



Para esse exemplo vou criar um simples programa onde nele é setado valores em dois registradores (AX e BX), depois é feito a adição entre esses registradores e por fim armazenando em um endereço de memoria especifico (não vou ensinar asm nesse tutorial XD, caso tenha interesse tem um ebook meu ensinando o básico de asm para arquitetura x86 ou quem sabe um futuro tutorial especifico para isso \o)
org 0x0
mov ax,0x10
mov bx,0x5
add ax,bx
mov [0x20],ax
hlt

No nasm especificamos o argumento -f bin para compilar um binário puro
nasm -f bin kodo.asm -o kodo.bin

Depois de carregar o nosso binário no emulador vai esta naquele endereço de memoria especificado (no meu caso joguei no endereço 0000:0000)



Para rodar o programa apertamos no menu "run", depois basta apertar na opção "step" para rodar passo a passo ou em "run" para rodar o programa sem pausa (nesse caso para parar usamos a opção "stop" ou colocamos uma instrução hlt no nosso código ~ outra forma ainda é colocar um breakpoint). Podemos notar que os registradores assim como a memoria vai sendo modificada conforme a logica do nosso código



Bom galera esse tutorial é bem pequeno apenas para mostrar um pouco desse emulador ^^
Compartilhar:

Como saber se seus dados do Facebook foram usados pela ambridge Analytica?

Depois do ocorrido sobre o vazamento de dados que teve até audiência com o CEO do Facebook, a empresa começou a tomar medidas de proteção sobre esse quesito. Agora pra você que usa a rede no Brasil, desde ontem (10) já está disponível para você checar se seus dados foram usados.

Para acessar clique aqui: Como faço para saber se minhas informações foram compartilhadas com a Ambridge Analytica?

Caso seus dados não tiverem sido usados, você verá essa imagem.



Então com isso você já pode ficar um pouco mais tranquilo.
Compartilhar:

Endereço MAC e Protocolo ARP

Hosts e roteadores possuem endereços. Assim como temos o endereço IP na camada de rede, temos o endereço MAC na camada de enlace. Um adaptador de rede, ou NIC(Network Interface Controller), não entende endereços IP, então surge o problema de como enviar um quadro da camada de enlace de um remetente à camada de enlace de um destinatário na mesma sub-rede. Aí que entra o endereço MAC.

Um endereço MAC é um endereço da camada de enlace no qual está associado ao seu adaptador de rede, ou seja, um endereço MAC não pertence à um computador e sim ao adaptador de rede que está naquele computador. Um endereço MAC é número de 6 Bytes, representado em hexadecimal. Um endereço da camada de enlace é como um CPF, por isso dizemos que o endereço MAC é linear, ele não muda. Já um endereço IP seria hierárquico, pois depende de dois fatores, do host e da rede. Se um host transita de uma rede para outra, seu endereço IP muda, já o endereço MAC permanece o mesmo. Contudo, um endereço MAC pode ser modificado por software. No nosso estudo, vamos considerar uma utopia onde o endereço MAC é fixo.

Com os comandos abaixo você pode consultar seu endereço MAC

Linux
ifconfig

Windows
ipconfig

[caption id="" align="aligncenter" width="637"] consulta de endereço MAC via terminal[/caption]

Ainda assim, não resolvemos o nosso problema de como enviar o nosso quadro ao destinatário. Já andamos meio caminho. Surge o nosso outro personagem, o protocolo ARP, Protocolo de Resolução de Endereços. Cabe ao ARP fazer a associação de um endereço IP à um endereço MAC. Vamos descrever o nosso primeiro cenário.

Quando um datagrama da camada de rede é enviado à camada inferior, ou seja, a camada de enlace de dados, envia consigo o endereço IP de destino(vamos considerar aqui como sendo o IP destino 222.222.222.223), então o protocolo ARP faz a associação daquele endereço IP com o endereço MAC de destino através do que é chamado de tabela ARP, no qual é consistida de três campos: endereço IP, endereço MAC e TTL(tempo de vida). O TTL corresponde ao tempo em que aquela informação sobre o respectivo host irá ficar guardada na tabela ARP do host 222.222.222.221. Assim é criado um modulo ARP com um endereço MAC e esse, junto com o datagrama da camada de rede é transformado em um quadro da camada de enlace(através do enquadramento) que por si só envia pelo meio de transmissão esse quadro, que chega ao adaptador de rede de endereço MAC 5C-66-AB-90-75-B1 e repassa o datagrama para a camada de rede.



Agora vamos considerar o nosso segundo cenário. E se o host de IP 222.222.222.221 não tiver o endereço MAC de destino do IP 222.222.222.223? ARP de novo! Quando um remetente não possui o endereço MAC de um IP destino em sua tabela ARP, é utilizado um pacote ARP para fazer a requisição na sub-rede, que contém um campo de endereço IP, um campo de endereço MAC entre outras informações. Leve em consideração que os pacotes ARP tanto pra requisição quanto pra resposta são os mesmos. Assim, o remetente envia o pacote ARP com o IP do destino e com um endereço MAC FF:FF:FF:FF:FF:FF, ou seja, por broadcasting. Isso quer dizer que o pacote será enviado à todos os nós(hosts) da sub-rede. O pacote de resposta é enviado pelo host da sub-rede que está associado aquele endereço IP, e junto ao pacote é retornado o endereço MAC correspondente ao seu IP. Dessa forma, voltamos ao processo comum de ter uma tabela ARP com os dados, assim podendo enviar os quadros normalmente. É o mesmo que chegar em uma sala e gritar "Quem é o dono deste CPF?".

Chegamos ao nosso terceiro, e último cenário deste artigo. Como enviar um quadro para um host de uma sub-rede para outra sub-rede se o protocolo ARP só funciona dentro da sub-rede? Outra situação ocasionaria um erro. Primeiro considere que um roteador possui uma porta de entrada e uma de saída, e que um roteador possui dois endereços IP e apenas um endereço MAC. Assim O host da sub-rede A envia o quadro contendo o IP destino de um host em uma sub-rede B, porém, o endereço MAC anexado ao quadro é o do roteador. Chegando o quadro no roteador, ele percebe que não pode repassar o quadro para a camada de rede pois o endereço IP do quadro não corresponde ao seu, e ele não sabe de quem pertence aquele IP. Como será que ele descobre de quem pertence aquele IP? Pacotes ARP de novo!  Dessa forma, o roteador envia um pacote ARP pelo seu endereço IP de saída(do ponto de vista da sub-rede A) e questiona a quem pertence aquele endereço IP na sub-rede B. Então algum host responde com um pacote ARP de resposta. Feito isso, o roteador cria uma pacote com o endereço IP e o endereço MAC destino do host na sub-rede B e lhe envia, assim chegando ao adaptador do destino e passando o datagrama para a camada de rede.

[caption id="" align="alignnone" width="1869"] cabeçalho de um pacote ARP[/caption]

Analisando um pacote ARP com Wireshark

Para analisar uma requisição ou resposta de um pacote ARP via Wireshark basta digitar no campo de filtro:
arp

[caption id="" align="alignnone" width="559"] pacote ARP no Wireshark[/caption]

Após isso clique em algum pacote ARP e vá em Address Resolution Protocol. Lá você irá se familiarizar com as abordagens que fizemos.

Mais detalhes sobre o protocolo ARP podem ser encontrados no RFC[1180].
Compartilhar:

Como a criptografia mudou o percurso da humanidade

 

Para os leigos, Criptografia é uma área da Criptologia que tem por objetivo deixar uma mensagem legível somente para seu destinatário. Dessa forma, terceiros mal intencionados não podem compreender as informações, mesmo que tenham posse da mensagem. Acontece que um usuário comum de internet faz uso de uma criptografia complexa todos os dias,  mas de forma simplificada e natural. Nosso objetivo não é destacar esses lugares, e sim apontar com exemplos como a criptografia mudou o percurso histórico da humanidade.

Sempre existiu a necessidade de se trocar mensagens secretas, seja por reis, rainhas ou generais da antiguidade. Como essas mensagens eram importantes e determinantes, surgiram pessoas interessadas em descobrir as informações originais, chamados hoje de Criptoanalistas. Antes de começar nosso giro histórico vale destacar também a estenografia, que compreende a técnicas para esconder a mensagem em si. Um dos primeiros relatos de uso da estenografia foi nas histórias de Heródoto, onde raspavam a cabeça de um grego, tatuavam a mensagem secreta e esperavam até que o cabelo crescesse. Depois o enviavam para o lugar desejado, onde o destinatário raspava e lia a mensagem em sua cabeça. Um processo um tanto quanto custoso que foi revolucionado rapidamente também pelos gregos que viviam em solo Persa. Eles conseguiram transmitir uma mensagem através de tabuas de madeira cobertas de cera, avisando sobre a invasão que estava sendo planejada pelo rei Persa Xerxes.

Nesse momento você deve estar pensando que a estenografia pode ser de certa forma uma técnica arriscada. Já que se a mensagem for descoberta, ela poderá se facilmente entendida. Por isso em diversas situações pode ser interessante aplicar as duas técnicas. Vamos agora entrar na essência desse artigo, Como a criptografia mudou a história.

Vamos começar com a Primeira Guerra mundial. Naquela época usavam uma cifra conhecida por ADFGVX, obtida com uma combinação de técnicas de substituição e transposição. Os Aliados tinham um criptoanalista chamado Georges Pavin  que depois de muitos fracassos conseguiu decodificar a cifra e trazer vantagens escabrosas durante a guerra contra Alemanha. Nesse ponto vale até lembrar o trecho de Sun Tzu que diz : "Se você conhece o inimigo e conhece a si mesmo, não precisa temer o resultado de cem batalhas. Se você se conhece mas não conhece o inimigo, para cada vitória ganha sofrerá também uma derrota. Se você não conhece nem o inimigo nem a si mesmo, perderá todas as batalhas". Outro acontecimento extremamente importante foi o "Telegrama Zimmermann", nele estratégias de guerra Alemãs revelavam um possível acordo com o México. A interceptação e decodificação do telegrama provocou nada mais do que a entrada dos Estados Unidos na primeira guerra.  Nesse primeiro exemplo vemos então por de baixo dos panos como a criptografia e os decifradores interferiram em um confronte que normalmente só é apresentado com tiros e bombardeios pela indústria cinematográfica.

O segundo acontecimento é um pouco clichê e já foi até destacado no filme "O jogo da imitação". Estamos falando da Segunda Guerra mundial, de novo contra os Alemães. O destaque nessa época foi a Enigma, máquina criada por Arthur Scherbius e mais tarde redesenhada pelo governo Alemão. Essa máquina usava cifra simétrica com o diferencial de troca na chave para dificultar a decodificação. A equipe inglesa liderada por Alain Turing foi responsável por quebrar a cifra e mudar novamente o rumo da guerra. Ao final desse segundo exemplo podemos nos distrair dizendo que mais uma vez a Alemanha foi traída pela confiança na criptografia.

Vamos falar agora do aspecto político da criptografia. Zimmermann, aquele criptoanalisa citado acima, foi o responsável por criar um programa chamado PGP, do ingles Pretty Good Privacy. O impacto foi tão grande quando o programa foi divulgado na internet que Zimmermann foi acusado pelo governo americano, que o inclui nas categorias de armas e munições, alegando que software podia ser usado também por criminosos e terroristas(PGP).

Outro nome importante que não podemos esquecer é  Giovan Batista Belaso, que foi o criador da cifra Vigenère. Por muito tempo Blaise de Vigenère levou a fama pela invensão, porém mais tarde um livro de Giovan descrevia a técnica.  Até  1750, diversas mensagens secretas na Europa foram enviadas usando essa criptografia. Novamente ela foi quebrada, dessa vez por Babbage e Kasiski.

Esses três fatos históricos servem apenas para ilustrar de forma simples que diversos fatos históricos sofreram influência da criptografia, estenografia e dos decodificadores ou criptoanalistas. Hoje quando enviamos uma mensagem no WhatsApp, quando acessamos um site qualquer ou enviamos um e-mail, estamos em contato com códigos de criptografia que são constantemente aperfeiçoados. Esse é um assunto que pode perdurar até o fim da humanidade, e pode ser um divisor de águas em um século dominado pela tecnologia e pela internet. Para aqueles que se interessaram no assuntou vou deixar um material complementar que aborda de forma detalhada o assunto.

Livro Cypherpunks

Telegrama Zimmermann

Artigo 

 

 

 


 
Compartilhar:

Redes sociais e seus riscos a privacidade e segurança dos usuários




Não é novidade que as redes sociais ajudaram muito na interação entre as pessoas que estão mais distantes ou que simplesmente não tem tanto tempo para visitar os amigos, seja pelo fato da faculdade, trabalho, ou qualquer outra coisa que impede elas se encontrarem, então as redes sociais, suprem essa necessidade de interação, visando unicamente a aproximação.

Agora como tudo na vida tem dois lados, essa interação e compartilhamento de informações de modo em tempo real, acaba que prejudicando muitos usuários, e o que pode ser pior, as consequências desses prejuízos, podem ser absurdamente maior do que você imaginava.

Infelizmente, boa parte dos usuários comuns de redes sociais, não tem uma noção fundamentada em segurança na internet, nem se quer, muitos deles tem nenhuma informação, o que pode ser absurdamente ruim, principalmente para quem desconhece as informações, agora o que pode ser "pior", boa parte das redes sociais, disponibiliza textos, artigos, até mesmo em algum canto na documentação, colocam algo sobre privacidade, agora o que acontece, é que boa parte dos usuários simplesmente ignoram esse fato e não se dão o mínimo trabalho de ler.

Alguns exemplos pode ser citado, muitas pessoas vão a algum determinado local(não sendo a sua casa), onde os mesmos postam fotos imediatamente assim que chegam, isso tem um efeito absurdamente ruim, se baseando no perfil da mesma, em uma situação hipotética, dias atrás posta como é ruim morar só, como sua casa fica vazia, sem filhos, solteiro(a). Entenderam o perigo aqui? Um individuo, acaba de citar, que ele, e exclusivamente ele, é quem vive na casa, e quando não está em casa, a casa fica obviamente vazia no dia a dia e que ainda por cima, essa pessoa não está em casa e o que ainda pode ser pior, ela acabou de chegar em um local e vai demorar algumas horas pra voltar pra casa, o que pode ocorrer é, que quando alguém mal intencionado, com posse dessas informações, sabendo que o individuo, que mora só, está "viajando" e obviamente não há ninguém em casa, então entende que a casa está livre para invasão.

Um outro exemplo, é o sentido de filhos, o que pode ser algo inocente, simples, meigo, até porque, muitos gostam de ver um rostinho bonito de uma criança. Todavia, o que acontece quando alguém já mal intencionado pode ver, é, o rosto da criança, nome (muitos pais já falam o nome da criança) e como também na rede social, realmente os usuários usam nome e sobrenome, obviamente, o sobrenome também é o mesmo, e ainda pior, muitos pais, postam foto da criança fardada, principalmente naqueles famosos "primeiro dia de aula de fulaninho" que quase certeza a criança está com a farda. Então novamente em posse dessas informações, a pessoa mal intencionada, pode planejar simplesmente um sequestro a criança.

Nesses pequenos exemplos, podemos ver que, claramente, mesmo que pequenos atos, podem se acabar variando em grandes ocorrências que ninguém imaginaria um dia passar, todavia, o que ocorre muito é que muitos pensam e sem dúvidas você já ouviu ou disse "isso nunca irá acontecer comigo", é ai onde está o problema, é criado essa bolha de falsa segurança, onde a pessoa acha que está plenamente salva disso apenas por não ser alguém "famoso'' ou alguém muito conhecido, mas engana-se.


Agora, o que realmente fazer para evitar isso?

Poderá ser feito simplesmente, evitar o uso de postagens instantâneas, exemplificando, no caso da pessoa que mora só, poderia bater as fotos e postar quando tivesse em casa, que tanto aproveitaria o local, quanto mostraria para os amigos o que queria mostrar. Sobre a criança, poderia não expor o nome da criança, nem que turno estuda e melhor ainda se não postar o fardamento.

Com pequenas medidas de prevenção, já diminui o escopo de informações públicas fornecidas muitas vezes a pessoas que você não conhece, sendo assim, minimizando os riscos que você poderá sofrer futuramente, embora ainda não esteja seguro. O mais interessante disso tudo, é que não citamos em momento algum, nenhum tipo de ferramenta de hacking, apenas o próprio usuário que compartilha as suas informações, e alguém coleta, sendo assim, não necessitando de um conhecimento aprofundado na área de segurança.

Uma boa prática a ser adotada, é pegar a área de privacidade da sua rede social, ler o que tem a oferecer e usar tudo aquilo que melhor poderá te ajudar a esconder as suas informações de forma que ninguém terá acesso a elas.

Então, com isso, muito cuidado com o que você compartilha.
Compartilhar:

Brasileiros criam vírus para clonar cartões de crédito

Um vírus Brasileiro baseado no Prelex, o mesmo tem como alvo os sistemas das máquinas de cartão de crédito, que atualmente boa (Não temos a informação certa se são todas) parte das máquinas usam derivados do C.

Infelizmente para nós consumidores, esse vírus abrange ambos os modos de compra, Débito e crédito, a habilidade de clonagem de cartão, é a segunda habilidade desta praga virtual, que tornou-se conhecida por agir primeiramente em caixas eletrônicos e após a infecção fazê-los “cuspir” dinheiro involuntariamente.
A programação do mesmo, teve de ser totalmente (figurativamente falando) programada novamente, na sua atual versão o vírus foi tão bem desenvolvido, que ele funciona habilitando inclusive transações protegidas pelas funcionalidades de chip e senha. Isso da abrangência para o criminoso realizar compras em lojas, tanto online, tanto offline. Funciona simplesmente pelo fato devido a uma implementação incorreta de um padrão técnico, que prejudica a autenticação e a verificação de alguns dados.
Segundo o analista de segurança Thiago Marques, da Kaspersly Lab, é preciso todo cuidado com a nova ameaça. “Estamos lidando com um novo tipo de malware que oferece suporte para os criminosos em suas operações, tudo com uma interface gráfica de usuário e modelos bem elaborados para criar diferentes estruturas de cartões de crédito. Cremos que a ameaça do Prilex e seu modelo de negócios são importantes para serem compartilhados com a comunidade; já que esses ataques estão se tornando cada vez mais fáceis de realizar”.

De todos os titulares de cartões – débito, crédito e pré-pago – 30% sofreram fraude nos últimos cinco anos, o que representa uma parte significativa do mercado brasileiro. Números de 2016 mostram que o Brasil ocupa o segundo lugar no ingrato ranking de pessoas atacadas virtualmente. 49% já teve algum problema com transações (o México lidera com 56% dos residentes relatando ter sofrido dessa fraude nos últimos 5 anos).

Em relação às fraudes de cartões de débito, o ranking mostra novamente o México na frente, com 34%, seguido pelo Brasil (25%), Índia (23%) e França (22%), de acordo com o 2016 Global Consumer Card Fraud.

fonte: tribunapr

Como funciona o ataque

Basicamente, a máquina infectada com esse tipo de vírus, apenas copia as informações dos cartões inseridos na mesma, assim já que ela está conectada a internet para fazer uma transação, como por exemplo a venda de algum produto, ela apenas envia as informações do cartão "clonado" para um servidor externo, para a clonagem, então ai, já era, as informações foram enviadas e estão pronto para serem usadas. Agora para fazer as compras em loja física, os atacantes usam os conhecidos Smart's card's, que serviam para fazer esse tipo de compra.
Compartilhar:
← Anterior Proxima → Inicio

Formulário de contato

Nome

E-mail *

Mensagem *

Sites Parceiros

Anuncio No Post

Anuncio No Post

Anuncio Aqui!