Análise estática de código

Software Assurance: Time to Raise the Bar on Static Analysis
Dark Reading

The results from tools studies suggest that using multiple tools together can produce more powerful analytics and more accurate results.
I had an interesting conversation recently about the after-effects of Heartbleed and the challenges facing static analysis with Barton Miller, the chief scientist of the Software Assurance Marketplace (SWAMP), which is a project I’m sponsoring at the Department of Homeland Security to improve software quality, and raise the bar of static analysis capabilities.

I wanted to know if the problems associated with static analysis can be attributed to a lackluster analysis engine. Are the core engines in static analysis tools robust enough to keep pace with the complexity and size of modern software? Obviously, these tools appear to be lacking in depth and breadth, which results in oversimplifying, which may lead tools to make inaccurate assumptions about code; as a result they miss (simple) things and produce a generous amount of false-positives.

(...)

De volta ao Citius

No blog já apareceram diversas notícias sobre o Citius mas parece que desta é de vez: deixa de ser possível ignorar o estado lastimável de um sistema que é crítico para o funcionamento do país. O artigo mais interessante que vi sobre o assunto saiu no Observador. Um excerto:

"As bases do sistema informático onde são colocados os processos cíveis, de família e menores e algumas gravações e notificações dos processos-crime não nasceu por concurso público. Partiu da iniciativa de um grupo de oficiais de justiça curiosos, que por acaso sabiam programar. Na altura, nos finais dos anos 1990, o parto do sistema deu-se numa sala alugada pelo Ministério da Justiça em Coimbra. Foi ali que a equipa o batizou de “Citius/Habilis” e que o desenvolveu em Vbase 6, uma linguagem de programação entretanto caída em desuso."

Continuo sem perceber por que é que a Informática é a única profissão que pode ser exercida por "curiosos" :-(

Tribunais mudam mas não saem do mesmo Citius - Observador

Shellshock ao ataque

Uma análise interessante de diversos ataques em curso contra a vulnerabilidade na Bash, aka Shellshock.

"We have observed a significant amount of overtly malicious traffic leveraging BASH, including

Malware droppers

Reverse shells and backdoors

DDoS"

Shellshock in the Wild - FireEye blog

Actualização (2/10): além deste os melhores artigos que encontrei sobre o Shellshock estão no blog do M. Zalewski (Google):

Quick notes about the bash bug, its impact, and the fixes so far
Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)



Roubo de dados médicos

Hackers roubam dados médicos para vender no mercado negro
Observador

Na sequência de um ataque a uma das maiores operadoras de hospitais norte-americana, o FBI alertou os profissionais de saúde para tomarem medidas de proteção contra os ciberataques, adiantou a agência noticiosa Reuters. No mês passado, a Community Health Systems Inc. foi atacada por hackers chineses, que entraram dentro da rede de computadores da operadora e roubaram a informação pessoal de 4,5 milhões de pacientes.

A indústria da saúde norte-americana está gradualmente a tornar-se num alvo preferencial dos criminosos, devido à pouca segurança dos sistemas informáticos hospitalares. Muitas empresas e hospitais utilizam ainda sistemas informáticos antigos, sem a proteção dos mais recentes recursos de segurança, o que permite aos hackers aceder aos dados com relativa facilidade.

Os dados roubados são os mais variados. Nomes, datas de nascimento, números de apólices de seguros, códigos de diagnósticos e informações de faturamento, quase tudo serve para depois ser vendido pelos hackers no mercado negro da saúde. Os criminosos usam depois a informação roubada para criar identidades falsas para comprarem equipamento médico ou medicamentos para venda. Outra das fraudes passa pela combinação do número de um paciente com um número falso de um fornecedor, que é depois utilizado para preencher um pedido junto de uma seguradora.

BashSmash / ShellShock: vulnerabilidade permite execução remota de código na bash

Uma vulnerabilidade séria e com mais de 20 anos:

Bash specially-crafted environment variables code injection attack
redhat security blog

(...)  It is common for a lot of programs to run bash shell in the background. It is often used to provide a shell to a remote user (via ssh, telnet, for example), provide a parser for CGI scripts (Apache, etc) or even provide limited command execution support (git, etc).

the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:
  • ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
  • Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
  • PHP scripts executed with mod_php are not affected even if they spawn subshells.
  • DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
  • Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
  • Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.
(...)

OWASP Testing Guide v4

Acaba de ser publicada a 4ª edição do OWASP Testing Guide. Ainda não li mas parece impressionante.

Dyre/Dyreza - malware dirigido à Salesforce

Uma análise muito interessante desse malware, que tem por objectivo roubar credenciais de acesso à Salesforce.

artigo

Ebook malicioso para Kindle

Engraçado: um Ebook malicioso para Kindle rouba as credenciais Amazon do dono através de um ataque de cross site scripting.

Amazon.com Stored XSS via Book Metadata

Amazon's Kindle Library, also known as "Manage Your Content and Devices" and "Manage your Kindle", is, at the time of writing, vulnerable to Stored Cross-Site Scripting (XSS) attacks. (Update 2014-09-16: Apparently, Amazon fixed the issue earlier today.) Malicious code can be injected via e-book metadata; for example, an e-book's title.

Once an attacker manages to have an e-book (file, document, ...) with a title like

added to the victim's library, the code will be executed as soon as the victim opens the Kindle Library web page. As a result, Amazon account cookies can be accessed by and transferred to the attacker and the victim's Amazon account can be compromised.



(...)

artigo completo

Roubar mails com DNS cache poisoning



CERT warns that DNS Cache Poisoning attacks could be used also to hijack email to a rogue server and not only to divert the Internet traffic.

(...)

Aprender segurança experimentando

SEED Labs

The objective of the SEED project is to develop an instructional laboratory environment and laboratory exercises (called labs) for computer system security education. Our approach is motivated by the traditional mature courses, such as Operating Systems (OS), Compilers, and Networking. In OS courses, a widely adopted successful practice is using an instructional OS (e.g. Minix, Nachos, and XINU) as a framework and ask students to write significant portions of each major piece of a modern OS. The Compiler and Network courses adopted a similar approach. Inspired by the success of the instructional OS strategy, we adapt it to our computer security courses. Namely, we use an instructional operating system (Minix) as our basis, and develop lab exercises on this instructional system.

The goal of our labs is to help students focus on (1) grasping security principles, concepts, and technologies, (2) applying security principles to design and implement security mechanisms, (3) analyzing and testing systems for security properties. (4) applying security principles to solve real-world problems. To meet this goal, we have designed a number of labs. Since 2002, we have been experimenting with some of these labs in both undergraduate and graduate courses, including Introduction to Computer Security, Computer Security, and Internet Security.


the matasano crypto challenges

We've built a collection of 48 exercises that demonstrate attacks on real-world crypto.

This is a different way to learn about crypto than taking a class or reading a book. We give you problems to solve. They're derived from weaknesses in real-world systems and modern cryptographic constructions. We give you enough info to learn about the underlying crypto concepts yourself. When you're finished, you'll not only have learned a good deal about how cryptosystems are built, but you'll also understand how they're attacked.

Hackers usam anti-virus online para testar o seu malware

Um artigo muito interessante da Wired ("A Google Site Meant to Protect You Is Helping Hackers Attack You") que explica como várias equipas de hackers têm vindo a usar o serviço VirusTotal para testar se o malware que desenvolvem é detectar por vários anti-virus.

Before companies like Microsoft and Apple release new software, the code is reviewed and tested to ensure it works as planned and to find any bugs.
Hackers and cybercrooks do the same. The last thing you want if you’re a cyberthug is for your banking Trojan to crash a victim’s system and be exposed. More importantly, you don’t want your victim’s antivirus engine to detect the malicious tool.
So how do you maintain your stealth? You submit your code to Google’s VirusTotal site and let it do the testing for you.
(...)
VirusTotal is a free online service—launched in 2004 by Hispasec Sistemas in Spain and acquired by Google in 2012—that aggregates more than three dozen antivirus scanners made by Symantec, Kaspersky Lab, F-Secure and others. Researchers, and anyone else who finds a suspicious file on their system, can upload the file to the site to see if any of the scanners tag it malicious. But the site, meant to protect us from hackers, also inadvertently provides hackers the opportunity to tweak and test their code until it bypasses the site’s suite of antivirus tools.

Um aspecto interessante é que até equipas sofisticadas como a APT1 e NetTraveler foram descobertas a usar o serviço:
One of the most prolific groups he tracked belongs to the infamous Comment Crew team, also known by security researchers as APT1, which was responsible for hacking The New York Times. Believed to be a state-sponsored group tied to China’s military, Comment Crew also reportedly is responsible for stealing terabytes of data from Coca-Cola, RSA and more than 100 other companies and government agencies since 2006. More recently, the group has focused on critical infrastructure in the U.S., targeting companies like Telvent, which makes control system software used in parts of the U.S. electrical power grid, oil and gas pipelines and in water systems. The group Dixon tracked isn’t the main Comment Crew outfit but a subgroup of it.
He also spotted and tracked a group known by security researchers as NetTraveler. Believed to be in China, NetTraveler has been hacking government, diplomatic and military victims for a decade, in addition to targeting the office of the Dalai Lama and supporters of Uyghur and Tibetan causes.

Outro ponto é que a utilização de trial&error básico para tentar evitar a detecção:

The data provides a rare and fascinating look at the inner workings of the hacker teams and the learning curve they followed as they perfected their attacks. During the three months he observed the Comment Crew gang, for example, they altered every line of code in their malware’s installation routine and added and deleted different functions. But in making some of the changes to the code, the hackers screwed up and disabled their Trojan at one point. They also introduced bugs and sabotaged other parts of their attack. All the while, Dixon watched as they experimented to get it right.
Between August and October 2012, when Dixon watched them, he mapped the Crew’s operations as they modified various strings in their malicious files, renamed the files, moved components around, and removed the URLs for the command-and-control servers used to communicate with their attack code on infected machines. They also tested out a couple of packer tools—used to reduce the size of malware and encase it in a wrapper to make it harder for virus scanners to see and identify malicious code.
Some of their tactics worked, others did not. When they did work, the attackers often were able to reduce to just two or three the number of engines detecting their code. It generally took just minor tweaks to make their attack code invisible to scanners, underscoring how hard it can be for antivirus engines to keep pace with an attacker’s shapeshifting code.
There was no definitive pattern to the kinds of changes that reduced the detection rate. Although all of the samples Dixon tracked got detected by one or more antivirus engine, those with low detection rates were often found only by the more obscure engines that are not in popular use.

Artigo completo na Wired