| Autor |
Mensagem |
|
|
O mercado negro vai utilizar para roubar pessoas (que é ruim). O governo chines vai utilizar para calar as ativistas de direitos humanos (que talvez seja pior ainda). 
|
 |
|
|
Sim, o mercado negro paga muito melhor. Uma citação interessante do Charlie Miller:
http://www.nytimes.com/aponline/2010/01/29/business/AP-US-TEC-China-Google-Security-Hole.html wrote:One researcher who has been open about his experience is Charlie Miller, a former National Security Agency analyst who now works in the private sector with Independent Security Evaluators. Miller netted $50,000 from an unspecified U.S. government contractor for a bug he found in a version of the Linux operating system.
Whether to pay -- and seek payment -- is hotly debated among researchers.
''I basically had to make a choice between doing something that would protect everybody and remodeling my kitchen -- as terrible as that is, I made that choice, and it's hard,'' Miller said. ''It's a lot of money for someone to turn down.''
Pessoalmente, eu vejo o mercado negro como inviavel. Além de motivos éticos, você não teria muita garantia do pagamento, etc. Pessoalmente eu já sinto mal quando vejo pessoas sendo afetadas pelos virus (link p/ AV da Microsoft) que aproveitam a falha que eu comuniquei para a Sun em 2008 e que já foi corrigido no mesmo ano.
|
|
|
|
jingle wrote:só uma pergunta... como ficaria o else desse if aqui? "-Caso eu aceito a oferta..." quer dizer que se você não aceita eles não podem concertar o erro?
Correto. Se você não aceita, eles não tem o direito de comunicar o problema ao fabricante, etc. Agora, porque é que você rejeitaria? Talvez, pelo valor ser muito baixo, você prefere você mesmo entrar em contato com a empresa responsável, tentar pressionar elas a corrigirem a falha. Talvez você queira tentar vender a falha para outro programa/empresa. Talvez você até queira negociar com o mercado negro. Talvez você queira tentar vender pro governo chines.
|
|
|
|
Leozin wrote:A remuneração é boa mesmo por essas falhas?
Então, esse programa do google está pagando 500 dólares, ou 1337 dólares para falhas muito interessantes.
A ZDI, não sei se estou na liberdade de divulgar os valores, mas são mais altos. Pelas apresentação do Pedram Amini, que trabalha no projeto ZDI, os valores vão de 1,000 dólares até 20,000 dólares. Isso parece consistente com minha experiência.
[]s,
Sami
|
|
|
|
Olá Pessoal,
Uns dias atrás foi lançado uma iniciativa pela Google de começar a remunerar pessoas que acham falhas significativas de segurança nos projetos Chrome e Chromium. Isso ganhou bastante atenção na mídia e eu pensei em aproveitar pra compartilhar algumas experiências nesse ramo.
Zero Day Initiative e iDefense são programas mais genéricas de empresas de segurança (3com Tipping Point e VeriSign respectivamente), e os três programas tratam de melhorar a segurança através de promover o tal de "responsible disclosure" - a divulgação de problemas de segurança de uma forma responsável.
Ou seja, é menos sobre você se dedicar a encontrar falhas de segurança e mais sobre agir de uma forma que protege todo mundo na hora encontrar elas.
Eu participei do programa ZDI no ano passado e tem sido bastante interessante. Como funciona?
-Eu encontro um problema de segurança grave num produto muito utilizado.
-Monto uma descrição do problema e um cenário de teste para facilitar a verificação.
-Eles analisam cuidadosamente a submissão e verificam que se trata de um problema real, grave e ainda-não-descuberto.
-Eles fazem uma oferta para comprar os direitos a essa falha.
-Caso eu aceito a oferta, eles passam ser donos daquela falha
-Eles comunicam a falha para a empresa/entidade responsável e coordenam a correção
-Eles ficam como o responsável por ter descoberta a falha (porém colocam meu nome junto como colaborador)
-Eles utilizam a informação para melhorar o produto IDS deles
-Eles ganham publicidade
-Eu concordo não divulgar nada sobre a falha
Eu queria compartilhar isso porque acho que muitas pessoas não estão cientes de programas como esses. Para uma pessoa que não trabalha com segurança de informação talvez seja difícil avaliar quão grave um determinado problema é. Mas mesmo assim, muitas vezes acabamos encontrando falhas realmente graves sem querer no nosso dia-a-dia de trabalho. E acho que é bom saber que em vez de compartilhar a falha no twitter/blog/forum e potencialmente causando problemas para muitas pessoas, ajudando os criminosos a disponibilizarem mais trojans para roubar senha de banco, em vez disso existem outras formas, possivelmente (muito bem) remuneradas de prosseguir.
Abraços,
Sami
|
|
|
|
luistiagos wrote:Eu testei todos os citados aqui... e acredita que nenhum descompila sem se perder e deixar erros de compilação?!
Eu acredito. Às vezes os erros são faceis de corrigir manualmente. O jad se comporta melhor com código compilado por compiladores antigos.
|
|
|
|
O legal do JD-GUI é que ele é muito rápido e prático pra abrir as classes. Mas às vezes ele se perde muito. Hoje se eu quero só visualizar algo compilado eu uso ele. Se eu quero descompilar para posteriormente compilar, eu uso o jad junto com o JD-GUI.
javap é prático por estar incluido no JDK, mas a saída dele é muito dificil de ler. Só bytecode puro. Pra listar os metodos de uma classe ele até serve.
[]s,
Sami
|
|
|
|
Para ver que o ViniGodoy tem razão, basta decompilar as duas versões (com e sem final) da classe.
[]s,
Sami
|
|
|
|
Eu não me expressei com muita claridade, mesmo.
ActiveX e Flash têm uma reputação muito ruim em termos de segurança. São muito utilizados para espalhar virus e trojans.
E Java tem (ou pelo menos tinha) uma reputação muito boa em termos de segurança (novamente falando de Applets) por causa da arquitetura de segurança dele. O código roda num "sandbox", só certas operações configuráveis são permitidas, os applets não conseguem acessar a rede, não conseguem acessar o disco do usuário, não conseguem executar programas. E há muitas pessoas que acham que falhas de segurança no Java são ou um mito, um boato, FUD, ou extremamente raros, mas na verdade cada segundo update do Java tem correções de segurança (Java6 update 9, 11, 13, 15, 17 etc), normalmente entre 5 e 10 itens graves.
Então, o que eu quis dizer era que na minha opinião a realidade é muito diferente da percepção geral quando se trata de segurança de Java no browser. O CVE-2008-5353 por exemplo permite que quando você entra numa página com um applet malicioso, ou uma página com um tag <applet injetado, a applet formate seu disco ou instala um vírus, desde que o usuário rodando o browser tem permissão para isso.
[]s,
Sami>
|
|
|
|
Uma notícia de dois dias atrás (5.1.2010) falando sobre applets exploitando a vulnerabilidade CVE-2008-5353 que achei interessante:
http://isc.sans.org/diary.html?storyid=7879
ISC wrote:We've had a report (thanks Tom!) of a java applet exploiting CVE-2008-5353 ( http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5353) as part of a web drive-by attack. While PoC has been around for a long time for this, this is the first time I've heard of it being used in the wild for a general attack. If anyone else has seen this, we'd be interested to hear about it.
The applet is already being detected by some A/V packages according to VirusTotal: https://www.virustotal.com/analisis/d4f5bcc9acecb2f53a78313fc073563de9fc4f7045dd8123a23a08f926a3974d-1262270360
As we get more details on what it does, we'll update this entry with it.
UPDATE: Minnie Mouse was kind enough to write and let us know that exploits for this vuln apparently are available and included in the LuckySploit, Liberty and Fragus kits. In at least one case the exploit was a recent addition
O CVE-2008-5353 é um problema na classe java.util.Calendar (trata-se de deserialização de objetos de uma forma não segura) que foi corrigido pela Sun em Dezembro de 2008 (Java 6 update 11), mas como muitas pessoas não atualizam o Java, os trojans ainda fazem sucesso. E eu sei de fato que a versão atual do Java está com pelo menos uns 6 falhas da mesma gravidade que a Sun ainda não corrigiu. A sorte é que o pessoal escrevendo os trojan desconhece essas falhas.
Os trojans devem continuar sendo escritos na linguagem nativa, a função do Java é simplesmente baixar um executável na maquina do usuário e depois executar.
Acho que fica cada vez mais óbvio que mesmo com o sandbox de segurança os Applets (ou JavaFX) na verdade não são tão mais seguros do que um ActiveX.
Falando estritamente de applets aqui, o mundo dos servidores de aplicações/web é totalmente diferente.
[]s,
Sami
|
|
|
|
Olá,
Acho que está o problema está na lógica.
Para mim, isso parece dar o resultado correto:
Eu tirei o cont-- do for, e invertei a regra do if final. (linha 15 nesse exemplo)
[]s,
Sami
|
|
|
|
Olá,
Talvez você queira/precisa resolver do seu jeito, provavelmente isso é um exercisio de lógica, e se for o caso, favor ignorar minha sugestão:
No mundo binário, as potências de 2 têm uma caracteristica que é que eles tem exatamente um bit setado, o resto são zeros.
dec 1 = bin 1
dec 2 = bin 10
dec 4 = bin 100
dec 8 = bin 1000
...
e assim pra frente. A classe Integer tem um método que diz quantos bits setados tem num número. Portanto seu método poderia ser definido assim (ele funciona para valores positivos. Só dá resultado errado para -214748364 :
[]s,
Sami
|
|
|
|
Olá,
JAD é linha de comando, muito bom, apesar de que acho que está descontinuado.
Tanto DJ Java Decompiler quanto CAVAJ são somente interfaces gráficas que usam JAD para descompilar.
Se o .class for ofuscado de certa forma, o código produzido pelo descompilador não vai compilar.
Meu projeto reJ tá parado faz alguns anos já, mas ele serve pra fazer alterações muito pequenas de classes compiladas. Só que ele não descompila exatamente - ele permite a alteração do código compilado com um editor de bytecode.
[]s,
Sami
|
|
|
|
Olá,
Não é um assunto que eu conheço muito bem, mas pra quem conhecer, provavelmente seria util saber com qual banco você está trabalhando.
Oracle tem uns views do sistema que ajudam com esse tipo de coisa, que dizem quem é que tá com lock do que.
Eu já vi uma vez uma pagina que tinha vários selects diferentes que mostraram esse tipo de coisa. Agora só achei esse:
http://www.dba-oracle.com/t_locked_rows_user_locks.htm
Mas poderia te ajudar depurar o problema.
[]s,
Sami
|
|
|
|
Tradução podre é um problema mais antigo ainda. 
O ataque foi chamado de sofisticado por varias fontes, e involvia SQL injection, mas o SQL injection não foi a parte sofisticada.
Pra uma descrição melhor (mais especulação nos comentarios):
http://securosis.com/blog/new-details-and-lessons-on-heartland-breach
According to our source, this is exactly what happened. SQL injection was used to compromise a system outside the transaction processing network segment. They used that toehold to start compromising vulnerable systems, including workstations. One of these internal workstations was connected by VPN to the transaction processing datacenter, which allowed them access to the sensitive information. These details were provided in a private meeting held by Heartland in Florida to discuss the breach with other members of the payment industry.
|
|
|
|
|
|