HACKERS no XOOPS: Fatal error: Call to undefined function: getbymodule() in .//projeto_1/modules/rw_banner/admin/myblocksadmin.php on line 86 Seguinte, quandoo eu acesso o menu blocos/grupos, dae esse erro ae...

testar hack para o securityimage: artsgeral escreveu: marcio , acho que sem quer querendo consegui fazer funcionar o módulo securityimage no formulario de cadastro do XOOPS versão 2.2.x. Olha a imagem abaixo, para ficar no gostinho até eu consegui ver quais as modificações que fiz. http://aycu35.webshots.com/image/21194/2002703142689222798_rs.jpg Pelo menos o mais difícil(pelo menos para mim) eu consegui resolver. Assim que tiver concluido eu posto aqui o endereço que vai estar o aqruivo no meu portal, BLZ T+ Como eu cogitei antes, os spamers voltaram a atacar meu portal. Provavelmente devido o captcha estar em um arquivo separado do form de cadastro (modules/profile/register.php) o robot conseguiu fazer o registro e encher os comentários de spams. artsgeral , se você puder me passar os arquivos já alterados do XOOPS 2.2.X para utilizar o captcha direto no form de cadastro para que eu possa fazer um teste aqui, eu fico grato. ;-)

autenticar usuário com banco de dados difenrente do mysql - ldap: legal

site hackeado: olá sacysem , Administro um portal que teve um problema semelhante, ele não foi pixado, mas teve arquivos inseridos em seus diretórios. Um certo dia, percebi um incremento considerável no consumo de banda, e alguns minutos depois, recebi um e-mail do host, informando que o portal estava hospedando scripts captadores de senhas, acessei imediatamente os arquivos e constatei os tais arquivos. Em contato com o host informei que não tinha sido eu e ninguém ligado ao portal que estava fazendo aquilo que estávamos sendo acusados, inclusive que não tinha autoridade para sequer apagar os arquivos. Providenciei um e-mail onde promovi a defesa do portal, elencando os fatos e situações, e destaquei que o fato de eu não ter autoridade para apagar os arquivos, só indicavam uma coisa: quem colocou os arquivos lá era um superusuário, ou alguém com as senhas dele... recorri também a legislação pátria para lembrá-los dos nossos direitos. E funcionou... o portal não ficou off nenhum minuto... mas tive que agir rápido, porque eles estavam inclinados a eliminar a conta do servidor. A forma de relacionamento com as pessoas também é importante, porque se nos estressarmos com as pessoas elas podem não nos ajudar a resolver os problemas. E até hoje, faz uns 6 meses isso, recebo hits nos endereços daqueles "marditos" scripts... Hehe mas não há nenhuma preocupação porque eles não estão lá. Agora, quando você se estressa mais de uma vez com o host, te falo, o jeito é mudar, porque geralmente os gerentes de host se acham semi-deuses e mandam e desmandam nos servidores de acordo com sua vontade e muitas vezes desrespeitando todos os utilizadores. é isso

xoops não é confiável!!!!: Bah pessoal! Eu migrei do Nuke para o XOOPS por questões de adaptabilidade. Me dei melhor com o XOOPS e com a linguagem dele. Os módulos, alguns mais simples, são até mais do que estou precisando para montar os portais do meu projeto de pós. Acontece que escontrei alguns erros quando atualizei da versão 2.0.13 para versão 2.0.15. O módulo usado em um portal (catads 1.4) está dando muitos erros. Pedi ajuda mas acho que o problema é únicamente comigo. Então, apesar do portal estar começando a crescer, vou fazer uma coisa drástica esta manhã: voltar para versão 2.0.13. Vou ter algumas reclamações, com certeza, mas terei o portal funcionando a 100% como estava antes. Obrigado a todos e estou me tornando fã deste fórum! Flw!

invadido xoops debader???: Posso estar enganado, mas quando tu refaz o prefixo das tabelas, deveria antes desativar no mainfile.php o protector e depois ativa-lo de novo. Não sei onde eu vi isto, rs XOOPS Agora dentro do protector, me parece que tem uma opção onde você salva antes este prefixo e cria o outro e depois modifica. Estou meio perdido nisto e me interesso pela solução também. Alguém aí para dar uma força [pergunta]

liaise não envia formulário: Bom... descobrimos que o módulo que faz toda essa confusão é o Multimenu. Vou postar novo tópico expondo o problema.

sem acesso a área de administração - 2: Existe um bloqueador no XOOPS nas preferencias de utilizadores no admin que faz restrição a alguns nome proibidos. Tu lembra o que pode ter colocado lá [pergunta] Apenas um hipotese. Agora este tópico deveria resolver o seu problema sim. [url=http://www.xoopscube.com.br/modules/newbb/viewtopic.php?topic_id=5776&forum;=10&post;_id=34221#forumpost34221]Um passo a passo para transformar um user normal em Admin[/url] Agora se você andou alterando as tabelas menciondas neste passo a passo talvez tenha comprometido a segurança das permissões do seu site.

manual de segurança para xoops: Maravilha camagada :-) Estarei liberando hoje o setor para os testes e a criação do manual sobre o DMS, e quando tiver um tempinho, passe por lá :-) Vou tentar a instalação do MediaWiki por lá, vamos torcer. XOOPS

bloqueando servidores proxy: Hum, mas que estranho, voltando ao tema que é muito importante. Relativo aos últimos acontecimentos. XOOPS

como edito um .htaccess?: Desculpe a ignorancia, mas qual painel de administração você se refere?

vulnerabilidade no php.: Desculpe-me Julio, o conteudo seria este: ============================================================ Secunia Advisory: SA17371 Print Advisory. Release Date: 2005-10-31 Last Update: 2005-11-02 Critical: Moderately critical. Impact: Security Bypass. Cross portal Scripting. DoS System access. Where: From remote. Solution Status: Vendor Patch. Software: PHP 4.0.x. PHP 4.1.x. PHP 4.2.x. PHP 4.3.x. PHP 4.4.x. PHP 5.0.x. Select a product and view a complete list of all Patched/Unpatched Secunia advisories affecting it. CVE reference: CAN-2005-2491 Description: Some vulnerabilities have been reported in PHP, which can be exploited by malicious people estou conduct cross-site scripting attacks, bypass certain security restrictions, and potentially compromise a vulnerable system. 1) An error where the "GLOBALS" array is not properly protected, can be exploited estou define global variables by sending a "multipart/form-data" POST request with a specially crafted file upload field, or via a script calling the PHP function "extract()" or "import_request_variables()". Successful exploitation may open up for vulnerabilities in various applications, but requires that "register_globals" is enabled. The vulnerability has been reported in versions 4.4.0 and 5.0.5, and prior. 2) An error in the handling of an unexpected termination in the "parse_str()" PHP function, can be exploited estou enable the "register_globals" directive for the current execution by e.g. triggering a memory_limit request shutdown in a script calling "parse_str()". The vulnerability has been reported in versions 4.4.0 and 5.0.5, and prior. 3) Some unspecified input passed estou the "phpinfo()" PHP function isn't properly sanitised before being returned estou the user. This can be exploited via a script calling "phpinfo()" estou execute arbitrary HTML and script code in a user's browser session in context of an affected site. The vulnerability has been reported in versions 4.4.0 and 5.0.5, and prior. 4) An integer overflow error in pcrelib may be exploited estou cause a memory corruption via a script calling a PHP function using the PCRE library where the regular expression can be controlled by the attacker. For more information: SA16502 Successful exploitation may allow execution of arbitrary code. 5) The problem is that it is possible estou bypass the "safe_mode" and "open_basedir" protection mechanisms via the "ext/curl" and "ext/gd" modules. 6) An unspecified error in calling "virtual()" on Apache 2 can be exploited estou bypass certain configuration directives (e.g. "safe_mode" and "open_basedir"). Other problemas have also been reported where some may be security related. Solution: Update estou version 4.4.1. http://php.net/downloads.php The vulnerabilities affecting PHP 5 have been fixed in the CVS repository. Provided and/or discovered by: 1-3) Stefan Esser, Hardened-PHP Project. Reported by vendor. Changelog: 2005-11-02: Updated "Solution" section. Original Advisory: Hardened-PHP Project: http://hardened-php.net/advisory_202005.79.html http://hardened-php.net/advisory_192005.78.html http://hardened-php.net/advisory_182005.77.html http://hardened-php.net/index.76.html The PHP Group: http://php.net/release_4_4_1.php Other References: SA16502: http://secunia.com/advisories/16502/ Please note: The information, which this Secunia Advisory is based upon, comes from third party unless stated otherwise. Secunia collects, validates, and verifies all vulnerability reports issued by security research groups, vendors, and others. Send Feedback estou Secunia: If you have new information regarding this Secunia advisory or a product in our database, please send it estou us using either our Web form or email us at vuln@secunia.com Ideas, suggestions, and other feedback is most welcome. Found: 16 Related Secunia Security Advisories, displaying 10 - PHP Trailing Slash "open_basedir" Security Bypass. - PHP Multiple Vulnerabilities. - PHP "readfile()" Denial of Service. - PHP Multiple Vulnerabilities. - PHP CURL "open_basedir" Security Bypass Vulnerability. - PHP Memory Leak and Arbitrary File Location Upload Vulnerabilities. - PHP "strip_tags()" Function and memory_limit Vulnerabilities. - PHP "escapeshellcmd()" and "escapeshellarg()" Security Bypass Vulnerability. - PHP Configuration Leakage Vulnerability. - PHP / mod_php File Descriptor Leakage Vulnerability. Show all related advisories.

xoops.org hackeado!: O cara ser idiota tudo bem, agora utilizar a corrupção do país para justificar a própria babaquice é demais! Que tipo de pessoa é bitolada o suficiente, para tirar do ar portais de projetos open source? Em vez de utilizar o conhecimento para construir alguma coisa, atrapalha o serviço dos outros. É o tipo de ser humano que não faria a menor falta nesse planeta. :(

protector, alguém sabe me informar se isso foi tentativa de invasão?: Se houvesse algum dano seria atque ao portal comprometendo o mesmo, por segurança mude as senhas de admtanto do XOOPS como do seu cpanel. Medidas: E-mail recebido enviado pela policia federal: São nossas orientações acerca do que foi notíciado: Deve ser feito registro de boletim de ocorrência na Delegacia de Polícia Civil do local onde se encontra a empresa. Responsável pelo portal que se tentou "invadir", preservando-se os logs do servidor, a contar de uma semana antes da. Tentativa de "invasão", para eventuais perícias. Divisão de Repressão aos Crimes Tecnológicos da Polícia Civil do Distrito Federal Jhonjhon escreveu: Estou com problemas tb, no meu portal apareceu como no do RMARX, no protector, porém não era visitante era um utilizador do portal mesmo, o tipo de ataque era DOS, e não tinha descrição, alguém saberia me orientar o que pode ter acontecido?, ou como posso agir nessa situação? Ou ainda, desculpe a ignorância, tem como eu saber se meu portal teve algum dano? Abraços a todos, Jhonjhon. XOOPS

acho que fui hackeado: kleberlpa! E aê? Já descobriu qual foi o problema? Conta para gente. Se precisar de ajudar é só falar. []'s. David Vasconcelos

acho que invadiram meu site, e agora????: cygraf escreveu: Agora eu pergunto, isso pode acontecer? Pensei que se hackeassem uma página, a praga não se. Espalharia por todo o server... ou o nuke e estão buraquento. Que contamina até outros utilizadores? Isso pode ocorrer sim isso porque na verdade é hospedagem compratilhada, ou seja vários portais no mesmo disco, aí algum engraçadinho tem o acesso ao root e aí já era mesmo!

xoopscube.com.br hackeado!: Fesz escreveu: Adinaldo, Desculpa a ignorancia mais o que acontece la na nave mãe? porque mesmo traduzindo os textos pelo nosso tio "Google" Não ficou muito claro. Pode exclarecer? muito obrigado. Quero saber o que se passa né , sempre é muito bom :pint: :pint: Desculpa Fesz, mas vou te ficar devendo essa. Não quero ficar alimentando mais essa polêmica. :-) Abraços, Adinaldo.

medidas de segurança: Volto a perguntar, porque considero algo sério: Há alguma recomendação do tipo: desinstalar o módulo ? Visto que não há versão nova deste módulo. Ou substituir pelo [url=http://xoops.org/modules/repository/singlefile.php?cid=78&lid;=1487]XOOP-stats[/url] Água mole em pedra dura... :hammer: :hammer: até que fura. :-D

mais um portal xoops hackeado!!: O e-mail do AstonThemes, é paul@astonthemes.com Eu particularmente acho válido o defaced, isso mostra o quanto vulnerável tal site, mas infelizmente existem os defaces assim como os crackers (hackers que apenas querem aproveitar a breja de segurança e utilizar para o mal), que de vez de mostrar onde está o problema de segurança, fala como pode resolver. Já reportei em vários que visitei e disse onde estava a falha de segurança. Sei que muitos não dão ouvidos a essas falhas, tem alguns que por causa disso precisa hackear ou fazer um defaced no portal para ver tal vulnerabilidade. Prova disso é o nosso amigo do XOOPS GIJOE, ele alertou consecutivas vezes o Mithrandir, Herko e cia. Mas não deram ouvidos. Ele abriu um tópico "XOOPS on Crack", e h-a-c-k-e-o-u a conta do Herko, mas ele pode ir muito mais além, só que mostrou que era vulnerável o XOOPS, depois disso todos estavam utilizando o XOOPS Protector. Agora quando a hackear ou não para mostrar tão vulnerabilidade vai da cabeça de cada um, o XOOPS já sofreu uma vez invasão por causa de um módulo de Upload, só que ninguém avisou que esse módulo tinha problema de invasão, apenas fomos avisados quando roubaram nosso Banco De Dados. O XOOPS sofre cerca de 3 tentativas de invasão por dia. Logo saindo o Manual de Segurança XOOPS By XOOPS não deixem de conferir. Ele está mastigadinho, não tem erro de se perder nas configurações que lá estão sendo mostradas. :-) Abraços, Adinaldo

xoops protector -o que isso significa?: comunidade que usa o protector, alguém pode esclarecer o que isso significa? MUITO OBRIGADO!