Saiu na Thebug! Magazine meu artigo sobre fuzzing. Publiquei um Heap Overflow local para MacOSx e um fuzzer em python como prova de conceito.
Check now -> http://www.thebugmagazine.org/magazine/bug04/0×01-fuzz.txt
” To temperance . . . in moderation. “
27
Jun
Saiu na Thebug! Magazine meu artigo sobre fuzzing. Publiquei um Heap Overflow local para MacOSx e um fuzzer em python como prova de conceito.
Check now -> http://www.thebugmagazine.org/magazine/bug04/0×01-fuzz.txt
5
Jan

Process Dumper e uma ferramenta que recupera varias informações do seu gmail como lista de contatos, corpo da mensagem, nomes de contas do gmail etc. Muito útil para quem faz analise forense.
Mais informacoes:
http://www.trapkit.de/research/forensic/pd/index.html
28
May
Denovo nAOOOOOO!!!!
Segue o Advisory:
CERT-FI Vulnerability Advisory on OpenSSL
Version Information
Advisory Reference FICORA #130450
Release Date 28 May 2008 10:30 UTC
Last Revision 28 May 2008
Version Number 1.1
Acknowledgement
Vulnerabilities were discovered by Ossi Herrala and Jukka Taimisto from the CROSS project at Codenomicon Ltd., and reported directly to the vendor through CERT-FI.
What is Affected?
The vulnerabilities described in this advisory affect OpenSSL versions 0.9.8f and 0.9.8g.
Impact
The impact from vulnerabilities can expose a Denial-of-Service (DoS) condition.
Summary
OpenSSL has two programming errors which cause it to crash. The first error causes OpenSSL to crash to segmentation fault when it receives TLS 1.0 Client Hello packet which contains server name extension having server_name set to 0×00. The openssl program does not have TLS extension handling enabled by default, it has to be explicitly enabled at compile time. The second error causes the SSL client implementation to crash to segmentation fault caused by NULL pointer dereference when ‘Server Key exchange message’ is omitted from the TLS handshake. The fault is present when Anonymous Diffie-Hellman key exchange is used.
Details
The first problem occurs when OpenSSL is run with command line
openssl s_server -key path_to_key \
-cert path_to_certificate \
-www `openssl ciphers ‘ALL:COMPLEMENTOFALL’`
receives Client Hello packet containing server name extension data having one server host name set where the length of the name is 1 and the data is single zero byte. It seems that the program detects the erroneus host name (in ssl/t1_lib.c, line 325) and then proceeds to end the handshake. When ending the handshake then program ends up trying to free already freed pointer. The stack backtrace when running the program on debugger shows following:
Program received signal SIGSEGV, Segmentation fault.
0×0000003a5806cbb7 in malloc_consolidate () from /lib64/libc.so.6
(gdb) bt
#0 0×0000003a5806cbb7 in malloc_consolidate () from /lib64/libc.so.6
#1 0×0000003a5806e7a7 in _int_free () from /lib64/libc.so.6
#2 0×0000003a5807214c in free () from /lib64/libc.so.6
#3 0×0000000000484c85 in CRYPTO_free (str=0×837030) at mem.c:378
#4 0×000000000045d3a7 in ssl3_free (s=0×8281e0) at s3_lib.c:1685
#5 0×00000000004663d7 in tls1_free (s=0×8281e0) at t1_lib.c:108
#6 0×0000000000473bf2 in SSL_free (s=0×8281e0) at ssl_lib.c:508
#7 0×0000000000482bef in ssl_free (a=0×8291f0) at bio_ssl.c:131
#8 0×00000000004c60f9 in BIO_free (a=0×8291f0) at bio_lib.c:136
#9 0×00000000004c6d21 in BIO_free_all (bio=0×828f40) at bio_lib.c:516
#10 0×000000000042b08d in www_body (hostname=0×822300 “localhost.localdomain”, s=7, context=0×0) at s_server.c:2231
#11 0×000000000043d329 in do_server (port=4433, type=1, ret=0×7dd708, cb=0×42a266 , context=0×0) at s_socket.c:310
#12 0×00000000004290cd in s_server_main (argc=0, argv=0×7fff26b87000) at s_server.c:1335
#13 0×0000000000402cee in do_cmd (prog=0×813f70, argc=12, argv=0×7fff26b86fa0) at openssl.c:382
#14 0×0000000000402a1e in main (Argc=12, Argv=0×7fff26b86fa0) at openssl.c:301
(gdb)
The second problem occurs when openssl is run with following command line:
openssl s_client -connect localhost:4433 -cipher \
`openssl ciphers ‘ALL:COMPLEMENTOFALL’` -debug -msg
The openssl sends ‘Client Hello’ message to server which responds with ‘Server Hello’ message (having selected TLS_DH_ANON_WITH_RC4_128_MD5 cipher suite), followed by Server Hello Done (omitting Server Key Exchange message).
The program dies with segmentation fault on ssl3_get_key_exchange() function, caused by the s->session->sess_cert being NULL. The stack backtrace from the core file shows following:
Program terminated with signal 11, Segmentation fault.
#0 0×000000000045be7b in ssl3_send_client_key_exchange (s=0×80dd90) at s3_clnt.c:1970
1970 if (s->session->sess_cert->peer_dh_tmp != NULL)
(gdb) bt
#0 0×000000000045be7b in ssl3_send_client_key_exchange (s=0×80dd90) at s3_clnt.c:1970
#1 0×000000000045882d in ssl3_connect (s=0×80dd90) at s3_clnt.c:341
#2 0×00000000004746c3 in SSL_connect (s=0×80dd90) at ssl_lib.c:859
#3 0×0000000000465e14 in ssl23_get_server_hello (s=0×80dd90) at s23_clnt.c:593
#4 0×0000000000464ecf in ssl23_connect (s=0×80dd90) at s23_clnt.c:169
#5 0×0000000000466126 in ssl23_write (s=0×80dd90, buf=0×818100, len=0) at s23_lib.c:184
#6 0×0000000000474891 in SSL_write (s=0×80dd90, buf=0×818100, num=0) at ssl_lib.c:912
#7 0×000000000042e251 in s_client_main (argc=0, argv=0×7fff05afd018) at s_client.c:1065
#8 0×0000000000402cee in do_cmd (prog=0×813f70, argc=7, argv=0×7fff05afcfe0) at openssl.c:382
#9 0×0000000000402a1e in main (Argc=7, Argv=0×7fff05afcfe0) at openssl.c:301
The error occurs since ssl3_get_key_exchange() allows omitting the Server Key Exchange message (which is correct, of course) but the s->session->sess_cert is left to NULL and it is not checked at ssl3_get_server_done(). Instead, the client state machine proceeds to ssl3_send_client_key_exchange() where it does not check the validity of s->session->sess_cert but just tries to dereference it (s3_clntl.c:1970).
Solution
Patch the affected software with the patches supplied by the vendor or update to version 0.9.8h.
Vendor Statements
OpenSSL
The issue is covered in the advisory secadv_20080528.
Cisco
We have tested our product sets that use OpenSSL and have concluded that our products are “Not vulnerable”.
Credits
CERT-FI would like to thank Codenomicon for providing the vulnerability information and Mark Cox of OpenSSL for his co-operation.
Contact Information
CERT-FI Vulnerability Coordination can be contacted as follows:
Email:
vulncoord@ficora.fi
Please quote the advisory reference in the subject line
Telephone:
+358 9 6966 510
Monday - Friday 08:00 - 16:15 (EET: UTC+2)
Fax :
+358 9 6966 515
Post:
Vulnerability Coordination
FICORA/CERT-FI
P.O. Box 313
FI-00181 Helsinki
FINLAND
CERT-FI encourages those who wish to communicate via email to make use of our PGP key. The key is available at https://www.cert.fi/en/activities/contact/pgp-keys.html
22
May
Excelente artigo de Kevin Beaver sobre as falhas mais comuns em aplicações web.
“When developing applications it isn’t enough to think about how they will be used. You must also consider how they will be misused — or abused — so that you can prevent attacks. Kevin Beaver gives some examples of Web application weak spo ts that your development team should consider.”
Link para o artigo: http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1310166,00.html
22
May

Tem um grande debate na lista bugtraq falando se o apache e vulneravel a um ataque de (XSS) utf7. William Rowe (Apache Team) explica porque o Apache nao esta vulneravel a este ataque mais o Interner Explorer sim. O primeiro post do William ele diz o seguinte: http://seclists.org/bugtraq/2008/May/0166.html
“Internet Explorer’s autodetection of UTF-7 clearly violates this specification, introducing the opportunity for myriad similar attacks. These are literally everywhere on the web today, we can trust the kids to continue to explore this vector until it is fixed by Microsoft. ”
“However this vulnerability should clearly be labeled as a flaw in Internet Explorer. If the browsers under your supervision continue to enable the autodetection of UTF-7, your users remain at risk. As all ISO, UTF-8 and related charsets were 7-bit clean, it’s clear that Microsoft err’ed on the side of accepting UTF-7 charset for automatic detection, contrary to to the behavior dictated by RFC 2616. ”
Vale apena conferir.
Email Thread Link: http://www.securityfocus.com/archive/1/492220/30/0/threaded
8
Jan

Existe um burburinho recente sobre rookits em MBR. Bem vamos por partes.
O que e a MBR?
Segundo a WIkipedia,
O arranque de um sistema PC segue os seguintes passos: POST (Power On Self Test, um pequeno teste de intercomunicação dos componentes da motherboard), aquisição dos dados do BIOS e reprogramação do suporte I/O, e seguidamente é lida o primeiro sector (MBR) do 1º disco do 1º canal da controladora (por exemplo, IDE 0/Master).
O MBR contém 512 bytes de informação da estrutura jr organizacional do disco (partições, código de arranque do sistema operativo, e assinatura desse código):
| Código de arranque do SO | Master Partition Table | Assinatura | |||
| 446 bytes | 16 bytes | 16 bytes | 16 bytes | 16 bytes | 2 bytes |
Basicamente se voce consegue controlar MBR, voce pode controlar o sistema operacional.
Ataques na MBR existem desde a era MS-DOS. Virus como Stoned, Michelangelo, Junkie e Tequila usam esta técnica para infectar os sistemas, o mais incrível e que 10 anos depois este tipo de ataque esta se tornando comum.
Como vimos códigos maliciosos que modificam a MBR não e novidade. Em 2005 Derek Soeder da eEye Digital Security criou um rookit como prova de conceito que infecta a MBR de nome “BootRoot”
Em 2007, Nitin e Vipin Kumar do NVLabs publicou um rootkit que infecta a MBR novamente, de nome “Vbootkit” que e possível exploitar a ultima versão do Microsoft Windos Vista. Symantec detectou este ataque com o nome Trojan.Mebroot.
De volta ao passado?