Acesso de alto desempenho para armazenamento de arquivos
Akamai emitiu novos certificados SSL para alguns de seus clientes depois de perceber sua OpenSSL personalizado não era imune ao erro Heartbleed como primeiro pensamento.
Algum tempo atrás, a gigante de distribuição web modificado o código para a biblioteca OpenSSL open-source e rolou a versão tweaked para apenas seus servidores: a de que o ajuste mudou a forma como a biblioteca aloca memória para que todos os dados particularmente sensíveis, como cripto-privada chaves, é mantido bem longe de alocações de uso geral que podem ser extraídos de longe usando o Heartbleed bug.
Akamai, assim, alegou chaves SSL privadas de seus clientes estavam a salvo de ataques Heartbleed, que trabalham por peneirar a memória de uma máquina remota para guloseimas secretas, como senhas e chaves. Mesmo assim, a Akamai ainda aplicada a correção Heartbleed ao seu sabor de OpenSSL apenas para ser seguro, pois as pessoas que encontraram o bug advertiu o biz antes de ir a público na segunda-feira 7 de Abril. Mas, fundamentalmente, ele não sente a necessidade de emitir mais do que um número muito pequeno de novas chaves privadas SSL.
Na sexta-feira, Abril 11, cinco dias após o Heartbleed vulnerável foi revelado, a Akamai escreveu em seu blog:
Akamai corrigiu a vulnerabilidade Heartbleed anunciado antes do seu anúncio público. Nós, como todos os usuários do OpenSSL, poderia ter exposto senhas ou cookies de sessão que transitam nossa rede a partir de agosto de 2012 a 04 de abril de 2014. Nossa alocador de memória personalizado protegido contra quase todas as circunstâncias pelas quais Heartbleed poderia ter vazado chaves SSL. Há uma janela muito estreita através da qual quatro clusters de servidores Akamai teve um lançamento vulnerável por 9 dias em março de 2013. Para o pequeno número de clientes potencialmente afectados, somos certificados de giro pró-ativamente.
Akamai, em seguida, dividiu o código fonte para suas modificações OpenSSL com o mundo, que, embora apreciado, é o lugar onde as rodas começaram a cair.
Bod infosec Independent Willem Pinckaers olhou para o código e foi capaz de criar buracos no "seguro" alocador de memória da Akamai, descarrilar a sua defesa contra a falha Heartbleed.
Na segunda-feira, abril 14, a empresa tinha invertido a sua posição: ele admitiu que vai mudar-up chaves criptográficas privadas dos clientes depois de tudo - porque há uma chance de que eles poderiam ter sido comprometida por qualquer pessoa que sabia do bug OpenSSL:
No fim de semana, um pesquisador independente de segurança contactado Akamai sobre alguns defeitos no software que usamos para alocação de memória em torno de chaves SSL. Discutimos sexta-feira como nós acreditava que isso tinha fornecido as nossas chaves SSL com proteção contra Heartbleed e tinha contribuído o código de volta para a comunidade. O código que havia contribuído para trás era, como vimos, não um patch completo, mas seria um ponto de partida para melhorar a base de código openssl.Em suma: tivemos um bug. Uma chave RSA tem 6 valores críticos; nosso código só tentaria proteger três partes da chave secreta, mas não protege 3 outros. Em particular, apenas tentar proteger d, p, e q, mas não d mod (p-1), d mod (q-1), ou q ^ {-1} mod p. Esses valores extras intermediários (o Teorema chinês Restante, ou CRT, valores) são calculados em tempo de key-geração como uma melhoria de desempenho. Como os valores CRT não foram armazenados na área de memória de segurança, existe a possibilidade de que estes valores críticos para as chaves SSL poderia ter sido exposto a um adversário explorando a vulnerabilidade Heartbleed. Dado qualquer valor CRT, é possível calcular todos os 6 valores críticos.
Como resultado, começamos o processo de girar todos SSL cliente chaves / certificados. Alguns desses certificados vai girar rapidamente; alguns exigem validação extra com as autoridades de certificação e pode demorar mais tempo.
Akamai cobra de seus clientes extra para servir de mídia através de HTTPS a partir de sua rede de distribuição, de modo que muitos usuários não Akamai optou por SSL e, portanto, não que muitas chaves privadas armazenadas nos servidores da empresa. Por isso que muitos não foram afetados pela falha Heartbleed, como alguns observadores de segurança já apontado .
Akaami agiu prontamente quando ele percebeu que havia um problema, mas cripto-especialistas ainda criticada a biz para colocar demasiada confiança nas garantias que acabou por ser falho.
"Nada contra a Akamai, mas a sério: eles realizada fora substituindo certs porque eles achavam que eram seguros Ugh," disse Matthew Green , professor de ciência da computação na Universidade Johns Hopkins. "Eu realmente gostaria de ouvir o caso de que a Akamai não jogou roleta russa com a segurança de seus clientes."
Akamai não é o único gigante de tecnologia coloca-lo no pescoço para sua manipulação de Heartbleed. Dropbox tem sido criticada por não avisar os clientes foi afetada pelo bug perigoso até sábado, e mesmo assim apenas mencioná-lo em um post no fórum facilmente esquecido e não através de seu blog corporativo.
O australiano foi grande sobre o assunto, em vez de informar sobre a abertura de um escritório de Sydney pela roupa sincronização e compartilhamento de nublado, já sob o ataque no início desta semana para a sua nomeação do ex-secretário de Estado dos EUA (e defensor de vigilância), Condoleezza Rice, para o seu conselho do diretor como um conselheiro de privacidade. ®
Nenhum comentário:
Postar um comentário