[Mickel]

Vi este mensaje hoy: http://www.lawebdelprogramador.com/n...ar.php?id=1057

Es algo a tomar en cuenta o solo un bluff?

[yoseman]

Es algo a tener muy en cuenta, es muy recomendable actualizar a la versión 2.0.11 porque a día de hoy miles de foros han sufrido de esos ataques :(

Salu2 ;)

[eschwartz]

que buena la info... yo tambien recien hoy escuche algo al respecto sobre que es un virus que ataca servidores con phpBB...

A cuidarse.
Slds..

[Elenabc123]

Alguien podría decirme donde puedo encontrar unas instrucciones (facilitas) de como actualizar mi foro a la version 2.0.11??

Gracias y saludos

[Fociños]

Cita:

Iniciado por Elenabc123

Alguien podría decirme donde puedo encontrar unas instrucciones (facilitas) de como actualizar mi foro a la version 2.0.11??

Gracias y saludos

Bájate la última versión y en la carpeta docs encontrarás la ayuda necesaria para la configuración.

[jpinedo]

Un usuario de miarroba posteó esta explicación en español

Cita:

Iniciado por admincartaya

RE: Fallo Grave de seguridad en PHPBB2

Proceso castellanizado y un poco mejor explicado:
1º Atención si tienes algun mod instalado en tu foro si haces este proceso dalo por muerto, asi que tendras que investigar con otro proceso

2º Haz una copia de seguridad de tus archivos y bases de datos , si se jode lo siento y no quiero disgustos, yo lo he hecho tal cual os lo pongo y no me ha dado ningun problema

3º bajate de aqui http://www.phpbb.com/downloads.php el
phpBB 2.0.11 [ Changed Files Only ] en el formato que mas te guste.

4º Descomprimelo en tu pc y veras que te salen 4 carpetas y otros tantos archivos compresos, de los compresos descomprime el que se adapte al cambio que vas a hacer, por ejemplo 2.0.10_to_2.0.11, version_que_tienes_to_a_la nueva (para saber la version que tienes lo puedes ver en la parte inferior de tu foro), una vez descompreso el contenido te quedaran las 4 carpetas mas otras carpetas y varios archivos(en el ejemplo 7 carpetas y 7 archivos)

5º Abre el ftp vete al directorio de tu foro y sube todas las carpetas y los archivos dejando que sobreescriba tranquilamente (nota: el .htaccess da error lo ignoras que no pasa náGiño

6º Una vez subido todo ejecuta ruta_ hasta_tu_foro/install/update_to_2011.php(ojo en la pagina de phpbb está mal) una vez que carge la pagina te dira felizmente que no errors y tal

7º pues ya ta borras las carpetas contrib e install y marchando

P.D: Espero ayudaros y asi contribuir a que no se extienda el jodio virus
un saludo a todos y felices fiestas

La dirección del mensaje es esta:
http://miarroba.com/foros/ver.php?fo...temaid=2665883

Saludos

[yoseman]

La verdad es que la última versión de phpBB impide que se pueda usar el exploit, cierra una 'puerta', pero no es ni mucho menos una solución a largo plazo. Ya que el 'Bug' cómo dicen muchos no es de phpBB, se trata de una vulnerabilidad de PHP:

Anuncio de seguridad de PHP:

Cita:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hardened-PHP Project
www.hardened-php.net

-= Security Advisory =-



Advisory: Multiple vulnerabilities within PHP 4/5
Release Date: 2004/12/15
Last Modified: 2004/12/15
Author: Stefan Esser [[email protected]]

Application: PHP4 <= 4.3.9
PHP5 <= 5.0.2
Severity: Several vulnerabilities within PHP allow
local and remote execution of arbitrary code
Risk: Critical
Vendor Status: Vendor has released bugfixed versions.
References: http://www.hardened-php.net/advisories/012004.txt


Overview:

PHP is a widely-used general-purpose scripting language that is
especially suited for Web development and can be embedded into HTML.

During the development of Hardened-PHP which adds security hardening
features to the PHP codebase, several vulnerabilities within PHP
were discovered that reach from bufferoverflows, over information
leak vulnerabilities and path truncation vulnerabilities to
safe_mode restriction bypass vulnerabilities.


Details:

[01 - pack() - integer overflow leading to heap bufferoverflow ]

Insufficient validation of the parameters passed to pack() can
lead to a heap overflow which can be used to execute arbitrary
code from within a PHP script. This enables an attacker to
bypass safe_mode restrictions and execute arbitrary code with
the permissions of the webserver. Due to the nature of this
function it is unlikely that a script accidently exposes it to
remote attackers.

[02 - unpack() - integer overflow leading to heap info leak ]

Insufficient validation of the parameters passed to unpack() can
lead to a heap information leak which can be used to retrieve
secret data from the apache process. Additionally a skilled
local attacker could use this vulnerability in combination with
01 to bypass heap canary protection systems. Similiar to 01 this
function is usually not used on user supplied data within
webapplications.

[03 - safe_mode_exec_dir bypass in multithreaded PHP ]

When safe_mode is activated within PHP, it is only allowed to
execute commands within the configured safe_mode_exec_dir.
Unfourtunately PHP does prepend a "cd [currentdir] ;" to any
executed command when a PHP is running on a multithreaded unix
webserver (f.e. some installations of Apache2). Because the name
of the current directory is prepended directly a local attacker
may bypass safe_mode_exec_dir restrictions by injecting shell-
commands into the current directory name.

[04 - safe_mode bypass through path truncation ]

The safe_mode checks silently truncated the file path at MAXPATHLEN
bytes before passing it to realpath(). In combination with certain
malfunctional implementations of realpath() f.e. within glibc this
allows crafting a filepath that pass the safe_mode check although
it points to a file that should fail the safe_mode check.

[05 - path truncation in realpath() ]

PHP uses realpath() within several places to get the real path
of files. Unfourtunately some implementations of realpath() silently
truncate overlong filenames (f.e. OpenBSD, and older NetBSD/FreeBSD)
This can lead to arbitrary file include vulnerabilities if something
like "include "modules/$userinput/config.inc.php"; is used on such
systems.

[06 - unserialize() - wrong handling of negative references ]

The variable unserializer could be fooled with negative references
to add false zvalues to hashtables. When those hashtables get
destroyed this can lead to efree()s of arbitrary memory addresses
which can result in arbitrary code execution. (Unless Hardened-PHP's
memory manager canaries are activated)

[07 - unserialize() - wrong handling of references to freed data ]

Additionally to bug 06 the previous version of the variable
unserializer allowed setting references to already freed entries in
the variable hash. A skilled attacker can exploit this to create
an universal string that will pass execution to an arbitrary
memory address when it is passed to unserialize(). For AMD64 systems
it was even possible to developed a string that directly passes
execution to shellcode contained in the string itself.

It is necessary to understand that these strings can exploit a
bunch of popular PHP applications remotely because they pass f.e.
cookie content to unserialize().

Examples of vulnerable scripts:

- phpBB2
- Invision Board
- vBulletin
- Woltlab Burning Board 2.x
- Serendipity Weblog
- phpAds(New)
- ...


Proof of Concept:

The Hardened-PHP project is not going to release exploits for any
of these vulnerabilities to the public.


CVE Information:

The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-1018 to issues 01, 02, the name
CAN-2004-1019 to issues 06, 07, the name CAN-2004-1063 to issue 03
and the name CAN-2004-1064 to issues 04, 05.


Recommendation:

It is strongly recommended to upgrade to the new PHP-Releases as
soon as possible, because a lot of PHP applications expose the
easy to exploit unserialize() vulnerability to remote attackers.
Additionally we always recommend to run PHP with the Hardened-PHP
patch applied.


GPG-Key:

http://www.hardened-php.net/hardened...nature-key.asc

pub 1024D/0A864AA1 2004-04-17 Hardened-PHP Signature Key
Key fingerprint = 066F A6D0 E57E 9936 9082 7E52 4439 14CC 0A86 4AA1


Copyright 2004 Stefan Esser. All rights reserved.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFBwIzIRDkUzAqGSqERArD/AKCqerfjCYJnZ2vy7tRYth3VqWmqhwCbB+LL
s12EomCQ0IstWmz3F/QhM8E=
=21xF
-----END PGP SIGNATURE-----

Ése mismo link lo puse en los foros de mi@, cuando Lim abrió un hilo diciendo que el servidor no tenía que ver con el asunto, y que se trata de un bug de phpBB, y eso no es cierto, es un exploit que usa una vulnerabilidad de PHP.
Y según ése árticulo que pongo, éste mismo sistema de foros sería vulnerable si la versión sobre la que corre esta dentro de las que indica de vulnerables.

Salu2 ;)

[Zertiko]

Yoseman entonces mi pregunta es que versión del php no es vulnerable a ese exploit??? porque no veo mucho sentido el actualizar a 2.0.11 si realmente no soluciona el problema???

Un saludo.

[yoseman]

La versión 2.0.11 soluciona el problema para ese exploit en concreto, pero la solución es cambiar la versión PHP del servidor a:
PHP4 > 4.3.9
PHP5 > 5.0.2

Porque al igual que ese exploit se sirve de unas vulnerabilidades de PHP que permiten la ejecución remota y las usa en el archivo viewtopic.php, puede suceder que creen algún otro que se sirva de otro script para atacar :( (incluso un script cualquiera que no tenga que ver con phpBB pero que use las funciones problemáticas ( unserialize()...etc )

Por eso digo que la solución a corto plazo es parchear la versión de phpBB para los foros que han sido atacados, pero de lo que se trata es de actualizar PHP que es el causante del problema en los sitios que han sido atacados y en los que NO han sido atacados, como medida preventiva.

Salu2 ;)