Cyber warfare cada vez mais presente

Sempre que tento convencer alguém, ou uma empresa, ou o mercado, que estamos cada vez mais vulneráveis e que corremos o risco de um dia estarmos todos nas mãos de meia-dúzia de indivíduos, que podem desligar-nos com o clique de um rato, debato-me com alguma relutância e até desdém.

Imagino que muitos se sintam também assim quando tenta vender a Segurança da Informação a pessoas menos sensibilizadas (ou menos informadas).

Só que por vezes acontecem eventos (ou indícios de eventos pois o controlo de informação também existe, quer queiramos quer não, pelas mais diferentes razões) que permitem abrir-nos os olhos pois passamos a apoiar-nos nos ombros de gigantes.

O seguinte artigo que copio na íntegra (referência no seu início) é, de facto, esclarecedor e simultaneamente transtornante.

Os 0-days de que falam são vulnerabilidades desconhecidas (com excepção de uma micro-minoria), descobertas ou provocadas por hackers e figurinhas afins, que são negociadas, vendidas, compradas, emprestadas, etc., a dinheiro ou com base na simples amizade.

E o resultado está à vista. Nation Cyber Warfare está a chegar e em força. William Gibson escreveu sobre isso há 20 ou 30 anos em Neuromancer, num mundo em que as nações são meta-corporações. Acho que qualquer semelhança com a realidade começa a não ser mera coincidência ….

Que o artigo abra o apetite a todos e, quem sabe, permita (se bem circulado pela organização de cada um) aumentar significativamente o orçamento dedicado à protecção do negócio.

Claro que podemos sempre perguntar-nos porque razão redes como as de um Operador de Comunicações português, por exemplo, poderiam ser alvo do interesse desta gente?! … Não são Centrais Nucleares, afinal de contas! … Não são, de facto, mas ligam muita gente ao mundo, entram na casa de muitas pessoas, pessoas essas que poderão ser precisamente as pessoas que estes low-profile-super-hackers precisam que carreguem malware para dentro da Central Nuclear. E os dados estão lançados.

Artigo original na Wired disponível aqui.

“Blockbuster Worm Aimed for Infrastructure, But No Proof Iran Nukes Were Target” By Kim Zetter

September 23, 2010

An exceptionally sophisticated piece of malware designed to attack programs used in critical infrastructure and other facilities garnered extensive attention among computer security experts this week as new details about its design and capabilities emerge, along with speculation it was aimed at disrupting Iran’s nuclear program.

“It’s the most complex piece of malware we’ve seen in the last five years or more,” says Nicolas Falliere, a code analyst at security firm Symantec. “It’s the first known time that malware is not targeting credit card [data], is not trying to steal personal user data, but is attacking real-world processing systems. That’s why it’s unique and is not over-hyped.”

The Stuxnet worm, which was discovered in June and has infected more than 100,000 computer systems worldwide, is designed to attack the Siemens Simatic WinCC SCADA system. SCADA systems, short for “supervisory control and data acquisition,” are programs installed in pipelines, nuclear plants, utility companies and manufacturing facilities to manage operations.

But even more intriguingly, researchers say the worm is designed to attack a very particular configuration of the Simatic SCADA software, indicating the malware writers had a specific facility or facilities in mind for their attack and had extensive knowledge of the system they were targeting. Although it’s not known what system was targeted, once on the targeted system, the worm was designed to install additional malware, possibly with the purpose of destroying the system and creating real-world explosions in the facility where it ran.


The worm was publicly exposed after VirusBlokAda, an obscure Belarusian security company, found it on computers belonging to a customer in Iran — the country where the majority of the infections occurred. Initial analysis suggested the worm was designed only to steal intellectual property — perhaps by competitors wishing to copy manufacturing operations or products.


But researchers who have spent the last three months reverse-engineering the code and running it in simulated environments now say that it’s designed for sabotage, and that its level of sophistication suggests that a well-resourced nation-state is behind the attack. A few researchers have speculated that Iran’s nascent nuclear program was a possible target for the worm’s destructive payload, though that’s based on circumstantial evidence.


Sophisticated Code


Ralph Langner, a computer security researcher in Germany, published an extensive look at the malware last week. He determined that once on a computer the malware looks for a specific configuration of a Siemens component called the Programmable Logic Controller, or PLC. If the malware determines it’s on the correct system, it begins to intercept communications from the system’s Simatic Manager to the PLC and interjects numerous commands to reprogram the PLC to do what it wants.


Symantec provided an even more detailed description of the malware on Wednesday and plans to release a paper about Stuxnet at a conference Sept. 29. Symantec’s Falliere, reached in France, said two models of Siemens PLCs are targeted by the worm — the S7-300 series and the S7-400 series — which are used in many facilities.


The malware is huge — about half a megabyte of code — and has a number of sophisticated and previously unseen characteristics:

  • It uses four zero-day vulnerabilities (vulnerabilities that haven’t yet been patched by a software vendor and are generally undetected by antivirus programs). One zero-day is used to spread the worm to a machine by a USB stick. A Windows printer-spooler vulnerability is used to propagate the malware from one infected machine to others on a network. The last two help the malware gain administrative privileges on infected machines to feed the system commands.
  • The malware is digitally signed with legitimate certificates stolen from two certificate authorities.
  • The attacker uses a command-and-control server to update the code on infected machines but also uses, in case the command server is taken down, peer-to-peer networking to propagate updates to infected machines.

The malware would have required a team or teams of people with different skills — some with extensive knowledge of the targeted PLC, and others who specialize in vulnerability research to find the zero-day holes, analysts say. The malware would have required extensive testing to ensure it could commandeer a PLC without crashing the system or setting off other alerts of its presence.


Eric Byres, chief technology officer for Byres Security, says the malware isn’t content to just inject a few commands into the PLC but does “massive reworking” of it.


“They’re massively trying to do something different than the processor was designed to do,” says Byres, who has extensive experience maintaining and troubleshooting Siemens control systems. “Every function block takes a fair amount of work to write, and they’re trying to do something quite radically different. And they’re not doing it in a light way. Whoever wrote this was really trying to mess with that PLC. We’re talking man-months, if not years, of coding to make it work the way it did.”


Although it’s unclear what specific processes the malware attacked, Langner, who couldn’t be reached, wrote on his blog that “we can expect that something will blow up” as a result of the malware.


Byres agrees and says this is because the malware interjects what’s known as Organizational Block 35 data blocks. OB35 data blocks are used for critical processes that are either moving very fast or are in high-pressure situations. These data blocks take priority over everything else in the processor and run every 100 milliseconds to monitor critical situations that can change quickly and wreak havoc.


“You use this priority for things that are absolutely mission-critical on the machine — things that really are threatening to the life of the people around it or the life of the machine,” Byres says, “like a turbine or a robot or a cyclone — something that’s going very, very fast and will tear itself apart if you don’t respond quickly. Big compressor stations on pipelines, for example, where the compressors are moving at very high RPMs would use OB35.”


The malware also affects the Windows programming station that communicates with the PLC and monitors it. The hack ensures that anyone examining the logic in the PLC for problems would see only the logic that was in the system before the malware struck — the equivalent of inserting a video clip into a surveillance camera feed so that someone watching a security monitor would see a looped image of a static picture rather than a live feed of the camera’s environment.


Beyond this, the malware injects dozens of other data blocks into the PLC for unknown reasons. Byres believes these disable safety systems and cancel alarms to “make absolutely certain that there’s nothing in [the attackers’] way” preventing them from releasing their destructive payload.


Langner calls the malware “a one-shot weapon,” and assumes the attack already occurred and was successful at what it intended to do, though he acknowledges this is just speculation.


Iran Connection


Langner believes the Bushehr nuclear power plant in Iran was the Stuxnet target, but offers little evidence to support this theory. He points to a computer screenshot published by United Press International which purports to have been taken at Bushehr in February 2009 showing a schematic of the plant’s operations and a pop-up box indicating the system was using Siemens’ control software.


But Frank Rieger, chief technology officer at Berlin security firm GSMK, thinks it more likely the target in Iran was a nuclear facility in Natanz. The Bushehr reactor is designed to develop non–weapons-grade atomic energy, while the Natanz facility, a centrifuge plant, is designed to enrich uranium and presents a greater risk for producing nuclear weapons. Rieger backs this claim with a number of seeming coincidences.


The Stuxnet malware appears to have begun infecting systems in January 2009. In July of that year, the secret-spilling site WikiLeaks posted an announcement saying that an anonymous source had disclosed that a “serious” nuclear incident had recently occurred at Natanz.


WikiLeaks broke protocol to publish the information — the site generally only publishes documents, not tips — and indicated that the source could not be reached for further information. The site decided to publish the tip after news agencies began reporting that the head of Iran’s atomic energy organization had abruptly resigned for unknown reasons after 12 years on the job.


There’s speculation his resignation may have been due to the controversial 2009 presidential elections in Iran that sparked public protests — the head of the atomic agency had also once been deputy to the losing presidential candidate. But information published by the Federation of American Scientists in the United States indicates that something may indeed have occurred to Iran’s nuclear program. Statistics from 2009 show that the number of enriched centrifuges operational in Iran mysteriously declined from about 4,700 to about 3,900 beginning around the time the nuclear incident WikiLeaks mentioned would have occurred.


If Iran was the target, however, it raises questions about the scattershot method of infection — the malware spread by worm among thousands of computers in multiple countries. Targeted attacks usually start by tricking an employee at the target facility to install malware through a phishing attack or other common means. Langner suggests the scattershot approach may be the result of the infection spreading through a Russian company known to be working on the Bashehr plant and which has contracts in other countries infected by the worm.


The Russian contractor, AtomStroyExport, had security problems with its web site, leading Langner to believe it had general lax security practices that could have been exploited by attackers to get the malware into Iran. Then the malware may have simply spread to machines in other countries where AtomStroyExport worked.


If Iran was the target, the United States or Israel are suspected as the likely perpetrators — both have the skill and resources to produce complicated malware such as Stuxnet. In 1981, Israel bombed Iran’s Osiraq nuclear reactor. Israel is also believed to be behind the bombing of a mysterious compound in Syria in 2007 that was believed to be an illicit nuclear facility.


Last year, an article published by Ynetnews.com, a web site connected to the Israeli newspaper Yediot Ahronot, quoted a former Israeli cabinet member saying the Israeli government determined long ago that a cyber attack involving the insertion of targeted computer malware was the only viable way to halt Iran’s nuclear program.

Segurança em Browsers Web

Este  é o primeiro de um conjunto de posts em que iremos tentar analisar a eficácia alguns dos mecanismos e arquitecturas de segurança dos browsers Web actuais. Neste primeiro post vamos olhar para o estado actual do SSL como forma de autenticar o servidor Web e assegurar a confidencialidade e integridade das comunicações.

A propósito dos posts recentes deste blog, temos vindo aqui a discutir na SysValue a eficácia e os objectivos de alguns mecanismos de segurança dos browsers modernos.

A Web baseia-se num conjunto de tecnologias díspares que foram evoluindo ao longo do tempo de diferentes formas, de forma desorganizada e pouco homogénea. É inegável que conseguimos fazer muito mais coisas na Web hoje do que há dez anos atrás. Também é consensual que a segurança destas tecnologias está a progredir e há avanços todos os dias com o objectivo de tornar a nossa utilização da Web mais segura.

Mas será que este evoluir dos níveis de segurança está a conseguir acompanhar o aumento exponencial de complexidade e funcionalidade – e por conseguinte o aumento da superfície de ataque?

Aqui as opiniões divergem. Queria neste post começar a abordar este tema de forma pragmática focando-me numa peça fundamental do “puzzle”, o Browser (Internet Explorer, Firefox, Chrome, etc.). O objectivo neste post é lançar a reflexão sobre alguns dos mecanismos de segurança que estão presentes nos Browsers modernos. Sem os querer descartar de imediato – afinal de contas estes mecanismos são até hoje a melhor resposta aos problemas de segurança que endereçam – o objectivo é questionar alguns “dogmas” para que olhemos a segurança no Browser com um olhar fresco e despoluído.

 

1. Certificados TLS/SSL como forma de validar a legitimidade de um site

Começemos por este mecanismo, que ainda é a “espinha dorsal” da segurança na Web. Há razões para continuarmos a usar o SSL para validar se estamos no site correcto. No entanto este mecanismo começa já a mostrar algumas “rugas” de idade e desgaste de utilização excessiva:

 

Problema 1: Existe uma economia à volta do processo de certificação.

A necessidade de lucro das empresas de certificação obrigou-as a baixar os critérios de validação de uma entidade ou organismo. Há dez ou quinze anos atrás, se uma empresa como a SysValue quisesse obter um certificado para www.sysvalue.com, teria de encetar um processo longo com uma entidade certificadora, envolvendo documentos que provassem que de facto eramos quem diziamos ser, chamadas telefónicas, etc. Hoje em dia, pouco mais basta que preencher um formulário Web e fazer um pagamento.

Se em 2001 já era possível criar de forma legítima certificados fraudulentos, em 2010 não será certamente mais difícil, com o “agilizar” do processo de validação.

A prova de que isto é um problema é que as entidades certificadoras começam agora a cobrar mais por um processo de validação mais seguro apesar de, na prática, a tecnologia utilizada e o processo interno de validação de certificados no browser ser o mesmo (ver Extended Validation Certificates).

 

Problema 2: Cada Browser tem uma lista numerosa de “trusted root Certification Authorities”.

O Chrome usa a lista do sistema operativo, assim como o Internet Explorer, o Windows vem já com 32 certificados root instalados. O Firefox vem com uma lista adicional de mais de 200 certificados-raíz, mas se contarmos com a lista de entidades certificadoras intermediárias, o mapa de relações é assustadorÉ importante salientar que cada uma destas entidades certificadoras, se for comprometida, é um ponto único de falha para toda a segurança SSL/TLS fornecida pelo browser. Basta ter acesso à chave privada de uma destas CA’s para falsificar qualquer site que o utilizador visite. Existe ainda um conjunto de CA’s intermédias em cujas CA’s raíz delegaram a possibilidade de emitir certificados reconhecidos pelos browsers .

Existem ainda soluções comerciais (que eu conheça, o proxy bluecoat) que exploram este facto para fazer SSL interception. O sysadmin apenas tem de colocar um CA interno nos browsers (p. ex. via domain policy ou script), e todo o tráfego SSL é interceptado (e passível de ser manipulado) no proxy sem que o utilizador se aperceba. Além deste produto, que tem um uso legítimo, existem também aparentemente usos mais questionáveis, como a utilização deste tipo de técnicas por parte de governos e outras entidades para “escutar” tráfego SSL, obtendo junto das entidades certificadoras certificados que lhes permitem tal, existindo já produtos comerciais a ser vendidos exclusivamente para este fim.

 

Problema 3: O SSL é baseado numa estrutura fortemente hierarquizada com inúmeros “topos de pirâmide”.

O SSL é um mecanismo fortemente hierarquizado, em que o modelo de confiança nos é “imposto”: Até podemos escolher em que autoridades certificadoras (CA’s) confiar — mesmo que tal na prática nunca aconteça e usemos a lista pré-definida dos browsers –, mas em última análise são estas CA’s que escolhem por nós quais os certificados em que vamos confiar.

Este é um caso claro em que podemos colocar a pergunta “quem guarda os guardas?”. O modelo hierarquizado não responde a esta questão directamente. Existem alguns esforços, isolados e pouco transparentes (p. ex. a Microsoft exige uma auditoria de 12 em 12 meses a CA’s raiz), mas não é um modelo transparente e verdadeiramente “bottom-up”.

Isto é um contraponto óbvio face a modelos mais “ad-hoc”, tais como, por exemplo, o modelo de confiança do PGP,  o “Web of Trust”: Não existe uma hierarquia clara, cada indivíduo escolhe individualmente em quem confiar, cada indivíduo é simultaneamente um certificado e uma entidade certificadora. O modelo normalmente é baseado na transitividade e na reputação: Se eu encontro um desconhecido em que muita gente que eu conheço já manifestou confiança na sua autenticidade, poderei em princípio confiar nele.

 

Conclusões e ideias.

Deixo aqui algumas sugestões ainda embrionárias que podiam ser implementadas nos browsers para ajudar a colmatar estas “falhas de carácter” do SSL:

  • Implementar um aviso quando a pessoa nunca acedeu ao site, à semelhança do SSH. Algo do tipo “atenção, nunca acedeu a este site antes. O certificado é este, a entidade certificadora é esta, e aqui está a certification path. Deseja continuar?”. Seria ainda necessário analisar como apresentar o aviso (popup? Barra de alerta? Outra “pista” visual?) e quando o apresentar (sempre? Apenas se o utilizador pedir explicitamente?).
  • Implementar um alerta de segurança quando o certification path ou os dados do certificado mudam ao longo de visitas subsequentes (mais uma vez, o sucesso estará sempre dependente de como este alerta seria apresentado e quando o apresentar).  Se um utilizador visita um site habitualmente e este tem um certificado emitido pela Verisign (e ainda bastante dentro da sua janela de validade), não deixa de ser estranho no dia seguinte o certificado aparecer igual mas emitido por uma entidade certificadora intermédia semi-obscura. Pode acontecer tratar-se de uma mudança legítima de certificado, mas tal certamente não será muito comum.
  • Implementar nos browsers um mecanismo de reputação de certificados e entidades certificadoras. A ideia seria complementar a pirâmide hierárquica do SSL com um mecanismo adicional em que qualquer pessoa pode manifestar a sua confiança (ou desconfiança) num certificado ou entidade certificadora, um pouco à semelhança de sistemas anti-spam baseados em “crowd-sourcing” que aprendem com os utilizadores. Esta sugestão é a que está mais embrionária e certamente precisaria de mais ideias para a complementar.

Ficam sugestões para debate!