Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Ping 1 en Windows, Mac OS X y Linux
Hoy tengo un poco de lío, así que toca un post rapido de una curiosidad con la que estaban jugando mis compañeros de auditoria web en Informática64 con el ping en IPv4 que tal vez os sirva alguna vez. La idea es hacer un Ping a una dirección IPv4 pero sin poner los 4 bytes, que tiene un comportamiento muy concreto en Windows y Mac OS X, aunque en Linux tiene un comportamiento ligeramente distinto.
 |
| Figura 1: Ping 1 en Windows |
 |
| Figura 2: Ping 1 en Mac OS X |
- Si se pone sólo 1 byte, rellena con ceros por la izquierda
- Con dos bytes, rellena de ceros en el medio.
- Con tres bytes, rellena de ceros el tercer byte.
Al final, la explicación parece ser que el último valor, cuando no están los cuatro bytes, lo toma como valor entero alineado a la derecha que luego se rellena con ceros, por lo que pue suceden cosas como que Ping 1.4000 es lo mismo que Ping 1.0.15.160 y que Ping 2.2.2000 es equivalente a Ping 2.27.208.
 |
| Figura 3: Ping 1 en Linux |
En los sistemas Linux, Ping 1 falla, pero el resto es similar. ¿Alguna idea en dónde usar esto?
Saludos Malignos!
16 comentarios:
Si te sirve, en un debian:
patatin$ ping 1
connect: Invalid argument
patatin$ ping 1.1
PING 1.1 (1.0.0.1) 56(84) bytes of data.
patatin$ ping 1.1.1
PING 1.1.1 (1.1.0.1) 56(84) bytes of data.
@Román Ramírez, curioso... voy a actualizar el post...
Lo único útil sería el no tener que completar con 0's como en este ejemplo:
C:\Windows\System32>ping 192.168.1
Haciendo ping a 192.168.0.1 con 32 bytes de datos:
Respuesta desde 192.168.0.1: bytes=32 tiempo=2ms TTL=64
Respuesta desde 192.168.0.1: bytes=32 tiempo=1ms TTL=64
Respuesta desde 192.168.0.1: bytes=32 tiempo=1ms TTL=64
Respuesta desde 192.168.0.1: bytes=32 tiempo=5ms TTL=64
Estadísticas de ping para 192.168.0.1:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0
(0% perdidos),
Pero cabe decir que he tardado más pensando el hueco que tenía que dejar que en haber rellenado todo :S
A lo mejor con práctica ahorra algo de tiempo.
Saludos Maligno!
Todo tiene un sentido:
http://blogs.itpro.es/oscarmarin/2006/uso-avanzado-del-comando-ping-windows/
@Oscar, en el caso de Ping 10.1, los 0 intermedios son evidentes, pero en Ping 1 y en Ping 1.1.1 no lo son tanto. Además es curioso que en Linux no funcione Ping 1.
Lo de codificar la IP en otros formatos nos ha venido muy bien para saltar filtros, como en el caso de 90 pares de ojos.
Me ha gustado lo del MTU, no lo suelo utilizar, y mola ese trick.
Saludos!
Casualidades de la vida, ayer me pasó una cosa similar en Android. Diría que pasaba igual tanto en Chrome como en el navegador que viene en mi Galaxy S2 con ICS: haciendo pruebas contra un Apache en dos redes distintas, al cambiar la IP de 192.168.1.2 a 192.168.0.27, borré el .2 (quedó 192.168.1) y le di a "Ir", y me mostró como error que no podía encontrar 192.168.0.1.
@Maligno, al parecer debe venir de la implementación que hace Windows o Linux de inet_aton(), échale un ojo a la descripción http://linux.die.net/man/3/inet_aton concretamente:
a.b.c.d
Each of the four numeric parts specifies a byte of the address; the bytes are assigned in left-to-right order to produce the binary address.
a.b.c
Parts a and b specify the first two bytes of the binary address. Part c is interpreted as a 16-bit value that defines the rightmost two bytes of the binary address. This notation is suitable for specifying (outmoded) Class B network addresses.
a.b
Part a specifies the first byte of the binary address. Part b is interpreted as a 24-bit value that defines the rightmost three bytes of the binary address. This notation is suitable for specifying (outmoded) Class C network addresses.
a
The value a is interpreted as a 32-bit value that is stored directly into the binary address without any byte rearrangement.
Prueba a hacer un ping 1.2.333
En linux habría que ver si se interpreta de la misma forma en todas las distribuciones o no.
@Oscar, gran aporte! Ping 1.2.333 da como resultado Ping a 1.2.1.77 }:))
Mola!
ping 3232235777 hace un ping a 192.168.1.1, pero me da a mi que no es muy fácil acordarse de ese número...
Aunque un escaneo de ip's rudimentario es más fácil así...
saludos.
Linux
$ ping 0
PING 0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.028 ms
Windows
C:\>ping 0
Haciendo ping a 0.0.0.0 con 32 bytes de datos:
PING: error en la transmisión. Error general.
C:\>ping 256
Haciendo ping a 0.0.1.0 con 32 bytes de datos:
PING: error en la transmisión. Error general.
Para el comportamiento de Windows con un solo número si tengo una explicación. Es que permite el ping a una dirección de red en notación entero de 32 bits (al fin y al cabo son 4 bytes).
Puede servir para hacer un bucle sencillo y escanear con ping una rango: de 2886732288 a 2886732799 escaneas el rango de la 172.16.10.0/23.
Lo de rellenar con 0 (por ejemplo 1.1 = 1.0.0.1) me recuerda a la notación de IPv6. Aunque sería más normal que fuera al reves :)
ping 127.1
...
En contextos muy específicos sería útil para bypassear algún filtro...
De hecho, te falto probar
Ping 256 y fijate que ocurre :D
Quiza sea una aportacion muy fuera de lugar, pero tiene que ver con el manejo hacia ipv6 y las abreviaciones, por eso esas reglas de relleno tan extrañas.. (ahorran mucho tiempo)
El ping 1 desde luego que funciona en linux (a la hora de generar la direccion). Luego se deniega su uso por ser una direccion no valida como destino. Lo mismo si haces ping 0.1.2.3
Porque windows se salta el comportamiento indicado en este rfc? Pues preguntadselo a ellos...
rfc1122 seccion 3.2.13
{ , }
(a) { 0, 0 }
This host on this network. MUST NOT be sent, except as
a source address as part of an initialization procedure
by which the host learns its own IP address.
El problema de ping 1 en Linux es una comprobación de argumento que hace el propio ping antes de resolver ni hacer nada.
#include
#include
#include
#include
int main(int argc, char *argv[])
{
struct in_addr add;
inet_aton(argv[1], &add) ;
printf ("IP: %s\n", inet_ntoa(add));
return 0;
}
Eso en linux, hace que la dirección 1 la resuelva como 0.0.0.1, la 256 como 0.0.1.0, la 65536 como 0.1.0.0, al final interpreta los 4 bytes del número que pongamos como la IP. Lo bueno es cuando nos pasamos de los 32bits. Por ejemplo 4294967295 (2^32-1) nos dará 255.255.255.255, 4294967296 (2^32) en Linux, yo creo que coge IPs de algún lado perdido de la memoria porque no tienen relación con los números de IP que representan... ¿ eso lo podríamos explotar de alguna forma ?
Publicar un comentario